翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon でのデータ検証 QLDB
重要
サポート終了通知: 既存のお客様は、07/31/2025 のサポート終了QLDBまで Amazon を使用できます。詳細については、「Amazon Ledger QLDB を Amazon Aurora Postgre に移行するSQL
Amazon を使用するとQLDB、アプリケーションデータの変更履歴が正確であると信頼できます。QLDB は、データストレージにジャーナル と呼ばれるイミュータブルなトランザクションログを使用します。ジャーナルは、コミット済みデータへの変更をすべて追跡し、完全かつ検証可能な変更履歴を一定の期間にわたって維持します。
QLDB は、Merkle ツリーベースのモデルで 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 ハッシュ関数は 1 つの方法です。つまり、出力が与えられたときに入力を計算することは数学的に不可能です。次の図は、出力ハッシュ値が与えられたときに入力QLDBドキュメントを計算することができないことを示しています。
検証QLDBの目的で、次のデータ入力がハッシュ化されます。
-
ドキュメントの改訂
-
PartiQL ステートメント
-
リビジョンのエントリ
-
ジャーナルブロック
ダイジェスト
ダイジェストは、ある時点での台帳のジャーナル全体の暗号表現です。ジャーナルは追加専用であり、ジャーナルブロックはブロックチェーンと同様に配列され、ハッシュチェーンされます。
台帳のダイジェストはいつでもリクエストできます。QLDB はダイジェストを生成し、安全な出力ファイルとして返します。その後、そのダイジェストを使用して、以前の時点でコミットされたドキュメントのリビジョンの整合性を検証できます。リビジョンで始まり、ダイジェストで終わることによってハッシュを再計算すると、データがその間に変更されていないことが証明されます。
マークルツリー
台帳のサイズが大きくなるにつれて、検証のためにジャーナルの完全なハッシュチェーンを再計算することはますます非効率的になります。QLDB は、Merkle ツリーモデルを使用して、この非効率性に対処します。
マークルツリーは、構造内の各リーフノードがデータブロックのハッシュを表すツリーデータ構造です。リーフ以外の各ノードは、その子ノードのハッシュです。ブロックチェーンで一般的に使用されているマークルツリーを使うと、監査プルーフの仕組みを使って大規模なデータセットを効率よく検証できます。マークルツリーの詳細については、Wikipedia のマークルツリーに関するページ
Merkle ツリーのQLDB実装は、ジャーナルの完全なハッシュチェーンから構築されます。このモデルでは、リーフノードはすべての個々のドキュメントリビジョンハッシュのセットです。ルートノードは、ある時点でのジャーナル全体のダイジェストを表します。
マークル監査プルーフを使用すると、台帳の改訂履歴の小さなサブセットのみをチェックすることで、リビジョンを検証できます。これを行うには、特定のリーフノード (リビジョン) からルート (ダイジェスト) までツリーをトラバースします。このトラバーサルパスに沿って、ダイジェストで終わるまで、親ハッシュを計算するために、ノードの兄弟ペアを再帰的にハッシュします。このトラバーサルには、ツリーの log(n) ノードの時間計算量があります。
証明
証明は、特定のダイジェストとドキュメントリビジョンに対して がQLDB返すノードハッシュの順序付きリストです。これは、マークルツリーモデルによって指定されたリーフノードハッシュ (リビジョン) をルートハッシュ (ダイジェスト) に連鎖させるために必要なハッシュで構成されています。
リビジョンとダイジェストの間でコミットされたデータを変更すると、ジャーナルのハッシュチェーンが壊れ、証明を生成できなくなります。
検証の例
次の図は、Amazon QLDBハッシュツリーモデルを示しています。この図は、ジャーナルストランドのダイジェストを表す、トップルートノードまでロールアップする一連のブロックハッシュを表しています。単一ストランドのジャーナルを持つ台帳では、このルートノードが台帳全体のダイジェストも兼ねます。
ノード [A] が、そのハッシュを検証するドキュメントのリビジョンを含むブロックであると仮定します。次のノードは、証明で QLDBが提供するハッシュの順序付きリストを表します: B 、E 、G 。 これらのハッシュは、ハッシュ 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 フィールドを使用してハッシュを再計算できます。
この条件付きチェックを行うことで、秘匿化されたリビジョンを特定し、適切な処置を取ることができます。例えば、モニタリングのためにデータ操作イベントをログに記録できます。
検証の使用開始
データを検証するには、台帳にダイジェストをリクエストし、後の照合に使用できるよう保存しておく必要があります。ダイジェストによりカバーされる最新のブロックより前にコミットされたすべてのドキュメントリビジョンが、ダイジェストに照らし合わせて検証できる対象となります。
次に、検証する対象リビジョンQLDBの証明を Amazon にリクエストします。この証明を使用して、リビジョンハッシュから始めて、クライアント側APIを呼び出してダイジェストを再計算します。以前に保存したダイジェストが の外部で認識され、信頼QLDBされている限り、再計算されたダイジェストハッシュが保存されたダイジェストハッシュと一致すると、ドキュメントの整合性が証明されます。
重要
-
この検証で具体的に証明できることは、このダイジェストを保存した時点から検証を実施する時点までの間に、ドキュメントリビジョンが改変されていないということです。後で検証するリビジョンがジャーナルにコミットされ次第、ダイジェストをリクエストして保存できます。
-
ベストプラクティスとして、定期的にダイジェストをリクエストし、台帳から離れた場所に保管することをお勧めします。台帳でリビジョンをコミットする頻度に基づいて、ダイジェストをリクエストする頻度を決定します。
詳細 AWS 現実的なユースケースにおける暗号化検証の価値について説明するブログ記事は、「Amazon による実際の暗号化検証QLDB
」を参照してください。
台帳からダイジェストをリクエストし、データを検証する step-by-step 方法については、以下を参照してください。
