Membership Service Providers (MSP)¶

このドキュメントは、MSPのセットアップとベストプラクティスの詳細を提供します。

メンバーシップサービスプロバイダ (Membership Service Provider, 以下、MSP) は、メンバーシップ操作の抽象化を提供するHyperledger Fabricのコンポーネントです。

特に、MSPは、証明書の発行、証明書の検証、およびユーザ認証の背後にあるすべての暗号化メカニズムとプロトコルを抽象化します。 MSPは、MSP自身のアイデンティティ、およびそれらのアイデンティティを管理するルール (アイデンティティの検証) と認証するルール (署名の生成と検証) を定義することができます。

Hyperledger Fabricブロックチェーンネットワークは、1つまたは複数のMSPによって管理されます。これにより、メンバーシップ操作のモジュール性と、異なるメンバーシップ標準やアーキテクチャ間での相互運用性を提供します。

このドキュメントの残りの部分では、Hyperledger FabricがサポートするMSP実装のセットアップについて詳しく説明し、その使用に関するベストプラクティスについて議論します。

MSPの設定¶

MSPのインスタンスをセットアップするためには、その設定を、各ピアやOrdererについてローカルに指定し (ピアとOrdererの署名を有効にするため)、ピア、Orderer、クライアントのアイデンティティ検証、およびすべてのチャネルメンバーによるそれぞれの署名検証 (認証) を有効にするために、チャネル上で指定をする必要があります。

まず、各MSPについて、そのMSPをネットワーク上で参照するために、名前を指定する必要があります (例: msp1, org2, org3.divA)。これは、コンソーシアム、組織、または組織の部門を表すMSPのメンバーシップルールがチャネル内で参照される名前です。これは MSP識別子 または MSP ID とも呼ばれます。 MSP IDは、MSPインスタンスごとに一意である必要があります。例えば、同じIDを持つ2つのMSPインスタンスがあると、システムチャネル生成時に検出されて、Ordererのセットアップが失敗します。

デフォルトのMSP実装の場合、アイデンティティ (証明書) 検証と署名検証を可能にするために、一連のパラメータを指定する必要があります。これらのパラメータは、RFC5280 によって推定されて、以下を含みます:

信頼のルート(root of trust) を構成する自己署名 (X.509) CA証明書のリスト
このプロバイダが証明書を検証するために考慮する中間CA (Intermediate CA) を表すX.509証明書のリスト。これらの証明書は、信頼のルートにある証明書のいずれか1つのみによって認証される必要があります。中間CAはオプショナルなパラメータです。
このMSPの管理者を表すX.509証明書のリスト。これらの証明書は、信頼のルートとなるCA証明書のいずれか1つにのみによって、検証可能な証明書のパスを持たなくてはいけません。これらの証明書の所有者は、このMSPの設定 (例: ルートCAや中間CA) への変更を要求することが許可されています。
このMSPの有効なメンバーがX.509証明書に含める必要のある組織単位 (Organizational Unit, OU) のリスト。これは、オプショナルな設定パラメータであり、例えば、複数の組織が同一の信頼ルートと中間CAを利用している場合や、メンバーのためのOUフィールドを予約している場合に利用されます。
証明書失効リスト (Certificate Revocation List, CRL) のリスト。それぞれは、(中間またはルート) MSP CAのうちいずれか1つのみに対応します。このオプショナルなパラメータです。
TLS証明書のためのの TLS信頼ルート を構成するための自己署名 (X.509) 証明書のリスト。
このプロバイダが考慮する必要のある中間TLS CAを表すX.509証明書のリスト。これらの証明書はTLSの信頼されたルート証明書のいずれか1つのみによって認証される必要があります。中間CAはオプショナルなパラメータです。

MSPインスタンスの 有効な アイデンティティは以下の条件を満たす必要があります:

アイデンティティは、X.509証明書の形式であり、信頼できるルート証明書のいずれか1つのみに対して検証可能な証明書のパスが含まれている。
アイデンティティは、どのCRLにも含まれていない。
アイデンティティは、X.509証明書の OU フィールドに、MSPで設定している組織単位 (OU) を1つ以上 リストアップ している。

現在のMSP実装におけるアイデンティティの有効性に関する詳細については、MSPアイデンティ検証ルールを参照してください。

検証に関連するパラメータに加えて、MSPがインスタンス化されたノードが署名または認証するためには、以下を指定する必要があります。

