次の方法で共有

カスタマー マネージド キーを使用した 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 では、キー ライフサイクル管理 (キーの作成、アップロード、交換、削除)、キーの使用権限、およびキーに対する操作の監査は、お客様の責任であり、お客様がこれらを完全に制御できます。

このシナリオでは、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)」をご覧ください。

注意

  • この記事は、Azure SQL Database、Azure SQL Managed Instance、Azure Synapse Analytics (専用 SQL プール (以前の SQL DW)) に適用されます。 Synapse ワークスペース内の専用 SQL プールの Transparent Data Encryption に関するドキュメントについては、Azure Synapse Analytics の暗号化に関する記事を参照してください。
  • Azure SQL のお客様に、2 つのレイヤーで保存データの暗号化を提供するため、プラットフォーム マネージド キーによる (AES-256 暗号化アルゴリズムを使用した) インフラストラクチャ暗号化がロールアウトされています。これにより、既に利用可能なカスタマー マネージド キーによる TDE と共に、保存時の暗号化の追加レイヤーが提供されます。 Azure SQL Database と Azure SQL Managed Instance の場合、インフラストラクチャの暗号化が有効になっていると、master データベースやその他のシステム データベースを含むすべてのデータベースが暗号化されます。 現時点では、お客様はこの機能に対するアクセスを要求する必要があります。 この機能に関心がある場合は、AzureSQLDoubleEncryptionAtRest@service.microsoft.comにお問い合わせください。

注意

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

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

注意

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

  • カスタマー マネージド キー (CMK) - キーの作成、ローテーション、削除など、キーのライフサイクルが顧客によって管理されます。 キーは、Azure Key Vault または Azure Key Vault Managed HSM に格納され、Azure SQL、Azure VM 上の SQL Server、およびオンプレミスの SQL Server のデータベース暗号化キー (DEK) の暗号化に使用されます。
  • Bring Your Own Key (BYOK) - お客様は、オンプレミスのハードウェア セキュリティ モジュール (HSM) から Azure Key Vault または Azure Key Vault Managed HSM に独自のキーを安全に取り込んだり、インポートしたりします。 このようなインポートされたキーは、DEK の暗号化のためのカスタマー マネージド キーなど、Azure Key Vault 内の他のキーとして使用できます。 詳細については、「HSM で保護されたキーを Managed HSM (BYOK)にインポートする」を参照してください。

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

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

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

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

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

  • AKV でのキーの一元管理

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

重要

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

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

カスタマー マネージド 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 ログを確認できます。

注意

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

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

AKV を構成するための要件

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

重要

新しいまたは既存のサーバーまたはマネージド インスタンスで、カスタマー マネージド TDE を構成する場合、キー コンテナーで論理的な削除と消去保護の両方を有効にする必要があります。

論理的な削除と消去保護は、削除されたコンテナーと削除されたキー コンテナー オブジェクトの回復を可能にする 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) で提供するようにしてください。

注意

Azure SQL および Azure VM 上の SQL Server では、TDE プロテクターとしてマネージド HSM に保存されている RSA キーを使用できます。 Azure Key Vault Managed HSM は、フル マネージド、高可用性、シングル テナント、標準準拠を特徴とするクラウド サービスで、FIPS 140-2 レベル 3 適合の HSM を使用してクラウド アプリケーションの暗号化キーを保護することができます。 マネージド HSM と SQL Server に必要な構成または RBAC アクセス許可の詳細については、「Azure Key Vault を使用した SQL Server TDE 拡張キー管理を設定する」の記事を参照してください。

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

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

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

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

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

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

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

注意

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

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 保護機能に対してエンドツーエンドのゼロタッチローテーションが可能になります。

注意

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

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 分以内に対応するエラー メッセージですべての接続を拒否するようになり、状態が "アクセス不可" に変わります。 アクセス不可状態のデータベースで許可される唯一のアクションは、削除だけです。

注意

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

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

注意

  • キーのアクセスが 30 分以内に復元された場合、データベースは次の 1 時間以内に自動回復します。
  • キーのアクセスが 30 分以上経ってから復元された場合、データベースの自動回復は実行できません。 データベースを復旧するには Azure portal で追加の手順を実行する必要があり、データベースのサイズによってはかなりの時間がかかることがあります。
  • データベースがオンラインに戻ると、以前に構成したサーバーレベルの設定 (フェールオーバー グループ構成、タグなど) と、データベースレベルの設定 (エラスティック プールの構成、読み取りスケール、自動一時停止、ポイントインタイム リストアの履歴、長期保有ポリシーなど) は失われます。 そのため、暗号化キーのアクセスの損失を 30 分以内に特定する通知システムをお客様が実装することをお勧めします。 30 分の期間が経過したら、復旧されたデータベースのすべてのサーバー レベルとデータベース レベルの設定を検証することをお勧めします。

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

TDE BYOK のアクセスできないデータベース

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

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

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

  • キーを削除する

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

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

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

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

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

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

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) に基づいて通知やアラートを送信できます。

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

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

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

重要

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

ターゲット サーバーでバックアップの復元に必要なキーが使用できなくなった場合は、復元の試行時に次のエラー メッセージが返されます。"ターゲット サーバー <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 には、ユーザーの介入なしに自動的に提供される以下の可用性と回復性のコンポーネントが用意されています。

注意

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

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

アクティブ geo レプリケーション と フェールオーバー グループ シナリオの両方で、関連するプライマリ サーバーとセカンダリ サーバーを任意のリージョンにある Azure Key Vault にリンクできます。 サーバーとキー コンテナーを同じリージョンに併置する必要はありません。 これにより、わかりやすくするために、プライマリサーバーとセカンダリサーバーを同じ key vault (任意のリージョン) に接続できます。 これにより、両方のサーバーで別個のキー コンテナーが使用されている場合にキー マテリアルが非同期になるというシナリオを回避できます。 

Azure Key Vault には、サービスまたはリージョンの障害が発生した場合でもキーとキー コンテナーを使用できるように、複数の冗長性レイヤーが用意されています。 冗長性は、ペアになっていないリージョンとペアになっているリージョンでサポートされます。 詳細については、「Azure Key Vault の可用性と冗長性」を参照してください。

お客様の要件に基づいて、TDE 保護機能キーを格納するためのオプションがいくつかあります。

  • Azure Key Vault とネイティブペアリージョンの回復性または非ペアリージョンの回復性を活用します。

  • 顧客の HSM を活用し、複数のリージョン間で個別の AKV 内の Azure Key Vault にキーを読み込みます。

  • Managed HSM とリージョン間レプリケーション オプションを活用します。

    • このオプションを使用すると、キーをレプリケートする目的のリージョンを選択できます。

次の図は、フェールオーバー グループを使用した geo レプリケーション用の Azure SQL セットアップを使用した AKV クロスフェールオーバーのペアリージョン (プライマリとセカンダリ) の構成を示しています。

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

Geo-DR に関する Azure Key Vault の解説

  • Azure SQL のプライマリ サーバーとセカンダリ サーバーの両方が、プライマリ リージョンの AKV にアクセスします。

  • AKV フェールオーバーは、お客様ではなく AKV サービスによって開始されます。

  • セカンダリ リージョンへの AKV フェールオーバーの場合でも、Azure SQL のサーバーは同じ AKV にアクセスできます。 内部的には、AKV 接続はセカンダリ リージョンの AKV にリダイレクトされます。

  • 新しいキーの作成、インポート、およびキーのローテーションは、プライマリの AKV が使用可能な間のみ可能です。

  • フェールオーバーが発生すると、ペアになっているリージョンのプライマリ リージョンの AKV に再度アクセスできるようになるまで、キーのローテーションは許可されません。

  • 顧客はセカンダリ リージョンに手動で接続できません。

  • AKV は読み取り専用の状態ですが、プライマリ リージョンの AKV は使用できません

  • お客様は、AKV が現在存在するリージョンを選択または確認できません。

  • ペアになっていないリージョンの場合、両方の Azure SQL サーバーが (グラフに示されているように) 最初のリージョンの AKV にアクセスし、AKV はゾーン冗長ストレージを使用して、同じリージョンの独立した可用性ゾーン間でリージョン内のデータをレプリケートします。

詳細については、「Azure Key Vault の可用性と冗長性の 、Azure リージョン ペアと非ペアリージョン 、Azure Key Vault のサービス レベル アグリーメントのに関するページを参照してください。

Geo-DR の Azure SQL 解説

  • 回復性を高めるために、Azure SQL MI と Azure SQL DB のゾーン冗長オプションを使用します。 詳細については、「Azure 可用性ゾーンとは」を参照してください。.

  • セカンダリ リージョンへのディザスター リカバリーには、Azure SQL MI と Azure SQL DB のフェールオーバー グループを使用します。 詳細については、「フェールオーバー グループの概要」& ベスト プラクティスを参照してください。

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

  • アプリケーションが再試行ロジックを活用していることを確認します。

お客様が AKV 経由でマネージド ハードウェア セキュリティ モジュール (HSM) ソリューションを選択する場合は、いくつかのシナリオがあります。

  • セカンダリボールトへの手動接続要件。

  • 障害が発生した場合でも、ボールトへの読み取りアクセスの要件。

  • キー マテリアルをレプリケートするリージョンを柔軟に選択できます

    • 2 番目のリージョンに 2 つ目の Managed HSM プールを作成するリージョン間レプリケーションを有効にする必要があります。

  • Managed HSM を使用すると、元の HSM が失われたり使用できなくなったりした場合に、HSM の正確なレプリカを作成できます。

  • セキュリティまたは規制の要件に対する Managed HSM の使用。

  • ボールト全体をバックアップする機能と比較して、個々のキーをバックアップする機能を持つ。

詳細については、「Azure Managed HSM でマルチリージョン レプリケーションを有効にする 」と「Managed HSM のディザスター リカバリー」を参照してください。

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

重要

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

関連するコンテンツ