JP6872015B2 - ブロックチェーン台帳を用いた機密データへのアクセスのセキュア化 - Google Patents

Description

関連出願の相互参照
本願は、２０１８年５月２９日に出願された米国特許出願第１５／９９１，２０４号に基づく優先権を主張し、この米国出願の開示を本明細書に引用により援用する。

分野
本開示の実施形態は、概してブロックチェーン台帳を用いて機密データへのアクセスをセキュアにすることに関する。

背景
企業体や政府のような組織またはそれ以外の組織は、相乗効果を高めるため、ビジネスニーズに応えるため、そうでなければ目標を達成するために、互いに協力しようとしてきた。しかしながら、極秘情報に関するリスクがあるので、組織は特定の種類のデータの共有を避けてきた。データ保存システムは、極秘データのセキュア化という点では改善されているものの、依然として組織は極秘データにアクセスする個人について懸念を抱いている。昨今のデータ漏洩は、極秘データへのアクセスを複数のエンティティが共有している場合、アクセス許可管理について透明性が必要であることを示している。

概要
本開示の実施形態は、概して、関連技術を実質的に改善する、ブロックチェーン台帳を用いて機密データへのアクセスをセキュアにするためのシステムおよび方法に関する。

第２のエンティティの代理としての第１のエンティティからの、アクセス許可の更新を、受け付けることができ、この更新は、機密データストアへのアクセス許可を変更することができる。この更新の妥当性を確認するスマートコントラクトを呼び出すことができる。ブロックチェーンコミュニティの合意形成がなされると、第２のエンティティに対するアクセス許可の更新を実行することができる。ブロックチェーンコミュニティは、機密データストアへのアクセスを共有する複数の異なる組織であってもよく、更新は、ブロックチェーンコミュニティに対するアクセス許可を格納するブロックチェーン台帳に追加することができる。

実施形態の特徴および利点は、以下の説明に記載されている、またはこの説明から明らかであろう、または本開示の実施によってわかる場合もある。

さらに他の実施形態、詳細、利点、および変形は、添付の図面との関連で考慮されるべき好ましい実施形態の以下の詳細な説明から明らかになるであろう。

実施形態の一例に係るブロックチェーン台帳を用いて機密データへのアクセスをセキュアにするためのシステムを示す図である。 実施形態の一例に係るブロックチェーン台帳システムに作動的に結合されたコンピューティングデバイスのブロック図を示す。 実施形態の一例に係るブロックチェーン台帳を用いてセキュアなデータストアから機密データを取り出すためのフロー図を示す。 実施形態の一例に係るセキュア属性データモデルを示す図である。 実施形態の一例に係るブロックチェーン台帳およびスマートコントラクトを用いる機密データへのアクセスのアクセス許可の更新のフロー図を示す。 実施形態の一例に係るブロックチェーン台帳を用いて機密データへのアクセスをセキュアにすることを示す図である。

詳細な説明
実施形態は、ブロックチェーン台帳を用いて機密データへのアクセスをセキュアにする。ブロックチェーン台帳は、暗号機能を用いてセキュアにされた、接続された記録またはブロックを含む、分散型電子台帳であってもよい。台帳内の各ブロックが前のブロックの暗号ハッシュを含む、ブロックチェーンの実装は、再帰的となり得る。したがって、ブロックチェーン台帳は、たとえば、最初のブロック（またはトランザクション）から最新のブロック（またはトランザクション）まで、この台帳が表す基礎となるブロックまたはトランザクションに対し、透明性を提供することができる。

実施形態は、ブロックチェーン台帳を用いて機密情報に対するアクセス許可を管理する。たとえば、現実世界では、状況によって、機密情報へのアクセスを複数の組織が共有する必要がある。これらの状況は、中央政府のような団体またはエンティティが極秘情報または機密情報であると特定した情報を、国家セキュリティサービスのような団体またはエンティティにサービスを提供するために、共有することを含み得る。それ以外の状況でも、機密または専有情報などに依拠する組織間の合弁事業のように、共有される機密情報から同様の利益を享受することができる。

いくつかの実施形態において、各組織におけるアイデンティティ、たとえば個人には、さまざまなレベルの機密情報へのアクセスを付与することができる。たとえば、機密情報をデータベースに格納し、この機密情報に、異なるセキュリティパラメータ（たとえば、セキュリティ分類レベル、タイトル、プロジェクト名、リリースなど）を対応付ける（keyed）ことができる。各組織のアイデンティティに対するアクセス許可は、個々のアクセス許可に対応するセキュリティパラメータが対応付けられた（keyed）機密情報へのアクセスを許可することができる。

実施形態は、ブロックチェーン台帳を用いて、アクセス許可およびアクセス許可の更新を管理することにより、各種組織のさまざまなアイデンティティに対し、機密情報へのアクセスをセキュアにする。たとえば、機密情報へのアクセスを共有する各種組織は、ブロックチェーンコミュニティのメンバーを表し得る。ある組織が、そのアイデンティティのうちの１つに対するアクセス許可の更新を要求した場合、一連のアクションをトリガする（たとえばスマートコントラクトを呼び出す）ことによってトランザクションを実行することができる。要求している組織／アイデンティティは、この変更を、ブロックチェーンコミュニティに対して申し出ることができる。ブロックチェーンコミュニティが合意に達すると、スマートコントラクトはこの変更を実行することができる。上記アイデンティティに対するアクセス許可の変更を反映するトランザクションまたはブロックを、ブロックチェーンに追加することができる。

したがって、ブロックチェーン台帳は、コミュニティメンバー（たとえば参加している組織）のアイデンティティに対する、最新の透明なアクセス許可を、格納することができる。いくつかの実施形態において、あるアイデンティティが機密情報へのアクセスを要求すると、データベースは、要求しているアイデンティティに対する最新のアクセス許可を取り出すために、ブロックチェーンにクエリすることができる。次に、これらのアクセス許可を用いて、対応する機密情報をデータベースから取り出すことにより、確実に、最新の透明なアクセス許可を用いて、アイデンティティがアクセスを許可された機密情報のみを取り出すことができる。

次に、その例が添付の図面に示されている本開示の実施形態について詳しく述べる。以下の詳細な説明には、本開示が十分に理解されるよう、数多くの具体的な詳細が記載されている。しかしながら、本開示はこれらの具体的な詳細がなくても実施し得ることは、当業者には明らかであろう。他の場合では、周知の方法、手順、コンポーネント、および回路は、実施形態の側面を不必要に曖昧にすることを避けるために、詳細には説明していない。可能な限り同様の参照番号が同様の要素に使用される。

図１は、ある実施形態に係るブロックチェーン台帳を用いて機密データをセキュアにするためのシステムを示す。システム１００は、エンティティ１０２と、パートナー１０４および１０６と、ブロックチェーン１０８と、ブロックチェーンコピー１１０および１１２と、データベース１１４とを含む。いくつかの実施形態において、エンティティ１０２は、データベース１１４に格納された機密情報にアクセスできる組織であってもよい。たとえば、データベース１１４は、仮想プライベートデータベース（Virtual Private Database）（「ＶＰＤ」）プロトコル（たとえばＯｒａｃｌｅ（登録商標）ラベル・セキュリティ（Label Security））を実装するＯｒａｃｌｅ（登録商標）データベースのような仮想プライベートデータベースであってもよい。データベース１１４に格納されたデータには、エンティティ１０２のアイデンティティ（たとえば認証された個人）が、この個人に対する管理されたアクセス許可に基づいて、アクセスすることができる。

いくつかの実施形態において、パートナー１０４および１０６も、データベース１１４に格納された機密情報へのアクセスを共有する組織であってもよい。たとえば、エンティティ１０２は、パートナー１０４および１０６との合弁事業に参加する組織であってもよく、この場合の各組織は、データベース１１４に格納されたさまざまなレベルの機密情報にアクセスすることができる。エンティティ１０２ならびにパートナー１０４および１０６は各々、特定のセキュリティパラメータによってセキュアにされたデータベース１１４の特定のデータにアクセスするように構成されたアクセス許可を有する、対応するアイデンティティ（たとえば個人）を有し得る。

エンティティ１０２ならびにパートナー１０４および１０６各々に対応付けられたアイデンティティのセットに対するアクセス許可は、ブロックチェーン台帳１０８ならびにブロックチェーン台帳コピー１１０および１１２を用いて管理することができる。たとえば、アイデンティティのセットに対するアクセス許可の変更は、ブロックチェーン台帳１０８により、透明かつ変更不能に表すことができる。いくつかの実施形態において、ブロックチェーン台帳１０８は、上記アイデンティティのセットに対するアクセス許可の初期セットを含み得る。また、ブロックチェーン台帳１０８に追加されたブロックは、アクセス許可の初期セットに対する変更を表す。このような実装形態において、ブロックチェーン台帳１０８は、アイデンティティのセットに対する最新のアクセス許可を格納することができ、一方で、これらのアイデンティティに対するアクセス許可のすべての変更のトランザクション履歴を格納する。いくつかの実施形態において、ブロックチェーン台帳１０８は中央台帳を管理し、ブロックチェーン台帳コピー１１０および１１２はこの中央台帳のコピーを格納する。

実装形態の一例において、エンティティ１０２はアイデンティティＡおよびＢを含み得る。アイデンティティＡは、アイデンティティＢのためにアクセス許可の変更を要求することができる。この変更は、ブロックチェーンコミュニティ（たとえばエンティティ１０２ならびにパートナー１０４および１０６）に対して申し出ることができる。ブロックチェーンコミュニティが合意に達するまたはこの変更を承認すると、アイデンティティＢのために要求されたアクセス許可の変更を表すブロックを、ブロックチェーン台帳１０８に追加することができる。

ある実施形態において、アイデンティティＢが機密情報へのアクセスを要求すると、データベース１１４は、ブロックチェーン台帳１０８によって格納されたアイデンティティＢのための最新のアクセス許可を取り出すことができる。アクセス許可のこのセキュアで透明な管理により、確実に、ブロックチェーンコミュニティが許可したセキュアな情報に対するアクセスのみをアイデンティティＢに付与することができる。

いくつかの実施形態において、エンティティ１０２は、Ｏｒａｃｌｅ（登録商標）データベース内にデータベース１１４を構成し、格納されているデータをセキュアにする同意されたセキュリティモデルを生成することができる。このモデルは、リリーサビリティ・マーキング（releasability markings）、クリアランス、プロジェクト名などを含み得る。次に、システム内に格納されたデータを、Ｏｒａｃｌｅ（登録商標）ラベル・セキュリティ、ＶＰＤ、および／またはデータ・リリース・アクセレレレータ（Data Release Accelerator）（たとえば国家セキュリティの利用者向け）を用いて制御する。次に、エンティティ１０２はブロックチェーンメンバーシップにおける信頼できる各当事者（たとえばパートナー１０４および１０６）との間にブロックチェーン１０８を構成することができ、ブロックチェーンとやり取りする／ブロックチェーンにアクセスすることができる有効なユーザについて、メンバーの同意を得ることができる。いくつかの実装形態において、個々のユーザがユーザのセキュリティ属性を追加または変更できるようにするスマートコントラクトをブロックチェーン上に生成することができる。

実施形態は、過去に実現されたシステムに勝る、複数の技術的利点を実現する。たとえば、ブロックチェーンを用いて共有機密情報に対するアクセス許可を管理し、格納し、取り出す実施形態は、機密情報を共有するメンバー組織間の透明性を高めることができ、それにより、データ共有の採用を促すことができる。ブロックチェーンの変更は、変更不能に格納されるので、アクセス許可を効率的な監査に利用することができる。ブロックチェーンストレージの透明性および変更不能という性質により、データを共有するパートナーは、合意されたセキュリティコントロールが有効に運営されることを保証することができ、データ共有の採用がさらに促進される。

加えて、ユーザ／アイデンティティにアクセスを許可する前にブロックチェーンから直接アクセス許可を取り出すことにより、確実に、最新の（かつ透明に管理される）アクセス許可を使用する。いくつかの実装形態は、セキュアで軽量のアクセス許可／セキュリティ属性モデル（たとえばＯｒａｃｌｅ（登録商標）ラベル・セキュリティ）を活用することにより、ブロックチェーンにとって計算上効率的なアクセス許可を提供する。たとえば、アクセス許可が大きく扱いにくい場合、直ちに、ブロックの追加時に、より困難な計算上の問題を生じさせる、大きなブロックチェーンとなる可能性がある。

加えて、分散型でセキュアな暗号化された記録の台帳を使用することにより、中央データベースを利用する既存の実装形態において頻繁に生じる漏洩のリスクを軽減する。たとえば、アクセス許可の透明な管理によってトレーサビリティが実現され、コミュニティは、信頼性のないアクター／アイデンティティからのアクセスをブロックすることができる。実施形態は、属性に基づくアクセスコントロール（attributes based access control）（「ＡＢＡＣ」）を拡張することにより、機密データへのアクセスを管理するための、よりセキュアで技術的に改善された実装形態を提供する。