ノードによる署名に使われる署名鍵 (現在は、ECDSA鍵のみがサポートされています)。
このノードのX.509証明書。これはこのMSPの検証パラメータで有効なアイデンティティです。

MSPアイデンティティは決して期限切れにならないことに注意してください。それらは、適切なCRLに追加することによってのみ取り消すことができます。また、TLS証明書の強制失効については現在サポートされていません。

MSPの証明書とその署名鍵を生成する方法¶

OpenSSL はX.509証明書と鍵を生成することができます。 Hyperledger FabricはRSA鍵と証明書をサポートしていないことに注意してください。

あるいは、Getting Started で説明されているように、ツール cryptogen を使用することもできます。

Hyperledger Fabric CA もMSPを設定するために必要な鍵や証明書の生成に使用できます。

ピアおよびOrderer側のMSPセットアップ¶

ローカルMSP (ピア用もしくはOrderer用) をセットアップするために、管理者は、以下の6つのサブフォルダと1つのファイルを含むフォルダ (例: $MY_PATH/mspconfig) を生成しなければなりません。

管理者の証明書に対応するPEMファイルを含んだ admincerts フォルダ (フォルダ内の各PEMファイルが証明書と1対1対応)
ルートCAの証明書に対応するPEMファイルを含んだ cacerts フォルダ (フォルダ内の各PEMファイルが証明書と1対1対応)
(Optional) 中間CAの証明書に対応するPEMファイルを含んだ intermediatecerts フォルダ (フォルダ内の各PEMファイルが証明書と1対1対応)
(Optional) サポートされる組織単位 (OU) とアイデンティティ分類を設定するための config.yaml ファイル (以降の各セッションを参照)
(Optional) 対象となるCRLを含んだ crls フォルダ
そのノードの署名鍵を持つPEMファイルを含んだ keystore フォルダ。現在はRSA鍵はサポートしていないことを強調しておきます。
そのノードのX.509証明書を持つPEMファイルを含んだ signcerts フォルダ
(Optional) TLSルートCA証明書に対応するPEMファイルを含んだ tlscacerts フォルダ (フォルダ内の各PEMファイルが証明書と1対1対応)
(Optional) 中間TLS CA証明書に対応するPEMファイルを含んだ tlsintermediatecerts フォルダ (フォルダ内の各PEMファイルが証明書と1対1対応)

ノードの設定ファイル (ピア用のcore.yamlファイルやOrderer用のorderer.yamlファイル) において、 mspconfigフォルダへのパスと、そのノードのMSP IDを指定する必要があります。 mspconfigフォルダへのパスは、FABRIC_CFG_PATHからの相対パスであることが想定されており、ピアに関してはパラメータ mspConfigPath の値、およびOrdererに関しては LocalMSPDir の値として提供されます。そのノードのMSP IDは、ピアに関してはパラメータ localMspId の値、およびOrdererに関しては LocalMSPID の値として提供されます。これらの変数は、ピア用の接頭語 (Prefix) であるCOREを使った環境変数 (例: CORE_PEER_LOCALMSPID) と Orderer用の接頭語 (Prefix) であるOREDERERを使った環境変数 (例: ORDERER_GENERAL_LOCALMSPID) を介して上書きできます。 Ordererのセットアップでは、システムチャネルのジェネシスブロックを生成し、Ordererに提供する必要があることに注意してください。 MSP設定のニーズについては、次のセクションで説明します。

「ローカル」MSPの 再設定 は、手動でのみ可能で、ピアあるいはOrdererプロセスを再起動する必要があります。将来のリリースでは、オンライン/動的再設定を提供することをめざしています (つまり、ノードによって管理されるシステムチェーンコードを用いることで、ノードを止めることが必要とされなくなります)。

組織単位 (OU)¶

MSPの有効なメンバーがX.509証明書に含まれるべき組織単位のリストを設定するために、 config.yaml ファイルに組織単位 (略称: OU) を指定する必要があります。以下に例を示します。

OrganizationalUnitIdentifiers:
  - Certificate: "cacerts/cacert1.pem"
    OrganizationalUnitIdentifier: "commercial"
  - Certificate: "cacerts/cacert2.pem"
    OrganizationalUnitIdentifier: "administrators"

