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

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

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

この場合、Transparent Data Encryption(TDE)プロテクターは顧客管理の鍵であり、データベース暗号化鍵(DEK)を保護します。 TDEプロテクターは、Azure Key VaultまたはAzure Key Vault Managed HSMのいずれかに保存します。これらは高可用性とスケーラビリティを重視した安全なクラウドベースの鍵管理サービスです。 両サービスともFIPS 140-2認証済みハードウェアで保護された暗号鍵をサポートしています。Azure Key VaultはFIPS 140-2レベル2をサポートし、Azure Key Vault Managed HSMはFIPS 140-2レベル3をサポートしています。 両サービスとも非対称キータイプおよび対称キータイプをサポートしており、サポートされるアルゴリズムや使用方法はTDEの展開モデルによって異なります。 サービス内で鍵を生成したり、インポートしたり、オン プレミスのHSMから安全に転送したりできます。 鍵への直接アクセスは制限されているため、認可されたサービスは鍵の資料を公開することなく暗号操作を行います。

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)」をご覧ください。

注

この記事は、Azure SQL Database、Azure SQL Managed Instance、Azure Synapse Analytics (専用 SQL プール (以前の SQL DW)) に適用されます。 Synapse ワークスペース内の専用 SQL プールの透過的なデータ暗号化の詳細については、 Azure Synapse Analytics の暗号化に関するページを参照してください。

注

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

カスタマー マネージド キー (CMK) と Bring Your Own Key (BYOK)

この記事では、カスタマー マネージド キー (CMK) と Bring Your Own Key (BYOK) という用語を同じように使用しますが、いくつかの違いを表しています。

  • カスタマー マネージド キー (CMK) - キーの作成、ローテーション、削除など、キーのライフサイクルが顧客によって管理されます。 キーは Azure Key Vault または Azure Managed HSM に格納され、Azure SQL、Azure VM 上の SQL Server、オンプレミスの SQL Server のデータベース暗号化キー (DEK) の暗号化に使用されます。

  • Bring Your Own Key (BYOK) - お客様は、オンプレミスのハードウェア セキュリティ モジュール (HSM) から Azure Key Vault または Azure Managed HSM に独自のキーを安全に取り込んだり、インポートしたりします。 このようなインポートされたキーは、DEK の暗号化用のカスタマー マネージド キーなど、Azure Key Vault 内の他のキーとして使用できます。 詳細については、「HSM で保護されたキーを Managed HSM (BYOK)にインポートする」を参照してください。

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

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

  • TDE 保護機能の使用状況と管理を完全かつきめ細かく制御します。

  • TDE 保護機能の使用の透明性。

  • 組織内のキーとデータの管理に職務の分離を実装する機能。

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

  • Azure Key Vault でのキーの一元管理。

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

重要

カスタマー マネージド TDE の使用を開始したいサービス管理 TDE を使用する場合、切り替えプロセス中もデータは暗号化されたままであり、データベース ファイルのダウンタイムや再暗号化はありません。 サービス マネージド キーからカスタマー マネージド キーへの切り替えに必要なのは、高速のオンライン操作である DEK の再暗号化だけです。

カスタマー マネージド TDE を構成するためのアクセス許可

カスタマー マネージド TDE のセットアップと機能を示す図。

使用する Azure Key Vault の種類を選択します。

Azureの論理サーバーがAzure Key Vaultに保存されたTDEプロテクターを使ってDEKの暗号化を行うには、Key Vault管理者がサーバー固有のMicrosoft Entraアイデンティティを使ってアクセス権を付与する必要があります。 サーバー ID には、システム割り当てマネージド ID またはサーバーに割り当てられたユーザー割り当てマネージド ID を指定できます。 サーバーにキー コンテナーへのアクセスを許可するには、次の 2 つのアクセス モデルがあります。

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

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

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

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

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

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

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

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

注

