[하이퍼레저 공식문서]Operations Guides - Membership Service Providers(MSP)

Membership Service Providers (MSP)

이 문서는 MSP의 설정 및 모범 사례에 대한 세부 정보를 제공합니다.

멤버쉽 서비스 공급자(MSP)는 멤버십 운영 아키텍처의 추상화를 제공하는 것을 목표로하는 구성 요소입니다.

특히 MSP는 인증서 발급 및 유효성 검사 및 사용자 인증에 대한 모든 암호화 메커니즘 및 프로토콜을 추상화합니다. MSP는 자신의 신원 개념과 신원을 관리 (신원 확인) 및 인증 (서명 생성 및 검증)하는 규칙을 정의 할 수 있습니다.

Hyperledger 패브릭 블록 체인 네트워크는 하나 이상의 MSP에 의해 관리 될 수 있습니다. 이는 멤버쉽 작업의 모듈화와 다양한 멤버쉽 표준 및 아키텍처 간의 상호 운용성을 제공합니다.

이 문서의 나머지 부분에서는 Hyperledger Fabric에서 지원하는 MSP 구현의 설정에 대해 자세히 설명하고 그 사용과 관련된 모범 사례에 대해 논의합니다.

MSP 구성

MSP의 인스턴스를 설정하려면 Peer 및 Orderer 서명을 가능하게하기 위해 각 Peer 및 Orderer에게 로컬로 구성을 지정하고 Peer, Orderer, 클라이언트 ID 유효성 검사 및 각 서명 확인을 가능하게 하는 채널에서 구성을 지정해야합니다 (인증 ) 모든 채널 회원에 의해.

우선, 각각의 MSP에 대한 이름이 네트워크에 해당 MSP를 참조하기 위해 지정 될 필요 (예를 들어 msp1, org2 및 org3.divA). 컨소시엄, 조직 또는 조직 부서를 대표하는 MSP의 멤버십 규칙을 채널에서 참조하는 이름입니다. 이를 MSP Identifier 또는 MSP ID 라고도합니다 . MSP 식별자는 MSP 인스턴스별로 고유해야합니다. 예를 들어, 동일한 식별자를 가진 두 개의 MSP 인스턴스가 시스템 채널 genesis에서 탐지되어야합니다. Orderer 설정은 실패합니다.

MSP의 기본 구현의 경우 ID (인증서) 유효성 검사 및 서명 확인을 허용하기 위해 일련의 매개 변수를 지정해야합니다. 이 매개 변수는 RFC5280 에 의해 추론되며 다음을 포함합니다.

• root of trust 를 구성하는 자체 서명 (X.509) 인증서 목록
• 이 공급자가 인증서 유효성 검사를 위해 고려하는 중간 CA를 나타내는 X.509 인증서 목록. 이러한 인증서는 신뢰의 루트에있는 인증서 중 하나만으로 인증 받아야합니다. 중간 CA는 선택적 매개 변수입니다.
• 이 MSP의 관리자를 나타낼 수 있는 신뢰할 수있는 인증서 경로가있는 X.509 인증서 목록입니다. 이 인증서의 소유자는 이 MSP 구성 (예 : 루트 CA, 중간 CA)에 대한 변경을 요청할 수 있는 권한이 있습니다.
• 이 MSP의 유효한 구성원이 X.509 인증서에 포함해야하는 조직 단위 목록 이것은 선택적 구성 매개 변수로, 예를 들어 여러 조직에서 동일한 신뢰 루트와 중간 CA를 활용하고 해당 구성원에 대해 OU 필드를 예약한 경우 사용됩니다
• 나열된 (중간 또는 루트) MSP 인증 기관 중 정확히 하나에 각각 해당하는 인증서 해지 목록 (CRL) 목록 이것은 선택적 매개 변수입니다.
• TLS 인증서 의 TLS root 를 구성하는 자체 서명 (X.509) 인증서 목록입니다 .
• 이 공급자가 고려하는 중간 TLS CA를 나타내는 X.509 인증서 목록; 이 인증서는 TLS root of trust의 인증서 중 하나만으로 인증 받아야합니다. 중간 CA는 선택적 매개 변수입니다.

이 MSP 인스턴스의 유효한 ID는 다음 조건을 충족해야합니다.

