Ocean Protocolがエンタープライズ対応のパーミッション設定をサポート
エンタープライズグレードのユースケースに対応したOceanのアクセスコントロールのセットアップを改良しました。パーミッションの適応によって、Ocean Marketのフォークでパブリッシングとコンシューマーへのアクセスを制限することができるようになりました。
1. はじめに
Ocean Protocolの大部分は、分散型のアクセスコントロールに関するものであり、その基本的なアプローチはデータトークンです。コンシューマーはリソース（ファイルなど）にアクセスするために、そのリソースのデータトークンの1.0を引き換えることができます。データトークンはERC20標準に準拠しています。
企業やその他のユーザは、アクセスを指定および管理するために、より正確な方法を必要とすることがよくあります。
例えば、医療データのユースケースを考えてみましょう。適切な資格を持つEUの研究者だけが、利用可能な医療データセットを閲覧したり、データセットそのものをダウンロードしたりすることができます。また、特定の国、コンソーシアム、地域、またはそれらの組み合わせの従業員に限定したい場合はどうしたらよいでしょうか。このような質問が、企業の共同研究者からよく寄せられました。
つまり、Oceanはこの2つのレベルで、より正確にアクセスをコントロールする方法を考えなければならないのです：
Oceanは現在、この2つをサポートしています。
この記事は以下のように構成されています：
- セクション1の残りの部分では、(1) と (2) のハイレベルなアプローチと、それがロールベースのアクセス制御 (RBAC) とデータトークンにどのように調和するかを説明します。
- セクション2では、マーケットプレイスレベルのパーミッション設定についての詳細を説明します。
- セクション3では、資産レベルのパーミッション設定についての詳細を説明します。
- セクション4は、まとめです。
1.2. マーケットレベルのパーミッションの概要
医療データのユースケースに戻りますが、適切な資格を持つEUの研究者だけがマーケットプレイスデータを利用できるようにしたい場合、誰がそのアクセス権限をどのように指定するのでしょうか？
最初のアイデアは、全ての「許可された（パーミッション）」人々のリストを持つことです。しかし、これには問題があります。ある企業が1000のデータ資産を公開し、それぞれの資産に対して全従業員のリストを持っていると想像してください。もし誰かが新しく採用されたら、1000のアセットを全て更新しなければならなくなります。
幸いなことに、もっと簡単な方法があります。アクセスは、クレデンシャルとして指定されたロールに基づいて行われます。上記の例を続けると、新入社員は入社時にクレデンシャルを取得する可能性があります。彼らはクレデンシャルを持っているので、つまり一定のパーミッションを持っています。それだけです :) このクレデンシャルベースのアプローチは、データ業界ではロールベースのアクセスコントロール（RBAC）として知られています。
マーケットレベルのパーミッションについては、Oceanは「RBACサーバー」を介してRBACを実装しています。これはユーザーの役割（クレデンシャル）に基づいて、ユーザーレベルで制限を実施するものです。
RBACサーバーは、マーケットプレイスによって実行・管理されます。したがって、このレベルでのパーミッションは、マーケットプレイスによって定義されます。
1.3 資産レベルのパーミッション：概要
医療データのユースケースに戻りますが、適切な資格を持つEUの研究者だけがデータセットをダウンロードできるようにしたい場合、どのように扱えばいいのでしょうか？
データトークンだけでは不十分で、1.0データトークンを持っている人なら誰でもそのデータにアクセスできることになります。
しかし、データトークンは、Oceanのユーザが既存の暗号インフラを活用してデータウォレット、データ交換、データユニオンなどをすぐに利用できるようにするものなので、私たちはデータトークンのアプローチを維持したいと考えるでしょう。これらの暗号ツールの作成に費やされた数千人年の努力は、データエコシステムのためのツールとして直接利用することができるのです。
これについては、次のようなメンタルモデルを描くことで、この問題を解消することができます。
18歳以上のロックコンサートに行くことを想像してみてください。18歳以上のロックコンサートに行くには、（a）コンサートチケットと（b）十分な年齢であることを示すIDの両方を提示しなければ入場できません。
このモデルをOceanに移植すると、(a)はデータトークン、(b)はクレデンシャルになります。データトークンはアクセス制御の基本です。データクンは交換可能で、あなたがお金を払って購入したもの、またはあなたに共有させたものです。これはあなたのIDとは無関係です。クレデンシャルは、あなたのアイデンティティや社会におけるあなたの役割（RBAC的なもの）の関数となります。
Oceanは、資産ベースのアクセスコントロールのためのパーミッション設定に対応しました。例えば、コンシューマーは1.0データクンとDDOの 「allow」リストにあるクレデンシャルの一つを持っている場合にのみリソースにアクセスすることができます。
Oceanには補完的な「deny」機能もあります。もしコンシューマが 「deny」リストに載っている場合、リソースへのアクセスは許可されません。
ルールは以下のように組み合わされます：
アクセス = 許可−拒否
許可 = デフォルトでは誰でも、またはエントリがある場合は許可リスト
拒否 = 拒否リスト内のエントリー
当初、サポートされるクレデンシャルはイーサリアムのパブリックアドレスのみです。公平に見て、これはクレデンシャルというより個人へのポインタですが、実装が複雑ではないので、良い出発点になります。拡張性については、Oceanのメタデータスキーマにより、W3C Verifiable Credentialなど、他のタイプのクレデンシャルを指定することが可能です。これが実装されると、アセットレベルのパーミッションも適切にRBAC化されるでしょう:)
アセットレベルのパーミッションはDDOにあり、DDOはパブリッシャーによって制御されているので、アセットレベルの制限はパブリッシャーによって制御されます。
2. マーケットプレイスレベルのパーミッションの詳細
2.1 概要
この機能は、Ocean Marketのフォークで動作するように特別に設計されており、必須ではありません。私たちは、Ocean Marketを誰もが使えるようにオープンにしておくために、Ocean Market自体でこれらを有効にしていません。フロントエンドでは、パーミッション機能は、環境変数を設定することで、マーケットのフォークで簡単に有効になります。バックエンドでは、RBACサーバーをあなたのプロジェクト専用にデプロイし、維持することができます。
マーケットプレイスがユーザーの公開、消費、閲覧の能力を制限するための主要なメカニズムは、ロールベースアクセス（RBAC）制御サーバーです。
図1は、マーケットがRBACサーバーとどのように相互作用してユーザーの権限を検証しているかを示しています。ユーザーがウォレットをマーケットに接続すると、RBACサーバーにリクエストが出され、そのユーザーがマーケットを閲覧する権限を持っているかどうかを確認します。RBACサーバーはkeycloakのマッピングからユーザーのロールを取得し（あるいはユーザーとロールのマッピングをJSONに格納することもできます）、ユーザーが閲覧に適したロールを持っている場合はマーケットに「true」と応答します。
RBACサーバーは4種類の役割を定義しています：
- 管理者
- パブリッシャー
- コンシューマー
- ユーザー
管理者/パブリッシャー
現在、管理者またはパブリッシャーの役割を持つユーザーは、何の制限もなくマーケットを使用することができます。データセットの公開、消費、閲覧が可能です。
コンシューマー
コンシューマーの役割を持つユーザーは、データセットを閲覧したり、購入したり、データトークンを交換したり、データプールに貢献したりすることができます。しかし、データセットを公開することはできません。公開ページにアクセスすると、必要な権限がないことを示すエラーが表示されます。
ユーザー
ユーザーはデータセットを閲覧・検索することはできますが、データセットを購入したり、データトークンを取引したり、データプールに貢献したり、データセットを公開することもできません。
ロールを持たないユーザー
ロールを持たないユーザーがデータマーケットを閲覧しようとした場合、どのデータセットも閲覧・検索することができません。
ウォレットが接続されていない状態
マーケットでRBACサーバーが有効な場合、ユーザーはデータセットを閲覧するためにウォレットが接続されていることが必要となります。
2.2 ユーザーとロールのマッピング
現在、RBACサーバーがユーザーのロールをイーサリアムアドレスにマッピングするために設定できる方法は2つあります。また、RBACサーバは独自のパーミッションサービスを追加できるように構築されています。
既存の方法としては、以下の2つがあります：
- Keycloack
- JSON
既にKeycloack IDおよびアクセス管理サーバーを実行している場合は、RBAC.envファイルのKEYCLOAK_URL環境変数にKeycloakサーバーのURLを追加することによって、それを使用するようにRBACサーバーを構成することが可能です。
または、まだKeycloakを使用していない場合、ユーザーロールをイーサリアムアドレスにマッピングする最も簡単な方法は、RBAC.envファイルのJSON_DATA環境変数として保存されるJSONオブジェクトにあります。このJSONオブジェクトに必要なフォーマットの例は、.example.envにあります。
ユーザーロールをEthereum Addressにマッピングする方法として、これら両方の方法を設定することが可能です。この場合、RBACサーバへのリクエストでは、どちらの認証サービスを使用するのかを指定する必要があります（例：authService、jsonまたはauthService: keycloakなど）
2.3 デフォルトのAuthサービス
さらに、RBACサーバー内で、使用するデフォルトの認証方法を指定する環境変数を設定することもできます (例: DEFAULT_AUTH_SERVICE = json)。
この変数を指定すると、RBACサーバーに送信されるリクエストにauthServiceを含める必要がなく、自動的にデフォルトの認証方法が使用されます。
2.4 デプロイメント
RBACサーバは、node.jsのexpressアプリケーションであり、プロジェクトに合わせてデプロイする必要があります。RBACサーバをセットアップする最も簡単な方法は、Docker コンテナの中に入れることです。セットアップの手順はGitHub リポジトリにあります。
3. アセットレベルのパーミッション 詳細
3.1 概要
許可リストと拒否リストは、パブリッシャーが個々のデータ資産へのアクセスを制御するための高度な機能です。
パブリッシャーは、承認されたユーザーだけがアクセスできるようにアセットを制限したり（許可リスト）、特定のユーザー以外がアクセスできるようにアセットを制限したり（拒否リスト）することが可能です。
一般的なアイデアは、アセットのDDOに「許可」と「拒否」リストを持つことで、各エントリーはイーサリアムアドレスになります。Ocean Providerはこの情報を使って、アクセスを許可するかどうかを決定します。
Ocean Marketでは、許可リストと拒否リストはデフォルトでは有効ではありません。Ocean Marketのフォークでこの機能を有効にするには、環境変数を編集する必要があります。許可リストと拒否リストを有効にするには、Ocean Marketのフォークの.envファイルに以下の環境変数を追加します。GATSBY_ALLOW_ADVANCED_SETTINGS=”true “を追加します。
3.2 高度な設定
高度な設定を有効にすると、資産の詳細ページに新しい「高度な設定の編集」セクションが表示されます。許可リストや拒否リストを使用するには、データ資産に移動して「詳細設定」をクリックする必要があります。
3.3 許可リストへのアドレスの追加
ユーザーを許可リストや拒否リストに追加するためには、まずそのユーザーのイーサリアムアドレスを知っておく必要があります。そこで、入力欄にユーザーのアドレスを入力し、「ADD」ボタンをクリックします。
3.4 許可リストまたは拒否リストからのユーザの削除
ユーザーを許可リストまたは拒否リストから削除するには、そのユーザーのEthereumアドレスの横にある十字をクリックすることができます。
3.5 許可リストまたは拒否リストへの変更の提出
詳細設定ページで行った変更は、トランザクションで送信し、署名する必要があります。これを行うには、まず「SUBMIT」をクリックします。
3.6 Metamaskのトランザクションに署名する
次に、Metamaskまたはお好みのウォレットで取引に署名する必要があります。署名がうまくいかない場合は、Metamaskの設定方法についてをご参照ください。
許可・拒否リストの更新が完了すると、成功のメッセージが表示されます。
4. まとめ
Ocean Protocolは、分散型アクセス制御のためのツールです。基本的なアプローチはデータトークンで、コンシューマは1.0データトークンでリソースにアクセスすることができます。
企業との共同研究者からのフィードバックに基づいて、より詳細なパーミッション設定機能を導入しています：
- マーケットプレイスフロントエンドでの閲覧、公開など、マーケットプレイスレベルのパーミッション設定が可能です。これは、RBACサーバーを介して実装されおり、パーミッションは、マーケットプレイスオペレーターによって制御されます。
- 資産レベルのきめ細かいパーミッションは、資産そのものを消費するためのパーミッションです。DDO の「allow」と「deny」項目によって指定され、パーミッションはパブリッシャーによって制御されます。
この記事に貢献してくれた皆さん、そして特にここで説明している技術の実現に取り組んでくれた方々に感謝します。特にOceanのコアソフトウェアチームと、この機能を形作る上でとても貴重な存在である我々の企業コラボレーターに感謝します。
Ocean Protocolについて
Ocean Protocolのミッションは、世界に広がるWeb3データエコノミーを始動させ、データの所有者が持つべき権利を取り戻し、人々がデータから本来得られる価値をもたらす世界を構築する事です。
データは新たな資産クラスであり、Ocean Protocolはその価値を引き出します。データの所有者と消費者は、Ocean Marketアプリを使用して、安全でプライバシーが守られた方法でデータ資産を公開、発見、消費できるようになります。
Ocean Protocolのデータトークンは、データを「データ資産」に変えます。これによりウォレットや取引所、その他のDeFiツールを活用して、データウォレット、データ交換、データ協同組合を実現します。プロジェクトは、OceanライブラリやOCEANを自分のアプリで使用し、Web3データエコノミーの推進に貢献していきます。
トークンとしてのOCEANは、データへのステークやデータの売買、ガバナンス投票などに使用されます。トークンの供給は、短期的な成長と長期的な持続性を促進するために時間をかけて分配され、利用量の増加に応じて増加するように設計されています。
詳しくはoceanprotocol.comをご覧ください。
Website | Twitter | Telegram｜Discord｜Blog｜YouTube |
日本版Twitter | 日本版Telegram
