適用対象: Azure Synapse Analytics 専用 SQL プール (旧称 SQL DW)
Tip
Microsoft Fabric Data Warehouse は、将来のアーキテクチャ、組み込みの AI、および新機能を備えた、Data Lake 基盤上のエンタープライズ 規模のリレーショナル ウェアハウスです。 データ ウェアハウスを初めて使用する場合は、Fabric Data Warehouseから始めます。 既存の dedicated SQL プール ワークロードは、Fabric にアップグレードして、データ サイエンス、リアルタイム分析、レポートの新機能にアクセスできます。
- Fabric無料試用版を開始します。
- Fabric Data Warehouseの移行アシスタント。
顧客管理鍵(CMK)を用いた透明なデータ暗号化(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から安全に転送したりできます。 鍵への直接アクセスは制限されているため、認可されたサービスは鍵の資料を公開することなく暗号操作を行います。
Note
この記事では、スタンドアロン専用SQLプール(旧SQL DW)について扱っています。
- Azure Synapse Analytics専用SQLプール(旧SQL DW)については、TDEプロテクターをサーバーレベルで設定します。 そのサーバーに関連付けられたすべての暗号化データベースはTDEプロテクターを引き継ぎます。
- Synapseワークスペース内の専用SQLプールおよびサーバーレスSQLプールでデータを暗号化し、ワークスペースレベルで設定された顧客管理キーを使用します。 Synapse ワークスペース内の専用 SQL プールの透過的なデータ暗号化の詳細については、 Azure Synapse Analytics の暗号化に関するページを参照してください。
カスタマー マネージド キー (CMK) と Bring Your Own Key (BYOK)
この記事では、カスタマー マネージド キー (CMK) と Bring Your Own Key (BYOK) という用語を同じように使用しますが、いくつかの違いを表しています。
カスタマー マネージド キー (CMK) - お客様が、キーの作成、ローテーション、削除を含むキー ライフサイクルを管理します。 鍵をAzure Key VaultまたはAzure Managed HSMに保存し、データベース暗号化鍵(DEK)の暗号化に使います。
Bring Your Own Key (BYOK) - オンプレミスのハードウェア セキュリティ モジュール (HSM) から Azure Key Vault に自分のキーを安全に持ち込むか、インポートします。 このようなインポートされたキーは、DEK の暗号化用のカスタマー マネージド キーなど、Azure Key Vault 内の他のキーとして使用できます。 詳細については、「HSM で保護されたキーを Managed HSM (BYOK)にインポートする」を参照してください。
カスタマー マネージド TDE の利点
顧客管理型TDEは以下の利点を提供します:
TDE 保護機能の使用状況と管理を完全かつきめ細かく制御します。
TDE 保護機能の使用の透明性。
組織内のキーとデータの管理に職務の分離を実装する機能。
Azure Key Vault 管理者は、キー アクセス許可を取り消して、暗号化されたデータベースにアクセスできないようにすることができます。
Azure Key Vault でのキーの一元管理。
Azure Key Vault は Microsoft が暗号化キーを表示したり抽出したりできないように設計されているため、エンド カスタマーからの信頼が高くなります。
Important
サービス管理型TDEを利用し、顧客管理TDEを使い始めたい場合、切り替え過程でデータは暗号化されたままで、ダウンタイムはなく、データベースファイルの再暗号化もありません。 サービス マネージド キーからカスタマー マネージド キーへの切り替えに必要なのは、高速のオンライン操作である DEK の再暗号化だけです。
Azure Key Vault で顧客管理のTDEを構成する権限
使用する Azure Key Vault の種類を選択します。
AzureのSQL論理サーバーがAzure Key Vaultに保存されたTDEプロテクターをDEKの暗号化に使用するためには、Key Vault管理者は、サーバー固有の Microsoft Entra ID を使用して、サーバーにアクセス権を付与する必要があります。 サーバー ID には、システム割り当てマネージド ID またはサーバーに割り当てられたユーザー割り当てマネージド ID を指定できます。 サーバーにキー コンテナーへのアクセスを許可するには、次の 2 つのアクセス モデルがあります。
Azure ロールベースのアクセス制御 (RBAC) - Azure RBAC を使用して、ユーザー、グループ、またはアプリケーションにキー コンテナーへのアクセス権を付与します。 柔軟性と細分性のためには、この方法が推奨されます。 サーバーの ID には、暗号化および復号化の操作でキーを使用するために、Key Vault Crypto Service Encryption User ロールが必要です。
コンテナー アクセス ポリシー - キー コンテナー アクセス ポリシーを使用して、サーバーにキー コンテナーへのアクセス権を付与します。 この方法は、よりシンプルで簡単ですが、柔軟性は低くなります。 サーバーアイデンティティにはキーボールトに対する以下の権限が必要です:
- get - Azure Key Vault 内のキーの公開部分とプロパティを取得する場合
- wrapKey - DEK を保護 (暗号化) できるようにします
- unwrapKey - DEK を保護解除 (復号化) できるようにします
[アクセス構成] の[キー コンテナーの Azure portal メニュー] には、[Azure ロールベースのアクセス制御] または [Vault アクセス ポリシー] を選択するオプションがあります。 TDE 用の Azure Key Vault アクセス構成を設定するための手順については、Azure Key Vault を使用して SQL Server TDE Extensible Key Management を設定する を参照してください。 アクセス モデルに関する詳細については、「Azure Key Vault セキュリティ」を参照してください。
キー コンテナー管理者は、後で監査できるように、キー コンテナーの監査イベントのログ記録を有効にすることもできます。
Azure Key Vault の TDE プロテクターを使用するようにサーバーを設定すると、サーバーは TDE 対応データベースごとの DEK を、暗号化のためにキー コンテナーに送信します。 キーボールトは暗号化されたDEKを返し、サーバーはそれをユーザーデータベースに保存します。
必要に応じて、サーバーは保護された DEK を復号のために鍵の保管庫に送ります。
監査人はログが有効であれば、Azure Monitorを使ってKey Vault の AuditEvent ログを確認できます。
Note
鍵の保管庫で許可の変更が有効になるまで約10分かかるかもしれません。 この時間にはAKVのTDEプロテクターへのアクセス権限の取り消しも含まれており、ユーザーは引き続きアクセス権限を保持している可能性があります。
Azure Key Vault で顧客管理 TDE を構成するための要件
Azure Key Vaultでソフト削除およびパージ保護機能を有効にしてください。 この設定により、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に保存され、データベース暗号化キー (DEK) を保護します。
次の要件が適用されます。
サポートされているキーの種類とサイズ
TDEプロテクタは、Azure Key Vaultに保存された非対称鍵で保護できます。 対応キーサイズは2,048ビットと3,072ビットです。
キーの状態と有効性の要件
- キーの有効化日を指定する場合は、過去の日付と時刻に設定してください。
- キーの有効期限を指定する場合は、現在より後の日時に設定してください。
- キーは、"有効" 状態になっている必要があります。
主なインポート要件
既存の鍵をAzure Key Vaultにインポートした場合、以下のいずれかの対応形式で鍵を提供してください:
.pfx.byok.backup
Azure Key Vault で顧客管理 TDE を構成するための推奨事項
高可用性を維持し、調整の問題を回避するには、サブスクリプションごとに次のガイドラインに従います。
最適なパフォーマンスと信頼性を確保するために、Azure SQL専用のAzure Key Vaultを使用してください。 このキーボールトを他のサービスと共有しないでください。 鍵の保管庫が共有使用や過剰な鍵操作で重負荷がかかる場合、特に暗号化鍵アクセス時にデータベースのパフォーマンスに悪影響を及ぼす可能性があります。 Azure Key Vault では スロットリング制限が適用されます。 これらの制限を超えると、操作が遅れたり失敗したりする可能性があります。 このリスクはサーバーフェイルオーバー時に最も高く、サーバー上のすべてのデータベースでキー操作がトリガーされます。
スロットリングの動作についての詳細は、Azure Key Vaultのスロットリングガイダンスをご覧ください。
単一の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 アラートを構成する」をご覧ください。
キー コンテナーにリソース ロックを設定して、この重要なリソースを削除できるユーザーを制御し、誤削除や許可されていない削除を防ぎます。 リソース ロックについて詳しくは
すべての暗号化キーの監査とレポートを有効にする: Azure Key Vault には、他のセキュリティ情報とイベント管理ツールに簡単に挿入できるログが用意されています。 Operations Management Suite Log Analytics は、既に統合されているサービスの一例です。
可用性を最大限に高めるために、コンテンツをペアリージョンにレプリケートできる Azure リージョンのキー ボールトを使用します。 詳細については、「Azure Key Vault を使用するためのベスト プラクティス」 および「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 Key Vaultに保存されたTDEプロテクターでデータベースバックアップを復元できます。 Azure Key Vault で作成された TDE プロテクターは、残存する保存済みバックアップがすべてサービス マネージド キーで作成されたものになるまで、維持する必要があります。 Backup-AzKeyVaultKeyを使ってこれらのキーの復元可能なバックアップコピーを作成しましょう。
セキュリティ インシデント中に侵害された可能性のあるキーをデータ損失のリスクなしで削除するには、 PowerShell を使用した Transparent Data Encryption (TDE) 保護機能の削除に関する記事の手順に従います。 侵害されたキーを削除または無効にする前に、常に新しい TDE 保護機能にローテーションし、すべてのデータベースが新しいキーを使用していることを確認します。 鍵をローテーションせずに削除または無効化すると、すべての暗号化されたデータベースがアクセス不能になり、以前にバックアップされて別のボールトに復元された鍵のコピーは無効化されません。
TDE プロテクターの回転
TDEプロテクターをローテーションすると、データベース暗号化キー (DEK) を保護するキーを交換します。 キーの回転はオンラインで行う操作で、数秒で完了します。 この操作はデータベース暗号化キーのみを復号・再暗号化し、データベース全体は対象ではありません。
Azure Key Vaultに保存された新しい鍵を使う設定に切り替えることで、TDEプロテクターをローテーションすることができます。 提供内容や対応する構成によって、このキーは以下の通りです:
- 同じキーの新しいキー バージョンに切り替える
- 別のキーに切り替える
TDEプロテクターの回転は 手動または自動回転機能で行うことができます。
サーバーのTDEプロテクターを設定する際に、 TDEプロテクターの自動回転 を有効にすることができます。 既定では、自動ローテーションは無効になっています。 有効化されると、サーバーはTDEプロテクタとして使われる鍵の新しいバージョンがないか鍵の保管庫を継続的にチェックします。 サーバーが鍵の新しいバージョンを検出すると、24時間以内にサーバーやデータベースのTDEプロテクターを自動的に最新の鍵バージョンにローテーションします。
Note
手動または自動のキー回転でCMKでTDEを設定する場合、システムがサポートするキーの最新バージョンを常に使います。 このセットアップでは、以前のバージョンやそれ以下のバージョンのキーを使うことはできません。 常に最新のキー バージョンを使用すると、侵害される可能性のある以前のキー バージョンを禁止する Azure SQL セキュリティ ポリシーに準拠します。
アクセスできない TDE 保護装置
TDEを顧客管理キーに設定すると、データベースはオンラインを維持するためにTDEプロテクターへの継続的なアクセスが必要です。 サーバーが Azure Key Vault 内の顧客管理 TDE プロテクターへのアクセスを失うと、データベースは 10 分以内にすべての接続を拒否し、エラー メッセージを表示して、状態が Inaccessible に変わります。 アクセス不可状態のデータベースで許可される唯一のアクションは、削除だけです。
アクセスできない状態
ネットワークの断続的な停止 (5XX エラーなど) が原因でデータベースにアクセスできない場合は、データベースが自動的にオンラインに戻されるため、操作は必要ありません。 Azure Key VaultのTDEプロテクターにアクセスする際のネットワークエラーや障害の影響を減らすため、サービスはデータベースをアクセス不能状態に移行する前に24時間のバッファを導入しています。 アクセスできない状態に達する前にフェールオーバーが発生した場合、暗号化キャッシュが失われるため、データベースは使用できなくなります。
もしサーバーがAzure Key Vault内の顧客管理TDEプロテクターへのアクセスを、例えば4XXエラーなどのAzure Key Vault エラーで失うと、データベースは30分後にアクセス不能状態に移行します。
Azure Key Vault エラーの後でデータベース アクセスを復元する
キーへのアクセスが復元された後、データベースをオンラインに戻すには、追加の時間と手順が必要になります。これは、キーが使用できない期間とデータベース内のデータのサイズによって異なる場合があります。
キー アクセスが 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 間で接続がブロックされている
SQL Managed Instance とキー コンテナーまたはマネージド HSM の間のネットワーク接続ブロックは、主にキー コンテナーまたはマネージド HSM リソースが存在するが、そのエンドポイントにマネージド インスタンスから到達できない場合に発生します。 キー コンテナーまたはマネージド HSM エンドポイントに到達できるが、接続が拒否されたり、アクセス許可が失われたりするすべてのシナリオでは、データベースの状態が アクセス不可に変更されます。
Azure Key Vault へのネットワーク接続ができない最も一般的な原因は次のとおりです：
Azure Key Vaultはプライベートエンドポイントを通じて公開されており、管理されたインスタンスサブネットに関連付けられたNetwork Security Group(NSG)のアウトバウンドルールでは、Azure Key VaultサービスのプライベートIPアドレスは許可されていません。
キー コンテナーやマネージド HSM の FQDN が解決されない場合や無効な IP アドレスに解決された場合など、DNS 解決が正しくありません。
SQL Managed InstanceからTDEプロテクターをホストするAzure Key Vaultへの接続をテストしてください。
- エンドポイントは、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、自動化ランブックなど、あなたの好みに基づいて通知やアラートを送信するために定義できます。
顧客管理 TDE によるデータベースのバックアップと復元
Azure Key Vaultの鍵を使ってTDEで暗号化されたデータベースは、新たに生成されたバックアップも同じTDEプロテクターで暗号化されます。 TDE 保護機能を変更しても、データベースのバックアップは、最新の TDE 保護機能を使用するように "更新されません"。
Azure Key VaultからTDEプロテクターで暗号化されたバックアップを復元するには、キー マテリアルがターゲットサーバーで利用可能であることを確認しましょう。 したがって、すべての古いバージョンのTDEプロテクターはキーボールトまたはマネージドHSMに保管し、データベースバックアップを復元できるようにしてください。
Important
現時点では、サーバーに複数の TDE 保護機能を設定することはできません。 [Azure portal] ウィンドウで [ キーを既定の TDE 保護機能 にする] でマークされているキーは TDE 保護機能です。 ただし、TDE 保護機能としてマークしなくても、複数のキーをサーバーにリンクできます。 これらのキーはDEKを保護するためには使われませんが、バックアップファイルが対応するサムプリント付きキーで暗号化されていれば、バックアップからの復元時に使用できます。
ターゲット サーバーでバックアップの復元に必要なキーが使用できなくなった場合は、復元の試行時に次のエラー メッセージが返されます。"ターゲット サーバー <Servername> は、<Timestamp #1> から <Timestamp #2> の間に作成されたいずれの AKV URI にもアクセスできません。 すべての AKV URI を復元してから操作をやり直してください\)
これを軽減するには、ターゲット サーバーに対して Get-AzSqlServerKeyVaultKey コマンドレットを実行するか、ターゲット マネージド インスタンスに対して Get-AzSqlInstanceKeyVaultKey を実行して、使用可能なキーの一覧を返し、不足しているキーを識別します。 すべてのバックアップを復元できるようにするには、復元のターゲット サーバーが必要なすべてのキーにアクセスできることを確認します。 これらのキーを TDE 保護機能としてマークする必要はありません。
Azure Synapse Analytics の専用 SQL プールのバックアップ復旧の詳細については、専用 SQL プールの復旧に関するページを参照してください。
ログ ファイルに関する他の考慮事項: TDE プロテクターが回転されてデータベースが新しい TDE プロテクターを使用している場合でも、バックアップされたログ ファイルは元の TDE プロテクターで暗号化されたままです。 復元時に、データベースを復元するには両方のキーが必要です。 ログファイルがAzure Key Vaultに保存されたTDEプロテクターを使用している場合、たとえその間にデータベースがサービス管理型TDEに変更されていても、復元時にこのキーが必要です。
カスタマー マネージド TDE による高可用性
Azure Key Vaultの多層冗長性を利用することで、顧客管理キーを使用するTDEはAzure Key Vaultの可用性とレジリエンスの恩恵を受けることができます。 彼らはAzure Key Vaultの冗長性ソリューションを完全に信頼できます。
Azure Key Vaultの複数の冗長レイヤーにより、個々のサービスコンポーネントが故障したり、Azureのリージョンや可用性ゾーンがダウンしてもキーアクセスが保証されます。 詳細については、「Azure Key Vault の可用性と冗長性」を参照してください。
Azure Key Vaultは、ユーザーの介入なしに自動的に以下の可用性とレジリエンスの要素を提供します: