按行加密SQL Server 2016
是否可以使用Always Encrypted功能以及SQL Server 2016中的行级安全功能？并以某种方式加密具有不同EncryptionKeys相对于特定用户要查看的行的行？按行加密SQL Server 2016
这有帮助。简短的回答，今天不能轻松地使用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，这两项要求都得到满足。这使得您的生活在长期内更容易，并且管理的表面面积更小。这几乎总是会导致更安全的环境。使用单独的密钥为您提供了一个附加层，这对于纵深防御非常有用，但在实践中，您的努力在其他领域（例如警报，用户教育等）将产生更多效果。
你的目标究竟是什么？始终加密和行级安全是完全不同的事情。 RLS根据您的过滤器函数过滤结果集，以便user_x仅查看他允许查看的数据。 RLS不加密用户数据。 AE将加密用户数据。无论RLS如何返回给用户，没有密钥，用户都会看到密文。当一起使用时，您需要小心如何编写RLS功能。如果取决于加密某些AE列，您的应用程序性能可能会受到影响。如果它没有，那么它将与通常的AE开销和限制一起工作 – SQLmojoe
@SQLmojoe：我的目标就像...如果用户A有一些行，并且用户B有一些其他行......有了RLS，我们可以确保A只看到AR和B只看到BROW。但是我的目标是用A对A进行加密，并将B用数据库中的B用不同的密钥加密。 –