Access Control Lists (ACL)

What is an Access Control List?

注釈: このトピックでは、チャネル管理レベルのアクセス制御とポリシーを説明します。 チェーンコードのアクセス制御を学ぶ場合、chaincode for developers tutorialを参照してください。

Fabricは、Policyをリソースに関連付けることで、アクセス制御リスト(ACL)を使用したリソースのアクセス管理を行います。 Fabricには、デフォルトのアクセス制御リストがたくさんあります。 このドキュメントでは、アクセス制御リストのフォーマット、および、デフォルトを上書きする方法を説明します。

しかし、その前に、リソースとポリシーについて少し理解する必要があります。

Resources

ユーザとFabricのやり取りは、ユーザーチェーンコードイベントソース、または、バックグラウンドで呼び出されるシステムチェーンコードで発生します。 そのため、これらのエンドポイントは、アクセス制御を実行する必要がある"リソース"と見なされます。

アプリケーション開発者は、これらのリソースとそれらに関連付けられたデフォルトポリシーを認識する必要があります。 これらのリソースの完全なリストは configtx.yaml にあります。 configtx.yaml のサンプルファイルはこちらを参照してください。

configtx.yamlで指定されたリソースは、Fabricによって現在定義されているすべての内部リソースの完全なリストです。 ここで採用されている緩い規約は <component>/<resource> です。 したがって、 cscc/GetConfigBlock は、 CSCC コンポーネント内のGetConfigBlock 呼出しのリソースです。

Policies

ポリシーはFabricの動作において重要です。 リクエストに関連づけられたアイデンティティ(またはアイデンティティのセット)は、リクエストを処理するために必要なリソースに関連づけられたポリシーと照合されます。 エンドースメントポリシーは、トランザクションが適切にエンドースされているかどうかを判断するために使用されます。 チャネル設定で定義されたポリシーは、アクセス制御だけでなく変更ポリシーとしても参照され、チャネル設定自体で定義されます。

ポリシーは、Signature ポリシーと ImplicitMeta ポリシーのうち、いずれかの方法で記述されます。

Signature policies

このポリシーは、どのユーザからの署名が必要かを指定します。 次に例を示します。

Policies:
  MyPolicy:
    Type: Signature
    Rule: "OR('Org1.peer', 'Org2.peer')"

このポリシー構造体は次のように解釈できます。MyPolicy という名前のポリシーは、"Org1のピア"または"Org2のピア"の役割を持つアイデンティティの署名によってのみ満たされます

Signatureポリシーは、 ANDORNOutOf の任意の組み合わせをサポートしており、"組織Aの管理者とそれ以外の2組織の管理者、もしくは、20組織のうち11組織の管理者"のように非常に強力なルールを記述することもできます。

ImplicitMeta policies

ImplicitMeta ポリシーは、設定階層の下層部分で定義されている Signature ポリシーを集約します。 例えば、"その組織の管理者の過半数"のようなデフォルトルールをサポートしています。 これらのポリシーは、 Signature ポリシーとは異なりますが、非常に単純な構文を使用します。 <ALL|ANY|MAJORITY> <sub_policy>.

次に例を示します。: ANY Readers または MAJORITY Admins.

デフォルトのポリシー設定では、 Admins は運用の役割を持ちます。 Admins(またはAdminsの一部)だけがリソースにアクセスできるポリシーは、ネットワークの機密性や運用面(チャネル上のチェーンコードのインスタンス化など)に使用される傾向があります。 Writers はトランザクションのように台帳の更新を提案できますが、通常は管理者権限を持たない傾向があります。 Readers は受動的な役割です。情報にアクセスすることはできますが、台帳の更新を提案する権限も管理タスクを実行する権限もありません。 これらのデフォルトポリシーは、例えば新しい peer ロールや client ロール( NodeOU を利用する場合)によって、追加、編集、補足することができます。

ImplicitMeta ポリシーの記述例を示します。:

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

ここで、 AnotherPolicy ポリシーは、 MAJORITYAdmins により満たされます。 Admins は、より低レイヤの Signature ポリシーで定義されます。

Where is access control specified?

アクセス制御のデフォルトは configtx.yaml に存在します。 configtxgen は、このファイルを利用してチャネル設定をビルドします。