図２は、実施形態に係るコンピュータサーバ／システム２１０のブロック図である。図２に示されるように、システム２１０は、プロセッサ２２２およびメモリ２１４といったシステム２１０の各種コンポーネント間で情報を伝達するように構成された、バスデバイス２１２および／またはその他の通信機構を含み得る。加えて、通信装置２２０が、ネットワーク（図示せず）を介してプロセッサ２２２から別のデバイスに送信されるデータをエンコードしネットワークを介して別のシステムから受信したプロセッサ２２２に対するデータをデコードすることにより、プロセッサ２２２とその他のデバイスとの接続性を有効にすることができる。

たとえば、通信装置２２０は、無線ネットワーク通信を提供するように構成されたネットワークインターフェイスカードを含み得る。赤外線、無線、Bluetooth（登録商標）、Ｗｉ−Ｆｉ（登録商標）、および／またはセルラー通信を含む、さまざまな無線通信技術を使用することができる。これに代えて、通信装置２２０は、イーサネット（登録商標）接続といった有線ネットワーク通信を提供するように構成されてもよい。

プロセッサ２２２は、システム２１０の計算および制御機能を実行するために１つ以上の汎用または専用プロセッサを含み得る。プロセッサ２２２は、マイクロ処理デバイスのような１つの集積回路を含んでいてもよく、または、プロセッサ２２２の機能を実現するために協働する複数の集積回路装置および／または回路基板を含んでいてもよい。加えて、プロセッサ２２２は、メモリ２１４に格納されている、オペレーティングシステム２１５、アクセス許可マネージャ２１６、およびその他のアプリケーション２１８といったコンピュータプログラムを実行し得る。

システム２１０は、情報と、プロセッサ２２２が実行する命令とを格納するためのメモリ２１４を含み得る。メモリ２１４は、データを取り出し、提示し、修正し、格納するための各種コンポーネントを含み得る。たとえば、メモリ２１４は、プロセッサ２２２によって実行されると機能を提供するソフトウェアモジュールを格納してもよい。これらのモジュールは、システム２１０に対してオペレーティングシステム機能を提供するオペレーティングシステム２１５を含み得る。これらのモジュールは、オペレーティングシステム２１５およびアクセス許可マネージャ２１６ならびにその他のアプリケーションモジュール２１８を含み得る。オペレーティングシステム２１５は、システム２１０に対してオペレーティングシステム機能を提供する。アクセス許可マネージャ２１６は、ブロックチェーン上でアクセス許可を格納および／または管理するための機能を提供することができる、または、本開示の任意のその他の機能をさらに提供してもよい。場合によっては、アクセス許可マネージャ２１６を、インメモリ構成として実現することができる。

非一時的なメモリ２１４は、プロセッサ２２２がアクセスできるさまざまなコンピュータ読取可能媒体を含み得る。たとえば、メモリ２１４は、ランダムアクセスメモリ（「ＲＡＭ」）、ダイナミックＲＡＭ（「ＤＲＡＭ」）、スタティックＲＡＭ（「ＳＲＡＭ」）、読出専用メモリ（「ＲＯＭ」）、フラッシュメモリ、キャッシュメモリ、および／または任意のそれ以外のタイプの非一時的なコンピュータ読取可能媒体を、任意に組み合わせたものを含み得る。

プロセッサ２２２はさらに、バス２１２を介して液晶ディスプレイ（「ＬＣＤ」）等のディスプレイ２２４に結合される。キーボード２２６およびコンピュータマウス等のカーソルコントロール装置２２８がさらに通信装置２１２に結合されて、ユーザとシステム２１０との間のインターフェイスを可能にする。

いくつかの実施形態において、システム２１０は、より大きなシステムの一部であってもよい。したがって、システム２１０は、さらに他の機能を含むために１つ以上の他の機能モジュール２１８を含み得る。他のアプリケーションモジュール１１８は、たとえば、Ｏｒａｃｌｅ（登録商標）クラウドに埋め込まれたエンゲージメントエンジン（「ＥＥ」）の各種モジュール、または、Ｏｒａｃｌｅ（登録商標）ブロックチェーンクラウドサービスのモジュールを含み得る。データベース２１７は、モジュール２１６および２１８のための集中ストレージ（centralized storage）を提供するためにバス２１２に結合される。データベース２１７は、論理的に関連付けられた記録またはファイルの一体化されたコレクションにデータを格納することができる。データベース２１７は、図１のデータベース１１４、オペレーショナルデータベース、分析データベース、データウェアハウス、分散型データベース、エンドユーザデータベース、外部ベータベース、ナビゲーションデータベース、インメモリデータベース、ドキュメント指向データベース、リアルタイムデータベース、リレーショナルデータベース、オブジェクト指向データベース、Ｈａｄｏｏｐ分散型ファイルシステム（「ＨＦＤＳ」）、ＮｏＳＱＬデータベース、または当該技術において周知の任意のその他のデータベースと同様のものであってもよい。

単一のシステムとして示されているが、システム２１０の機能は分散型システムとして実現されてもよい。たとえば、メモリ２１４およびプロセッサ２２２を、全体としてシステム２１０を表す複数の異なるコンピュータに分散させてもよい。一実施形態において、システム２１０は、あるデバイス（たとえばスマートフォン、タブレット、コンピュータなど）の一部であってもよい。

ある実施形態において、システム２１０は、デバイスから分離していてもよく、このデバイスに対して上記機能を遠隔から提供してもよい。さらに、システム２１０の１つ以上のコンポーネントが含まれていなくてもよい。たとえば、ユーザまたはコンシューマデバイスとしての機能の場合、システム２１０は、プロセッサとメモリとディスプレイとを含むスマートフォンまたはその他の無線装置であってもよく、図２に示される他のコンポーネントのうちの１つ以上を含まず、図２に示されていない追加のコンポーネントを含む。

いくつかの実施形態において、システム２１０または同様のシステムを、ブロックチェーンコミュニティメンバーによって実現することにより、ブロックチェーン台帳トランザクションを処理することができる。たとえば、システム２１０を用いて、ブロックチェーン台帳に対するブロックの追加に関連する暗号関数を実行してもよく、または、その他の関連するブロックチェーン暗号機能を実行してもよい（たとえば、proof of workに関連する計算、妥当性確認、合意など）。たとえば、システム２１０は、Ｏｒａｃｌｅ（登録商標）ブロックチェーンクラウドサービス、または任意の他のクラウドサービスおよび／またはブロックチェーンサービスの機能を実現することができる。