キー ボールトに対してアクセス許可の変更が有効になるまで、約10分かかる場合があります。 これには、AKV の TDE プロテクターへのアクセス許可の取り消しが含まれます。この概算時間内のユーザーには、まだアクセス許可がある可能性があります。

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

  • Azure Key Vault で論理的な削除と消去の保護機能を有効にする必要があります。 これにより、データベースが "アクセスできない" 状態になる可能性がある、誤ったまたは悪意によるキー コンテナーまたはキーの削除のシナリオを防ぐために役立ちます。 既存のサーバーまたはサーバーの作成時に TDE 保護機能を構成すると、Azure SQL によって、使用されているキー コンテナーで論理的な削除と消去保護が有効にされていることが検証されます。 キー コンテナーで論理的な削除と消去保護が有効にされていない場合、TDE 保護機能のセットアップがエラーで失敗します。 この場合、最初にキー ボールトでソフト削除と消去保護を有効にし、その後で TDE プロテクターのセットアップを実行する必要があります。

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

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

顧客管理鍵を用いたTransparent Data Encryptionは、TDEプロテクターと呼ばれる外部鍵を使用し、Azure Key VaultまたはAzure Managed HSMに保存されてデータベース暗号化鍵(DEK)を保護します。

次の要件が適用されます。

サポートされているキーの種類とサイズ

Azure SQL のオファリングと TDE の構成に応じて、TDE プロテクターは、Azure Key Vault または Azure Key Vault Managed HSM に格納された非対称キーまたは対称キーのいずれかによって保護されます。

  • 非対称キー (RSA または RSA HSM)

    • Azure Key Vault および Azure Key Vault Managed HSM でサポートされます
    • 対応キーサイズ:2,048ビットおよび3,072ビット
    • Azure SQL Database、Azure SQL Managed Instance、Azure Synapse Analytics でサポートされています

  • 対称キー (AES)

    • Azure Key Vault Premium (preview) and Azure Key Vault Managed HSM でサポートされています
    • 対応キーサイズ:128ビット、192ビット、256ビット
    • 現在パブリックプレビュー中のAzure SQL Databaseのみでサポートされています

注

Transparent Data Encryption with symmetric keys(AES)は現在プレビュー中です。 プレビュー機能は限られた機能でリリースされますが、Microsoftはプレビュー形式で提供しており、顧客が早期アクセスを行ってフィードバックを提供できるようにしています。 プレビュー機能は別の補足プレビュー条項の対象であり、SLA の対象ではありません。 サポートは特定の場合にベスト エフォートとして提供されます。 ただし、Microsoft サポートはプレビュー機能に関するフィードバックを受け取ることを熱望しており、場合によってはベスト エフォートサポートを提供する場合があります。 プレビュー機能には、制限された機能または制限付き機能があり、選択した地理的領域でのみ使用できる場合があります。

対称鍵(AES)鍵の鍵管理動作

Azure Key Vault Premium(プレビュー版)やAzure Key Vault Managed HSMに保存された対称(AES)鍵をTDEプロテクターとして使用できます。 オンプレミスのハードウェアセキュリティモジュール(HSM)からの鍵で始めるには、その鍵をどちらのサービスにもインポートしてください。 初期インポート後、進行中のキーライフサイクル操作はすべてAzure Key Vault Premium(プレビュー)またはAzure Key Vault Managed HSMで行われます。 ポイントインタイム復旧、地元災害復旧、鍵再認証はすべて、そこに残っている鍵に依存します。 インポートされた鍵のローカルバックアップを維持し、回復や再認証のシナリオをサポートします。 この挙動は対称(AES)鍵にのみ適用され、非対称(RSA)鍵には適用されません。

キーの状態と有効性の要件

  • キーのアクティブ化日を指定する場合は、過去の日付と時刻に設定する必要があります。
  • キーの有効期限を指定する場合は、将来の日付と時刻に設定する必要があります。
  • キーは、"有効" 状態になっている必要があります。

主なインポート要件

既存の鍵をAzure Key Vaultにインポートした場合、以下のいずれかの対応形式で鍵を提供してください:

  • .pfx
  • .byok
  • .backup

HSM で保護されたキーを Azure Managed HSM にインポートするには、「 HSM で保護されたキーを Managed HSM (BYOK) にインポートする」を参照してください。

注

