在不牺牲查询性能的情况下加密数据

信息安全 加密
2021-09-03 07:53:53

我们正在构建一个由多租户数据库支持的云 Web 应用程序。为了最大限度地提高安全性,我们计划使用单独的密钥加密每个客户的数据。问题是查询。假设他们在报表编写器中并希望按姓氏对他们的 1,000,000 客户表进行排序。这将执行得非常糟糕,因为所有 1M 行都必须不加密,然后在每个查询中进行排序!

这是我能想到的唯一选择。你会怎么做?还有其他选择吗?

  1. 只加密数据库中的 NPI 列,然后永远不允许它们按 NPI 值排序或过滤。

    PRO:保护敏感数据,同时在非 NPI 列上仍提供出色的查询性能

    缺点:对我们的用户来说不是一个很好的用户体验

  2. 与 #1 相同,但在 RAM 中保留未加密的 NPI 列缓存

    PRO:更好的用户体验

    CON:现在 DataInUse 是未加密的(这比未加密的 DataAtRest 更好吗??)。此外,具有 NPI 和非 NPI 列的过滤器的编码会非常难看。例如,如果过滤器是 SELECT ALL CUSTOMERS WHERE LASTNAME LIKE "S%" AND BIZTYPE="MEDICAL",则 lastname 记录 ID 必须首先来自缓存,然后发送到数据库以进一步限制 biztype 的记录。

  3. 放弃并保留数据库中未加密的所有数据,并应用 db 加密 (SQLServer TDE) 或磁盘加密。

    PRO:出色的用户体验和性能

    CON:性能会受到影响。此外,如果密钥被泄露,我们所有客户的数据都会暴露出来,我们就会登上《华尔街日报》的封面。

3个回答

问题是您的解决方案:

“为了最大限度地提高安全性,我们计划使用单独的密钥加密每个客户的数据。”

别那样做。为每个客户使用单独的密钥不会扩展。对整个数据库使用单个键。

或者,在将数据插入数据库之前使用硬件安全模块 (HSM) 对数据进行加密。检索加密数据,然后使用硬件安全模块解密。查询性能不会受到影响。性能瓶颈现在转移到硬件安全模块。

您是否考虑过对要索引的数据进行散列处理?

这个想法很简单。您在 LastName 列旁边添加一列,用于存储 LastName 的盐渍/胡椒散列。当服务器需要寻找史密斯先生时,您只需对姓名史密斯进行哈希处理,然后搜索该哈希值。

这种方法的问题是可以从哈希中获取有关数据库的信息。

变体建议:

  1. 为每个加载的新客户创建一个新的 ID 记录
  2. 加密 SSN
  3. 仅使用新 id 来选择/检索

PRO:保持性能,SSN 加密
CON:为用户记住一个新 ID