図３は、実施形態の一例に係るブロックチェーン台帳によってセキュアにされた機密データを取り出すフローを示す。フロー３００は、ユーザ３０２と、サービス３０４と、データベース３０６と、ブロックチェーン３０８とを含む。ユーザ３０２は、ブロックチェーンコミュニティの一部である組織（たとえば図１のエンティティ１０２）のユーザであってもよい。サービス３０４は、アイデンティティ管理サービス、データベースクエリサービス、ウェブサービスなどを含む、各種実施形態を実現するのに適したソフトウェアサービスを含み得る。サービスの例は、各種ハイパーレジャーブロックチェーンプロジェクト（たとえばハイパーレジャーファブリック（Hyperledger fabric））および／またはＯｒａｃｌｅ（登録商標）ブロックチェーンクラウドサービスのような、各種ブロックチェーンおよび／または企業データソリューションによって提供することができる。データベース３０６は、図１のデータベース１１４または図２のデータベース２１７と同様であってもよく、ブロックチェーン３０８は、図１のブロックチェーン台帳１０８と同様であってもよい。

ある実施形態において、ユーザ３０２は、サービス３０４を用いてアイデンティティ認証を実行することができる。たとえば、サービス３０４のうちの１つは、ユーザ３０２に関連付けられた組織（たとえば図１のエンティティ１０２）のためのアイデンティティ管理システムを含み得る。ユーザ３０２のアイデンティティを認証することができるアイデンティティ管理システムの一例は、Ｏｒａｃｌｅ（登録商標）アイデンティティクラウドサービス（「ＩＤＣＳ」）である。いくつかの実施形態において、ある組織は、米国特許第９，８３８，３７６号に記載のような、クラウドベースのユーザ認証システムを実現することができる。任意のその他適切なアイデンティティ管理システムを実現することもできる。

ユーザ３０２のアイデンティティが認証されると、このユーザは、機密情報を求めてデータベース３０６にクエリするために、サービス３０４を活用することができる。それに応じて、データベース３０６は、たとえば以前のユーザの認証に基づいて、ユーザ３０２の妥当性確認を行うことができる。ある実施形態において、アイデンティティ管理サービスは、トークンのような、妥当性確認に使用できる身分証明を提供することができる。たとえば、ＩＤＣＳサービスは、データベース３０６といったその他のさまざまなシステムがユーザのアイデンティティの妥当性確認を行えるよう、ユーザ３０２の１つ以上のトークンを提供することができる。

ユーザ３０２のアイデンティティの妥当性が確認されると、データベース３０６は、妥当性が確認されたアイデンティティに対するアクセス許可またはセキュリティ属性を、ブロックチェーン３０８から取り出すことができる。いくつかの実施形態において、ブロックチェーン３０８は、キーに基づく台帳とみなすことができ、各アイデンティティはこの台帳上のキー（またはアドレス）を有する。このような実施形態において、データベース３０６は、ブロックチェーン３０８上のユーザ３０２のキーの値を取り出すことができる。ブロックチェーン３０８のこの場所のデータはユーザ３０２のアイデンティティのセキュリティ属性に対応するからである。

いくつかの実施形態において、ブロックチェーン３０８は、ブロックチェーンの現在の「実世界の状態（state of the world）」を格納するデータベースを（たとえばデータベース３０６の機密データストアとは別に）含み得る。この実世界の状態は、トランザクションが台帳に追加されるたびに、更新される。たとえば、このデータベースは、ＮｏＳＱＬデータベースであってもよく、やや複雑なクエリを実行することによってデータを取り出すことができる。

ある実装形態において、ブロックチェーン３０８の「実世界の状態」は、ブロックチェーン３０８がアクセス許可を管理する対象であるアイデンティティに対する最新のアクセス許可を含み得る。このような実装形態において、最新のアクセス許可をこのデータベースから取り出して、データベース３０６に格納されている機密データにアクセスするために使用することができる。このような実施形態において、データベースは、機密データに対する最新のアクセス許可を格納するために使用されるが、ブロックチェーン３０８はなおも、変更不能の記録を保持し、これらのアクセス許可のためのトランザクションの実行を管理する。よって、ブロックチェーン３０８はなおも、透明性を提供し、機密データへのアクセスの管理について定められたポリシーが実現されていることを保証する。

図３に示されるように、属性モデルを用いることにより、アイデンティティに対するアクセス許可を定めることができる。示されているアクセス許可属性モデルの例（Example attribute model）において、アイデンティティは、「シークレット」クリアランス（"SECRET" clearance）を有し、ブリーフィング（briefing）「Ａ」、「Ｂ」、および「Ｃ」に対してクリアされ、「麻薬中毒更生会（narcotics）」および「テロリズム（terrorism）」グループに属し、「lighting」および「thunder」プロジェクトに対応付けられている。

図４は、実施形態に係るセキュアなデータの属性モデルを示す。たとえば、アイデンティティについて図３に示されるアクセス許可属性モデルと同様に、セキュアなデータも同様にセキュリティ属性４０２に対応付ける（keyed）ことができる。セキュリティ属性４０２は、ブリーフィングと同様であってもよい「タイトル」と、「分類」と、「プロジェクト」と、「リリース」とを含み得る。データベース３０６に格納された機密データへのアクセスに関しては、１つの機密データをセキュアにするセキュアにされた属性に対応するアクセス許可を有するユーザ／アイデンティティに対し、データへのアクセス／データの取り出しを許可することができる。

たとえば、いくつかの実装形態は、セキュアなデータをリレーショナルデータテーブルに格納する。テーブル、これらのリレーショナルデータテーブルの行および／または列は、データへのアクセスを制限する異なるセキュリティレベルを有し得る。ある実施形態において、セキュリティ属性の第１のミックスを用いて第１のテーブル（たとえば行および／または列のセット）をセキュアにし、セキュリティ属性の第２のミックスを用いて第２のテーブルをセキュアにしてもよい。さらに、いくつかの実施形態は、これらのデータテーブルの列／行レベルで、セキュリティ属性の各種ミックスを含む。したがって、対応するセキュリティ属性を有するアイデンティに対し、第１のテーブルからデータを取り出す許可を与えるが第２のテーブルからデータを取り出す許可は与えないようにしてもよく、いくつかの実装形態においては、第１のテーブルの特定の行／列からデータを取り出す許可を与えるが第１のテーブルの他の行／列からデータを取り出す許可は与えないようにしてもよい。

いくつかの実施形態において、データベース３０６は、Ｏｒａｃｌｅ（登録商標）ラベル・セキュリティを実現するＶＰＤであってもよい。たとえば、データベース３０６は、ブロックチェーンコミュニティのメンバーが同意したセキュリティモデルを用いてデータを格納するように構成することができる。たとえば、セキュリティモデルは、図４に示される、リリースマーキング、クリアランスレベル、プロジェクト名、その他のセキュリティ属性などを含み得る。格納されているデータに対するアクセスを、他のＯｒａｃｌｅ（登録商標） ＶＰＤおよびラベル・セキュリティの特徴を用い、場合によってはデータ・リリース・アクセレレータを用いて、セキュアにすることができる。

