[Hyperledger Fabric v1.0] 4. OPREATION GUIDE(운영가이드): Membership Service Providers(MSP)(멤버 서비스 공급자)

해당 글은 Hyperledger Fabric 페이지의 게시글을 번역 및 정리한 자료입니다.

원본 사이트 : http://hyperledger-fabric.readthedocs.io/en/release/msp.html

 Membership Service Providers(MSP)(멤버 서비스 공급자)

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

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

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

Hyperledger Fabric 블록 체인 네트워크는 하나 이상의 MSP에 의해 관리될 수 있습니다. 이러한 방식으로 Fabric은 멤버쉽 운영의 모듈화와 다양한 멤버쉽 표준 및 아키텍처 전반의 상호 운용성을 제공합니다.

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

MSP Configuration(MSP 구성)

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

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

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

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

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

• X.509 인증서 형태로 되어 있으며 루트 인증서 인증서의 루트 중 하나에 대한 검증 가능한 인증서 경로가 있습니다.
• 그들은 어떤 CRL에도 포함되어 있지 않습니다.
• 또한 X.509 인증서 구조의 OU 필드에 하나 이상의 MSP 구성의 조직 구성 단위를 나열합니다.

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

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

• 노드에 의한 서명에 사용되는 서명 키.
• 노드의 X.509 인증서, 즉 이 MSP의 확인 매개 변수 아래에 유효한 ID입니다.

How to generate MSP certificates and their signing keys?(MSP 인증서와 서명 키를 생성하는 방법)

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

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

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

MSP setup on the peer & orderer side(피어 및 발주자 측의 MSP 설정)

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

1. 관리자 인증서에 각각 해당하는 PEM 파일을 포함하는 admincerts 폴더
2. 루트 CA의 인증서에 각각 해당하는 PEM 파일을 포함하는 cacerts 폴더
3. (선택 사항) 중간 CA 인증서에 각각 해당하는 PEM 파일을 포함하는 intermediatecerts 폴더
4. 고려 대상 OU에 대한 정보를 포함하는 config.yaml 파일 (선택 사항). 후자는 OrganizationalUnitIdentifiers로 불리는 yaml 배열의 <Certificate, OrganizationalUnitIdentifier> 항목 쌍으로 정의됩니다 . 여기서 Certificate는 이 조직 단위(예 : ./cacerts/cacert.pem)의 구성원을 인증하기 위해 고려해야 하는 인증 기관의 인증서에 대한 상대 경로(루트 또는 중간)를 나타내며 OrganizationalUnitIdentifier는 X.509 인증서 OU 필드(예 : "COP")에 나타날 것으로 예상되는 실제 문자열을 나타냅니다.
5. 고려 대상 CRL을 포함할 crls 폴더 (선택 사항)
6. 노드의 서명 키가 있는 PEM 파일을 포함하는 keystore 폴더
7. 노드의 X.509 인증서가 있는 PEM 파일을 포함하는 signcerts 폴더
8. (선택 사항) TLS 루트 CA의 인증서에 각각 해당하는 PEM 파일을 포함하는 tlscacerts 폴더
9. (선택 사항) 중간 TLS CA 인증서에 각각 해당하는 PEM 파일을 포함하는tlsintermediatecerts 폴더

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

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

Channel MSP setup(채널 MSP 설정)

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

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

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

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

Best Practices(모범 사례)

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

1) Mapping between organizations/corporations and MSPs(단체 / 기업과 MSP 간의 매핑)

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

• 다양한 MSP를 사용하는 한 조직. 이는 관리 독립성을 이유로 또는 개인 정보 보호를 이유로 MSP로 대표되는 다양한 부서를 포함하는 조직의 경우에 해당합니다. 이 경우 피어는 단일 MSP 만 소유 할 수 있으며 다른 조직의 피어가 동일한 조직의 피어로 인식되지 않습니다. 이것의 의미는 동료들이 가십 조직 범위의 데이터를 실제 조직을 구성하는 전체 제공자가 아닌 동일한 하위 단위의 구성원과 공유 할 수 있다는 것입니다.
• 단일 MSP를 사용하는 여러 조직. 이것은 유사한 회원 구성에 의해 관리되는 조직의 컨소시엄의 경우에 해당합니다. 동일한 실제 조직에 속해 있는지 여부에 관계없이 동일한 MSP에서 신원이있는 동료에게 동료 범위의 메시지를 전파해야한다는 것을 여기에서 알아야합니다. 이것은 MSP 정의 및 / 또는 피어 구성의 세분화 한계입니다. 패브릭의 차후 버전에서는 (i) 네트워크의 모든 회원 관련 정보를 포함하는 ID 채널, (ii) 피어의 관리자가 피어에서 지정하는 피어의 관리자가 구성 할 수있는 "트러스트 영역"의 피어 개념 MSP 구성원이 조직 범위 메시지를 수신하도록 승인 된 것으로 동료에 의해 처리되어야하는 설정 시간.

2) One organization has different divisions (say organizational units), to which it wants to grant access to different channels.(하나의 조직은 서로 다른 부서 (조직 단위)를 가지고 있으며 , 서로 다른 채널에 대한 액세스 권한을 부여.)

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

• 모든 조직 구성원의 구성원 자격을 수용하도록 하나의 MSP를 정의하십시오 . 해당 MSP의 구성은 루트 CA, 중간 CA 및 관리자 인증서 목록으로 구성됩니다. 회원 ID에는 OU회원이 속한 조직 단위 ( ) 가 포함 됩니다. 정책을 정의하여 특정 구성원을 파악할 OU수 있으며 이러한 정책은 채널의 읽기 / 쓰기 정책 또는 체인 코드의 승인 정책을 구성 할 수 있습니다. 이 접근 방식의 한계는 가십 피어가 로컬 MSP에서 동일한 회원의 회원 자격을 가진 동료를 동일 조직의 구성원으로 간주하여 결과적으로 조직 범위 데이터 (예 : 자신의 상태)를 가십을 수 있다는 것입니다.
• 하나의 MSP를 정의하여 각 부서를 나타냅니다 . 여기에는 각 부서에 대해 루트 CA, 중간 CA 및 관리 인증서에 대한 인증서 집합이 지정되므로 MSP간에 중복되는 인증서 경로가 없어야합니다. 이는, 예를 들어 세분당 다른 중간 CA가 사용됨을 의미합니다. 여기서 단점은 하나가 아닌 하나 이상의 MSP를 관리하는 것이지만, 이전 방법에서 제기 된 문제를 우회하는 것입니다. 또한 MSP 구성의 OU 확장을 활용하여 각 부서에 대해 하나의 MSP를 정의 할 수 있습니다.

3) 클라이언트를 동일한 조직의 동료와 분리합니다.

많은 경우에 신원의 "유형"은 신원 자체에서 검색 할 수 있어야합니다 (예 : 고객 또는 전적으로 주문자가되는 노드가 아닌, 동료가 보증을 보증해야하는 경우).

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

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

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

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

4) 관리자 및 CA 인증서

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




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

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

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

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