次の方法で共有

データベース レベルのカスタマー マネージド キーを使用した Transparent Data Encryption (TDE)

適用対象:Azure SQL データベース

この記事では、Azure SQL Database のデータベース レベルでカスタマー マネージド キーを使用した Transparent Data Encryption (TDE) について説明します。

注

データベース レベルの TDE CMK が Azure SQL Database (すべての SQL Database エディション) で使用できます。 Azure SQL Managed Instance、SQL Server オンプレミス、Azure VM、Azure Synapse Analytics (専用 SQL プール (旧称 SQL DW)) では使用できません。

注

Microsoft Entra ID の、旧称は Azure Active Directory（Azure AD）です。

概要

Azure SQL では、Transparent Data Encryption (TDE) を使用して保存時の暗号化機能を顧客に提供します。 カスタマーマネージドキー (CMK) を使用して TDE を拡張することにより、TDE プロテクタ (暗号化キー) がデータベースの暗号化キーを暗号化する Azure Key Vault または Azure Managed HSM に格納され、保存されているデータを保護します。 CMK を含む TDE はサーバー レベルで設定でき、そのサーバーに関連付けられているすべての暗号化されたデータベースによって継承されます。 TDE 保護機能は、サーバー内のデータベースごとに個別にカスタマー マネージド キーとして設定することもできます。 有効で、空ではない Microsoft.Sql/servers/databases プロパティを持つ encryptionProtector リソースはすべて、データベース レベルのカスタマー マネージド キーで構成されています。

このシナリオでは、顧客所有でカスタマー マネージドの Azure Key Vault または Azure Managed HSM に格納されている非対称キーを、サーバー内のデータベースごとに個別に使用して、TDE 保護機能と呼ばれるデータベース暗号化キー (DEK) を暗号化できます。 キーの追加、キーの削除、各データベースのユーザー割り当てマネージド ID (UMI) の変更を行うためのオプションがあります。 ID の詳細については、Azure の「マネージド ID の種類」を参照してください。

次の機能を使用できます。

  • ユーザー割り当てマネージド ID: データベースに単一のユーザー割り当てマネージド ID を割り当てることができます。 この ID を使用して、Azure Key Vault または Azure Managed HSM にアクセスし、暗号化キーを管理できます。
  • 暗号化キーの管理: 1 つ以上の暗号化キーをデータベース レベルで追加できるようにし、追加されたキーの 1 つを TDE 保護機能として設定できます。 追加される暗号化キーは、データベースに既に割り当てられているユーザー割り当てマネージド ID を使用して、Azure Key Vault または Azure Managed HSM にアクセスします。
  • フェデレーション クライアント ID: Azure SQL Database で設定されたフェデレーション クライアント ID を使用して、別の Microsoft Entra テナントの Azure Key Vault または Azure Managed HSM のカスタマー マネージド キー (CMK) をデータベース レベルで TDE 保護機能として設定することもできます。 これにより、別のテナントの Azure Key Vault または Azure Managed HSM に格納されているキーを使用して TDE を管理できます。

注

システム割り当てマネージド ID は、データベース レベルではサポートされていません。

データベース レベルでのカスタマー マネージド TDE の利点

Azure SQL Database を使用してサービスを構築するサービス プロバイダー (独立系ソフトウェア ベンダー (ISV) とも呼ばれます) が増えており、その多くがコンピューティング リソースを複数のデータベースに効率的に分散する方法としてエラスティック プールに移行しています。 ISV は、各顧客のデータベースを共有のエラスティック プールに配置することで、リソースの使用率を最適化するプールの機能を利用しながら、各データベースに十分なリソースを確保できます。

ただし、この方法には 1 つの重要な制限があります。 複数のデータベースが同じ Azure SQL 論理サーバーでホストされている場合、サーバー レベルの TDE 保護機能が共有されます。 ISV は、真のカスタマー マネージド キー (CMK) 機能を顧客に提供することができません。 特にコンプライアンス規制で暗号化キーを完全に制御することが求められている場合、顧客は、独自の暗号化キーを管理できなければ、機密データを ISV のサービスに委託することをためらう可能性があります。