図３に示される、取り出されたセキュリティ属性またはアクセス許可を考慮して、ユーザ３０２の認証され妥当性が確認されたアイデンティティは、ユーザ３０２のアイデンティティに対するアクセス許可と、サブセット４０４のセキュリティ属性との間の対応関係に基づいて、サブセット４０４のセキュリティ属性に対応付けられた（keyed）情報を取り出すことを許可される。アイデンティティに対するアクセス許可および／または機密データのセキュリティ属性は、同様に構成することができる、または、いくつかの実施形態では異なっていてもよい。

加えて、アクセス許可／セキュリティ属性は、高いレベルのセキュリティクリアランス、より高いレベルのセキュリティクリアランス、最高レベルのセキュリティクリアランスといった、階層構造を含み得る。この例において、セキュリティクリアランスが最高レベルであるアクセス許可は、最高レベル、より高いレベル、および高いレベルのセキュアデータへのアクセス／データの取り出しを許可され、セキュリティクリアランスがより高いレベルであるアクセス許可は、より高いレベルおよび高いレベルのセキュアデータへのアクセス／データの取り出しを許可され、セキュリティクリアランスが高いレベルであるアクセス許可は、高いレベルのセキュアデータのみへのアクセス／データの取り出しを許可される。その他のアクセス許可／属性も同様に、階層機能を実現することができる。

再び図３を参照して、返されたユーザ３０２のアイデンティに対するアクセス許可に対応するセキュリティ属性が対応付けられた（keyed）、要求された機密データを、ユーザ３０２／サービス３０４に返すことができる。たとえば、ユーザ３０２／サービス３０４が、データベース３０６からセキュアなデータのセットを取り出すことを要求した場合、データベース３０６によって返されるセキュアなデータは、ブロックチェーン３０８から返された、ユーザ３０２の認証済のアイデンティティに対するアクセス許可に対応する要求されたデータであろう。

図５は、ある実施形態に係るアイデンティティに対するアクセス許可を更新するフローを示す。フロー５００は、ユーザ５０２および５０４（たとえばそれぞれボブおよびジェーン）と、スマートコントラクト５０６と、アイデンティティサービス５０８と、ブロックチェーン５１０と、更新されたブロックチェーン５１２とを含む。

ある実施形態において、ユーザ５０２および５０４は、本開示において説明する、ブロックチェーンコミュニティの一部である第１の組織と関係があるユーザであってもよい。ユーザ５０４に対するアクセス許可は、たとえばユーザの仕事の割当の変更に基づいて、または何らかのその他適切な状況に基づいて、時折更新される場合がある。よって、ユーザ５０２が、ユーザ５０４のアクセス許可の変更を要求する場合がある。この例において、たとえばアイデンティティサービス５０８内で、第１の組織と関係があるユーザに対するアクセス許可を変更する特定の権限が、ユーザ５０２に委任されてもよい。その他の実施形態において、ユーザ５０４はこれらのアクセス許可の更新を要求することができ、フロー５００と同様のフローに従うことができる。

一例としてのアイデンティティサービス５０８は、本開示においてさらに説明するＯｒａｃｌｅ（登録商標） ＩＤＣＳである。この例において、アイデンティティサービス５０８は第１の組織に属することができるが、さまざまな組織（たとえば、ブロックチェーンコミュニティ内の第１の組織およびその他の組織）のアイデンティティを管理するアイデンティティサービスのような、その他の構造も同様に実現することができる。

ある実施形態において、ユーザ５０２がユーザ５０４のアクセス許可の更新を要求するために、スマートコントラクトサービスを呼び出して、最終的に更新を実現する一連のアクションであってもよいスマートコントラクト５０６を実行することができる。スマートコントラクトは、アクションの結果に基づいて実行のフローに従う、ソフトウェアが実行する半自動化された一連のアクションであるとみなすことができる。ソフトウェアが実行するスマートコントラクトの一例は、合意形成アクションを含み得る。たとえば、１つのソフトウェアコードの実行等の特定のアクションを実施すべきであることに対し、コミュニティは、コミュニティのうちの大多数がこのアクションに同意すれば、同意してもよい。スマートコントラクトは、アクションを実施すべきか否かについてコミュニティから投票またはその他の表示を電子的に受けてもよく、コミュニティの大半が同意すれば、スマートコントラクトは、アクション（たとえば１つのコード）を自動的に実行することができる。

スマートコントラクト５０６は先ず、アイデンティティサービス５０８を用いて、ユーザ５０２および５０４（たとえばボブおよびジェーン）のアイデンティティを認証することができる。ある実施形態において、スマートコントラクト５０６は次に、ボブであるユーザ５０２が、ジェーンであるユーザ５０４に対するアクセス許可を変更する権限を有しているか否かを判断することができる。いくつかの実施形態において、アクセス許可を変更する権限は、要求された変更に基づいていてもよい。

たとえば、ユーザ５０２は、アイデンティティサービス５０８および第１の組織内においてある役割を有していてもよい。要求された変更が、必須アクセス制御（mandatory access control）の変更（たとえばセキュリティクリアランスレベルの変更）等の第１のタイプであれば、ユーザ５０２はユーザの役割が第１のタイプの変更を許可する役割である場合に（たとえば第１の組織内のセキュリティ責任者）、この変更を実施することを許可される。要求された変更が、任意アクセス制御（discretionary access control）の変更（たとえばグループまたはプロジェクトの変更）等の第２のタイプであれば、ユーザ５０２はユーザの役割が第２のタイプの変更を許可する役割である場合に（たとえば第１の組織内のグループ／プロジェクトに対する管理者）、この変更を実施することを許可される。いくつかの実施形態において、組織／アイデンティティ管理システムは、あるユーザが組織の（他の）ユーザに対するアクセス許可の変更をいつ認められるかを決定する追加のビジネスロジック／ルールを取り入れることもできる。

ユーザ５０２および５０４の認証が正常に完了し、要求された、ユーザ５０４に対するアクセス許可の特定の変更を、ユーザ５０２が実施することが許可されると、スマートコントラクト５０６は、ブロックチェーン５１０に対してこの変更を申し出ることができる。先に述べたように、ブロックチェーン５１０は、複数のブロックチェーンコミュニティメンバー（たとえば組織）を含み得る。ブロックチェーンコミュニティのメンバーは、申し出があった変更の妥当性を確認することができ、ブロックチェーンで合意に達すると、ブロックをブロックチェーン５１０に追加することにより、更新されたブロックチェーン５１２を生成することができる。こうして、フロー５００は、ブロックチェーンコミュニティのメンバーに属するユーザに対するアクセス許可（たとえば共有されるセキュアなデータにアクセスするために使用される）の変更を表す記録からなる、変更不能で透明な台帳を、生成したことになる。

