Azure SQL DatabaseのTransparent Data Encryption (TDE) 有効化設定手順

2026.01.14 　最終更新日: 2026.01.15

このブログシリーズ「クラウドセキュリティ実践集」では、一般的なセキュリティ課題を取り上げ、「なぜ危険なのか？」というリスクの解説から、「どうやって直すのか？」という具体的な修復手順（コンソール、Azure CLI、Terraformなど）まで、分かりやすく解説します。

この記事では、Azure SQL DatabaseでTransparent Data Encryption（TDE）が無効になっている場合のリスクと対策を解説します。

ポリシーの説明

Azure SQL Databaseでは、保存時の暗号化を実現するためにTransparent Data Encryption（TDE）の有効化が必須です。TDEは、データベースファイル（.mdf）、トランザクションログファイル（.ldf）、バックアップファイル（.bak）、スナップショット、TempDBを含むすべての保存データをリアルタイムで自動的に暗号化する機能です。なお、Azure SQL Database の TempDB はプラットフォーム側で自動的に暗号化されます。

TDEは、データが8KBのページ単位でリアルタイムに暗号化・復号化される仕組みで、AES-256暗号化アルゴリズム（FIPS 140-2準拠）を使用します。データベース暗号化キー（DEK）はTDEプロテクターによって保護されます。2017年5月以降に作成されたデータベースではデフォルトで有効化されていますが、それ以前のデータベースや明示的に無効化された場合は、重大なセキュリティリスクが生じます。

修復方法

コンソールでの修復手順

Azure コンソールを使用して、SQL DatabaseのTDEを有効化する手順：

Azure Portalにログイン
- Azure Portal にアクセスし、管理者権限を持つアカウントでログインします。
SQL Databaseリソースへ移動
- 左側のメニューから「すべてのサービス」→「データベース」→「SQL データベース」を選択
- TDEを有効化したいデータベースを選択します。
Transparent Data Encryptionの設定
- データベースのメニューから「セキュリティ」セクションを展開
- 「Transparent data encryption」を選択します。
TDEの有効化

「データ暗号化」のトグルを「オン」に切り替えます
暗号化方式を選択：
- サービス管理キー（SMK）: Azureが自動的にキーを管理、組み込みサーバー証明書を使用（開発・テスト環境に推奨）
- カスタマー管理キー（CMK/BYOK）: Azure Key VaultまたはManaged HSMで管理するキーを使用（本番環境・規制対応に推奨）
「保存」をクリックして設定を適用します。

暗号化の進捗状況を確認
- 暗号化プロセスはデータベースのサイズによって時間がかかります
  - 暗号化完了までの時間はデータサイズ、ワークロード、基盤状況に依存し大きく変動する。公式に保証された所要時間はないため、進捗は動的管理ビューで確認する（percent_complete など）。
- 暗号化状態は以下のステータスで確認可能：
  - 0: 暗号化キー未設定
  - 1: 暗号化されていない
  - 2: 暗号化中（進捗率をpercent_completeで確認可能）
  - 3: 暗号化済み
  - 4: キー変更中
  - 5: 復号化中
  - 6: 保護変更中（SMK↔CMK切り替え）
- パフォーマンスへの影響：
  - CPU: 3-5%増加（Intel AES-NIハードウェアアクセラレーション使用時）
  - I/O: 最小限（ページレベルの暗号化のため）
  - メモリ: 影響なし（メモリ上では平文）

カスタマー管理キー（CMK/BYOK）を使用する場合の追加手順：

Azure Key Vaultの準備
- Key Vaultが存在しない場合は新規作成
- 必須設定:
  - ソフト削除: 90日以上（推奨）、最小7日
  - パージ保護: 必ず有効化（無効の場合TDE設定が失敗）
- アクセスポリシー方式に加え、Azure RBAC による権限管理も推奨。いずれの場合も必要な Key 権限（Get, Wrap Key, Unwrap Key）を満たすこと
- ネットワークアクセス制限：信頼されたAzureサービスと特定IPのみ許可
マネージドIDの設定
- システム割り当てマネージドID: 従来方式、単一テナント内でのみ使用可能
- ユーザー割り当てマネージドID（UMI）: 2024年以降推奨
  - Key Vault は同一テナント内の利用が前提。クロステナント運用は未サポートまたは強い制約があるため避ける。CMK/BYOKは同一テナント内の Key Vault または Managed HSM を利用すること
- Key VaultアクセスポリシーにマネージドIDを追加
キーの選択と設定
- TDE設定画面で「カスタマー管理キー」を選択
- Key Vaultとキーを指定:
  - キータイプ: RSAまたはRSA-HSM
  - キーサイズ: 2048ビット（最小要件）、4096ビット（推奨）
- TDEプロテクターの構成:
  - サーバーレベル: すべてのデータベースに適用
  - データベースレベル: 個別データベースごとに異なるキーを設定可能（2024年新機能）
高可用性の考慮事項
- Key Vaultアクセス障害時の影響:
  - Key Vault へのアクセスが失われるとデータベースの可用性に影響する可能性がある。復旧は Key Vault 側の復旧後に自動的に回復する。具体的な時間しきい値は公式に保証されていないため、値の断定は避ける。
- スケール制限:
  - 特定のDB数の上限は TDE CMK 固有の固定値としては示されていない。スループットやレイテンシは Key Vault の要求レート、冗長化、ネットワーク設計に依存するため、可用性・レート制限・冗長構成を考慮して設計する。
- 推奨構成:
  - Key Vaultの地理冗長構成（プライマリ/セカンダリ）
  - 自動フェールオーバーグループとの統合