Tôi có thể khôi phục chứng chỉ TDE bằng cách khôi phục cơ sở dữ liệu MASTER không?

(May mắn thay, hiện tại chúng tôi không ở trong tình huống này, chỉ cần lên kế hoạch trước để xem những lựa chọn của chúng tôi sẽ là gì nếu nó xảy ra.)

Đối với cơ sở dữ liệu được mã hóa bằng Mã hóa ngày trong suốt (TDE), bản sao của cơ sở dữ liệu sao lưu không thể khôi phục được trừ khi bạn có bản sao lưu chứng chỉ được sử dụng để mã hóa nó.

Nếu bạn không có điều đó thì sao? Có bất kỳ lựa chọn bổ sung?

Trong trường hợp máy chủ bị lỗi hoàn toàn, việc khôi phục bản sao lưu cơ sở dữ liệu MASTER trên phần cứng mới cũng sẽ khôi phục chứng chỉ?

Do TDE dựa vào chứng chỉ được lưu trữ trong master (được sử dụng để mã hóa khóa mã hóa cơ sở dữ liệu), nên điều này sẽ chỉ hoạt động nếu bạn có thể khôi phục cơ sở dữ liệu chủ sang máy chủ khác theo cách mà chứng chỉ có thể được giải mã.

Đây là hệ thống phân cấp mã hóa TDE:

1. Khóa chính dịch vụ (được bảo vệ bởi Windows; gắn với thông tin đăng nhập tài khoản dịch vụ và khóa máy)
2. Khóa chủ cơ sở dữ liệu (trong trường hợp này là khóa dành cho cơ sở dữ liệu chủ)
3. Chứng chỉ
4. Khóa mã hóa TDE

Ba mục đầu tiên được lưu trữ trong cơ sở dữ liệu chủ và tất cả đều có thể được sao lưu. Thứ tư được lưu trữ (được mã hóa bởi chứng chỉ từ # 3) trong tiêu đề của cơ sở dữ liệu được mã hóa.

Vì vậy, trong trường hợp thất bại, bạn sẽ phải khôi phục đủ cấu trúc phân cấp mã hóa để cho phép bạn đọc khóa TDE. SQL Server tạo khóa chủ dịch vụ khi cài đặt; do đó, trong khi khôi phục cơ sở dữ liệu chủ sang một phiên bản khác cũng sẽ khôi phục các mục 2 và 3, (các) khóa cần thiết để giải mã chúng sẽ không xuất hiện. Kết quả: dữ liệu không thể đọc được.

Hai tùy chọn tốt nhất là khôi phục chứng chỉ (# 3) từ bản sao lưu (một tùy chọn tốt nếu không thể khôi phục chính vì bất kỳ lý do gì) hoặc khôi phục cơ sở dữ liệu chính và khóa chính của nó (# 2) từ bản sao lưu. Khôi phục khóa chính có thể là một lựa chọn tốt hơn nếu bạn có nhiều chứng chỉ / khóa được bảo vệ bởi khóa này và cần phải làm cho tất cả chúng có thể truy cập cùng một lúc. Điều này đi kèm với các biện pháp phòng ngừa tương tự thường được liên kết với việc khôi phục cơ sở dữ liệu chủ (collations, đăng nhập, tên cơ sở dữ liệu và đường dẫn tệp, v.v.)

Nói chung, tôi chỉ khuyên bạn nên khôi phục chủ trong kịch bản khôi phục. Đối với kịch bản di chuyển / mở rộng quy mô (chẳng hạn như sử dụng Nhóm khả dụng / phản chiếu với cơ sở dữ liệu được mã hóa TDE), tốt hơn hết là bạn nên sao lưu / khôi phục chứng chỉ (# 3) để nó được mã hóa bằng các khóa chính duy nhất cho mỗi trường hợp di chuyển đến. Bạn sẽ cần bao gồm khóa riêng với bản sao lưu chứng chỉ.

Trong mọi trường hợp, bạn sẽ phải tạo bản sao lưu khóa / chứng chỉ, vì vậy hãy bảo vệ chúng thật tốt và lưu trữ chúng ở những vị trí an toàn, dự phòng. Chỉ cần có một bản sao lưu của chủ sẽ không giúp bạn thoát khỏi thảm họa TDE; bạn sẽ cần một bản sao lưu ít nhất một khóa hoặc chứng chỉ.

1.Nếu bạn muốn khôi phục bản sao lưu được mã hóa sang máy chủ khác như bình thường, bạn gặp phải lỗi sau

 Cannot find server certificate with thumbprint …...

2.Tìm tên cert: trong ví dụ này vestacert

   SELECT  * FROM   sys.certificates

3. sao lưu chứng chỉ từ máy chủ nguồn (Máy chủ mã hóa nguồn):

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. Tạo chứng chỉ Master mới trên máy chủ UAT nếu chưa tồn tại

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

5.Restore certs sao lưu trong máy chủ 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.Sau khi bước này khôi phục lại bản sao lưu không có bất kỳ lỗi nào và tất cả dữ liệu đều có thể đọc được.

7. Nhưng điều buồn cười là việc loại bỏ mã hóa đơn giản và thực hiện sao lưu mới và khôi phục nó trên máy chủ cuối cùng (Máy chủ Cuối cùng) không hoạt động và đưa ra lỗi sau Tệp "mydb_log" không thể khởi tạo chính xác. Kiểm tra các bản ghi lỗi để biết thêm chi tiết.

8. Cách chính xác để loại bỏ mã hóa khỏi UAT là xóa tất cả các dấu hiệu như bên dưới từng bước và từ dưới lên trên

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

9. Bây giờ hãy tạo bản sao lưu mới từ máy chủ UAT và khôi phục nó về máy chủ cuối cùng

bài viết hay: http://sqlserverzest.com/2013/10/03/sql-server-restoring-a-tde-encrypted-database-to-a-different-server/

Nếu hệ thống của bạn gặp sự cố và trở nên không sử dụng được, thì bạn có thể xây dựng một hệ thống mới và khôi phục cơ sở dữ liệu chủ so với cơ sở dữ liệu hiện có để khôi phục chứng chỉ TDE miễn là bạn sử dụng cùng một tài khoản dịch vụ trên hệ thống mới. Sau đó, bạn nên khởi động lại hệ thống để sửa mã hóa Khóa dịch vụ chính bằng khóa máy cục bộ. Sau đó, bạn sẽ có thể sao lưu chứng chỉ TDE hoặc khôi phục cơ sở dữ liệu người dùng và truy cập dữ liệu. Khóa dịch vụ chính được bảo vệ bởi API bảo vệ dữ liệu của máy chủ Windows theo hai cách, thứ nhất là sử dụng khóa máy cục bộ dành riêng cho hệ thống và thứ hai sử dụng tài khoản dịch vụ của công cụ cơ sở dữ liệu. Vì bạn sẽ không còn có khóa máy cục bộ của hệ thống gốc do sự cố hệ thống, bạn phải sử dụng cùng một tài khoản dịch vụ. Chứng chỉ TDE được sao lưu với cơ sở dữ liệu, nhưng không thể truy cập cho đến khi phân cấp mã hóa hoàn tất.