いくつかの実施形態において、ブロックチェーン５０８の合意形成は、実用ビザンチン障害耐性（Practical Byzantine Fault Tolerance）（「ＰＢＦＴ」）アルゴリズム、権威証明（Proof of Authority）（「ＰｏＡ」）および／または消費時間証明（Proof of Elapsed Time）（「ＰｏＥＴ」）アルゴリズムのうちの１つ以上を用いて得ることができる。ハイパーレジャーファブリックによって実現されるアルゴリズムのようなＰＢＦＴアルゴリズムは、同意したノード間の合意を提供することができる。ＰＢＦＴの１つの利点は、悪意のあるノードの悪意を緩和できる点であり、これは、信頼性が低い許可台帳において有用となり得る、または、悪意のあるコードによってブロックチェーンコミュニティ内の組織に障害が発生するリスクから守るのに有用となり得る。ＰｏＡが有する指定ノードは、十分な（たとえば大半の）指定ノードが同意すれば、トランザクションを更新する。これは、ノードのうちのいくつかは権限を有するがその他のノードは権限を有しない許可された台帳において有用となり得る。ＰｏＥＴは、許可された台帳のノードに実行機会を分散させることに基づく。これは、いずれかのノード（またはノードのサブセット内のいずれか）が、許可された台帳の変更について信頼できるときに有用となり得る。

いくつかの実施形態において、合意に達し新たなブロックがブロックチェーンに追加されるとき、このブロックには、前のブロックのハッシュ、タイムスタンプ、ノンス（任意のランダム数）、およびこのブロックに追加中のデータのハッシュが格納される。いくつかの実施形態において、データ自体は暗号化されないので、ブロックチェーン台帳のノードはこのデータを技術的に読み取ることができる。いくつかの実施形態ではデータ自体は暗号化されないが、アイデンティティは保護される。なぜなら、各アイデンティティは（たとえばブロックチェーン内の）アドレスによって参照されるからである。言い換えると、アイデンティティＡが「トップシークレット」クリアランスを有することを保護できる。なぜなら、アイデンティティＡのアドレスはクリアランスレベルを示すからである。いくつかの実施形態においては、アクセス許可のセットを、「トップシークレット」クリアランスまたはその他何らかの機密に関わるアクセス許可を用いて暗号化することができる。この例において、データベースに解読キーを与えて、妥当性確認ノードに妥当性確認の対象の解読データが与えられるようにすることができる。

実施形態は、任意の適切なソフトウェアサービスを活用し、ブロックチェーン技術の各種バージョンを実現することができる。たとえば、実施形態は、ファブリックのような、構成された１つ以上のハイパーレジャープロジェクトを含むことにより、開示された機能を実現することができる。いくつかの実装形態において、ブロックチェーンが活用するデータ処理および暗号関数は、公開鍵、秘密鍵、およびデジタル署名暗号技術、ハッシュ関数および暗号ハッシュ関数（たとえば、セキュアハッシュアルゴリズム（secure hash algorithm）（「ＳＨＡ」）、ＳＨＡ−０、ＳＨＡ−１、ＳＨＡ−２など）、および、実行可能な計算（たとえばプルーフオブワーク（Proof of Work））シナリオを維持しつつも台帳をセキュアにするために使用されるその他の任意の適切なデータ処理または暗号関数を含み得る。

実施形態は、任意の適切な「スマートコントラクト」またはそれに代わる任意の適切なものを実現することもできる。たとえば、ハイパーレジャー「チェーンコード」を、開示されているスマートコントラクト機能を実行するように構成することができる、または、その他任意の適切な自動機能またはコードを実現することができる。

いくつかの実施形態において、ユーザのアクセス許可の変更は、ブロックチェーンコミュニティのサブセット間で非公開にしておくことができる。たとえば、ハイパーレジャーファブリックの「チャネル」という特徴を用いることにより、所与のチャネルについてサブセットのメンバー間の非公開通信を実現することができる。その他の実施形態において、同様のコンセプトを有するその他のブロックチェーン実装例があってもよい。この機能は、ブロックチェーンコミュニティ内の当事者間における非公開トランザクションを提供することができる。たとえば、組織Ａおよび組織Ｂは、所与のアイデンティティに対するアクセス許可の変更を申し込むことができるが、この変更は、ブロックチェーンコミュニティの他のメンバーに知られないように隠すことができる。

このような実施形態において、データベースはこの非公開トランザクションにアクセスできるので、データベースに対してこの非公開データの閲覧許可が与えられるか、または、このサブセットに対して非公開台帳を生成することができ、非公開台帳は、所有するシステムへのアクセスを公開するとき（およびこれらのシステムがこの非公開台帳に接続するとき）に、使用することができる。これらの実施形態では、監査を参照し、ブロックチェーン台帳の変更は、当事者／組織がアクセスできる台帳に限定される。

実施形態は、ブロックチェーン（またはブロックチェーンのコピー）とのインターフェイスのために使用できる１つ以上の分散型アプリケーションまたはアプリを含むこともできる。たとえば、ブロックチェーンコミュニティのメンバーのユーザ（たとえば機密データを共有する組織）は、クライアントコンピューティングデバイス（たとえば、サーバ、ラップトップ、モバイルデバイスなど）で実行されている１つ以上のアプリケーションまたはアプリ（たとえば、モバイルアプリまたは軽量アプリケーション）を用いてブロックチェーンにアクセスすることができる。たとえば、アプリケーションを、機密情報の一部へのアクセスを要求するために、ブロックチェーンコミュニティの機密情報を格納するデータベースと（１つ以上のソフトウェアアプリケーションを用いて）やり取りするように構成してもよい。別の例において、アプリケーションを用いて合意形成し最終的にはブロックチェーンを処理することにより新たなブロックを追加することができる。

いくつかの実施形態において、ブロックチェーンコミュニティのメンバーは、既存のセキュリティプロトコルを管理する構成されたシステムを用いて、またはウェブサイト（たとえばカスタムウェブまたはモバイルポータル）を介して、ブロックチェーンとやり取りすることができる。既存のアイデンティティシステムの場合、ユーザの属性は、通常のチャネルを通して（たとえば組織内の役割を変更する、プロジェクトに説明するなどによって）更新することができ、そうすると、アイデンティティシステムは、ブロックチェーンを呼び出し、スマートコントラクトを実行してこれらの変更をユーザのアイデンティティに適用することができる（たとえば、アイデンティティのブロックチェーンアドレスがそのアイデンティティ属性に記録されることに注目する）。いくつかの実施形態において、１つの当事者／組織が関与する場合がある、すなわち、組織の一雇用者に、その組織が所有する機密データベース内のデータホールディングスに対するアクセスが付与される。

