保护google应用引擎数据中的数据

Question

我们的googleappengine应用程序存储了大量的个人识别信息（email、ssn等）来识别用户。我在寻求如何保护这些数据的建议。在

我目前的策略

以两种形式存储敏感数据：

• 散列-使用SHA-2和盐
• 使用加密的私钥/RSA

当我们需要查找时：

• 查找散列数据（散列查询中的PII，将其与数据存储中的散列PII进行比较）。在

如果我们需要重新散列数据或以原始形式处理它：

• 用我们的私钥解密加密版本。不要以原始形式存储它，只需处理它，然后重新哈希和重新加密它。在

我的顾虑

为我们的杂碎盐保密

如果攻击者得到了数据存储中的数据以及我们的哈希盐，我担心他们可能会暴力攻击敏感数据。其中一些（比如SSN，一个9位数的数字）没有很大的密钥空间，所以即使使用现代哈希算法，我相信如果攻击者知道salt，也可以做到。在

我目前的想法是将salt从源代码控制中排除，并保存在它自己的文件中。该文件在部署期间被加载到GAE上，应用程序在需要散列传入数据时读取该文件。在

在两次部署之间，salt文件保存在一个由愤怒的熊（或一个保险箱）保护的USB密钥上。在

盐只生活在两个地方

1. U盘
2. 部署到谷歌应用程序

由于代码下载被永久禁用，我想不出一个办法让别人在不偷U盘的情况下拿到盐。我错过什么了吗？在

为我们的私人RSA密钥保密

少担心这个。我们很少需要解密加密的版本（只有当我们更改哈希算法或数据格式时）。在

私钥永远不必接触GAE服务器，我们可以提取加密数据，在本地解密，处理它，然后重新上传加密/哈希版本。在

我们可以把我们的RSA私钥保存在一个由熊和老虎看守的U盘上，并且只有在我们需要的时候才把它拿出来。在

---

我意识到这个问题并不完全是针对google应用程序的，但我认为GAE让情况有点独特。在

如果我有完全的控制权，我会做一些事情，比如锁定部署访问权和通过双因素身份验证访问datastoreviewer，但是这些选项目前还不可用（使用特定于GAE的密码是很好的，但是我喜欢使用RSA令牌）。在

我既不是GAE专家，也不是安全专家，所以如果有什么漏洞我遗漏了，或者我没有想到平台的具体情况，我会很乐意听到的。在

Answer 1

在数据存储上加密数据的有趣方法。在经历了这些之后，我想到的一个问题是如何查询散列上的数据？您是使用两个哈希的比较还是更细粒度的哈希？同样，在对表中的数据进行哈希和加密后，如何完成大于值、小于值的操作？在

Fine grained hashing意思是，您是否对数据流的连续字节进行哈希以获得累积哈希值。i、 e散列（abcd）=散列（a，b）+散列（b，c）+等。这种类型的散列将显示基础数据的相似程度，而不是匹配。在

Answer 2

您可以通过使用HMAC、一个秘密密钥和每个条目的唯一salt来提高哈希算法的安全性（我知道人们在这方面会不同意我的观点，但我的研究认为这有助于避免某些攻击）。您也可以使用bcrypt或scrypt来散列，这将使反转散列成为一个非常耗时的过程（但您还必须考虑到这一点，因为您的应用程序需要计算哈希值）。在

通过禁用代码下载并保护您的密钥，我无法想象有人如何获得它。只需确保您的代码在类似的安全保护下受到保护，或者您在开发期间从代码中删除了密钥，并且只将其拉出以进行部署。我会把你的秘密藏在你的记忆里，但我认为这是不可能的。在

更新： 请确保对你的应用程序拥有管理员权限的所有Google帐户启用双因素身份验证。谷歌提供了这项服务，所以不确定你的限制是否是外部力量强加的。在

Answer 3

在决定安全体系结构时，您首先想到的应该是威胁模型。谁是你的潜在攻击者，他们有什么能力，你如何防御他们？如果不清楚你的威胁模型，你就无法评估你提出的安全措施是否足够，甚至是必要的。在

从你的文字来看，我猜你是想保护自己不受以下因素的影响：

1. 危害数据存储数据，但不损害应用程序代码的攻击者。在
2. 攻击者获取访问凭据以访问应用程序的管理控制台并可以部署新代码的攻击者。在

对于前者，加密或散列您的数据存储数据可能已经足够了（但请参见本回答后面的注意事项）。针对后者的保护是很困难的，但是只要你的管理员用户在没有部署新的应用程序版本的情况下不能执行任意代码，将你的密钥存储在一个未签入到源代码管理的模块中，应该可以正常工作，因为即使有了管理员访问权限，他们也无法恢复密钥，也无法部署新版本揭示了他们的钥匙。显然，一定要禁用源代码的下载。在

您正确地注意到了一些关于使用有限的熵对数据进行散列处理的问题，而且您关注的是正确的。在某种程度上，salt可以通过防止预计算攻击来帮助实现这一点，而密钥拉伸（如PBKDF2、scrypt和bcrypt中使用的密钥拉伸）会增加攻击者的工作量，从而使攻击者的生活更加艰难。但是，对于SSN之类的东西，您的密钥空间非常小，以至于任何数量的密钥扩展都没有帮助—如果您对数据进行哈希处理，并且攻击者获得哈希值，他们将能够确定原始的SSN。在

在这种情况下，唯一可行的方法是用密钥加密数据。现在你的攻击者为了获取数据而被迫强行破解密钥，这是一个数量级的挑战。在

简而言之，我的建议是使用标准（私钥）密码加密数据，密钥存储在不在源代码管理中的模块中。相反，使用散列只会削弱你的数据，而使用公钥加密并不能提供明显的安全性，以防止任何可能的威胁模型，而你还没有使用一个标准密码。在

当然，保护用户数据的首要方法是，如果可以的话，首先不要存储这些数据。：）