• 이들은 X.509 인증서의 형태로되어 있으며 신뢰할 수 있는 인증서 루트와 정확히 일치하는 하나의 인증서 경로가 있습니다.
• CRL에는 포함되지 않습니다.
• 또한 X.509 인증서 구조의 OU 필드에 MSP 구성의 조직 구성 단위 중 하나 이상을 나열합니다.

현재 MSP 구현에서 ID의 유효성에 대한 자세한 내용은 MSP Identity Validity Rules(MSP ID 유효성 규칙) 을 참조하십시오 .

검증 관련 매개 변수 외에도 MSP가 서명 또는 인증을 위해 인스턴스화 된 노드를 활성화하려면 다음을 지정해야합니다.

• 노드에서 서명하는 데 사용되는 서명 키 (현재 ECDSA 키만 지원됨)
• 노드의 X.509 인증서로,이 MSP의 확인 매개 변수 아래에 유효한 ID입니다.

MSP ID는 절대로 만료되지 않습니다. 해당 CRL에 추가하여 취소할 수 있습니다. 또한 현재 TLS 인증서 해지 시행을 지원하지 않습니다.

How to generate MSP certificates and their signing keys?

X.509 인증서를 생성하여 MSP 구성을 제공하려면 응용 프로그램에서 Openssl 을 사용할 수 있습니다. 우리는 Hyperledger Fabric에서 RSA 키를 포함한 인증서를 지원하지 않는다는 점을 강조합니다.

또는 cryptogen 도구를 사용할 수도 있습니다.이 도구의 작업 방법은 Getting Started(시작하기) 에서 설명 합니다.

Hyperledger Fabric CA 는 MSP를 구성하는 데 필요한 키와 인증서를 생성하는데도 사용할 수 있습니다.

MSP setup on the peer & orderer side

관리자는 로컬 MSP (Peer 또는 Orderer용)를 설정하려면 6 개의 하위 폴더와 파일을 포함 하는 폴더 (예 : $MY_PATH/mspconfig)를 만들어야 합니다.

1. 관리자 인증서에 각각 해당하는 PEM 파일을 포함하는 admincerts 폴더
2. 루트 CA의 인증서에 각각 해당하는 PEM 파일을 포함하는 cacerts 폴더
3. (선택 사항) 중간 CA 인증서에 각각 해당하는 PEM 파일을 포함하는 intermediatecerts 폴더
4. (선택 사항) 파일 config.yaml을 사용하여 지원되는 조직 단위 및 ID 분류를 구성합니다 (아래 각 절 참조).
5. (선택 사항) 고려 대상 CRL을 포함할 crls 폴더
6. 노드의 서명 키가 있는 PEM 파일을 포함 하는 keystore 폴더. 우리는 현재 RSA 키가 지원되지 않는다는 것을 강조한다.
7. 노드의 X.509 인증서가 있는 PEM 파일을 포함하는 signcerts 폴더
8. (선택 사항) TLS 루트 CA의 인증서에 각각 해당하는 PEM 파일을 포함하는 tlscacerts 폴더
9. (선택 사항) 중간 TLS CA 인증서에 각각 해당하는 PEM 파일을 포함하는 tlsintermediatecerts 폴더

노드의 구성 파일 (Peer에 대한 core.yaml 파일 및 Orderer에 대한 orderer.yaml)에서 mspconfig 폴더의 경로와 노드의 MSP의 MSP 식별자를 지정해야합니다. mspconfig 폴더에 대한 경로는 FABRIC_CFG_PATH에 상대적인 것으로 예상되며 Peer에 대한 mspConfigPath 매개변수의 값으로 제공되고, Orderer는 LocalMSPDir로 제공됩니다. 노드의 MSP 식별자는 Peer에 대한 매개 변수 localMspId 및 Orderer에 대한 LocalMSPID 값으로 제공됩니다. 이러한 변수는 Peer에 대한 CORE 접두사 (예 : CORE_PEER_LOCALMSPID)와 Orderer의 ORDERER 접두사 (예 : ORDERER_GENERAL_LOCALMSPID)를 사용하여 환경을 통해 무시할 수 있습니다. Orderer 설정을 위해서는 시스템 채널의 genesis 블록을 생성하고 Orderer에게 제공해야합니다. 이 블록의 MSP 구성 요구 사항은 다음 절에서 자세히 설명합니다.

