次の方法で共有


Transparent Data Encryption (TDE)

Transparent Data Encryption (TDE) は、保存データの暗号化と呼ばれるデータベース データ ファイルSQL ServerおよびAzure SQLを暗号化します。 セキュリティで保護されたシステムの設計、機密資産の暗号化、データベース サーバーに対するファイアウォールの構築などの、データベースを保護するいくつかの対策を講じることができます。 ただし、物理メディア (ドライブやバックアップ テープなど) が盗まれるシナリオでは、悪意のある第三者がデータベースを復元するかアタッチするだけでデータを閲覧することができます。 解決策の 1 つは、データベース内の機密データを暗号化し、データの暗号化に使用されるキーを証明書で保護することです。 これにより、キーを持たない人物によるデータの使用を防止できますが、このような保護は事前に計画する必要があります。

TDE は、データとログ ファイルの I/O 暗号化と複合化をリアルタイムで実行します。 暗号化は、復旧中に、可用性のためのデータベース ブート レコードに格納されるデータベース暗号化キー (DEK) を使用します。 DEK は、サーバーの master データベースに保存されている証明書を使用して保護される対称キーか、EKM モジュールによって保護される非対称キーです。 TDE では、"静止した" データ、つまりデータとログ ファイルが保護されます。 この暗号化は、法律、規制、およびさまざまな業界で確立されているガイドラインの多くに準拠できるようになっています。 これによりソフトウェア開発者は、既存のアプリケーションを変更することなく、AES および 3DES 暗号化アルゴリズムを使用してデータを暗号化できます。

重要

TDE では、通信チャネル全体を暗号化することはできません。 通信チャネル全体でデータを暗号化する方法の詳細については、「データベース エンジンへの暗号化接続の有効化 (SQL Server 構成マネージャー)」を参照してください。

関連項目:

TDE について

データベース ファイルの暗号化は、ページ レベルで実行されます。 暗号化されたデータベースのページは、ディスクに書き込まれる前に暗号化され、メモリに読み込まれるときに暗号化解除されます。 TDE では、暗号化されたデータベースのサイズが増えることはありません。

SQL Database に該当する情報

SQL Database V12 V12 (一部のリージョンではプレビュー) で TDE を使用する場合、マスター データベースに格納されているサーバー レベルの証明書は、SQL Databaseによって自動的に作成されます。 SQL Databaseで TDE データベースを移動するには、データベースの暗号化を解除し、データベースを移動してから、コピー先のSQL Databaseで TDE を再度有効にする必要があります。 SQL Databaseでの TDE の詳細な手順については、「Azure SQL データベースを使用した Transparent Data Encryption」を参照してください。

TDE の状態のプレビューは、SQL Databaseのバージョン ファミリ V12 が現在一般提供状態であると発表されている地理的リージョンのサブセットでも適用されます。 TDE for SQL Databaseは、Microsoft が TDE がプレビューから GA に昇格することを発表するまで、運用データベースでの使用を目的としていません。 SQL Database V12 の詳細については、「Azure SQL Database の新機能」を参照してください。

SQL Server に該当する情報

セキュリティで保護されたデータベースは、正しい証明書を使用することで復元できます。 証明書の詳細については、「 SQL Server Certificates and Asymmetric Keys」をご覧ください。

TDE を有効にしたら、証明書とそれに関連付けられた秘密キーを直ちにバックアップする必要があります。 証明書が使用できなくなった場合、またはデータベースを別のサーバーに復元またはアタッチする必要がある場合に、証明書と秘密キーの両方のバックアップが必要です。これらのバックアップがない場合は、データベースを開けません。 暗号化証明書は、データベースで TDE を無効にした場合でも保持する必要があります。 データベースが暗号化されていない場合でも、トランザクション ログの一部はまだ保護されたままである場合があるため、データベースの完全バックアップが実行されるまでは、一部の操作では証明書が必要な場合があります。 有効期限の日付を過ぎた証明書であっても、TDE によりデータを暗号化および暗号化解除できる場合があります。

暗号化階層

TDE 暗号化のアーキテクチャを次の図に示します。 SQL Databaseで TDE を使用する場合、データベース レベルの項目 (データベース暗号化キーと ALTER DATABASE 部分はユーザーが構成できます)。

トピックで説明されている階層を表示します。

Transparent Data Encryption の使用

TDE を使用するには、次の手順を実行します。

適用対象: SQL Server
  • マスター キーを作成します。

  • マスター キーで保護された証明書を作成または取得します。

  • データベース暗号化キーを作成し、証明書で保護します。

  • 暗号化を使用するようにデータベースを設定します。

次の例では、 AdventureWorks2012 という名前のサーバーにインストールされた証明書を使用して、 MyServerCertデータベースを暗号化および暗号化解除しています。

USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';
go
CREATE CERTIFICATE MyServerCert WITH SUBJECT = 'My DEK Certificate';
go
USE AdventureWorks2012;
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_128
ENCRYPTION BY SERVER CERTIFICATE MyServerCert;
GO
ALTER DATABASE AdventureWorks2012
SET ENCRYPTION ON;
GO

暗号化および暗号化解除の操作は、SQL Server によってバックグラウンド スレッドでスケジュールされます。 これらの操作の状態は、この後の一覧に示すカタログ ビューおよび動的管理ビューを使用して確認できます。

注意事項

TDE が有効になっているデータベースのバックアップ ファイルも、データベース暗号化キーを使用して暗号化されます。 このため、このバックアップを復元するときには、データベース暗号化キーを保護している証明書が必要です。 つまり、データの損失を防ぐには、データベースをバックアップするだけでなく、サーバー証明書のバックアップも確実に保守する必要があります。 証明書が使用できなくなると、データの損失が発生します。 詳細については、「 SQL Server Certificates and Asymmetric Keys」をご覧ください。

コマンドと関数

TDE の証明書を次に示すステートメントで処理できるようにするには、この証明書をデータベース マスター キーで暗号化する必要があります。 パスワードだけで暗号化された証明書は、ステートメントで暗号化機能として受け付けられません。

重要

TDE で使用された証明書をパスワードで保護するように変更すると、再起動後にデータベースにアクセスできなくなります。

次の表に、TDE のコマンドと関数の説明とリンクを示します。

コマンドまたは関数 目的
CREATE DATABASE ENCRYPTION KEY (Transact-SQL) データベースの暗号化に使用されるキーを作成します。
ALTER DATABASE ENCRYPTION KEY (Transact-SQL) データベースの暗号化に使用されるキーを変更します。
DROP DATABASE ENCRYPTION KEY (Transact-SQL) データベースの暗号化に使用されたキーを削除します。
ALTER DATABASE SET のオプション (Transact-SQL) TDE を有効にするために使用される ALTER DATABASE オプションについて説明します。

カタログ ビューと動的管理ビュー

次の表に、TDE のカタログ ビューと動的管理ビューを示します。

カタログ ビューまたは動的管理ビュー 目的
sys.databases (Transact-SQL) データベース情報を表示するカタログ ビュー
sys.certificates (Transact-SQL) データベース内の証明書を表示するカタログ ビュー
sys.dm_database_encryption_keys (Transact-SQL) データベースで使用されている暗号化キー、およびデータベースの暗号化の状態に関する情報を表示する動的管理ビュー

アクセス許可

TDE の各機能とコマンドには、上の表で説明されているように、個別の権限要件があります。

TDE に関係するメタデータを表示するには、証明書に対する VIEW DEFINITION 権限が必要です。

考慮事項

データベース暗号化操作の再暗号化スキャンが実行されている間は、データベースに対するメンテナンス操作が無効になります。 メンテナンス操作を実行するには、データベースに対してシングル ユーザー モード設定を使用します。 詳細については、「 データベースをシングル ユーザー モードに設定する」を参照してください。

データベースの暗号化の状態を確認するには、sys.dm_database_encryption_keys 動的管理ビューを使用します。 詳細については、このトピックの「カタログ ビューと動的管理ビュー」を参照してください。

TDE では、データベース内のすべてのファイルとファイル グループが暗号化されます。 データベースに READ ONLY とマークされているファイル グループがあると、データベースの暗号化操作は失敗します。

データベースがデータベース ミラーリングまたはログ配布で使用されている場合は、両方のデータベースが暗号化されます。 トランザクション ログは、2 つのデータベースの間で送信されるときに暗号化されます。

重要

データベースを暗号化の対象として設定すると、新しいフルテキスト インデックスが暗号化されるようになります。 以前に作成したフルテキスト インデックスはアップグレード中にインポートされ、データがSQL Serverに読み込まれた後、TDE に格納されます。 列でフルテキスト インデックスを有効にすると、フルテキスト インデックス スキャンの実行時に、その列のデータがプレーンテキストでディスクに書き込まれる可能性があります。 暗号化された機密データにはフルテキスト インデックスを作成しないことをお勧めします。

暗号化されたデータは、暗号化されていない同等のデータより、圧縮比率が大幅に下がります。 TDE を使用してデータベースを暗号化した場合、バックアップの圧縮によってバックアップ ストレージが大幅に圧縮されることはありません。 したがって、TDE とバックアップの圧縮を併用することはお勧めしません。

制限

最初のデータベース暗号化、キー変更、またはデータベースの暗号化解除の実行中は、次の操作を実行できません。

  • データベース内のファイル グループからのファイルの削除

  • データベースの削除

  • データベースのオフライン化

  • データベースのデタッチ

  • データベースまたはファイル グループの READ ONLY 状態への移行

