Để xác định theo chương trình nếu SMK hiện tại được sử dụng để bảo vệ DMK, bạn có thể chỉ cần thử một thao tác yêu cầu DMK. Một hoạt động như vậy trước tiên cần phải giải mã DMK để sử dụng nó. Giả sử rằng bạn chưa mở DMK một cách rõ ràng (sử dụng mật khẩu được cung cấp khi tạo nó), việc giải mã DMK sẽ yêu cầu SMK. Nếu SMK hiện tại không phải là SMK chính xác , thì DMK sẽ không được giải mã tự động và hoạt động sẽ thất bại. Vì thế:
Nếu bạn có Chứng chỉ được đảm bảo tồn tại trong Cơ sở dữ liệu đang được khôi phục, hãy thử sử dụng Chứng chỉ:
SELECT SIGNBYCERT( CERT_ID( '{certificate_name}' ), 'test' );
Điều đó sẽ trả về một NULL
giá trị VARBINARY. Nếu giá trị trả về là NULL
, thì DMK cần được tạo lại (theo hướng dẫn bên dưới).
Nếu không có Chứng chỉ nào được đảm bảo tồn tại trong Cơ sở dữ liệu đang được khôi phục, thì hãy thử tạo một Chứng chỉ. Nếu SMK có thể được sử dụng để tự động giải mã DMK, thì Chứng chỉ sẽ được tạo, nếu không thì thao tác sẽ thất bại:
BEGIN TRY
CREATE CERTIFICATE [TestCert] WITH SUBJECT = 'yadda yadda yadda';
DROP CERTIFICATE [TestCert];
PRINT 'All good, yo!';
END TRY
BEGIN CATCH
PRINT ERROR_MESSAGE();
END CATCH;
Tuy nhiên, vì bạn vừa khôi phục cơ sở dữ liệu đến từ một cá thể khác và không khôi phục SMK của cá thể đó vào phiên bản mới, nên có thể giả định rằng câu trả lời là: "không, DMK không được mã hóa bằng SMK của máy chủ này ."
Đây là một kịch bản dự kiến yêu cầu các bước sau để khắc phục:
USE [newly_restored_db];
OPEN MASTER KEY DECRYPTION BY PASSWORD = '{password}'; -- password used to protect DMK
ALTER MASTER KEY REGENERATE WITH ENCRYPTION BY PASSWORD = '{password}';
CLOSE MASTER KEY;
Trang MSDN cho CREATE MASTER KEY
các trạng thái (nhấn mạnh thêm):
Đối với SQL Server và Kho dữ liệu song song, Khóa chính thường được bảo vệ bởi Khóa chính dịch vụ và ít nhất một mật khẩu. Trong trường hợp cơ sở dữ liệu được di chuyển vật lý đến một máy chủ khác (vận chuyển nhật ký, khôi phục sao lưu, v.v.), cơ sở dữ liệu sẽ chứa một bản sao của Khóa chính được mã hóa bởi Máy chủ gốc Khóa dịch vụ (trừ khi mã hóa này được xóa rõ ràng bằng ALTER MASTER KEY DDL) và một bản sao của nó được mã hóa bởi mỗi mật khẩu được chỉ định trong quá trình CREATE MASTER KEY hoặc các hoạt động DDL ALTER MASTER KEY tiếp theo. Để khôi phục Khóa chính và tất cả dữ liệu được mã hóa bằng Khóa chính làm gốc trong phân cấp khóa sau khi cơ sở dữ liệu được di chuyển, người dùng sẽ có [để] sử dụng [câu lệnh] OPEN MASTER KEY bằng một trong mật khẩu được sử dụng để bảo vệ Khóa chính, khôi phục bản sao lưu của Khóa chính hoặc khôi phục bản sao lưu của Khóa chính gốc trên máy chủ mới.
Trang MSDN cho OPEN MASTER KEY
các trạng thái:
Khi cơ sở dữ liệu lần đầu tiên được đính kèm hoặc khôi phục vào phiên bản mới của SQL Server, một bản sao của khóa chính cơ sở dữ liệu (được mã hóa bởi khóa chính dịch vụ) chưa được lưu trữ trong máy chủ. Bạn phải sử dụng câu lệnh OPEN MASTER KEY để giải mã khóa chính cơ sở dữ liệu (DMK). Khi DMK đã được giải mã, bạn có tùy chọn bật giải mã tự động trong tương lai bằng cách sử dụng câu lệnh ALTER MASTER KEY REGENERATE để cung cấp cho máy chủ bản sao DMK, được mã hóa bằng khóa chính dịch vụ (SMK). Khi cơ sở dữ liệu đã được nâng cấp từ phiên bản cũ hơn, DMK sẽ được tạo lại để sử dụng thuật toán AES mới hơn. Để biết thêm thông tin về việc tạo lại DMK, hãy xem ALTER MASTER KEY (Transact-SQL). Thời gian cần thiết để tạo lại khóa DMK để nâng cấp lên AES tùy thuộc vào số lượng đối tượng được DMK bảo vệ. Việc tạo lại khóa DMK để nâng cấp lên AES chỉ cần thiết một lần và không có tác động đến việc tái tạo trong tương lai như là một phần của chiến lược xoay vòng chính.
Trang MSDN cho trạng thái ALTER MASTER KEY :
Tùy chọn REGENERATE tạo lại khóa chính cơ sở dữ liệu và tất cả các khóa mà nó bảo vệ. Các khóa đầu tiên được giải mã bằng khóa chính cũ và sau đó được mã hóa bằng khóa chính mới. Hoạt động sử dụng nhiều tài nguyên này nên được lên lịch trong thời gian nhu cầu thấp, trừ khi khóa chính đã bị xâm phạm.
before
tôi tái tạo khóa chủ?