是否可以在SQL Server 2016中使用"始终加密"功能和行级安全功能？对于特定用户要查看的行，以某种方式使用不同的EncryptionKey对行进行加密？
这很有帮助。简短的回答，今天用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，也可以满足这两个要求。从长远来看，这会让你的生活变得更轻松，需要管理的表面积更小。这几乎总是会带来一个更安全的环境。拥有单独的密钥可以为您增加一层，这在纸面上非常适合深度防御，但在实践中，您的努力将在其他领域产生更多效果（例如警报、用户教育等）。