按行加密SQL Server 2016

Question

是否可以使用Always Encrypted功能以及SQL Server 2016中的行級安全功能？並以某種方式加密具有不同EncryptionKeys相對於特定用戶要查看的行的行？

Answer 1

這有幫助。簡短的回答，今天不能輕鬆地使用AE & RLS。

AE目前是列作用域;您使用特定的列加密密鑰（CEK）加密整個列。您可以對錶中的多個列進行加密，每個列都有自己的CEK，但它仍然是列作用域。您無法在邏輯上對行進行分組，並使用當前的AE實現使用自己的密鑰對它們進行加密。如果這對你來說非常重要，你可以通過https://connect.microsoft.com/SQLServer/feedback/

向團隊提出建議。也就是說，除了滿足一些法規或公司政策要求外，您從目前的建議設計中獲益不多。除非您的用戶（或用戶組）數量非常少，因此只有極少數的行組，否則您很快會遇到CEK擴散。管理起來並不困難，但仍然乏味且可能需要很多工作。例如，每個用戶或一組用戶需要他們自己的密鑰或祕密來訪問推送到他們的應用或工作站的密鑰。複雜性和/或許多移動部件意味着更多的失敗風險。此外，在審覈季節期間它可能會更加「有趣」（當然取決於您的審覈員）。

如果我可以重申你的目標，你要確保 1.數據始終是未經授權的眼睛安全 2.授權用戶只允許看他們有權查看

正確實施，AE數據符合＃1的要求。沒有密鑰，你看到的只是密文。當然，你可以強制它或者在加密算法或SQL Server的實現中發現缺陷，但是比FAR，FAR更容易比好萊塢希望我們相信的方式。

在大多數情況下，RLS確實地址爲＃2。實現在查詢處理器級別，因此規避RLS非常困難;在RLS中必須有一個可能的錯誤。如果您的RLS過濾器基於非加密列（實際上應該是），那麼除非您的客戶受到威脅，否則別人甚至不可能從內存/網絡中嗅出您的祕密。

因此，即使您只有1 CEK，這兩項要求都得到滿足。這使得您的生活在長期內更容易，並且管理的表面面積更小。這幾乎總是會導致更安全的環境。使用單獨的密鑰爲您提供了一個附加層，這對於縱深防禦非常有用，但在實踐中，您的努力在其他領域（例如警報，用戶教育等）將產生更多效果。