ダイジェスト管理

適用対象: SQL Server 2022 (16.x) Azure SQL DatabaseAzure SQL Managed Instance

データベース ダイジェスト

データベース台帳における最新のブロックのハッシュは、データベース ダイジェストと呼ばれます。 これは、ブロックが生成された時点のデータベース内のすべての台帳テーブルの状態を表します。 データベース ダイジェストの生成は、最近追加されたブロックのハッシュだけが計算されるため、効率的です。

データベース ダイジェストは、システムによって自動的に生成することも、ユーザーが手動で生成することもできます。 後でこれらを使用して、データベースのデータ整合性を確認することができます。

データベース ダイジェストは、最新ブロックのハッシュと、ブロック ID のメタデータを含む JSON ドキュメントの形式で生成されます。 メタデータには、ダイジェストが生成された時刻と、このブロック内の最後のトランザクションのコミット タイムスタンプが含まれます。

検証プロセスとデータベースの整合性は、入力ダイジェストの整合性によって左右されます。 このため、データベースから抽出されるデータベース ダイジェストは、データベースの高い特権を持つユーザーや攻撃者が改ざんできない、信頼できるストレージに保管する必要があります。

データベース ダイジェストの自動生成と保存

台帳は、Azure Blob Storage の不変ストレージ機能および Azure Confidential Ledger と統合されています。 この統合により、Azure においてセキュリティで保護されたストレージ サービスがもたらされ、データベース ダイジェストは改ざんの可能性から保護されます。 この統合により、ユーザーは可用性や地理的なレプリケーションについて心配することなく、簡単でコスト効率の高い方法でダイジェスト管理を自動化できます。 Azure Confidential Ledger は、特権管理者がダイジェストにアクセスすることを心配する可能性があるお客様に対して、より強力な整合性保証を提供します。 この表では、Azure Blob Storage の不変ストレージ機能と Azure Confidential Ledger を比較します。

Azure portal、PowerShell、または Azure CLI を使用して、データベース ダイジェストの自動生成とストレージを構成できます。 詳細については、「自動ダイジェスト ストレージを有効にする」を参照してください。 自動生成とストレージを構成すると、データベース ダイジェストは、30 秒の事前定義された間隔で生成され、選択したストレージ サービスにアップロードされます。 30 秒間隔でシステムでトランザクションが発生しない場合、データベース ダイジェストは生成・アップロードされません。 このメカニズムにより、データベース ダイジェストは、データベースでデータが更新された場合にのみ生成されます。 エンドポイントが Azure Blob Storage の場合、Azure SQL Database や Azure SQL Managed Instance の論理サーバーが、ServerName/DatabaseName/CreationTime のような命名規則で、sqldbledgerdigests という名前の新しいコンテナーを作成します。 同じ名前のデータベースを削除して再作成または復元できるため、作成時刻が必要です。これにより、データベースのさまざまな復元版を同じ名前で作成できます。 詳細については、「ダイジェスト管理に関する考慮事項」を参照してください。

Azure Storage アカウントの不変ポリシー

Azure Storage アカウントを使用してデータベース ダイジェストを保存する場合、プロビジョニング後にコンテナーに不変ポリシーを設定し、改ざんから保護する必要があります。 この不変ポリシーが、Append BLOB に対する保護付きの追加書き込みを許可しており、かつロックされていることを確認してください。

Azure Storage アカウントのアクセス許可

Azure SQL Database または Azure SQL Managed Instance を使用している場合は、論理サーバーやマネージド インスタンス (システム ID) にストレージ BLOB データ共同作成者ロールを割り当て、ダイジェスト書き込みのための十分なロールベースのアクセス制御 (RBAC) アクセス許可を付与します。 アクティブ geo レプリケーションや自動フェールオーバー グループを使用している場合は、Azure Storage アカウントでセカンダリ レプリカにも同じ RBAC アクセス許可が付与されていることを確認してください。

SQL Server を使用している場合は、SQL Server が Azure Storage アカウントに接続・認証できるよう、ダイジェスト コンテナーに対して共有アクセス署名 (SAS) を作成する必要があります。

• Azure Storage アカウント上に sqldbledgerdigests という名前のコンテナーを作成します。
• このコンテナーに対して読み取り、追加、作成、書き込み、一覧表示のアクセス許可を含めたポリシーを作成し、共有アクセス署名キーを生成します。
• ダイジェスト ファイルの保存に使用する sqldbledgerdigests コンテナーに対して、そのパス名と一致する名前で SQL Server 資格情報を作成します。

次の例では、Azure Storage コンテナー、ポリシー、SAS キーが作成済みであることを前提としています。 これは、SQL Server がコンテナー内のダイジェスト ファイルにアクセスするために必要です。

次のコード スニペットでは、<your SAS key> を SAS キーに置き換えます。 SAS キーは 'sr=c&si=<MYPOLICYNAME>&sig=<THESHAREDACCESSSIGNATURE>' のようになります。