上記の例では、commercial と administrators という二つの組織単位 (OU) 識別子を宣言しています。 MSPアイデンティティは、これらのOU識別子のうち少なくとも1つを保持している場合に有効となります。 Certificate フィールドは、特定のOUを持つIDが検証されるべきCAまたは中間CAの証明書へのパスを指します。これらのパスは、MSPルートフォルダの相対パスであり、空にすることはできません。

アイデンティティ分類¶

デフォルトのMSP実装では、組織は、X.509証明書のOUに基づいて、IDをクライアント (client)、管理者 (admin)、ピア、Ordererにさらに分類することができます。

ネットワーク上で取引を行う場合、アイデンティティは クライアント (client) に分類される必要があります。
チャネルへのピアの参加 (Join) やチャネル設定更新トランザクションへの署名のような管理タスクを処理する場合、アイデンティティは 管理者 (admin) に分類される必要があります。
トランザクションのエンドースやコミットをする場合、アイデンティティはピアに分類される必要があります。
オーダリングノードに属している場合、アイデンティティは orderer に分類される必要があります。

MSPのクライアント、管理者、ピア、Ordererを定義するためには、 config.yaml ファイルを適切に設定する必要があります。以下にその設定のために必要な config.yaml ファイルのNodeOUセクションの例を示します。

NodeOUs:
  Enable: true
  # 利用したいアイデンティティ分類ごとに、OU識別子を指定します。
  # オプションで、特定のCAまたはあなたの組織の中間証明書によってOU識別子が発行されなければならないことを設定できます。
  # しかし、特定の証明書を設定しないのが一般的な使い方です。
  # 特定の証明書を設定しないことで、すべての証明書を再発行することなく、あとから他のCAまたは中間証明書を追加できます。
  # このため、以下のサンプルでは、証明書設定用 (Certificate) フィールドをコメントアウトしています。
  ClientOUIdentifier:
    # Certificate: "cacerts/cacert.pem"
    OrganizationalUnitIdentifier: "client"
  AdminOUIdentifier:
    # Certificate: "cacerts/cacert.pem"
    OrganizationalUnitIdentifier: "admin"
  PeerOUIdentifier:
    # Certificate: "cacerts/cacert.pem"
    OrganizationalUnitIdentifier: "peer"
  OrdererOUIdentifier:
    # Certificate: "cacerts/cacert.pem"
    OrganizationalUnitIdentifier: "orderer"

アイデンティティ分類は NodeOUs.Enable が true に設定された場合に有効化されます。そして、クライアント (管理者、ピア、Orderer) 組織単位 (OU) 識別子は、それぞれ NodeOUs.ClientOUIdentifier (NodeOUs.AdminOUIdentifier, NodeOUs.PeerOUIdentifier, NodeOUs.OrdererOUIdentifier) キーのプロパティを設定することで定義されます。

OrganizationalUnitIdentifier: は、クライアント (管理者、ピア、Orderer) とみなされるためにX.509証明書に含める必要のあるOUの値です。このフィールドが空の場合には、分類は適用されません。
Certificate: (Optional) には、クライアント (または管理者、ピア、Orderer) IDを検証するべきCAまたは中間CA証明書へのパスを設定します。このフィールドは、MSPルートフォルダの相対パスです。このフィールドに指定できる証明書は1つだけです。このフィールドを設定しない場合には、アイデンティティはこの組織のMSP設定で定義されている任意のCAによって検証されます。将来的に他のCAまたは中間証明書を追加する必要がある場合には、設定しないことが望ましい可能性があります。

NodeOUs.ClientOUIdentifier セクション (NodeOUs.AdminOUIdentifier, NodeOUs.PeerOUIdentifier, NodeOUs.OrdererOUIdentifier) がない場合には、分類が適用されないことに注意してください。 NodeOUs.Enable が true に設定されており、分類キーが定義されていない場合には、アイデンティティ分類が無効であるとみなされます。

アイデンティティは組織単位 (OU) を使うことで、クライアント、管理者、ピア、Ordererのいずれかに分類することができます。この4つの分類は排他的です。アイデンティティをクライアントまたはピアとして分類するためには、v1.1 チャネルケイパビリティを有効にする必要があります。管理者またはOrdererとして分類するためには、v1.4.3 チャネルケイパビリティを有効にする必要があります。