いくつかの実施形態において、ユーザは、ウェブサイト（たとえばポータル）とやり取りし、ウェブフォームに接続することにより、アクセス許可の変更の詳細を提供することができる。これは、追加／変更（たとえばプロジェクト、リリーサビリティ、グループ、タグなどの）のためのアクセス許可と、変更を実施する対象であるユーザ／アイデンティティのアドレスとを含み得る。ある実施形態において、要求しているユーザのアドレスもこの書き込みに含まれる（たとえば、スマートコントラクトがこのユーザの変更の許可を検査するために）。以下で詳しく説明するように、このようなやり取りは、要求の妥当性確認のためにブロックチェーン上のスマートコントラクトをトリガすることができる。いくつかの実施形態において、スマートコントラクトまたはウェブフォーム内で、その他のワークフローを実行することもできる（たとえば要求を承認するために）。

図６は、実施形態の一例に係るブロックチェーン台帳を用いて機密データへのアクセスをセキュアにするための機能の一例を示す。一実施形態において、以下の図６の機能は、メモリまたはその他のコンピュータ読取可能もしくは有形の媒体に格納されたソフトウェアによって実現され、プロセッサによって実行される。他の実施形態において、各機能は、ハードウェアによって（たとえば、特定用途向け集積回路（「ＡＳＩＣ」）、プログラマブルゲートアレイ（「ＰＧＡ」）、フィールドプログラマブルゲートアレイ（「ＦＰＧＡ」）などを使用することによって）、または、ハードウェアとソフトウェアとの任意の組み合わせによって、実行されてもよい。

６０２において、第２のエンティティの代理としての第１のエンティティからの、アクセス許可の更新を、受け付けることができ、この更新は、機密データストアへのアクセス許可を変更するものである。図１を参照して、エンティティ１０２（またはパートナー１０４および／または１０６）の第１のアイデンティティは、エンティティ１０２の第２のアイデンティティに対するアクセス許可の変更を要求することができる。いくつかの実施形態において、アクセス許可は、データベース１１４に格納されている機密データをセキュアにすることができる。データベース１１４は、ＶＰＤおよび／またはＯｒａｃｌｅ（登録商標）セキュリティラベルプロトコルを含むセキュリティモデルを実現することができ、アクセス許可は、仮想プライベートデータベースのセキュリティパラメータに対応し得る。ある実施形態において、更新されたアクセス許可は、第２のエンティティに対し、機密データストアへの行レベルのアクセスを提供する。

６０４において、上記更新の妥当性を確認するスマートコントラクトを呼び出すことができる。たとえば、第２のアイデンティティに対するアクセス許可を更新する許可を第１のアイデンティティが有することについて妥当性を確認するスマートコントラクトを呼び出すことができる。ある実施形態において、このような妥当性確認は、アイデンティティ管理システム（たとえばＩＤＣＳ）と、エンティティ１０２のための１つ以上のソフトウェアサービスとを用いて実行することができる。

６０６において、更新を、ブロックチェーンコミュニティの複数のメンバーに対して提示することができる。たとえば、妥当性が確認された更新を、ブロックチェーンコミュニティのメンバー（たとえばパートナー１０４および１０６）に対して申し出ることができる。ある実施形態において、ブロックチェーン台帳は、第１のエンティティおよび第２のエンティティに対するアクセス許可を検証するために使用される。６０８において、ブロックチェーンコミュニティの合意形成がなされると、第２のエンティティに対するアクセス許可の更新を実行することができ、この更新は、ブロックチェーンコミュニティに対するアクセス許可を格納するブロックチェーン台帳に追加され、ブロックチェーンコミュニティは、機密データストアへのアクセスを共有する複数の異なる組織を含む。

６１０において、ブロックチェーン台帳の分散したコピーに、この更新を格納することができる。たとえば、新たなブロックをブロックチェーン１０８に追加することができ、ブロックチェーンコピー１１０および１１２に、この新たなブロックを格納することができる。ある実施形態において、ブロックチェーン１０８は、ブロックチェーンコミュニティのアクセス許可トランザクションの、暗号化された変更不可の台帳であってもよい。

６１２において、第２のアイデンティティに対する更新されたアクセス許可を、ブロックチェーンから取り出すことができる。たとえば、第２のアイデンティティからの、データベース１１４から機密データを取り出すことを求める要求を、受け付けることができる。データベース１１４は、この要求を受けたことに応じて、ブロックチェーン１０８から、第２のアイデンティティに対する更新されたアクセス許可を取り出すことができる。

６１４において、第２のエンティティは、更新されたアクセス許可を用いて、機密情報にアクセスすることができる。ある実施形態において、データベース１１４は、第２のアイデンティティに対する取り出されたアクセス許可に対応するセキュリティ属性を有する、データベース１１４に要求された機密情報を、返すことができる。たとえば、更新されたアクセス許可に対応するセキュリティパラメータが対応付けられた（keyed）機密情報へのアクセスを、第２のアイデンティティに対して許可することができる。

実施形態は、ブロックチェーン台帳を用いて機密情報に対するアクセス許可を管理する。たとえば、現実世界では、状況によって、機密情報へのアクセスを複数の組織が共有する必要がある。これらの状況は、中央政府のような団体またはエンティティが極秘情報または機密情報であると特定した情報を、国家セキュリティサービスのような団体またはエンティティにサービスを提供するために、共有することを含み得る。それ以外の状況でも、機密または専有情報などに依拠する組織間の合弁事業のように、共有される機密情報から同様の利益を享受することができる。

いくつかの実施形態において、各組織におけるアイデンティティ、たとえば個人には、さまざまなレベルの機密情報へのアクセスを付与することができる。たとえば、機密情報をデータベースに格納し、この機密情報に、異なるセキュリティパラメータ（たとえば、セキュリティ分類レベル、タイトル、プロジェクト名、リリースなど）を対応付ける（keyed）ことができる。各組織のアイデンティティに対するアクセス許可は、個々のアクセス許可に対応するセキュリティパラメータが対応付けられた（keyed）機密情報へのアクセスを許可することができる。

実施形態は、ブロックチェーン台帳を用いて、アクセス許可およびアクセス許可の更新を管理することにより、各種組織のさまざまなアイデンティティに対し、機密情報へのアクセスをセキュアにする。たとえば、機密情報へのアクセスを共有する各種組織は、ブロックチェーンコミュニティのメンバーを表し得る。ある組織が、そのアイデンティティのうちの１つに対するアクセス許可の更新を要求した場合、一連のアクションをトリガする（たとえばスマートコントラクトを呼び出す）ことによってトランザクションを実行することができる。要求している組織／アイデンティティは、この変更を、ブロックチェーンコミュニティに対して申し出ることができる。ブロックチェーンコミュニティが合意に達すると、スマートコントラクトはこの変更を実行することができる。上記アイデンティティに対するアクセス許可の変更を反映するトランザクションまたはブロックを、ブロックチェーンに追加することができる。

