適用対象:Azure SQL Database
Azure SQL Managed Instance
Azure Synapse Analytics (専用の SQL プールのみ)
カスタマー マネージド キー (CMK) を使用した Azure SQL の Transparent Data Encryption (TDE) を使用すると、保存データの保護に Bring Your Own Key (BYOK) シナリオが可能になり、組織がキーとデータの管理における職務の分離を実施できるようになります。 カスタマー マネージド TDE では、キー ライフサイクル管理 (キーの作成、アップロード、交換、削除)、キーの使用権限、およびキーに対する操作の監査は、お客様の責任であり、お客様がこれらを完全に制御できます。
このシナリオでは、Transparent Data Encryption (TDE) 保護機能 (データベース暗号化キー (DEK) のセキュリティ保護に使用されるカスタマー マネージド非対称キー) が 、Azure Key Vault または Azure Key Vault Managed HSM のいずれかに格納されます。 これらは、高可用性とスケーラビリティのために設計された、セキュリティで保護されたクラウドベースのキー管理サービスです。 Azure Key Vault は RSA キーをサポートしており、FIPS 140-2 レベル 2 の検証済み HSM でサポートできます。 より高い保証が必要なお客様のために、Azure Key Vault Managed HSM には FIPS 140-2 レベル 3 の検証済みハードウェアが用意されています。 キーは、サービス内で生成することも、インポートすることも、 オンプレミスの 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 プールの Transparent Data Encryption に関するドキュメントについては、Azure Synapse Analytics の暗号化に関する記事を参照してください。
注
Microsoft Entra ID の、旧称は Azure Active Directory(Azure AD)です。
カスタマー マネージド TDE の利点
注
この記事では、カスタマー マネージド キー (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 保護機能の使用の透明性。
組織内のキーとデータの管理に職務の分離を実装する機能。
Azure Key Vault 管理者は、キー アクセス許可を取り消して、暗号化されたデータベースにアクセスできないようにすることができます。
Azure Key Vault でのキーの一元管理。
Azure Key Vault は Microsoft が暗号化キーを表示したり抽出したりできないように設計されているため、エンド カスタマーからの信頼が高くなります。
重要
カスタマー マネージド TDE の使用を開始したいサービス管理 TDE を使用する場合、切り替えプロセス中もデータは暗号化されたままであり、データベース ファイルのダウンタイムや再暗号化はありません。 サービス マネージド キーからカスタマー マネージド キーへの切り替えに必要なのは、高速のオンライン操作である DEK の再暗号化だけです。
カスタマー マネージド TDE を構成するためのアクセス許可
使用する Azure Key Vault の種類を選択します。
Azure 内の論理サーバーで、DEK の暗号化に Azure Key Vault に格納されている TDE 保護機能を使用するには、Key Vault 管理者が一意の Microsoft Entra ID を使用してサーバーへのアクセス権を付与する必要があります。 サーバー 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 保護機能を構成するための要件
TDE 保護機能には、非対称、RSA、または RSA HSM の各キーのみを指定できます。 サポートされるキーの長さは、2,048 ビットと 3,072 ビットです。
キーがアクティブ化された日時 (設定する場合) は、過去の日付と時刻にする必要があります。 有効期限の日時 (設定する場合) は、将来の日付と時刻にする必要があります。
キーは、"有効" 状態になっている必要があります。
キー コンテナーに既存のキーをインポートする場合は、サポートされているファイル形式 (
.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 で使用できなくなります。 この問題の詳細については、こちらをご覧ください。 このような場合は、Azure Key Vault にキーをインポートしてから 24 時間待って、サーバーまたはマネージド インスタンスの TDE 保護機能として使用を開始します。 この問題は Thales CipherTrust Manager v2.8.0 で解決されています。
カスタマー マネージド TDE を構成する際の推奨事項
サーバーがキー コンテナー内の TDE 保護機能にアクセスする際の高可用性を確保するために、1 つのサブスクリプションで 1 つのキー コンテナーに最大 500 の General Purpose データベースまたは 200 の Business Critical データベースを関連付けます。 これらの数値は、エクスペリエンスに基づいており、 Azure Key Vault サービスの制限に記載されています。 目的は、サーバーのフェールオーバー後の問題を回避することです。これは、フェールオーバーによってそのサーバー内のデータベースと同じ数のキー操作がコンテナーに対してトリガーされるためです。
キー コンテナーにリソース ロックを設定して、この重要なリソースを削除できるユーザーを制御し、誤削除や許可されていない削除を防ぎます。 リソース ロックの詳細については、こちらをご覧ください。
すべての暗号化キーの監査とレポートを有効にする: 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 など) に変更を加えるたびに新しいバックアップを作成します。
以前のバージョン のキーは、キーのローテーション時にキー コンテナーまたは Managed HSM に保持して、古いデータベース バックアップを復元できるようにします。 データベースの TDE 保護機能が変更されても、データベースの古いバックアップが、最新の TDE 保護機能を使用するように更新されることはありません。 復元時には、各バックアップに作成時に暗号化された TDE 保護機能が必要です。 キーの交換を行うには、「PowerShell を使用して 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 を使用して、これらのキーの回復可能なバックアップ コピーを作成します。
セキュリティ インシデントの発生時に、データ損失のリスクを伴わずに、侵害された可能性のあるキーを削除するには、侵害された可能性のあるキーの削除の手順に従ってください。
TDE プロテクターの回転
サーバーの TDE 保護機能のローテーションは、サーバー上のデータベースを保護する新しい非対称キーに切り替えることを示します。 キーのローテーションはオンライン操作であり、数秒で完了します。 この操作では、データベース全体ではなく、データベース暗号化キーの暗号化の解除と再暗号化のみが行われます。
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) を使用する geo レプリケーション シナリオがサポートされています。 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 保護機能のアクセスが誤って取り消された場合
キー コンテナーまたはマネージド 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 のバックアップ回復の詳細については、SQL Database のデータベース回復に関する記事を参照してください。 Azure Synapse Analytics の専用 SQL プールのバックアップ復旧の詳細については、専用 SQL プールの復旧に関するページを参照してください。 SQL Managed Instance を使用した SQL Server のネイティブ バックアップと復元については、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 でマルチリージョン レプリケーションを有効にする」を参照してください。
Geo-DR とカスタマー マネージド TDE
アクティブ geo レプリケーションとフェールオーバー グループの両方のシナリオでは、関係するプライマリ サーバーとセカンダリ サーバーを、任意のリージョンにある Azure Key Vault または Azure Managed HSM にリンクできます。 サーバーとキー コンテナー、またはマネージド HSM を同じリージョンに併置する必要はありません。 これにより、わかりやすくするために、プライマリ サーバーとセカンダリ サーバーを同じキー コンテナーまたはマネージド HSM (任意のリージョン) に接続できます。 これにより、両方のサーバーに個別のキー コンテナーまたはマネージド HSM が使用されている場合に、キー マテリアルが同期できなくなる可能性があるシナリオを回避できます。
Azure Key Vault と Azure Managed HSM には、サービスまたはリージョンの障害が発生した場合でもキーとキー コンテナーを使用できるように、複数の冗長性レイヤーが用意されています。 冗長性は、ペアになっていないリージョンとペアになっているリージョンでサポートされます。 詳細については、「Azure Key Vault の可用性と冗長性」を参照してください。
お客様の要件に基づいて、TDE 保護機能キーを格納するためのオプションがいくつかあります。
Azure Key Vault とネイティブペアリージョンの回復性または非ペアリージョンの回復性を活用します。
お客様の HSM を活用し、キーを複数リージョンにまたがる個別の Azure Key Vault に読み込むことができます。
Azure Managed HSM とリージョン間レプリケーション オプションを利用します。
- このオプションを使用すると、キーをレプリケートする目的のリージョンを選択できます。
次の図は、Azure Key Vault のクロスフェールオーバーと、フェールオーバー グループを使用した geo レプリケーション用の Azure SQL セットアップのペアリージョン (プライマリとセカンダリ) の構成を示しています。
Geo-DR に関する Azure Key Vault の解説
Azure SQL のプライマリ サーバーとセカンダリ サーバーの両方が、プライマリ リージョンの Azure Key Vault にアクセスします。
Azure Key Vault のフェールオーバーは、お客様ではなく Azure Key Vault サービスによって開始されます。
セカンダリ リージョンへの Azure Key Vault フェールオーバーの場合でも、Azure SQL のサーバーは同じ Azure Key Vault にアクセスできます。 内部的には、Azure Key Vault 接続はセカンダリ リージョンの Azure Key Vault にリダイレクトされます。
新しいキーの作成、インポート、およびキーローテーションは、プライマリ内の Azure Key Vault を使用できる間のみ可能です。
フェールオーバーが発生すると、ペアになっているリージョンのプライマリ リージョン内の Azure Key Vault に再度アクセスできるようになるまで、キーのローテーションは許可されません。
顧客はセカンダリ リージョンに手動で接続できません。
Azure Key Vault は読み取り専用の状態ですが、プライマリ リージョンの Azure Key Vault は使用できません
お客様は、Azure Key Vault が現在存在するリージョンを選択または確認できません。
ペアになっていないリージョンの場合、両方の Azure SQL サーバーが (グラフに示されているように) 最初のリージョンの Azure Key Vault にアクセスし、Azure Key Vault はゾーン冗長ストレージを使用して、同じリージョンの独立した可用性ゾーン間でリージョン内のデータをレプリケートします。
詳細については、「Azure Key Vault の可用性と冗長性の 、Azure リージョン ペアと非ペアリージョン 、Azure Key Vault のサービス レベル アグリーメントのに関するページを参照してください。
Geo-DR の Azure SQL 解説
回復性を高めるために、Azure SQL MI と Azure SQL DB のゾーン冗長オプションを使用します。 詳細については、「Azure 可用性ゾーンとは」を参照してください。.
セカンダリ リージョンへのディザスター リカバリーには、Azure SQL MI と Azure SQL DB のフェールオーバー グループを使用します。 詳細については、「フェールオーバー グループの概要」& ベスト プラクティスを参照してください。
データベースがアクティブ geo レプリケーションまたはフェールオーバー グループの一部であり、 アクセスできなくなった場合、SQL コントロール プレーンはリンクを切断し、データベースをスタンドアロン データベースに変換します。 キーのアクセス許可を修正した後は、通常、プライマリ データベースをオンラインに戻すことができます。 Azure SQL では、設計上、セカンダリ データベースの完全バックアップが実行されないため、セカンダリ データベースをオンラインに戻すことはできません。 セカンダリ データベースを削除し、リンクを再確立することをお勧めします。
Azure SQL でプライベート エンドポイントを使用する場合は、構成により複雑な DNS ゾーンが必要になる場合があります (たとえば、同じ DNS ゾーン内の同じリソースに対して 2 つのプライベート エンドポイントを作成することはできません)。
アプリケーションが再試行ロジックを活用していることを確認します。
お客様が Azure Key Vault を使用して Azure Managed HSM ソリューションを選択する場合は、いくつかのシナリオがあります。
セカンダリ コンテナーへの手動接続要件。
障害が発生した場合でも、コンテナーへの読み取りアクセスの要件。
キー マテリアルをレプリケートするリージョンを柔軟に選択できます
- 2 番目のリージョンに 2 つ目の Azure Managed HSM プールを作成するリージョン間レプリケーションを有効にする必要があります。
Azure Managed HSM を使用すると、元のレプリカが失われたり使用できなくなったりした場合に、HSM の正確なレプリカを作成できます。
セキュリティまたは規制の要件に対する Azure 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 に対する以前のバージョンの組み込みポリシーは非推奨になりました。 非推奨のポリシーを使用する既存のポリシー割り当ては影響を受けず、以前と同様に機能し続けます。