(58)【調査した分野】(Int.Cl.,DB名)
前記スマートコントラクトは、アイデンティティ管理システムを用いて前記第1のエンティティおよび前記第2のエンティティのアイデンティティの妥当性を確認する、請求項1に記載の方法。
前記スマートコントラクトは、前記第2のエンティティのアイデンティティのセキュリティパラメータを更新する許可を前記第1のエンティティのアイデンティティが有することについて妥当性を確認する、請求項2に記載の方法。
前記機密データストアは仮想プライベートデータベースを含み、前記アクセス許可は、前記仮想プライベートデータベースのセキュリティパラメータに対応する、請求項1から3のいずれか1項に記載の方法。
前記ブロックチェーン台帳は、前記第1のエンティティおよび前記第2のエンティティに対するアクセス許可を検証するために使用される、請求項1から5のいずれか1項に記載の方法。
前記スマートコントラクトは、アイデンティティ管理システムを用いて前記第1のエンティティおよび前記第2のエンティティのアイデンティティの妥当性を確認し、前記スマートコントラクトは、前記第2のエンティティのアイデンティティのセキュリティパラメータを更新する許可を前記第1のエンティティのアイデンティティが有することについて妥当性を確認する、請求項10に記載のシステム。
前記ブロックチェーン台帳は、前記ブロックチェーンコミュニティのアクセス許可トランザクションの、暗号化された変更不可の台帳を含む、請求項10または11に記載のシステム。
【発明を実施するための形態】
【0009】
詳細な説明
実施形態は、ブロックチェーン台帳を用いて機密データへのアクセスをセキュアにする。ブロックチェーン台帳は、暗号機能を用いてセキュアにされた、接続された記録またはブロックを含む、分散型電子台帳であってもよい。台帳内の各ブロックが前のブロックの暗号ハッシュを含む、ブロックチェーンの実装は、再帰的となり得る。したがって、ブロックチェーン台帳は、たとえば、最初のブロック(またはトランザクション)から最新のブロック(またはトランザクション)まで、この台帳が表す基礎となるブロックまたはトランザクションに対し、透明性を提供することができる。
【0010】
実施形態は、ブロックチェーン台帳を用いて機密情報に対するアクセス許可を管理する。たとえば、現実世界では、状況によって、機密情報へのアクセスを複数の組織が共有する必要がある。これらの状況は、中央政府のような団体またはエンティティが極秘情報または機密情報であると特定した情報を、国家セキュリティサービスのような団体またはエンティティにサービスを提供するために、共有することを含み得る。それ以外の状況でも、機密または専有情報などに依拠する組織間の合弁事業のように、共有される機密情報から同様の利益を享受することができる。
【0011】
いくつかの実施形態において、各組織におけるアイデンティティ、たとえば個人には、さまざまなレベルの機密情報へのアクセスを付与することができる。たとえば、機密情報をデータベースに格納し、この機密情報に、異なるセキュリティパラメータ(たとえば、セキュリティ分類レベル、タイトル、プロジェクト名、リリースなど)を対応付ける(keyed)ことができる。各組織のアイデンティティに対するアクセス許可は、個々のアクセス許可に対応するセキュリティパラメータが対応付けられた(keyed)機密情報へのアクセスを許可することができる。
【0012】
実施形態は、ブロックチェーン台帳を用いて、アクセス許可およびアクセス許可の更新を管理することにより、各種組織のさまざまなアイデンティティに対し、機密情報へのアクセスをセキュアにする。たとえば、機密情報へのアクセスを共有する各種組織は、ブロックチェーンコミュニティのメンバーを表し得る。ある組織が、そのアイデンティティのうちの1つに対するアクセス許可の更新を要求した場合、一連のアクションをトリガする(たとえばスマートコントラクトを呼び出す)ことによってトランザクションを実行することができる。要求している組織/アイデンティティは、この変更を、ブロックチェーンコミュニティに対して申し出ることができる。ブロックチェーンコミュニティが合意に達すると、スマートコントラクトはこの変更を実行することができる。上記アイデンティティに対するアクセス許可の変更を反映するトランザクションまたはブロックを、ブロックチェーンに追加することができる。
【0013】
したがって、ブロックチェーン台帳は、コミュニティメンバー(たとえば参加している組織)のアイデンティティに対する、最新の透明なアクセス許可を、格納することができる。いくつかの実施形態において、あるアイデンティティが機密情報へのアクセスを要求すると、データベースは、要求しているアイデンティティに対する最新のアクセス許可を取り出すために、ブロックチェーンにクエリすることができる。次に、これらのアクセス許可を用いて、対応する機密情報をデータベースから取り出すことにより、確実に、最新の透明なアクセス許可を用いて、アイデンティティがアクセスを許可された機密情報のみを取り出すことができる。
【0014】
次に、その例が添付の図面に示されている本開示の実施形態について詳しく述べる。以下の詳細な説明には、本開示が十分に理解されるよう、数多くの具体的な詳細が記載されている。しかしながら、本開示はこれらの具体的な詳細がなくても実施し得ることは、当業者には明らかであろう。他の場合では、周知の方法、手順、コンポーネント、および回路は、実施形態の側面を不必要に曖昧にすることを避けるために、詳細には説明していない。可能な限り同様の参照番号が同様の要素に使用される。
【0015】
図1は、ある実施形態に係るブロックチェーン台帳を用いて機密データをセキュアにするためのシステムを示す。システム100は、エンティティ102と、パートナー104および106と、ブロックチェーン108と、ブロックチェーンコピー110および112と、データベース114とを含む。いくつかの実施形態において、エンティティ102は、データベース114に格納された機密情報にアクセスできる組織であってもよい。たとえば、データベース114は、仮想プライベートデータベース(Virtual Private Database)(「VPD」)プロトコル(たとえばOracle(登録商標)ラベル・セキュリティ(Label Security))を実装するOracle(登録商標)データベースのような仮想プライベートデータベースであってもよい。データベース114に格納されたデータには、エンティティ102のアイデンティティ(たとえば認証された個人)が、この個人に対する管理されたアクセス許可に基づいて、アクセスすることができる。
【0016】
いくつかの実施形態において、パートナー104および106も、データベース114に格納された機密情報へのアクセスを共有する組織であってもよい。たとえば、エンティティ102は、パートナー104および106との合弁事業に参加する組織であってもよく、この場合の各組織は、データベース114に格納されたさまざまなレベルの機密情報にアクセスすることができる。エンティティ102ならびにパートナー104および106は各々、特定のセキュリティパラメータによってセキュアにされたデータベース114の特定のデータにアクセスするように構成されたアクセス許可を有する、対応するアイデンティティ(たとえば個人)を有し得る。
【0017】
エンティティ102ならびにパートナー104および106各々に対応付けられたアイデンティティのセットに対するアクセス許可は、ブロックチェーン台帳108ならびにブロックチェーン台帳コピー110および112を用いて管理することができる。たとえば、アイデンティティのセットに対するアクセス許可の変更は、ブロックチェーン台帳108により、透明かつ変更不能に表すことができる。いくつかの実施形態において、ブロックチェーン台帳108は、上記アイデンティティのセットに対するアクセス許可の初期セットを含み得る。また、ブロックチェーン台帳108に追加されたブロックは、アクセス許可の初期セットに対する変更を表す。このような実装形態において、ブロックチェーン台帳108は、アイデンティティのセットに対する最新のアクセス許可を格納することができ、一方で、これらのアイデンティティに対するアクセス許可のすべての変更のトランザクション履歴を格納する。いくつかの実施形態において、ブロックチェーン台帳108は中央台帳を管理し、ブロックチェーン台帳コピー110および112はこの中央台帳のコピーを格納する。
【0018】
実装形態の一例において、エンティティ102はアイデンティティAおよびBを含み得る。アイデンティティAは、アイデンティティBのためにアクセス許可の変更を要求することができる。この変更は、ブロックチェーンコミュニティ(たとえばエンティティ102ならびにパートナー104および106)に対して申し出ることができる。ブロックチェーンコミュニティが合意に達するまたはこの変更を承認すると、アイデンティティBのために要求されたアクセス許可の変更を表すブロックを、ブロックチェーン台帳108に追加することができる。
【0019】
ある実施形態において、アイデンティティBが機密情報へのアクセスを要求すると、データベース114は、ブロックチェーン台帳108によって格納されたアイデンティティBのための最新のアクセス許可を取り出すことができる。アクセス許可のこのセキュアで透明な管理により、確実に、ブロックチェーンコミュニティが許可したセキュアな情報に対するアクセスのみをアイデンティティBに付与することができる。
【0020】
いくつかの実施形態において、エンティティ102は、Oracle(登録商標)データベース内にデータベース114を構成し、格納されているデータをセキュアにする同意されたセキュリティモデルを生成することができる。このモデルは、リリーサビリティ・マーキング(releasability markings)、クリアランス、プロジェクト名などを含み得る。次に、システム内に格納されたデータを、Oracle(登録商標)ラベル・セキュリティ、VPD、および/またはデータ・リリース・アクセレレレータ(Data Release Accelerator)(たとえば国家セキュリティの利用者向け)を用いて制御する。次に、エンティティ102はブロックチェーンメンバーシップにおける信頼できる各当事者(たとえばパートナー104および106)との間にブロックチェーン108を構成することができ、ブロックチェーンとやり取りする/ブロックチェーンにアクセスすることができる有効なユーザについて、メンバーの同意を得ることができる。いくつかの実装形態において、個々のユーザがユーザのセキュリティ属性を追加または変更できるようにするスマートコントラクトをブロックチェーン上に生成することができる。
【0021】
実施形態は、過去に実現されたシステムに勝る、複数の技術的利点を実現する。たとえば、ブロックチェーンを用いて共有機密情報に対するアクセス許可を管理し、格納し、取り出す実施形態は、機密情報を共有するメンバー組織間の透明性を高めることができ、それにより、データ共有の採用を促すことができる。ブロックチェーンの変更は、変更不能に格納されるので、アクセス許可を効率的な監査に利用することができる。ブロックチェーンストレージの透明性および変更不能という性質により、データを共有するパートナーは、合意されたセキュリティコントロールが有効に運営されることを保証することができ、データ共有の採用がさらに促進される。
【0022】
加えて、ユーザ/アイデンティティにアクセスを許可する前にブロックチェーンから直接アクセス許可を取り出すことにより、確実に、最新の(かつ透明に管理される)アクセス許可を使用する。いくつかの実装形態は、セキュアで軽量のアクセス許可/セキュリティ属性モデル(たとえばOracle(登録商標)ラベル・セキュリティ)を活用することにより、ブロックチェーンにとって計算上効率的なアクセス許可を提供する。たとえば、アクセス許可が大きく扱いにくい場合、直ちに、ブロックの追加時に、より困難な計算上の問題を生じさせる、大きなブロックチェーンとなる可能性がある。
【0023】
加えて、分散型でセキュアな暗号化された記録の台帳を使用することにより、中央データベースを利用する既存の実装形態において頻繁に生じる漏洩のリスクを軽減する。たとえば、アクセス許可の透明な管理によってトレーサビリティが実現され、コミュニティは、信頼性のないアクター/アイデンティティからのアクセスをブロックすることができる。実施形態は、属性に基づくアクセスコントロール(attributes based access control)(「ABAC」)を拡張することにより、機密データへのアクセスを管理するための、よりセキュアで技術的に改善された実装形態を提供する。
【0024】
図2は、実施形態に係るコンピュータサーバ/システム210のブロック図である。
図2に示されるように、システム210は、プロセッサ222およびメモリ214といったシステム210の各種コンポーネント間で情報を伝達するように構成された、バスデバイス212および/またはその他の通信機構を含み得る。加えて、通信装置220が、ネットワーク(図示せず)を介してプロセッサ222から別のデバイスに送信されるデータをエンコードしネットワークを介して別のシステムから受信したプロセッサ222に対するデータをデコードすることにより、プロセッサ222とその他のデバイスとの接続性を有効にすることができる。
【0025】
たとえば、通信装置220は、無線ネットワーク通信を提供するように構成されたネットワークインターフェイスカードを含み得る。赤外線、無線、Bluetooth(登録商標)、Wi−Fi(登録商標)、および/またはセルラー通信を含む、さまざまな無線通信技術を使用することができる。これに代えて、通信装置220は、イーサネット(登録商標)接続といった有線ネットワーク通信を提供するように構成されてもよい。
【0026】
プロセッサ222は、システム210の計算および制御機能を実行するために1つ以上の汎用または専用プロセッサを含み得る。プロセッサ222は、マイクロ処理デバイスのような1つの集積回路を含んでいてもよく、または、プロセッサ222の機能を実現するために協働する複数の集積回路装置および/または回路基板を含んでいてもよい。加えて、プロセッサ222は、メモリ214に格納されている、オペレーティングシステム215、アクセス許可マネージャ216、およびその他のアプリケーション218といったコンピュータプログラムを実行し得る。
【0027】
システム210は、情報と、プロセッサ222が実行する命令とを格納するためのメモリ214を含み得る。メモリ214は、データを取り出し、提示し、修正し、格納するための各種コンポーネントを含み得る。たとえば、メモリ214は、プロセッサ222によって実行されると機能を提供するソフトウェアモジュールを格納してもよい。これらのモジュールは、システム210に対してオペレーティングシステム機能を提供するオペレーティングシステム215を含み得る。これらのモジュールは、オペレーティングシステム215およびアクセス許可マネージャ216ならびにその他のアプリケーションモジュール218を含み得る。オペレーティングシステム215は、システム210に対してオペレーティングシステム機能を提供する。アクセス許可マネージャ216は、ブロックチェーン上でアクセス許可を格納および/または管理するための機能を提供することができる、または、本開示の任意のその他の機能をさらに提供してもよい。場合によっては、アクセス許可マネージャ216を、インメモリ構成として実現することができる。
【0028】
非一時的なメモリ214は、プロセッサ222がアクセスできるさまざまなコンピュータ読取可能媒体を含み得る。たとえば、メモリ214は、ランダムアクセスメモリ(「RAM」)、ダイナミックRAM(「DRAM」)、スタティックRAM(「SRAM」)、読出専用メモリ(「ROM」)、フラッシュメモリ、キャッシュメモリ、および/または任意のそれ以外のタイプの非一時的なコンピュータ読取可能媒体を、任意に組み合わせたものを含み得る。
【0029】
プロセッサ222はさらに、バス212を介して液晶ディスプレイ(「LCD」)等のディスプレイ224に結合される。キーボード226およびコンピュータマウス等のカーソルコントロール装置228がさらに通信装置212に結合されて、ユーザとシステム210との間のインターフェイスを可能にする。
【0030】
いくつかの実施形態において、システム210は、より大きなシステムの一部であってもよい。したがって、システム210は、さらに他の機能を含むために1つ以上の他の機能モジュール218を含み得る。他のアプリケーションモジュール118は、たとえば、Oracle(登録商標)クラウドに埋め込まれたエンゲージメントエンジン(「EE」)の各種モジュール、または、Oracle(登録商標)ブロックチェーンクラウドサービスのモジュールを含み得る。データベース217は、モジュール216および218のための集中ストレージ(centralized storage)を提供するためにバス212に結合される。データベース217は、論理的に関連付けられた記録またはファイルの一体化されたコレクションにデータを格納することができる。データベース217は、
図1のデータベース114、オペレーショナルデータベース、分析データベース、データウェアハウス、分散型データベース、エンドユーザデータベース、外部ベータベース、ナビゲーションデータベース、インメモリデータベース、ドキュメント指向データベース、リアルタイムデータベース、リレーショナルデータベース、オブジェクト指向データベース、Hadoop分散型ファイルシステム(「HFDS」)、NoSQLデータベース、または当該技術において周知の任意のその他のデータベースと同様のものであってもよい。
【0031】
単一のシステムとして示されているが、システム210の機能は分散型システムとして実現されてもよい。たとえば、メモリ214およびプロセッサ222を、全体としてシステム210を表す複数の異なるコンピュータに分散させてもよい。一実施形態において、システム210は、あるデバイス(たとえばスマートフォン、タブレット、コンピュータなど)の一部であってもよい。
【0032】
ある実施形態において、システム210は、デバイスから分離していてもよく、このデバイスに対して上記機能を遠隔から提供してもよい。さらに、システム210の1つ以上のコンポーネントが含まれていなくてもよい。たとえば、ユーザまたはコンシューマデバイスとしての機能の場合、システム210は、プロセッサとメモリとディスプレイとを含むスマートフォンまたはその他の無線装置であってもよく、
図2に示される他のコンポーネントのうちの1つ以上を含まず、
図2に示されていない追加のコンポーネントを含む。
【0033】
いくつかの実施形態において、システム210または同様のシステムを、ブロックチェーンコミュニティメンバーによって実現することにより、ブロックチェーン台帳トランザクションを処理することができる。たとえば、システム210を用いて、ブロックチェーン台帳に対するブロックの追加に関連する暗号関数を実行してもよく、または、その他の関連するブロックチェーン暗号機能を実行してもよい(たとえば、proof of workに関連する計算、妥当性確認、合意など)。たとえば、システム210は、Oracle(登録商標)ブロックチェーンクラウドサービス、または任意の他のクラウドサービスおよび/またはブロックチェーンサービスの機能を実現することができる。
【0034】
図3は、実施形態の一例に係るブロックチェーン台帳によってセキュアにされた機密データを取り出すフローを示す。フロー300は、ユーザ302と、サービス304と、データベース306と、ブロックチェーン308とを含む。ユーザ302は、ブロックチェーンコミュニティの一部である組織(たとえば
図1のエンティティ102)のユーザであってもよい。サービス304は、アイデンティティ管理サービス、データベースクエリサービス、ウェブサービスなどを含む、各種実施形態を実現するのに適したソフトウェアサービスを含み得る。サービスの例は、各種ハイパーレジャーブロックチェーンプロジェクト(たとえばハイパーレジャーファブリック(Hyperledger fabric))および/またはOracle(登録商標)ブロックチェーンクラウドサービスのような、各種ブロックチェーンおよび/または企業データソリューションによって提供することができる。データベース306は、
図1のデータベース114または
図2のデータベース217と同様であってもよく、ブロックチェーン308は、
図1のブロックチェーン台帳108と同様であってもよい。
【0035】
ある実施形態において、ユーザ302は、サービス304を用いてアイデンティティ認証を実行することができる。たとえば、サービス304のうちの1つは、ユーザ302に関連付けられた組織(たとえば
図1のエンティティ102)のためのアイデンティティ管理システムを含み得る。ユーザ302のアイデンティティを認証することができるアイデンティティ管理システムの一例は、Oracle(登録商標)アイデンティティクラウドサービス(「IDCS」)である。いくつかの実施形態において、ある組織は、米国特許第9,838,376号に記載のような、クラウドベースのユーザ認証システムを実現することができる。任意のその他適切なアイデンティティ管理システムを実現することもできる。
【0036】
ユーザ302のアイデンティティが認証されると、このユーザは、機密情報を求めてデータベース306にクエリするために、サービス304を活用することができる。それに応じて、データベース306は、たとえば以前のユーザの認証に基づいて、ユーザ302の妥当性確認を行うことができる。ある実施形態において、アイデンティティ管理サービスは、トークンのような、妥当性確認に使用できる身分証明を提供することができる。たとえば、IDCSサービスは、データベース306といったその他のさまざまなシステムがユーザのアイデンティティの妥当性確認を行えるよう、ユーザ302の1つ以上のトークンを提供することができる。
【0037】
ユーザ302のアイデンティティの妥当性が確認されると、データベース306は、妥当性が確認されたアイデンティティに対するアクセス許可またはセキュリティ属性を、ブロックチェーン308から取り出すことができる。いくつかの実施形態において、ブロックチェーン308は、キーに基づく台帳とみなすことができ、各アイデンティティはこの台帳上のキー(またはアドレス)を有する。このような実施形態において、データベース306は、ブロックチェーン308上のユーザ302のキーの値を取り出すことができる。ブロックチェーン308のこの場所のデータはユーザ302のアイデンティティのセキュリティ属性に対応するからである。
【0038】
いくつかの実施形態において、ブロックチェーン308は、ブロックチェーンの現在の「実世界の状態(state of the world)」を格納するデータベースを(たとえばデータベース306の機密データストアとは別に)含み得る。この実世界の状態は、トランザクションが台帳に追加されるたびに、更新される。たとえば、このデータベースは、NoSQLデータベースであってもよく、やや複雑なクエリを実行することによってデータを取り出すことができる。
【0039】
ある実装形態において、ブロックチェーン308の「実世界の状態」は、ブロックチェーン308がアクセス許可を管理する対象であるアイデンティティに対する最新のアクセス許可を含み得る。このような実装形態において、最新のアクセス許可をこのデータベースから取り出して、データベース306に格納されている機密データにアクセスするために使用することができる。このような実施形態において、データベースは、機密データに対する最新のアクセス許可を格納するために使用されるが、ブロックチェーン308はなおも、変更不能の記録を保持し、これらのアクセス許可のためのトランザクションの実行を管理する。よって、ブロックチェーン308はなおも、透明性を提供し、機密データへのアクセスの管理について定められたポリシーが実現されていることを保証する。
【0040】
図3に示されるように、属性モデルを用いることにより、アイデンティティに対するアクセス許可を定めることができる。示されているアクセス許可属性モデルの例(Example attribute model)において、アイデンティティは、「シークレット」クリアランス("SECRET" clearance)を有し、ブリーフィング(briefing)「A」、「B」、および「C」に対してクリアされ、「麻薬中毒更生会(narcotics)」および「テロリズム(terrorism)」グループに属し、「lighting」および「thunder」プロジェクトに対応付けられている。
【0041】
図4は、実施形態に係るセキュアなデータの属性モデルを示す。たとえば、アイデンティティについて
図3に示されるアクセス許可属性モデルと同様に、セキュアなデータも同様にセキュリティ属性402に対応付ける(keyed)ことができる。セキュリティ属性402は、ブリーフィングと同様であってもよい「タイトル」と、「分類」と、「プロジェクト」と、「リリース」とを含み得る。データベース306に格納された機密データへのアクセスに関しては、1つの機密データをセキュアにするセキュアにされた属性に対応するアクセス許可を有するユーザ/アイデンティティに対し、データへのアクセス/データの取り出しを許可することができる。
【0042】
たとえば、いくつかの実装形態は、セキュアなデータをリレーショナルデータテーブルに格納する。テーブル、これらのリレーショナルデータテーブルの行および/または列は、データへのアクセスを制限する異なるセキュリティレベルを有し得る。ある実施形態において、セキュリティ属性の第1のミックスを用いて第1のテーブル(たとえば行および/または列のセット)をセキュアにし、セキュリティ属性の第2のミックスを用いて第2のテーブルをセキュアにしてもよい。さらに、いくつかの実施形態は、これらのデータテーブルの列/行レベルで、セキュリティ属性の各種ミックスを含む。したがって、対応するセキュリティ属性を有するアイデンティに対し、第1のテーブルからデータを取り出す許可を与えるが第2のテーブルからデータを取り出す許可は与えないようにしてもよく、いくつかの実装形態においては、第1のテーブルの特定の行/列からデータを取り出す許可を与えるが第1のテーブルの他の行/列からデータを取り出す許可は与えないようにしてもよい。
【0043】
いくつかの実施形態において、データベース306は、Oracle(登録商標)ラベル・セキュリティを実現するVPDであってもよい。たとえば、データベース306は、ブロックチェーンコミュニティのメンバーが同意したセキュリティモデルを用いてデータを格納するように構成することができる。たとえば、セキュリティモデルは、
図4に示される、リリースマーキング、クリアランスレベル、プロジェクト名、その他のセキュリティ属性などを含み得る。格納されているデータに対するアクセスを、他のOracle(登録商標) VPDおよびラベル・セキュリティの特徴を用い、場合によってはデータ・リリース・アクセレレータを用いて、セキュアにすることができる。
【0044】
図3に示される、取り出されたセキュリティ属性またはアクセス許可を考慮して、ユーザ302の認証され妥当性が確認されたアイデンティティは、ユーザ302のアイデンティティに対するアクセス許可と、サブセット404のセキュリティ属性との間の対応関係に基づいて、サブセット404のセキュリティ属性に対応付けられた(keyed)情報を取り出すことを許可される。アイデンティティに対するアクセス許可および/または機密データのセキュリティ属性は、同様に構成することができる、または、いくつかの実施形態では異なっていてもよい。
【0045】
加えて、アクセス許可/セキュリティ属性は、高いレベルのセキュリティクリアランス、より高いレベルのセキュリティクリアランス、最高レベルのセキュリティクリアランスといった、階層構造を含み得る。この例において、セキュリティクリアランスが最高レベルであるアクセス許可は、最高レベル、より高いレベル、および高いレベルのセキュアデータへのアクセス/データの取り出しを許可され、セキュリティクリアランスがより高いレベルであるアクセス許可は、より高いレベルおよび高いレベルのセキュアデータへのアクセス/データの取り出しを許可され、セキュリティクリアランスが高いレベルであるアクセス許可は、高いレベルのセキュアデータのみへのアクセス/データの取り出しを許可される。その他のアクセス許可/属性も同様に、階層機能を実現することができる。
【0046】
再び
図3を参照して、返されたユーザ302のアイデンティに対するアクセス許可に対応するセキュリティ属性が対応付けられた(keyed)、要求された機密データを、ユーザ302/サービス304に返すことができる。たとえば、ユーザ302/サービス304が、データベース306からセキュアなデータのセットを取り出すことを要求した場合、データベース306によって返されるセキュアなデータは、ブロックチェーン308から返された、ユーザ302の認証済のアイデンティティに対するアクセス許可に対応する要求されたデータであろう。
【0047】
図5は、ある実施形態に係るアイデンティティに対するアクセス許可を更新するフローを示す。フロー500は、ユーザ502および504(たとえばそれぞれボブおよびジェーン)と、スマートコントラクト506と、アイデンティティサービス508と、ブロックチェーン510と、更新されたブロックチェーン512とを含む。
【0048】
ある実施形態において、ユーザ502および504は、本開示において説明する、ブロックチェーンコミュニティの一部である第1の組織と関係があるユーザであってもよい。ユーザ504に対するアクセス許可は、たとえばユーザの仕事の割当の変更に基づいて、または何らかのその他適切な状況に基づいて、時折更新される場合がある。よって、ユーザ502が、ユーザ504のアクセス許可の変更を要求する場合がある。この例において、たとえばアイデンティティサービス508内で、第1の組織と関係があるユーザに対するアクセス許可を変更する特定の権限が、ユーザ502に委任されてもよい。その他の実施形態において、ユーザ504はこれらのアクセス許可の更新を要求することができ、フロー500と同様のフローに従うことができる。
【0049】
一例としてのアイデンティティサービス508は、本開示においてさらに説明するOracle(登録商標) IDCSである。この例において、アイデンティティサービス508は第1の組織に属することができるが、さまざまな組織(たとえば、ブロックチェーンコミュニティ内の第1の組織およびその他の組織)のアイデンティティを管理するアイデンティティサービスのような、その他の構造も同様に実現することができる。
【0050】
ある実施形態において、ユーザ502がユーザ504のアクセス許可の更新を要求するために、スマートコントラクトサービスを呼び出して、最終的に更新を実現する一連のアクションであってもよいスマートコントラクト506を実行することができる。スマートコントラクトは、アクションの結果に基づいて実行のフローに従う、ソフトウェアが実行する半自動化された一連のアクションであるとみなすことができる。ソフトウェアが実行するスマートコントラクトの一例は、合意形成アクションを含み得る。たとえば、1つのソフトウェアコードの実行等の特定のアクションを実施すべきであることに対し、コミュニティは、コミュニティのうちの大多数がこのアクションに同意すれば、同意してもよい。スマートコントラクトは、アクションを実施すべきか否かについてコミュニティから投票またはその他の表示を電子的に受けてもよく、コミュニティの大半が同意すれば、スマートコントラクトは、アクション(たとえば1つのコード)を自動的に実行することができる。
【0051】
スマートコントラクト506は先ず、アイデンティティサービス508を用いて、ユーザ502および504(たとえばボブおよびジェーン)のアイデンティティを認証することができる。ある実施形態において、スマートコントラクト506は次に、ボブであるユーザ502が、ジェーンであるユーザ504に対するアクセス許可を変更する権限を有しているか否かを判断することができる。いくつかの実施形態において、アクセス許可を変更する権限は、要求された変更に基づいていてもよい。
【0052】
たとえば、ユーザ502は、アイデンティティサービス508および第1の組織内においてある役割を有していてもよい。要求された変更が、必須アクセス制御(mandatory access control)の変更(たとえばセキュリティクリアランスレベルの変更)等の第1のタイプであれば、ユーザ502はユーザの役割が第1のタイプの変更を許可する役割である場合に(たとえば第1の組織内のセキュリティ責任者)、この変更を実施することを許可される。要求された変更が、任意アクセス制御(discretionary access control)の変更(たとえばグループまたはプロジェクトの変更)等の第2のタイプであれば、ユーザ502はユーザの役割が第2のタイプの変更を許可する役割である場合に(たとえば第1の組織内のグループ/プロジェクトに対する管理者)、この変更を実施することを許可される。いくつかの実施形態において、組織/アイデンティティ管理システムは、あるユーザが組織の(他の)ユーザに対するアクセス許可の変更をいつ認められるかを決定する追加のビジネスロジック/ルールを取り入れることもできる。
【0053】
ユーザ502および504の認証が正常に完了し、要求された、ユーザ504に対するアクセス許可の特定の変更を、ユーザ502が実施することが許可されると、スマートコントラクト506は、ブロックチェーン510に対してこの変更を申し出ることができる。先に述べたように、ブロックチェーン510は、複数のブロックチェーンコミュニティメンバー(たとえば組織)を含み得る。ブロックチェーンコミュニティのメンバーは、申し出があった変更の妥当性を確認することができ、ブロックチェーンで合意に達すると、ブロックをブロックチェーン510に追加することにより、更新されたブロックチェーン512を生成することができる。こうして、フロー500は、ブロックチェーンコミュニティのメンバーに属するユーザに対するアクセス許可(たとえば共有されるセキュアなデータにアクセスするために使用される)の変更を表す記録からなる、変更不能で透明な台帳を、生成したことになる。
【0054】
いくつかの実施形態において、ブロックチェーン508の合意形成は、実用ビザンチン障害耐性(Practical Byzantine Fault Tolerance)(「PBFT」)アルゴリズム、権威証明(Proof of Authority)(「PoA」)および/または消費時間証明(Proof of Elapsed Time)(「PoET」)アルゴリズムのうちの1つ以上を用いて得ることができる。ハイパーレジャーファブリックによって実現されるアルゴリズムのようなPBFTアルゴリズムは、同意したノード間の合意を提供することができる。PBFTの1つの利点は、悪意のあるノードの悪意を緩和できる点であり、これは、信頼性が低い許可台帳において有用となり得る、または、悪意のあるコードによってブロックチェーンコミュニティ内の組織に障害が発生するリスクから守るのに有用となり得る。PoAが有する指定ノードは、十分な(たとえば大半の)指定ノードが同意すれば、トランザクションを更新する。これは、ノードのうちのいくつかは権限を有するがその他のノードは権限を有しない許可された台帳において有用となり得る。PoETは、許可された台帳のノードに実行機会を分散させることに基づく。これは、いずれかのノード(またはノードのサブセット内のいずれか)が、許可された台帳の変更について信頼できるときに有用となり得る。
【0055】
いくつかの実施形態において、合意に達し新たなブロックがブロックチェーンに追加されるとき、このブロックには、前のブロックのハッシュ、タイムスタンプ、ノンス(任意のランダム数)、およびこのブロックに追加中のデータのハッシュが格納される。いくつかの実施形態において、データ自体は暗号化されないので、ブロックチェーン台帳のノードはこのデータを技術的に読み取ることができる。いくつかの実施形態ではデータ自体は暗号化されないが、アイデンティティは保護される。なぜなら、各アイデンティティは(たとえばブロックチェーン内の)アドレスによって参照されるからである。言い換えると、アイデンティティAが「トップシークレット」クリアランスを有することを保護できる。なぜなら、アイデンティティAのアドレスはクリアランスレベルを示すからである。いくつかの実施形態においては、アクセス許可のセットを、「トップシークレット」クリアランスまたはその他何らかの機密に関わるアクセス許可を用いて暗号化することができる。この例において、データベースに解読キーを与えて、妥当性確認ノードに妥当性確認の対象の解読データが与えられるようにすることができる。
【0056】
実施形態は、任意の適切なソフトウェアサービスを活用し、ブロックチェーン技術の各種バージョンを実現することができる。たとえば、実施形態は、ファブリックのような、構成された1つ以上のハイパーレジャープロジェクトを含むことにより、開示された機能を実現することができる。いくつかの実装形態において、ブロックチェーンが活用するデータ処理および暗号関数は、公開鍵、秘密鍵、およびデジタル署名暗号技術、ハッシュ関数および暗号ハッシュ関数(たとえば、セキュアハッシュアルゴリズム(secure hash algorithm)(「SHA」)、SHA−0、SHA−1、SHA−2など)、および、実行可能な計算(たとえばプルーフオブワーク(Proof of Work))シナリオを維持しつつも台帳をセキュアにするために使用されるその他の任意の適切なデータ処理または暗号関数を含み得る。
【0057】
実施形態は、任意の適切な「スマートコントラクト」またはそれに代わる任意の適切なものを実現することもできる。たとえば、ハイパーレジャー「チェーンコード」を、開示されているスマートコントラクト機能を実行するように構成することができる、または、その他任意の適切な自動機能またはコードを実現することができる。
【0058】
いくつかの実施形態において、ユーザのアクセス許可の変更は、ブロックチェーンコミュニティのサブセット間で非公開にしておくことができる。たとえば、ハイパーレジャーファブリックの「チャネル」という特徴を用いることにより、所与のチャネルについてサブセットのメンバー間の非公開通信を実現することができる。その他の実施形態において、同様のコンセプトを有するその他のブロックチェーン実装例があってもよい。この機能は、ブロックチェーンコミュニティ内の当事者間における非公開トランザクションを提供することができる。たとえば、組織Aおよび組織Bは、所与のアイデンティティに対するアクセス許可の変更を申し込むことができるが、この変更は、ブロックチェーンコミュニティの他のメンバーに知られないように隠すことができる。
【0059】
このような実施形態において、データベースはこの非公開トランザクションにアクセスできるので、データベースに対してこの非公開データの閲覧許可が与えられるか、または、このサブセットに対して非公開台帳を生成することができ、非公開台帳は、所有するシステムへのアクセスを公開するとき(およびこれらのシステムがこの非公開台帳に接続するとき)に、使用することができる。これらの実施形態では、監査を参照し、ブロックチェーン台帳の変更は、当事者/組織がアクセスできる台帳に限定される。
【0060】
実施形態は、ブロックチェーン(またはブロックチェーンのコピー)とのインターフェイスのために使用できる1つ以上の分散型アプリケーションまたはアプリを含むこともできる。たとえば、ブロックチェーンコミュニティのメンバーのユーザ(たとえば機密データを共有する組織)は、クライアントコンピューティングデバイス(たとえば、サーバ、ラップトップ、モバイルデバイスなど)で実行されている1つ以上のアプリケーションまたはアプリ(たとえば、モバイルアプリまたは軽量アプリケーション)を用いてブロックチェーンにアクセスすることができる。たとえば、アプリケーションを、機密情報の一部へのアクセスを要求するために、ブロックチェーンコミュニティの機密情報を格納するデータベースと(1つ以上のソフトウェアアプリケーションを用いて)やり取りするように構成してもよい。別の例において、アプリケーションを用いて合意形成し最終的にはブロックチェーンを処理することにより新たなブロックを追加することができる。
【0061】
いくつかの実施形態において、ブロックチェーンコミュニティのメンバーは、既存のセキュリティプロトコルを管理する構成されたシステムを用いて、またはウェブサイト(たとえばカスタムウェブまたはモバイルポータル)を介して、ブロックチェーンとやり取りすることができる。既存のアイデンティティシステムの場合、ユーザの属性は、通常のチャネルを通して(たとえば組織内の役割を変更する、プロジェクトに説明するなどによって)更新することができ、そうすると、アイデンティティシステムは、ブロックチェーンを呼び出し、スマートコントラクトを実行してこれらの変更をユーザのアイデンティティに適用することができる(たとえば、アイデンティティのブロックチェーンアドレスがそのアイデンティティ属性に記録されることに注目する)。いくつかの実施形態において、1つの当事者/組織が関与する場合がある、すなわち、組織の一雇用者に、その組織が所有する機密データベース内のデータホールディングスに対するアクセスが付与される。
【0062】
いくつかの実施形態において、ユーザは、ウェブサイト(たとえばポータル)とやり取りし、ウェブフォームに接続することにより、アクセス許可の変更の詳細を提供することができる。これは、追加/変更(たとえばプロジェクト、リリーサビリティ、グループ、タグなどの)のためのアクセス許可と、変更を実施する対象であるユーザ/アイデンティティのアドレスとを含み得る。ある実施形態において、要求しているユーザのアドレスもこの書き込みに含まれる(たとえば、スマートコントラクトがこのユーザの変更の許可を検査するために)。以下で詳しく説明するように、このようなやり取りは、要求の妥当性確認のためにブロックチェーン上のスマートコントラクトをトリガすることができる。いくつかの実施形態において、スマートコントラクトまたはウェブフォーム内で、その他のワークフローを実行することもできる(たとえば要求を承認するために)。
【0063】
図6は、実施形態の一例に係るブロックチェーン台帳を用いて機密データへのアクセスをセキュアにするための機能の一例を示す。一実施形態において、以下の
図6の機能は、メモリまたはその他のコンピュータ読取可能もしくは有形の媒体に格納されたソフトウェアによって実現され、プロセッサによって実行される。他の実施形態において、各機能は、ハードウェアによって(たとえば、特定用途向け集積回路(「ASIC」)、プログラマブルゲートアレイ(「PGA」)、フィールドプログラマブルゲートアレイ(「FPGA」)などを使用することによって)、または、ハードウェアとソフトウェアとの任意の組み合わせによって、実行されてもよい。
【0064】
602において、第2のエンティティの代理としての第1のエンティティからの、アクセス許可の更新を、受け付けることができ、この更新は、機密データストアへのアクセス許可を変更するものである。
図1を参照して、エンティティ102(またはパートナー104および/または106)の第1のアイデンティティは、エンティティ102の第2のアイデンティティに対するアクセス許可の変更を要求することができる。いくつかの実施形態において、アクセス許可は、データベース114に格納されている機密データをセキュアにすることができる。データベース114は、VPDおよび/またはOracle(登録商標)セキュリティラベルプロトコルを含むセキュリティモデルを実現することができ、アクセス許可は、仮想プライベートデータベースのセキュリティパラメータに対応し得る。ある実施形態において、更新されたアクセス許可は、第2のエンティティに対し、機密データストアへの行レベルのアクセスを提供する。
【0065】
604において、上記更新の妥当性を確認するスマートコントラクトを呼び出すことができる。たとえば、第2のアイデンティティに対するアクセス許可を更新する許可を第1のアイデンティティが有することについて妥当性を確認するスマートコントラクトを呼び出すことができる。ある実施形態において、このような妥当性確認は、アイデンティティ管理システム(たとえばIDCS)と、エンティティ102のための1つ以上のソフトウェアサービスとを用いて実行することができる。
【0066】
606において、更新を、ブロックチェーンコミュニティの複数のメンバーに対して提示することができる。たとえば、妥当性が確認された更新を、ブロックチェーンコミュニティのメンバー(たとえばパートナー104および106)に対して申し出ることができる。ある実施形態において、ブロックチェーン台帳は、第1のエンティティおよび第2のエンティティに対するアクセス許可を検証するために使用される。608において、ブロックチェーンコミュニティの合意形成がなされると、第2のエンティティに対するアクセス許可の更新を実行することができ、この更新は、ブロックチェーンコミュニティに対するアクセス許可を格納するブロックチェーン台帳に追加され、ブロックチェーンコミュニティは、機密データストアへのアクセスを共有する複数の異なる組織を含む。
【0067】
610において、ブロックチェーン台帳の分散したコピーに、この更新を格納することができる。たとえば、新たなブロックをブロックチェーン108に追加することができ、ブロックチェーンコピー110および112に、この新たなブロックを格納することができる。ある実施形態において、ブロックチェーン108は、ブロックチェーンコミュニティのアクセス許可トランザクションの、暗号化された変更不可の台帳であってもよい。
【0068】
612において、第2のアイデンティティに対する更新されたアクセス許可を、ブロックチェーンから取り出すことができる。たとえば、第2のアイデンティティからの、データベース114から機密データを取り出すことを求める要求を、受け付けることができる。データベース114は、この要求を受けたことに応じて、ブロックチェーン108から、第2のアイデンティティに対する更新されたアクセス許可を取り出すことができる。
【0069】
614において、第2のエンティティは、更新されたアクセス許可を用いて、機密情報にアクセスすることができる。ある実施形態において、データベース114は、第2のアイデンティティに対する取り出されたアクセス許可に対応するセキュリティ属性を有する、データベース114に要求された機密情報を、返すことができる。たとえば、更新されたアクセス許可に対応するセキュリティパラメータが対応付けられた(keyed)機密情報へのアクセスを、第2のアイデンティティに対して許可することができる。
【0070】
実施形態は、ブロックチェーン台帳を用いて機密情報に対するアクセス許可を管理する。たとえば、現実世界では、状況によって、機密情報へのアクセスを複数の組織が共有する必要がある。これらの状況は、中央政府のような団体またはエンティティが極秘情報または機密情報であると特定した情報を、国家セキュリティサービスのような団体またはエンティティにサービスを提供するために、共有することを含み得る。それ以外の状況でも、機密または専有情報などに依拠する組織間の合弁事業のように、共有される機密情報から同様の利益を享受することができる。
【0071】
いくつかの実施形態において、各組織におけるアイデンティティ、たとえば個人には、さまざまなレベルの機密情報へのアクセスを付与することができる。たとえば、機密情報をデータベースに格納し、この機密情報に、異なるセキュリティパラメータ(たとえば、セキュリティ分類レベル、タイトル、プロジェクト名、リリースなど)を対応付ける(keyed)ことができる。各組織のアイデンティティに対するアクセス許可は、個々のアクセス許可に対応するセキュリティパラメータが対応付けられた(keyed)機密情報へのアクセスを許可することができる。
【0072】
実施形態は、ブロックチェーン台帳を用いて、アクセス許可およびアクセス許可の更新を管理することにより、各種組織のさまざまなアイデンティティに対し、機密情報へのアクセスをセキュアにする。たとえば、機密情報へのアクセスを共有する各種組織は、ブロックチェーンコミュニティのメンバーを表し得る。ある組織が、そのアイデンティティのうちの1つに対するアクセス許可の更新を要求した場合、一連のアクションをトリガする(たとえばスマートコントラクトを呼び出す)ことによってトランザクションを実行することができる。要求している組織/アイデンティティは、この変更を、ブロックチェーンコミュニティに対して申し出ることができる。ブロックチェーンコミュニティが合意に達すると、スマートコントラクトはこの変更を実行することができる。上記アイデンティティに対するアクセス許可の変更を反映するトランザクションまたはブロックを、ブロックチェーンに追加することができる。
【0073】
したがって、ブロックチェーン台帳は、コミュニティメンバー(たとえば参加している組織)のアイデンティティに対する、最新の透明なアクセス許可を、格納することができる。いくつかの実施形態において、あるアイデンティティが機密情報へのアクセスを要求すると、データベースは、要求しているアイデンティティに対する最新のアクセス許可を取り出すために、ブロックチェーンにクエリすることができる。次に、これらのアクセス許可を用いて、対応する機密情報をデータベースから取り出すことにより、確実に、最新の透明なアクセス許可を用いて、アイデンティティがアクセスを許可された機密情報のみを取り出すことができる。
【0074】
本明細書において説明した本開示の特徴、構造、および特性は、1つ以上の実施形態において任意の適切なやり方で組み合わせてもよい。たとえば、「一実施形態」、「いくつかの実施形態」、「特定の実施形態」、「特定の複数の実施形態」、またはその他同様の表現の使用は、本明細書において、その実施形態に関連して説明した特定の特徴、構造、または特性が、本開示の少なくとも1つの実施形態に含まれ得ることを意味する。よって、「一実施形態」、「いくつかの実施形態」、「特定の実施形態」、「特定の複数の実施形態」という表現、またはその他同様の表現の表示は、本明細書において、すべて必ずしも同一グループの実施形態を指している訳ではなく、記載されている特徴、構造、または特性は、1つ以上の実施形態において任意の適切なやり方で組み合わせてもよい。
【0075】
上記実施形態は、順序が異なるステップで、および/または開示されている構成と異なる構成における要素によって実施し得ることを、当業者は容易に理解するであろう。したがって、本開示は概略を述べた実施形態を考慮しているが、本開示の精神および範囲に含まれる、特定の変更、変形、および代替の構成が明白であることは、当業者にとって明らかであろう。したがって、本開示の範囲を判断するためには以下の請求項を参照する必要がある。