[Hyperledger] Composer Access 제어 언어(ACL)

2018-07-23

2021-03-04

Hyperledger Composer Access Control Language

이번에는 ACL이다! 다음에는 스크립트 작성 방법 튜토리얼 번역해야지. 아무튼, 블로그 한답시고 공식 사이트 내용을 거의 복붙 수준으로 옮기고 있다. 난 초보니까! 공부하기 위해 블로그를 만든다는 이념(??)을 아주 잘 따르고 있어서 다행이다. ^^

개요와 맨 마지막의 Example, 그리고 마무리만 보셔도 큰 문제 없을 듯합니다. 백 번의 설명보다 한 줄의 코드가 나은 포스트네용…

Composer는 도메인 모델 엑세스 제어를 위한 ACL(Access Control Language)을 제공한다. ACL을 사용하면 user와 role의 permission 제어가 가능하다. ACL을 통해 비즈니스 도메인 모델의 CRUD(Create, Read, Update, Delete) 권한 설정을 할 수 있다.

Network Access Control

비즈니스 및 네트워크 엑세스 제어는 모두 .acl 파일에 정의된다. 특정 동작에 대한 엑세스를 허용하거나 거부하도록 만들 수 있다.

Network Access Control의 허용과 비허용

네트워크 엑세스 제어는 다음 CLI 명령에 영향을 준다.

Composer Network

composer network download

레지스트리와 네트워크를 READ 할 때 권한을 필요로 함
composer network list

레지스트리와 네트워크를 READ 할 때 권한을 필요로 함
composer network loglevel

네트워크를 UPDATE 할 때 권한을 필요로 함
composer network ping

레지스트리와 네트워크를 READ 할 때 권한을 필요로 함

Composer Identity

composer identity import

Identity 레지스트리에서 UPDATE를 시도하거나 CREATE를 시도할 때 네트워크 접근 권한을 필요로 함
composer identity issue

Identity 레지스트리에서 UPDATE를 시도하거나 CREATE를 시도할 때 네트워크 접근 권한을 필요로 함
composer identity revoke

Identity 레지스트리에서 UPDATE를 시도하거나 DELETE를 시도할 때 네트워크 접근 권한을 필요로 함

Composer Participant

composer participant add

참여자의 CREATE 또는 UPDATE 명령을 사용하기 위해 네트워크 접근 권한이 필요하다.

Network Access Control 부여하기

Network Access는 System Namespace로부터 부여된다. org.hyperledger.composer.system.Network 은 네트워크 제어, org.hyperledger.composer.system 는 모든 제어를 위한 System Namespace이다. 다음의 access control rule에 따라 NetworkControl 참가자에게 네트워크 명령과 함께 모든 작업을 사용할 수있는 권한을 부여한다.

rule NetworkControlPermission {
  description:  "NetworkControl can access network commands"
  participant: "org.example.basic.NetworkControl"
  operation: ALL
  resource: "org.hyperledger.composer.system.Network"
  action: ALLOW
}

다음의 Access Control은 모든 participant가 네트워크 및 비즈니스 엑세스를 포함하여 비즈니스 네트워크의 모든 작업과 명령에 접근할 수 있도록 한다.

rule AllAccess {
  description: "AllAccess - grant everything to everybody"
  participant: "org.hyperledger.composer.system.Participant"
  operation: ALL
  resource: "org.hyperledger.composer.system.**"
  action: ALLOW
}

비즈니스 네트워크에 대한 액세스 컨트롤은 ACL로 정의한다. rule은 순서대로 체크되고, 조건이 일치하는 첫 번째 rule은 액세스 여부를 결정한다. 일치하는 rule이 없으면 액세스가 거부된다.

ACL rule은 permissions.acl비즈니스 네트워크의 루트에서 호출되는 파일에 정의된다. 비즈니스 네트워크에 이 파일이 없다면 모든 액세스를 허용한다.

Access Control Rule Grammar

ACL rule에는 단순 ACL rule과 조건부 ACL rule 두 가지 유형이 있다. 간단한 rule은 참여자 또는 참여자 인스턴스에 의한 namespace, asset 접근을 제어하는 데 사용된다.

예를 들어, 아래의 코드는 모든 org.example.SampleParticipant유형의 인스턴스가 org.example.SampleAsset에 대한 모든 작업을 수행 할 수 있음을 의미한다.

rule SimpleRule {
    description: "Description of the ACL rule"
    participant: "org.example.SampleParticipant"
    operation: ALL
    resource: "org.example.SampleAsset"
    action: ALLOW
}

조건부 ACL rule은 변수 바인딩과 bool JavaScript 표현식을 제공한다. true로 설정할 경우 참여자의 접근을 허가하거나 반려할 수 있다.

예를 들어, 아래 코드는 participant가 저작물의 소유자인 경우 org.example.SampleParticipant유형의 인스턴스는 모든 org.example.SampleAsset 인스턴스에서 어떠한 작업이라도 할 수 있다는 것을 의미한다.

rule SampleConditionalRule {
    description: "Description of the ACL rule"
    participant(m): "org.example.SampleParticipant"
    operation: ALL
    resource(v): "org.example.SampleAsset"
    condition: (v.owner.getIdentifier() == m.getIdentifier())
    action: ALLOW
}

조건부 ACL rule은 선택적으로 트랜잭션을 지정할 수도 있다. 트랜잭션이 지정된 경우, 참여자가 던진 트랜잭션이 특정 유형일 때에만 자원에 접근할 수 있게 한다.

