Amazon QLDB でのデータ検証 - Amazon Quantum Ledger Database (Amazon QLDB)

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Amazon QLDB でのデータ検証

Amazon QLDB を使用すると、アプリケーションデータの変更履歴が正確であると信頼できます。QLDB では、イミュータブルトランザクションログ (ジャーナル) をデータストレージに使用します。ジャーナルは、コミット済みデータへの変更をすべて追跡し、完全かつ検証可能な変更履歴を一定の期間にわたって維持します。

QLDB は、SHA-256 ハッシュ関数をマークルツリーベースのモデルで使用して、ジャーナルの暗号化表現 (ダイジェスト) を生成します。ダイジェストは、ある時点におけるデータの変更履歴全体の一意の署名として機能します。これにより、その署名に関連するドキュメントのリビジョンの整合性を振り返り、検証することができます。

QLDB で検証できるデータの種類

QLDB では、台帳ごとにジャーナルが 1 つ作成されます。ジャーナルには、ジャーナルのパーティションとなる複数のストランドを設けることができます。

注記

QLDB は現在、単一ストランドのジャーナルのみをサポートしています。

ブロックは、トランザクション中にジャーナルストランドにコミットされるオブジェクトです。このブロックには、トランザクションに起因するドキュメントリビジョンを表すエントリオブジェクトが含まれます。QLDB では、個々のリビジョンまたはジャーナルブロック全体を検証できます。

以下の図は、このジャーナルの構造を示したものです。


                1 つのストランドを構成する一連のハッシュチェーンブロックと、各ブロックのシーケンス番号およびハッシュを示した Amazon QLDB ジャーナル構造図。

この図は、トランザクションがドキュメントのリビジョンのエントリを含むブロックとしてジャーナルにコミットされていることを示しています。また、各ブロックが後続のブロックにハッシュチェーンされ、ストランド内のアドレスを指定するシーケンス番号があることも示しています。

ブロック内のデータコンテンツについては、「Amazon QLDB のジャーナルコンテンツ」を参照してください。

データの整合性とは

QLDB におけるデータ整合性とは、台帳のジャーナルが実際にイミュータブルであることを意味します。言い換えると、お客様のデータ (具体的には、各ドキュメントリビジョン) が、以下に該当する状態にあることをいいます。

  1. ジャーナル内で最初に書き込まれた場所と同じ場所に存在する。

  2. 書き込み以降にいかなる方法でも改変されていない。

検証の仕組み

Amazon QLDB での検証の仕組みを理解するために、概念を 4 つの基本コンポーネントに分けることができます。

ハッシュ

QLDB は、SHA-256 暗号化ハッシュ関数を使用して 256 ビットのハッシュ値を作成します。ハッシュは、任意の量の入力データの一意の固定長の署名として機能します。入力の任意の部分 (1 文字またはビットでも) を変更すると、出力ハッシュは完全に変更されます。


                    SHA-256 暗号化ハッシュ関数が、1 桁だけ異なる 2 つの QLDB Ion ドキュメントに対して完全に一意のハッシュ値を作成することを示す図。

SHA-256 ハッシュ関数は一方向です。つまり、出力が与えられたときに入力を計算することは数学的に実行可能ではありません。


                    出力ハッシュ値が与えられたときに入力 QLDB Ion ドキュメントを計算することは不可能であることを示す図。

検証の目的で、次のデータ入力が QLDB でハッシュされます。

  • ドキュメントの改訂

  • PartiQL ステートメント

  • リビジョンのエントリ

  • ジャーナルブロック

ダイジェスト

ダイジェストは、ある時点での台帳のジャーナル全体の暗号表現です。ジャーナルは追加専用であり、ジャーナルブロックはブロックチェーンと同様に配列され、ハッシュチェーンされます。

QLDB を使用すると、セキュアな出力ファイルとしてダイジェストを生成できます。その後、そのダイジェストを使用して、以前の時点でコミットされたドキュメントのリビジョンの整合性を検証できます。リビジョンで始まり、ダイジェストで終わることによってハッシュを再計算すると、データがその間に変更されていないことが証明されます。

マークルツリー

台帳のサイズが大きくなるにつれて、検証のためにジャーナルの完全なハッシュチェーンを再計算することはますます非効率的になります。QLDB はマークルツリーモデルを使用して、この非効率性を解決します。

