カスタマー マネージド キーを使用した Azure SQL Transparent Data Encryption

適用対象: Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics (専用の SQL プールのみ)

カスタマー マネージド キー (CMK) を使用した Azure SQL の Transparent Data Encryption (TDE) を使用すると、保存データの保護に Bring Your Own Key (BYOK) シナリオが可能になり、組織がキーとデータの管理における職務の分離を実施できるようになります。 カスタマー マネージド TDE では、キー ライフサイクル管理 (キーの作成、アップロード、交換、削除)、キーの使用権限、およびキーに対する操作の監査は、お客様の責任であり、お客様がこれらを完全に制御できます。

このシナリオでは、TDE 保護機能と呼ばれるデータベース暗号化キー (DEK) の暗号化に使用されるキーは、顧客が所有し、顧客が管理する Azure Key Vault (AKV) (クラウドベースの外部キー管理システム) に格納されている、カスタマー マネージド非対称キーです。 Key Vault は、FIPS 140-2 Level 2 認定のハードウェア セキュリティ モジュール (HSM) をオプションで使用できる、RSA 暗号化キー向けの、可用性が高くスケーラブルでセキュリティで保護されたストレージです。 格納されているキーに直接アクセスすることはできませんが、キーを使用して暗号化/復号化のサービスを認証されたエンティティに提供します。 キーは、Key Vault で生成するか、インポートするか、オンプレミスの HSM デバイスから Key Vault に転送することができます。

Azure SQL Database と Azure Synapse Analytics の場合、TDE 保護機能はサーバー レベルで設定され、そのサーバーに関連付けられているすべての暗号化されたデータベースによって継承されます。 Azure SQL Managed Instance の場合、TDE 保護機能はインスタンス レベルで設定され、そのインスタンス上のすべての暗号化されたデータベースによって継承されます。 "サーバー" という用語は、別途明記されていない限り、このドキュメントでは、SQL Database や Azure Synapse のサーバーと、SQL Managed Instance のマネージド インスタンスの両方を指します。

Azure SQL Database でデータベース レベルで TDE 保護機能を管理できます。 詳細については、「カスタマー マネージド キーを使用したデータベース レベルでの Transparent Data Encryption (TDE)」をご覧ください。

カスタマー マネージド TDE の利点

カスタマー マネージド TDE は、顧客に次の利点をもたらします。

• TDE 保護機能の使用と管理の完全かつ詳細な制御

• TDE 保護機能の使用の透過性

• 組織内でキーとデータの管理における職務の分離を実施することができる

• Key Vault 管理者は、暗号化されたデータベースにアクセスできないようにキーのアクセス許可を取り消すことができる

• AKV でのキーの一元管理

• AKV は Microsoft が暗号化キーを表示したり抽出したりできないように設計されているため、エンド カスタマーからの信頼が高まる

カスタマー マネージド TDE のしくみ

Azure の論理サーバーが DEK の暗号化に AKV に格納されている TDE 保護機能を使用できるようにするには、キー コンテナー管理者が一意の Microsoft Entra ID を使用して、サーバーにアクセス権を付与する必要があります。 サーバーにキー コンテナーへのアクセスを許可するには、次の 2 つのアクセス モデルがあります。

• Azure ロールベースのアクセス制御 (RBAC) - Azure RBAC を使用して、ユーザー、グループ、またはアプリケーションにキー コンテナーへのアクセス権を付与します。 柔軟性と細分性のためには、この方法が推奨されます。 Key Vault Crypto Service Encryption User ロールは、暗号化と暗号化解除の操作にキーを使用できるようにするために、サーバー ID によって必要とされます。

• コンテナー アクセス ポリシー - キー コンテナー アクセス ポリシーを使用して、サーバーにキー コンテナーへのアクセス権を付与します。 この方法は、よりシンプルで簡単ですが、柔軟性は低くなります。 サーバー ID には、キー コンテナーに対する次のアクセス許可が必要です。

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