CREATE DATABASE ENCRYPTION KEY、ALTER DATABASE ENCRYPTION KEY、DROP DATABASE ENCRYPTION KEY、または ALTER DATABASE...SET ENCRYPTION の各ステートメントの実行中は、次の操作を実行できません。

  • データベース内のファイル グループからのファイルの削除

  • データベースの削除。

  • データベースのオフライン化

  • データベースのデタッチ

  • データベースまたはファイル グループの READ ONLY 状態への移行

  • ALTER DATABASE コマンドの使用

  • データベースまたはデータベース ファイルのバックアップの開始

  • データベースまたはデータベース ファイルの復元の開始

  • スナップショットの作成

次の操作または状況が発生すると、CREATE DATABASE ENCRYPTION KEY、ALTER DATABASE ENCRYPTION KEY、DROP DATABASE ENCRYPTION KEY、または ALTER DATABASE...SET ENCRYPTION の各ステートメントを実行できなくなります。

  • データベースが読み取り専用であるか、読み取り専用のファイル グループを含んでいる。

  • ALTER DATABASE コマンドが実行されている。

  • データ バックアップが実行されている。

  • データベースがオフラインまたは復元中である。

  • スナップショットが実行されている。

  • データベース メンテナンス タスク。

データベース ファイルを作成する際には、TDE が有効になっているとファイルの瞬時初期化を使用できません。

非対称キーでデータベース暗号化キーを暗号化するには、非対称キーが拡張キー管理プロバイダーに存在している必要があります。

Transparent Data Encryption とトランザクション ログ

データベースで TDE の使用を有効にすると、仮想トランザクション ログの残りの部分が "ゼロ設定" され、強制的に次の仮想トランザクション ログに移行します。 これにより、データベースが暗号化対象として設定された後にトランザクション ログにクリア テキストが残らないことが保証されます。 ログ ファイルの暗号化の状態を確認するには、次の例のように encryption_state ビュー内の sys.dm_database_encryption_keys 列を表示します。

USE AdventureWorks2012;
GO
/* The value 3 represents an encrypted state 
   on the database and transaction logs. */
SELECT *
FROM sys.dm_database_encryption_keys
WHERE encryption_state = 3;
GO

SQL Server ログ ファイルのアーキテクチャの詳細については、「トランザクション ログ (SQL Server)」を参照してください。

データベース暗号化キーを変更する前にトランザクション ログに書き込まれたデータは、以前のデータベース暗号化キーで暗号化されます。

データベース暗号化キーを 2 回変更した後は、データベース暗号化キーを再度変更する前に、ログ バックアップを実行する必要があります。

Transparent Data Encryption と tempdb システム データベース

SQL Serverのインスタンス上の他のデータベースが TDE を使用して暗号化されている場合、tempdb システム データベースは暗号化されます。 これは、SQL Serverの同じインスタンスで暗号化されていないデータベースのパフォーマンスに影響する可能性があります。 tempdb システム データベースの詳細については、「tempdb データベース」を参照してください。

Transparent Data Encryption とレプリケーション

レプリケーションでは、TDE が有効になっているデータベースのデータが暗号化された形式で自動的にレプリケートされることはありません。 ディストリビューション データベースとサブスクライバー データベースを保護する場合は、TDE を個別に有効にする必要があります。 スナップショット レプリケーションでは、トランザクション レプリケーションとマージ レプリケーションへの最初のデータ ディストリビューションと同様に、暗号化されていない中間ファイル (bcp ファイルなど) にデータを格納できます。 トランザクション レプリケーションまたはマージ レプリケーション時に、暗号化を有効にして通信チャネルを保護することができます。 詳細については、「データベース エンジンへの暗号化接続の有効化 (SQL Server 構成マネージャー)」を参照してください。

Transparent Data Encryption と FILESTREAM データ

FILESTREAM データは TDE が有効になっている場合でも暗号化されません。

Transparent Data Encryption とバッファー プール拡張機能

バッファー プール拡張機能 (BPE) に関連するファイルは、データベースが TDE を使用して暗号化される場合でも暗号化されません。 BPE 関連のファイルについては、Bitlocker や EFS などのファイル システム レベルの暗号化ツールを使用する必要があります。

Transparent Data Encryption とインメモリ OLTP

TDE は、インメモリ OLTP オブジェクトを含むデータベースで有効にすることができます。 TDE が有効な場合、インメモリ OLTP ログ レコードが暗号化されます。 MEMORY_OPTIMIZED_DATA ファイル グループのデータは、TDE が有効な場合は暗号化されません。

参照

Azure SQL データベースでの EKM Transparent Data Encryption を使用した TDE 保護されたデータベースの別のSQL Server有効な TDE への移動SQL Server暗号化SQL Serverデータベース暗号化キー (データベース エンジン)Security Center for SQL Server Databaseエンジンとデータベース FILESTREAM のAzure SQL(SQL Server)