Membership Service Providers (MSP)

원서 : https://hyperledger-fabric.readthedocs.io/en/release-1.4/msp.html

• 자세히 MSP를 설치하고 실예를 보는 시간을 가져 봅시다.
• MSP는 "membership 아키텍쳐"의 추상화를 제공하는 컴포넌트라 볼 수 있습니다.
• 특히, '인증서 발급 및 검증' 및 '사용자 인증'에 관한 모든 "암호화 와 프로토콜"을 추상화 합니다.
• MSP는 자신의 'Identity 개념'을 정의할수 있고, 'Identity 검증' 및 '인증' 관련 규직을 정할수있습니다.
• Hyperledger Fabric의 blockchain-network에서는 하나 이상의 MSP으로 관리할수있습니다.
• 이를통해, 'membership 작업'의 모듈화 와 서로다른 membership간에 상호운영성이 가능합니다.
• 그럼 MSP 설치하고 실예를 보도록 합시다...
• MSP Configuration
  
  • MSP 인스턴스를 설치하려면, 각각의 peer 및 orderer 로컬에 MSP-configuration을 해줘야 합니다.
  • (channel의 모든 member들의 'Idendity 검증' 및 '인증' 을 할수있어야 하는것 이죠)
  • 먼저, 네트워크 상에서 명시를 할 'MSP 이름'을 정해야 합니다.
  • MSP의 'membership 규칙' 하에, consortium이나 organization을 대표할수있도록 작명하면 됩니다.
  • 즉, 'MSP ID'로 할수있습니다. 각각에 MSP 인스턴스마다 자신의 'MSP ID' 가 있는것 이죠.
  • 예를들면, 특정 channel에서 똑같은 'MSP ID'가 기존재하면~ 해당 설치는 실패될것입니다.
  • 디폴트 MSP 구현체에서는 'Identity 검증' 및 '인증' 을 위해, 몇가지 파라미터가 필요합니다.
  • 해당 파라미터는 "RFC5280" 을 따릅니다.
    • root of trust 인증서 목록. (자가서명) (필수)
    • intermediate CAs 인증서 목록. (RoT서명) (선택)
    • 검증가능한 인증서 경로가 있는 인증서 목록. (필수)
      • (해당 MSP 관리자인 RoT와 정확히 연결되야 함)
      • (root CAs, intermediate CAs 같이 해당 인증서 소유자가~ MSP-configuration 변경함)
    • Organizational-Units 목록. (해당 MSP의 유효한 member로 구성) (선택)
    • CRLs(certificate revocation lists) 목록. (선택)
    • TLS를 위한, root of trust 인증서 목록. (자가서명) 
    • TLS를 위한, intermediate CAs 인증서 목록. (RoT서명)
  • MSP 인스턴스의 'Identity 검증'이 유효하기 위해서는 아래의 조건을 만족해야 합니다.
    
    • 'X.509 인증서' 형식으로, 적확히 하나의 "root of trust 인증서"에 대해 검증가능한 인증서 경로가 있어야 함.
    • 당연히 CRLs에 포함 되면 안됨.
    • 'X.509 인증서' 형식의 OU필드에, 하나 이상의 "MSP-configuration Organizational-Units"를 나열함.
  • (좀더 자세히 알고 싶으면, "MSP Identity Validity Rules"을 참고 하시람니다.)
  • MSP의 '인증' 은 아래중 하나를 지정해야 합니다.
    • 서명키 (현재는 ECDSA keys 만 지원)
    • node’s X.509 인증서
  • (참고적으로, MSP 인증서는 웹처럼... 자동 만료폐기 되는 기능은 없습니다. CRLs으로 관리하세요)
  • (또한, TLS는 현재 폐기 기능을 지원하지 않습니다.)
• How to generate MSP certificates and their signing keys?
  
  • MSP-configuration을 제공하려면, 'X.509 인증서'를 생성을 해야합니다. (아래 3가지 방안)
  • 1) 'OpenSSL' 을 사용하기. (현재 Hyperledger Fabric에서는 "RSA 키"를 사용하는 인증서는 지원안됨)
  • 2) 'cryptogen 툴' 사용하기.
  • 3) 'Hyperledger Fabric CA' 이용하기. (keys and certificates 생성가능)
