[Hyperledger Fabric v1.2] 4. Operations Guides: Access Control Lists (ACL)

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

원본 사이트 : https://hyperledger-fabric.readthedocs.io/en/release-1.2/access_control.html

What is an Access Control List?

Fabric은 접근 권한 리스트(ACL)을 정책과 연관함으로서 리소스에 접근을 관리하도록 사용합니다. 이 정책은 true나 false 값의 룰을 주어진 ID의 집합에 명시합니다.

Fabric은 다양한 디폴트 ACL을 포함하고 있습니다.

이 문서에선, ACL이 어떤 포맷으로 존재하고, 그들의 디폴트 값이 어떻게 덮어쓰기 될 수 있는지 알아볼 것입니다.

그러나 이에 대해서 설명하기 이전에, 리소스와 정책에 대해서 이해할 필요가 있습니다.

Resources

사용자는 사용자 체인코드, 시스템 체인코드, event stream source를 타게팅함으로서 Fabric과 상호작용합니다.

이와 같이 이러한 엔드포인트는 리소스로 간주되고, 접근 권한은 리소스에서 행사됩니다.

어플리케이션 개발자는 그들과 관련된 리소스들과 디폴트 정책을 알아둘 필요가 있습니다.

리소스의 전체 리스트는 configtx.yaml에서 확인할 수 있습니다.

여기를 클릭하시면 샘플 configtx.yaml을 확인하실 수 있습니다.

Policies

정책은 Fabric이 작동하기 위해서 아주 기본적인 것입니다. 왜냐하면 정책이 요청과 관련된 ID(또는 ID 집합)이 요청을 수행하는데 필요한 리소스와 관련된 정책과 비교하여 검사되도록 허용하기 때문입니다.

승인 정책은 트랜잭션이 적절하게 승인 되었는지 여부를 결정하는데 사용됩니다. 채널 구성에 정의된 정책은 접근 제어 뿐이 아니라 수정 정책으로 참조되며 채널 구성 자체에 정의됩니다.

정책은 Signature 정책이나 ImplicitMeta 정책 두 가지 방법 중 하나로 구성됩니다.

Signature Policies

이 정책은 정책을 충족시키기 위해 로그인을 해야하는 사용자를 식별합니다.

Policies:
  MyPolicy:
    Type: Signature
    Rule: “Org1.Peer OR Org2.Peer”

이 정책 구성은 다음과 같이 해석할 수 있습니다. Mypolicy라는 정책은 오직 Org1.Peer 또는 Org2.Peer의 ID 서명만으로 충족될 수 있습니다.

서명 정책은 And, Or, NOutOf 중 임의적인 조합을 지원하고, "OrgA와 두명의 다른 관리자 또는 20명의 조직 관리자 중 11명"과 같이 매우 강력한 규칙을 구성 할 수 있습니다.

ImplicitMeta Policies

ImplicitMeta 정책은 최종적으로 Signature 정책에 의해 정의되는 구성 계층에서 더 깊은 정책 결과를 집계합니다. 그들은 "대다수의 조직 관리자"와 같은 기본 규칙을 지원합니다.

이러한 정책들은 Signature 정책에 비해서 다르지만 동시에 단순한 문법을 다음과 같은 예시처럼 사용합니다. "<ALL|ANY|MAJORITY> <sub_policy>"

예를 들자면, Any Readers 나 MAJORITY Admins와 같은 것들이 있습니다.

기본 정책 구성인 Admins에는 운영 역할이 주어짐을 유의하십시오.

Admins 또는 일부 Admins의 하위 사용자만 리소스에 접근 할 수 있도록 지정하는 정책은 네트워크의 민감하거나 운영(채널 체인코드 인스턴스 생성과 같은) 측면에서 유용합니다.

Writers는 원장의 업데이트를 제안할 수 있지만 일반적으로 관리 권한은 가지고 있지 않습니다. Readers는 수동적인 역할을 가지게 됩니다.

Readers는 정보에 접근할 수 있지만 원장 업데이트나 관리 업무같은 것에 대한 허가는 가지고 있지 않습니다.

이러한 기본 정책은 추가, 수정, 보충되지 않습니다. 예를 들어 신규 peer 및 client 역할(NodeOU의 지원이 있는 경우)이 이와 같습니다.

다음은 Implicitmeta 정책 구조의 예시입니다.

Policies:
  AnotherPolicy:
    Type: ImplicitMeta
    Rule: "MAJORITY Admins"