分類によって、MSPの admincerts フォルダに証明書を格納しなくても、アイデンティティを管理者として分類 (および管理者のアクションを実行) 可能です。代わりに、 admincerts フォルダを空のままにして、管理者OU (admin OU) を設定したアイデンティを登録することで管理者を作成できます。 admincerts フォルダ内の証明書は、クライアントOU (client OU) または管理者OU (admin OU) を所有している場合に、それらのベアラ (bearer、持参者) に管理者の役割を付与することができます。

チャネルMSPセットアップ¶

システム生成 (ジェネシス) 時においては、ネットワークに現れるすべてのMSPの検証パラメータを指定し、システムチャネルのジェネシスブロックに含める必要があります。 MSP検証用パラメータは、MSP ID、ルート証明書、中間CA証明書、管理者の証明書、およびOUの仕様とCRLで構成されることを思い出してください。システムジェネシスブロックは、セットアップ段階でOrdererによって提供され、チャネル生成リクエストを認証できるようにします。もしシステムジェネシスブロックが同一の識別子を持つ2つのMSPを含む場合には、Ordererはシステムジェネシスブロックを却下し、その結果、ネットワークのブートストラップが失敗します。

アプリケーションチャネルに関しては、チャネルのジェネシスブロックが、チャネルを管理するMSPだけの検証コンポーネント (※訳者注: 検証パラメータと同義と思われる) を含んでいる必要があります。 1つ以上のピアにチャネルにジョインするように指示をする前に、チャネルのジェネシスブロック (あるいは最新のコンフィグレーションブロック) に正しいMSP設定情報が含まれていることを確認することは、 アプリケーション側の責任 であることを強調します。

configtxgenツールを使用してチャネルを立ち上げる場合には、MSPの検証パラメータをmspconfigフォルダに含め、 configtx.yaml の関連セクションにそのパスを指定することで、チャネルMSPを設定できます。

チャネル上のあるMSPの 再設定 (そのMSPのCAに関連付けられた証明書失効リストのアナウンスも含む) は、 MSPの管理者証明書の所有者が config_update オブジェクトの作成を通じて実施可能です。その管理者によって管理されるクライアントアプリケーションは、さらに、このMSPが登場している (複数の) チャネルに対してもこの更新をアナウンスする必要があります。

ベストプラクティス¶

このセクションでは、一般的なシナリオにおけるMSP設定のベストプラクティスについて詳しく説明します。

1) 組織/会社とMSPの間のマッピング

組織とMSPの間には1対1のマッピングがされることをお勧めします。もし異なるタイプのマッピングが選択された場合には、以下の点を考慮する必要があります:

1つの組織が様々なMSPを使用する場合 これは、管理の独立性の理由あるいはプライバシーの理由のために、 MSPによってそれぞれ表現される様々な部門を含む組織の場合に対応します。この場合、ピアは単一のMSPのみが所有することができ、他のMSPのアイデンティティを持つピアを同じ組織のピアとして認識することはできません。これの意味するところは、ピアは、実際の組織を構成するプロバイダのすべての集合ではなく、同じ部門のメンバーであるピアの集合と、ゴシッププロトコルを介した組織スコープのデータ (gossip organization-scoped data) を共有ができるということです。
単一のMSPを複数の組織が使う場合 これは、似たようなメンバーシップアーキテクチャで管理される組織のコンソーシアムの場合に対応します。この場合には、ピアが実際に同じ組織に属しているかどうかに関わらず、同一MSPの下でアイデンティティを持つピアに組織スコープのメッセージが伝達されることを知っておく必要があります。これは、MSP定義の粒度、および/またはピアの設定の制限です。

2) 1つの組織に異なる部門 (組織単位 (OU)) があり、それらに異なるチャネルへのアクセスを許可したい場合

以下の二つの対処方法があります:

