ダイジェスト管理

  • [アーティクル]

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

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

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

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

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

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

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

Note

SQL Serverにおけるデータベースダイジェストの自動生成と保存は、Azure Storageアカウントのみをサポートしています。

台帳は、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 の論理サーバーは、sqldbledgerdigests という名前の新しいコンテナを作成し、次のような命名パターンを使用します：ServerName/DatabaseName/CreationTime 作成時間が必要なのは、同じ名前のデータベースを一旦削除し、再作成またはリストアすることで、同じ名前のデータベースをさまざまな形で使用できるようにするためである。 詳細については、ダイジェスト管理に関する考察を参照のこと。

Note

SQL Server の場合、コンテナーはユーザーが手動で作成する必要があります。

Azure ストレージ アカウントの不変ポリシー

データベースダイジェストの保存に Azure ストレージ アカウントを使用する場合は、プロビジョニング後にコンテナで不変性ポリシーを構成して、データベースダイジェストが改ざんから保護されるようにします。 不変ポリシーで追加 BLOB への保護された追加書き込みが許可され、ポリシーがロックされていることを確認します。

Azure ストレージ アカウントのアクセス許可

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

SQL Server を使用する場合は、ダイジェスト コンテナーに Shared Access Signature (SAS) を作成して、SQL Server が Azure ストレージ アカウントに対して接続して認証できるようにする必要があります。

  • sqldbledgerdigests という名前 のコンテナーを Azure ストレージ アカウントに作成します。
  • 読み取り、追加、作成、書き込み、および一覧表示のアクセス許可を持つコンテナーにポリシーを作成し、Shared Access Signature キーを生成します。
  • ダイジェストファイル ストレージに使用する 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 を使用する場合、論理サーバーまたはマネージドインスタンス（System Identity）に 投稿者ロールを追加して、ダイジェストを書き込むのに十分なアクセス許可があることを確認してください。 これを行うには、Azure Confidential Ledger ユーザー管理の手順に従います。

Note

SQL Serverにおけるデータベースダイジェストの自動生成と保存は、Azure Storageアカウントのみをサポートしています。

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

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

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

必要に応じてデータベース ダイジェストを生成し、信頼される保管先と見なされるサービスやデバイスにダイジェストを手動で保管することもできます。 たとえば、オンプレミスの 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 時刻です。 台帳には、復元操作がいつ発生したかに関する情報が保持されるため、検証プロセスでは、データベースのさまざまなインカーネーション全体で関連するすべてのダイジェストを使用できます。 さらに、ユーザーはすべてのダイジェストでさまざまな作成時刻を調べて、データベースが復元された日時とどの時点まで遡って復元されるかを識別できます。 このデータは不変ストレージに書き込まれるため、この情報も保護されます。

Note

Azure SQL でデータベース バックアップのネイティブ復元を行う場合は、Azure Portal、PowerShell、または Azure CLI を使用してダイジェスト パスを手動で変更する必要があります。

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

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

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

データベースが SQL Server の Always On 可用性グループの一部または Managed Instance のリンクである場合は、アクティブ geo レプリケーションと同じ原則が使用されます。 ダイジェストのアップロードは、すべてのトランザクションがセカンダリ レプリカにレプリケートされている場合にのみ行われます。

関連するコンテンツ