[アクセス構成] の[キー コンテナーの Azure portal メニュー] には、[Azure ロールベースのアクセス制御] または [Vault アクセス ポリシー] を選択するオプションがあります。 TDE の Azure Key Vault アクセス構成を設定する手順については、「Azure Key Vault を使用した SQL Server TDE 拡張キー管理の設定」を参照してください。 アクセス モデルに関する詳細については、「Azure Key Vault セキュリティ」を参照してください。

キー コンテナー管理者は、後で監査できるように、キー コンテナーの監査イベントのログ記録を有効にすることもできます。

AKV の TDE 保護機能を使用するようにサーバーを構成すると、そのサーバーから各 TDE 対応データベースの DEK が暗号化のためキー コンテナーに送信されます。 キー コンテナーから、暗号化された DEK が返され、その後、ユーザー データベースに格納されます。

必要に応じて、保護された DEK が復号化のためにサーバーからキー コンテナーに送信されます。

ログ記録が有効になっている場合、監査者は Azure Monitor を使用してキー コンテナーの AuditEvent ログを確認できます。

カスタマー マネージド TDE を構成するための要件

AKV を構成するための要件

• キー (またはキー コンテナー) の誤削除によってデータが失われないよう保護するために、キー コンテナーで論理的な削除機能と消去保護機能を有効にする必要があります。

• Microsoft Entra ID を使用して、サーバーまたはマネージド インスタンスにキー コンテナーへのアクセス権 (get、wrapKey、unwrapKey) を付与します。 サーバー ID には、システム割り当てマネージド ID またはサーバーに割り当てられたユーザー割り当てマネージド ID を指定できます。 Azure portal を使用する場合、サーバーの作成時に Microsoft Entra ID が自動的に作成されます。 PowerShell または Azure CLI を使用する場合は、Microsoft Entra ID を明示的に作成し、検証する必要があります。 PowerShell を使用するときの詳細な手順については、BYOK 対応 TDE の構成および SQL Managed Instance 用 BYOK 対応 TDE の構成に関する記事を参照してください。

  • Key vault のアクセス許可モデル (アクセスポリシーまたは Azure RBAC) に応じて、key vault にアクセスポリシーを作成するか、ロール {1}Key Vault Crypto Service 暗号化ユーザー{2}を使用して新しい Azure RBAC ロールの割り当てを作成することによって、key vault のアクセス権を付与できます。

• AKV でファイアウォールを使用する場合は、AKV にプライベート エンドポイントを使用していない限り、[信頼されたMicrosoft サービスがファイアウォールをバイパスすることを許可する] オプションを有効にする必要があります。 詳細については、「Azure Key Vault のファイアウォールと仮想ネットワークを構成する」を参照してください。

AKV の論理的な削除と消去保護を有効にする

論理的な削除と消去保護は、削除されたコンテナーと削除されたキー コンテナー オブジェクトの回復を可能にする Azure Key Vault の重要な機能であり、ユーザーがキーまたはキー コンテナーを誤ってまたは悪意を持って削除するリスクを軽減します。

• お客様が復旧または消去しない限り、ソフト削除されたリソースは 90 日間保持されます。 復旧と消去アクションには、キー コンテナーのアクセス ポリシーに関連付けられた独自のアクセス許可があります。 論理的な削除機能は、新しいキー コンテナーに対し既定でオンにされ、Azure portal、PowerShell、または Azure CLI を使用して有効にすることもできます。

• 消去保護は、 またはPowerShellを使用Azure CLI有効にできます。 消去保護を有効にすると、保持期間が経過するまで、削除された状態のコンテナーまたはオブジェクトを消去できません。 既定の保有期間は 90 日ですが、7 日から 90 日の間に構成Azure portal。

