.Net中(对称)加密的最佳实践？

Question

加密SQL数据库中的某些敏感或个人身份识别数据(根据PCI,HIPAA或其他适用的合规标准)的"最佳实践"是什么？

这里有很多关于解决方案的个别方面的问题,但我没有看到任何在高层次上讨论该方法的问题.环顾了一段时间后,我想出了以下内容:

这够了吗？过时了吗？审计,安全吗？鲁莽？

Answer 1

您的方法很好,我的眼睛有一些调整(我通常会对PCI合规性进行编码):

使用CryptoAPI和Rijndael

无论其他API如何,至少使用Rijndael/AES256

生成IV并将其与加密数据一起存储

好

使用DPAPI(机器范围)来"保护"对称密钥

不确定是否重要.我只是将IV保存在加密数据旁边,或者如果你真的偏执于某些其他媒介.确保公众无法使用IV.

将对称密钥存储在注册表或文件或数据库中,拆分密钥并将部件存储在多个位置以提供额外保护

如果有人窃取您的媒体,在多个地方存储将无法帮助您.将密钥分开是有点矫枉过正,但绝对不要将它与你的IV和/或密文一起存储.那太糟糕了.

不要解密数据,除非确实需要,即不是从数据库中读取.相反,将密文保存在内存中.

当然.在内存中保存密码文本很好,但不要在任何地方传递它,并且除非绝对必要,否则不要解密,甚至不要对整个未加密的数据集进行EXPOSE - 只需要它至少需要它.此外,如果可能,请勿将密钥保存在内存中 - 内存转储可能会将其暴露.

加法:

无论您将密文存储在何种数据库中,都要将读取访问权限完全限制为为给定标识符选择的proc.不允许对存储此数据的表的读访问权限,甚至是SA帐户.这样,闯入您系统的人将很难在不知道要查找的ID的情况下下载您的密文.对引用密文表上的标识符的任何表执行相同操作.不要在这些表格中阅读BLANKET!
通过IP限制数据库访问
永远不要在内存中保留任何未加密的明文.一旦请求完成,就允许它被解除引用/垃圾收集.
将运行此代码的服务器限制为尽可能少的用户.
可能将加密方法组合成更强的密文(例如AES + Blowfish)

希望这些帮助.其中一些是我个人的意见,但据我所知仍然符合PCI标准.