実践！ブロックチェーン いろは
第5回 ビジネスでの応用に必須となる権限管理の詳細を解説！

新年明けましておめでとうございます！ おかげさまで、2021年に開始させていただいた「実践ブロックチェーンいろは」の連載も5回目を迎えることになりました。世間では、まだまだコロナ禍の影響が続き、生活なども制限される状況が続いていますが、一刻も早く乗り越えていくことができればと思います。

ここ数ヵ月間における、いろはのトピックスについて

Hyperledger Iroha関連のニュースとしては、カンボジア国立銀行（中央銀行）がスマートフォンを使った小口決済システム「バコン」にHyperledger Irohaの技術を採用したのに加えて、2021年10月4日にはラオス中央銀行でもHyperledger Irohaの技術を利用したCBDC（中央銀行デジタル通貨）の検討が開始されたことが発表されています。

さらに2021年末の12月9日には内閣官房から「大洋州所国の金融インフラ調査・分析業務」を受託したNTTデータ経営研究所から、一部の業務としてブロックチェーン技術を活用したデジタル通貨および決済インフラなどに関する相手国の導入可能性調査をソラミツ株式会社が受託しています。大洋州4カ国である、フィジー、ソロモン諸島、トンガ、バヌアツにおいても、Hyperledger IrohaによるCBDCが利用される日が来るのかも知れません。

・2021年10月4日　ソラミツ、ラオス中央銀行とCBDCの検討開始　PRTIMES
・2021年12月29日　内閣官房・「大洋州諸国の金融インフラ調査・分析業務」のNTTデータ経営研究所からの受託とデジタル通貨の検討開始　PRTIMES

いろはの権限管理

前置きが長くなりましたが、本題に入りたいと思います。今回は、Hyperledger Irohaがブロックチェーンとしてビジネスで利用される際に必須機能の1つとなる権限管理の仕組みについて説明していきたいと思います。

第2回でも説明させていただきましたが、パブリックブロックチェーンとして誕生したビットコインやイーサリアムなどの場合には、すべての情報が公開されていることが大きな特徴であり、その特徴をもとにしてブロックチェーン（分散台帳）に記録されている情報の信頼性が確保されています。

ところが、ブロックチェーンは暗号資産に利用できるだけではなく、他の多くのユースケースでも利用していくことができます。そこで、ブロックチェーンをビジネスで利用する際には、すべての参加者が平等に情報を取り扱えるだけではなく、必要な人が必要な情報だけを取り扱えるようにする必要が出てきます。

たとえば、サプライチェーンのシステムにブロックチェーンを利用している場合、商品の仕入れ値段は当事者のみが知っていて、他の人には知られたくない場合があります。このように、必要な情報を必要な参加者だけが取り扱い、参照できるようにする機能がHyperledger Irohaでは権限管理の仕組みとして実装されています。ここで、Hyperledger Irohaの場合には前回ご紹介している「データモデル」に基づいた実装となっているために、特別なプログラミングをすることなく、元々備わっている権限管理の機能を利用していくことが可能となっています。

いろはのパーミッションとロールの具体例

Hyperledger Irohaでは、図のようにデータモデルに基づいて設定されたドメイン内にアセットとアカウントが設定されます。そしてドメイン内のアカウントの権限に基づいて、トランザクションを発行したり、トランザクションなどの情報を参照することができます。ここで、トランザクションを発行したり、情報を参照したりする操作は、その操作を実行するアカウントに設定された権限の範囲内においてのみ可能となっています。

それでは、APIを使用していく上での権限管理の方法であるパーミッションとロールについて見ていきたいと思います。

Hyperledger Irohaではデータモデルが定義されています。
トランザクションを発行したりクエリーで情報を参照したりする主体となるのがアカウントですが、アカウントにはロールが設定されています。このロールは、あらかじめ定義されているパーミッションを組み合わせて、必要な役割として定義していきます。その上で、必要なロールをアカウントに設定することで、アカウントの実行できる処理が決められていきます。
具体例として、Hyperledger IrohaのGitHubで公開されているリポジトリーでの使われ方を紹介しましょう。

少し図が詳しいのですが、次のような内容になっています。

アカウント
・admin
・alice
・bob

ロール
・admin
・user
・money_creator

ここでは、admin、alice、bobとして3つのアカウントが設定されています。また、パーミッションを組み合わせた3つのロール（役割）がadmin、user、money_creatorとして設定されています。

そして、これもHyperledger Irohaの大きな特徴の1 つですが、実はジェネシスブロックでトランザクションを実行して、これらのロールをアカウントに設定しています。ジェネシスブロックで実行されている内容は次のようになっています。ここでは説明のためにalice、bobというアカウントを使用していますが実際のジェネシスブロックではtestというアカウントになっています。