• Azure SQL では、サーバーまたはマネージド インスタンスの TDE 保護機能として使用される暗号化キーを格納するキー コンテナーで、論理的な削除と消去保護を有効にすることを必要とします。 これにより、データベースがアクセスできない状態になる可能性がある、誤ったまたは悪意によるキー コンテナーまたはキーの削除のシナリオを防ぐために役立 ちます。

• 既存のサーバーまたはサーバーの作成時に TDE 保護機能を構成すると、Azure SQL によって、使用されているキー コンテナーで論理的な削除と消去保護が有効にされていることが検証されます。 キー コンテナーで論理的な削除と消去保護が有効にされていない場合、TDE 保護機能のセットアップがエラーで失敗します。 この場合、最初にキー コンテナーで論理的な削除と消去保護を有効にしてから、TDE 保護機能のセットアップを実行する必要があります。

TDE 保護機能を構成するための要件

• TDE 保護機能には、非対称、RSA、または RSA HSM の各キーのみを指定できます。 サポートされているキーの長さは、2048 ビットおよび 3072 ビットです。

• キーがアクティブ化された日時 (設定する場合) は、過去の日付と時刻にする必要があります。 有効期限の日時 (設定する場合) は、将来の日付と時刻にする必要があります。

• キーは、"有効" 状態になっている必要があります。

• キー コンテナーに既存のキーをインポートする場合は、サポートされているファイル形式 (.pfx、.byok、.backup) で提供するようにしてください。

カスタマー マネージド TDE を構成する際の推奨事項

AKV を構成する際の推奨事項

• サーバーがキー コンテナー内の TDE 保護機能にアクセスする際の高可用性を確保するために、1 つのサブスクリプションで 1 つのキー コンテナーに最大 500 の General Purpose データベースまたは 200 の Business Critical データベースを関連付けます。 これらの数字は経験に基づいており、キー コンテナー サービスの制限に記載されています。 目的は、サーバーのフェールオーバー後の問題を回避することです。これは、フェールオーバーによってそのサーバー内のデータベースと同じ数のキー操作がコンテナーに対してトリガーされるためです。

• キー コンテナーにリソース ロックを設定して、この重要なリソースを削除できるユーザーを制御し、誤削除や許可されていない削除を防ぎます。 リソース ロックの詳細については、こちらをご覧ください。

• すべての暗号化キーの監査およびレポートを有効にします。キー コンテナーで提供されるログは、他のセキュリティ情報およびイベント管理ツールに簡単に挿入できます。 Operations Management Suite Log Analytics は、既に統合されているサービスの一例です。

• 暗号化されたデータベースの高可用性を確保するため、各サーバーを異なるリージョンに存在する 2 つのキー コンテナーとリンクします。 キー コンテナーの 1 つからキーを TDE 保護機能としてマークします。 1 つ目のリージョン内のキー コンテナーに影響する障害が発生した場合、システムは同じキー マテリアルを含む 2 つ目のリージョン内のキー コンテナーに自動的に切り替わります。

TDE 保護機能を構成する際の推奨事項

• TDE 保護機能のコピーを安全な場所に保管するか、エスクロー サービスにエスクローします。

• キーがキー コンテナー内に生成される場合は、初めて AKV でキーを使用する前に、キーのバックアップを作成します。 バックアップは Azure Key Vault にのみ復元できます。 Backup-AzKeyVaultKey コマンドの詳細については、こちらをご覧ください。

• キー (キー属性、タグ、ACL など) に変更を加えるたびに新しいバックアップを作成します。

• データベースの古いバックアップを復元できるように、キーを交換するときは、キー コンテナーにキーの以前のバージョンを保持します。 データベースの TDE 保護機能が変更されても、データベースの古いバックアップが、最新の TDE 保護機能を使用するように更新されることはありません。 復元時には、各バックアップに作成時に暗号化された TDE 保護機能が必要です。 キーの交換を行うには、PowerShell を使用した Transparent Data Encryption 保護機能のローテーションに関する記事の手順に従います。

