Azure Key Vault を使用した SQL Server TDE 拡張キー管理を設定する
適用対象: SQL Server
この記事では、SQL Server Connector for Azure Key Vault をインストールして構成します。
Note
Microsoft Entra ID の、旧称は Azure Active Directory(Azure AD)です。
Azure Key Vault (AKV) を使用した拡張キー管理は、SQL Server 2022 (16.x) 累積的な更新プログラム 12 以降の SQL Server on Linux 環境で使用できます。 同じステップに従いますが、ステップ 3 と 4 はスキップします。
前提条件
SQL Server インスタンスで Azure Key Vault の使用を開始する前に、次の前提条件を満たしていることを確認してください。
Azure サブスクリプションが必要です。
Azure PowerShell バージョン 5.2.0 以降をインストールしておくこと。
Microsoft Entra テストを作成する。
「Azure Key Vault を使用した拡張キー管理 (SQL Server)」を読んで、Azure Key Vault を使用した拡張キー管理 (EKM) の保存の原理について熟知していること。
SQL Server コンピューター上のレジストリを変更できます。
実行中の SQL Server のバージョンに応じた Visual Studio C++ 再頒布可能パッケージのバージョンをインストールしておくこと。
SQL Server のバージョン Visual Studio C++ 再頒布可能パッケージのバージョン 2008、2008 R2、2012、2014 Visual Studio 2013 の Visual C++ 再頒布可能パッケージ 2016, 2017, 2019, 2022 Visual Studio 2015 の Visual C++ 再頒布可能パッケージ ファイアウォールの内側またはプロキシ サーバーで SQL Server Connector for Azure Key Vault を使用する予定の場合、ファイアウォールの背後にある Azure Key Vault へのアクセスを熟知してください。
Note
SQL Server 2022 (16.x) CU 14 以降のバージョンでは、SQL Server on Linux では、Azure Key Vault を使用した TDE 拡張キー管理がサポートされています。 このガイドの手順 3 と手順 4 は、SQL Server on Linux では必要ありません。
手順 1: Microsoft Entra サービス プリンシパルを設定する
SQL Server インスタンスのアクセス許可を Azure Key Vault に付与するためには、Microsoft Entra ID にサービス プリンシパル アカウントが必要です。
Azure portal にサインインして、以下のいずれかを実行します。
[Microsoft Entra ID] ボタンを選択します。
[その他のサービス] を選択してから、[すべてのサービス] ウィンドウに [Microsoft Entra ID] と入力します。
以下を実行して、Microsoft Entra ID でアプリケーションを登録します。 詳しい段階的な手順については、Azure Key Vault のブログ投稿である、「Azure Key Vault - 段階的な説明」の「アプリケーションの ID を取得する」セクションを参照してください。
[Microsoft Entra ID] リソースの [管理] セクションで、[アプリの登録] を選択します。
アプリの登録 ページで、新しい登録 を選択します。
[アプリケーションの登録] ペインで、アプリのユーザー向け表示名を入力してから、[登録] を選択します。
左ペインで [証明書とシークレット] > [クライアント シークレット] > [新しいクライアント シークレット] を選択します。
[クライアント シークレットの追加] で、説明と適切な有効期限を入力してから、[追加] を選択します。 24 か月を超える有効期限を選択することはできません。 詳細については、「クライアント シークレットの追加」を参照してください。
[証明書とシークレット] ウィンドウの [値] で、SQL Server で非対称キーを作成するために使用するクライアント シークレットの値の横にある [コピー] ボタンを選択します。
左側のペインで [概要] を選択してから、[アプリケーション (クライアント) ID] ボックスで、SQL Server で非対称キーを作成するために使用する値をコピーします。
手順 2: キー コンテナーを作成する
キー コンテナーの作成方法を選択します。
Azure portal を使用してキー コンテナーを作成する
Azure portal を使用してキー コンテナーを作成し、それに Microsoft EntraD プリンシパルを追加できます。
リソース グループを作成する。
Azure portal で作成するすべての Azure リソースは、キー コンテナーを格納するために作成するリソース グループに含まれている必要があります。 この例のリソース名は DocsSampleRG です。 すべてのキー コンテナー名はグローバルに一意である必要があるため、リソース グループとキー コンテナーには独自の名前を選択します。
[リソースグループを作成します] ペインの [プロジェクトの詳細] で、値を入力してから、[確認および作成] を選択します。
Azure portal で、キー コンテナー サービスを検索または選択してキー コンテナーを作成します。 [作成] を選択します
[キー コンテナーの作成] ウィンドウで、[基本] タブを選択します。タブの適切な値を入力します。消去保護を有効にすることもお勧めします。
[アクセス構成] タブには、[Azure ロールベースのアクセス制御] または [Vault アクセス ポリシー] を選択するオプションがあります。 両方のオプションについて説明しますが、Azure ロールベースのアクセス制御 オプションをお勧めします。 詳細については、「アクセス モードの概要」を参照してください。
[ネットワーク] タブは既定値のままにする、またはキーコンテナーのネットワーク設定を構成することもできます。 キー コンテナーでファイアウォールを使用する場合は、[Allow trusted Microsoft services to bypass the firewall]\(信頼された Microsoft サービスがファイアウォールをバイパスすることを許可する\) オプションを有効にする必要があります。ただし、プライベート エンドポイント接続を使用している場合は、このオプションを有効にする必要はありません。 詳細については、「Azure Key Vault のファイアウォールと仮想ネットワークを構成する」を参照してください。
[レビュー + 作成] ボタンを選択してキー コンテナーを作成します。
Azure ロールベースのアクセス制御
推奨方法は、Azure ロールベースのアクセス制御 (RBAC) を使用して、キー コンテナーにアクセス許可を割り当てることです。 この方法を使用すると、より詳細なレベルでユーザー、グループ、およびアプリケーションにアクセス許可を割り当てることができます。 管理プレーン (Azure ロールの割り当て) とデータ プレーン (キー コンテナー アクセス ポリシー) で、キー コンテナーにアクセス許可を割り当てることができます。 アクセス ポリシーのみを使用できる場合は、このセクションをスキップして、[Vault アクセス ポリシー] セクションに移動できます。 Azure Key Vault RBAC アクセス許可の詳細については、「キー コンテナー データ プレーン操作用の Azure 組み込みロール」を参照してください。
作成したキー コンテナー リソースに移動し、[アクセス制御 (IAM)] 設定を選択します。
[追加] > [ロール割り当ての追加] の順に選択します。
EKM アプリケーションでは、ラップ操作とラップ解除操作を実行するために、キー コンテナー暗号化サービスの暗号化ユーザーロールが必要です。 [キー コンテナー暗号化サービスの暗号化ユーザー] を検索してロールを選択します。 [次へ] を選択します。
[メンバー] タブで、[メンバーの選択] オプションを選択し、手順 1 で作成した Microsoft Entra アプリケーションを検索します。 このアプリケーションを選択してから [選択] ボタンを押します。
[確認と割り当て] を 2 回選択して、ロールの割り当てを完了します。
キーを作成するユーザーには、キー コンテナー 管理者 ロールが必要です。 [キー コンテナー管理者] を検索してロールを選択します。 [次へ] を選択します。
前の手順と同様に、キーを作成するメンバーを追加し、ロールを割り当てます。
コンテナー アクセス ポリシー
Note
[Azure ロールベースのアクセス制御] オプションを使用している場合は、このセクションをスキップできます。 アクセス許可モデルを変更する場合は、キー コンテナーの [アクセス構成] メニューに移動します。 キー コンテナーの管理のための正確なアクセス許可があることを確認します。 詳細については、「Key Vault で Azure RBAC アクセス許可を有効にする」を参照してください。
[アクセス構成] タブから、[Vault アクセス ポリシー] を選択します。 既存のキー コンテナーを使用している場合は、キー コンテナー リソースから [アクセス ポリシー] メニューを選択し、[作成] を選択できます。
[アクセス ポリシーの作成] ウィンドウで、[キー管理操作] オプションから [取得] と [一覧表示] のアクセス許可の選択します。 [暗号化操作] オプションから [キーのラップ解除] と [キーのラップ] のアクセス許可を選択します。 [次へ] を選択します
[プリンシパル] タブで、手順 1 で作成したアプリケーションを選択します。
[次へ]、[作成] の順に選択します。
キーの作成
[キー コンテナー] ウィンドウで [キー] を選択し、[生成/インポート] オプションを選択します。 これにより [キーの作成] ウィンドウが開きます。 キー コンテナー名を入力します。 [生成] オプションを選択し、キーの名前を入力します。 SQL Server コネクタを使用する場合、キー名に使用できる文字は、"a ~ z"、"A ~ Z"、"0 ~ 9"、"-" に限られます。また、26 文字が長さの上限となります。
キーの種類は [RSA] を、RSA キー サイズ は [2048] を使用します。 EKM では現在、RSA キーのみがサポートされています。 アクティブ化と有効期限の日付を適宜設定し、[有効] を [はい] に設定します。
ベスト プラクティス
すばやいキー復旧を確保し、Azure 以外のデータにアクセスできるようにするには、次のベスト プラクティスをお勧めします。
ローカル ハードウェア セキュリティ モジュール (HSM) デバイス上で暗号化キーをローカルに作成します。 SQL Server によってサポートされるように、必ず非対称の RSA 2048 または 3072 キーを作成してください。
暗号化キーを Azure Key Vault にインポートします。 このプロセスについては、以降のセクションで説明します。
Azure Key Vault で初めてキーを使用する前に、
Backup-AzureKeyVaultKey
PowerShell コマンドレットを使用して、Azure Key Vault キーのバックアップを実行します。キーに何らかの変更を加える場合 (ACL の追加、タグの追加、キー属性の追加など) は、必ずもう一度 Azure Key Vault キーのバックアップを実行してください。
Note
キーのバックアップは、任意の場所に保存できるファイルを返す Azure Key Vault キー操作です。
ファイアウォールまたはプロキシ サーバーの背後で SQL Server Connector for Azure Key Vault を使用すると、トラフィックが遅延またはブロックされた場合にパフォーマンスに影響する可能性があります。 ファイアウォールの背後にある Access Azure Key Vault について理解し、正しい規則が適用されていることを確認してください。
オプション - Azure Key Vault マネージド HSM (ハードウェア セキュリティ モジュール) を構成する
Azure Key Vault マネージド HSM (ハードウェア セキュリティ モジュール) は、最新バージョンの SQL Server コネクタと Azure SQL を使用する場合、SQL Server と Azure Virtual Machines (VM) 上の SQL Server でサポートされます。 マネージド HSM は、フルマネージド、高可用性、シングルテナント HSM サービスです。 マネージド HSM は、暗号化操作とキー ストレージ用のセキュリティで保護された基盤を提供します。 マネージド HSM は、最も厳格なセキュリティとコンプライアンスの要件を満たすように設計されています。
手順 2 では、Azure Key Vault でキー コンテナーとキーを作成する方法について説明しました。 必要に応じて、Azure Key Vault マネージド HSM を使用して、SQL Server コネクタで使用するキーを格納または作成できます。 次に手順を示します。
Azure Key Vault マネージド HSM を作成します。 これは、Azure portal を使用して実行できます。具体的には、Azure Key Vault マネージド HSM サービスを検索して新しいリソースを作成するか、Azure CLI、PowerShell、または ARM テンプレートを使用して実行します。
マネージド HSM のアクティブ化。 HSM をアクティブにできるのは、マネージド HSM の作成時に割り当てられた指定された管理者だけです。 これを行うには、Azure portal でマネージド HSM リソースを選択し、リソースの [概要] メニューで [セキュリティ ドメインのダウンロード] を選択します。 次に、マネージド HSM をアクティブ化するためのクイックスタートのいずれかに従います。
Microsoft Entra サービス プリンシパルがマネージド HSM にアクセスするためのアクセス許可を付与します。 マネージド HSM 管理者ロールでは、キーを作成するためのアクセス許可は付与されません。 手順 2 と同様に、EKM アプリケーションでは、ラップ操作とラップ解除操作を実行するために、マネージド HSM 暗号化ユーザーまたはマネージド HSM 暗号化サービスの暗号化ユーザー ロールが必要です。 ロールの割り当てのプリンシパルを追加するときに、種類として [Enterprise アプリケーション] を選択します。 詳細については、「マネージド HSM のローカル RBAC 組み込みロール」を参照してください。
Azure Key Vault マネージド HSM サービス メニューの [設定] で、[キー] を選択します。 [キー] ウィンドウで、[バックアップの生成/インポート/復元] を選択してキーを作成するか、既存のキーをインポートします。
Note
マネージド HSM にアクセスするための資格証明を作成する場合、ID は
<name of Managed HSM>.managedhsm.azure.net
です。この ID は、Azure Key Vault マネージド HSM の [概要] で、Azure portal の [HSM URI] として確認できます。キーの自動ローテーションは、Azure Key Vault マネージド HSM でサポートされています。 詳細については、「Azure Managed HSM でキーの自動ローテーションを構成する」を参照してください。
Azure Key Vault マネージド HSM をサポートするには、SQL Server コネクタ バージョン 15.0.2000.440 以降が必要です。
マネージド HSM はプライベート エンドポイント接続をサポートします。 詳しくは、「マネージド HSM と Azure Private Link を統合する」をご覧ください。 この構成では、Azure Key Vault マネージド HSM [ネットワーク] 設定に対して、Microsoft の信頼されたサービス バイパス のオプションを有効にする必要があります。
手順 3: SQL Server コネクタのインストール
Microsoft ダウンロード センターから SQL Server コネクタをダウンロードします。 このダウンロードは、SQL Server コンピューターの管理者が行う必要があります。
Note
- バージョン 1.0.0.440 以前の SQL Server コネクタは置き換えられ、運用環境ではサポートされなくなりました。「SQL Server コネクタのアップグレード」の「SQL Server コネクタのメンテナンスとトラブルシューティング」ページの手順を使用してください。
- バージョン 1.0.3.0 以降の SQL Server コネクタでは、関連するエラー メッセージがトラブルシューティングのために Windows イベント ログにレポートされます。
- バージョン 1.0.4.0 以降、21Vianet が運営する Azure、Azure Germany、Azure Government を含むプライベートの Azure クラウドがサポートされています。
- バージョン 1.0.5.0 では、サムプリントのアルゴリズムについて破壊的変更があります。 1.0.5.0 にアップグレードした後、データベースの復元でエラーが発生する可能性があります。 詳細については、サポート技術情報の記事 447099 を参照してください。
- バージョン 1.0.5.0 (タイムスタンプが 2020 年 9 月) 以降の SQL Server コネクタで、メッセージのフィルター処理とネットワーク要求の再試行ロジックがサポートされます。
- 更新されたバージョン 1.0.5.0 (TimeStamp: 2020 年 11 月) 以降、SQL Server コネクタでは RSA 2048、RSA 3072、RSA-HSM 2048、RSA-HSM 3072 キーがサポートされています。
- 更新済みのバージョン 1.0.5.0 (タイムスタンプ: 2020 年 11 月) 以降、Azure Key Vault 内の特定のキー バージョンを参照できます。
デフォルトでコネクタは C:\Program Files\SQL Server Connector for Microsoft Azure Key Vault
にインストールされています。 この場所は、セットアップ中に変更することができます。 変更する場合は、次のセクションでスクリプトを調整します。
コネクタ用のインターフェイスはありませんが、正常にインストールされた場合はコンピューターに Microsoft.AzureKeyVaultService.EKM.dll
がインストールされます。 このアセンブリは、CREATE CRYPTOGRAPHIC PROVIDER
ステートメントを使用して SQL Server に登録する必要がある暗号化 EKM プロバイダー DLL です。
SQL Server コネクタのインストールでは、必要に応じて、SQL Server の暗号化で使用するサンプル スクリプトをダウンロードすることもできます。
SQL Server コネクタのエラー コードの説明、構成設定、またはメンテナンス タスクを確認するには、以下を参照してください。
手順 4: EKM プロバイダーをサポートするレジストリ キーを追加する
警告
レジストリの変更は、実行内容を正確に把握しているユーザーが実行する必要があります。 レジストリを正しく変更しないと、重大な問題が発生する可能性があります。 保護のために、レジストリを変更する前に、バックアップします。 問題が起こった場合は、レジストリを復元できます。
SQL Server がインストールされ、実行されていることを確認します。
regeditを実行して、レジストリ エディターを開きます。
SQL Server Cryptographic Provider
レジストリ キーをHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
に作成する。 完全なパスはHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider
です。SQL Server Cryptographic Provider
レジストリ キーを右クリックし、[アクセス許可] を選択します。SQL Server Cryptographic Provider
レジストリ キーの [フル コントロール] アクセス許可を、SQL Server サービスを実行しているユーザー アカウントに提供します。[Apply](適用) 、 [OK] の順に選択します。
レジストリ エディターを閉じて、SQL Server サービスを再起動します。
Note
フェールオーバー クラスター インスタンスで EKM または Azure Key Vault による TDE を使用する場合、レジストリがノード間で同期できるように、追加ステップを完了して
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider
をクラスター レジストリ チェックポイント ルーチンに追加する必要があります。 同期により、フェールオーバーとキーのローテーション後のデータベースの復旧が容易になります。レジストリ キーをクラスター レジストリ チェックポイント ルーチンに追加するには、PowerShell で次のコマンドを実行します。
Add-ClusterCheckpoint -RegistryCheckpoint "SOFTWARE\Microsoft\SQL Server Cryptographic Provider" -Resourcename "SQL Server"
手順 5: SQL Server を構成する
このセクションの各操作に最低限必要な権限レベルについては、「B. よく寄せられる質問」を参照してください。
master
データベースを構成する
sqlcmd を実行するか、SQL Server Management Studio を開きます。
次の Transact-SQL スクリプトを実行して、EKM を使用するように SQL Server を構成します。
-- Enable advanced options. USE master; GO EXEC sp_configure 'show advanced options', 1; GO RECONFIGURE; GO -- Enable EKM provider EXEC sp_configure 'EKM provider enabled', 1; GO RECONFIGURE;
SQL Server に EKM プロバイダーとして SQL Server コネクタを登録します。
Azure Key Vault の EKM プロバイダーである SQL Server コネクタを使用して暗号化サービス プロバイダーを作成します。 この例では、プロバイダー名は
AzureKeyVault_EKM
です。CREATE CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM FROM FILE = 'C:\Program Files\SQL Server Connector for Microsoft Azure Key Vault\Microsoft.AzureKeyVaultService.EKM.dll'; GO
Note
ファイル パスは 256 文字以内で指定してください。
キー コンテナーを使用するために SQL Server ログイン用の SQL Server 資格情報を設定します。
キー コンテナーのキーを使用して暗号化を実行する各ログインに対し、資格情報を追加する必要があります。 その例を次に示します。
SQL Server の暗号化シナリオをセットアップして管理するためにキー コンテナーを使用する 管理者のログイン。
その他、TDE をはじめとする SQL Server の暗号化機能を有効にする可能性がある SQL Server ログイン。
資格情報とログインとの間には一対一の対応関係が存在します。 つまり、各ログインには一意の資格情報が必要です。
この Transact-SQL スクリプトを以下のように変更します。
IDENTITY
引数 (DocsSampleEKMKeyVault
) を編集し、Azure Key Vault を参照するようにします。- グローバル Azure を使用している場合は、
IDENTITY
引数を「手順 2: キー コンテナーを作成する」のお使いの Azure Key Vault の名前に置き換えます。 - プライベート Azure クラウド (Azure Government、Microsoft Azure operated by 21Vianet、Azure Germany など) を使用している場合は、
IDENTITY
引数を「PowerShell を使用してキー コンテナーとキーを作成する」セクションの手順 3 で返された Vault URI に置き換えます。 キー コンテナー URI にhttps://
は含めないでください。
- グローバル Azure を使用している場合は、
SECRET
引数の最初の部分を、「手順 1: Microsoft Entra サービス プリンシパルを設定する」の Microsoft Entra クライアント ID に置き換えます。 この例のクライアント ID はd956f6b9xxxxxxx
です。重要
アプリ (クライアント) ID のハイフンは必ず削除してください。
SECRET
引数の 2 番目の部分を、「手順 1: Microsoft Entra サービス プリンシパルを設定する」のクライアント シークレットに置き換えます。 この例のクライアント シークレットはyrA8X~PldtMCvUZPxxxxxxxx
です。SECRET
引数の最後の文字列は、ハイフンのない長い文字と数字のシーケンスになります (クライアント シークレットにハイフンが含まれている場合の [クライアント シークレット] セクション以外)。USE master; CREATE CREDENTIAL sysadmin_ekm_cred WITH IDENTITY = 'DocsSampleEKMKeyVault', -- for public Azure -- WITH IDENTITY = 'DocsSampleEKMKeyVault.vault.usgovcloudapi.net', -- for Azure Government -- WITH IDENTITY = 'DocsSampleEKMKeyVault.vault.azure.cn', -- for Microsoft Azure operated by 21Vianet -- WITH IDENTITY = 'DocsSampleEKMKeyVault.vault.microsoftazure.de', -- for Azure Germany -- WITH IDENTITY = '<name of Managed HSM>.managedhsm.azure.net', -- for Managed HSM (HSM URI in the Azure portal resource) --<----Application (Client) ID ---><--Microsoft Entra app (Client) ID secret--> SECRET = 'd956f6b9xxxxxxxyrA8X~PldtMCvUZPxxxxxxxx' FOR CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM; -- Add the credential to the SQL Server administrator's domain login ALTER LOGIN [<domain>\<login>] ADD CREDENTIAL sysadmin_ekm_cred;
CREATE CREDENTIAL
引数に変数を使用し、プログラムでクライアント ID からハイフンを削除する方法の例については、「CREATE CREDENTIAL」をご覧ください。SQL Server インスタンスで Azure Key Vault キーを開きます。
新しいキーを作成したか、「手順 2: キー コンテナーを作成する」の説明に従って非対称キーをインポートしたかにかかわらず、キーを開く必要があります。 次の Transact-SQL スクリプトに実際のキー名を指定して、キーを開きます。
重要
この手順では、最初にレジストリの前提条件を完了してください。
EKMSampleASYKey
を SQL Server でキーに割り当てる名前に置き換えます。ContosoRSAKey0
の部分は、Azure Key Vault またはマネージド HSM 内のお使いのキー名に置き換えます。 バージョンレス キーの例を以下に示します。
CREATE ASYMMETRIC KEY EKMSampleASYKey FROM PROVIDER [AzureKeyVault_EKM] WITH PROVIDER_KEY_NAME = 'ContosoRSAKey0', CREATION_DISPOSITION = OPEN_EXISTING;
更新済みのバージョン 1.0.5.0 の SQL Server コネクタ以降、Azure Key Vault 内の特定のキー バージョンを参照できます:
CREATE ASYMMETRIC KEY EKMSampleASYKey FROM PROVIDER [AzureKeyVault_EKM] WITH PROVIDER_KEY_NAME = 'ContosoRSAKey0/1a4d3b9b393c4678831ccc60def75379', CREATION_DISPOSITION = OPEN_EXISTING;
前述のスクリプト例では、
1a4d3b9b393c4678831ccc60def75379
は使用されるキーの特定のバージョンを表しています。 このスクリプトを使用する場合、キーを新しいバージョンで更新しても問題ありません。 キーのバージョン (たとえば)1a4d3b9b393c4678831ccc60def75379
は、データベースの操作に常に使用されます。前の手順で作成した SQL Server の非対称キーを使用して、新しいログインを作成します。
--Create a Login that will associate the asymmetric key to this login CREATE LOGIN TDE_Login FROM ASYMMETRIC KEY EKMSampleASYKey;
SQL Server の非対称キーから新しいログインを作成します。 「手順 5: SQL Server を構成する」で設定した資格情報のマッピングを削除して、資格情報を新しいログインにマッピングできるようにします。
--Now drop the credential mapping from the original association ALTER LOGIN [<domain>\<login>] DROP CREDENTIAL sysadmin_ekm_cred;
新しいログインを変更して、EKM 資格情報を新しいログインにマップします。
--Now add the credential mapping to the new Login ALTER LOGIN TDE_Login ADD CREDENTIAL sysadmin_ekm_cred;
暗号化するユーザー データベースを構成する
Azure Key Vault キーを使用して暗号化されるテスト データベースを作成します。
--Create a test database that will be encrypted with the Azure Key Vault key CREATE DATABASE TestTDE;
ASYMMETRIC KEY
を使用してデータベース暗号化キーを作成します(EKMSampleASYKey
)。USE <DB Name>; --Create an ENCRYPTION KEY using the ASYMMETRIC KEY (EKMSampleASYKey) CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256 ENCRYPTION BY SERVER ASYMMETRIC KEY EKMSampleASYKey;
テスト データベースを暗号化します。
ENCRYPTION ON
を設定して TDE を有効にします。--Enable TDE by setting ENCRYPTION ON ALTER DATABASE TestTDE SET ENCRYPTION ON;
レジストリ詳細
master
データベースで次の Transact-SQL クエリを実行して、使用される非対称キーを表示します。SELECT name, algorithm_desc, thumbprint FROM sys.asymmetric_keys;
このステートメントからは次の情報が返されます。
name algorithm_desc thumbprint EKMSampleASYKey RSA_2048 <key thumbprint>
ユーザー データベース (
TestTDE
) で、次の Transact-SQL クエリを実行して、使用される暗号化キーを表示します。SELECT encryptor_type, encryption_state_desc, encryptor_thumbprint FROM sys.dm_database_encryption_keys WHERE database_id = DB_ID('TestTDE');
このステートメントからは次の情報が返されます。
encryptor_type encryption_state_desc encryptor_thumbprint ASYMMETRIC KEY ENCRYPTED <key thumbprint>
クリーンアップ
テスト オブジェクトをクリーンアップします。 このテスト スクリプトで作成されたすべてのオブジェクトを削除します。
-- CLEAN UP USE master; GO ALTER DATABASE [TestTDE] SET SINGLE_USER WITH ROLLBACK IMMEDIATE; DROP DATABASE [TestTDE]; GO ALTER LOGIN [TDE_Login] DROP CREDENTIAL [sysadmin_ekm_cred]; DROP LOGIN [TDE_Login]; GO DROP CREDENTIAL [sysadmin_ekm_cred]; GO USE master; GO DROP ASYMMETRIC KEY [EKMSampleASYKey]; DROP CRYPTOGRAPHIC PROVIDER [AzureKeyVault_EKM]; GO
サンプル スクリプトについては、「SQL Server Transparent Data Encryption and Extensible Key Management with Azure Key Vault (Azure Key Vault を使用した SQL Server Transparent Data Encryption と拡張キー管理)」のブログをご覧ください。
キーまたはすべての EKM キーが削除された後、
SQL Server Cryptographic Provider
レジストリ キーは自動的にクリーンアップされません。 手動でクリーンアップする必要があります。 レジストリキーのクリーニングは、レジストリを途中でクリーニングすると EKM 機能が壊れる可能性があるため、細心の注意を払って行う必要があります。 レジストリ キーをクリーンアップするには、SQL Server Cryptographic Provider
でHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
レジストリ キーを削除します。
トラブルシューティング
レジストリ キー HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider
が作成されていない場合、または必要なアクセス許可が付与されていない場合、次の DDL ステートメントは失敗します。
CREATE ASYMMETRIC KEY EKMSampleASYKey
FROM PROVIDER [AzureKeyVault_EKM]
WITH PROVIDER_KEY_NAME = 'ContosoRSAKey0',
CREATION_DISPOSITION = OPEN_EXISTING;
Msg 33049, Level 16, State 2, Line 65
Key with name 'ContosoRSAKey0' does not exist in the provider or access is denied. Provider error code: 2058. (Provider Error - No explanation is available, consult EKM Provider for details)
有効期限が切れようとしているクライアント シークレット
資格情報に有効期限が迫っているクライアント シークレットがある場合は、その資格情報に新しいシークレットを割り当てることができます。
「手順 1: Microsoft Entra サービス プリンシパルを設定する」で最初に作成したシークレットを更新します。
次のコードを使用し、同じ ID と新しいシークレットを使用して資格情報を変更します。
<New Secret>
を新しいシークレットに置き換えます。ALTER CREDENTIAL sysadmin_ekm_cred WITH IDENTITY = 'DocsSampleEKMKeyVault', SECRET = '<New Secret>';
SQL Server サービスを再起動します。
Note
可用性グループ (AG) で EKM を使用している場合は、資格情報を変更し、AG のすべてのノードで SQL Server サービスを再起動する必要があります。
新しい AKV キーまたは新しい AKV キー バージョンで非対称キーをローテーションする
Note
- AKV キーを手動でローテーションする場合、SQL Server では AKV バージョンレス キーやバージョン管理キーの両方がサポートされ、別の AKV キーを使用する必要はありません。
- 元の AKV キーをローテーションして、SQL Server で作成された以前のキーを置き換えることができる新しいバージョンを作成できます。
- 手動でキーをローテーションするには、AKV でローテーションされたバージョンレスのキーまたはバージョン管理キーを参照して、新しい SQL Server 非対称キーを作成する必要があります。 新しい SQL Server 非対称キーに関しては、バージョンレスの AKV キーは、AKV の最上位のキー バージョンを使用して自動的に選択されます。 バージョン管理されたキーの場合は、構文
WITH PROVIDER_KEY_NAME = <key_name>/<version>
を使用して AKV の最上位バージョンを指定する必要があります。 データベース暗号化キーを変更して、新しい非対称キーを用いて再暗号化できます。 AKV ローテーション ポリシーでは、同じキー名 (バージョン管理またはバージョンレス) を使用できます。 バージョン管理されたキーの場合は、現在のバージョンを追加する必要があります。 バージョンレス キーの場合は、同じキー名を使用します。
SQL Server には、TDE に使用される非対称キーを自動的にローテーションするメカニズムはありません。 非対称キーを手動でローテーションする手順は次のとおりです。
初期セットアップ (
sysadmin_ekm_cred
) で使用される認証情報は、キーのローテーションにも再利用できます。 必要に応じて、新しい非対称キーの新しい認証情報を作成します。CREATE CREDENTIAL <new_credential_name> WITH IDENTITY = <key vault>, SECRET = 'existing/new secret' FOR CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM;
プリンシパルに認証情報を追加します:
ALTER LOGIN [domain\userName]; ADD CREDENTIAL <new_credential_name>;
新しいキーに基づいて新しい非対称キーを作成します (キーをローテーションした後)。 新しいキーは、バージョンレス キー (この例では
ContosoRSAKey0
) またはバージョン管理されたキー (1a4d3b9b393c4678831ccc60def75379
が AKV の更新されたキーのバージョンである場合はContosoRSAKey0/1a4d3b9b393c4678831ccc60def75379
) である可能性があります:CREATE ASYMMETRIC KEY <new_ekm_key_name> FROM PROVIDER [AzureKeyVault_EKM] WITH PROVIDER_KEY_NAME = <new_key_from_key_vault>, CREATION_DISPOSITION = OPEN_EXISTING;
新しい非対称キーから新しいログインを作成します。
CREATE LOGIN <new_login_name> FROM ASYMMETRIC KEY <new_ekm_key_name>;
プリンシパルから認証情報を削除します:
ALTER LOGIN [domain\username] DROP CREDENTIAL <new_credential_name>;
AKV 資格情報を新しいログインにマッピングします。
ALTER LOGIN <new_login_name>; ADD CREDENTIAL <new_credential_name>;
データベース暗号化キー (DEK) を変更して、新しい非対称キーで再暗号化します。
USE [databaseName]; GO ALTER DATABASE ENCRYPTION KEY ENCRYPTION BY SERVER ASYMMETRIC KEY <new_ekm_key_name>;
データベースで使用される新しい非対称キーと暗号化キーを確認できます:
SELECT encryptor_type, encryption_state_desc, encryptor_thumbprint FROM sys.dm_database_encryption_keys WHERE database_id = DB_ID('databaseName');
このサムプリントは、パス
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider\Azure Key Vault\<key_vault_url>\<thumbprint>
の下のレジストリ キーと一致し、ローテーションされたキーをKeyUri
に指定する必要があります。
重要
サーバーの論理的な TDE 保護機能のローテーションは、サーバー上のデータベース暗号化キー (DEK) を保護する新しい非対称キーまたは認定資格証に切り替えることを意味します。 キー ローテーションはオンラインで行われ、データベース全体ではなく DEK を復号化して再暗号化するのみであるため、完了までに数秒しかかかりません。
ローテーション後に以前のバージョンのキーは削除しないでください。 キーがローテーションされると、古いデータベース バックアップ、バックアップされたログファイル、仮想ログ ファイル (VLF)、トランザクション ログ ファイルなど、一部のデータは引き続き以前のキーで暗号化されます。 以前のキーは、データベースの回収やデータベースの復元にも必要な場合があります。