"로컬" MSP의 재구성 은 수동으로만 가능하며 Peer 또는 Orderer 프로세스가 다시 시작되어야합니다. 후속 릴리스에서는 온라인 / 동적 재구성 (노드 관리 시스템 체인 코드를 사용하여 노드를 중지 할 필요 없음)을 제공하는 것을 목표로합니다.

Organizational Units

이 MSP의 구성원이 유효한 X.509 인증서에 포함되어야하는 조직 구성 단위 목록을 구성하려면 config.yaml 파일에서 조직 구성 단위 식별자를 지정해야합니다. 다음은 그 예입니다 :

OrganizationalUnitIdentifiers:
  - Certificate: "cacerts/cacert1.pem"
    OrganizationalUnitIdentifier: "commercial"
  - Certificate: "cacerts/cacert2.pem"
    OrganizationalUnitIdentifier: "administrators"

위의 예에서는 두 개의 조직 구성 단위 식별자인 상업용(commercial) 및 관리자(administrators) 를 선언합니다. MSP ID는 이러한 조직 구성 단위 식별자 중 하나 이상을 포함하는 경우 유효합니다. 이 Certificate 필드는 특정 OU가있는 ID의 유효성을 검사해야하는 CA 또는 중간 CA 인증서 경로를 나타냅니다. 경로는 MSP 루트 폴더와 관련이 있으며 비워 둘 수 없습니다.

Identity Classification

기본 MSP 구현을 사용하면 x509 인증서의 OU를 기반으로 ID를 클라이언트 및 피어로 더 분류 할 수 있습니다. ID 는 트랜잭션을 제출하거나 피어를 쿼리하는 등의 경우 클라이언트(client) 로 분류되어야합니다. ID 는 트랜잭션을 승인하거나 커밋하는 경우 피어(peer) 로 분류되어야 합니다. 특정 MSP의 클라이언트 및 피어를 정의하려면 config.yaml 파일을 적절히 설정해야합니다. 다음은 그 예입니다.

NodeOUs:
  Enable: true
  ClientOUIdentifier:
    Certificate: "cacerts/cacert.pem"
    OrganizationalUnitIdentifier: "client"
  PeerOUIdentifier:
    Certificate: "cacerts/cacert.pem"
    OrganizationalUnitIdentifier: "peer" 

위에서 보여준 것처럼, NodeOUs.Enable 값은 true로 설정되어 신원 분류를 가능하게합니다. 그런 다음 client (peer) 식별자는 NodeOUs.ClientOUIdentifier( NodeOUs.PeerOUIdentifier) 키에 대해 다음 속성을 설정하여 정의됩니다.

1. OrganizationalUnitIdentifier : 클라이언트 (피어)의 x509 인증서에 포함해야하는 OU와 일치하는 값으로 설정합니다.
2. Certificate : 이를 클라이언트 (피어) ID의 유효성을 검사해야하는 CA 또는 중간 CA로 설정합니다. 필드는 MSP 루트 폴더와 관련이 있습니다. 비어있을 수 있습니다. 즉, MSP 구성에 정의 된 모든 CA에서 ID의 x509 인증서를 확인할 수 있습니다.

분류가 활성화되면 MSP 관리자는 해당 MSP의 클라이언트여야합니다. 즉, x509 인증서는 클라이언트를 식별하는 OU를 전송해야합니다. 신원은 클라이언트 또는 피어가 될 수 있습니다. 두 분류는 상호 배타적입니다. ID가 클라이언트도 아니고 피어도 아닌 경우 유효성 검사가 실패합니다.

마지막으로, 업그레이드 된 환경에서는 분류 식별을 사용하기 전에 1.1 채널 기능을 활성화해야합니다.

Channel MSP setup

시스템의 초기 단계에서 네트워크에 나타나는 모든 MSP의 확인 매개 변수를 지정하고 시스템 채널의 genesis 블록에 포함해야합니다. MSP 확인 매개 변수는 MSP 식별자, 트러스트 인증서 루트, 중간 CA 및 관리자 인증서, OU 사양 및 CRL로 구성됩니다. 시스템 genesis 블록은 설치 단계에서 orderers에게 제공되며 채널 생성 요청을 인증할 수 있습니다. 명령자는 동일한 식별자를 가진 두 개의 MSP를 포함하는 경우 시스템 genesis 블록을 거부하므로 결과적으로 네트워크의 부트 스트랩이 실패합니다.