CREATE CREDENTIAL [https://ledgerstorage.blob.core.windows.net/sqldbledgerdigests]  
WITH IDENTITY='SHARED ACCESS SIGNATURE',  
SECRET = '<your SAS key>'   

Azure Confidential Ledger のアクセス許可

Azure SQL Database または Azure SQL Managed Instance を使用している場合は、論理サーバーまたはマネージド インスタンス (システム ID) に共同作成者ロールを割り当て、ダイジェスト書き込みのための十分なアクセス許可を付与します。 そのためには、Azure Confidential Ledger のユーザー管理手順に従ってください。

Azure Confidential Ledger と連携するように Azure SQL Managed Instance の NSG ルールを構成する

Azure SQL Managed Instance を使用している場合は、Azure Confidential Ledger と通信できるように仮想ネットワーク規則を構成します。 詳細については、「Azure Confidential Ledger と連携するように Azure SQL Managed Instance の NSG ルールを構成する」を参照してください。

データベース ダイジェストの手動生成と保存

必要に応じてデータベース ダイジェストを生成し、信頼される保管先と見なされるサービスやデバイスにダイジェストを手動で保管することもできます。 たとえば、オンプレミスの Write Once Read Many (WORM) デバイスを保管先として選択することができます。 データベース ダイジェストを手動で生成するには、SQL Server Management Studio または Azure Data Studio で、sys.sp_generate_database_ledger_digest ストアド プロシージャを実行します。

EXECUTE sp_generate_database_ledger_digest;

返される結果セットは、1 行のデータです。 これは、次のように、JSON ドキュメントとして信頼できる保管場所に保存する必要があります。

    {
        "database_name":  "ledgerdb",
        "block_id":  0,
        "hash":  "0xDC160697D823C51377F97020796486A59047EBDBF77C3E8F94EEE0FFF7B38A6A",
        "last_transaction_commit_time":  "2020-11-12T18:01:56.6200000",
        "digest_time":  "2020-11-12T18:39:27.7385724"
    }

アクセス許可

データベース ダイジェストの生成には GENERATE LEDGER DIGEST アクセス許可が必要です。 台帳テーブルに関連するアクセス許可の詳細については、アクセス許可に関するページを参照してください。

ダイジェスト管理に関する考慮事項

データベースの復元

データベースを以前の時点に復元すること (ポイントインタイム リストアとも呼ばれます) は、間違いが発生し、ユーザーがデータベースの状態を以前の時点にすばやく戻す必要がある場合に頻繁に使用される操作です。 生成されたダイジェストを Azure Storage または Azure Confidential Ledger にアップロードすると、これらのダイジェストがマップされるデータベースの "作成時刻" がキャプチャされます。 データベースが復元されるたびに、新しい作成時刻でタグ付けされ、このしくみにより、データベースの異なる「復元版」にまたがってダイジェストを保存できるようになります。 SQL Server の場合、作成時刻は、初めてダイジェストのアップロードが有効になった際の UTC 現在時刻となります。 台帳には、復元操作がいつ発生したかに関する情報が保持されるため、検証プロセスでは、データベースのさまざまなインカーネーション全体で関連するすべてのダイジェストを使用できます。 さらに、ユーザーはすべてのダイジェストでさまざまな作成時刻を調べて、データベースが復元された日時とどの時点まで遡って復元されるかを識別できます。 このデータは不変ストレージに書き込まれるため、この情報も保護されます。

アクティブ geo レプリケーションと Always On 可用性グループ

Azure SQL Database や Azure SQL Managed Instance では、アクティブ geo レプリケーションや自動フェールオーバー グループの構成が可能です。 地理的リージョン間のレプリケーションはパフォーマンス上の理由から非同期であるため、セカンダリ データベースはプライマリと比較して若干遅れる可能性があります。 地理的なフェールオーバーが発生した場合、まだレプリケートされていない最新のデータは失われます。 台帳は、地理的なフェールオーバーが発生した場合に失われる可能性のあるデータをダイジェストが参照しないことを保証するために、地理的セカンダリにレプリケートされたデータのデータベース ダイジェストのみを発行します。 これは、データベース ダイジェストの自動生成と保存にのみ適用されます。 フェールオーバー グループでは、プライマリとセカンダリの両データベースで同じダイジェスト パスが使用されます。 フェールオーバーが発生しても、プライマリとセカンダリの両方のダイジェスト パスは変わりません。

フェールオーバー グループが削除されるかリンクが切断されると、両方のデータベースはプライマリとして動作します。 その時点で、旧セカンダリ データベースのダイジェスト パスが変更され、パスに RemovedSecondaryReplica フォルダーが追加されます。

SQL Server における Always On 可用性グループや Managed Instance リンクでも、アクティブ geo レプリケーションと同じ原則が適用されます。 すべてのトランザクションがセカンダリ レプリカに複製された後に限り、ダイジェストのアップロードが実行されます。

関連するコンテンツ

• 台帳の概要
• 自動ダイジェスト ストレージを有効にする
• sys.sp_generate_database_ledger_digest