次の方法で共有


Transparent Data Encryption

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

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

重要

TDE では、クライアントと PDW の間を移動するデータの暗号化は提供されません。 クライアントと SQL Server PDW の間でデータを暗号化する方法の詳細については、「証明書のプロビジョニング」を参照してください。

TDE では、移動中または使用中のデータは暗号化されません。 SQL Server PDW 内の PDW コンポーネント間の内部トラフィックは暗号化されません。 メモリ バッファーに一時的に格納されているデータは暗号化されません。 このリスクを軽減するには、SQL Server PDW への物理的なアクセスと接続を制御します。

セキュリティで保護されたデータベースは、正しい証明書を使用することで復元できます。

Note

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

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

TDE 暗号化のキーの階層を次の図に示します。

Displays the hierarchy

Transparent Data Encryption の使用

TDE を使用するには、次の手順を実行します。 最初の 3 つの手順は、TDE をサポートするために SQL Server PDW を準備するときに 1 回だけ実行されます。

  1. マスター データベースにデータベース マスター キーを作成します。

  2. sp_pdw_database_encryptionを使用して、SQL Server PDW で TDE を有効にします。 この操作は、将来の一時データの保護を確保するために一時データベースを変更し、一時テーブルを持つアクティブなセッションがある場合に失敗します。 sp_pdw_database_encryption は、PDW システム ログでユーザー データ マスクを有効にします。 (PDW システム ログでのユーザー データ マスクの詳細については、sp_pdw_log_user_data_masking を参照してください)。

  3. sp_pdw_add_network_credentials を使用して、証明書のバックアップが格納される共有に対して認証と書き込みを行うことができる資格情報を作成します。 目的のストレージ サーバーの資格情報が既に存在する場合は、既存の資格情報を使用できます。

  4. マスター データベースで、マスター キーによって保護された証明書を作成します。

  5. 証明書をストレージ共有にバックアップします。

  6. ユーザー データベースで、データベース暗号化キーを作成し、マスター データベースに格納されている証明書で保護します。

  7. ALTER DATABASEステートメントを 使用して、TDE を使用してデータベースを暗号化します。

次の例では、SQL Server PDW で作成された MyServerCert という名前のサーバーにインストールされた証明書を使用して、AdventureWorksPDW2012 データベースを暗号化しています。

最初: SQL Server PDW で TDE を有効にします。 このアクションは 1 回だけ必要です。

USE master;  
GO  
  
-- Create a database master key in the master database  
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';  
GO  
  
-- Enable encryption for PDW  
EXEC sp_pdw_database_encryption 1;  
GO  
  
-- Add a credential that can write to the share  
-- A credential created for a backup can be used if you wish  
EXEC sp_pdw_add_network_credentials 'SECURE_SERVER', '<domain>\<Windows_user>', '<password>';  

次: スター データベースでバックアップ証明書を作成し、バックアップを取ります。 このアクションは 1 回だけ必要です。 データベースごとに個別の証明書を用意することも (推奨)、1 つの証明書で複数のデータベースを保護することもできます。

-- Create certificate in master  
CREATE CERTIFICATE MyServerCert WITH SUBJECT = 'My DEK Certificate';  
GO  
  
-- Back up the certificate with private key  
BACKUP CERTIFICATE MyServerCert   
    TO FILE = '\\SECURE_SERVER\cert\MyServerCert.cer'  
    WITH PRIVATE KEY   
    (   
        FILE = '\\SECURE_SERVER\cert\MyServerCert.key',  
        ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>'   
    )   
GO  

最後: DEK を作成し、ALTER DATABASE を使用してユーザー データベースを暗号化します。 このアクションは、TDE によって保護されているデータベースごとに繰り返されます。

USE AdventureWorksPDW2012;  
GO  
  
CREATE DATABASE ENCRYPTION KEY  
WITH ALGORITHM = AES_128  
ENCRYPTION BY SERVER CERTIFICATE MyServerCert;  
GO  
  
ALTER DATABASE AdventureWorksPDW2012 SET ENCRYPTION ON;  
GO  

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

注意事項

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

コマンドと関数

TDE の証明書を次に示すステートメントで処理できるようにするには、この証明書をデータベース マスター キーで暗号化する必要があります。

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

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

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

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

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

アクセス許可

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

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

考慮事項

データベース暗号化操作の再暗号化スキャンが実行されている間は、データベースに対するメンテナンス操作が無効になります。

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

