Microsoft có một số tính năng bảo mật trong SQL Server 2017 hữu ích cho các mục đích khác nhau, tùy thuộc vào những gì bạn đang cố gắng bảo vệ và (các) mối đe dọa mà bạn đang cố gắng chống lại. Một số tính năng bảo mật này có thể có các tác động về hiệu suất mà bạn nên biết khi quyết định tính năng nào bạn muốn triển khai. Như phần giới thiệu, tôi sẽ trình bày một số điểm nổi bật của một số tính năng bảo mật này.
Mã hóa cơ sở dữ liệu minh bạch (TDE)
Mã hóa dữ liệu minh bạch (TDE) là hình thức mã hóa của SQL Server, có nghĩa là các tệp dữ liệu, tệp nhật ký, tệp tempdb và các bản sao lưu toàn bộ, phân biệt và nhật ký SQL Server của bạn sẽ được mã hóa khi bạn bật TDE trên cơ sở dữ liệu người dùng . Điều này bảo vệ dữ liệu của bạn khỏi ai đó có quyền truy cập vào cơ sở dữ liệu đó hoặc các tệp sao lưu cơ sở dữ liệu miễn là người đó cũng không có quyền truy cập vào các chứng chỉ và khóa mã hóa của bạn.
Quá trình quét mã hóa TDE ban đầu cho cơ sở dữ liệu người dùng sẽ sử dụng một luồng CPU nền cho mỗi tệp dữ liệu trong cơ sở dữ liệu (nếu tệp dữ liệu nằm trên các ổ đĩa logic riêng biệt), để đọc từ từ toàn bộ nội dung của tệp dữ liệu vào bộ nhớ với tốc độ khoảng 52MB / giây cho mỗi tệp dữ liệu (nếu tệp dữ liệu nằm trên các ổ đĩa logic riêng biệt).
Sau đó, dữ liệu được mã hóa bằng thuật toán mã hóa đã chọn của bạn và sau đó được ghi lại vào tệp dữ liệu với tốc độ khoảng 55MB / giây (trên mỗi tệp dữ liệu, nếu chúng nằm trên các ổ đĩa logic riêng biệt). Các tốc độ đọc và ghi tuần tự này dường như được điều chỉnh một cách có chủ đích và nhất quán trong thử nghiệm của tôi trên nhiều hệ thống với nhiều loại lưu trữ khác nhau.
Quá trình mã hóa TDE ban đầu xảy ra ở cấp độ trang, bên dưới SQL Server, vì vậy nó không gây ra khóa hoặc tạo hoạt động nhật ký giao dịch như bạn sẽ thấy khi xây dựng lại chỉ mục. Bạn có thể tạm dừng quét mã hóa TDE bằng cách bật TF 5004 toàn cầu và hủy tạm dừng nó bằng cách tắt TF 5004 và chạy lại lệnh ALTER DATABASE dbNAME SET ENCRYTION ON mà không bị mất tiến trình.
Tác động của CPU khi mã hóa / giải mã sẽ giảm đáng kể trên SQL Server 2016 và phiên bản mới hơn nếu bạn có bộ xử lý hỗ trợ hướng dẫn phần cứng AES-NI. Trong không gian máy chủ, chúng được giới thiệu trong dòng sản phẩm Intel Xeon 5600 (Westmere-EP) dành cho máy chủ hai ổ cắm và dòng sản phẩm Intel Xeon E7-4800 / 8800 (Westmere-EX) dành cho máy chủ bốn và tám ổ cắm. Bất kỳ dòng sản phẩm Intel nào mới hơn cũng sẽ có hỗ trợ AES-NI. Nếu bạn nghi ngờ về việc liệu bộ xử lý của mình có hỗ trợ AES-NI hay không, bạn có thể tìm “AES” trong đầu ra trường hướng dẫn từ CPU-Z, như bạn thấy trong Hình 1.
Hình 1:Đầu ra CPU-Z hiển thị Hỗ trợ hướng dẫn AES
Sau khi bạn đã mã hóa cơ sở dữ liệu bằng TDE, tác động thời gian chạy của TDE khó có thể định lượng được vì nó hoàn toàn phụ thuộc vào khối lượng công việc của bạn. Ví dụ:nếu khối lượng công việc của bạn hoàn toàn nằm trong vùng đệm của SQL Server thì về cơ bản sẽ không có chi phí nào từ TDE. Mặt khác, nếu khối lượng công việc của bạn chỉ bao gồm quét bảng, nơi trang được đọc và sau đó xóa gần như ngay lập tức, điều đó sẽ áp dụng hình phạt tối đa. Hình phạt tối đa đối với khối lượng công việc biến động I / O thường dưới 5% với phần cứng hiện đại và với SQL Server 2016 trở lên.
Công việc bổ sung của giải mã TDE xảy ra khi bạn đọc dữ liệu vào vùng đệm từ bộ lưu trữ và công việc bổ sung của mã hóa TDE xảy ra khi bạn ghi dữ liệu trở lại bộ nhớ. Đảm bảo rằng bạn không bị áp lực bộ nhớ, bằng cách có một vùng đệm đủ lớn và bằng cách thực hiện điều chỉnh chỉ mục và truy vấn rõ ràng sẽ làm giảm tác động hiệu suất của TDE. TDE không mã hóa dữ liệu FILESTREAM và cơ sở dữ liệu được mã hóa TDE sẽ không sử dụng tính năng khởi tạo tệp tức thì cho các tệp dữ liệu của nó.
Trước SQL Server 2016, TDE và nén sao lưu gốc không hoạt động tốt cùng nhau. Với SQL Server 2016 trở lên, bạn có thể sử dụng TDE và nén sao lưu gốc cùng nhau miễn là bạn chỉ định MAXTRANSFERSIZE lớn hơn 64K trong lệnh sao lưu. Điều rất quan trọng là bạn phải cập nhật các bản cập nhật tích lũy của mình, vì đã có nhiều bản sửa lỗi quan trọng liên quan đến TDE cho cả SQL Server 2016 và SQL Server 2017. Cuối cùng, TDE vẫn là tính năng chỉ dành cho Phiên bản Doanh nghiệp, ngay cả sau SQL Server 2016 SP1 (đã thêm nhiều tính năng chỉ dành cho Doanh nghiệp vào Standard Edition).
Bảo mật cấp hàng (RLS)
Bảo mật cấp độ hàng (RLS) giới hạn quyền truy cập đọc và hầu hết quyền truy cập cấp độ ghi dựa trên các thuộc tính của người dùng. RLS sử dụng cái được gọi là kiểm soát truy cập dựa trên vị từ. SQL Server áp dụng các giới hạn truy cập trong tầng cơ sở dữ liệu và chúng sẽ được áp dụng mỗi khi cố gắng truy cập dữ liệu từ bất kỳ tầng nào.
RLS hoạt động bằng cách tạo một hàm vị từ giới hạn các hàng mà người dùng có thể truy cập, sau đó sử dụng chính sách bảo mật và vị từ bảo mật để áp dụng hàm đó cho bảng.
Có hai loại vị từ bảo mật, đó là vị từ bộ lọc và vị từ khối. Các vị từ bộ lọc sẽ lọc âm thầm các hàng có sẵn để đọc các thao tác (CHỌN, CẬP NHẬT và XÓA), bằng cách thêm mệnh đề WHERE về cơ bản ngăn không cho các hàng được lọc hiển thị trong tập kết quả. Vị ngữ bộ lọc được áp dụng trong khi đọc dữ liệu từ bảng cơ sở và người dùng hoặc ứng dụng sẽ không biết rằng các hàng đang được lọc khỏi kết quả. Từ góc độ hiệu suất, điều quan trọng là phải có một chỉ mục lưu trữ hàng bao gồm vị từ bộ lọc RLS của bạn.
Chặn vị từ một cách rõ ràng, (có thông báo lỗi) chặn các hoạt động ghi (SAU KHI CHÈN, SAU KHI CẬP NHẬT, TRƯỚC KHI CẬP NHẬT và TRƯỚC KHI XÓA) sẽ vi phạm vị từ khối.
Các vị từ bộ lọc và khối được tạo dưới dạng các hàm có giá trị bảng nội tuyến. Bạn cũng sẽ cần sử dụng câu lệnh T-SQL TẠO CHÍNH SÁCH BẢO MẬT để áp dụng và bật chức năng lọc cho bảng cơ sở có liên quan
RLS đã được thêm vào SQL Server 2016 và có sẵn trong tất cả các phiên bản của SQL Server 2016 và mới hơn. RLS sẽ không hoạt động với các chế độ xem Filestream, Polybase và được lập chỉ mục. RLS có thể ảnh hưởng đến hiệu suất của Tìm kiếm toàn văn bản và nó có thể buộc các truy vấn lập chỉ mục cột phải kết thúc bằng cách sử dụng chế độ hàng thay vì chế độ hàng loạt. Bài đăng trên blog này của Microsoft có thêm thông tin về tác động hiệu suất của RLS. Đây là một ví dụ điển hình về cách sử dụng Query Store để điều chỉnh hiệu suất RLS.
Mặt nạ dữ liệu động (DDM)
Mặt nạ dữ liệu động (DDM) có thể giúp hạn chế hiển thị dữ liệu nhạy cảm bằng cách che nó cho người dùng không có đặc quyền. DDM được áp dụng ở cấp bảng, do đó, tất cả các truy vấn đều bị ảnh hưởng bởi việc tạo mặt nạ dữ liệu, trong khi các quy tắc tạo mặt nạ thực tế được áp dụng trong các cột riêng lẻ trong bảng.
Có bốn loại mặt nạ dữ liệu mà bạn có thể sử dụng, bao gồm mặc định, email, chuỗi tùy chỉnh và ngẫu nhiên. Mặt nạ mặc định cung cấp mặt nạ mặc định đầy đủ của dữ liệu tùy thuộc vào kiểu dữ liệu. Ví dụ:kiểu dữ liệu chuỗi sẽ nhận được mặt nạ là ‘XXXX’ thay vì dữ liệu thực. Mặt nạ email sẽ trả về chữ cái đầu tiên của địa chỉ email thực, theo sau là [email protected], bất kể hậu tố tên miền thực tế là gì. Mặt nạ chuỗi tùy chỉnh sẽ hiển thị các chữ cái đầu tiên và cuối cùng của chuỗi, với một phần đệm tùy chỉnh ở giữa. Cuối cùng, một mặt nạ ngẫu nhiên được sử dụng để che dữ liệu số và cung cấp một giá trị ngẫu nhiên trong một phạm vi xác định. Mặt nạ dữ liệu có thể được tạo trong câu lệnh CREATE TABLE hoặc bằng câu lệnh ALTER COLUMN.
Tạo mặt nạ dữ liệu động không cung cấp mặt nạ cho những người dùng có đặc quyền vẫn có thể truy vấn trực tiếp các bảng của bạn và xem dữ liệu được che mặt. Không thể sử dụng quy tắc tạo mặt nạ với các cột được mã hóa (Luôn được mã hóa), các cột được tính toán hoặc với dữ liệu Filestream. Nếu có các chỉ mục hiện có trên một cột mà bạn muốn che dấu, bạn sẽ phải bỏ chỉ mục, tạo mặt nạ trên cột, rồi tạo lại chỉ mục. Cũng có thể suy ra các giá trị cho các cột dữ liệu được che bằng cách viết các truy vấn cho phép người dùng cuối cùng đoán giá trị cho một cột được che.
Mặt nạ dữ liệu động đã được giới thiệu trong SQL Server 2016 và nó có sẵn trong tất cả các phiên bản của SQL Server. DDM không có nghĩa là một biện pháp bảo mật mạnh mẽ như mã hóa thực tế, nhưng mặt khác, tác động hiệu suất của nó dường như khá đáng kể.