データベース レベルの TDE CMK を使用すると、ISV は顧客に CMK 機能を提供し、セキュリティの分離を実現できます。各データベースの TDE 保護機能は、所有するキー コンテナーまたはマネージド HSM の各 ISV 顧客が所有する可能性があるためです。 ISV の顧客に対して実現されるセキュリティ分離は、"キー" と、キーへのアクセスに使用されるID の両方に関して行われます。

次の図は、上記の新機能をまとめたものです。 2 つの個別の Microsoft Entra テナントが表示されます。 Best Services テナントには、DB 1 と DB 2 の 2 つのデータベースを使用する Azure SQL 論理サーバーと、Azure Key Vault 1 を使用してデータベース Key 1 にアクセスする DB 1 を持つUMI 1 が含まれています。 UMI 1 と Key 1 は両方ともサーバー レベルの設定を表します。 既定では、このサーバーで最初に作成されるすべてのデータベースは、CMK を使用する TDE のこの設定を継承します。 Contoso テナントは、Azure Key Vault 2 を含むクライアント テナントを表します。この Azure Key Vault には、Key 2 と DB 2 の設定を使用して、データベース レベル CMK テナント間サポートの一部としてテナント全体でデータベース Key 2 を評価する UMI 2 が含まれています。

データベース レベルでのカスタマー マネージド TDE のセットアップと機能

テナント間 ID の構成の詳細については、サーバー レベルのドキュメント「Transparent Data Encryption を使ったクロステナント カスタマー マネージド キー」を参照してください。

サポートされるキー管理シナリオ

次のセクションでは、3 つのデータベース (たとえば、Database1、Database2、Database3) で構成されるサーバーがあるとします。

既存のシナリオ

Key1 は、論理サーバー レベルでのカスタマー マネージド キーとして構成されています。 このサーバーの下にあるすべてのデータベースは、同じキーを継承します。

  • サーバー - CMK として設定された Key1
  • Database1 - CMK として使用される Key1
  • Database2 - CMK として使用される Key1
  • Database3 - CMK として使用される Key1

新しくサポートされるシナリオ: カスタマー マネージド キーで構成された論理サーバー

Key1 は、論理サーバー レベルでのカスタマー マネージド キーとして構成されています。 別のカスタマー マネージド キー (Key2) をデータベース レベルで構成できます。

  • サーバー - CMK として設定された Key1
  • Database1 - CMK として使用される Key2
  • Database2 - CMK として使用される Key1
  • Database3 - CMK として使用される Key1

注

論理サーバーが、TDE 用のカスタマー マネージド キーで構成されている場合、この論理サーバー内の個々のデータベースは、Transparent Data Encryption にサービス マネージド キーの使用することを選択できません。

新しくサポートされるシナリオ: サービス マネージド キーを使用して構成された論理サーバー

論理サーバーは、TDE 用のサービス マネージド キー (SMK) を使用して構成されます。 別のカスタマー マネージド キー (Key2) をデータベース レベルで構成できます。

  • サーバー - TDE 保護機能として設定されたサービス マネージド キー
  • Database1 - CMK として設定された Key2
  • Database2 - TDE 保護機能として設定されたサービス マネージド キー
  • Database3 - TDE 保護機能として設定されたサービス マネージド キー

サーバー レベルの暗号化に戻す

Database1 は TDE 用のデータベース レベルのカスタマー マネージド キーで構成され、論理サーバーはサービス マネージド キーで構成されています。 Database1 を、論理サーバー レベルのサービス マネージド キーを使用するように戻すことができます。

注

論理サーバーが TDE 用の CMK で構成されている場合、データベース レベル CMK で構成されたデータベースをサーバー レベルの暗号化に戻すことはできません。

元に戻す操作は、TDE を使用する場合に論理サーバーがサービス マネージド キーで構成されている場合にのみサポートされますが、データベース レベルの CMK で構成されたデータベースは、サーバーが有効な ID を持つソース データベースによって使用されているすべてのキーにアクセスできる場合、CMK で構成されたサーバーに復元できます。

Azure Key Vault と Azure Managed HSM - マネージド ID の要件

サーバー レベルのカスタマー マネージド キー (CMK) 機能に適用される ID に付与されるキー設定やアクセス許可など、Azure Key Vault または Azure Managed HSM キーとマネージド ID を構成する場合と同じ要件が、データベース レベルの CMK にも適用されます。 詳細については、「CMK を使用した Transparent Data Encryption」および CMK を使用したマネージド IDに関するページを参照してください。

キー管理

データベースの TDE 保護機能のローテーションは、データベースを保護する新しい非対称キーに切り替えることを意味します。 キーのローテーションはオンライン操作であり、数秒で完了します。 この操作では、データベース全体ではなく、データベース暗号化キーの暗号化の解除と再暗号化のみが行われます。 有効なユーザー割り当てマネージド ID がデータベースに割り当てられると、データベース レベルでのキーのローテーションは、データベースの暗号化保護機能プロパティの更新を伴うデータベース CRUD 操作になります。 キーをローテーションするには、Set-AzSqlDatabase とプロパティ -EncryptionProtector を使用することができます。 データベース レベル CMK で構成された新しいデータベースを作成するには、New-AzSqlDatabase と -EncryptionProtector、-AssignIdentity、-UserAssignedIdentityId パラメーターを使用することができます。

同様の要求を使用し、データベース リソースの keys プロパティを変更することで、新しいキーを追加したり、既存のキーをデータベースから削除したりすることができます。 Set-AzSqlDatabase と、パラメーター -KeyList および -KeysToRemove をこれらの操作に使用できます。 暗号化保護機能、ID、キーの設定を取得するには、Get-AzSqlDatabase を使用できます。 既定では、Azure Resource Manager リソース Microsoft.Sql/servers/databases には、データベースに構成された TDE 保護機能とマネージド ID のみが表示されます。 キーの完全なリストを展開するには、-ExpandKeyList などの他のパラメーターが必要です。 さらに、-KeysFilter "current" や特定の時点の値 (たとえば 2023-01-01) を使用して、現在使用されているキーと過去の特定の時点で使用されたキーを取得できます。

キーの自動ローテーション

自動キー ローテーションはデータベース レベルで使用でき、Azure Key Vault または Azure Managed HSM キーで使用できます。 ローテーションは、新しいバージョンのキーが検出されるとトリガーされ、24 時間以内に自動的にローテーションされます。 Azure portal、PowerShell、または Azure CLI を使用してキーの自動ローテーションを構成する方法については、「データベース レベルの自動キー ローテーション」を参照してください。

キー管理のアクセス許可

使用するキー ボールトの種類を選択してください。

キー コンテナーのアクセス許可モデル (アクセスポリシーまたは Azure RBAC) に応じて、キー コンテナー にアクセスポリシーを作成するか、新しい Azure RBAC ロール割り当てを作成することによって、キー コンテナーへのアクセスを許可できます。

アクセス ポリシーのアクセス許可モデル

データベースが DEK の暗号化に Azure Key Vault に格納されている TDE 保護機能を使用するには、Azure Key Vault 管理者は、一意の Microsoft Entra ID を使用して、データベース ユーザー割り当てマネージド ID に対する次のアクセス権を付与する必要があります。

  • get - Azure Key Vault 内のキーの公開部分とプロパティを取得します。
  • wrapKey - DEK を保護 (暗号化) できるようにします。
  • unwrapKey - DEK を保護解除 (復号化) できるようにします。

Azure RBAC アクセス許可モデル

データベースが DEK の暗号化に Azure Key Vault に格納されている TDE 保護機能を使用するには、その一意の Microsoft Entra ID を使用して、データベース ユーザー割り当てマネージド ID に Key Vault Crypto Service Encryption ユーザー ロールを持つ新しい Azure RBAC ロールの割り当てを追加する必要があります。

クロステナントのカスタマー マネージド キー

