web-dev-qa-db-ja.com

SQLデータベースを復元するときにTDEをオフにする

TDEを始めたばかりです。最終的には、製品SQL Server環境と2つの主要な非製品環境になりますが、現在は1つの非製品システムにのみ存在します。

私の質問は、これらのデータベースの復元についてです。他にもいくつかの環境(EnterpriseおよびStandard Edition)があり、データベースのバックアップを送信するオフサイトベンダーもあります。それらについては、中間サーバーを使用して復元する前にTDEをオフにするか、別のキーでバックアップする必要があります。

しかし、具体的には、TDE対応の本番環境からTDE対応の非本番環境に復元する方法について疑問に思っています。 TDEをオフにせずにTDEデータベースを復元すると、ソースサーバーのキーが使用されますか?この状況でTDEをオフおよびオンにする(これには数時間かかる)必要があるのか​​どうか疑問に思っています。以下に復元したときの奇妙な動作にも注意してください。それはデータベースの以前の具体化を通じて履歴キーを運んでいるように見え、同じデータベース名のサーバーにコピーするとき、2番目のサーバーのキーを許可しています。これは正しいですか?

異なるVM上の2つのデータベースインスタンスで構成される非製品環境で次のことを行いました。

インスタンス1:

  1. データベースDBAでTDEを有効にし、
  2. 証明書、キー、データベースをバックアップし、
  3. DBAのバックアップを新しいデータベースDBA2に復元しました。
  4. データベースDBA2のインスタンス2をバックアップしました。
  5. インスタンス1からDBA2バックアップをコピーした
  6. DBA2を復元しました。

DBA2の証明書またはキーを作成せず、インスタンス1から2にDBA証明書とキーをコピーしなかったことに注意してください。

インスタンス2には、TDE証明書とキーを持つ独自の無関係なDBAデータベースがあります。リストア後、DBA2でTDEが有効になっていません。

だからそれはようです:

  1. インスタンス1のDBAキーが手順3でDBA2に引き継がれ、
  2. インスタンス1のDBAとインスタンス2のDBAが別々のエンティティである場合でも、復元では、手順6でインスタンス2のDBAキーを使用した可能性があります。

これらのデータベースの暗号化ステータスは次のとおりです。

    SELECT db_name(database_id), encryption_state,   percent_complete, key_algorithm, key_length
    FROM sys.dm_database_encryption_keys
where db_name(database_id) like 'DBA%'

インスタンス1:

dbname  encryption_state    percent_complete    key_algorithm   key_length
DBA     3                   0                   AES             256
DBA2    3                   0                   AES             256

インスタンス2:

dbname  encryption_state    percent_complete    key_algorithm   key_length
DBA     3                   0                   AES             256
6
BrianC

しかし、具体的には、TDE対応の本番環境からTDE対応の非本番環境に復元する方法について疑問に思っています。

ドキュメント全体 があります。特定の質問がある場合はお知らせください。

TDEをオフにせずにTDEデータベースを復元すると、ソースサーバーのキーが使用されますか?

上記の記事を見ると、データベースに存在するデータベース暗号化キー(DKE)を保護しているサーバー証明書が復元され、移行先サーバーで利用できない限り、データベースを読み取ることができないことがわかります。 。

この状況でTDEをオフおよびオンにする(これには数時間かかる)必要があるのか​​どうか疑問に思っています。

お客様がTDEを使​​用できない場合、それは要件です(非エンタープライズエディション)。内部証明書を送信したくない場合は、宛先サーバーに復元したら、サーバー証明書を新しいものにローテーションします。データベースで(メタデータの変更を除いて)追加の操作は必要ありません。もちろん、2つの別々の通信チャネルまたは安全なチャネルで、証明書とデータベースを顧客に送信できます。

以下に復元したときの奇妙な動作にも注意してください。それはデータベースの以前の具体化を通じて履歴キーを運んでいるように見え、同じデータベース名のサーバーにコピーするとき、2番目のサーバーのキーを許可しています。

えっ?出力には、データベースの暗号化状態以外は何も表示されません。サーバー証明書がないと、文字通りデータベースを復元できません。したがって、問題なくデータベースを復元でき、そのためのサーバー証明書を復元しなかった場合、論理的な結論は、現在のサーバー証明書がソースサーバーと宛先サーバーで同じであるということです。 。

7
Sean Gallardy

しかし、具体的には、TDE対応の本番環境からTDE対応の非本番環境に復元する方法について疑問に思っています。

(キーとパスワードを使用して)バックアップしたTDE証明書を非製品SQLサーバーに復元するだけで、暗号化されたデータベースを2つの環境間で相互に復元できます。

私たちの環境では、サーバーごとではなく、証明書各アプリケーション用を作成します。これは、同じサーバー上の複数のデータベースが異なるアプリケーションの一部である場合、異なる証明書を使用している可能性があることも意味します。

また、これらのアプリケーションのQAおよびDEV環境は、セキュリティの観点から、製品環境と同じくらい厳しくロックダウンする必要があることも意味します。セキュリティポリシーで許可されていない場合は、はい。データベースのコピーを中間サーバーに復元(またはprodでコピーを復元)して、TDEを削除する必要があります。

TDEをオフにせずにTDEデータベースを復元すると、ソースサーバーのキーが使用されますか?

エクスポートされたキーとパスワードを使用して証明書を復元すると、同じ証明書が使用されますが、新しいサーバーのマスターキーに接続なので、元の証明書は使用されますが、ソースサーバーの証明書は使用されません「キー」、それ自体。

以下に復元したときの奇妙な動作にも注意してください。それはデータベースの以前の具体化を通じて履歴キーを運んでいるように見え、同じデータベース名のサーバーにコピーするとき、2番目のサーバーのキーを許可しています。これは正しいですか?

いいえ、それは不可能です。 2番目のサーバーに復元する前に誰かがTDEを削除したか、2番目のインスタンスが同じTDE証明書の以前に復元されたコピーを(名前ではなく拇印で)持っています。

いくつかの便利なクエリ:

SELECT name, issuer_name, subject, thumbprint
FROM master.sys.certificates
WHERE pvt_key_encryption_type = 'MK'

インスタンス上のすべてのTDE証明書を一覧表示します(または、少なくとも、マスターキーで暗号化されたすべての証明書を推奨します)。 「拇印」は、サーバー間で証明書を比較する場合に重要な列です。

SELECT d.name as dbname, d.is_encrypted,
       CASE k.encryption_state
           WHEN 0 THEN 'NoKey'
           WHEN 1 THEN 'Unencrypted'
           WHEN 2 THEN 'Encryping...'
           WHEN 3 THEN 'Encrypted'
           WHEN 4 THEN 'KeyChange...'
           WHEN 5 THEN 'Decrypting...'
           WHEN 6 THEN 'ProtectionChange...'
       END as state_desc,
       k.percent_complete, CONCAT(k.key_algorithm, '-', k.key_length) as key_type,
       c.name as certname
FROM sys.databases d
LEFT OUTER JOIN sys.dm_database_encryption_keys k ON d.database_id = k.database_id
LEFT OUTER JOIN sys.certificates c ON k.encryptor_thumbprint = c.thumbprint
ORDER BY k.encryption_state DESC, d.name;

サーバー上のすべてのデータベース、それらの暗号化状態、およびそれらが関連付けられている暗号化キーを(名前ではなく拇印に基づいて)表示します。

3
BradC