（1）CreateRoleでadmin、user、money_creatorの3つのロールを作成して、それぞれのロールに必要なパーミッションを割り当てます。
（2）CreateAccountでadmin、testのアカウントを作成。ここで、先に実行されているCreateDomainの設定で作成されるアカウントの既定値のロールがuserとなっているために、すべてのアカウントがuserロールで設定されています。
（3）AppendRoleでadminアカウントにadminロールとmoney_creatorロールを追加します。この操作によってadminアカウントが、実際に管理者権限を保持して実行できるようになっています。

パーミッションの実際

can_append_role	can_read_roles	can_get_all_acc_ast_txs
can_create_role	can_get_roles	can_get_domain_acc_ast_txs
can_detach_role	can_get_my_account	can_get_my_txs
can_add_asset_qty	can_get_all_accounts	can_get_all_txs
can_subtract_asset_qty	can_get_domain_accounts	can_get_blocks
can_add_peer	can_get_my_signatories	can_get_peers
can_remove_peer	can_get_all_signatories	can_get_my_engine_receipts
can_add_signatory	can_get_domain_signatories	can_get_domain_engine_receipts
can_set_quorum	can_get_my_acc_ast	can_get_all_engine_receipts
can_create_account	can_get_all_acc_ast	can_grant_can_set_my_quorum
can_set_detail	can_get_domain_acc_ast	can_grant_can_add_my_signatory
can_create_asset	can_get_my_acc_detail	can_grant_can_remove_my_signatory
can_transfer	can_get_all_acc_detail	can_grant_can_transfer_my_assets
can_receive	can_get_domain_acc_detail	can_grant_can_set_my_account_detail
can_create_domain	can_get_my_acc_txs	can_grant_can_call_engine_on_my_behalf
can_add_domain_asset_qty	can_get_all_acc_txs
can_subtract_domain_asset_qty	can_get_domain_acc_txs
can_call_engine	can_get_my_acc_ast_txs

参考：　https://github.com/hyperledger/iroha/blob/1.2.1/shared_model/schema/primitive.proto

Hyperledger Irohaで実際に用意されているパーミッションは、表1のような内容になっています。このように、すべてのトランザクション操作でパーミッションとして許可されている必要があります。さらに、データ参照をするクエリーも、パーミッションで許可されている場合にのみ参照が可能となっています。

特に、クエリーにおいては、たとえばアカウント情報を参照するGetAccountの場合には、can_get_my_account、can_get_all_accounts、can_get_domain_accountsのような種類があります。

ここで、can_get_my_accountは、一般ユーザーのアカウントが持つ権限で、自分自身のアカウント情報のみを参照できる権限です。can_get_all_accountsは、Hyperledger Irohaのネットワーク全体を管理する管理者のための権限で、すべてのアカウント情報を参照することができます。最後の、can_get_domain_accountsの場合には、ドメイン管理者の有する権限で、自アカウントの所属しているドメイン内のすべてのアカウント情報を参照することができます。

このようなパーミッションを組み合わせることで、テナントモデルとしてHyperledger Irohaのネットワークに設定したドメインごとに管理者を設定して運用することも可能になります。この場合、ドメインの管理者は、自アカウントの所属していないドメインの情報を参照することはできないようになっています。

権限設定により、あたかも憲法のような策定が可能に！

さらにHyperledger Irohaでは、ジェネシスブロックを使用することで、CreateRoleを実行してロールを作成することができ、CreateAccountで作成したアカウントにAppendRoleを実行して役割（ロール）を割り当てられます。

この機能を利用することで、あらかじめ設計しておいた役割（ロール）をジェネシスブロックで作成しておき、その際にcan_create_roleとcan_append_roleのパーミッションを割り当てないでおくようなことも可能です。この場合には、最初に作成されたジェネシスブロックの内容を逸脱したロールを作成することや、割当てるようなことができなくなってしまいます。最初に設計した役割の範囲内のみで実行されるブロックチェーンを構築できるという点で、セキュリティ的にも非常に強固なシステムを運用できる可能性があります。

また、この際に作成するロールとして、先にみたmoney_creatorのようにアセット管理だけができる役割などを作成し、さらにmoney_creatorの操作についてはMST（マルチ署名トランザクション）に設定することで、複数アカウントによる署名で初めて実際のトランザクション操作を実行可能になり、より安全なシステム運用を実現できます。

同様の考え方で、特定のアカウントに広範なデータ照会の権限を与え、監査の役割を設定したり、別のアカウントには多くのトランザクション操作を可能にすることで、管理者の役割を設定しながら必要な権限分掌が行えます。

このようにしてパーミッションとロールによる権限管理の機能と、ジェネシスブロックでの設定を組み合わせていくことで、あたかも憲法が制定されているかのようにアカウントの役割と権限の範囲を設定していくことができるのがHyperledger Irohaの大きな特徴となっています。

権限の移譲

さらにHyperledger Irohaの特徴の1つとして、アカウントに対する操作権限を特定アカウントに移譲できるようになっています。もちろんすべての権限を移譲できるわけではなく、以下の表2にある6つ（このうち1つは実際には使用できません）の権限を移譲できる権限を持っている場合には、該当の権限を他のアカウントに移譲することが可能です。