制限

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

  • データベースの削除。

  • ALTER DATABASE コマンドの使用。

  • データベース バックアップの開始。

  • データベースの復元の開始。

次の操作または条件により、CREATE DATABASE ENCRYPTION KEYALTER DATABASE ENCRYPTION KEYDROP DATABASE ENCRYPTION KEY、または ALTER DATABASE...SET ENCRYPTION ステートメントが使用できなくなります。

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

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

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

TDE によって保護されていない領域

TDE は外部テーブルを保護しません。

TDE は診断セッションを保護しません。 ユーザーは、診断セッションの使用中に機密性の高いパラメーターを持つクエリを実行しないように注意する必要があります。 機密情報を明らかにする診断セッションは、不要になればすぐに削除する必要があります。

TDE によって保護されたデータは、SQL Server PDW メモリに配置されると復号化されます。 メモリ ダンプは、アプライアンスで特定の問題が発生したときに作成されます。 ダンプ ファイルは、問題の出現時のメモリの内容を表し、暗号化されていない形式で機密データを含めることができます。 メモリ ダンプの内容は、他のユーザーと共有する前に確認する必要があります。

マスター データベースは TDE で保護されていません。 マスター データベースにはユーザー データは含まれませんが、ログイン名などの情報が含まれています。

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

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

WITH dek_encryption_state AS   
(  
    SELECT ISNULL(db_map.database_id, dek.database_id) AS database_id, encryption_state  
    FROM sys.dm_pdw_nodes_database_encryption_keys AS dek  
        INNER JOIN sys.pdw_nodes_pdw_physical_databases AS node_db_map  
           ON dek.database_id = node_db_map.database_id AND dek.pdw_node_id = node_db_map.pdw_node_id  
        LEFT JOIN sys.pdw_database_mappings AS db_map  
            ON node_db_map .physical_name = db_map.physical_name  
        INNER JOIN sys.dm_pdw_nodes AS nodes  
            ON nodes.pdw_node_id = dek.pdw_node_id  
    WHERE dek.encryptor_thumbprint <> 0x  
)  
SELECT TOP 1 encryption_state  
       FROM dek_encryption_state  
       WHERE dek_encryption_state.database_id = DB_ID('AdventureWorksPDW2012 ')  
       ORDER BY (CASE encryption_state WHEN 3 THEN -1 ELSE encryption_state END) DESC;  

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

PDW アクティビティ ログ

SQL Server PDW では、トラブルシューティングを目的とした一連のログが保持されます。 (これはトランザクション ログ、SQL Server エラー ログ、または Windows イベント ログではないことに注意してください)。これらの PDW アクティビティ ログには、クリア テキストの完全なステートメントを含めることができます。その一部にはユーザー データを含めることができます。 一般的な例は、INSERT ステートメントとUPDATE ステートメントです。 ユーザー データのマスクは、sp_pdw_log_user_data_masking を使用して明示的にオンまたはオフにすることができます。 SQL Server PDW で暗号化を有効にすると、ユーザー データを保護するために、PDW アクティビティ ログのユーザー データのマスクが自動的にオンになります。 sp_pdw_log_user_data_masking を使用して TDE を使用しない場合はステートメントをマスクすることもできますが、これは、Microsoft サポート チームが問題を分析する能力を大幅に低下させるので推奨されません。

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

tempdb システム データベースは、sp_pdw_database_encryption を使用して暗号化が有効になっている場合に暗号化されます。 これは、データベースで TDE を使用する前に必要です。 この場合、同じSQL Server PDW 上にある暗号化されないデータベースのパフォーマンスに影響が生じることがあります。

キーの管理

データベース暗号化キー (DEK) は、マスター データベースに格納されている証明書で保護されます。 これらの証明書は、マスター データベースのデータベース マスター キー (DMK) で保護されます。 TDE に使用するには、サービス マスター キー (SMK) で、DMK を保護する必要があります。

システムは、人の介入 (パスワードの指定など) を必要とせずにキーにアクセスできます。 証明書が使用できない場合、適切な証明書が使用可能になるまで DEK を復号化できないことを説明するエラーが出力されます。

あるアプライアンスから別のアプライアンスにデータベースを移動する場合は、その DEK を保護するために使用される証明書を先に移行先サーバーに復元する必要があります。 その後、データベースは通常どおりに復元できます。 詳細については、「 別の SQL Server への TDE で保護された標準SQL Server ドキュメントの移動」を参照してください。