「Transparent Data Encryption を使ったテナント間カスタマー マネージド キー」では、サーバー レベル CMK のフェデレーション クライアント ID を設定する方法について説明しています。 データベース レベル CMK に対しても同様の設定を行う必要があり、Set-AzSqlDatabase または New-AzSqlDatabase API 要求の一部としてフェデレーション クライアント ID を追加する必要があります。

注

必要なアクセス許可 (Get、Wrap Key、Unwrap Key) を使用してマルチテナント アプリケーションがキー コンテナーまたはマネージド HSM に追加されていない場合、Azure portal で ID フェデレーションにアプリケーションを使用するとエラーが表示されます。 フェデレーション クライアント ID を構成する前に、アクセス許可が正しく構成されていることを確認します。

Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevert を使用して論理サーバーがサービス マネージド キーで構成されている場合、データベース レベル CMK で構成されたデータベースをサーバー レベルの暗号化に戻すことができます。

「CMK を使用した Transparent Data Encryption (TDE)」で説明されているように、TDE 保護機能にアクセスできない場合、キー アクセスを修正したら、Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevalidation を使用してデータベースにアクセスできるようにすることができます。

注

データベース レベルのカスタマー マネージド キーを使用した TDE の ID と キーの管理では、PowerShell、Azure CLI、REST API の例と共に、データベース レベル CMK の ID およびキー管理操作について詳しく説明します。

その他の考慮事項

  • CMK を使用した TDE を既にサーバー レベルで有効にしている場合は、特定のデータベースに対して CMK を設定すると、サーバー レベル CMK 設定がオーバーライドされます (データベースの DEK は、データベース レベルの TDE 保護機能で再暗号化されます)。
  • 論理サーバー レベルのキーの変更またはローテーションは、データベース レベル CMK の設定に影響することはなく、データベースでは引き続き独自の CMK 設定が使用されます。
  • データベース レベル CMK は、Transact-SQL (T-SQL) ではサポートされていません。
  • 論理サーバーのユーザー割り当てマネージド ID (UMI) をデータベース レベルで使用することができます。 ただし、データベース レベル CMK には、指定された UMI を使用することをお勧めします。
  • サーバー レベルのテナント間 CMK 設定は、データベース レベル CMK で構成された個々のデータベースには影響することはなく、データベースでは引き続き、独自のシングル テナントまたはクロス テナント構成が使用されます。
  • データベース レベルで設定できるユーザー割り当てマネージド ID は 1 つだけです。

注

データベースの名前を変更する場合は、データベースのマネージド ID を再割り当てする必要があります。

既存のデータベースをデータベース レベル CMK に移行する

「データベース レベルのカスタマー マネージド キーを使用した TDE 用の ID とキーの管理」で説明する操作を使用すると、新しいデータベースを作成時にデータベース レベル CMK で構成でき、サービス マネージド キーで構成されたサーバー内の既存のデータベースをデータベース レベル CMK に移行できます。 サーバー レベル CMK または geo レプリケーションで構成されたデータベースを移行するには、以降のセクションで説明する他の手順が必要です。

geo レプリケーションを使用せず、サーバー レベル CMK で構成されたデータベース

  1. データベースの sys.dm_db_log_info (Transact-SQL) - SQL Server を使用して、アクティブな仮想ログ ファイル (VLF) を探します。
  2. すべてのアクティブな VLF について、vlf_encryptor_thumbprint の結果から sys.dm_db_log_info を記録します。
  3. データベースの sys.dm_database_encryption_keys (Transact-SQL) - SQL Server ビューを使用して encryptor_thumbprint をチェックします。 encryptor_thumbprint を記録します。
  4. Get-AzSqlServerKeyVaultKey コマンドレットを使用して、論理サーバーで構成されているすべてのサーバー レベル キーを取得します。 結果から、上記の結果のリストと一致する同じサムプリントを持つキーを選択します。
  5. ID および暗号化保護機能と共に、移行するデータベースに対してデータベース更新 API を呼び出します。 、-UserAssignedIdentityId、-AssignIdentity、-KeyList、(必要に応じて -EncryptionProtector) パラメーターを使用した -FederatedClientId を使用して、上記のキーをデータベース レベルのキーとして渡します。