여기서 AnotherPolicy 정책은 Admins가 궁극적으로 더 낮은 레벨로 특정되는 Admins의 MAJORITY에서 충족될 수 있습니다.

Where is access control specified?

접근 권한의 기본 설정은 configtx.yaml에 존재합니다. 이 파일은 configtxget이 채널 설정을 만들기 위해서 사용합니다.

접근 권한은 configtx.yaml을 수정함으로서 ACL의 변화를 각 다른 채널에 전파하거나 특정 채널의 설정 중 접근 권한을 업데이트 하는 두 가지 방법 중 하나를 활용해서 업데이트 할 수 있습니다.

How ACLs are formatted in configtx.yaml

ACLs는 key-value 쌍으로 리소스의 함수명에 따르는 String으로 구성되어 있습니다.

실제로 어떻게 구성이 되있는지 보고 싶다면, sample configtx.yaml 파일을 참고하세요.

샘플에서 두가지를 발췌해온 것을 확인해보세요.

# ACL policy for invoking chaincodes on peer
peer/Propose: /Channel/Application/Writers

# ACL policy for sending block events
event/Block: /Channel/Application/Readers

이러한 ACLs는 peers/Propose와 event/Block의 리소스가 절대 경로 /Channel/Application/Writers와 /Channel/Application/Readers에 각각 정의되어 있는 정책을 만족시키는 Id에게만 제한되어 있습니다.

Updating ACL defaults in configtx.yaml

네트워크를 부트스트랩 할 때 ACLs의 기본 설정을 무시하거나 채널이 부스스트랩 하기 전에 ACLs를 변경하는 것이 필요한 경우에 configtx.yaml을 업데이트하는 것이 좋습니다.

peer/purpose의 ACL 기본 설정(피어에 체인코드 인보크에 대한 정책 지정)을 /Channel/Application/Writers에서 Mypolicy라는 정책으로 수정하고 싶다고 가정해봅시다.

이것은 Mypolicy(이름과 무관, 예시를 위해 Mypolicy 사용)를 정책으로 올림으로서 해결될 수 있습니다.

정책은 configtx.yaml안에 Application.Policies 섹션에 정의되어 있고, 사용자의 접근이 승인 여부를 확인하기 위한 규칙을 명시합니다.

아래의 예시에선, SampleOrg.admin을 식별하는 Signature 정책을 생성하는 것을 확인하실 수 있습니다.

Policies: &ApplicationDefaultPolicies
    Readers:
        Type: ImplicitMeta
        Rule: "ANY Readers"
    Writers:
        Type: ImplicitMeta
        Rule: "ANY Writers"
    Admins:
        Type: ImplicitMeta
        Rule: "MAJORITY Admins"
    MyPolicy:
        Type: Signature
        Rule: "OR('SampleOrg.admin')"

그리고나서, configtx.yaml의 Application: ACLs 섹션을 peer/Purpose를 변경하기 위해서 수정합니다.

peer/Purpose: /Channel/Application/Writers에서

peer/Purpose: /Channel/Application/Mypolicy로 변경합니다.

한 번 이 필드가 configtx.yaml에서 변경되면, configtxget 툴이 정책을 사용할 것이고 ACLs는 채널 생성 트랜잭션이 실행되면 정의될 것입니다.

적절하게 서명된 상태로 컨소시엄 멤버 관리자 중 한명에 의해서 제출되면, ACLs와 정책이 새로 포함된 새로운 채널이 생성됩니다.

한번 Mypolicy가 채널 설정에 부트스트랩되면, 기본 ACLs 설정을 무시하도록 참조될 수 있습니다.

SampleSingleMSPChannel:
    Consortium: SampleConsortium
    Application:
        <<: *ApplicationDefaults
        ACLs:
            <<: *ACLsDefault
            event/Block: /Channel/Application/MyPolicy

이것이 SampleOrg.admin로 하여금 이벤트를 차단하도록 신청하는 기능을 제한합니다.

만약 채널이 이미 만들어졌고 이 ACL을 사용하고 싶다면, 각 채널의 설정을 다음 장에서의 설명을 따라서 한번에 변경할 수 있습니다.

Updating ACL defaults in the channel config

만약 이미 채널이 생성되었고, peer/Purpose로의 접근을 제한 하거나 또는 ACLs를 만들고 다른 채널에 그것을 알리고 싶지 않은 경우를 위해서 Mypolicy를 사용하고 싶다면,

