Policies

想定読者: アーキテクト、アプリ/スマートコントラクト開発者、管理者

このトピックでは、以下について説明します:

• What is a policy
• Why are policies needed
• How are policies implemented throughout Fabric
• Fabric policy domains
• How do you write a policy in Fabric
• Fabric chaincode lifecycle
• Overriding policy definitions

What is a policy

最も基本的なレベルでは、ポリシーとは、意思決定がどのように行われ、特定の結果が得られるか、に関する構造を定義する一連のルールです。 そのために、ポリシーには通常、ある 資産 (asset) に対する個人のアクセス権や権利のような、誰が と なにを を記述します。 レンタカー、健康、住宅など、我々にとって価値のある資産を守るために我々の日常生活を通じてポリシーが使われてることがわかります。

例えば、インシュアランス・ポリシー (保険契約) は、保険の支払いがされる内容条件、期間、制限事項、および有効期限を定義します。 そのポリシーは、保険契約者と保険会社によって合意され、各当事者の権利と責任を定義します。

インシュアランス・ポリシーは、リスク管理のために導入されていますが、 Hyperledger Fabricでは、ポリシーは、インフラ管理のメカニズムです。 Fabricのポリシーは、ネットワーク、チャネル、スマートコントラクトへの変更を受け入れるか却下するかをメンバーが合意する方法を表します。 ポリシーは、ネットワークが最初に設定されるときにコンソーシアムメンバーによって合意されますが、ネットワークの成長に応じて変更されることもあります。 例えば、ポリシーにはチャネルへのメンバーの追加や削除の基準を記述したり、 チャネルのブロックのフォーマットを変更したり、スマートコントラクトをエンドースするのに必要な組織数を指定したりします。 これらのアクションはすべて、誰がアクションをできるかを定義するポリシーによって記述されます。 簡単に言うと、Fabricネットワークでやりたいことはすべてポリシーで制御されるということです。

Why are policies needed

ポリシーは、Hyperledger FabricがEthereumやBitcoinのような他のブロックチェーンとは異なる要素の1つです。 これらのシステムでは、トランザクションはネットワークの任意のノードによって生成・検証することが可能です。 ネットワークを管理するポリシーについては、常時固定されており、コードを管理するのと同じプロセスで変更することができます。 Fabricは基盤となるインフラによってユーザーが認識される許可型ブロックチェーンであるため、 それらのユーザーはネットワークのガバナンスを起動する前に決定し、稼働中のネットワークのカバナンスを変更することができます。

ポリシーは、メンバーがどの組織がFabricネットワークにアクセスしたり更新したりできるかを決定することを可能にし、 その決定を強制するメカニズムを提供します。 ポリシーはユーザーチェーンコードやシステムチェーンコードなどの特定のリソースにアクセスできる組織のリストを含みます。 ポリシーはチャネルやスマートコントラクトなどのリソースを更新するための提案を合意するための必要な組織数も指定します。 一度ポリシーが記述されると、ポリシーはトランザクションや提案に添付された署名のコレクションを評価し、 署名がポリシーはそのネットワークによって合意されたカバナンスを満たすかどうかを検証します。

How are policies implemented throughout Fabric

ポリシーはFabricネットワーク上の様々なレベルで実装されています。 各ポリシーのドメインは、ネットワークの運用方法の様々な側面を管理します。

Fabricポリシー階層の視覚的表現

System channel configuration

すべてのネットワークは、オーダリング用の システムチャネル を用いて開始されます。 オーダリングサービスのためには、システムチャネルは1つだけ必要であり、 このチャネルは最初に生成されるチャネルです。 システムチャネルにはオーダリングサービスのメンバーとなる組織 (オーダリング組織, ordering organizations)、 取引を行うネットワーク上にある組織 (コンソーシアム組織、consortium organizations) も含まれます。

オーダリング用のシステムチャネル設定ブロック内のポリシーはオーダリングサービスで使われる合意形成を管理し、 新しいブロックの生成方法を定義します。 また、システムチャネルはコンソーシアムのどのメンバーが新しいチャネルを生成できるかも管理します。

Application channel configuration

