我们正在考虑对敏感数据使用sql Server列(单元)级加密.我们最初加密列时应该没有问题,但我们要求每年都需要更改加密密钥.看来这个要求可能有问题.
假设:包含具有敏感数据的列的表将具有5亿条记录.
以下是我们考虑实施的步骤.在加密/解密过程中,数据是否在线,以及此过程需要多长时间?
>最初加密列
>新年
>解密专栏
>使用新密钥加密列.
题 :
当列被解密/加密时,数据是否在线(可用于查询)?
sql Server是否提供允许在数据联机时进行密钥更改的功能?
BarDev
解决方法
重新加密静态数据将是令人望而却步的.更新500M记录会产生巨大的日志,很多数据IO,如果不是几天就会持续数小时,总体来说会非常具有破坏性.更不用说操作错误可能会使整个数据库完全加密(即没有密钥来解密它).
我建议的是在密钥层次结构上旋转更高的密钥:
>使用对称密钥加密数据.
>定期更改对称密钥,例如.每周生成一个新数据,使用新数据加密新数据但不更改旧数据
>使用证书加密对称密钥
>使用DECRYPTBYKEYAUTOCERT解密数据,这将自动处理选择正确的对称密钥
>如果需要,请旋转加密对称密钥的证书.对称密钥支持多证书加密,因此添加新证书,通过新证书将加密添加到所有对称密钥,然后删除旧证书是完全可行的
类似的计划通常由大公司部署.很少重新加密所有数据,因为这是如此令人望而却步.如果对称密钥遭到破坏,使用多个对称密钥并经常生成新密钥将减少可能的隐私丢失量.旋转用于解密对称密钥的证书可以减少证书泄露,因为受损的证书在轮换后将无法访问数据,即使数据仍然使用相同的旧对称密钥加密.
确实,我可以设想一种攻击,如果我可以访问证书,我可以提取所有对称密钥材料,然后当证书旋转时,我理论上可以使用保存的密钥材料来解密数据(使用其他方法)比sql Server).但是,如果说“如果我在轮换之前可以访问受损的证书,我可以解密所有数据并保存解密的数据”,这就没有什么不同了,这使攻击成为一个新的亮点,因为事实上,密钥轮换将恢复已经丢失给攻击者的数据.