응용 프로그램 채널의 경우 채널을 관리하는 MSP의 확인 구성 요소만 채널의 genesis 블록에 있어야합니다. 우리는 하나 이상의 피어에게 채널에 참여하도록 지시하기 전에 올바른 MSP 구성 정보가 채널의 구성 블록 (또는 가장 최근 구성 블록)에 포함되도록하는 것이 응용 프로그램의 책임 임을 강조합니다 .

configtxgen 도구를 사용하여 채널을 부트 스트랩 할 때 mspconfig 폴더에 MSP의 확인 매개 변수를 포함하고 configtx.yaml의 해당 섹션에서 해당 경로를 설정하여 채널 MSP를 구성 할 수 있습니다.

해당 MSP의 CA와 관련된 인증서 해지 목록의 알림을 포함하여 채널에서 MSP를 다시 구성 하는 작업은 MSP의 관리자 인증서 중 하나의 소유자가 config_update 개체를 만들어서 수행합니다. 그러면 관리자가 관리하는 클라이언트 응용 프로그램은 이 MSP가 나타나는 채널에 이 업데이트를 알립니다.

Best Practices

이 섹션에서는 일반적으로 충족되는 시나리오에서 MSP 구성에 대한 모범 사례를 자세히 설명합니다.

1) 단체 / 기업과 MSP 간의 매핑

조직과 MSP 간에는 일대일 매핑이 권장됩니다. 다른 매핑 유형의 매핑이 선택되면 다음 사항을 고려해야합니다.

• 다양한 MSP를 사용하는 한 조직. 이는 관리 독립성을 이유로 또는 개인 정보 보호를 이유로 MSP로 대표되는 다양한 부서를 포함하는 조직의 경우에 해당합니다. 이 경우 피어는 단일 MSP 만 소유할 수 있으며 다른 조직의 피어가 동일한 조직의 피어로 인식되지 않습니다. 이것이 의미하는 바는 동료는 가십 조직 범위의 데이터를 통해 동일한 조직의 구성원인 피어 집합과 공유할 수 있지만 실제 조직을 구성하는 전체 제공자 집합과 공유할 수는 없습니다.
• 단일 MSP를 사용하는 여러 조직. 이것은 유사한 회원 구성에 의해 관리되는 조직의 컨소시엄의 경우에 해당합니다. 동일한 실제 조직에 속해 있는지 여부에 관계없이 동일한 MSP에서 신원을 가진 동료에게 동료 범위의 메시지를 전파해야한다는 것을 여기에서 알아야합니다. 이것은 MSP 정의 및 / 또는 피어 구성의 세분화 한계입니다.

2) 한 조직은 서로 다른 부서 (조직 단위)를 가지고 있으며 , 서로 다른 채널에 대한 액세스 권한을 부여하려고합니다.

이것을 처리하는 두 가지 방법 :

• 모든 조직 구성원의 구성원 자격을 수용하도록 하나의 MSP를 정의하십시오. 해당 MSP의 구성은 루트 CA, 중간 CA 및 관리자 인증서 목록으로 구성됩니다. 회원 ID에는 회원이 소속된 조직 단위 (OU) 가 포함됩니다. 정책을 정의하여 특정 OU의 구성원을 파악할 수 있으며 이러한 정책은 채널의 읽기 / 쓰기 정책 또는 체인 코드의 승인 정책을 구성 할 수 있습니다. 이 접근 방식의 한계는 가십 피어가 로컬 MSP에서 회원 자격을 가진 동료를 동일한 조직의 구성원으로 간주하여 결과적으로 조직 범위의 데이터 (예 : State)를 가십을 수 있다는 것입니다.

• 하나의 MSP를 정의하여 각 부서를 나타냅니다 . 여기에는 각 부서에 대해 루트 CA, 중간 CA 및 관리 인증서에 대한 인증서 집합이 지정되므로 MSP간에 중복되는 인증서 경로가 없어야합니다. 이는 예를 들어 세분당 다른 중간 CA가 사용됨을 의미합니다. 여기서 단점은 하나가 아닌 하나 이상의 MSP를 관리하는 것이지만 이전 방법에서 제기된 문제를 우회하는 것입니다. MSP 구성의 OU 확장을 활용하여 각 부서에 대해 하나의 MSP를 정의 할 수도 있습니다.

3) 고객을 동일한 조직의 동료와 분리합니다.

많은 경우에 신원의 "유형"을 신원 자체에서 검색할 수 있어야합니다 (예 : clients 또는 orderers로만 활동하는 노드가 아닌, peers가 보증을 보증해야하는 경우).

이러한 요구 사항에 대한 지원은 제한적입니다.

이러한 분리를 허용하는 한 가지 방법은 clients와 peers / orderers를 위한 하나의 노드 유형에 대해 별도의 중간 CA를 작성하는 것입니다. 두 개의 서로 다른 MSP를 구성하십시오. 하나는 clients용이고 다른 하나는 peers / orderers용입니다. 이 조직이 액세스해야하는 채널은 두 MSP를 모두 포함해야하며, 인증 정책은 동료를 참조하는 MSP만 사용합니다. 결국 궁극적으로 조직이 두 개의 MSP 인스턴스에 매핑되고 peers와 clients가 상호 작용하는 방식에 어떤 영향을 미칩니다.

동일한 조직의 모든 peers가 여전히 하나의 MSP에 속하기 때문에 가십(gossip)은 크게 영향을 받지 않습니다. peers는 특정 시스템 체인 코드의 실행을 로컬 MSP 기반 정책으로 제한할 수 있습니다. 예를 들어 peers는 clients인 로컬 MSP의 admin이 요청을 서명한 경우 (최종 사용자가 요청의 출처에 있어야 함) "joinChannel" 요청만 실행합니다. peer / orderer MSP의 멤버가되는 유일한 클라이언트가 해당 MSP의 관리자가 된다는 사실을 받아들이면 이 불일치를 해결할 수 있습니다.

이 접근법과 함께 고려해야 할 또 다른 포인트는 피어가 자신의 로컬 MSP 내의 요청 발신자의 회원 자격을 기반으로 이벤트 등록 요청을 승인하는 것입니다. 분명히, 요청의 발신자가 클라이언트이기 때문에, 요청 발신자는 요청된 피어와 다른 MSP에 속하도록 항상 운명 지워지고 피어는 요청을 거부합니다.

4) 관리자 및 CA 인증서

root of trust 또는 중간 CA에 대해 MSP에서 고려한 인증서와 다른 MSP 관리 인증서로 설정하는 것이 중요합니다. 이는 구성원 구성 요소 관리의 의무를 새 인증서 발급 및 / 또는 기존 인증서 유효성 검사와 구분하는 일반적인 (보안) 방법입니다.

5) 중간 CA를 블랙리스트에 올린다.

이전 섹션에서 언급했듯이 MSP의 재구성은 재구성 메커니즘 (로컬 MSP 인스턴스의 수동 재구성 및 채널의 MSP 인스턴스에 대해 올바르게 구성된 config_update 메시지를 통해 수행)을 통해 이루어집니다. 분명히, MSP에서 고려되는 중간 CA가 더 이상 해당 MSP의 신원 확인을 위해 고려되지 않는지 확인하는 두 가지 방법이 있습니다.

1. 신뢰할 수 있는 중간 CA 인증서 목록에 해당 중간 CA 인증서를 더 이상 포함하지 않도록 MSP를 다시 구성합니다. 로컬로 구성된 MSP의 경우 이 CA의 인증서가 해당 intermediatecerts 폴더에서 제거되었음을 의미합니다.
2. 언급된 중간 CA의 인증서를 거부하는 root of trust에서 생성된 CRL을 포함하도록 MSP를 다시 구성합니다.

현재 MSP 구현에서 우리는 더 간단하고 더 이상 고려되지 않는 중간 CA를 블랙리스트에 올 필요가 없으므로 방법 (1) 만 지원합니다.

6) CA와 TLS CA

MSP ID의 루트 CA와 MSP TLS 인증서의 루트 CA (및 상대 중간 CA)는 서로 다른 폴더에 선언해야합니다. 이는 서로 다른 클래스의 인증서 간에 혼란을 피하기 위한 것입니다. MSP ID와 TLS 인증서 모두에 대해 동일한 CA를 재사용하는 것이 금지되어 있지는 않지만 최선의 방법은 프로덕션 환경에서 이를 피하기 위한 것입니다.

출처 : http://hyperledger-fabric.readthedocs.io/en/release-1.1/msp.html