MASTERデータベースを復元してTDE証明書を回復できますか?


10

(幸いなことに、私たちは現在このような状況にありません。それが発生した場合の選択肢がどうなるかを事前に計画しているだけです。)

透過的日付暗号化(TDE)で暗号化されたデータベースの場合、暗号化に使用した証明書のバックアップがない限り、データベースバックアップのコピーは回復できません。

それがない場合はどうなりますか?追加のオプションはありますか?

完全なサーバー障害が発生した場合、MASTERデータベースのバックアップを新しいハードウェアに復元すると、証明書も復元されますか?

回答:


9

TDEはマスターに保存されている証明書(データベース暗号化キーの暗号化に使用される)に依存しているため、マスターデータベースを別のサーバーに復元して証明書を復号化できる場合にのみ機能します。

これはTDE暗号化階層です:

  1. サービスマスターキー(Windowsで保護されています。サービスアカウントの資格情報とマシンキーに関連付けられています)
  2. データベースマスターキー(この場合は、マスターデータベースのキー)
  3. 証書
  4. TDE暗号化キー

最初の3つのアイテムはマスターデータベースに保存され、すべてバックアップできます。4番目は、暗号化されたデータベースのヘッダーに格納されます(#3の証明書で暗号化されています)。

したがって、障害シナリオでは、TDEキーを読み取ることができるように、暗号化階層を十分に復元する必要があります。SQL Serverはインストール時にサービスマスターキーを作成します。したがって、マスターデータベースを別のインスタンスに復元すると、アイテム2と3も復元されますが、アイテムを復号化するために必要なキーは存在しません。結果:読み取り不可能なデータ。

証明書(#3)をバックアップから復元する(何らかの理由でマスターを復元できない場合に適したオプション)か、マスターデータベースとそのマスターキー(#2)をバックアップから復元するという2つの最適なオプションがあります。マスターキーを復元することは、このキーで保護された証明書/キーがたくさんあり、それらすべてに一度にアクセスできるようにする必要がある場合に、より良いオプションになることがあります。これには、masterデータベースの復元に通常関連する同じ予防策(照合順序、ログイン、データベース名、ファイルパスなど)が付属しています。

一般に、回復シナリオでのみマスターを復元することをお勧めします。移行/スケールアウトシナリオ(TDEで暗号化されたデータベースでの可用性グループ/ミラーリングの使用など)の場合、移動する各インスタンスに固有のマスターキーを使用して暗号化されるように、証明書(#3)をバックアップ/復元することをお勧めしますに。証明書のバックアップに秘密鍵を含める必要があります。

いずれの場合も、キー/証明書のバックアップを作成する必要があるため、それらを適切に保護し、冗長で安全な場所に保管します。masterのバックアップを作成するだけでは、TDE災害から抜け出すことはできません。少なくとも1つのキーまたは証明書のバックアップが必要になります。


さて、SMK(1)またはマスターdb DMK(2)も復元せずに、別のサーバーで証明書を復元できるのはどうしてでしょうか。その新しいサーバーからSMK / DMKにそれ自体を「接続」しますか?
BradC 2013

ああ、わかったと思います。証明書をエクスポートすると、元のサーバーからのSMK / DMKへの依存を置き換えるエクスポート用のキーが明示的に提供されます。新しいサーバーにインポートすると、依存関係が新しいサーバーのSMK / DMKに転送されます。いいですか?
BradC 2013

うん、それはまさにそれです。証明書をエクスポートまたはインポートするときは、バックアップの暗号化/復号化に使用するパスワードを提供する必要があります。バックアップを復元すると、証明書がインポートされ、宛先サーバーのDMKで再暗号化されます。
db2 2013

5

1.暗号化されたバックアップを通常どおり別のサーバーに復元する場合は、次のエラーが発生します

 Cannot find server certificate with thumbprint …...

2.証明書名を検索します:この例ではvestacert

   SELECT  * FROM   sys.certificates

3.ソースサーバーから証明書をバックアップします(ソース暗号化サーバー):

BACKUP CERTIFICATE vestacert
TO FILE = 'c:\Backup\certificate_TDE_Test_Certificate.cer'
WITH PRIVATE KEY
(FILE = 'c:\Backup\certificate_TDE_Test_Key.pvk',
ENCRYPTION BY PASSWORD = 'Password12#')

4.まだ存在しない場合は、UATサーバーに新しいマスター証明書を作成します。

USE master GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'D1ffPa$$w0rd'

5.UATサーバー(UATserver)にバックアップ証明書を復元する

CREATE CERTIFICATE vestacert2
FROM FILE = 'C:\tmp\certificate_TDE_Test_Certificate.cer'     
WITH PRIVATE KEY (FILE = 'C:\tmp\LCMS\certificate_TDE_Test_Key.pvk', 
DECRYPTION BY PASSWORD = 'Passsword12#')

6.この手順の後、バックアップを復元してもエラーは発生せず、すべてのデータが読み取り可能でした。

7.面白いのは、暗号化を削除し、新しいバックアップを取り、最終サーバー(Final Server)でそれを復元することが機能せず、次のエラーが発生することです。「mydb_log」ファイルは正しく初期化できませんでした。詳細については、エラーログを調べてください。

8. UATから暗号化を削除する正しい方法は、以下のようなすべての兆候を段階的に、下から上に削除することです

    USE master
    ALTER DATABASE mydb SET ENCRYPTION OFF
    USE mydb
    DROP DATABASE ENCRYPTION KEY 
    USE master
    DROP CERTIFICATE vestacert2 
    DROP MASTER KEY

9.今度はUATサーバーから新しいバックアップを作成し、それを最終サーバーに復元します

良い記事:http : //sqlserverzest.com/2013/10/03/sql-server-restoring-a-tde-encrypted-database-to-a-different-server/


1
ログファイルに暗号化された内容が残っているため、ログの復元は失敗します。無効にした後、シンプルモードに切り替え、ログを切り捨ててからバックアップを再度実行します。
IDisposable

0

システムがクラッシュして使用できなくなった場合は、新しいシステムを構築し、既存のシステムにマスターデータベースを復元して、新しいシステムで同じサービスアカウントを使用している限り、TDE証明書を回復できます。。次に、システムを再起動して、ローカルマシンキーによるサービスマスターキーの暗号化を修正する必要があります。その後、TDE証明書をバックアップするか、ユーザーデータベースを復元してデータにアクセスできるようになります。サービスマスターキーは、Windowsサーバーのデータ保護APIによって2つの方法で保護されます。1つはシステムに固有のローカルマシンキーを使用する方法、もう1つはデータベースエンジンのサービスアカウントを使用する方法です。システムクラッシュにより、元のシステムのローカルマシンキーがなくなるため、同じサービスアカウントを使用する必要があります。TDE証明書はデータベースと共にバックアップされますが、暗号化階層が完了するまでアクセスできません。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.