Tôi vẫn chưa bắt gặp một danh sách "Thực tiễn tốt nhất" dứt khoát liên quan đến nhiều loại mã hóa cho SQL Server, nhưng trong tình huống của bạn, tôi có thể khuyên bạn nên như sau:
- Mã hóa dữ liệu cần thiết bằng cách sử dụng Luôn mã hóa
- Đó là sự nóng bỏng mới. Bạn đang trên 2016, hãy tận hưởng nó!
- Bảo mật tốt hơn - DBA không thể giải mã dữ liệu do khóa được lưu trữ bên ngoài cơ sở dữ liệu.
- Thêm tùy chọn để điều chỉnh các truy vấn riêng lẻ và giảm hiệu suất của tính năng.
- Dễ dàng thực hiện nhất trên cả cơ sở dữ liệu và ứng dụng (trừ khi TDE là một tùy chọn) vì bạn chỉ phải định cấu hình các tham số trình điều khiển so với thay đổi truy vấn của mình như với Mã hóa mức cột.
- Tải giải mã bổ sung trở thành vấn đề của ứng dụng (cụ thể là trình điều khiển) (tốt đối với tôi là DBA).
- Tính năng này có thể sẽ được cải thiện và tối ưu hóa trong một thời gian vì nó là một tính năng mới (theo ý kiến của tôi).
- Đối với các cột bạn cần tìm kiếm, hãy tạo một giá trị băm để thực hiện tra cứu.
- Duy trì bảo mật dữ liệu nhưng rất hiệu quả cho việc tra cứu. Nó cho phép bạn có hiệu suất tìm kiếm trên một hàng bình thường mà không cần phải giải mã mọi hàng hoặc mặc định để quét bảng. Bạn có thể lập chỉ mục cho hiệu suất cao hơn nếu muốn.
- Ứng dụng của bạn sẽ lấy đầu vào của người dùng và băm nó, sau đó sử dụng giá trị băm đó để truy vấn phiên bản băm được lưu trữ trong bảng. Việc tra cứu này sẽ nhanh chóng và sẽ cho phép bạn chỉ giải mã (các) hàng mong muốn so với giải mã các hàng bạn không thực sự muốn như một phần của tập kết quả.
- Thiết kế này phụ thuộc vào số lượng cột bạn cần tra cứu và nếu bạn đang sử dụng nhiều cột hoặc từng cột trong
WHEREmệnh đề của mình .
- Không gian thêm là giá trị nó cho hiệu suất miễn là bạn có thể đủ khả năng.
- Đừng bận tâm sử dụng Mã hóa cấp cột
- Bạn sẽ phải giải mã toàn bộ cột để thực hiện tìm kiếm, việc này sẽ kém hiệu quả hơn cột băm không được mã hóa. Điều này có nghĩa là bảng của bạn càng lớn, phương thức này càng kém hiệu quả. 1 triệu hàng có nghĩa là bạn phải dành CPU để giải mã một triệu hàng ngay cả khi bộ lọc của bạn chỉ trả về 1 hàng. Chỉ vì bạn có thể thực hiện tìm kiếm không có nghĩa là nó sẽ được thực hiện.
- Tôi có thể thấy việc bảo trì dài hạn hai tính năng mã hóa trong cùng một bảng là khó hiểu và trở thành kiến thức bộ lạc tốt nhất.
Bạn cũng có thể triển khai # 2 với Mã hóa cấp cột, nhưng không có bất kỳ ràng buộc nào, tôi không thể hiểu tại sao bạn lại chọn CLE trên Luôn được mã hóa nói chung.
Tôi nói đùa về việc mã hóa vấn đề của ứng dụng, nhưng tôi thấy rằng cơ sở dữ liệu thường được cài đặt với nhiều chức năng logic và lập dị hơn so với hầu hết các trường hợp. Nếu có một tùy chọn để đẩy một số tính toán trở lại phía ứng dụng, tôi đã thấy đó thường là lựa chọn tốt nhất và giúp ngăn sự cố và điều chỉnh chung trở thành một cơn ác mộng.
Tất nhiên bạn nên kiểm tra đầy đủ các lựa chọn thay thế. Nếu bạn tìm thấy CLE, hoặc một kết hợp, hoạt động tốt nhất cho kịch bản cụ thể của bạn, vì vậy hãy là nó.
Đọc thêm: