cloud - 逐行加密 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 的实现中找到缺陷，但有远比好莱坞希望我们相信的更简单的方法。

在大多数情况下，RLS 确实解决了 #2。实现是在查询处理器级别，因此绕过 RLS 非常困难；RLS 中必须有一个错误才能实现。如果您的 RLS 过滤器基于未加密的列（确实应该如此），那么除非您的客户端受到威胁，否则有人甚至不可能从内存/网络中嗅出您的秘密。

因此，即使您只有 1 个 CEK，这两个要求都可以满足。从长远来看，这使您的生活更轻松，管理的表面积更小。这几乎总能带来更安全的环境。拥有单独的密钥可以为您购买一个额外的层，这在纸面上非常适合深度防御，但在实践中，您的努力将在其他领域（例如警报、用户教育等）产生更多收益。