アプリケーション チャネル はコンソーシアム内の組織の間でプライベートなやり取りをするメカニズムを提供するために使用されます。

アプリケーションチャネルのポリシーは、チャネルからメンバーを追加または削除する機能を管理します。 アプリケーションチャネルは、Fabricのチェーンコードライフサイクルを使ってチャネルにチェーンコードが定義・コミットされる前に、 そのチェーンコードをどの組織が承認する必要があるかも管理します。 アプリケーションチャネルは最初に生成されるときに、 デフォルトではシステムチャネルからすべてのオーダリングサービスのパラメータを継承します。 しかし、これらのパラメータ (およびそれらを管理するポリシー) は、チャネルごとにカスタマイズ可能です。

Access control lists (ACLs)

ネットワーク管理者はFabricのACLの使用に特に関心があるでしょう。 ACLはリソースを既存のポリシーに関連付けることで、リソースへのアクセスを設定する機能を提供します。 これらの「リソース」は、システムチェーンコードの機能 (例えば、「qscc」の「GetBlockByNumber」) あるいは その他のリソース (例えば、誰がブロックイベントを受信できるか) である可能性があります。 ACLはアプリケーションチャネル設定の中で定義されたポリシーを参照し、それらを拡張して追加のリソースを制御します。 FabricのACLのデフォルトセットは configtx.yaml ファイル内の Application: &ApplicationDefaults セクションに記述されますが、 本番環境では、それらは上書き可能であり、上書きするべきです。 configtx.yaml で指定されたリソースのリストは、Fabricによって現在定義されているすべての内部リソースの完全なセットです。

このファイル内では、ACLは以下のフォーマットで表現されます。

# チェーンコード間呼び出しのためのACLポリシー
peer/ChaincodeToChaincode: /Channel/Application/Readers

ここで、 peer/ChaincodeToChaincode は保護されているリソースを表し、 /Channel/Application/Readers は関連するトランザクションが有効とみなされるために満たす必要があるポリシーを表します。

ACLの詳細については、運用ガイドのACLsを参照してください。

Smart contract endorsement policies

チェーンコードパッケージ内のすべてのスマートコントラクトは、 トランザクションが有効とみなされるために、特定のスマートコントラクトに対して そのトランザクションを実行および検証する必要がある異なるチャネルメンバー組織に属しているピアの数を指定する、 エンドースメントポリシーを持ちます。 エンドースメントポリシーは、提案の実行を (ピアを通じて)「エンドース」(つまり、承認) する必要がある組織を定義します。

Modification policies

最後の種類のポリシーとして、Fabricの動作に重要なものがあります。 それが、「変更ポリシー (Modification policy) 」です。 変更ポリシーは、任意の設定 更新 の署名 (承認) に必要なアイデンティティのグループを指定します。 ポリシー更新方法を定義するポリシーです。 つまり、各チャネル設定要素には、その変更を管理するポリシーへの参照が含まれています。

The Fabric policy domains

Fabricのポリシーは柔軟であり、ネットワークのニーズに合わせて設定することができる一方、 ポリシーの構造は当然、オーダリングサービスの組織、あるいは、コンソーシアムメンバーが 管理するドメイン間の分割につながります。 次の図では、デフォルトポリシーがどのように下層のFabricポリシードメインに対する制御を実装しているかを示しています。

オーダリング組織とコンソーシアム組織が管理するポリシードメインの詳細

完全に機能するFabricネットワークは異なる責任を持つ多くの組織を特色とすることができます。 ドメインは、オーダリングサービスの創設者がコンソーシアムの初期ルールやメンバーシップを設立可能にできるようにすることで、 異なる権限や役割を異なる組織に拡張する機能を提供します。 また、ドメインは、コンソーシアムに参加する組織がプライベートアプリケーションチャネルを生成し、 その組織のビジネスロジックを管理し、ネットワーク上に配置されるデータにアクセス制限できるようにします。

システムチャネル設定と各アプリケーションチャネル設定の一部により、オーダリング組織は、 コンソーシアムのメンバーである組織、ブロックがチャネルに配信される方法、 オーダリングサービスのノードによって使われる合意形成機構を制御できます。