채널 설정을 설정 업데이트 트랜잭션으로 한번에 업데이트 할 수 있습니다.

주의: 채널 설정 트랜잭션은 포함된 프로세스이고 더 이상 설명하지 않습니다. 만약 더 자세한 정보를 알고 싶다면 channel configuration updates나 "Adding an Org to a Channel" 튜토리얼을 학습하세요.

메타데이터의 설정 블록을 가져오고, 번역하고, 분해한 이후에, MyPolicy를 이미 존재하고 있는 Admins, Writers, Readers 정책에 Application: policies에 추가함으로서 설정을 수정할 것입니다.

"MyPolicy": {
  "mod_policy": "Admins",
  "policy": {
    "type": 1,
    "value": {
      "identities": [
        {
          "principal": {
            "msp_identifier": "SampleOrg",
            "role": "ADMIN"
          },
          "principal_classification": "ROLE"
        }
      ],
      "rule": {
        "n_out_of": {
          "n": 1,
          "rules": [
            {
              "signed_by": 0
            }
          ]
        }
      },
      "version": 0
    }
  },
  "version": "0"
},

여기서 msp_identifier과 role을 확인하세요.

그리고나서 config의 ACLs 섹션안에 peer/Purpose를 다음과 같이 수정하십시오.

"peer/Propose": {
  "policy_ref": "/Channel/Application/Writers"

에서

"peer/Propose": {
  "policy_ref": "/Channel/Application/MyPolicy"

으로 변경합니다.

주의: 채널 구성에 ACL이 정의되어 있지 않으면 전체 ACL 구조를 추가해야합니다.

구성이 업데이트되면 일반적인 채널 업데이트 프로세스를 통해 제출해야합니다.

Satisfying an ACL that requires access to multiple resources

멤버가 다중 시스템 체인코드를 호출하는 요청을 만들면, 시스템 체인코드의 모든 ACLs가 충족되어야만합니다.

예를 들어, peer/Propose는 채널에 제안 요청을 나타냅니다.

특정한 제안에서의 시스템 체인코드가 Writers를 충족시키는 Id를 요구하고 또 다른 시스템 체인코드가 MyPolicy를 충족하기 위한 Id를 요구할 경우,

제안을 보낸 멤버가 Writers와 MyPolicy 둘 다 "true"인 Id를 가지고 있어야합니다.

기본설정에서, Writers는 rule이 SampleOrg.member인 서명 정책입니다.

다시 말해서, "내 org의 어느 멤버"라는 말입니다.

MyPolicy는 위에서 언급된 것처럼, SamplOrg.admin이고 이는 "내 org의 어느 관리자"입니다.

이 ACLs를 충족하기 위해선, 멤버가 SampleOrg에서 관리자임과 멤버라는 역할을 동시에 수행하고 있어야합니다.

기본적으로, 모든 관리자는 멤버입니다.(종종 해당되지 않을 경우도 있지만), 그러나 이 요건을 수정자가 정책을 충족하는 역할을 새로 지정하여 덮어쓸 수 있습니다.

결과적으로, 피어의 제안에 대한 ACL이 만족스럽지 않은지 확인하기 위한 이러한 정책을 추적하는 것이 중요합니다(의도가 없는한).

Migration considerationfor customers using the experimental ACL feature

이전에는 접근 제어 리스트(ACL)의 관리가 채널 생성 트랜잭션의 isolated_data 섹션에서 이루어졌고, PEER_RESOURCE_UPDATE 트랜잭션을 통해서 수행되었습니다.

원래, resources 트리는 궁극적으로 다른 방식으로 처리되는 몇가지 함수의 업데이트를 처리할 것이므로 별도의 병렬 피어 구성 트리를 유지 관리하는 것은 불필요하다고 판단되었습니다.

1.1 버전의 실험 리소스 트리를 사용하는 고객을 위한 마이그레이션 기능을 제공합니다. 공식 1.2 릴리즈 버전에서는 이전 ACL 방식을 지원하지 않으므로 네트워크 운영자는 모든 네트워크를 종료해야합니다.

이후 1.2 버전으로 업그레이드 하고, 1.2 기능을 활성화하길 원하는 ACL을 설정한 다음 다시 업그레이드 된 피어를 다시 시작하는 채널 재구성 트랜잭션을 제출해야합니다.

다시 시작된 피어는 즉시 새 채널을 구성하고 설정된 대로 ACL을 실행합니다.