v2.8.0 より前の Thales CipherTrust Manager のバージョンに関する問題により、Azure Key Vault に新しくインポートされたキーが、カスタマー マネージド TDE シナリオで Azure SQL Database または Azure SQL Managed Instance で使用されなくなります。 この問題の詳細については、 CipherTrust Cloud Key Manager のリリース ノートを参照してください。 このような場合は、Azure Key Vault にキーをインポートしてから 24 時間待って、サーバーまたはマネージド インスタンスの TDE 保護機能として使用を開始します。 この問題は Thales CipherTrust Manager v2.8.0 で解決されています。

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

  • 最適なパフォーマンスと信頼性を確保するために、Azure SQL専用のAzure Key Vaultを使用してください。 このキーボールトを他のサービスと共有しないでください。 鍵の保管庫が共有使用や過剰な鍵操作で重負荷がかかる場合、特に暗号化鍵アクセス時にデータベースのパフォーマンスに悪影響を及ぼす可能性があります。 Azure Key Vault では スロットリング制限が適用されます。 これらの制限を超えると、操作が遅れたり失敗したりする可能性があります。 このリスクはサーバーフェイルオーバー時に最も高く、サーバー上のすべてのデータベースでキー操作がトリガーされます。

    調整動作の詳細については、 Azure Key Vault の調整ガイダンスを参照してください。

    高可用性を維持し、調整の問題を回避するには、サブスクリプションごとに次のガイドラインに従います。

    • Azure SQL リソースには 専用の Azure Key Vault を使用します。

    • 1 つの Azure Key Vault に 関連付ける General Purpose データベースは 500 個以下です。

    • 1 つの Azure Key Vault に 関連付ける Business Critical データベースは 200 個以下です。

    • 1 つの Azure Key Vault に関連付けることができるハイパースケール データベースの数は、ページ サーバーの数によって決まります。 各ページ サーバーは論理データ ファイルにリンクされます。 ページ サーバーの数を検索するには、次のクエリを実行します。

      -- # of page servers (primary copies) for this database
SELECT COUNT(*) AS page_server_count
FROM sys.database_files
WHERE type_desc = 'ROWS';

      500以上のページサーバーを1つのAzure Key Vaultに関連付けないでください。 データベースが増えると、ページ サーバーの数が自動的に増えるので、データベース サイズを定期的に監視することが重要です。 ページサーバー数が500を超える場合は、各Hyperscaleデータベースごとに専用のAzure Key Vaultを使用し、そのKey Vaultを他のAzure SQLリソースと共有しないでください。

    • Azure Key Vault アラートを監視して構成します。 監視とアラートの詳細については、「 Azure Key Vault の監視」および「Azure Key Vaultアラートの構成」を参照してください。

  • 長期的な暗号学的レジリエンス計画に整合させるために、TDEプロテクタとしてAES-256対称鍵を使用することを検討してください。

    大規模な量子コンピューティングはRSAのような公開鍵暗号アルゴリズムを破ることが期待されています。 AESを含む対称暗号は、十分な大きな鍵サイズで量子耐性があると考えられています。

    Microsoftのより広範な量子安全セキュリティ戦略は、暗号通貨の機敏性を強調しています。 サポートされているより強力な対称アルゴリズムを採用し、指針や標準の進化に伴う将来の暗号学的移行を計画しましょう。

    重要

    対称キー (AES) を使用したTransparent Data Encryptionは現在、Azure SQL Databaseでのみサポートされており、パブリック プレビュー段階です。

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

  • すべての暗号化キーの監査とレポートを有効にする: Azure Key Vault には、他のセキュリティ情報とイベント管理ツールに簡単に挿入できるログが用意されています。 Operations Management Suite Log Analytics は、既に統合されているサービスの一例です。

  • 可用性を最大限に高めるために、コンテンツをペアリージョンにレプリケートできる Azure リージョンのキー ボールトを使用します。 詳細については、「Azure Key Vault を使用するためのベスト プラクティス」 および「Azure Key Vault の可用性と冗長性」を参照してください。

注

