Access Control Lists (ACL)

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

• What is an Access Control List?
  
  • Hyperledger Fabric은 ACL을 기반으로 'policy' 에 따른 'resource' 접근관리를 합니다.
  • 기본적으로 몇가지 디폴트 ACL이 있고, 그 형식과 재지정에 관해 알아봅시다.
  • Resources
    
    • Hyperledger Fabric은 "chaincode 및 system-chaincode 및 events-streamsource" 으로 상호작용 합니다. 
    • 바로 이런 포인트가 'resource' 이고, ACL 가 이루어져야할 부분입니다.
    • application 개발자는 어떤 'resource' 가 제공되는지 알아야 할것이고, 그에 따른 'policy' 도 알아야 합니다.
    • 바로 그 "configtx.yaml" 에  'resource' 가 명시 됩니다. ( 예: {component명}/{resource명} = ... )
  • Policies
    
    • 'policy'는 요청된 'resource' 와 관련해서 identity 를 확인하는 아주 근본적인 방식입니다.
    • 마치 '보증정책'이 transaction의 보증을 판단하는것 처럼요.
    • channel configuration 에 정의된 'policy'가 자신을 수정하는 정책에도 사용됨을 참고 하세요.
    • 두가지 방법으로 구조화 할수 있는데, "Signature policies" 와 "ImplicitMetapolicy" 입니다.
    • Signature policies
      
      • 반듯이 필요한 서명을 명시하는 정의
      • 예) Policies: // Org1 혹인 Org2 의 peer 서명이 있어야 만족. (AND, OR, NOutOf)
        • MyPolicy:
          • Type: Signature
          • Rule: "Org1.Peer OR Org2.Peer"
    • ImplicitMeta policies
      
      • 궁극적으로 "Signature policies" 에서 더 세밀하고 깊이있는 정의가 가능합니다.
      • 문법적으로 <ALL|ANY|MAJORITY> <sub_policy> 등 사용해서, 좀 까다롭게 정의 합니다.
      • Admins : 전반적인 네트워크의 주요 운영적 역할.
      • Writers : 원장 업데이트 역할.
      • Readers : 원장 조회 역할.
      • (위 디폴트 이외에도, Peer 나 Client 역할을 추가할수도있습니다.)
• Where is access control specified?
  
  • 앞서 이야기한것 처럼, "configtxgen" 으로 생성한 "configtx.yaml" 에 ACL이 정의 됩니다. 
  • ACL을 수정하는 방법은, "직접 .yaml를 고쳐서 새로운 channel으로 전파" 하거나 "channel-configuration의 ACL을 업데이트" 하면 됩니다.
• How ACLs are formatted in configtx.yaml
  
  • ACL은 'resource 함수명' 으로 구성된 key-value 쌍입니다.
  • 예) peer/Propose: /Channel/Application/Writers // peer에서 chaincode를 인보크하는 정책
  • 예) event/Block: /Channel/Application/Readers // block 이벤트를 보내는 정책.
• Updating ACL defaults in configtx.yaml
  
  • ...
• Updating ACL defaults in the channel config
  
  • ...
• ...
• ...

-끝-