6) Membership

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

• (What's) Membership
  • 자~ 그럼, 'digital identity'가 blockchain-network 상의 member판단에 어떻게 이용되는지? 알아볼까용.
  • 앞서 MSP(membership service provider)는 ('digital identity'를 확인하는)신뢰 할 수 있는 authority라 설명 했습니다.
  • 그리고 blockchain-network에 참여하는 member나 organization는 Root CA(Intermediate CA)의해 발급된 'X.509 인증서' 기반으로 'digital identity'를 갖춘다고도 잘~ 알실것이십니다.
  • 이런 상황에서 MSP는 참여하는 member나 organization의 리스트를 관리하고, 세부적으로 각각에 다양한 권한관리도 한다고 보시면 됩니다. (특정member의 특정 admin권한, read권한, write권한 등등)
  • MSP 설정은 blockchain-network의 모든 channel에 적용 할 수 있는데, 이것을 "channel MSP" 라고 합니다.
  • 또한 "local MSP" 도 있는데, 'peer' 'orderer' 'client application' 등의 node에 권한을 정할 수 있습니다. (예를들어... 특정 peer에서 특정 외부message 허용이나 chaincode 인스톨 권한 등등)
  • 끝으로... MSP로 특정 'digital identity'를 차단 할 수 도 있습니다.
• Mapping MSPs to Organizations
  
  • organization가 특정 member들의 그룹이라는 개념! 당연히 아시죠?
  • 당연히 blockchain-network에 참여하는 organization는 아주 큰 글로벌기업 일 수 도 있겠고... 그냥 작은 동네꽃집가게  일 수 도 있는거죠.ㅎ
  • 중요한건, organization의 특정 member그룹은 각 '단일 MSP'으로 관리된다는 것 입니다. (이것은 'X.509 인증서' 스펙에서 말하는 organization개념과 약간 다르다고 볼 수 있습니다! 기억해두세용!)
  • 특정 organization 과 해당 MSP는 배타적(?)인 관계이니... organization 을 정한뒤에, MSP를 정하는것이 바람식 하다고 합니다. 대충 무슨말인지 느낌 오시죠?ㅎ
  • (예를들러, 'ORG1'이라고 하면~ MSP는 'ORG1-MSP' 으로 하면 쉽습니다.)
  • (만약 organization의 특정 member들을 복수개의 그룹으로 나누고 싶을때는~ 각각의 MSP를 만드세요)
  • (예 : 'ORG2-MSP-DEV', 'ORG2-MSP-BIZ', 'ORG2-MSP-UX' )

  • 

  • 이런식으로 한 organization의 member그룹들을 각각에 MSP으로 관리 할 수 있다는것 입니다.
•  Organizational Units and MSPs
  • 한 organization는 당연히 복수개의 OU(organizational unit)으로 나뉠 수 있습니다. 예를들면, 'ORG1'은 'ORG1-제조부' 와 'ORG1-유통부' 이렇게 될 수 있는거죠.
  • 이런상황 에서는 'X.509 인증서' 발급시 'OU필드'에 명시를 해주는것이 좋습니다.
  • 이렇게 하면 차후에 'OU필드' 기반으로 각 부서별 권한관리에도 매우 유용하겠죠? (가끔은 서로다른 organization을 구별하는 식으로도 쓰곤 한답니다.)
• Local and Channel MSPs
  
  • 앞서 이야기 했지만, MSP는 'channel MSP' 와 'local MSP' 가 있습니다. 'channel MSP'는 blockchain-network의channel에 설정하는 것이고, 'local MSP' 한 node에 온프리머스에 설정하는 것 입니다.
  • 'local MSP'은 'peer' 'orderer' 'client application' 등의 역활을 하는node에... 뭐 'chaincode 트렌젝션' 허용이라던지? organization admin 라던지? 등을 권한을 정하는 것 입니다.
  • 그래서 모든 node에는 일단 'local MSP' 으로, 어떤 node에 어드민 및 참여권한이 있는지? 정해놓습니다.
  • 그 이후, 'channel MSP'으로 특정 channel 에 어드민 및 참여권한을 부여 하는것 입니다.
  • channel에 참여하는 모든 organization를 반듯이 MSP를 가져야 하고~ channel에 있는 'peer' 와 'orderer' 는 모두 똑같은 'channel MSP'에 영향을 받음으로, 일괄적인 'channel 참여인증'을 할 수 있게 되는것 입니다.
  • 즉, 어떤 organization이 특정 channel에 참여하려면~ channel 설정된 'chain of trust'에 맞는 MSP이어야 하다는것 입니다. (타 organization’s identities는 당연 channel에서 거부 당하겠죠)
  • 'channel MSP' 와 'local MSP' 의 차이점은 ('digital identity' 를 역활으로 바꾸는기능이 아니라~) 각각의 적용범위 이라는것! 입니다.

  • 

    각 peer의 organization을 'local MSP'에 정의함. organization MSP는 'channel MSP'에 추가함.

  • 위 그림을 참고해서, blockchain-network의 administrator 가 'chaincode 인스톨 및 인스턴티' 할때, 'channel MSP' 와 'local MSP' 이 어떻게 쓰이는지? 이해하면 됩니다.
    • 1) peer-node는 RCA1에서 발행되고 'local MSP'으로 저장된 'digital identity'를 갖추고 있습니다.
    • 2) administrator인 B씨가 해당 identity으로 peer-node에 접속을 합니다.
    • 3) B씨는 'chaincode 인스톨'을 시도 합니다.
    • 4) peer-node는 자신의 'local MSP'인 'ORG1-MSP'를 검증합니다. (B씨가 ORG1 소속 맞는지?)
    • 5) 검증이 성공하면, 'chaincode 인스톨' 허용 합니다.
    • 6) 이후  B씨는 해당 channel에 'chaincode 인스턴티'도 요구 합니다.
    • 7) (인스턴티는 'channel 오퍼레이션' 이기 때문에) 해당 channel의 모든 organization이 동의 해줘야 합니다. 그래서 peer-node는 'channel MSP'를 확인 합니다.
    • 8) 참고로, 'local MSP'는 해당 node의 로컬 파일시스템에만 적용되면 됩니다. 그래서 물리적으로나 논리적으로나 하나의 node에만 정의하면 되는것 입니다.
    • 9) 반면, 'channel MSP'는 해당 channel의 모든 node에 적용이 되야만 합니다. 그래서 'channel MSP'는 모든 node의 로컬 파일시스템에 '인스턴티' 되어야 하고, 또 (consensus를 통해서~) 동기화 되야 합니다. 이 결과 'channel MSP'는 각각의 노드에 해당 사본이 있고, 그래서 'channel MSP' network상에서 관리가 되는것 입니다.