カスタマー マネージド TDE を柔軟に構成できるように、1 つのリージョン内の Azure SQL Database と Azure SQL Managed Instance を、他のリージョンの Azure Key Vault にリンクできるようになりました。 サーバーとキー コンテナーが同じリージョンに併置されている必要はありません。

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

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

  • キーコンテナーでキーが生成された場合は、初めて Azure Key Vault でキーを使用する前にキー バックアップを作成します。 バックアップは Azure Key Vault にのみ復元できます。 Backup-AzKeyVaultKey コマンドの詳細については、こちらをご覧ください。 Azure Managed HSM では、すべてのキー、バージョン、属性、タグ、ロールの割り当てを含む、HSM のコンテンツ全体の完全バックアップの作成がサポートされています。 詳細については、「 完全バックアップと復元と選択的キーの復元」を参照してください。

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

  • キーをローテーションする際は、キーの古いバージョンをキーボールトやマネージドHSMに保持しておき、古いデータベースのバックアップを復元できます。 データベースのTDEプロテクターが変更される際、古いバックアップは最新のTDEプロテクターに 更新 されません。 復元時には、各バックアップに作成時に暗号化された TDE 保護機能が必要です。 鍵を回転させるには、「 Rotate the Transparent data encryption (TDE)プロテクターを回転させる」という記事の指示に従ってください。

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

  • セキュリティ インシデント中に侵害された可能性のあるキーをデータ損失のリスクなしで削除するには、 PowerShell を使用した Transparent Data Encryption (TDE) 保護機能の削除に関する記事の手順に従います。 侵害されたキーを削除または無効にする前に、常に新しい TDE 保護機能にローテーションし、すべてのデータベースが新しいキーを使用していることを確認します。 鍵をローテーションせずに削除または無効化すると、すべての暗号化されたデータベースがアクセス不能になり、以前にバックアップされて別のボールトに復元された鍵のコピーは無効化されません。

ヒント

TDE でのバージョン管理された Azure キー コンテナー キーとバージョン管理されていない Azure キー コンテナー キーの使用

TDE 保護機能を設定すると、特定のキー バージョンまたはバージョンレス キー識別子を使用して Azure Key Vault キーを参照できます。

どちらの場合も、Azure SQL Database は常に、Azure Key Vault または Azure Key Vault Managed HSM の最新の有効なバージョンのキーを解決して使用します。 TDE 保護機能構成に特定のキー バージョンが埋め込まれるのを回避するには、バージョンレス キー識別子を使用します。

バージョンレス キー識別子は、現在、Azure SQL Database でのみサポートされています。

例:

  • 特定のバージョンを含むキー識別子

    https://<key-vault-name>.vault.azure.net/keys/<key-name>/<key-version>

  • バージョンレス キー識別子

    https://<key-vault-name>.vault.azure.net/keys/<key-name>

TDE プロテクターの回転

TDE 保護機能をローテーションすると、データベース暗号化キー (DEK) の保護に使用するキーを置き換えることができます。 キーのローテーションはオンライン操作であり、数秒で完了します。 この操作では、データベース全体ではなく、データベース暗号化キーの暗号化の解除と再暗号化のみが行われます。

Azure Key Vault または Azure Key Vault Managed HSM に格納されている新しいキーを使用するように構成を切り替えることで、TDE プロテクターをローテーションできます。 Azure SQLオファリングとサポートされている構成に応じて、次のような場合があります。

  • 同じキーの新しいキー バージョンに切り替える
  • 別のキーに切り替える
  • 非対称 (RSA) キーや対称キー (AES) キーなど、サポートされているキーの種類の切り替え

注

対称キー (AES) を使用したTransparent Data Encryptionは現在、Azure SQL Databaseでのみサポートされており、パブリック プレビュー段階です。

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

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

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

注

キーの手動または自動ローテーションを使用して CMK で TDE を設定すると、常にサポートされている最新バージョンのキーが使用されます。 セットアップでは、以前のバージョンまたは下位バージョンのキーの使用は許可されません。 常に最新のキー バージョンを使用すると、侵害される可能性のある以前のキー バージョンを禁止する Azure SQL セキュリティ ポリシーに準拠します。 以前のバージョンのキーは、データベースのバックアップまたは復元の目的で必要になる場合があります。特に、古いキー バージョンを保持する必要がある長期保有バックアップの場合です。 geo レプリケーションのセットアップでは、ソース サーバーに必要なすべてのキーがターゲット サーバーに存在する必要があります。

TDE 保護機能の自動ローテーションを構成するときの地理的レプリケーションに関する検討すべき事項

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

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

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

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

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

アクセスできない TDE 保護装置

TDE がカスタマー マネージド キーを使用するように構成されている場合、データベースをオンラインのままにするには、TDE 保護機能への継続的アクセスが必要です。 サーバーが Azure Key Vault または Azure Managed HSM のカスタマー マネージド TDE 保護機能にアクセスできなくなった場合、最大 10 分で、対応するエラー メッセージを含むすべての接続がデータベースによって拒否され、その状態が [アクセス不可] に変更されます。 アクセス不可状態のデータベースで許可される唯一のアクションは、削除だけです。

アクセスできない状態

ネットワークの断続的な停止 (5XX エラーなど) が原因でデータベースにアクセスできない場合は、データベースが自動的にオンラインに戻されるため、操作は必要ありません。 Azure Key Vault または Azure Managed HSM で TDE 保護機能にアクセスするときのネットワーク エラーまたは停止の影響を軽減するために、サービスがデータベースをアクセスできない状態に移動する前に 24 時間のバッファーが導入されます。 アクセスできない状態に達する前にフェールオーバーが発生した場合、暗号化キャッシュが失われるため、データベースは使用できなくなります。

Azure Key Vault エラー (4XX エラーなど) が原因で、サーバーが Azure Key Vault または Azure Managed HSM のカスタマー マネージド TDE 保護機能にアクセスできなくなった場合、データベースは 30 分後にアクセスできない状態に移動されます。

Azure Key Vault または Azure Managed HSM エラーの後にデータベース アクセスを復元する

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

キー アクセスが 30 分以内に復元された場合、データベースは 1 時間以内に自動的に復旧します。 ただし、キー アクセスが 30 分を超える後に復元された場合、データベースの自動復旧は実行できません。 このような場合、データベースの復元には、Azure portal を使用した追加の手順が必要であり、データベースのサイズによっては時間がかかる場合があります。

データベースがオンラインに戻ると、フェールオーバー グループの構成、タグ、エラスティック プールの構成、読み取りスケール、自動一時停止、ポイントインタイム リストア履歴、長期保持ポリシーなどのデータベース レベルの設定など、以前に構成されたサーバー レベルの設定が失われます。 そのため、30 分以内に暗号化キーアクセスの損失を検出する通知システムを実装することをお勧めします。 30 分のウィンドウの有効期限が切れた後、復旧されたデータベースのすべてのサーバー レベルとデータベース レベルの設定を検証することをお勧めします。

アクセスできないデータベースをオンラインに戻すためにポータルで必要な追加の手順を次に示します。

TDE BYOK にアクセスできないデータベースのスクリーンショット。

TDE 保護機能のアクセスが誤って取り消された場合

キー コンテナーまたはマネージド HSM に対する十分なアクセス権を持つユーザーが、次の方法でキーへのサーバー アクセスを誤って無効にしてしまう可能性があります。

  • キー ボールトまたはマネージド HSM の get、wrapKey、unwrapKey のアクセス許可をサーバーから取り消す

  • キーを削除する

  • キー ボールトまたはマネージド HSM を削除

  • キー ボールトまたはマネージド HSM のファイアウォール規則の変更

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

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

SQL Managed Instance と Azure Key Vault または Azure Managed HSM の間の接続のブロック

SQL Managed Instance とキー コンテナーまたはマネージド HSM の間のネットワーク接続ブロックは、主にキー コンテナーまたはマネージド HSM リソースが存在するが、そのエンドポイントにマネージド インスタンスから到達できない場合に発生します。 キー コンテナーまたはマネージド HSM エンドポイントに到達できるが、接続が拒否されたり、アクセス許可が失われたりするすべてのシナリオでは、データベースの状態が アクセス不可に変更されます。

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

  • Azure Key Vault または Azure Managed HSM はプライベート エンドポイントを介して公開され、マネージド インスタンス サブネットに関連付けられているネットワーク セキュリティ グループ (NSG) の送信規則では、Azure Key Vault または Azure Managed HSM サービスのプライベート IP アドレスは許可されません。

  • キー コンテナーやマネージド HSM の FQDN が解決されない場合や無効な IP アドレスに解決された場合など、DNS 解決が正しくありません。

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

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

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

  • 解決された IP アドレスを調べて、それが有効であることを確認します。 値がない場合は、DNS 解決に問題があることを意味します。

    • 特に解決されたアドレスがキー コンテナーまたはマネージド HSM プライベート エンドポイントに属している場合は、マネージド インスタンスのネットワーク セキュリティ グループに、ポート 443 で解決された IP アドレスをカバーする 送信 規則があることを確認します。

    • ルート テーブル、仮想アプライアンスの存在、その構成などの他のネットワーク構成を確認します。