システムチャネル設定によって、コンソーシアムのメンバーがチャネルを生成することを可能とします。 アプリケーションチャネルとACLは、コンソーシアム組織がチャネルのメンバーを追加または削除し、 チャネル上のデータとスマートコントラクトへのアクセスを制限するために使用するメカニズムです。

How do you write a policy in Fabric

Fabricで何かを変更したい場合、そのリソースに関連付けられたポリシーは、 個別メンバーからの明示的な署名、あるいはグループからの暗黙的な署名のいずれかによって、 誰 がそれを承認する必要があるかを記述しています。 保険ドメインでは、明示的な承認は、住宅オーナー保険代理店グループのメンバーの一人がありえます。 そして、暗黙的な承認は、住宅オーナー保険グループの管理メンバーの過半数の承認を必要とすることに類似しています。 ポリシーを更新する必要なしに、そのグループのメンバーを時間の経過とともに変更できるため、 暗黙的な承認は特に便利です。 Hyperledger Fabricでは、明示的な承認のためには Signature シンタックスが、暗黙的な承認のためには ImplicitMeta シンタックスが使われます。

Signature policies

Signature ポリシーは、OR('Org1.peer', 'Org2.peer') など、 ポリシーが満たされるために署名する必要がある特定のタイプのユーザーを定義します。 これらのポリシーは、「組織Aの管理者と他の2組織の管理者、または6組織のうち5組織の管理者」 のような非常に具体的なルールの構築を可能にするため、最も用途が広いと考えられています。 構文は、 AND 、 OR 、 NOutOf の任意の組み合わせをサポートしています。 たとえば、 AND('Org1.member', 'Org2.member') のような形でポリシーを簡単に表現できます。 これは、Org1の少なくとも1名のメンバーとOrg2の1名のメンバーからの署名がポリシーを満たすために必要であることを意味します。

ImplicitMeta policies

ImplicitMeta ポリシーは、設定ツリー内のポリシーの階層に基づいたチャネル設定のコンテキストでのみ有効です。 ImplicitMetaポリシーは、最終的にSignatureポリシーによって定義された設定ツリーのより深いポリシーの結果を集約します。 ImplicitMetaポリシーはチャネル設定の現在の組織に基づいて暗黙的に構築されているため Implicit (暗黙的) と呼ばれ、 それらの評価は特定のMSPプリンシパルに対してではなく、設定ツリー内でそれらよりも下にある他のサブポリシーに対して行われるため Meta と呼ばれます。

次の図は、アプリケーションチャネルの階層型ポリシー構造を示し、 /Channel/Admins という名前の ImplicitMeta チャネル設定ポリシーが、設定階層でその下にある Admins というサブポリシーが満たされたときにどのように解決されるかを示しています。 各チェックマークはサブポリシーの条件が満たされたことを表しています。

上記の図を見るとわかるように、 ImplicitMeta ポリシーは、Type = 3、 異なるシンタックスである "<ANY|ALL|MAJORITY> <SubPolicyName>" を使います。 例えば、以下の通りです。

`MAJORITY sub policy: Admins`

この図では この設定ツリー以下のすべての Admins ポリシーを参照する Admins サブポリシーが示されています。 管理者は、独自のサブポリシーを作成し、好きな名前を付けて、各組織でそれらを定義できます。

前述の通り、 MAJORITY Admins などの ImplicitMeta ポリシーの主な利点は、 新しい管理組織をチャネルに追加するときに、チャネルポリシーを更新する必要がないことです。 従って、 ImplicitMeta ポリシーは、コンソーシアムのメンバーが変わったときにも、より柔軟であると考えられます。 Ordererに関するコンソーシアムでは、新しいメンバーを追加したり、既存のメンバーが退会したりする場合に、 コンソーシアムのメンバーがその変更に同意することで変更できますが、その際にポリシーの更新自体は必要ありません。 図が示すように、 ImplicitMeta ポリシーは、設定ツリーでそれらの下にある Signature サブポリシーを最終的に解決することを思い出してください。