예를 들어, 아래의 코드는 org.example.SampleParticipant 참여자가 asset의 소유자이고 참여자가 트랜잭션을 제출 한 경우, 모든 org.example.SampleAsset 인스턴스에서 모든 org.example.SampleTransaction 트랜잭션을 수행 할 수 있음을 의미한다.

rule SampleConditionalRuleWithTransaction {
    description: "Description of the ACL rule"
    participant(m): "org.example.SampleParticipant"
    operation: READ, CREATE, UPDATE
    resource(v): "org.example.SampleAsset"
    transaction(tx): "org.example.SampleTransaction"
    condition: (v.owner.getIdentifier() == m.getIdentifier())
    action: ALLOW
}

여러 ACL rule을 의사 결정 테이블에 정의 할 수 있다. 의사 결정 트리에는 액세스 제어(허용 또는 거부). 의사 결정 테이블이 일치하지 않으면 액세스가 거부된다.

리소스는 ACL rule이 적용되는 사항을 정의한다. 이것은 클래스, 네임 스페이스 내의 모든 클래스 또는 네임 스페이스 아래의 모든 클래스일 수 있다. 또한 클래스의 인스턴스가 될 수도 있다.

리소스 예제

네임 스페이스 : org.example. *
네임 스페이스 (재귀 적) : org.example. **
네임 스페이스의 클래스 : org.example.Car
클래스의 인스턴스 : org.example.Car # ABC123

Operation 은 작업을 확인한다. CREATE, READ, UPDATE, DELETE 네 가지를 지원한다. ALL을 사용하여 모든 모든 기능을 제어할 수 있도록 지정할 수 있다. 또는 쉼표로 구분 된 목록을 사용하여 지원 세트를 관리하도록 지정할 수 있다.

Participant 는 트랜잭션을 보낸 개인 또는 entity를 정의한다. 지정된 참여자는 반드시 참여자 레지스트리에 존재해야 한다. 참가자는 선택적으로 PREDICATE에서 사용할 변수에 바인딩 될 수 있다. 'ANY’는 Participant 검사가 rule에 적용되지 않음을 나타낼 때 사용한다.

Transaction 은 지정된 자원을 조작하기 위해 Participant의 Transaction을 정의한다. 이것이 지정되었으나 참여자가 이 유형의 트랜잭션을 제출하지 않은 경우에는 (예 : CRUD API를 사용하는 경우) ACL rule에 따라 접근이 거부된다.

Condition 은 바운드 변수에 대한 Bool JavaScript 식이다. 표현식 내에서 유효한 모든 JavaScript 표현식을 if(...) 로 사용할 수 있다. ACL rule의 조건에 사용되는 JavaScript 표현식은 스크립트 파일의 JavaScript 유틸리티 함수를 참조 할 수 있다. 이를 통해 사용자는 복잡한 액세스 제어를 쉽게 구현하고 여러 ACL rule에서 동일한 액세스 제어 논리 기능을 재사용할 수 있다.

Action 은 rule의 동작을 식별한다. ALLOW, DENY 중 하나여야 한다.

예시

다음은 ACL rule의 예시이다.

rule R1 {
    description: "Fred can DELETE the car ABC123"
    participant: "org.example.Driver#Fred"
    operation: DELETE
    resource: "org.example.Car#ABC123"
    action: ALLOW
}

rule R2 {
    description: "regulator with ID Bill can not update a Car if they own it"
    participant(r): "org.example.Regulator#Bill"
    operation: UPDATE
    resource(c): "org.example.Car"
    condition: (c.owner == r)
    action: DENY
}

rule R3 {
    description: "regulators can perform all operations on Cars"
    participant: "org.example.Regulator"
    operation: ALL
    resource: "org.example.Car"
    action: ALLOW
}

rule R4 {
    description: "Everyone can read all resources in the org.example namespace"
    participant: "ANY"
    operation: READ
    resource: "org.example.*"
    action: ALLOW
}

rule R5 {
    description: "Everyone can read all resources under the org.example namespace"
    participant: "ANY"
    operation: READ
    resource: "org.example.**"
    action: ALLOW
}

Rule은 맨 위에서 (가장 구체적)부터 맨 아래 (가장 덜 구체적인)까지 적용된다. Participant, Operation, Resource는 rule이 일치하는 즉시 이후의 rule 무시된다.

이 순서는 의사 결정 테이블을 사람과 컴퓨터 모두에 대해 더 빠르게 적용시킨다. ACL rule이 실행되지 않으면 Access Control이 거부된다.

마무리하며

하기 싫음에 몸부림치던 포스팅이었다. 대체 이게 무슨 말인지 이해가 안 돼! 단순히 생각하면, 접근 유형에 규칙을 부여할 수 있다는 말인 듯하다. participant, operation, resource, action 등에 규칙(rule)을 설정하고, 이 rule에 부합하는 경우에만 control 권한을 주는 방법?

이 rule은 가장 상위 rule부터 마지막 rule까지 평가되는데, 상위 rule에 부합할 경우 아래의 rule은 굳이 따지지 않고 넘어간다. 이 부분은 switch문이나 if문을 생각하면 될 듯하다. 그래서!!! 맨 위의 규칙은 major한 규칙(아무나 가지면 안 되는 규칙)이어야 하고, 아래로 갈수록 그 중요도가 낮아져야 한다. 예를 들어, 1번은 admin, 2번은 manager, 3번은 user의 권한이 될 수 있겠지?

쓰면서라도 머리에 때려박아 다행이다. 아니었으면 스루하고 넘겼을 것임. -_- 장하다!

ITBlockchain