在 SQL Server 2016 中结合始终加密和列级加密

Question

我们有使用 SQL Server 2016 加密敏感列数据的要求，并选择了 Always Encrypted(AE) 功能来使用确定性方法加密这些列。

由于 AE 确定性加密不允许对这些加密列进行不等式、范围或 LIKE 查询，因此我们尝试使用对称密钥（列级）加密技术对这些类型的列进行加密。

在某些列（不需要任何不等式、范围或 LIKE 查询）上实现 AE 功能并在需要生成不等式、范围或 LIKE 查询的列上实现对称密钥类型加密是否是一个好习惯？

考虑到性能、安全性和维护性，将 AE 加密和列级加密结合在一个表上是一个好习惯吗？

请专家指教。

Answer 1

我还没有遇到关于 SQL Server 多种加密类型的明确“最佳实践”列表，但在您的情况下，我可能会推荐以下内容：

1. 使用 Always Encrypt 加密必要的数据
   • 它的新热点。你在2016年，享受它！
   • 更好的安全性 - DBA 无法解密数据，因为密钥存储在数据库之外。
   • 更多用于调整单个查询和减少功能性能影响的选项。
   • 最容易在数据库和应用程序端实现（除非 TDE 是一个选项），因为您只需要配置驱动程序参数而不是像列级加密那样更改查询。
   • 额外的解密负载成为应用程序（特别是驱动程序）的问题（作为 DBA 对我来说很好）。
   • 此功能可能会在一段时间内得到改进和优化，因为它是一个新功能（我认为）。
2. 对于需要搜索的列，创建一个哈希值来进行查找。
   • 维护数据的安全性，但对于查找非常有效。它允许您在普通行上进行搜索，而无需解密每一行或默认为表扫描的开销。如果需要，您可以对其进行索引以获得进一步的性能。
     • 您的应用程序将接受用户输入并对其进行哈希处理，然后使用该哈希值查询存储在表中的哈希版本。此查找将很快，并且将允许您仅解密所需的行，而不是解密您实际上不希望作为结果集一部分的行。
   • 其设计取决于您需要查找多少列以及您是否在WHERE子句中使用多个或单个列。
   • 只要您负担得起，额外的空间对于性能来说是值得的。
3. 不要打扰使用列级加密
   • 您必须解密整个列才能进行搜索，这比未加密的哈希列效率低。这意味着您的表越大，此方法的效率就越低。100 万行意味着即使您的过滤器只返回 1 行，您也必须花费 CPU 来解密一百万行。仅仅因为您可以执行搜索并不意味着它将是高性能的。
   • 我可以看到同一个表中的两个加密功能的长期维护令人困惑并且充其量成为部落知识。

您也可以使用列级加密实现 #2，但没有任何限制，我不明白为什么您通常会选择 CLE 而不是 Always Encrypted。

我开玩笑说要对应用程序的问题进行加密，但我发现数据库经常背负着比大多数情况下更多的业务逻辑和古怪的功能。如果可以选择将某些计算推回到应用程序端，我发现这通常是最好的选择，有助于防止故障排除和一般调整成为一场噩梦。

当然，您应该对替代方案进行全面测试。如果您发现 CLE 或组合最适合您的特定场景，就这样吧。

补充阅读：

• 始终加密的性能- Aaron Bertrand
• 始终加密的性能 - 后续- Aaron Bertrand
• 列级加密开销- Dallas Snyder
• Always Encrypted（数据库引擎）（官方文档登陆页面）