• MSP Levels
  
  • 'channel MSP' 과 'local MSP' 을 분리 시킴으로써, 여러가지 organization에 필요한 사항(예를들면, node같은 local리소스 혹은 ledger 및 chaincode같은 channel리소스 를 관리) 충족에 효과적 입니다.
  • 각각의 MSP마다 level등급을 나누어서, high-level에서는 blockchain-network의 전반적인 관리를 하고~ low-level에서는 private한 리소스 관리를 하는 식입니다.
  • 이제, blockchain-network, channel, peer, orderer, and user(client-application)에 모두 MSP가 필수적 이라는것! 아시겠죠?

  • 

  • 위 그림은 peer, orderer 엔 각각 'local MSP'가 있고, 'channel MSP'는 모든 참여자에게 공유 되고 있습니다. blockchain-network 는 ORG1으로 관리되고, channel은 ORG1 및 ORG2으로 관리 됩니다. peer는 ORG2의 member이고, orderer 는 ORG1의 member 입니다. ORG1은 RCA1으로부터 발급되었고, ORG2은 RCA2으로부터 발급되었습니다.
    • Network MSP : blockchain-network의 주체를 정의함. 해당 member가 ('channel 생성' 같은) admin작업을 할수있음.
    • Channel MSP : 각 member그룹의 MSP으로 channel를 유지하는것이 중요합니다. channel은 서로다른 organization간에 private한 통신을 제공합니다. 'channel MSP'으로 해당 channel의 정책이 정해지며, 이에따라 'organization 추가', 'chaincode 인스턴티' 같은 권한을 누가 할지? 정해집니다. (참고로, channel을 관리하는 권한과 blockchain-network에 channel구성하는 권한은 서로 관련 없삼) 관리권한의 scope는 관리대상 scope내로 하게 됩니다.
    • Peer MSP : 'local MSP'은 각 peer의 파일시스템에 정의되고, '단일 MSP'으로 구성됩니다. 기능적으로는 'channel MSP'와 동일 하지만, 오직 하나의 peer에만 적용이 되는 것 입니다. 적용하는 권한의 예로는 특정 peer에 'chaincode 인스톨' 등이 있습니다.
    • Orderer MSP : 마찬가지로 'local MSP' 입니다. 마찬가지로 orderer도 단일 organization의 소속이니, 당연 '단일 MSP'으로 구성됩니다.
