データベース レベルのカスタマー マネージド キーを使用した Transparent Data Encryption (TDE)
適用対象: 
Azure SQL データベース
この記事では、Azure SQL Database のデータベース レベルでカスタマー マネージド キーを使用した Transparent Data Encryption (TDE) について説明します。
Note
データベース レベルの TDE CMK が Azure SQL Database (すべての SQL Database エディション) で使用できます。 Azure SQL Managed Instance、SQL Server オンプレミス、Azure VM、Azure Synapse Analytics (専用 SQL プール (旧称 SQL DW)) では使用できません。
Note
Microsoft Entra ID の、旧称は Azure Active Directory（Azure AD）です。
概要
Azure SQL では、Transparent Data Encryption (TDE) を使用して保存時の暗号化機能を顧客に提供します。 TDE をカスタマー マネージド キー (CMK) で拡張すると、データベース暗号化キーを Azure Key Vault に格納し、TDE 保護機能 (暗号化キー) を暗号化して、保存時のデータ保護を実現できます。 現在、CMK を使用した TDE はサーバー レベルで設定され、そのサーバーに関連付けられているすべての暗号化されているデータベースによって継承されます。 この新しい機能を使用すると、サーバー内の各データベースに対して、TDE 保護機能をカスタマー マネージド キーとして個別に設定できます。 有効で、空ではない encryptionProtector プロパティを持つ Microsoft.Sql/servers/databases リソースはすべて、データベース レベルのカスタマー マネージド キーで構成されています。
このシナリオでは、顧客が所有および管理している Azure Key Vault (AKV) に格納されている非対称キーを、サーバー内の各データベースに対して個別に使用して、TDE 保護機能と呼ばれるデータベース暗号化キー (DEK) を暗号化できます。 キーの追加、キーの削除、各データベースのユーザー割り当てマネージド ID (UMI) の変更を行うためのオプションがあります。 ID の詳細については、Azure の「マネージド ID の種類」を参照してください。
次の機能を使用できます。
- ユーザー割り当てマネージド ID: データベースに単一のユーザー割り当てマネージド ID を割り当てることができます。 この ID は、Azure Key Vault にアクセスし、暗号化キーを管理するために使用できます。
- 暗号化キーの管理: 1 つ以上の暗号化キーをデータベース レベルで追加できるようにし、追加されたキーの 1 つを TDE 保護機能として設定できます。 追加される暗号化キーは、データベースに既に割り当てられているユーザー割り当てマネージド ID を使用して、Azure Key Vault にアクセスします。
- フェデレーション クライアント ID: Azure SQL Database で設定されたフェデレーション クライアント ID を使用して、別の Microsoft Entra テナントの Azure Key Vault のカスタマー マネージド キー (CMK) を有効にして、データベース レベルで TDE 保護機能として設定することもできます。 これにより、別のテナントの Azure Key Vault に格納されているキーを使用して TDE を管理できます。
注意
システム割り当てマネージド ID は、データベース レベルではサポートされていません。
データベース レベルでのカスタマー マネージド TDE の利点
Azure SQL Database を使用してサービスを構築するサービス プロバイダー (独立系ソフトウェア ベンダー (ISV) とも呼ばれます) が増えており、その多くがコンピューティング リソースを複数のデータベースに効率的に分散する方法としてエラスティック プールに移行しています。 ISV は、各顧客のデータベースを共有のエラスティック プールに配置することで、リソースの使用率を最適化するプールの機能を利用しながら、各データベースに十分なリソースを確保できます。
ただし、この方法には 1 つの重要な制限があります。 複数のデータベースが同じ Azure SQL 論理サーバーでホストされている場合、サーバー レベルの TDE 保護機能が共有されます。 ISV は、真のカスタマー マネージド キー (CMK) 機能を顧客に提供することができません。 特にコンプライアンス規制で暗号化キーを完全に制御することが求められている場合、顧客は、独自の暗号化キーを管理できなければ、機密データを ISV のサービスに委託することをためらう可能性があります。
データベース レベル TDE CMK を使用すると、各データベースの TDE 保護機能が、それぞれの ISV 顧客が所有するキー コンテナー内で所有される可能性があるため、ISV は顧客に CMK 機能を提供し、セキュリティの分離を実現することができます。 ISV の顧客に対して実現されるセキュリティ分離は、"キー" と、キーへのアクセスに使用されるID の両方に関して行われます。
次の図は、上記の新機能をまとめたものです。 2 つの個別の Microsoft Entra テナントが表示されます。 Best Services テナントには、DB 1 と DB 2 の 2 つのデータベースを使用する Azure SQL 論理サーバーと、UMI 1 を使用してデータベース DB 1 にアクセスする Key 1 を持つAzure Key Vault 1 が含まれています。 UMI 1 と Key 1 は両方ともサーバー レベルの設定を表します。 既定では、このサーバーで最初に作成されるすべてのデータベースは、CMK を使用する TDE のこの設定を継承します。 Contoso テナントは、Azure Key Vault 2 を含むクライアント テナントを表します。この Azure Key Vault には、Key 2 と UMI 2 の設定を使用して、データベース レベル CMK テナント間サポートの一部としてテナント全体でデータベース DB 2 を評価する Key 2 が含まれています。
テナント間 ID の構成の詳細については、サーバー レベルのドキュメント「Transparent Data Encryption を使ったクロステナント カスタマー マネージド キー」を参照してください。
サポートされるキー管理シナリオ
次のセクションでは、3 つのデータベース (たとえば、Database1、Database2、Database3) で構成されるサーバーがあるとします。
既存のシナリオ
Key1 は、論理サーバー レベルでのカスタマー マネージド キーとして構成されています。 このサーバーの下にあるすべてのデータベースは、同じキーを継承します。
- サーバー - CMK として設定された
Key1 Database1- CMK として使用されるKey1Database2- CMK として使用されるKey1Database3- CMK として使用されるKey1
新しくサポートされるシナリオ: カスタマー マネージド キーで構成された論理サーバー
Key1 は、論理サーバー レベルでのカスタマー マネージド キーとして構成されています。 別のカスタマー マネージド キー (Key2) をデータベース レベルで構成できます。
- サーバー - CMK として設定された
Key1 Database1- CMK として使用されるKey2Database2- CMK として使用されるKey1Database3- CMK として使用されるKey1
注意
論理サーバーが、TDE 用のカスタマー マネージド キーで構成されている場合、この論理サーバー内の個々のデータベースは、Transparent Data Encryption にサービス マネージド キーの使用することを選択できません。
新しくサポートされるシナリオ: サービス マネージド キーを使用して構成された論理サーバー
論理サーバーは、TDE 用のサービス マネージド キー (SMK) を使用して構成されます。 別のカスタマー マネージド キー (Key2) をデータベース レベルで構成できます。
- サーバー - TDE 保護機能として設定されたサービス マネージド キー
Database1- CMK として設定されたKey2Database2- TDE 保護機能として設定されたサービス マネージド キーDatabase3- TDE 保護機能として設定されたサービス マネージド キー
サーバー レベルの暗号化に戻す
Database1 は TDE 用のデータベース レベルのカスタマー マネージド キーで構成され、論理サーバーはサービス マネージド キーで構成されています。 Database1 を、論理サーバー レベルのサービス マネージド キーを使用するように戻すことができます。
注意
論理サーバーが TDE 用の CMK で構成されている場合、データベース レベル CMK で構成されたデータベースをサーバー レベルの暗号化に戻すことはできません。
元に戻す操作は、TDE を使用するときに論理サーバーがサービス マネージド キーで構成されている場合のみサポートされますが、サーバーが、有効な ID を持つソース データベースで使用されるすべてのキーにアクセスできる場合、データベース レベル CMK で構成されたデータベースを CMK で構成されたサーバーに復元することはできます。
キー コンテナーとマネージド ID の要件
Azure Key Vault (AKV) キーとマネージド ID を構成するための同じ要件 (キーの設定や、サーバー レベルのカスタマー マネージド キー (CMK) 機能に適用される 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 キーで使用できます。 ローテーションは、新しいバージョンのキーが検出されるとトリガーされ、24 時間以内に自動的にローテーションされます。 Azure portal、PowerShell、または Azure CLI を使用してキーの自動ローテーションを構成する方法については、「データベース レベルの自動キー ローテーション」を参照してください。
キー管理のアクセス許可
キー コンテナーのアクセス許可モデル (アクセスポリシーまたは Azure RBAC) に応じて、キー コンテナー にアクセスポリシーを作成するか、新しい Azure RBAC ロール割り当てを作成することによって、キー コンテナーへのアクセスを許可できます。
アクセス ポリシーのアクセス許可モデル
DEK の暗号化のために AKV に格納されている TDE 保護機能をデータベースで使用できるようにするには、キー コンテナー管理者が一意の Microsoft Entra ID を使用して、データベースのユーザー割り当てマネージド ID に次のアクセス権を付与する必要があります。
- get - Azure Key Vault 内のキーの公開部分とプロパティを取得します。
- wrapKey - DEK を保護 (暗号化) できるようにします。
- unwrapKey - DEK を保護解除 (復号化) できるようにします。
Azure RBAC アクセス許可モデル
データベースが DEK の暗号化に AKV に格納されている TDE 保護機能を使用するには、一意の Microsoft Entra ID を使用して、データベース ユーザー割り当てマネージド ID にロール Key Vault Crypto Service 暗号化ユーザーを使用して新しい Azure RBAC ロールの割り当てを追加する必要があります。
クロステナントのカスタマー マネージド キー
「Transparent Data Encryption を使ったテナント間カスタマー マネージド キー」では、サーバー レベル CMK のフェデレーション クライアント ID を設定する方法について説明しています。 データベース レベル CMK に対しても同様の設定を行う必要があり、Set-AzSqlDatabase または New-AzSqlDatabase API 要求の一部としてフェデレーション クライアント ID を追加する必要があります。
注意
必要なアクセス許可 ([取得]、[キーを折り返す]、[キーの折り返しを解除]) でマルチテナント アプリケーションがキー コンテナー アクセス ポリシーに追加されていない場合、Azure portal で ID フェデレーションのアプリケーションを使用するとエラーが表示されます。 フェデレーション クライアント ID を構成する前に、アクセス許可が正しく構成されていることを確認します。
Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevert を使用して論理サーバーがサービス マネージド キーで構成されている場合、データベース レベル CMK で構成されたデータベースをサーバー レベルの暗号化に戻すことができます。
「CMK を使用した Transparent Data Encryption (TDE)」で説明されているように、TDE 保護機能にアクセスできない場合、キー アクセスを修正したら、Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevalidation を使用してデータベースにアクセスできるようにすることができます。
Note
「データベース レベルのカスタマー マネージド キーを使用した 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 つだけです。
Note
データベースの名前を変更する場合は、データベースのマネージド ID を再割り当てする必要があります。
既存のデータベースをデータベース レベル CMK に移行する
「データベース レベルのカスタマー マネージド キーを使用した TDE 用の ID とキーの管理」で説明する操作を使用すると、新しいデータベースを作成時にデータベース レベル CMK で構成でき、サービス マネージド キーで構成されたサーバー内の既存のデータベースをデータベース レベル CMK に移行できます。 サーバー レベル CMK または geo レプリケーションで構成されたデータベースを移行するには、以降のセクションで説明する他の手順が必要です。
geo レプリケーションを使用せず、サーバー レベル CMK で構成されたデータベース
- データベースの sys.dm_db_log_info (Transact-SQL) - SQL Server を使用して、アクティブな仮想ログ ファイル (VLF) を探します。
- すべてのアクティブな VLF について、
sys.dm_db_log_infoの結果からvlf_encryptor_thumbprintを記録します。 - データベースの sys.dm_database_encryption_keys (Transact-SQL) - SQL Server ビューを使用して
encryptor_thumbprintをチェックします。encryptor_thumbprintを記録します。 - Get-AzSqlServerKeyVaultKey コマンドレットを使用して、論理サーバーで構成されているすべてのサーバー レベル キーを取得します。 結果から、上記の結果のリストと一致する同じサムプリントを持つキーを選択します。
- ID および暗号化保護機能と共に、移行するデータベースに対してデータベース更新 API を呼び出します。
-UserAssignedIdentityId、-AssignIdentity、-KeyList、-EncryptionProtector、(必要に応じて-FederatedClientId) パラメーターを使用した Set-AzSqlDatabase を使用して、上記のキーをデータベース レベルのキーとして渡します。
重要
データベース更新要求で使用される ID は、入力として渡されるすべてのキーにアクセスできる必要があります。
geo レプリケーションを使用し、サーバー レベル CMK で構成されたデータベース
- 前のセクションで説明した手順 (1) から (4) に従って、以降に必要なキーのリストを取得します。
- Set-AzSqlDatabase と
-KeyListパラメーターを使用して、ID と上記のキーをデータベース レベルのキーとして使用し、移行するプライマリおよびセカンダリ データベースに対してデータベース更新 API を呼び出します。 まだ暗号化保護機能を設定しないでください。 - 最初に、データベースでプライマリ保護機能として使用するデータベース レベルのキーをセカンダリ データベースに追加する必要があります。 Set-AzSqlDatabase と
-KeyListを使用して、このキーをセカンダリ データベースに追加します。 - 暗号化保護機能キーをセカンダリ データベースに追加したら、Set-AzSqlDatabase と
-EncryptionProtectorパラメーターを使用して、プライマリ データベースでそのキーを暗号化保護機能として設定します。 - (4) で説明したとおりに、セカンダリ データベースでキーを暗号化保護機能として設定します。
重要
サーバー レベルのサービス マネージド キーと geo レプリケーションを使用して構成されたデータベースを移行するには、このセクションの (3)、(4)、(5) に従います。
geo レプリケーションと高可用性
アクティブ geo レプリケーション と フェールオーバー グループの両方のシナリオでは、関連するプライマリおよびセカンダリ データベースを同じキー コンテナー (任意のリージョン内)、または個別のキー コンテナーのいずれかにリンクできます。 個別のキー コンテナーがプライマリおよびセカンダリ サーバーにリンクされている場合、顧客は、キー コンテナー間でキー マテリアルを一貫性のあるものに保つ責任があります。これにより、リージョンの停止によってプライマリにアクセスできなくなり、フェールオーバーがトリガーされた場合に、同期されている geo セカンダリが、同じキーを使用して、リンクされているキー コンテナーから引き継ぐことができます。 最大 4 つのセカンダリを構成でき、チェーン (セカンダリのセカンダリ) はサポートされていません。
データベース レベル CMK で構成されたデータベースのアクティブ geo レプリケーションを確立するには、有効なユーザー割り当てマネージド ID とプライマリ データベースで使用されている現在のキーのリストを使用してセカンダリ レプリカを作成する必要があります。 現在のキーのリストは、必要なフィルターとクエリ パラメーターを使用して、または PowerShell と Azure CLI を使用して、プライマリ データベースから取得できます。 このようなデータベースの geo レプリケーションを設定するために必要な手順は次のとおりです。
- Get-AzSqlDatabase コマンドと
-ExpandKeyListおよび-KeysFilter "current"パラメーターを使用して、プライマリ データベースで使用されているキーのリストを事前に入力します。 すべてのキーを取得する場合は-KeysFilterを除外します。 - ユーザー割り当てマネージド ID (およびテナント間アクセスを構成する場合はフェデレーション クライアント ID) を選択します。
- New-AzSqlDatabaseSecondary を使用して新しいデータベースをセカンダリとして作成し、ソース データベースから取得したキーの事前入力されたリストと上記の ID (およびテナント間アクセスを構成する場合はフェデレーション クライアント ID) を、
-KeyList、-AssignIdentity、-UserAssignedIdentityId、-EncryptionProtector(さらに必要に応じて-FederatedClientId) パラメーターを使用して、API 呼び出しで提供します。 - New-AzSqlDatabaseCopy と、前の手順と同じパラメーターを使用して、データベースのコピーを作成します。
重要
データベース レベル CMK で構成されたデータベースには、データベース レベル CMK で構成されたレプリカ (コピー) が必要です。 このレプリカでは、サーバー レベルの暗号化設定を使用することはできません。
フェールオーバー グループで、データベース レベル CMK で構成されたデータベースを使用するには、プライマリ レプリカと同じ名前のセカンダリ レプリカを作成する上記の手順をセカンダリ サーバーで使用する必要があります。 このセカンダリ レプリカを構成したら、データベースをフェールオーバー グループに追加できます。
データベース レベルの CMK で構成されたデータベースでは、フェールオーバー グループに追加された場合、自動化されたセカンダリ作成はサポートされません。
詳細については、「データベース レベルのカスタマー マネージド キーを使用する Transparent Data Encryption の geo レプリケーションとバックアップ復元を構成する」では、REST API、PowerShell、Azure CLI を使用して geo レプリケーションとフェールオーバー グループを設定する方法について説明しています。
注意
サーバー レベル CMK の CMK を使用する Transparent Data Encryption (TDE) に関するページで取り上げられている geo レプリケーションと高可用性に関するすべてのベスト プラクティスは、データベース レベル CMK に適用されます。
データベース レベルでカスタマー マネージド キーを使用した TDE を使用するデータベースのバックアップと復元
Azure Key Vault のキーを使用して TDE でデータベースを暗号化すると、新しく生成されるバックアップも同じ TDE 保護機能で暗号化されます。 TDE 保護機能を変更しても、データベースのバックアップは、最新の TDE 保護機能を使用するように "更新されません"。 データベース レベルで構成された Azure Key Vault の TDE 保護機能で暗号化されたバックアップを復元するには、キー素材がターゲットのデータベースに提供されていることを確認します。 データベースのバックアップを復元できるように、TDE 保護機能の古いバージョンをすべてキー コンテナーに保持しておくことをお勧めします。
重要
データベースに設定できる TDE 保護機能は 1 つだけです。 ただし、追加キーを TDE 保護機能としてマークしなくても、復元時に複数の追加キーをデータベースに渡すことができます。 これらのキーは DEK の保護には使用されませんが、バックアップ対応するサムプリントを持つキーでファイルが暗号化されている場合は、バックアップからの復元時に使用できます。
ポイントインタイム リストア
データベース レベルのカスタマー マネージド キーを使用して構成されたデータベースを特定の時点に復元するには、次の手順が必要です。
- Get-AzSqlDatabase コマンドと
-ExpandKeyListおよび-KeysFilter "2023-01-01"パラメーターを使用して、プライマリ データベースで使用されているキーのリストを事前に入力します。2023-01-01は、データベースを復元する特定時点の例です。 すべてのキーを取得する場合は-KeysFilterを除外します。 - ユーザー割り当てマネージド ID (およびテナント間アクセスを構成する場合はフェデレーション クライアント ID) を選択します。
- Restore-AzSqlDatabase と
-FromPointInTimeBackupパラメーターを使用し、上記の手順から取得したキーの事前入力されたリストと、上記の ID (およびテナント間アクセスを構成する場合はフェデレーション クライアント ID) を、-KeyList、-AssignIdentity、-UserAssignedIdentityId、-EncryptionProtector、(必要に応じて-FederatedClientId) パラメーターを使用して API 呼び出しで提供します。
注意
すべての有効なキーを持つ -EncryptionProtector プロパティを使用しないでデータベースを復元すると、サーバー レベルの暗号化を使用するようにデータベースがリセットされます。 これは、データベース レベルのカスタマー マネージド キー構成をサーバー レベルのカスタマー マネージド キー構成に戻す場合に役立ちます。
削除済みのデータベースの復元
データベース レベルのカスタマー マネージド キーを使用して構成されたデータベースの削除されたデータベースを復元するには、次の手順が必要です。
- Get-AzSqlDeletedDatabaseBackup と
-ExpandKeyListパラメーターを使用して、プライマリ データベースで使用されているキーのリストを事前に入力します。 ソース データベースで使用されていたすべてのキーを渡すことをお勧めします。ただし、代わりに、削除時間によって提供されるキーを-KeysFilterとして使用して復元することもできます。 - ユーザー割り当てマネージド ID (およびテナント間アクセスを構成する場合はフェデレーション クライアント ID) を選択します。
- 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 復元先に渡す必要があります。
データベース レベル CMK を使用する SQL Database のバックアップ復旧と Powershell、Azure CLI、REST API の使用例について詳しくは、「データベース レベルのカスタマー マネージド キーを使用する Transparent Data Encryption の 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 がフラッシュされ、別のキーローテーションを実行できるようになります。
予想よりも長くログを保持しているものがあると思われる場合は、次のドキュメントを参照してトラブルシューティングを行ってください。
- 使用可能な
log_truncation_holdup_reason値の sys.dm_db_log_stats (Transact-SQL)。 - 満杯になったトランザクション ログのトラブルシューティング (エラー 9002)
次のステップ
さまざまなデータベース レベルの CMK 操作については、次のドキュメントを確認してください。