カスタマー マネージド TDE を監視する

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

  • Azure Resource Health。 TDE 保護機能へのアクセスを失ったアクセスできないデータベースは、データベースへの最初の接続が拒否された後、"使用不可" と表示されます。

  • アクティビティ ログ。ユーザーが管理するキー コンテナーの TDE 保護機能へのアクセスに失敗すると、アクティビティ ログにエントリが追加されます。 これらのイベントに対してアラートを作成すると、できるだけ早くアクセスを再開できるようになります。

  • アクション グループを定義して、設定 (たとえば、メール、SMS、プッシュ、音声、ロジック アプリ、Webhook、ITSM、Automation Runbook) に基づいて通知やアラートを送信できます。

backup と restore のデータベース（カスタマー管理のTDE使用）

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

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

重要

現時点では、サーバーに複数の TDE 保護機能を設定することはできません。 [Azure portal] ウィンドウで [ キーを既定の TDE 保護機能 にする] でマークされているキーは TDE 保護機能です。 ただし、TDE 保護機能としてマークしなくても、複数のキーをサーバーにリンクできます。 これらのキーは DEK の保護には使用されませんが、バックアップ ファイルが対応する拇印を持つキーで暗号化されている場合は、バックアップからの復元中に使用できます。

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

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

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

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

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

複数レイヤーの冗長性を提供する Azure Key Vault または Azure Managed HSM を使用すると、カスタマー マネージド キーを使用する TDE は、Azure Key Vault または Azure Managed HSM の可用性と回復性を活用し、Azure Key Vault または Azure Managed HSM の冗長性ソリューションに完全に依存できます。

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

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

注

すべてのペア リージョンについて、Azure Key Vault キーは両方のリージョンにレプリケートされ、これらのキーを操作できる両方のリージョンにハードウェア セキュリティ モジュール (HSM) があります。 詳細については、「データ レプリケーション」を参照してください。 これは、Standard と Premium の両方の Azure Key Vault サービス レベルと、ソフトウェアまたはハードウェア キーに当てはまります。

Azure Managed HSM マルチリージョン レプリケーションを使用すると、Azure Managed HSM プールを 1 つの Azure リージョン (プライマリ リージョンと呼ばれる) から別の Azure リージョン (拡張リージョンと呼ばれる) に拡張できます。 構成が完了すると、両方のリージョンがアクティブになり、要求を処理できるようになります。自動レプリケーションでは、同じキー マテリアル、ロール、およびアクセス許可を共有できます。 詳細については、「 Azure Managed HSM でマルチリージョン レプリケーションを有効にする」を参照してください。

顧客管理型 TDE を活用した geo ディザスター リカバリー

アクティブジオレプリケーション および フェイルオーバーグループ は、顧客管理のTDEをサポートします。 プライマリおよびセカンダリサーバーは、サポートされているリージョンのどの地域でもAzure Key VaultまたはAzure Managed HSMを使用できます。 サーバーとキーストアは必ずしも同じ地域にある必要はありません。

フェイルオーバーを成功させるためには、両方のサーバーが必要な鍵を含むすべてのAzure Key VaultまたはAzure Managed HSMにアクセスできる必要があります。

構成に関する考慮事項