• MSP setup on the peer & orderer side
  
  • 각 peer 및 orderer 에 'local MSP' 를 설치하려면, "6개의 하위폴더"를 가지는 "mspconfig폴더"를 준비해서 아래와같이 합니다.
    • 1) 'admincerts' 폴더에는 "administrator 인증서" 에 해당하는 'PEM 파일'. (필수)
    • 2) 'cacerts' 폴더에는 "root CA's 인증서" 에 해당하는 'PEM 파일'. (필수)
    • 3) 'intermediatecerts' 폴더에는 "intermediate CA's 인증서" 에 해당하는 'PEM 파일'. (선택)
    • 4) 'config.yaml' 파일. (Organizational-Units 및 identity-classifications 설정) (선택)
    • 5) 'crls' 폴더에는 CRLs 관련파일. (선택)
    • 6) 'keystore' 폴더에는 "각 node의 서명키" 에 해당하는 'PEM 파일'. ("RSA 키" 미지원) (필수) 
    • 7) 'signcerts' 폴더에는 "각 node의 인증서" 에 해당하는 'PEM 파일'. (필수) 
    • 8) 'tlscacerts' 폴더에는 "TLS root CA's 인증서" 에 해당하는 'PEM 파일'.
    • 9) 'tlsintermediatecerts' 폴더에는 "intermediate TLS CA's 인증서" 에 해당하는 'PEM 파일'.
  • 각 node의 설정파일(예:peer의 core.yaml 혹은 orderer의 orderer.yaml)에서, "mspconfig폴더 경로" 와 "MSP ID"를 지정해주면 됩니다.
  • ("mspconfig폴더 경로"는 환경변수 'FABRIC_CFG_PATH'의 상대경로 하면 됩니다.)
  • (이 경로는 peer에 'mspConfigPath' 파라미터로 제공됩니다.)
  • (이 경로는 orderer에 'LocalMSPDir' 파라미터로 제공됩니다.)
  • ("MSP ID"는 peer에 'localMspId' 및 orderer에 'LocalMSPID' 파라미터로 제공됩니다.)
  • (peer의 CORE 환경변수, 예:CORE_PEER_LOCALMSPID 으로 대체가능)
  • (orderer의 ORDERER 환경변수, 예:ORDERER_GENERAL_LOCALMSPID 으로 대체가능)
  • 참고적으로 orderer 설치시, channel의 genesis block 으로 제공해아 합니다.
  • 참고적으로 'local MSP'의 재설치는 각 node에서 "수작업/재시작" 해야합니다. (차후 릴리즈에서 "온라인/무중단" 재설치 지원예정)
• Organizational Units
  
  • 'X.509 인증서'에 Organizational-Units 목록(MSP의 유효한 member)를 설정하려면, "config.yaml 파일" 에 "OU identity"를 명시하면 됩니다.
    • 예) commercial 및 administrators OU identity
    • OrganizationalUnitIdentifiers:
      • - Certificate: "cacerts/cacert1.pem" OrganizationalUnitIdentifier: "commercial"
      • - Certificate: "cacerts/cacert2.pem" OrganizationalUnitIdentifier: "administrators"
    • // 'Certificate 필드'는 CA 혹은 intermediate CA 인증서로, msfconfig폴더의 상대경로
  • 'MSP identity'는 최소 하나의 "OU identity"를 가지고 있어야 하는것 입니다.
• Identity Classification
  
  • 디폴트 MSP 구현체에서는 client 와 peer 를 'X.509 인증서'의 OUs로 구별 해줍니다.
  • 'client identity'는 "transaction 제출" , "peer 쿼리" 을 하는 부류입니다.
  • 'peer identity'는 "transaction 보증 및 커밋" 을 하는 부류입니다.
  • 즉, 특정 MSP에서 client 와 peer 를 정의하기 위해서는~ "config.yaml 파일" 에 적절히 하면 됩니다.
    • 예)
    • NodeOUs:
      • Enable: true // identify-classification 활성화
      • ClientOUIdentifier:
        • Certificate: "cacerts/cacert.pem" // 빈값일 경우, MSP의 CA하 모든 인증서 유효
        • OrganizationalUnitIdentifier: "client" // 'X.509 인증서'의 OU와 일치된 값
      • PeerOUIdentifier:
        • Certificate: "cacerts/cacert.pem" // ''
        • OrganizationalUnitIdentifier: "peer" // ''
  • identity-classification가 활성화 되면, 'MSP 관리자'는 해당 MSP의 'client'여야 합니다.
  • 즉,'X.509 인증서'에 'client'를 식별하는 'OU identity' 를 가지고 있어야 합니다.
  • 'identity'는 'client' 또는 'peer' 인데, 이 둘은 상호배타적 입니다. ('client' 아니면 'peer')
