Sql-Server
在 SQL Server 2016 中結合始終加密和列級加密
我們要求使用 SQL Server 2016 加密敏感列數據，並選擇始終加密 (AE) 功能來使用確定性方法加密這些列。
由於 AE 確定性加密不允許對這些加密列進行不等式、範圍或 LIKE 查詢，因此我們嘗試使用對稱密鑰（列級）加密技術對這些類型的列進行加密。
在某些列（不需要任何不等式、範圍或 LIKE 查詢）上實現 AE 功能並在需要生成不等式、範圍或 LIKE 查詢的列上實現對稱密鑰類型加密是一種好習慣嗎？
考慮到性能、安全性和維護，將 AE 加密和列級加密結合在一個表上是否是一種好習慣？
請高手指教。
我還沒有遇到關於 SQL Server 的多種加密類型的明確“最佳實踐”列表，但在您的情況下，我可能會推薦以下內容：
- 使用 Always Encrypt 加密必要的數據
- 它的新熱點。你在 2016 年，享受它！
- 更好的安全性 - DBA 無法解密數據，因為密鑰儲存在數據庫之外。
- 用於調整單個查詢和減少功能性能影響的更多選項。
- 最容易在數據庫和應用程序端實現（除非 TDE 是一個選項），因為您只需配置驅動程序參數，而不是像使用列級加密那樣更改查詢。
- 額外的解密負載成為應用程序（特別是驅動程序）的問題（對於作為 DBA 的我來說很好）。
- 這個功能很可能會改進和優化一段時間，因為它是一個新的（我的觀點）。
- 對於您需要搜尋的列，創建一個雜湊值以進行查找。
維護數據的安全性，但對於查找非常有效。它允許您在正常行上進行搜尋，而無需解密每一行或預設為表掃描的成本。如果需要，您可以索引它以獲得進一步的性能。
- 您的應用程序將獲取使用者輸入並對其進行雜湊處理，然後使用該雜湊值來查詢儲存在表中的雜湊版本。此查找速度很快，並且只允許您解密所需的行，而不是解密您實際上不希望作為結果集一部分的行。
其設計取決於您需要查找多少列，以及您在
WHERE子句中是否使用多個或單獨的列。只要您負擔得起，額外的空間對於性能來說是值得的。
- 不要打擾使用列級加密
- 您必須解密整個列才能進行搜尋，這比未加密的雜湊列效率低。這意味著您的表越大，此方法的效率就越低。100 萬行意味著您必須花費 CPU 來解密一百萬行，即使您的過濾器只返回 1 行。僅僅因為您可以執行搜尋並不意味著它將是高效的。
- 我可以看到在同一張表中長期維護兩個加密功能令人困惑，並且充其量只是部落知識。
您也可以使用列級加密來實現#2，但是如果沒有任何限制，我不明白為什麼您通常會選擇 CLE 而不是 Always Encrypted。
我開玩笑說讓加密成為應用程序的問題，但我發現數據庫經常背負著比大多數情況下更多的業務邏輯和古怪的功能。如果有一個選項可以將一些計算推回應用程序端，我發現這通常是最好的選項，並且有助於防止故障排除和一般調整成為一場噩夢。
當然，您應該全面測試替代方案。如果您發現 CLE 或組合最適合您的特定場景，那就這樣吧。
補充閱讀：
- 始終加密的性能- Aaron Bertrand
- 始終加密的性能 - 後續行動- Aaron Bertrand
- 列級加密成本- Dallas Snyder
- Always Encrypted（數據庫引擎）（官方文件登錄頁面）