アクセス制御は、次のいずれかの方法で更新できます。 1つ目は、 configtx.yaml を編集し、新しいチャネル設定を生成する時に利用する方法です。 2つ目は、既存チャネルのチャネル設定内のアクセス制御を更新する方法です。

How ACLs are formatted in configtx.yaml

ACLは、リソース関数名の後に文字列が続くキーバリューペアで記述されます。 これがどのように見えるかを確認するには、configtx.yamlのサンプルファイルを参照してください。

このサンプルからの2つの抜粋:

# ACL policy for invoking chaincodes on peer
peer/Propose: /Channel/Application/Writers
# ACL policy for sending block events
event/Block: /Channel/Application/Readers

これらのアクセス制御リストは、peer/Proposeevent/Block リソースへのアクセスが、それぞれ /Channel/Application/Writers/Channel/Application/Readers という正規化パスで定義されたポリシーを満たすアイデンティティに制限されることを示します。

Updating ACL defaults in configtx.yaml

ネットワークのブートストラップ時にACLのデフォルトを上書きする必要がある場合や、チャネルがブートストラップされる前にACLを変更する必要がある場合は、 configtx.yaml を更新するのがベストプラクティスです。

例えば、ピアのチェーンコード呼び出しに関するポリシーを指定する peer/Propose の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')"

それから、 peer/Propose を変更するために、 configtx.yaml 内の Application: ACLs セクションを:

peer/Propose: /Channel/Application/Writers

下記のように編集します。:

peer/Propose: /Channel/Application/MyPolicy

これらのフィールドが configtx.yaml で変更されると、チャネル作成トランザクションを作成する時、 configtxgen ツールはそのポリシーとACLを使用します。 コンソーシアムメンバーの管理者の1人が適切に署名して送信すると、定義されたACLとポリシーを持つ新しいチャネルが作成されます。

MyPolicy がチャネル設定にブートストラップされると、他のACLのデフォルトを上書きするために参照することもできます。 次に例を示します。

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

これにより、 SampleOrg.admin がブロックイベントをサブスクライブする機能が制限されます。

このACLを使用するチャネルがすでに作成されている場合は、次のフローを使用してチャネル設定を一度に1つずつ更新する必要があります。

Updating ACL defaults in the channel config

MyPolicy を使用して peer/Propose へのアクセスを制限するチャネルがすでに作成されている場合、または他のチャネルに知られたくないACLを作成したい場合は、コンフィギュレーション更新トランザクションを使用してチャネル設定を一度に1つずつ更新する必要があります。

注釈: チャネル設定トランザクションはプロセスが複雑なので、ここでは詳しく説明しません。 詳細については、channel configuration updates、および、"Adding an Org to a Channel" tutorialのドキュメントを参照してください。

設定を編集するには、メタデータのコンフィギュレーションブロックを取得し、変換し、除去した後で、Application: policies の下に MyPolicy を追加します。 ここでは、 AdminsWritersReaders の各ポリシーがすでに存在しています。

"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_identifierrole に注意してください。

それから、設定のACLセクション内で、peer/Propose のACLを:

"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

メンバーが複数のシステムチェーンコードを呼び出す要求を行った場合は、それらのシステムチェーンコードに対するすべてのACLを満たす必要があります。

例えば、 peer/Proposal はチャネル上の任意の提案要求を参照します。 特定の提案が、 Writers を満たすアイデンティティを必要とする2つのシステムチェーンコードと、 MyPolicy を満たすアイデンティティを必要とする1つのシステムチェーンコードへのアクセスを必要とする場合、 提案を送信するメンバーは WritersMyPolicy の両方が"true"と評価されるアイデンティティを持っている必要があります。

デフォルト設定では、 WritersSampleOrg.member という rule を持つ署名ポリシーです。 つまり、"私の組織のすべてのメンバー"ということです。 上記の MyPolicy には、SampleOrg.admin 、つまり、"私の組織のすべての管理者"というルールがあります。 これらのACLを満たすためには、メンバーは管理者であると同時に SampleOrg のメンバーである必要があります。 デフォルトでは、すべての管理者がメンバーになっていますが(すべての管理者がメンバーになっているわけではありません)、これらのポリシーを任意のポリシーに上書きすることができます。 その場合、これらのポリシーを追跡して、(意図的ではない限り)ピアの提案を満たすことが不可能なACLになっていないことを確認することが重要です。