重要

データベース更新要求で使用される ID は、入力として渡されるすべてのキーにアクセスできる必要があります。

geo レプリケーションを使用し、サーバー レベル CMK で構成されたデータベース

  1. 前のセクションで説明した手順 (1) から (4) に従って、以降に必要なキーのリストを取得します。
  2. Set-AzSqlDatabase と -KeyList パラメーターを使用して、ID と上記のキーをデータベース レベルのキーとして使用し、移行するプライマリおよびセカンダリ データベースに対してデータベース更新 API を呼び出します。 まだ暗号化保護機能を設定しないでください。
  3. 最初に、データベースでプライマリ保護機能として使用するデータベース レベルのキーをセカンダリ データベースに追加する必要があります。 Set-AzSqlDatabase と -KeyList を使用して、このキーをセカンダリ データベースに追加します。
  4. 暗号化保護機能キーをセカンダリ データベースに追加したら、Set-AzSqlDatabase と -EncryptionProtector パラメーターを使用して、プライマリ データベースでそのキーを暗号化保護機能として設定します。
  5. (4) で説明したとおりに、セカンダリ データベースでキーを暗号化保護機能として設定します。

重要

サーバー レベルのサービス マネージド キーと geo レプリケーションを使用して構成されたデータベースを移行するには、このセクションの (3)、(4)、(5) に従います。

geo レプリケーションと高可用性

アクティブ geo レプリケーションとフェールオーバー グループのどちらのシナリオでも、関連するプライマリ データベースとセカンダリ データベースは、同じキー コンテナーまたはマネージド HSM (任意のリージョン) にリンクすることも、キー コンテナーまたはマネージド HSM を分離することもできます。 別のキー コンテナーまたはマネージド HSM がプライマリ サーバーとセカンダリ サーバーにリンクされている場合、お客様はキー コンテナーまたはマネージド HSM 間でキー マテリアルを一貫性を維持する責任を負います。そのため、geo セカンダリが同期され、リージョンの停止によってプライマリがアクセスできなくなったりフェールオーバーがトリガーされた場合に、リンクされたキー コンテナーまたはマネージド HSM から同じキーを使用して引き継ぐことができます。 最大 4 つのセカンダリを構成でき、チェーン (セカンダリのセカンダリ) はサポートされていません。

データベース レベル CMK で構成されたデータベースのアクティブ geo レプリケーションを確立するには、有効なユーザー割り当てマネージド ID とプライマリ データベースで使用されている現在のキーのリストを使用してセカンダリ レプリカを作成する必要があります。 現在のキーのリストは、必要なフィルターとクエリ パラメーターを使用して、または PowerShell と Azure CLI を使用して、プライマリ データベースから取得できます。 このようなデータベースの geo レプリケーションを設定するために必要な手順は次のとおりです。

  1. Get-AzSqlDatabase コマンドと -ExpandKeyList および -KeysFilter "current" パラメーターを使用して、プライマリ データベースで使用されているキーのリストを事前に入力します。 すべてのキーを取得する場合は -KeysFilter を除外します。
  2. ユーザー割り当てマネージド ID (およびテナント間アクセスを構成する場合はフェデレーション クライアント ID) を選択します。
  3. New-AzSqlDatabaseSecondary を使用して新しいデータベースをセカンダリとして作成し、ソース データベースから取得したキーの事前入力されたリストと上記の ID (およびテナント間アクセスを構成する場合はフェデレーション クライアント ID) を、-KeyList、-AssignIdentity、-UserAssignedIdentityId、-EncryptionProtector (さらに必要に応じて -FederatedClientId) パラメーターを使用して、API 呼び出しで提供します。
  4. New-AzSqlDatabaseCopy と、前の手順と同じパラメーターを使用して、データベースのコピーを作成します。

重要

データベース レベル CMK で構成されたデータベースには、データベース レベル CMK で構成されたレプリカ (コピー) が必要です。 このレプリカでは、サーバー レベルの暗号化設定を使用することはできません。