また、アプリケーションレベルの ImplicitMeta ポリシーを定義して、 たとえばチャネルなどの組織横断での操作を行うことができます。 ANY、ALL、またはMAJORITYが満たされていることを要求することが可能です。 このフォーマットは、より優れた、より自然なデフォルト設定として適しているため、 各組織が有効なエンドースメントの意味を決めることができます。

組織定義に NodeOUs を含めると、さらに細かく制御できます。 組織単位 (OU) は、Fabric CAのクライアント設定ファイルで定義されており、アイデンティ作成時に関連付けることができます。 Fabricでは、 NodeOUs はデジタル証明書階層のアイデンティを分類する方法を提供します。 たとえば、特定の NodeOUs が有効になっている組織では、その「ピア」署名が有効な承認であることを要求できますが、 何もない組織では、任意のメンバー署名を要求するだけかもしれません。

An example: channel configuration policy

ポリシーを理解するには、チャネルポリシーが定義されている configtx.yaml を調べることから始めます。 Fabricテストネットワーク (test-network) 内の configtx.yaml ファイルを使用して、両方のポリシー構文タイプの例を確認できます。 fabric-samples/test-network サンプルで使われる configtx.yaml ファイルを見ていきます。

ファイルの最初のセクションでは、ネットワークの組織を定義します。 各組織の定義の内部には、その組織のデフォルトのポリシーである Readers 、 Writers 、 Admins 、および Endorsement がありますが、 ポリシーには任意の名前を付けることができます。 各ポリシーには、ポリシーの表現方法 ( Signature または ImplicitMeta ) を示す Type と Rule があります。

以下のテストネットワークの例は、システムチャネルのOrg1の組織定義を示しています。 ここで、ポリシーの Type は Signature であり、エンドースメントポリシールールは "OR('Org1MSP.peer')" として定義されています。 このポリシーは、 Org1MSP のメンバーであるピアが署名する必要があることを指定します。 ImplicitMetaポリシーが指すサブポリシーになるのは、これらのSignatureポリシーです。

**Signatureポリシーを使って定義された組織の例を見るにはこちらをクリックして下さい**

 - &Org1
        # DefaultOrgは、fabric.git開発環境のsampleconfig内で使われる組織を定義します。
        Name: Org1MSP

        # MSP定義をロードするID
        ID: Org1MSP

        MSPDir: crypto-config/peerOrganizations/org1.example.com/msp

        # Policiesでは、設定ツリーのこのレベルにおけるポリシーのセットを定義します。
        # 組織ポリシーの場合、その正規化パス (canonical path) は通常以下の通りです。
        #   /Channel/<Application|Orderer>/<OrgName>/<PolicyName>
        Policies:
            Readers:
                Type: Signature
                Rule: "OR('Org1MSP.admin', 'Org1MSP.peer', 'Org1MSP.client')"
            Writers:
                Type: Signature
                Rule: "OR('Org1MSP.admin', 'Org1MSP.client')"
            Admins:
                Type: Signature
                Rule: "OR('Org1MSP.admin')"
            Endorsement:
                Type: Signature
                Rule: "OR('Org1MSP.peer')"

次の例は、 configtx.yaml の Application セクションで使用される ImplicitMeta ポリシータイプを示しています。 これらのポリシーのセットは、 /Channel/Application/ パスにあります。 FabricのACLのデフォルトセットを使用する場合、これらのポリシーは、台帳へのクエリ、チェーンコードの呼び出し、チャネル設定の更新など、 アプリケーションチャネルの多くの重要な機能の動作を定義します。 これらのポリシーは、各組織に定義されたサブポリシーを参照します。 上記のセクションで定義されたOrg1には、 Application セクションの Reader 、 Writer 、および Adminの ImplicitMeta ポリシーによって評価される Reader、 Writer、および Admin サブポリシーが含まれています。 テストネットワークはデフォルトのポリシーで使って構築されているため、 サンプルのOrg1を使用してチャネル上の台帳をクエリし、チェーンコードを呼び出し、作成したテストネットワークチャネルのチャネル更新を承認できます。

**ImplicitMetaポリシーの例を見るにはこちらをクリックしてください**