マークルツリーは、構造内の各リーフノードがデータブロックのハッシュを表すツリーデータ構造です。リーフ以外の各ノードは、その子ノードのハッシュです。ブロックチェーンで一般的に使用されているマークルツリーを使うと、大規模なデータセットを監査プルーフの仕組みを使って効率よく検証できます。マークルツリーの詳細については、Wikipedia のマークルツリーに関するページを参照してください。マークルツリーにおける監査プルーフとそのユースケース例については、Certificate Transparency サイトの「How Log Proofs Work」を参照してください。

マークルツリーの QLDB 実装は、ジャーナルの完全なハッシュチェーンから構築されます。このモデルでは、リーフノードはすべての個々のドキュメントリビジョンハッシュのセットです。ルートノードは、ある時点でのジャーナル全体のダイジェストを表します。

マークル監査プルーフを使用すると、台帳の改訂履歴の小さなサブセットのみをチェックすることで、リビジョンを検証できます。これを行うには、特定のリーフノード (リビジョン) からルート (ダイジェスト) までツリーをトラバースします。このトラバーサルパスに沿って、ダイジェストで終わるまで、親ハッシュを計算するために、ノードの兄弟ペアを再帰的にハッシュします。このトラバーサルには、ツリーの log(n) ノードの時間計算量があります。

証明

証明は、指定されたダイジェストとドキュメントリビジョンに対して QLDB が返すノードハッシュの順序付きリストです。これは、マークルツリーモデルによって指定されたリーフノードハッシュ (リビジョン) をルートハッシュ (ダイジェスト) に連鎖させるために必要なハッシュで構成されています。

リビジョンとダイジェストの間でコミットされたデータを変更すると、ジャーナルのハッシュチェーンが壊れ、証明を生成できなくなります。

検証の例

以下の図は、Amazon QLDB のハッシュツリーモデルを示したものです。この図は、ジャーナルストランドのダイジェストを表す、トップルートノードまでロールアップする一連のブロックハッシュを表しています。単一ストランドのジャーナルを持つ台帳では、このルートノードが台帳全体のダイジェストも兼ねます。


                ジャーナルストランド内にある一連のブロックハッシュに関する、Amazon QLDB のハッシュツリー図。

ノード [A] が、そのハッシュを検証するドキュメントのリビジョンを含むブロックであると仮定します。次のノードは、QLDB がプルーフで提供するハッシュ (QLDB) の順序付きリストを表しています。B,E,G。 これらのハッシュは、ハッシュ (ハッシュ) からダイジェストを再計算するために必要です。ある

ダイジェストを再計算するには、以下の手順を実行します。

  1. まず、ハッシュ A をハッシュ B と連結し、その結果をハッシュして D を計算します。

  2. DE を使用して F を計算します。

  3. FG を使用してダイジェストを計算します。

再計算したダイジェストが想定値と一致したら検証は成功です。リビジョンハッシュとダイジェストが与えられた場合、証明のハッシュをリバースエンジニアリングすることは不可能です。したがって、この演習では、リビジョンが実際にダイジェストに対してこのジャーナルの位置に書かれていることを証明します。

検証の使用開始

データを検証するには、台帳にダイジェストをリクエストし、後の照合に使用できるよう保存しておく必要があります。ダイジェストによりカバーされる最新のブロックより前にコミットされたすべてのドキュメントリビジョンが、ダイジェストに照らし合わせて検証できる対象となります。

その後、検証対象となる使用可能なリビジョンに関する証明を Amazon QLDB でリクエストします。このプルーフを使用して、ダイジェストを再計算するためのクライアント側 API を呼び出し、リビジョンのハッシュから始めます。過去に保存されたダイジェストがわかっており、QLDB の外部で信頼されている限り、ドキュメントの整合性は、再計算したダイジェストハッシュが保存されているダイジェストハッシュと一致した場合に証明されます。

重要
  • この検証で具体的に証明できることは、このダイジェストを保存した時点から検証を実施する時点までの間に、ドキュメントリビジョンが改変されていないということです。ベストプラクティスとして、後で検証するリビジョンがジャーナルに書き込まれ次第、ダイジェストをリクエストして保存します。

  • ダイジェストをリクエストし、定期的に安全な場所に保存することをお勧めします。台帳でリビジョンをコミットする頻度に基づいて、ダイジェストを保存する頻度を決定します。

    詳細についてAWS現実的なユースケースにおける暗号検証の価値について説明するブログ記事については、Amazon QLDB による実際の暗号化検証

を使用する場合 step-by-step 台帳にダイジェストをリクエストし、その後データを検証する方法のガイドについては、以下を参照してください。