フェールオーバー グループで、データベース レベル CMK で構成されたデータベースを使用するには、プライマリ レプリカと同じ名前のセカンダリ レプリカを作成する上記の手順をセカンダリ サーバーで使用する必要があります。 このセカンダリ レプリカを構成したら、データベースをフェールオーバー グループに追加できます。

データベース レベルの CMK で構成されたデータベースでは、フェールオーバー グループに追加された場合、自動化されたセカンダリ作成はサポートされません。

詳細については、「 データベース レベルのカスタマー マネージド キーを使用した透過的なデータ暗号化のために geo レプリケーションとバックアップ復元を構成 する」では、REST API、PowerShell、Azure CLI を使用して geo レプリケーションとフェールオーバー グループを設定する方法について説明します。

注

サーバー レベル CMK の CMK を使用する Transparent Data Encryption (TDE) に関するページで取り上げられている geo レプリケーションと高可用性に関するすべてのベスト プラクティスは、データベース レベル CMK に適用されます。

データベース レベルでカスタマー マネージド キーを使用した TDE を使用するデータベースのバックアップと復元

データベースが Azure Key Vault または Azure Managed HSM のキーを使用して TDE で暗号化されると、新しく生成されたバックアップも同じ TDE 保護機能で暗号化されます。 TDE 保護機能を変更しても、データベースのバックアップは、最新の TDE 保護機能を使用するように "更新されません"。 データベース レベルで構成された Azure Key Vault または Azure Managed HSM から TDE 保護機能を使用して暗号化されたバックアップを復元するには、キー マテリアルがターゲット データベースに提供されていることを確認します。 データベース バックアップを復元できるように、古いバージョンの TDE 保護機能をすべてキー コンテナーまたはマネージド HSM に保持することをお勧めします。

重要

データベースに設定できる TDE 保護機能は 1 つだけです。 ただし、追加キーを TDE 保護機能としてマークしなくても、復元時に複数の追加キーをデータベースに渡すことができます。 これらのキーは DEK の保護には使用されませんが、バックアップ対応するサムプリントを持つキーでファイルが暗号化されている場合は、バックアップからの復元時に使用できます。

ポイントインタイム リストア

データベース レベルのカスタマー マネージド キーを使用して構成されたデータベースを特定の時点に復元するには、次の手順が必要です。

  1. Get-AzSqlDatabase コマンドと -ExpandKeyList および -KeysFilter "2023-01-01" パラメーターを使用して、プライマリ データベースで使用されているキーのリストを事前に入力します。 2023-01-01 は、データベースを復元する特定時点の例です。 すべてのキーを取得する場合は -KeysFilter を除外します。
  2. ユーザー割り当てマネージド ID (およびテナント間アクセスを構成する場合はフェデレーション クライアント ID) を選択します。
  3. Restore-AzSqlDatabase と -FromPointInTimeBackup パラメーターを使用し、上記の手順から取得したキーの事前入力されたリストと、上記の ID (およびテナント間アクセスを構成する場合はフェデレーション クライアント ID) を、-KeyList、-AssignIdentity、-UserAssignedIdentityId、-EncryptionProtector、(必要に応じて -FederatedClientId) パラメーターを使用して API 呼び出しで提供します。

注

すべての有効なキーを持つ -EncryptionProtector プロパティを使用しないでデータベースを復元すると、サーバー レベルの暗号化を使用するようにデータベースがリセットされます。 これは、データベース レベルのカスタマー マネージド キー構成をサーバー レベルのカスタマー マネージド キー構成に戻す場合に役立ちます。

削除済みのデータベースの復元

データベース レベルのカスタマー マネージド キーを使用して構成されたデータベースの削除されたデータベースを復元するには、次の手順が必要です。

  1. Get-AzSqlDeletedDatabaseBackup と -ExpandKeyList パラメーターを使用して、プライマリ データベースで使用されているキーのリストを事前に入力します。 ソース データベースで使用されていたすべてのキーを渡すことをお勧めします。ただし、代わりに、削除時間によって提供されるキーを -KeysFilter として使用して復元することもできます。
  2. ユーザー割り当てマネージド ID (およびテナント間アクセスを構成する場合はフェデレーション クライアント ID) を選択します。
  3. Restore-AzSqlDatabase と -FromDeletedDatabaseBackup パラメーターを使用し、上記の手順から取得したキーの事前入力されたリストと、上記の ID (およびテナント間アクセスを構成する場合はフェデレーション クライアント ID) を、-KeyList、-AssignIdentity、-UserAssignedIdentityId、-EncryptionProtector、(必要に応じて -FederatedClientId) パラメーターを使用して API 呼び出しで提供します。