DEK の暗号化に使用される証明書は、それらを使用するデータベース バックアップがある限り保持する必要があります。 秘密キーがないと、証明書をデータベースの復元に使用できないため、証明書のバックアップには証明書の秘密キーを含める必要があります。 これらの証明書秘密キーのバックアップは、証明書の復元のために指定する必要があるパスワードで保護された別のファイルに格納されます。

スター データベースの復元

マスター データベースは、ディザスター リカバリーの一環として DWConfig を使用して復元できます。

  • 制御ノードが変更されていない場合、つまりマスター データベースのバックアップが作成されたのと同じ変更されていないアプライアンスでマスター データベースが復元された場合、DMK とすべての証明書は追加の操作なしで読み取り可能になります。

  • マスター データベースが別のアプライアンスに復元されている場合、またはマスター データベースのバックアップ以降に制御ノードが変更されている場合は、DMK を再生成するために追加の手順が必要になります。

    1. DMK を開く

      OPEN MASTER KEY DECRYPTION BY PASSWORD = '<password>';  
      
    2. SMK による暗号化を追加します。

      ALTER MASTER KEY   
          ADD ENCRYPTION BY SERVICE MASTER KEY;  
      
    3. アプライアンスを再起動します。

仮想マシンのアップグレードと交換をします

VM のアップグレードまたは置換が実行されたアプライアンスに DMK が存在する場合は、DMK パスワードをパラメーターとして指定する必要があります。

アップグレード アクションの例。 ********** を、ご利用のDMK パスワードに置き換えます。

setup.exe /Action=ProvisionUpgrade ... DMKPassword='**********'

仮想マシンを置き換えるアクションの例。

setup.exe /Action=ReplaceVM ... DMKPassword='**********'

アップグレード中に、ユーザー DB が暗号化されていて、DMK パスワードが指定されていない場合、アップグレード 操作は失敗します。 置換中に、DMK が存在するときに正しいパスワードが指定されていない場合、操作は DMK 回復手順をスキップします。 他のすべての手順は、VM の置換アクションの最後に完了しますが、アクションは最後にエラーを報告して、追加の手順が必要であることを示します。 セットアップ ログ (\ProgramData\Microsoft\Microsoft SQL Server Parallel Data Warehouse\100\Logs\Setup\\<time-stamp>\Detail-Setup にあります) では、末尾近くに次の警告が表示されます。

*** WARNING \*\*\* DMK is detected in master database, but could not be recovered automatically! The DMK password was either not provided or is incorrect!

DMK を復旧するには、PDW で次のステートメントを手動で実行し、その後アプライアンスを再起動します。

OPEN MASTER KEY DECRYPTION BY PASSWORD = '<DMK password>';  
ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY;  

マスター データベースの復元に関する段落の手順を使用してデータベースを復旧し、アプライアンスを再起動します。

DMK が前に存在していたが、アクションの後に復旧されなかった場合は、データベースの照会時に次のエラー メッセージが表示されます。

Msg 110806;  
A distributed query failed: Database '<db_name>' cannot be opened due to inaccessible files or insufficient memory or disk space. See the SQL Server errorlog for details.

パフォーマンスへの影響

TDE のパフォーマンスへの影響は、使用しているデータの種類、その格納方法、およびSQL Server PDW でのワークロード アクティビティの種類によって異なります。 TDE によって保護されている場合、データの読み取りと復号化、またはデータの暗号化と書き込みに関する I/O は、CPU を大量に消費するアクティビティであり、他の CPU 負荷の高いアクティビティが同時に発生していると、より大きい影響を受けます。 TDE は 暗号化されるためtempdb、TDE は暗号化されていないデータベースのパフォーマンスに影響する可能性があります。 パフォーマンスを正確に把握するには、データとクエリ アクティビティを使用してシステム全体をテストする必要があります。

次のリンクには、SQL Server による暗号化の管理方法に関する一般的な情報が含まれています。 これらの記事は SQL Server の暗号化を理解するのに役立ちますが、これらの記事には SQL Server PDW に固有の情報はなく、SQL Server PDW に存在しない機能について説明しています。

参照

ALTER DATABASE
CREATE MASTER KEY
CREATE DATABASE ENCRYPTION KEY
BACKUP CERTIFICATE
sp_pdw_database_encryption
sp_pdw_database_encryption_regenerate_system_keys
sp_pdw_log_user_data_masking
sys.certificates
sys.dm_pdw_nodes_database_encryption_keys