Azureポータルでアクティブジオレプリケーションやフェイルオーバーグループを設定する際には、以下の点が適用されます。

  • TDEプロテクターの場所:プライマリサーバーとセカンダリサーバーは、同じAzure Key VaultまたはAzureマネージドHSMを使用できます。 同じ鍵庫を使用することで、鍵の資料が同期しなくなるリスクが減ります。複数の地域で別々の鍵保管庫を使う場合、必要な鍵資料を同期させておく必要があります。 キーストアのレジリエンスについては、Azure Key Vaultの可用性および冗長性およびマネージドHSMにおけるマルチリージョンレプリケーションを参照してください。

  • ゾーン冗長性:利用可能な場合、Azure SQL DatabaseやAzure SQL Managed Instanceのゾーン冗長性は、リージョン内で追加のレジリエンスを提供します。 詳細については、「Azure 可用性ゾーンとは」を参照してください。.

  • キー権限:プライマリサーバーとセカンダリサーバーの両方が、必要なTDEプロテクターを含むすべてのAzure Key VaultまたはAzure管理HSMに対して必要な権限を保持している必要があります。

  • キーの入手可能性: 必要なキーがプライマリサーバーとセカンダリサーバーの両方で利用可能であることを確認しましょう。 サーバー同士は同じTDEプロテクターを使う必要はありませんが、各サーバーは同じ鍵素材を持つ必要があります。 Azureポータル、PowerShell、Azure CLI、またはAzure SQL REST APIを使ってサーバーに鍵を追加できます。 フェイルオーバー時に必要なキーが利用できない場合、データベースがアクセス不能になる可能性があります。

  • プライベートエンドポイント:Azure SQLでプライベートエンドポイントを使う場合、設定により複雑なDNSゾーンが必要になるかもしれません(例えば、同じDNSゾーン内で同じリソースに2つのプライベートエンドポイントを作成することはできません)。

  • アプリケーション接続性: アプリケーションはフェイルオーバー中の一時的な障害を処理するためにリトライロジックを用いるべきです。

Azure SQLジオ災害復旧リソースの設定に関する情報は、Active Geo-replicationまたはFailover Groupsの概要およびベストプラクティスをご覧ください。

重要

ジオレプリケーションリンクやフェイルオーバーグループを作成すると、Azure SQLは両方のサーバーがすべての顧客管理キーにアクセスできることを検証します。 どちらかのサーバーが必要な鍵にアクセスできなければ、作成操作は失敗します。 例えば、プライマリサーバーとセカンダリサーバーがそれぞれキーAとキーBを使用している場合、ジオレプリケーションリンクやフェイルオーバーグループを作成する前に両方のキーを両方のサーバーに追加してください。

以下の図は、フェイルオーバーグループを用いたAzure SQLジオレプリケーションと、ペアリージョン構成におけるAzure Key Vaultのクロスリージョンフェイルオーバーを示しています:

ペアリージョンに対する Azure Key Vault のリージョン間フェールオーバーのサポートを示す図。

Azure Key Vault のフェイルオーバー時の挙動

  • フェイルオーバーはあなたが行うのではなく、Azure Key Vaultが開始します。
  • プライマリー リージョンのキー コンテナーが利用できない間、そのキー コンテナーは読み取り専用となります。
  • 鍵の作成、インポート、回転は、主要な地域の鍵保管庫が利用可能である限り可能です。 フェイルオーバー後は、キーの回転は再びプライマリ領域に到達可能になるまでブロックされたままです。
  • キー コンテナーが現在どのリージョンにあるかを選択したり確認することはできず、セカンダリ リージョンに手動で接続することもできません。

アクセス不能なTDEプロテクターからの回復

アクティブなジオレプリケーション関係やフェイルオーバーグループのデータベースがアクセス不能になると、Azure SQL制御プレーンがリンクを切断し、データベースをスタンドアロンのデータベースに変換します。

キー権限を復元した後、通常はプライマリデータベースを再起動できます。 セカンダリデータベースをオンラインに戻すことはできません。なぜならAzure SQLはセカンダリデータベースの完全なバックアップを受け付けないからです。 セカンダリデータベースを廃止し、その後ジオレプリケーションリンクまたはフェイルオーバーグループを再構築します。

カスタマー マネージド 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 が Deny に設定されている場合、Azure SQL 論理サーバーまたはマネージド インスタンスの作成は失敗します。 このエラーの詳細は、リソース グループの アクティビティ ログ に記録されます。

重要

AuditIfNotExists効果を含むカスタマー マネージド TDE の以前のバージョンの組み込みポリシーは非推奨になりました。 非推奨のポリシーを使用する既存のポリシー割り当ては影響を受けず、以前と同様に動作し続けます。

関連するコンテンツ

  • Last updated on