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ポリシーは、 AND
、 OR
、 NOutOf
の任意の組み合わせをサポートしており、"組織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
ポリシーは、 MAJORITY
の Admins
により満たされます。
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/Propose
と event/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
を追加します。
ここでは、 Admins
と Writers
と Readers
の各ポリシーがすでに存在しています。
"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
に注意してください。
それから、設定の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つのシステムチェーンコードへのアクセスを必要とする場合、
提案を送信するメンバーは Writers
と MyPolicy
の両方が"true"と評価されるアイデンティティを持っている必要があります。
デフォルト設定では、 Writers
は SampleOrg.member
という rule
を持つ署名ポリシーです。
つまり、"私の組織のすべてのメンバー"ということです。
上記の MyPolicy
には、SampleOrg.admin
、つまり、"私の組織のすべての管理者"というルールがあります。
これらのACLを満たすためには、メンバーは管理者であると同時に SampleOrg
のメンバーである必要があります。
デフォルトでは、すべての管理者がメンバーになっていますが(すべての管理者がメンバーになっているわけではありません)、これらのポリシーを任意のポリシーに上書きすることができます。
その場合、これらのポリシーを追跡して、(意図的ではない限り)ピアの提案を満たすことが不可能なACLになっていないことを確認することが重要です。