Azure SQL の Transparent Data Encryption（TDE）は、データベースのデータファイル、ログファイル、バックアップを保存時に暗号化する機能です。アプリケーションのSQLや接続方式を変えずに使える一方で、通信経路の暗号化や列単位の暗号化を代替するものではありません。
2026年6月25日に更新された Microsoft Learn の「Transparent Data Encryption (TDE) – SQL Server」で管理者がまず確認すべき点は、TDEの適用範囲、証明書・キーのバックアップ、復元や移行時の扱い、Azure SQLでの既定設定の違いです。公式情報上、今回の更新に伴う一律の移行期限や強制的な設定変更は示されていません。ただし、古い Azure SQL Database、復元元が暗号化されていないデータベース、Customer-managed key（CMK）を使う環境では、暗号化状態とキー管理を棚卸ししておく必要があります。(Microsoft Learn)
Azure SQL の TDE とは何か
Transparent Data Encryption（TDE）は、SQL Server、Azure SQL Database、Azure SQL Managed Instance、Azure Synapse Analytics で利用できる保存データ暗号化の仕組みです。データベースのページがディスクへ書き込まれる前に暗号化され、メモリへ読み込まれるときに復号されます。暗号化はデータベースエンジン側で行われるため、通常はアプリケーション側のコード変更を必要としません。(Microsoft Learn)
TDEで暗号化される主な対象は、次のとおりです。
| 対象 | TDEで保護されるか | 管理者が確認すべき点 |
|---|---|---|
| データファイル | 対象 | 暗号化状態をDMVで確認する |
| トランザクションログ | 対象 | TDE有効化後のログ暗号化状態を確認する |
| バックアップ | 対象 | 復元に必要な証明書・キーを保持する |
| 通信経路 | 対象外 | TLSなど別の対策が必要 |
master、model、msdbなどのシステムDB | 対象外 | 機密情報を保存しない設計にする |
tempdb | 条件付きで暗号化 | TDE有効DBがある環境では影響を考慮する |
| FILESTREAMデータ | 対象外 | 必要に応じて別の暗号化を検討する |
特に誤解しやすいのは、TDEが「データベース全体のセキュリティ対策」ではなく、保存されているファイルを盗まれた場合のリスクを下げるための暗号化機能である点です。SQLインジェクション、権限過多、誤った共有、通信傍受、アプリケーションから見える平文データの保護には、別の対策が必要です。Microsoftの公式情報でも、TDEは通信チャネルの暗号化を提供しないと説明されています。(Microsoft Learn)
2026年6月25日更新情報で確認すべきポイント
今回参照対象となる Microsoft Learn の TDE ページは、2026年6月25日に更新されています。内容としては、SQL Serverを中心にTDEの仕組み、制限事項、証明書管理、バックアップ、可用性構成、トランザクションログ、tempdb、レプリケーションなどの注意点が整理されています。(Microsoft Learn)
Azure SQL 管理者の視点では、次の4点を優先して確認すると実務に落とし込みやすくなります。
| 確認ポイント | 重要な理由 | 取るべき行動 |
|---|---|---|
| TDEの適用範囲 | 通信やアプリ層の暗号化とは役割が違う | 保存データ暗号化、通信暗号化、列暗号化を分けて設計する |
| 暗号化状態 | 古いDBや復元元によって状態が異なる可能性がある | sys.dm_database_encryption_keys で確認する |
| 証明書・キー管理 | 復元時に証明書やキーがないとDBを開けない場合がある | バックアップ、保管先、復旧手順を確認する |
| 移行・復元時の扱い | コピー、復元、geo-replicationで暗号化状態が変わる場合がある | 移行前後で暗号化状態をチェックする |
重要なのは、「TDEが有効かどうか」だけを確認して終わらせないことです。実運用では、誰がキーを管理するのか、復元時に必要なキーへアクセスできるのか、監査で証明できるのかまで確認して初めて、TDEを安全に運用できていると言えます。
Azure SQL での影響範囲
Azure SQL Databaseでは、新しく作成されるSQLデータベースは既定でサービス管理TDEにより暗号化されます。一方で、2017年5月より前に作成された既存のAzure SQL Databaseや、2019年2月より前に作成された既存のAzure SQL Managed Instanceデータベースは、既定で暗号化されていない場合があると公式情報に記載されています。(Microsoft Learn)
そのため、特に長く運用しているAzure環境では、「Azure SQLだからTDEは有効なはず」と決めつけないことが重要です。次のようなデータベースは、優先的に棚卸ししてください。
| 優先度 | 確認対象 | 理由 |
|---|---|---|
| 高 | 2017年以前から運用している Azure SQL Database | 既定で暗号化されていない可能性がある |
| 高 | 2019年以前から運用している Azure SQL Managed Instance | 既定の暗号化状態を確認する必要がある |
| 高 | オンプレミスSQL Serverから移行したDB | 証明書、DEK、移行手順の確認が必要 |
| 中 | 復元、コピー、geo-replicationで作成したDB | 元DBの暗号化状態を継承する場合がある |
| 中 | BACPACでエクスポート・インポートしたDB | BACPAC自体はTDEで暗号化されない |
| 中 | Customer-managed keyを利用するDB | Key Vault権限やキーの有効性が可用性に直結する |
Azure SQL DatabaseとAzure Synapseでは、TDE保護機能はサーバーレベルで設定され、関連するデータベースへ継承されます。Azure SQL Managed Instanceではインスタンスレベルで設定され、暗号化されたデータベースへ継承されます。(Microsoft Learn)
設定変更は必要か
今回の公式情報から読み取れる範囲では、すべてのAzure SQL利用者に対して直ちに必要な強制的な設定変更は示されていません。したがって、管理者が行うべきことは「急いで設定を変える」ことではなく、現在の暗号化状態とキー管理の健全性を確認することです。
まず確認すべき観点は、次の3つです。
| 観点 | 確認内容 | 判断基準 |
|---|---|---|
| 暗号化状態 | 対象DBでTDEが有効か | 本番DB、個人情報、機密情報を含むDBは原則有効 |
| キー管理方式 | サービス管理キーか、Customer-managed keyか | 一般用途はサービス管理、厳格な統制が必要ならCMK |
| 復旧可能性 | 証明書・キー・Key Vault権限が復旧時に使えるか | 復元手順を実際に検証できている状態が望ましい |
Azure SQLのサービス管理TDEでは、Microsoftが管理する組み込み証明書によりDEKが保護されます。Azure SQL DatabaseとAzure SQL Managed Instanceでは、Microsoftがこれらの証明書を内部ポリシーに従って管理・ローテーションします。(Microsoft Learn)
一方、Customer-managed keyを使う場合、TDE ProtectorはAzure Key VaultまたはAzure Key Vault Managed HSMに保存される顧客管理の非対称キーになります。キーへのアクセス権が取り消されると、データベースにアクセスできなくなるため、権限設計と監視が非常に重要です。(Microsoft Learn)
移行期限はあるのか
2026年6月25日更新の公式TDEページ、および関連するAzure SQLのTDE概要ページを確認する限り、今回のTDE情報更新に伴う一律の移行期限、廃止期限、強制移行日は示されていません。(Microsoft Learn)
ただし、移行期限がないからといって、何もしなくてよいわけではありません。TDEは移行・復元・バックアップと密接に関係するため、次のタイミングでは必ず確認が必要です。
| タイミング | 確認すべきこと |
|---|---|
| オンプレミスSQL ServerからAzure SQLへ移行する前 | TDE証明書、DEK、移行先での復元可否 |
| Azure SQL Managed Instanceへバックアップ復元する前 | 必要なTDE証明書をインポートできるか |
| Geo-replicationを構成する前 | プライマリとセカンダリのTDE保護方式 |
| BACPACでエクスポートする前 | エクスポートファイル自体がTDEで暗号化されない点 |
| Customer-managed keyへ切り替える前 | Key Vault権限、キーのバックアップ、監査ログ |
| DR訓練の前 | 障害時にキーへアクセスできるか |
特にBACPACは見落とされがちです。TDEで保護されたデータベースをBACPACへエクスポートしても、エクスポートされた内容自体はTDEで暗号化されません。持ち出し、保管、転送を行う場合は、別途ストレージ暗号化やアクセス制御を設計する必要があります。(Microsoft Learn)
TDEの暗号化状態を確認する方法
Azure SQL DatabaseやSQL ServerでTDEの状態を確認するには、sys.dm_database_encryption_keys を使用します。Microsoftの公式情報でも、暗号化状態の確認にこの動的管理ビューを使うことが示されています。(Microsoft Learn)
代表的な確認クエリは次のとおりです。
SELECT
DB_NAME(database_id) AS database_name,
encryption_state,
encryption_state_desc,
encryptor_type,
key_algorithm,
key_length,
percent_complete
FROM sys.dm_database_encryption_keys;encryption_state_desc で状態を確認し、暗号化中、暗号化済み、復号中などの状態を把握します。運用監視では、単に「有効か無効か」だけでなく、percent_complete を見て暗号化処理が途中で止まっていないかも確認してください。
SQL Serverで証明書のバックアップ状況を確認する場合は、公式ドキュメントで紹介されている考え方に沿って、TDEで使われている証明書と pvt_key_last_backup_date を確認します。証明書がバックアップされていないと、復元や別サーバーへのアタッチ時にデータベースを開けなくなる可能性があります。(Microsoft Learn)
SELECT
c.pvt_key_last_backup_date,
DB_NAME(dek.database_id) AS encrypted_database,
c.name AS certificate_name
FROM sys.certificates AS c
INNER JOIN sys.dm_database_encryption_keys AS dek
ON c.thumbprint = dek.encryptor_thumbprint;pvt_key_last_backup_date が NULL の場合は、証明書のバックアップが行われていない可能性があります。本番環境では、バックアップファイル、秘密キー、パスワード、保管場所、復旧手順をセットで管理してください。
TDE有効化・変更時に注意すべき制限
TDEはアプリケーション変更が不要な一方で、データベース内部では大きな暗号化処理が行われます。SQL Serverでは、初回暗号化、キー変更、復号処理中に一部の操作が制限されます。たとえば、ファイル削除、データベースのオフライン化、デタッチ、READ ONLYへの変更、バックアップや復元の開始などが制限される場面があります。(Microsoft Learn)
運用で失敗しやすいのは、次のようなケースです。
| 失敗しやすいケース | 起きる問題 | 回避策 |
|---|---|---|
| メンテナンス時間中にTDEを有効化するだけで終わらせる | 暗号化スキャンが長引き、後続作業に影響する | 事前にDBサイズと負荷を確認する |
| 証明書バックアップを後回しにする | 復元時にDBを開けない | 有効化直後に証明書と秘密キーをバックアップする |
| 読み取り専用ファイルグループを見落とす | 暗号化処理が失敗する | TDE有効化前にファイルグループ状態を確認する |
| tempdbの影響を考慮しない | 同一インスタンス上の未暗号化DBにも性能影響が出る可能性がある | 負荷試験と監視を行う |
| レプリケーション先を未暗号化のままにする | 配布DBやサブスクライバーDBが保護されない | 必要なDBごとにTDEを有効化する |
| FILESTREAMをTDEで守れると思い込む | FILESTREAMデータが暗号化されない | 別の暗号化手段を検討する |
SQL Server 2019以降では、TDE暗号化スキャンを一時停止・再開する構文が導入されています。ただし、このSuspend/Resume TDE scan機能は、Azure SQL Database、Azure SQL Managed Instance、Azure Synapse Analyticsでは現在利用できないと公式情報に記載されています。Azure SQLでは、スキャン制御に過度に依存せず、作業時間帯と負荷監視を前提に計画する必要があります。(Microsoft Learn)
Azure SQLでサービス管理キーとCustomer-managed keyをどう選ぶか
Azure SQLのTDEでは、大きく分けてサービス管理TDEとCustomer-managed TDEがあります。どちらを選ぶべきかは、セキュリティ要件、監査要件、運用体制によって変わります。
| 方式 | 向いている環境 | メリット | 注意点 |
|---|---|---|---|
| サービス管理TDE | 一般的な業務システム、標準的なクラウド運用 | 設定・運用が簡単、Microsoftが証明書を管理 | キー管理を細かく制御したい要件には合わない場合がある |
| Customer-managed key | 金融、医療、公共、厳格な内部統制がある環境 | キー管理、ローテーション、監査を顧客側で制御しやすい | Key Vault権限ミスがDB停止につながる可能性がある |
判断に迷う場合は、まずサービス管理TDEを標準とし、次の条件に当てはまる場合にCustomer-managed keyを検討すると現実的です。
- 暗号化キーの管理主体を明確に分離する必要がある
- Azure Key VaultまたはManaged HSMで監査ログを一元管理したい
- キーローテーション手順を自社ポリシーに合わせたい
- 規制対応や顧客契約で顧客管理キーが求められている
- データ管理者とキー管理者を分離する必要がある
ただし、Customer-managed keyは「より安全」という単純な話ではありません。Key Vaultの削除、アクセス権の取り消し、ファイアウォール設定、マネージドIDの変更、キーの無効化などが原因で、データベースにアクセスできなくなるリスクがあります。導入前に、通常時の運用手順だけでなく、キーにアクセスできない場合の復旧手順まで決めておくことが重要です。
バックアップと復元で管理者が確認すべきこと
TDEで保護されたデータベースのバックアップは、DEKによって暗号化されます。そのため、復元時にはDEKを保護している証明書やキーが利用可能でなければなりません。証明書が失われると、バックアップがあってもデータベースを復元できない可能性があります。(Microsoft Learn)
特にSQL ServerやAzure SQL Managed InstanceでTDE付きデータベースを移行・復元する場合は、次のチェックリストを使うと抜け漏れを防げます。
| チェック項目 | 確認内容 |
|---|---|
| 証明書のバックアップ | TDE証明書と秘密キーをバックアップしているか |
| パスワード管理 | 証明書バックアップ時のパスワードを安全に保管しているか |
| 復元先の準備 | 復元先に必要な証明書をインポートできるか |
| 権限 | 復元作業者が必要な権限を持っているか |
| DR手順 | 障害時にキーへアクセスできるか |
| 復元テスト | 本番相当の手順で復元検証を行っているか |
| 保管ポリシー | 証明書、秘密キー、バックアップを同じ場所に置いていないか |
「バックアップは成功しているが、復元できない」という状態は、TDE運用で最も避けたい失敗です。バックアップジョブの成功だけでなく、復元可能性を定期的に確認してください。
監査・コンプライアンスでの見落としポイント
TDEは多くのセキュリティ基準や社内統制で有効な対策になりますが、TDEを有効にしただけでコンプライアンス要件をすべて満たせるわけではありません。TDEは主に保存データの暗号化であり、アクセス権限、監査ログ、通信暗号化、データ分類、バックアップ保護、運用者権限の分離と組み合わせて初めて実効性が高まります。
Azure SQLの公式情報では、テーブル名、オブジェクト名、インデックス名など一部の顧客コンテンツに該当する情報が、Microsoftのサポートやトラブルシューティング用ログに送信される可能性があると説明されています。規制業種やグローバル展開している企業では、データ本体だけでなく、メタデータの取り扱いも確認しておくとよいでしょう。(Microsoft Learn)
監査で説明しやすい状態にするには、次の情報を台帳化しておくことをおすすめします。
| 台帳項目 | 記録する内容 |
|---|---|
| 対象データベース | サーバー名、DB名、環境、本番・検証の区分 |
| TDE状態 | 有効・無効、確認日、確認方法 |
| キー管理方式 | サービス管理TDE、Customer-managed key |
| Key Vault情報 | 使用している場合のVault名、キー名、権限 |
| ローテーション方針 | 自動・手動、頻度、担当者 |
| バックアップ方針 | DBバックアップ、証明書、秘密キーの保管先 |
| 復旧テスト | 最終実施日、復旧結果、課題 |
| 例外管理 | TDE無効DBの理由、承認者、見直し期限 |
この台帳があると、監査対応だけでなく、移行、障害対応、担当者変更の際にも役立ちます。
管理者が今すぐ確認すべき実務チェックリスト
Azure SQL環境を管理している場合は、次の順番で確認すると効率的です。
| 順番 | 作業 | 目的 |
| -: | ———————————————— | —————- |
| 1 | 全Azure SQL Database、Managed Instance、Synapseの棚卸し | 対象範囲を明確にする |
| 2 | sys.dm_database_encryption_keys でTDE状態を確認 | 暗号化漏れを見つける |
| 3 | 古いDB、復元DB、コピーDBを重点確認 | 既定設定に頼れないDBを洗い出す |
| 4 | サービス管理キーかCMKかを分類 | 運用責任範囲を明確にする |
| 5 | CMK利用環境のKey Vault権限を確認 | キーアクセス不能による停止を防ぐ |
| 6 | バックアップと復元手順を確認 | 「復元できない」を防ぐ |
| 7 | BACPAC、エクスポート、外部保管の扱いを確認 | TDE対象外のデータ流出を防ぐ |
| 8 | 監査ログと台帳を整備 | 監査・障害対応・引き継ぎに備える |
TDEの確認は、セキュリティ担当だけで完結しません。DBA、クラウド管理者、アプリケーション担当、監査担当が同じ前提を共有しておく必要があります。特にCMKを利用する場合は、Key Vault管理者とDB管理者の役割分担を明文化しておくと、障害時の対応が速くなります。
TDEを正しく運用するための考え方
Azure SQL の TDE は、保存データを保護するうえで基本となる重要な機能です。新規のAzure SQL Databaseでは既定で有効化されるため、普段は意識しにくいかもしれません。しかし、長期運用している古いデータベース、オンプレミスから移行したデータベース、Managed Instanceへの復元、Customer-managed keyの利用、BACPACによるエクスポートでは、管理者の判断と確認が必要になります。
今回の公式情報更新を受けて、まず行うべきことは大きな設定変更ではなく、暗号化状態、キー管理、復元可能性、TDE対象外のデータ経路を確認することです。
実務では、次の3つを最低限の行動として進めてください。
- すべての対象DBでTDE状態を確認する
- TDE証明書、キー、Key Vault権限、復元手順を点検する
- BACPAC、FILESTREAM、通信経路、監査ログなどTDEで守れない部分を別対策で補完する
TDEは「有効にして終わり」の機能ではありません。暗号化されたデータを、必要なときに安全に復元できる状態まで含めて設計することが、Azure SQL管理者に求められる実務上のポイントです。
コメント