什么是加密 SQL 数据库中某些敏感或个人身份数据的“最佳实践”（根据 PCI、HIPAA 或其他适用的合规标准）？
这里有很多关于解决方案各个方面的问题，但我还没有看到任何在高层讨论该方法的问题。
经过一段时间的观察，我得出以下结论：
- 使用 CryptoAPI 和 Rijndael
- 生成IV并与加密数据一起存储
- 使用 DPAPI（机器范围）来“保护”对称密钥
- 将对称密钥存储在注册表、文件或数据库中，拆分密钥并将各个部分存储在多个位置以增强保护
- 除非确实需要，即不在从数据库读取时，否则不要解密数据。相反，将密文保存在内存中。
这足够了吗？过时了吗？审计安全？鲁莽？
你的方法很好，在我看来有一些调整（我通常为 PCI 合规性编写代码）：
使用 CryptoAPI 和 Rijndael
至少使用 Rijndael/AES256，无论其他 API 如何
生成IV并与加密数据一起存储
Good
使用 DPAPI（机器范围）来“保护”对称密钥
不确定这是否重要。我只是将 IV 放在加密的数据旁边，或者如果您真的对其他介质很偏执的话。确保 IV 不向公众开放。
将对称密钥存储在注册表、文件或数据库中，拆分密钥并将各个部分存储在多个位置以增强保护
如果有人窃取您的媒体，存储在多个位置对您没有帮助。将密钥全部拆分有点过大，但绝对不要将其与您的 IV 和/或密文一起存储。那就糟糕了。
除非确实需要，即不在从数据库读取时，否则不要解密数据。相反，将密文保存在内存中。
确实。将密文很好地保存在内存中，但不要将其传递到任何地方，除非绝对必要，否则不要解密，即使如此，也不要公开整个未加密的数据集 - 至少只公开其中需要的内容。另外，如果可能的话，不要将密钥保存在内存中 - 内存转储可能会暴露它。
补充：
- 无论您将密文存储在哪个数据库中，都将读取访问权限完全限制为为给定标识符选择的过程。不允许任何人（甚至 SA 帐户）对存储此数据的表进行读取访问。这样，闯入您系统的人将很难在不知道要查找什么 ID 的情况下提取您的密文。对引用密文表上标识符的任何表执行相同的操作。请勿一揽子阅读这些表格！
- 通过IP限制数据库访问
- 切勿在内存中保留任何未加密的明文状态。请求完成后立即允许其取消引用/垃圾收集。
- 将运行此代码的服务器限制为尽可能少的用户。
- 可能结合加密方法以获得更强的密文（例如 AES + Blowfish）
希望这些有帮助。其中一些是我的个人意见，但据我所知，它们仍然符合 PCI 标准。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
