我们正在考虑对敏感数据使用 SQL Server 列（单元格）级加密。当我们最初加密列时应该没有问题，但我们要求每年更改加密密钥。看来这个要求可能会有问题。
假设：包含敏感数据的列的表将有 5 亿条记录。
以下是我们考虑实施的步骤。加密/解密过程中数据是否在线，以及这个过程需要多长时间？
- 最初加密列
- 新年
- 解密列
- 使用新密钥加密该列。
问题：当列被解密/加密时，数据是否在线（可供查询）？ SQL Server 是否提供允许在数据在线时更改密钥的功能？
巴德
答案1
重新加密静态数据的成本将非常高。要更新的 5 亿条记录将生成大量日志，大量的数据 IO，将持续数小时甚至数天，总体而言将非常混乱。更不用说操作错误可能会导致整个数据库完全加密（即没有密钥来解密）。
我建议将密钥在密钥层次结构中轮换到更高的位置：
- 使用对称密钥加密数据。
- 定期更改对称密钥，例如每周生成一个新密钥，使用新密钥加密新数据，但不要更改旧数据
- 使用证书加密对称密钥
- 使用DECRYPTBYKEYAUTOCERT解密数据，它将自动选择正确的对称密钥
- 必要时，轮换加密对称密钥的证书。对称密钥支持多证书加密，因此完全可以添加新证书，用新证书加密所有对称密钥，然后删除旧证书
大型公司经常部署类似的方案。由于成本太高，因此很少重新加密所有数据。使用多个对称密钥并时常生成新密钥将减少对称密钥被泄露时可能造成的隐私损失。轮换用于解密对称密钥的证书可以减轻证书泄露的风险，因为被泄露的证书在轮换后将无法访问数据，即使数据仍使用相同的旧对称密钥加密。
确实，我可以设想这样一种攻击：如果我有权访问证书，我就可以提取所有对称密钥材料，然后在证书轮换时，理论上我可以使用保存的密钥材料解密数据（使用 SQL Server 以外的方法）。但这与说“如果我有权访问轮换之前的受损证书，我就可以解密所有数据并保存解密的数据”没有什么不同，这让攻击有了新的视角，因为事后密钥轮换再多也无法恢复攻击者已经丢失的数据。
答案2
您当然可以编写一个应用程序来执行解密/加密（SELECT数据输出，解密，使用新密钥重新加密并UPDATE重新输入 - 敏感数据永远不会以这种方式以未加密的形式存储），但是您正在创建一个巨大的每年密钥轮换的开销量只会随着数据库的增长而增加。还有一个问题是，必须在重新加密过程中保留两个密钥（现在可能是一个小时，明年可能几天，这取决于您的增长率和加密复杂性……）
您可能想要评估年度变更要求背后的业务/安全逻辑，看看是否可以通过对解密密钥实施合理的控制以及“在发生泄露或疑似泄露时”更改密钥的要求来获得同等的安全性......