• サービス マネージド キーに切り替えた後でも、以前に使用したすべてのキーを AKV で保持します。 これにより、AKV に格納された TDE 保護機能を使用してデータベースのバックアップを復元できます。 Azure Key Vault で作成された TDE 保護機能は、残りの保存されているすべてのバックアップがサービス マネージド キーを使用して作成されるまで保持される必要があります。 Backup-AzKeyVaultKey を使用して、これらのキーの回復可能なバックアップ コピーを作成します。

• セキュリティ インシデントの発生時に、データ損失のリスクを伴わずに、侵害された可能性のあるキーを削除するには、侵害された可能性のあるキーの削除の手順に従ってください。

TDE 保護機能のローテーション

サーバーの TDE 保護機能のローテーションは、サーバー上のデータベースを保護する新しい非対称キーに切り替えることを示します。 キーのローテーションはオンライン操作であり、数秒で完了します。 この操作では、データベース全体ではなく、データベース暗号化キーの暗号化の解除と再暗号化のみが行われます。

TDE 保護機能のローテーション は、手動、または、自動回転機能を使用して行うことができます。

サーバーの TDE 保護機能を構成するときに、TDE 保護機能の自動ローテーションを有効にすることができます。 既定では、自動ローテーションは無効になっています。 有効にすると、サーバーで、TDE 保護機能として使用されているキーの新しいバージョンがないか、キー コンテナーが継続的にチェックされます。 新しいバージョンのキーが検出された場合、サーバーまたはデータベース上の TDE 保護機能が24 時間以内に最新のキー バージョンに自動的にローテーションされます。

Azure Key Vault で自動キーローテーションと共に使用すると、この機能により、Azure SQL Database と Azure SQL Managed Instance の TDE 保護機能に対してエンドツーエンドのゼロタッチローテーションが可能になります。

TDE 保護機能の自動ローテーションを構成するときの geo レプリケーションに関する考慮事項

geo レプリケーションの確立中またはその実行中に問題が発生しないようにするには、プライマリまたはセカンダリ サーバーで TDE 保護機能の自動ローテーションが有効になっている場合、geo レプリケーションを構成するときに次の規則に従うことが重要です。

• プライマリ サーバーとセカンダリ サーバーの両方に、プライマリ サーバーのキー コンテナー (プライマリ サーバーの TDE 保護機能キーを保持するキー コンテナー) に対する Get、wrapKey、unwrapKey のアクセス許可が必要です。

• 自動キーローテーションが有効になっているサーバーの場合、geo レプリケーションを開始する前に、プライマリ サーバーで TDE 保護機能として使用されている暗号化キーをセカンダリ サーバーに追加します。 セカンダリ サーバーは、プライマリ サーバーで使用されているのと同じキー コンテナー内のキーにアクセスする必要があります (同じキー マテリアルを持つ別のキーにはアクセスできません)。 または、geo レプリケーションを開始する前に、セカンダリ サーバーのマネージド ID (ユーザー割り当てまたはシステム割り当て) にプライマリ サーバーのキー コンテナーに対する必要なアクセス許可があることを確認します。その後、システムによりセカンダリ サーバーへのキーの追加が試みられます。

• 既存の geo レプリケーションのセットアップでは、プライマリ サーバーで自動キーローテーションを有効にする前に、プライマリ サーバーで TDE 保護機能として使用されている暗号化キーをセカンダリ サーバーに追加します。 セカンダリ サーバーは、プライマリ サーバーで使用されているのと同じキー コンテナー内のキーにアクセスする必要があります (同じキー マテリアルを持つ別のキーにはアクセスできません)。 または、自動化キーを有効にする前に、セカンダリ サーバーのマネージド ID (ユーザー割り当てまたはシステム割り当て) にプライマリ サーバーのキー コンテナーに対する必要なアクセス許可があることを確認します。その後、システムによりセカンダリ サーバーへのキーの追加が試みられます。

• TDE にカスタマー マネージド キー (CMK) を使用する geo レプリケーション シナリオがサポートされています。 Azure portal で TDE を構成する場合は、自動キー ローテーションを使用する TDE をすべてのサーバーで構成する必要があります。 TDE を使用する geo レプリケーション構成用の自動キー ローテーションの設定について詳しくは、「geo レプリケーション構成のキーの自動ローテーション」をご覧ください。

アクセスできない TDE 保護機能

TDE がカスタマー マネージド キーを使用するように構成されている場合、データベースをオンラインのままにするには、TDE 保護機能への継続的アクセスが必要です。 サーバーが AKV 内のカスタマー マネージド TDE 保護機能にアクセスできなくなると、データベースは 10 分以内に対応するエラー メッセージですべての接続を拒否するようになり、状態が "アクセス不可" に変わります。 アクセス不可状態のデータベースで許可される唯一のアクションは、削除だけです。

キーへのアクセスが復元された後、データベースをオンラインに戻すには、追加の時間と手順が必要です。これは、キーにアクセスできなくなってからの経過時間とデータベース内のデータのサイズによって異なる場合があります。

以下は、アクセスできないデータベースをオンラインに戻すためにポータルで必要な追加手順です。

TDE 保護機能アクセスの誤失効

キー コンテナーに対する十分なアクセス権を持つユーザーが、次のことを行うことで、キーへのサーバー アクセスを誤って無効にしてしまうことがあります。

• サーバーからキー コンテナーの get、wrapKey、unwrapKey のアクセス許可を取り消す

• キーを削除する

• キー コンテナーを削除する

• キー コンテナーのファイアウォール規則を変更する

• Microsoft Entra ID 内のサーバーのマネージド ID を削除する

データベースにアクセスできなくなる一般的な原因については、こちらを参照してください。

SQL Managed Instance と Key Vault の間のブロックされている接続

SQL Managed Instance では、Azure Key Vault で TDE の保護機能にアクセスしようとしたときにネットワーク エラーが発生し、データベースの状態がアクセス不可に変更されない可能性がありますが、その後、インスタンスは使用できなくなります。 これは主に、キー コンテナー リソースが存在するが、マネージド インスタンスからそのエンドポイントに到達できない場合に発生します。 キー コンテナー エンドポイントに到達できるが、接続が拒否されたり、アクセス許可がないなどのシナリオではすべて、データベースの状態が "アクセス不可" に変更されます。

Key Vault へのネットワーク接続がない最も一般的な原因は次のとおりです。

• Key Vault はプライベート エンドポイントを介して公開され、AKV サービスのプライベート IP アドレスは、マネージド インスタンス サブネットに関連付けられているネットワーク セキュリティ グループ (NSG) のアウトバウンド規則では許可されません。
• キー コンテナーの FQDN が解決されない場合や無効な IP アドレスに解決された場合など、DNS 解決が正しくありません。

SQL Managed Instance から TDE 保護機能をホストしている Key Vault への接続をテストします。

