0

これは、この質問が通常尋ねられる方法とは少し逆です。次を使用して、データベース マスター キー、証明書、および対称キーを作成しました。

証明書/キーを作成する方法は次のとおりです（明らかに実際のパスワードを使用）：

CREATE MASTER KEY ENCRYPTION
BY PASSWORD = '123456'

CREATE CERTIFICATE EncryptionCert
WITH SUBJECT = 'EncryptionCert'

CREATE SYMMETRIC KEY SymmetricKey
WITH ALGORITHM = AES_256
ENCRYPTION BY CERTIFICATE EncryptionCert;

次に、そのキーを使用して一部のデータを暗号化し、データベースをバックアップして、別のボックスに復元しました。

最初に古いボックスからサービス マスター キーを移行するまでデータを復号化できないと思っていましたが、実際には、証明書やパスワードを 1 つも提供しなくても、復元後すぐに復号化できました。

Amazon EC2 イメージを使用してボックスを作成していたため、これが発生していると推測したため、そのイメージから作成されたすべてのボックスが同じサービス マスター キーを持っていると想定しています。

サービス キーを強制的に変更するために、次のコマンドを実行しました。

alter service master key regenerate

両方のボックスに。

新しいデータベース、新しいキー/証明書などで最初からやり直しましたが、今回はバックアップを新しいボックスに移動したとき、データを自動的に読み取ることができませんでしたが、最初にデータベースのパスワードを提供する必要がありました私が作成したマスターキー。それができたら、データにアクセスできました。

私が読んだすべてのことから、最初にサービス マスター キーを移動しないと、マスター キーを復号化できないと思っていたでしょう。

サービス マスター キーが必要ないのは、まだテスト環境がおかしいためではないかと心配しています。

ここで何が起こっているのかを明らかにできる人はいますか? サービス マスター キーの移動が不要になるような SQL の変更がありましたか、それとも移動が不要になるような方法でデータベース マスター キーを作成しましたか? それとも、間違っている可能性のある結果を返していますか?

4

1 に答える 1

0

Matt Bowler は、データベース暗号化に関する優れた記事を書いています。問題は、サーバー マスター キーの暗号化方法にある可能性があります。インスタンスが同じサービス アカウントで実行されている可能性はありますか?

サービス マスター キー: キー階層の最上位はサービス マスター キーです。SQL Server インスタンスごとに 1 つあり、これは対称キーであり、マスター データベースに格納されます。データベース マスター キー、リンク サーバーのパスワード、および資格情報を暗号化するために使用され、最初の SQL Server の起動時に生成されます。

このキーに関連付けられているユーザー構成可能なパスワードはありません。これは、SQL Server サービス アカウントとローカル マシン キーによって暗号化されています。起動時に、SQL Server はこれらの復号化のいずれかを使用してサービス マスター キーを開くことができます。どちらかが失敗した場合 – SQL Server はもう一方を使用し、失敗した復号化を「修正」します(両方が失敗した場合 – SQL Server はエラーになります)。これは、フェールオーバー後にローカル マシン キーが異なるクラスターなどの状況に対応するためです。これは、サービス マスター キーの暗号化が正しく再生成されるため、SQL Server 構成マネージャーを使用してサービス アカウントを変更する必要がある理由の 1 つでもあります。

http://mattsql.wordpress.com/2012/11/13/migrating-sql-server-databases-that-use-database-master-keys/

于 2015-01-03T22:47:40.997 に答える