我们的谷歌应用引擎应用存储了大量的个人识别信息(电子邮件、ssn 等)来识别用户。我正在寻求有关如何保护这些数据的建议。
我目前的策略
以两种形式存储敏感数据:
- 散列 - 使用 SHA-2 和盐
- 加密 - 使用公钥/私钥 RSA
当我们需要查找时:
- 查找散列数据(在查询中散列 PII，将其与数据存储区中散列的 PII 进行比较)。
如果我们需要重新散列数据或以其他方式以原始形式处理数据:
- 使用我们的私钥解密加密版本。切勿以原始形式存储它，只需对其进行处理，然后重新散列并重新加密即可。
我的担忧
对我们的哈希盐保密
如果攻击者获取了数据存储区中的数据以及我们的哈希盐，我担心他们会暴力破解敏感数据。其中一些(如 SSN，一个 9 位数字)没有大的 key 空间，所以即使使用现代哈希算法，我相信只要攻击者知道盐就可以做到。
我目前的想法是将盐排除在源代码控制之外并保留在它自己的文件中。该文件在部署期间被加载到 GAE 中，应用程序在需要散列传入数据时读取该文件。
在部署之间，salt 文件保存在受愤怒熊(或保险箱)保护的 USB key 上。
盐只生活在两个地方
- USB key
- 部署到谷歌应用
并且由于永久禁用了代码下载，我想不出一种方法可以让某人在不窃取该 USB key 的情况下获得盐。我错过了什么吗？
保密我们的私有(private) RSA key
不太担心这个。我们很少需要解密加密版本(仅当我们更改哈希算法或数据格式时)。
私钥永远不必接触GAE服务器，我们可以拉下加密数据，在本地解密，处理它，然后重新上传加密/散列版本。
我们可以将我们的 RSA 私钥保存在由熊和老虎守卫的 U 盘上，并且只在需要时将其取出。
我意识到这个问题并不完全是谷歌应用程序特有的，但我认为 GAE 使这种情况有些独特。
如果我可以完全控制，我会使用双重身份验证来锁定部署访问和对数据存储查看器的访问，但这些选项目前不可用(拥有 GAE 特定密码很好，但我喜欢使用 RSA token )。
我既不是 GAE 专家也不是安全专家，所以如果我遗漏了某个漏洞或者我没有想到特定于平台的东西，我很乐意听到。
最佳答案
在决定安全架构时，您首先想到的应该是威胁模型。谁是您的潜在攻击者，他们的能力如何，您如何防御他们？如果对您的威胁模型没有一个清晰的概念，您将无法评估您提议的安全措施是否足够，或者是否有必要。
从您的文字中，我猜您正在寻求防止以下某些子集:
- 攻击者会破坏您的数据存储区数据，但不会破坏您的应用程序代码。
- 获取凭据以访问您应用的管理控制台并可以部署新代码的攻击者。
对于前者，加密或散列您的数据存储数据可能就足够了(但请参阅此答案后面的注意事项)。防止后者更加困难，但只要您的管理员用户在不部署新应用程序版本的情况下无法执行任意代码，按照您的建议，将您的 key 存储在未 checkin 源代码控制的模块中，应该可以正常工作，因为即使具有管理员访问权限，他们也无法恢复 key ，也无法部署向他们显示 key 的新版本。确保禁用源下载，显然。
您正确地注意到了对熵有限的数据散列的一些担忧——您的担忧是正确的。在某种程度上，盐可以通过防止预计算攻击来帮助解决此问题，而 key 拉伸(stretch)(例如 PBKDF2、scrypt 和 bcrypt 中使用的 key 拉伸(stretch))可以通过增加攻击者必须做的工作量来使攻击者的生活更加艰难。但是，对于像 SSN 这样的东西，您的 key 空间非常小，以至于没有多少 key 拉伸(stretch)会有所帮助 - 如果您对数据进行哈希处理，并且攻击者得到哈希值，他们将能够确定原始 SSN。
在这种情况下，您唯一可行的方法是使用 key 加密数据。现在，您的攻击者被迫暴力破解 key 以获取数据，这是一个难度更大的挑战。
简而言之，我的建议是使用标准(私钥)密码加密您的数据，并将 key 存储在不受源代码控制的模块中。相反，使用散列只会削弱您的数据，而使用公钥加密并不能提供明显的安全性来抵御使用标准密码所没有的任何似是而非的威胁模型。
当然，如果可以的话，保护用户数据的首要方法是一开始就不要存储它。 :)
关于python - 保护 google app engine 数据存储区中的数据，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10096268/