• エンドポイントは、<vault_name>.vault.azure.net (https:// なし) など、コンテナーの FQDN です。
• テストするポートは 443 です。
• RemoteAddress の結果は、正しい IP アドレスとして存在する必要があります
• TCP テストの結果は TcpTestSucceeded: True である必要があります。

テストで TcpTestSucceeded: False が返される場合は、次のネットワーク構成を確認してください。

• 解決された IP アドレスを調べて、それが有効であることを確認します。 値がない場合は、DNS 解決に問題があることを意味します。
  • 特に、解決されたアドレスがキー コンテナーのプライベート エンドポイントに属している場合、マネージド インスタンスのネットワーク セキュリティ グループに、ポート 443 で解決された IP アドレスを含むアウトバウンド規則があることを確認します。
  • ルート テーブル、仮想アプライアンスの存在、その構成などの他のネットワーク構成を確認します。

カスタマー マネージド TDE の監視

データベースの状態を監視したり、TDE 保護機能にアクセスできなくなった場合のアラートを有効にしたりするには、Azure の次の機能を構成します。

• Azure Resource Health。 TDE 保護機能へのアクセスが失われたアクセス不可能なデータベースには、データベースへの最初の接続が拒否された後、"使用できません" と表示されます。
• アクティビティ ログ。ユーザーが管理するキー コンテナーの TDE 保護機能へのアクセスに失敗すると、アクティビティ ログにエントリが追加されます。 これらのイベントに対してアラートを作成すると、できるだけ早くアクセスを再開できるようになります。
• アクション グループを定義して、設定 (たとえば、メール、SMS、プッシュ、音声、ロジック アプリ、Webhook、ITSM、Automation Runbook) に基づいて通知やアラートを送信できます。

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

Key Vault のキーを使用して TDE でデータベースを暗号化すると、新しく生成されるバックアップも同じ TDE 保護機能で暗号化されます。 TDE 保護機能が変更されても、データベースの古いバックアップが、最新の TDE 保護機能を使用するように更新されることはありません。

Key Vault の TDE 保護機能で暗号化されたバックアップを復元するには、キー マテリアルがターゲット サーバーで使用できることを確認します。 そのため、データベースのバックアップを復元できるように、TDE 保護機能の古いバージョンをすべてキー コンテナーに保持しておくことをお勧めします。

ターゲット サーバーでバックアップの復元に必要なキーが使用できなくなった場合は、復元の試行時に次のエラー メッセージが返されます。"ターゲット サーバー <Servername> は、<Timestamp #1> から <Timestamp #2> の間に作成されたいずれの AKV URI にもアクセスできません。 すべての AKV URI を復元してから操作をやり直してください\)

これを軽減するには、ターゲット サーバーに対して Get-AzSqlServerKeyVaultKey コマンドレットを実行するか、ターゲット マネージド インスタンスに対して Get-AzSqlInstanceKeyVaultKey を実行して、使用可能なキーの一覧を返し、不足しているキーを識別します。 すべてのバックアップを復元できるようにするには、復元のターゲット サーバーが必要なすべてのキーにアクセスできることを確認します。 これらのキーを TDE 保護機能としてマークする必要はありません。

SQL Database のバックアップ回復の詳細については、SQL Database のデータベース回復に関する記事を参照してください。 Azure Synapse Analytics の専用 SQL プールのバックアップ復旧の詳細については、専用 SQL プールの復旧に関するページを参照してください。 SQL Managed Instance を使用した SQL Server のネイティブ バックアップと復元については、SQL Managed Instance にデータベースを復元する方法についてのクイックスタートに関するページを参照してください。

ログ ファイルに関するその他の考慮事項: 交換され、データベースが新しい TDE の保護機能を使用している場合でも、バックアップ ログ ファイルは元の TDE の保護機能で暗号化されたままになっています。 復元時に、データベースを復元するには両方のキーが必要です。 その間にサービス マネージド TDE を使用するようにデータベースが変更された場合でも、Azure Key Vault に格納されている TDE 保護機能がログ ファイルで使用されている場合は、復元時にこのキーが必要になります。

カスタマー マネージド TDE による高可用性

AKV で複数の層の冗長性を提供することで、カスタマー マネージド キーを使用する TDE は AKV の可用性と回復性を活用し、AKV 冗長性ソリューションに完全に依存できます。

AKV の複数の冗長性レイヤーにより、個々のサービス コンポーネントが失敗した場合や、Azure リージョンまたは可用性ゾーンがダウンしている場合でも、キー アクセスが保証されます。 詳細については、「Azure Key Vault の可用性と冗長性」を参照してください。

AKV には、ユーザーの介入なしに自動的に提供される可用性と回復性の次のコンポーネントが用意されています。

• データのレプリケーション
• リージョン内のフェールオーバー
• リージョン間のフェールオーバー

Geo-DR とカスタマー マネージド TDE

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

不完全なキー マテリアルが原因で geo レプリケーションの確立中または実行中に問題が発生するのを回避するには、カスタマー マネージド TDE を構成するときに、次の規則に従うことが重要です (プライマリ サーバーとセカンダリ サーバーに個別のキー コンテナーが使用されている場合)。

• 関連するすべてのキー コンテナーに、同じプロパティと、それぞれのサーバーに対する同じアクセス権がある必要があります。

• 関連するすべてのキー コンテナーに、同じキー マテリアルが含まれている必要があります。 これは現在の TDE 保護機能だけでなく、バックアップ ファイルで使用されている可能性がある以前のすべての TDE 保護機能にも適用されます。

• TDE 保護機能の初期セットアップとローテーションは、どちらも最初にセカンダリで実行してから、プライマリで実行する必要があります。

フェールオーバーをテストするには、アクティブ geo レプリケーションの概要の手順に従います。 フェールオーバーのテストを定期的に行い、SQL Database で両方のキー コンテナーへのアクセス許可が保持されていることを検証する必要があります。

あるリージョンの Azure SQL Database サーバーと SQL Managed Instance を、他のリージョンのキー コンテナーにリンクできるようになりました。 サーバーとキー コンテナーが同じリージョンに併置されている必要はありません。 これにより、わかりやすくするために、プライマリサーバーとセカンダリサーバーを同じ key vault (任意のリージョン) に接続できます。 これにより、両方のサーバーで別個のキー コンテナーが使用されている場合にキー マテリアルが非同期になるというシナリオを回避できます。 Azure Key Vault には、サービスまたはリージョンで障害が発生した場合でもキーとキーコンテナーを確実に使用できるようにするために、複数の層の冗長性があります。 Azure Key Vault の可用性と冗長性

カスタマー マネージド TDE の Azure Policy

Azure SQL Database サーバーや Azure SQL Managed Instance の作成または更新中、Azure Policy を使用して、カスタマー マネージド TDE を適用することができます。 このポリシーが適用されていると、Azure 内で論理サーバーを、またはマネージド インスタンスを作成または更新しようとしても、カスタマー マネージド キーを使用して構成されていない場合は失敗します。 Azure Policy は、Azure サブスクリプション全体に適用することも、リソース グループ内だけに適用することも可能です。

Azure Policy の詳細については、「Azure Policy とは」および「Azure Policy の定義の構造」を参照してください。

Azure Policy では、カスタマー マネージド TDE に対して、次の 2 つの組み込みポリシーがサポートされています。

• SQL サーバーでは保存データを暗号化するためにカスタマー マネージド キーを使用する必要がある
• マネージド インスタンスでは保存データを暗号化するためにカスタマー マネージド キーを使用する必要がある

カスタマー マネージド TDE を管理するには、Azure portal にアクセスし、Policy サービスを検索します。 [定義] で、カスタマー マネージド キーを検索します。

これらのポリシーには、次の 3 つの効果があります。

• 監査 - 既定の設定。Azure Policy アクティビティ ログ内で監査レポートをキャプチャするだけです
• 拒否 - カスタマー マネージド キーを構成せず、論理サーバーまたはマネージド インスタンスが作成/更新されないようにします
• 無効 - ポリシーを無効にします。カスタマー マネージド TDE を有効にせず、ユーザーによる論理サーバーまたはマネージド インスタンスの作成/更新は制限されません

カスタマー マネージド TDE の Azure Policy が [拒否] に設定されている場合、Azure SQL 論理サーバーまたはマネージド インスタンスの作成は失敗します。 このエラーの詳細は、リソース グループのアクティビティ ログに記録されます。

関連するコンテンツ

• SQL Database の Transparent Data Encryption 保護機能をローテーションする
• SQL Database の Transparent Data Encryption (TDE) 保護機能を削除する
• PowerShell を使用して、SQL Managed Instance で独自のキーを使用して Transparent Data Encryption を管理する
• Microsoft Defender for SQL