can_grant_can_set_my_quorum	自アカウントのクォーラム値を設定する権限を移譲できる権限
can_grant_can_add_my_signatory	自アカウントに署名（公開鍵）を追加する権限を移譲できる権限
can_grant_can_remove_my_signatory	自アカウントから署名（公開鍵）を削除する権限を移譲できる権限
can_grant_can_transfer_my_assets	自アカウントのアセットを他のアカウントに転送できる権限の移譲
can_grant_can_set_my_account_detail	自アカウントにアカウントディテールを設定できる権限の移譲
can_grant_can_call_engine_on_my_behalf	自アカウントの代理としてスマートコントラクトを実行できる権限の移譲

ここで表2にある権限を持っている場合には、該当の権限を他のアカウントに移譲することが可能となります。ここで、実際に移譲される権限は次の内容となっています。

can_set_my_quorum	自アカウントにクォーラム値を設定する権限
can_add_my_signatory	自アカウントに署名（公開鍵）を追加する権限
can_remove_my_signatory	自アカウントから署名（公開鍵）を削除する権限
can_transfer_my_assets	自アカウントのアセットを他のアカウントに転送できる権限
can_set_my_account_detail	自アカウントのディテール情報を設定する権限
can_call_engine_on_my_behalf	自アカウントの代理値してスマートコントラクトを実行できる権限

ここで、can_transfer_my_assetsについては”not implemented now”とされていますので、現在は非実装となっていて使用することができません。

また、アカウントディテールは前回の「Hyperledger Irohaのデータモデル」で説明していますが、アカウントに対しては詳細情報としてキー、バリュー形式で任意の値を設定していくことができます。キーとしては64文字以内の英数字（およびアンダースコア）、バリューとしては4KB以内の文字列となっていますが、アカウントに対してさらに複数の詳細情報としてキー、バリューを設定していくことができます。

この自アカウントに対する詳細情報（アカウントディテール）を設定できる権限を、他のアカウントに移譲できる権限がcan_grant_can_set_my_account_detailとなります。

アカウントの秘密鍵保護

ブロックチェーンにおいては、ワレットまたはアカウントで使用されている秘密鍵が非常に重要なものとなっています。たとえば、ビットコインの場合には、大金の入っているワレットの秘密鍵を紛失してしまったために、取り戻すことができなくなってしまったというような話題があります。

また、秘密鍵をサーバーに委託して管理するサーバーワレットと、秘密鍵をモバイルなどのクライアントで管理するクライアントワレットというお話がありますが、それぞれの特徴があります。

サーバーワレットの場合には、サーバーがハッキングされた場合に秘密鍵を盗まれてしまうリスクがあります。そのような事態が起きた場合には、盗まれた秘密鍵を使われて大金を失ってしまう可能性があります。逆にクライアントワレットの場合は、サーバーから秘密鍵が盗まれてしまうようなことはありませんが、モバイルであれば機種変更や紛失によって秘密鍵を紛失してしまう可能性があります。このような場合に備えて、パスフレーズとして幾つかの単語を控えておいて、必要な場合にはパスフレーズを使用してワレットを復元するような場合もあります。

ここでHyperledger Irohaの場合には、プライベート型またはコンソーシアム型での利用を想定し、たとえばデジタル通貨として利用している場合なら、デジタル通貨の発行元の管理者アカウントに対して、先にご紹介したアカウント署名（公開鍵）を追加・削除できる権限を移譲しておくことができます。

この場合、たとえばユーザーがモバイルの機種交換、または紛失によって秘密鍵を紛失してしまったような場合でも、デジタル通貨の発行元における本人確認を実施後に、新しいモバイルで作成した鍵と交換することが可能になります。このようにして、サーバーワレットのセキュリティリスクを回避して、モバイル上に設定した秘密鍵を安全に運用できるように工夫されています。

まとめ

今回は、Hyperledger Irohaの権限管理の仕組みとして、パーミッションとロールについてご紹介してきました。最初から用意されている権限管理の仕組みを利用することで、ビジネスでは必須となる、必要な情報を必要な人、組織のみが参照・操作できるような管理が行えます。

次回は、本連載の最後の予定として、Hyperledger Irohaの最新状況と最新版で追加された機能についてご紹介していきたいと思います。

「LITA エキスパート」のお知らせ Hyperledger Irohaをはじめとする、ブロックチェーン技術やデジタル通貨についての講習サイト「LITA エキスパート」が2021年12月16日にリリースされました。 「LITAエキスパート」は、ソラミツ株式会社から技術提携を受けてHyperledger Irohaを使用した「LITAプラットフォーム」によるデジタル通貨などを展開するDigital Platformer株式会社により運営されています。 LITAエキスパートページURLはこちら 詳細はこちらよりご確認ください。➡　ブロックチェーン、デジタル通貨・IDに関するオンライン研修プログラム「LITAエキスパート」が開講！

◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇

執筆書籍のご紹介

関連書籍のご紹介

◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