• Channel MSP setup
  
  • 시스템 초창기 때, 모든 "MSP 검증 파라미터"를 지정하고~ channel의 genesis-block에 넣어야 합니다.
  • "MSP 검증 파라미터"는 'MSP identifier' 및 'root of trust','intermediate CA','admin' 인증서 및 'OUs' 및 'CRLs 입니다.
  • genesis-block은 설치시 orderer에게 제공되어지고, orderer는 이를 물고 시작합니다. 
  • 그 결과 orderer는 (genesis-block 기반하에) "channel 생성요청"의 인증처리를 하게됩니다.
  • 또한 orderer는 동일한 2개의 MSP를 가지는 genesis-block은 거부합니다. (네트워크 부트스트랩 실패)
  • application 차원에서, MSP들의 '검증 컴포넌트'는 channel의 genesis-block에 있어야 합니다.
  • 옳바른 MSP-configuration 정보가 genesis-blocks에 잘 포함 시키는건! application 측에서 꼭 해주셔야 합니다.
  • "configtxgen툴"을 통해 channel을 부트스트랩하시려면, 'channel MSP'을 "mspconfig폴더"으로 구성하고~ 'configtx.yaml' 을 잘 설정해서 하면 됩니다.
  • channel의 MSP를 (새 CRLs 발표 등) 재구성하려면, 관리자가 "config_update 오브젝트" 를 생성하면 됩니다.
  • 관리자가 application을 통해서, 재구성된 MSP를 channel에 공표하면 되는거 같습니다.
• Best Practices
  
  • 그럼 한번! 모범 시나리오 상에서, MSP-configuration을 구성하는 사례를 보도록 합니다.
  • 1) Mapping between organizations/corporations and MSPs
    • 각 organization 하나당 MSP 하니씩, '1:1 맵핑'이 바람직 합니다.
    • 아래와 같은 "1:N 및 N:1 맵핑"은 고민을 좀 해야 합니다.
    • - One organization employing various MSPs : ...
    • - Multiple organizations using a single MSP : ... 
  • 2) Organization has different divisions(OUs), to which it wants to grant access to different channels
    • 한 organization이 서로다른 OUs으로 분할되어, 서로다른 channel으로 접속하는 법은 아래와 같습니다.
    • - Define one MSP to accommodate membership for all organization’s members : ...
    • - Defining one MSP to represent each division : ...
  • 3) Separating clients from peers of the same organization
    
    • 같은 organization의 peer으로 부터, client를 분류하기.
    • 많은 경우에서, identity 자체적으로~ identity의 종류를 찾을 수 있어야 합니다.
    • (예를들어, 보증정책은 peer에서만 처리 되어야하고, orderer이면 안되는 판단을 하려면...)
    • ...
  • 4) Admin and CA certificates
    
    • MSP의 'admin 인증서' 설치는 'root of trust' 및 'intermediate CAs' 와 다르게 설치하는 것이 매주 중요합니다.
    • 이것은 membership 을 관리하는 일반적인 관행입니다. (신규 인증서 발급 및 기존 인증서 검증)
  • 5) Blacklisting an intermediate CA.
    
    • ...
  • 6) CAs and TLS CAs
    
    • "MSP Identity 인증서" 와 "MSP TLS 인증서는" 혼돈을 피하기 위해, 서로다른 폴더로 관리 합니다.
    • 참고로, 둘이 동일한 CAs를 재활용하는것이 불가능은 아니지만... 가급적 그러지마세요.

 

-끝-