したがって、ブロックチェーン台帳は、コミュニティメンバー（たとえば参加している組織）のアイデンティティに対する、最新の透明なアクセス許可を、格納することができる。いくつかの実施形態において、あるアイデンティティが機密情報へのアクセスを要求すると、データベースは、要求しているアイデンティティに対する最新のアクセス許可を取り出すために、ブロックチェーンにクエリすることができる。次に、これらのアクセス許可を用いて、対応する機密情報をデータベースから取り出すことにより、確実に、最新の透明なアクセス許可を用いて、アイデンティティがアクセスを許可された機密情報のみを取り出すことができる。

本明細書において説明した本開示の特徴、構造、および特性は、１つ以上の実施形態において任意の適切なやり方で組み合わせてもよい。たとえば、「一実施形態」、「いくつかの実施形態」、「特定の実施形態」、「特定の複数の実施形態」、またはその他同様の表現の使用は、本明細書において、その実施形態に関連して説明した特定の特徴、構造、または特性が、本開示の少なくとも１つの実施形態に含まれ得ることを意味する。よって、「一実施形態」、「いくつかの実施形態」、「特定の実施形態」、「特定の複数の実施形態」という表現、またはその他同様の表現の表示は、本明細書において、すべて必ずしも同一グループの実施形態を指している訳ではなく、記載されている特徴、構造、または特性は、１つ以上の実施形態において任意の適切なやり方で組み合わせてもよい。

上記実施形態は、順序が異なるステップで、および／または開示されている構成と異なる構成における要素によって実施し得ることを、当業者は容易に理解するであろう。したがって、本開示は概略を述べた実施形態を考慮しているが、本開示の精神および範囲に含まれる、特定の変更、変形、および代替の構成が明白であることは、当業者にとって明らかであろう。したがって、本開示の範囲を判断するためには以下の請求項を参照する必要がある。

Claims (13)

1. ブロックチェーン台帳を用いて機密データへのアクセスをセキュアにするために記憶装置に格納された命令を実行するプロセッサを含むシステムで実行される方法であって、前記方法は、
   前記プロセッサが、第２のエンティティの代理としての第１のエンティティからの、アクセス許可の更新を、受け付けるステップを含み、前記更新は、機密データストアへのアクセス許可を変更するものであり、
   前記プロセッサが、前記更新の妥当性を確認するスマートコントラクトを呼び出すステップと、
   ブロックチェーンコミュニティの合意形成がなされると、前記プロセッサが、前記第２のエンティティに対する前記アクセス許可の更新を実行するステップとを含み、前記更新は、前記ブロックチェーンコミュニティに対するアクセス許可を格納するブロックチェーン台帳に追加され、前記ブロックチェーンコミュニティは、前記機密データストアへのアクセスを共有する複数の異なる組織を含む、方法。
2. 前記スマートコントラクトは、アイデンティティ管理システムを用いて前記第１のエンティティおよび前記第２のエンティティのアイデンティティの妥当性を確認する、請求項１に記載の方法。
3. 前記スマートコントラクトは、前記第２のエンティティのアイデンティティのセキュリティパラメータを更新する許可を前記第１のエンティティのアイデンティティが有することについて妥当性を確認する、請求項２に記載の方法。
4. 前記機密データストアは仮想プライベートデータベースを含み、前記アクセス許可は、前記仮想プライベートデータベースのセキュリティパラメータに対応する、請求項１から３のいずれか１項に記載の方法。
5. 前記更新されたアクセス許可は、前記第２のエンティティに対し、前記機密データストアへの行レベルのアクセスを提供する、請求項４に記載の方法。
6. 前記ブロックチェーン台帳は、前記第１のエンティティおよび前記第２のエンティティに対するアクセス許可を検証するために使用される、請求項１から５のいずれか１項に記載の方法。
7. 前記ブロックチェーン台帳は、前記ブロックチェーンコミュニティのアクセス許可トランザクションの、暗号化された変更不可の台帳を含む、請求項６に記載の方法。
8. 前記プロセッサが、前記第２のエンティティからの、前記機密データストアへのアクセス要求を、受け付けるステップと、
   前記プロセッサが、前記ブロックチェーン台帳から、前記第２のエンティティに対する前記更新されたアクセス許可を取り出すステップと、
   前記プロセッサが、前記更新されたアクセス許可に対応するセキュリティパラメータが対応付けられた機密情報へのアクセスを、前記第２のエンティティに対して許可するステップとをさらに含む、請求項１から７のいずれか１項に記載の方法。
9. 請求項１から８のいずれか１項に記載の方法をコンピュータに実行させるためのプログラム。
10. ブロックチェーン台帳を用いて機密データへのアクセスをセキュアにするためのシステムであって、前記システムは、
    記憶装置と通信するプロセッサを備え、前記プロセッサは、命令を実行することにより、
    第２のエンティティの代理としての第１のエンティティからの、アクセス許可の更新を、受け付け、前記更新は、機密データストアへのアクセス許可を変更するものであり、
    前記更新の妥当性を確認するスマートコントラクトを呼び出し、
    ブロックチェーンコミュニティの合意形成がなされると、前記第２のエンティティに対する前記アクセス許可の更新を実行するように、構成されており、前記更新は、前記ブロックチェーンコミュニティに対するアクセス許可を格納するブロックチェーン台帳に追加され、前記ブロックチェーンコミュニティは、前記機密データストアへのアクセスを共有する複数の異なる組織を含む、システム。
11. 前記スマートコントラクトは、アイデンティティ管理システムを用いて前記第１のエンティティおよび前記第２のエンティティのアイデンティティの妥当性を確認し、前記スマートコントラクトは、前記第２のエンティティのアイデンティティのセキュリティパラメータを更新する許可を前記第１のエンティティのアイデンティティが有することについて妥当性を確認する、請求項１０に記載のシステム。
12. 前記ブロックチェーン台帳は、前記ブロックチェーンコミュニティのアクセス許可トランザクションの、暗号化された変更不可の台帳を含む、請求項１０または１１に記載のシステム。
13. 前記プロセッサはさらに、命令を実行することにより、
    前記第２のエンティティからの、前記機密データストアへのアクセス要求を、受け付け、
    前記ブロックチェーン台帳から、前記第２のエンティティに対する前記更新されたアクセス許可を取り出し、
    前記更新されたアクセス許可に対応するセキュリティパラメータが対応付けられた機密情報へのアクセスを、前記第２のエンティティに対して許可するように、構成されている、請求項１０から１２のいずれか１項に記載のシステム。

Images