逐行加密 SQL Server 2016答案

【问题标题】：Row-wise encryption SQL Server 2016逐行加密 SQL Server 2016
【发布时间】：2015-11-17 16:25:03
【问题描述】：

是否可以使用 Always Encrypted 功能和 SQL Server 2016 中的行级安全功能？并以某种方式对特定用户要查看的行使用不同的 EncryptionKeys 加密行？

【问题讨论】：

您的目标到底是什么？始终加密和行级安全是完全不同的东西。 RLS 根据您的过滤函数过滤结果集，因此 user_x 只能看到他被允许查看的数据。 RLS 不加密用户数据。 AE 将加密用户数据。不管 RLS 返回给用户什么，没有密钥，用户看到的只是密文。一起使用时，需要注意如何编写 RLS 函数。如果它依赖于加密的某些 AE 列，您的应用程序性能可能会受到影响。如果没有，那么它将使用通常的 AE 开销和限制
@SQLmojoe：我的目标是......如果用户 A 有一些行，而用户 B 有一些其他行......使用 RLS，我们可以确保 A 只看到 ARows 而 B 只看到 BRows .但我的目标是，ARows 由 A 使用密钥加密，BRows 由 B 在数据库中使用不同的密钥加密。

标签： cloud sql-server-2016

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

【讨论】：