Tại sao SQL Server yêu cầu khóa riêng để mã hóa bản sao lưu?


7

Tôi đang thiết lập một thử nghiệm trong đó tôi chỉ có phần khóa công khai của chứng chỉ trên máy chủ. Chứng chỉ được tạo trên một máy chủ khác và tôi không khôi phục khóa riêng.

Khi tôi cố gắng sao lưu cơ sở dữ liệu bằng mã hóa bằng chứng chỉ đó, tôi gặp lỗi này:

Msg 15556, Level 16, State 1, Line 15
Cannot decrypt or encrypt using the specified certificate, either because it has no private key or because the password provided for the private key is incorrect.
Msg 3013, Level 16, State 1, Line 15
BACKUP DATABASE is terminating abnormally.

Đó là SQL Server rõ ràng cho tôi biết nó cần khóa riêng để mã hóa.

Nhưng tại sao vậy?

Tôi hiểu rằng BACKUP tạo khóa đối xứng nhanh chóng, bảo vệ khóa đối xứng bằng khóa chung trong chứng chỉ và lưu trữ cùng với nội dung sao lưu. Khóa đối xứng sau đó được sử dụng để mã hóa nội dung sao lưu thực tế, vì mã hóa đối xứng thường nhanh hơn (luôn luôn?) So với mã hóa bất đối xứng.

Để khôi phục bản sao lưu, sau đó tôi sẽ cần khóa riêng tương ứng với khóa chung được sử dụng trong mã hóa. Đó là mong đợi.

Tôi không hiểu tại sao cần có khóa riêng trong quá trình sao lưu. Không tìm thấy câu trả lời trên tài liệu hoặc bất cứ nơi nào khác. Ai đó có thể giải thích điều đó hoặc chỉ cho tôi một số tài liệu về lý do tại sao đó là trường hợp?


Câu trả lời:


6

Tôi không hiểu tại sao cần có khóa riêng trong quá trình sao lưu.

Câu trả lời ngắn

Đó là cách nó hiện đang được thực hiện.

Câu trả lời dài hơn

Tôi đã không xem xét tất cả các phụ thuộc để xem liệu nó có được yêu cầu không (về mặt logic sẽ không cần mã hóa dữ liệu, chỉ giải mã như bạn đã nêu) cho tất cả các cuộc gọi khác, nhưng nó đã được kiểm tra và do đó lỗi được đưa ra như thế nào nó được viết và thực hiện.

Nếu bạn lo lắng về việc có các khóa trên cùng một máy chủ hoặc nhiều máy chủ để thực hiện các hoạt động sao lưu, bạn có thể muốn xem xét việc sử dụng HSM tích hợp với mã hóa dự phòng.

Bạn có thể tích hợp các khóa mã hóa với các nhà cung cấp Quản lý khóa mở rộng (EKM).

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.