geo リストア

データベース レベルのカスタマー マネージド キーを使用して構成されたデータベースの geo 復元には、次の手順が必要です。

  • Get-AzSqlDatabaseGeoBackup と -ExpandKeyList を使用してすべてのキーを取得し、プライマリ データベースで使用されているキーのリストを事前に入力します。
  • ユーザー割り当てマネージド ID (およびテナント間アクセスを構成する場合はフェデレーション クライアント ID) を選択します。
  • Restore-AzSqlDatabase と -FromGeoBackup パラメーターを使用し、上記の手順から取得したキーの事前入力されたリストと、上記の ID (およびテナント間アクセスを構成する場合はフェデレーション クライアント ID) を、-KeyList、-AssignIdentity、-UserAssignedIdentityId、-EncryptionProtector、(必要に応じて -FederatedClientId) パラメーターを使用して API 呼び出しで提供します。

重要

データベースを復元するには、データベースで使用されるすべてのキーを保持することをお勧めします。 また、これらのすべてのキーを復元先に渡すこともお勧めします。

注

長期バックアップリテンション期間 (LTR) バックアップでは、バックアップで使用されるキーの一覧は提供されません。 LTR バックアップを復元するには、ソース データベースで使用されるすべてのキーを LTR 復元先に渡す必要があります。

PowerShell、Azure CLI、REST API を使用した例を使用したデータベース レベル CMK を使用した SQL Database のバックアップ復旧の詳細については、「 データベース レベルのカスタマー マネージド キーを使用した透過的なデータ暗号化のための geo レプリケーションとバックアップ復元の構成」を参照してください。

制限事項

データベース レベルのカスタマー マネージド キー機能では、データベースの現在のプライマリ保護機能とは異なる古いキーでデータベース仮想ログ ファイルが暗号化されている場合、キーのローテーションはサポートされません。 この場合にスローされるエラーは次のとおりです。

PerDatabaseCMKKeyRotationAttemptedWhileOldThumbprintInUse: アクティブなトランザクションが古いキーで暗号化されたログを保持している場合、データベース レベルでの TDE 保護機能のキー ローテーションはブロックされます。

このシナリオをさらに理解するために、次のタイムラインについて考えてみましょう。

データベース レベルのカスタマー マネージド キーで構成されたデータベースでのキー ローテーションのタイムラインの例。

  • 時刻 t0 = 暗号化を使用しないでデータベースが作成されます
  • 時刻 t1 = このデータベースは、データベース レベルのカスタマー マネージド キーである Thumbprint A によって保護されます。
  • 時刻 t2 = データベース保護機能は、新しいデータベース レベルのカスタマー マネージド キー Thumbprint B にローテーションされます。
  • 時刻 t3 = Thumbprint C への保護機能変更が要求されます。
  • アクティブな VLF が Thumbprint A を使用している場合、ローテーションは許可されません。
  • アクティブな VLF が Thumbprint A を使用していない場合、ローテーションは許可されます。

データベースの sys.dm_db_log_info (Transact-SQL) - SQL Server ビューを使用して、アクティブな仮想ログ ファイルを探すことができます。 最初のキーで暗号化されたアクティブな VLF が表示されます (例: Thumbprint A)。 データ挿入によって十分なログが生成されると、この古い VLF がフラッシュされ、別のキーローテーションを実行できるようになります。

予想よりも長くログを保持しているものがあると思われる場合は、次のドキュメントを参照してトラブルシューティングを行ってください。

次のステップ

さまざまなデータベース レベルの CMK 操作については、次のドキュメントを確認してください。