すべての組織のメンバーのためのメンバーシップに対応する1つのMSPを定義. そのMSPの設定は、ルートCA、中間CA、および管理証明書のリストで構成されます。そして、メンバーシップIDには、メンバーが所属する組織単位 (OU) が含まれます。さらに、ポリシーは特定の「役割」(peer, admin, client, orderer, memberのうちのいずれか) のメンバーを捉えるために定義することができ、これらのポリシーは、チャネルの読み書き (read/write) ポリシーやチェーンコードのエンドースメントポリシーを構成することができます。 configtx.yaml のプロファイルセクションでカスタムOUを指定することは現在のところできません。このアプローチの制約は、ゴシップピアがローカルMSPの下で同一メンバーシップアイデンティティを持つピアを同じ組織のメンバーとしてみなすため、その結果、それらのピアに組織スコープのデータ (例えばステータス) を伝搬することです。
各部門を表現するために1つのMSPを定義. これは、ルートCA、中間CA、および管理者証明書のセットを各部門に対して指定する必要があり、MSP間で重複する証明書パスが存在しないようにする必要があります。このことは、例えば、部門ごとに異なる中間CAが使用されることを意味します。この欠点は1つではなく複数のMSPを管理する必要があることですが、これにより1つ目のアプローチで存在していた問題が回避されます。 MSP設定のOU拡張を活用することで、各部門に1つのMSPを定義することができます。

3) 同一組織内でクライアントとピアを分離したい場合

多くのケースでは、アイデンティティの「タイプ」がアイデンティティ自体から取得可能である必要があります (例: エンドースメントが、クライアントやOrdererとしてのみ動くノードではなく、ピアから派生したものであることが保証されていることが必要な場合があります)。

このような要件のためのサポートは限られています。

この分離を可能にする1つの方法は、ノードタイプごとに (1つはクライアント用に、もう1つはピア/Orderer用に) 別々の中間CAを作成し、 2つの異なるMSPを設定することです (1つはクライアント用、もう1つはピア/Orderer用)。この組織がアクセスする必要があるチャネルには、両方のMSPを含める必要がありますが、エンドースメントポリシーは、ピアを参照するMSPのみを利用します。これにより、最終的に、この組織が2つのMSPインスタンスにマッピングされ、ピアとクライアントの相互作用の方法に特定の結果をもたらすでしょう。

同じ組織のすべてのピアが1つのMSPに属しているために、ゴシップに大きな影響はありません。ピアは特定のシステムチェーンコードの実行をローカルMSPベースのポリシーで制限できます。例えば、クライアントのみとなるローカルMSPの管理者がリクエストに署名した場合にのみ (エンドユーザがそのリクエストの起点としてなっているはず) 、ピアは「joinChannel」リクエストを実行するとします。このケースでの矛盾は、ピア/Orderer用のMSPメンバーになるクライアントのみがそのMSPの管理者になることを許可するようにすれば、回避できます。

このアプローチで考慮すべきもう1つのポイントは、ピアがイベント登録要求を、ローカルMSP内のリクエスト組織のメンバーシップに基づいて行うことです。明らかに、リクエストの発行者はクライアントであるため、常にリクエスト組織はリクエストされたピアと異なるMSPに属しているとみなされ、ピアはリクエストを却下します。

4) 管理者とCAの証明書

MSPの管理者証明書を、 信頼のルート または中間CAのためにMSPが考慮する証明書とは異なるものに設定することは重要です。これは、新しい証明書の発行、および/または既存の証明書の検証から、メンバーシップコンポーネントの管理義務を切り離すための一般的な (セキュリティの) 慣例です。

5) 中間CAのブロック

前のセクションで述べたように、MSPの再設定は、再設定メカニズム (ローカルMSPインスタンスの手動での再設定、およびチャネルのMSPインスタンス用の、適切に構成された config_update メッセージを介した再設定) によって実現されます。明らかに、MSPで考慮されている中間CAがそのMSPのアイデンティティ検証で使わなくするための2つの方法があります:

そのMSPを再設定して、信頼できる中間CA証明書のリストに対象となる中間CAの証明書が含まれないようにします。ローカルMSPでは、これは対象となるCA証明書が intermediatecerts フォルダから削除されることを意味します。
そのMSPを再設定して、前述の中間CAの証明書を非難する、信頼のルートによって生成されたCRLを含むようにします。

現在のMSP実装では、このうち(1)の方法のみをサポートしています。この方法のほうがシンプルであり、中間CAをブラックリスト化する必要がないためです。

6) CAとTLS CA

MSPアイデンティティのルートCAとMSP TLS証明書のルートCA (およびそれらの各中間CA) は、別フォルダで宣言する必要があります。これは、異なるクラスの証明書が混同されないようにするためです。 MSPアイデンティティとTLS証明書の両方で同じCAを流用することは禁止されてはいませんが、ベストプラクティスとしては、本番においてはこれを避けることを提案しています。