• MSP Structure
  
  • 자 그럼~ MSP 구성에서 가장 중요한 (membership을 부여하는) Root CA 및 Intermediate CA 스펙을 파악 해보도록 해요! (물론 두 요소 이외의 요소도 함께 보아요!)

  • 

    로컬파일시스템에 'local MSP'이 이렇게 저장 되있음. ('channel  MSP'는 물리적으로 똑같지는 않지만, 비슷한 식임)

  • 보시는것 처럼, 디렉토리 구조로~ 'MSP 이름'이 루트이고 나머지 9개가 하위폴더인 구조임.
    • Root CA : 자가서명된 'Root CA 인증서' 리스트를 가지고있는 폴더. (당연, 해당 organization는 해당 RCA를 신뢰함) 최소 하나의 'Root CA 인증서'는 있어야 함. 왜냐면, 이것에 의해 파생되는 다른인정서가 특정 organization의 member로 간주되는 CA식별에 사용되기 때문입니다.
    • Intermediate CA : 마찬가지로 'Intermediate CA 인증서' 리스트를 가지고있는 폴더. (당연, 해당 organization는 해당 ICA를 신뢰함) 'chain of trust'에 의해 궁극적으로는 Root CA에 연결되어 있어야 함. Intermediate CA 는 organization의 세분화로 표현 되는것 입니다. (예 : 'ORG1'을 'ORG1-제조부' 와 'ORG1-유통부'로 나눔) organization를 분류하고 싶을때 적절히 활용하면 되는거 아시겠죠? 물론 이럴필요 없으면, 안써도 됩니다. 빈폴더로 놔두어도 된다는 말이죠. 이것 역시 organization의 member로 간주되는 CA식별에 사용 됩니다.
    • Organizational Unit (OU) : "$FABRIC_CFG_PATH/msp/config.yaml" 에 작성됩니다. 내용은 member그룹을 의미하는 'organization unit' 리스트 입니다. organization의 특정 member그룹에 권한제한을 할때, OU으로 판단하시면 됩니다. 물론, OU 작성은 옵셔널입니다. 없으면 그냥 똑같은 organization의 member로 간주 되겠죠.
    • Administrator : organization의 administrator역할을 할 'digital identity' 리스트를 정의 합니다. 표준적으로는 하나 이상의 'X.509 인증서' 로 구성 됩니다. administrator역할을 한다고 해서... 모든것을 총괄한다는 의미는 아닙니다. 실질적인 권한은 상위정책에 영향 받습니다. 예를들면, 'channel 정책'으로 'ORG1-제조부' administrator가 해당 channel에 'organization 추가'를 할 수 있게하고, 'ORG1-유통부' administrator는 못하게 하도록 할 수 있다는 것 입니다. 물론 'X.509 인증서'에는 ROLE속성이 있는데, 이건 organization 내에서의 역할을 말하는것이고~ blockchain-network에서 역할을 말하는것은 아닙니다. ROLE속성은 'chaincode 인스턴티' 같은 'channel 작업' 권한을 특정 administrator에 부여하는데 사용하면 좋습니다. organization내 역활을 blockchain-network에서의 역활으로 부여 할 수 있습니다.
    • Revoked Certificates : (자세한 설명은 생략한다~)
    • Node Identity (for Sign Certificate) : 이 폴더는 node의 'digital identity'를 의미합니다. 이건 (KeyStore와 함께) blockchain-network 및 channel 상의 다른 node와의 통신인증에 사용됩니다. 당연히 이폴더에는 'X.509 인증서'가 하나가 있겠죠... peer의 'transaction proposal 응답'에 사용이 되는데~ 예를들어 peer가 보증을 했음을 나타내기 위해, 검증시 'transaction 보증정책' 확인에 사용됩니다. 이 폴더는 'local MSP'에 필수적이고 node당 딱 하나가 있고~ 'channel MSP'에는 필요 없습니다.
    • KeyStore (for Private Key) : 'local MSP'에 있는 폴더 이고, 해당 node의 'signing key' 값 입니다. 암호학적으로 'Node Identity 폴더'의 Key로써 사용이 됩니다. 예를들어 보증절차의 'transaction proposal 응답' 단계에서 서명으로 사용 됩니다. 마찬가지로 이 폴더도 'local MSP'에 필수적이고 node당 오직 하나가 있어야 합니다. 말그대로 핵심키 이니, administrator 만이 이 폴더에 접근 가능하도록 제한 해야겠죠? 물론 역시나 'channel MSP'에는 필요 없습니다. 'channel MSP' 에서는 'digital identity' 검증만 잘하면 되지~ 'digital identity' 서명을 할일은 없기 때문이지요.
    • TLS Root CA : 자가서명된 'Root CA 인증서' 리스트를 가지고있는 폴더. (TLS통신 용도로, 해당 organization는 해당 RCA를 신뢰함) HTTPS같은 보안통신에 사용되는 그런 용도. peer 와 orderer 등의 내부통신에 사용된다.
    • TLS Intermediate CA : (자세한 설명은 생략한다~)
• 이제 blockchain-network에서 'digital identity' 용도로 PKI 와 MSP 가 어떻게 쓰이는지? 잘~ 아시겠죠? 지금까지 'X.509 인증서', '공개키 비밀키', 'chain of trust', 'MSP의 물리적 논리적 구조' 를 잘 설명해 드린거? ㅇㅈ? ㅇㅇㅈ!

 

-끝-