.NET中(对称)加密的最佳做法? [英] Best practices for (symmetric) encryption in .Net?

问题描述

(在PCI，HIPAA或其他适用的合规性标准下)对SQL数据库中的某些敏感或个人身份数据进行加密的最佳做法是什么?

What is considered "best practice" for encrypting certain sensitive or personally identifiable data in a SQL database (under PCI, HIPAA, or other applicable compliance standards)?

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

There are many questions here regarding individual aspects of a solution, but I have not seen any that discuss the approach at a high level. After looking around for quite some time, I came up with the following:

• 使用CryptoAPI和Rijndael
• 生成IV并将其与加密数据一起存储
• 使用DPAPI(机器范围)保护"对称密钥
• 将对称密钥存储在注册表或文件或数据库中，分割密钥并将部件存储在多个位置以增强保护
• 除非确实需要数据，否则不要解密数据，即不是从数据库读取数据时才解密.而是将密文保存在内存中.

这样够吗?过时了吗审核安全吗?鲁ck?

Is this adequate? Outdated? Audit-safe? Reckless?

推荐答案

您的方法很好，但我的眼睛有些调整(我一般都遵循PCI规范):

Your approach is good, with a few adjustments in my eyes (I code for PCI compliance generally):

使用CryptoAPI和Rijndael

Use CryptoAPI and Rijndael

至少使用Rijndael/AES256，与其他API无关

Use Rijndael/AES256 at a minimum, regardless of other APIs

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

Generate IV and store it with the encrypted data

好

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

Use DPAPI (Machine scope) to "protect" the symmetric key

不确定是否重要.我只是将IV保留在已加密的数据旁边，或者如果您对其他媒介确实很偏执的话.确保公众不能访问IV.

Not sure if it matters. I'd just keep the IV next to the data that's encrypted, or if you're really paranoid on some other medium. Ensure that the IV is not accessible to the public.

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

Store the symmetric key in the registry or a file or the database, split the key and store parts in multiple places for added protection

如果有人偷了您的媒体，那么将其存储在多个地方将无济于事.将密钥全盘拆分有点过头，但是绝对不要将其与您的IV和/或密文一起存储.那就不好了.

Storing in multiple places will not help you if someone steals your media. It's a bit overkill to split the key up all over heck, but definitely do NOT store it with your IV and/or ciphertext. That'd be bad.

除非确实需要，否则不要解密数据，即从数据库中读取数据时才解密.而是将密文保存在内存中.

do not decrypt the data unless it is really needed, i.e. not upon read from the database. Instead, hold cipher text in memory.

当然.最好将密文保存在内存中，但不要将其传递到任何地方，除非绝对必要，否则不要解密，即使如此，也不要暴露整个未加密的数据集-至少只需要它.另外，如果可能的话，不要将密钥保持在内存中-内存转储可能会将其公开.

Definitely. Holding cipher text in memory in fine, but don't pass it around anywhere, and don't decrypt except when you absolutely must, and even then don't EXPOSE the entire unencrypted dataset - only what is needed from it at the minimum. Also, do not hold the key in memory if possible - a memory dump could expose it.

添加项:

• 无论在哪个数据库中存储密文，都将读取访问权限完全限制为为给定标识符选择的proc.不允许对将数据存储到任何人的表(即使是SA帐户)进行读取访问.这样，一个闯入您系统的人将很难在不知道要查找什么ID的情况下提取密文.对引用密文表上的标识符的任何表执行相同的操作. 禁止空白阅读这些表！
• 通过IP限制数据库访问
• 永远不要将任何未加密的纯文本持久保存在内存中.请求完成后，请立即将其取消引用/回收.
• 将运行此代码的服务器限制为尽可能少的用户.
• 可能结合使用加密方法以获得更强的密文(例如AES + Blowfish)

• Whatever database you store your cipher text in, restrict read access entirely to the proc(s) that select for a given identifier. Do not allow read access to the tables that store this data to ANYONE, even the SA account. This way, a person who breaks into your system will have a hard time pulling down your cipher texts without knowing what IDs to look for. Do the same for any table(s) referencing the identifier on the ciphertext table. DO NOT ALLOW BLANKET READS OF THESE TABLES!
• Restrict database access by IP
• Never persist any unencrypted plaintext in memory over state. Allow it to be dereferenced/garbage collected as soon as the request is completed.
• Restrict the server(s) running this code to as few users as possible.
• Possibly combine encryption methods for a stronger ciphertext (AES + Blowfish for example)

希望这些帮助.其中一些是我的个人观点，但据我所知仍保持PCI兼容性.

Hope these help. Some of them are my personal opinions but remain PCI compliant to the best of my knowledge.

这篇关于.NET中(对称)加密的最佳做法?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！