Nhóm Khả dụng là tuyệt vời cho các giải pháp Khả năng sẵn sàng cao / Phục hồi sau thảm họa và tôi chắc chắn rằng các DBA đồng nghiệp sẽ đồng ý với tôi. Tuy nhiên, sẽ có lúc chúng ta phải cân nhắc một số biện pháp phòng ngừa và các bước bổ sung một cách cẩn thận để tránh những bất ngờ không mong muốn. Ví dụ:bất kỳ Bản sao thứ cấp nào trở thành Bản sao chính hiện tại vì bất kỳ lý do gì và mục tiêu của chúng tôi là không để điều đó xảy ra.
Có hai tùy chọn mã hóa được cung cấp bởi SQL:sql tde so với luôn được mã hóa. Trong bài viết này, tôi sẽ giới thiệu một tình huống yêu cầu DBA phải chú ý đến chi tiết. Giống như tiêu đề đã nói, nó sẽ hướng dẫn bạn cách thích hợp để xử lý mã hóa dữ liệu trong cơ sở dữ liệu là một phần của thiết lập Nhóm luôn sẵn sàng.
Cân nhắc ban đầu
Tôi sẽ sử dụng Mã hóa dữ liệu minh bạch (TDE) làm công nghệ để xây dựng trường hợp của tôi. Nó áp dụng cho tất cả các phiên bản SQL Server được hỗ trợ. Điều quan trọng cần đề cập là tính năng này chỉ khả dụng trong các Phiên bản SQL Server sau:
- Đánh giá SQL Server 2019, Tiêu chuẩn, Nhà phát triển, Doanh nghiệp
- Đánh giá SQL Server 2017, Nhà phát triển, Doanh nghiệp
- Đánh giá SQL Server 2016, Nhà phát triển, Doanh nghiệp
- Đánh giá SQL Server 2014, Nhà phát triển, Doanh nghiệp
- Đánh giá SQL Server 2012, Nhà phát triển, Doanh nghiệp
- Trung tâm dữ liệu SQL Server 2008R2, Đánh giá, Nhà phát triển, Doanh nghiệp
- Đánh giá SQL Server 2008, Nhà phát triển, Doanh nghiệp
Hãy xem cách chúng ta có thể sử dụng TDE (Mã hóa dữ liệu minh bạch) trong SQL Server Standard Edition. Trước hết, chúng ta cần tạo một DMK (Database Master Key) để mã hóa dữ liệu. Sau đó, chúng tôi tạo một chứng chỉ và một khóa để có thể giải mã dữ liệu trong khi truy cập nó. Đừng quên sao lưu chứng chỉ và cuối cùng, bật mã hóa.
Lưu ý: Tính năng TDE không được hỗ trợ trong SQL Server Express Edition.
Bài đăng này sẽ không đề cập đến các bước để xây dựng Nhóm sẵn sàng và tôi đang dựa vào nhóm đã được xây dựng cho mục đích thử nghiệm. Bạn có thể đọc thêm về cách triển khai nhóm khả dụng SQL Server AlwaysOn trên Linux.
Môi trường dựa trên Windows, nhưng các nguyên tắc sẽ rất giống nhau nếu bạn sử dụng các nền tảng khác nhau (ví dụ:SQL Server trên Linux hoặc Azure SQL Managed Instances).
Mã hóa dữ liệu tạm thời là gì
Lý do chính tại sao chúng tôi sử dụng TDE là bảo mật dữ liệu và tệp nhật ký cho cơ sở dữ liệu SQL của bạn. Để ngăn dữ liệu cá nhân của bạn bị đánh cắp, bạn nên bảo vệ dữ liệu đó, ngoài ra quá trình mã hóa này rất dễ dàng. Trước khi trang được ghi vào đĩa, các tệp được mã hóa ở cấp độ trang. Mỗi khi bạn muốn truy cập dữ liệu của mình, nó sẽ được giải mã. Sau khi triển khai TDE, bạn sẽ cần một chứng chỉ cụ thể và một khóa để khôi phục hoặc đính kèm cơ sở dữ liệu. Đó là thuật toán mã hóa.
Microsoft Ví dụ về nhóm khả dụng của máy chủ SQL
Nhóm Khả dụng thử nghiệm của tôi bao gồm 2 bản sao, mỗi bản sao nằm trong máy ảo riêng của nó. Dưới đây là các thuộc tính cơ bản:
Như bạn có thể thấy, không có gì lạ mắt, chỉ là một vài bản sao sử dụng chế độ cam kết đồng bộ và ở chế độ chuyển đổi dự phòng thủ công.
Ảnh chụp màn hình sau đây minh họa một cơ sở dữ liệu được gọi là “thử nghiệm”. Nó được thêm vào Nhóm luôn sẵn sàng của SQL Server và nó ở trạng thái được đồng bộ hóa.
Cách bật TDE trong SQL Server
Dưới đây là các bước để kích hoạt SQL Server TDE cho cơ sở dữ liệu "thử nghiệm". Lưu ý :chúng tôi sẽ thực hiện các bước sau trong Bản sao chính hiện tại.
Bước 1
Tạo khóa chính trong cơ sở dữ liệu chính.
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';
Bước 2
Tạo chứng chỉ được bảo vệ bằng khóa chính.
CREATE CERTIFICATE TestCertificate WITH SUBJECT = 'My test Certificate';Bước 3
Tạo Khóa mã hóa cơ sở dữ liệu (DEK) và bảo vệ nó bằng chứng chỉ được tạo ở Bước 2.
USE test;
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE TestCertificate;
Bước 4
Đặt cơ sở dữ liệu "kiểm tra" để sử dụng mã hóa.
ALTER DATABASE test
SET ENCRYPTION ON;
Cách Kiểm tra xem TDE đã được Bật chưa?
Sau khi hoàn tất, bạn cần xác nhận rằng Mã hóa dữ liệu minh bạch trong SQL Server đã được bật cho cơ sở dữ liệu "thử nghiệm".
Trong Thuộc tính cơ sở dữ liệu , đi tới Tùy chọn trang. Ở đó, hãy chú ý đến Trạng thái khu vực ở cuối cửa sổ. Đã bật mã hóa giá trị phải là True .
Bạn cũng có thể chạy mã TSQL sau để xác nhận nó:
SELECT name,is_encrypted
FROM sys.databases
WHERE name = 'test'
Vấn đề chứng nhận và quản lý khóa
Lưu ý: Đừng ngạc nhiên nếu bạn phát hiện ra rằng tempdb cũng được mã hóa. Đó là vì tempdb là nơi diễn ra tất cả các loại hoạt động (ví dụ:sắp xếp, tham gia băm, v.v.), sử dụng dữ liệu từ tất cả cơ sở dữ liệu. Do đó, nếu ít nhất một cơ sở dữ liệu người dùng được mã hóa, các hoạt động từ cơ sở dữ liệu cụ thể đó có thể đi vào tempdb và sẽ cần trả lại dữ liệu đó cho cơ sở dữ liệu người dùng. Do đó, việc gửi lại dữ liệu không được mã hóa sẽ thể hiện sự cố.
Bạn có thể đọc thêm về mã hóa sao lưu trong SQL Server để tăng cường bảo mật cho cơ sở dữ liệu của mình.
Bạn có thể sử dụng Mã TSQL sau để xác nhận rằng có một Khóa chính cơ sở dữ liệu cho cơ sở dữ liệu "thử nghiệm" được mã hóa bởi chứng chỉ (như được thực thi ở Bước 3):
SELECT
DB_NAME(database_id) AS DB,
create_date,
key_algorithm,
key_length,
encryptor_thumbprint,
encryptor_type
FROM sys.dm_database_encryption_keys
WHERE DB_NAME(database_id) = 'test'
Cho đến nay rất tốt, ít nhất là đối với Bản sao chính. Nhưng điều gì sẽ xảy ra nếu chúng tôi truy vấn sys.databases chế độ xem hệ thống để xác nhận trạng thái mã hóa của cơ sở dữ liệu “thử nghiệm” trong Bản sao thứ cấp?
Nhóm Khả dụng sao chép mọi thứ liên quan đến cơ sở dữ liệu từ bản sao này sang bản sao khác. Tuy nhiên, Bản sao phụ nói rõ rằng nó không được mã hóa.
Hãy kiểm tra Bản sao phụ của chúng tôi để biết bất kỳ manh mối nào về điều đó:
Trạng thái của cơ sở dữ liệu là “Không đồng bộ hóa / Nghi ngờ” - trông không đẹp chút nào. Tuy nhiên, sau khi kiểm tra Nhật ký Lỗi của Bản sao Phụ, tôi có thể thấy những điều sau:
2021-04-10 00:40:55.940 spid39s Error: 33111, Severity: 16, State: 3.
2021-04-10 00:40:55.940 spid39s Cannot find server certificate with thumbprint '0xDF36E3D052086AA05BBB1C64A72A2CAB5A98F240'.
2021-04-10 00:40:55.950 spid39s Error: 33111, Severity: 16, State: 3.
2021-04-10 00:40:55.950 spid39s Cannot find server certificate with thumbprint '0xDF36E3D052086AA05BBB1C64A72A2CAB5A98F240'.
2021-04-10 00:40:55.950 spid39s Always On Availability Groups data movement for database 'test' has been suspended for the following reason: "system" (Source ID 2; Source string: 'SUSPEND_FROM_REDO'). To resume data movement on the database, you will need to resume the database manually. For information about how to resume an availability database, see SQL Server Books Online.
2021-04-10 00:40:55.950 spid39s Error: 3313, Severity: 21, State: 2.
2021-04-10 00:40:55.950 spid39s During redoing of a logged operation in database 'test', an error occurred at log record ID (34:743:1). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database.
Vấn đề chính là chứng chỉ được sử dụng để mã hóa Khóa mã hóa cơ sở dữ liệu của cơ sở dữ liệu “thử nghiệm” (Bước 3) không có trong Bản sao phụ.
Tại sao?
Bởi vì Nhóm khả dụng không sao chép dữ liệu từ cơ sở dữ liệu hệ thống. Chứng chỉ máy chủ bị thiếu nằm trong cơ sở dữ liệu chính của Bản sao chính.
Cách kiểm tra và thiết lập chứng chỉ TDE trong SQL Server
Hãy tạo bản sao lưu chứng chỉ máy chủ trong cơ sở dữ liệu chính của Bản sao chính. Sau đó, hãy khôi phục nó trong cơ sở dữ liệu chính của Bản sao phụ.
Sử dụng mã TSQL sau để tạo bản sao lưu từ Bản sao chính hiện tại có cơ sở dữ liệu "thử nghiệm" với TDE được bật:
USE master;
GO
BACKUP CERTIFICATE TestCertificate
TO FILE = 'C:\temp\TestCertificate.cer'
WITH PRIVATE KEY (file='C:\temp\TestCertificate.pvk',
ENCRYPTION BY PASSWORD='<YourStrongPasswordHere>');
Trước khi cố gắng khôi phục chứng chỉ trong Bản sao phụ, trước tiên hãy kiểm tra xem Khóa chính của cơ sở dữ liệu có tồn tại trong cơ sở dữ liệu chính hay không. Nếu không, hãy tạo nó chính xác như ở Bước 1.
Sử dụng mã TSQL sau để khôi phục chứng chỉ trong Bản sao phụ. Lưu ý :Đảm bảo sao chép các tệp .cer và .pvk vào thư mục đích trước.
USE master;
GO
CREATE CERTIFICATE TestCertificate
FROM FILE = 'C:\temp\TestCertificate.cer'
WITH PRIVATE KEY (
FILE = N'C:\temp\TestCertificate.pvk',
DECRYPTION BY PASSWORD = '<YourStrongPasswordHere>'
);
Do đó, ngay cả sau khi khôi phục chứng chỉ trong Bản sao thứ cấp, trạng thái của cơ sở dữ liệu “thử nghiệm” vẫn như cũ:
Vì quá trình di chuyển dữ liệu cho cơ sở dữ liệu "thử nghiệm" bị tạm dừng, hãy tiếp tục theo cách thủ công để xem lần này chúng ta có may mắn không:
Đúng! Hoạt động thành công. Cơ sở dữ liệu "thử nghiệm" không chỉ được đồng bộ hóa hoàn toàn và khỏe mạnh mà còn được mã hóa bằng TDE.
Bên cạnh đó, sau khi thực hiện chuyển đổi dự phòng thủ công để hoán đổi vai trò của các bản sao, mọi thứ tiếp tục hoạt động hoàn toàn tốt.
Kết luận
Giải pháp được trưng bày hoạt động hoàn toàn tốt. Tuy nhiên, nó có thể không phải là lý tưởng trong mọi trường hợp, đặc biệt nếu bạn là một DBA, người thích lập kế hoạch và làm mọi việc theo cách “đúng đắn”. Tôi thấy "đúng" như sau:
- Xóa cơ sở dữ liệu khỏi Nhóm Khả dụng
- Thực hiện tất cả các bước để bật Mã hóa dữ liệu minh bạch trong bản sao nơi cơ sở dữ liệu được đọc / ghi.
- Sao lưu chứng chỉ máy chủ từ Bản sao Chính.
- Sao chép tệp sao lưu vào (các) vị trí của (các) Bản sao phụ.
- Khôi phục chứng chỉ trong cơ sở dữ liệu chính.
- Thêm lại cơ sở dữ liệu vào Nhóm Khả dụng.
- Đảm bảo rằng trạng thái hoạt động của cơ sở dữ liệu là chính xác và đúng mục đích (tùy thuộc vào thiết lập cụ thể của bạn).
Tôi đang ném dấu ngoặc kép cho "đúng" vì theo cách tôi trình bày giải pháp, tôi đã nhận được cơ sở dữ liệu trong Bản sao phụ được đánh dấu là Nghi ngờ. Chỉ riêng điều này có thể sẽ làm dấy lên nhiều cờ / cảnh báo / chỉ tay không mong muốn. Bạn có thể dễ dàng tránh được tiếng ồn không cần thiết bằng cách tính đến tất cả các cân nhắc để lập kế hoạch và triển khai TDE đúng cách trong thiết lập Nhóm Luôn sẵn sàng.
Để kết thúc bài đăng này, tôi gửi cho bạn Hệ thống phân cấp mã hóa chính thức được sử dụng cho TDE mà Microsoft đã đăng trên trang web của họ. Điều tôi muốn bạn lưu ý là nơi mỗi phần tử được tạo (trong cơ sở dữ liệu chính hoặc cơ sở dữ liệu người dùng), để bạn có thể khắc phục mọi sự cố / bất ngờ tiềm ẩn với Nhóm khả dụng.
Trong trường hợp bạn không biết, SQL Complete có thể hỗ trợ bạn rất nhiều trong việc định cấu hình Luôn được mã hóa, đây là một công nghệ hữu ích khác để bảo vệ dữ liệu nhạy cảm.
Hãy nhớ rằng bạn sẽ cần phải xem xét điều tương tự được thảo luận trong bài viết này nếu bạn đang có kế hoạch xử lý tình huống Luôn được mã hóa trong một nhóm Luôn sẵn sàng. Tuy nhiên, các tính năng mà SQL Complete v6.7 giới thiệu được thiết kế để đảm bảo rằng bạn thành công ngay lập tức.