################################################################################
#
#   SECTION: Application
#
#   - このセクションでは、アプリケーション関連パラメータに関するコンフィグトランザクション
#   あるいはジェネシスブロックにエンコードする値を定義します
#
################################################################################
Application: &ApplicationDefaults

    # Organizationsは、ネットワークのアプリケーション側の参加者として定義されている組織の一覧です
    Organizations:

    # Policiesは、設定ツリーのこのレベルでのポリシーのセットを定義します
    # アプリケーションポリシーの場合、正規化パス (canonical path) は以下の通りです
    #   /Channel/Application/<PolicyName>
    Policies:
        Readers:
            Type: ImplicitMeta
            Rule: "ANY Readers"
        Writers:
            Type: ImplicitMeta
            Rule: "ANY Writers"
        Admins:
            Type: ImplicitMeta
            Rule: "MAJORITY Admins"
        LifecycleEndorsement:
            Type: ImplicitMeta
            Rule: "MAJORITY Endorsement"
        Endorsement:
            Type: ImplicitMeta
            Rule: "MAJORITY Endorsement"

Fabric chaincode lifecycle

Fabric 2.0リリースでは、新しいチェーンコードライフサイクルプロセスが導入され、 より民主的なプロセスを使用してネットワーク上のチェーンコードを管理しています。 新しいプロセスでは、複数の組織が、チェーンコードをチャネルで使用する前に、 どのように運用するかを投票することができます。 この新しいライフサイクルプロセスとそのプロセス中に指定されるポリシーの組み合わせは、ネットワーク全体のセキュリティを決定するため、重要な意味を持ちます。 そのフローの詳細については、Fabric chaincode lifecycle コンセプトトピックをご覧ください。 ただし、本トピックの目的のために、このフローでのポリシーの使用方法を理解する必要があります。 新しいフローには、ポリシーを指定する2つのステップが含まれます。 それは、 承認 (approved) されたときと、チャネルに コミット (committed) されたときです。

configtx.yaml ファイルの Application セクション は、デフォルトのチェーンコードライフサイクルエンドースメントポリシーを含みます。 本番環境では、ユースケースに応じて定義をカスタマイズする必要があるかもしれません。

################################################################################
#
#   SECTION: Application
#
#   - このセクションでは、アプリケーション関連パラメータに関するコンフィグトランザクション
#   あるいはジェネシスブロックにエンコードする値を定義します
#
################################################################################
Application: &ApplicationDefaults

    # Organizationsは、ネットワークのアプリケーション側の参加者として定義されている組織の一覧です
    Organizations:

    # Policiesは、設定ツリーのこのレベルでのポリシーのセットを定義します
    # アプリケーションポリシーの場合、正規化パス (canonical path) は以下の通りです
    #   /Channel/Application/<PolicyName>
    Policies:
        Readers:
            Type: ImplicitMeta
            Rule: "ANY Readers"
        Writers:
            Type: ImplicitMeta
            Rule: "ANY Writers"
        Admins:
            Type: ImplicitMeta
            Rule: "MAJORITY Admins"
        LifecycleEndorsement:
            Type: ImplicitMeta
            Rule: "MAJORITY Endorsement"
        Endorsement:
            Type: ImplicitMeta
            Rule: "MAJORITY Endorsement"

• LifecycleEndorsement ポリシーは誰が チェーンコード定義を承認 する必要があるか管理します。
• Endorsement ポリシーは、 チェーンコードのデフォルトエンドースメントポリシー です。これについては以下で詳しく説明します。

Chaincode endorsement policies

エンドースメントポリシーは、Fabricチェーンコードライフサイクルを使用して、承認され (approved)、チャネルにコミットされる (committed) ときに チェーンコード に指定されます (つまり、1つのエンドースメントポリシーがチェーンコードに関連付けられたすべてのステートをカバーします) 。 エンドースメントポリシーは、チャネル設定で定義されているエンドースメントポリシーを参照するか、Signatureポリシーを明示的に指定することによって指定できます。

