翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon QLDB でのデータ検証
Amazon QLDB を使用すると、アプリケーションデータの変更履歴が正確であると信頼できます。QLDB では、イミュータブルトランザクションログ (ジャーナル) をデータストレージに使用します。ジャーナルは、コミット済みデータへの変更をすべて追跡し、完全かつ検証可能な変更履歴を一定の期間にわたって維持します。
QLDB は、SHA-256 ハッシュ関数をマークルツリーベースのモデルで使用して、ジャーナルの暗号化表現 (ダイジェスト) を生成します。ダイジェストは、ある時点におけるデータの変更履歴全体の一意の署名として機能します。ダイジェストを使用して、その署名に関連するドキュメントのリビジョンの整合性を検証します。
トピック
QLDB で検証できるデータの種類
QLDB では、台帳ごとにジャーナルが 1 つ作成されます。ジャーナルには、ジャーナルのパーティションとなる複数のストランドを設けることができます。
注記
QLDB は現在、単一ストランドのジャーナルのみをサポートしています。
ブロックは、トランザクション中にジャーナルストランドにコミットされるオブジェクトです。このブロックには、トランザクションに起因するドキュメントリビジョンを表すエントリオブジェクトが含まれます。QLDB では、個々のリビジョンまたはジャーナルブロック全体を検証できます。
以下の図は、このジャーナルの構造を示したものです。
この図は、トランザクションがドキュメントのリビジョンのエントリを含むブロックとしてジャーナルにコミットされていることを示しています。また、各ブロックが後続のブロックにハッシュチェーンされ、ストランド内のアドレスを指定するシーケンス番号があることも示しています。
ブロック内のデータコンテンツについては、「Amazon QLDB のジャーナルコンテンツ」を参照してください。
データの整合性とは
QLDB におけるデータ整合性とは、台帳のジャーナルが実際にイミュータブルであることを意味します。言い換えると、お客様のデータ (具体的には、各ドキュメントリビジョン) が、以下に該当する状態にあることをいいます。
-
ジャーナル内で最初に書き込まれた場所と同じ場所に存在する。
-
書き込み以降にいかなる方法でも改変されていない。
検証の仕組み
Amazon QLDB での検証の仕組みを理解するために、概念を 4 つの基本コンポーネントに分けることができます。
ハッシュ
QLDB は、SHA-256 暗号化ハッシュ関数を使用して 256 ビットのハッシュ値を作成します。ハッシュは、任意の量の入力データの一意の固定長の署名として機能します。入力の任意の部分 (1 文字またはビットでも) を変更すると、出力ハッシュは完全に変更されます。
以下の図は、SHA-256 ハッシュ関数が、1 桁だけ異なる 2 つの QLDB ドキュメントに対して完全に一意のハッシュ値を作成することを示しています。
SHA-256 ハッシュ関数は一方向です。つまり、出力が与えられたときに入力を計算することは数学的に実行可能ではありません。以下の図は、出力ハッシュ値が与えられたときに入力 QLDB ドキュメントを計算することが不可能であることを示しています。
検証の目的で、次のデータ入力が QLDB でハッシュされます。
-
ドキュメントの改訂
-
PartiQL ステートメント
-
リビジョンのエントリ
-
ジャーナルブロック
ダイジェスト
ダイジェストは、ある時点での台帳のジャーナル全体の暗号表現です。ジャーナルは追加専用であり、ジャーナルブロックはブロックチェーンと同様に配列され、ハッシュチェーンされます。
台帳のダイジェストはいつでもリクエストできます。QLDB はダイジェストを生成してセキュアな出力ファイルとして返します。その後、そのダイジェストを使用して、以前の時点でコミットされたドキュメントのリビジョンの整合性を検証できます。リビジョンで始まり、ダイジェストで終わることによってハッシュを再計算すると、データがその間に変更されていないことが証明されます。
マークルツリー
台帳のサイズが大きくなるにつれて、検証のためにジャーナルの完全なハッシュチェーンを再計算することはますます非効率的になります。QLDB はマークルツリーモデルを使用して、この非効率性を解決します。
マークルツリーは、構造内の各リーフノードがデータブロックのハッシュを表すツリーデータ構造です。リーフ以外の各ノードは、その子ノードのハッシュです。ブロックチェーンで一般的に使用されているマークルツリーを使うと、監査プルーフの仕組みを使って大規模なデータセットを効率よく検証できます。マークルツリーの詳細については、Wikipedia のマークルツリーに関するページ
マークルツリーの QLDB 実装は、ジャーナルの完全なハッシュチェーンから構築されます。このモデルでは、リーフノードはすべての個々のドキュメントリビジョンハッシュのセットです。ルートノードは、ある時点でのジャーナル全体のダイジェストを表します。
マークル監査プルーフを使用すると、台帳の改訂履歴の小さなサブセットのみをチェックすることで、リビジョンを検証できます。これを行うには、特定のリーフノード (リビジョン) からルート (ダイジェスト) までツリーをトラバースします。このトラバーサルパスに沿って、ダイジェストで終わるまで、親ハッシュを計算するために、ノードの兄弟ペアを再帰的にハッシュします。このトラバーサルには、ツリーの log(n) ノードの時間計算量があります。
証明
証明は、指定されたダイジェストとドキュメントリビジョンに対して QLDB が返すノードハッシュの順序付きリストです。これは、マークルツリーモデルによって指定されたリーフノードハッシュ (リビジョン) をルートハッシュ (ダイジェスト) に連鎖させるために必要なハッシュで構成されています。
リビジョンとダイジェストの間でコミットされたデータを変更すると、ジャーナルのハッシュチェーンが壊れ、証明を生成できなくなります。
検証の例
以下の図は、Amazon QLDB のハッシュツリーモデルを示したものです。この図は、ジャーナルストランドのダイジェストを表す、トップルートノードまでロールアップする一連のブロックハッシュを表しています。単一ストランドのジャーナルを持つ台帳では、このルートノードが台帳全体のダイジェストも兼ねます。
ノード [A] が、そのハッシュを検証するドキュメントのリビジョンを含むブロックであると仮定します。ノード B、E、G は、QLDB が証明で示すハッシュの順序付きリストを表します。これらのハッシュではハッシュ A からダイジェストを再計算する必要があります。
ダイジェストを再計算するには、以下の手順を実行します。
-
まず、ハッシュ A をハッシュ B と連結し、その結果をハッシュして D を計算します。
-
D と E を使用して F を計算します。
-
F と G を使用してダイジェストを計算します。
再計算したダイジェストが想定値と一致したら検証は成功です。リビジョンハッシュとダイジェストが与えられた場合、証明のハッシュをリバースエンジニアリングすることは不可能です。したがって、この演習では、リビジョンが実際にダイジェストに対してこのジャーナルの位置に書かれていることを証明します。
データの秘匿化は検証にどのような影響を与えますか?
Amazon QLDB では、DELETE ステートメントは、削除済みとしてマークする新しいリビジョンを作成することによってのみドキュメントを論理的に削除します。QLDB テーブルの履歴にある使用頻度の低いドキュメントリビジョンを完全に削除できるデータの秘匿化オペレーションもサポートしています。
秘匿化オペレーションでは、指定されたリビジョンのユーザーデータのみが削除され、ジャーナルシーケンスとドキュメントのメタデータは変更されません。リビジョンが秘匿化されると、リビジョン内の (data 構造によって表される) ユーザーデータが新しい dataHash フィールドに置き換えられます。このフィールドの値は、削除された data 構造の Amazon Ion ハッシュです。詳細と秘匿化オペレーションの例については、「ドキュメントのリビジョンを秘匿化する」を参照してください。
その結果、台帳は全体的なデータ整合性を維持し、既存の検証 API オペレーションを通じて暗号的に検証できる状態を維持します。これらの API オペレーションを期待どおりに使用して、ダイジェスト (GetDigest) をリクエストし、証明 (GetBlock または GetRevision) をリクエストしてから、返されたオブジェクトを使用して検証アルゴリズムを実行できます。
リビジョンハッシュの再計算
ハッシュを再計算することによって、個々のドキュメントのリビジョンを検証する場合は、そのリビジョンが秘匿化されたかどうかを条件付きで確認する必要があります。リビジョンが秘匿化された場合は、dataHash フィールドに提供されているハッシュ値を使用できます。秘匿化されていない場合は、data フィールドを使用してハッシュを再計算できます。
この条件付きチェックを行うことで、秘匿化されたリビジョンを特定し、適切な処置を取ることができます。例えば、モニタリングのためにデータ操作イベントをログに記録できます。
検証の使用開始
データを検証するには、台帳にダイジェストをリクエストし、後の照合に使用できるよう保存しておく必要があります。ダイジェストによりカバーされる最新のブロックより前にコミットされたすべてのドキュメントリビジョンが、ダイジェストに照らし合わせて検証できる対象となります。
その後、検証対象となる使用可能なリビジョンに関する証明を Amazon QLDB でリクエストします。このプルーフを使用して、ダイジェストを再計算するためのクライアント側 API を呼び出し、リビジョンのハッシュから始めます。過去に保存されたダイジェストがわかっており、QLDB の外部で信頼されている限り、ドキュメントの整合性は、再計算したダイジェストハッシュが保存されているダイジェストハッシュと一致した場合に証明されます。
重要
-
この検証で具体的に証明できることは、このダイジェストを保存した時点から検証を実施する時点までの間に、ドキュメントリビジョンが改変されていないということです。後で検証するリビジョンがジャーナルにコミットされ次第、ダイジェストをリクエストして保存できます。
-
ベストプラクティスとして、定期的にダイジェストをリクエストし、台帳から離れた場所に保管することをお勧めします。台帳でリビジョンをコミットする頻度に基づいて、ダイジェストをリクエストする頻度を決定します。
実際のユースケースにおける暗号化検証の価値について説明する詳細な AWS ブログ記事については、「Amazon QLDB による実際の暗号化検証
」を参照してください。
台帳にダイジェストをリクエストし、データを検証する step-by-step 方法については、以下を参照してください。