承認 (approval) ステップ中にエンドースメントポリシーが明示的に指定されていない場合、 デフォルト Endorsement ポリシー "MAJORITY Endorsement" が使用されます。 これは、チェーンコードに対するトランザクションが有効と見なされるために、異なるチャネルメンバー (組織) に属するピアの過半数がそのトランザクションを実行して検証する必要があることを意味します。 このデフォルトポリシーにより、チャネルに組織が参加するとその組織が自動的にチェーンコードエンドースメントポリシーに追加されるようになります。 デフォルトのエンドースメントポリシーを使用しない場合は、Signatureポリシー形式を使用して、より複雑なエンドースメントポリシーを指定します (たとえば、チェーンコードをある特定の1つの組織が承認し、さらにチャネル上の他の組織の1つが承認することを要求するなど)。

Signatureポリシーを使用すると、アイデンティティをロールにマッチさせるための方法である principals (プリンシパル) を含めることもできます。 プリンシパルはユーザーIDまたはグループIDに似ていますが、アクターの組織、組織単位 (OU)、ロール、特定のアイデンティティなど、 アクターのアイデンティティの幅広いプロパティを含めることができるため、より用途が広くなっています。 プリンシパルについて語るとき、それらはプリンシパルの権限を決定するプロパティです。 プリンシパルは「MSP.ROLE」として記述されます。 MSP は必要なMSP ID (組織) を表し、 ROLE は4つの許可されたロール (メンバー、管理者、クライアント、ピア) の1つを表します。 ユーザーをCAを用いてエンロールすると、ロールがアイデンティティに関連付けられます。 Fabric CAで使用可能なロールのリストはカスタマイズ可能です。

有効なプリンシパルの例としては、以下のようなものがあります:

• 'Org0.Admin': Org0 MSPの管理者
• 'Org1.Member': Org1 MSPのメンバー
• 'Org1.Client': Org1 MSPのクライアント
• 'Org1.Peer': Org1 MSPのピア
• 'OrdererOrg.Orderer': OrdererOrg MSPのOrderer

特定のステート (言い換えると、特定のKey-Valueペア) に別のエンドースメントポリシーしたい場合があります。 ステートベースエンドースメント は、デフォルトのチェーンコードレベルのエンドースメントポリシーを、 特定のKeyのために別のエンドースメントポリシーで上書きするを可能とします。

エンドースメントポリシーの記述方法の詳細については、 オペレーションガイドの Endorsement policies に関するトピックを参照してください。

注: ポリシーは、使用しているFabricのバージョンによって動作が異なります。

• 2.0より前のFabricリリースでは、チェーンコードのエンドースメントポリシーは、チェーンコードのインスタンス化中、またはチェーンコードのライフサイクルコマンドを使用して更新できます。 インスタンス化時に指定されていない場合、エンドースメントポリシーはデフォルトで「チャネル内の組織の任意のメンバー」になります。 たとえば、「Org1」と「Org2」を持つチャンネルのデフォルトのエンドースメントポリシーは「OR(‘Org1.member’, ‘Org2.member’)」です。
• Fabric 2.0以降では、Fabricは新しいチェーンコードライフサイクルプロセスを導入しました。 これにより、チャネルで使用する前にチェーンコードをどのように運用するかについて複数の組織が合意することができます。 新しいプロセスでは、名前、バージョン、チェーンコードのエンドースメントポリシーなど、チェーンコードを定義するパラメーターに組織が同意する必要があります。

Overriding policy definitions

Hyperledger Fabricには、ブロックチェーンの開始、開発、テストに役立つデフォルトポリシーが含まれていますが、 本番環境でカスタマイズされることを想定しています。 configtx.yaml ファイルのデフォルトポリシーに注意する必要があります。 チャネル設定ポリシーは、 configtx.yaml のデフォルトの Readers 、 Writers 、 Admins を超えて、任意の動詞で拡張できます。 Orderer用のシステムチャネルとアプリケーションチャネルは、 Orderer用のシステムチャネルの configtx.yaml または特定のチャネルの configtx.yaml を編集して、 デフォルトポリシーを上書きするときに、config updateを発行することで上書きされます。

より詳細な情報は、トピック Updating a channel configuration を参照してください。