java - 应用集群数据加密

Question

我有一个通过 SSL 访问的 Web 应用程序。为了加强后端的安全性，我们正在考虑为数据库添加对称加密。

该应用程序分布在 websphere 集群中的 6 台服务器上。

我们正在研究一个生成通用 key 的简单模型，将 key 传播到隔离的 JCEKS keystore 中的所有克隆。

密码和 key 长度采用 AES (256)。

我的问题是这种方法的安全性如何？我担心的是我们创建了所有这些并加密了数据，但如果我们丢失了 keystore 或他们的 key ，我们所有的数据基本上都会永远丢失。

这是否只是备份 key 和 keystore 以确保我们在发生灾难时始终在某个地方拥有副本的问题？

AES 仍然是可靠的密码吗？对称加密通常比非对称加密快。使用 256 位 key 是否会对性能产生重大影响，还是对加密数据的大小有更大影响？

Answer 1

AES

AES 仍然是官方的“高级加密标准”，因此它仍然是对称密码的一个很好的选择。较长 key 大小的速度损失是 negligible与改进的安全性相比。

总体方法

首先，该方法本身似乎很合理。但是你应该记住数据库中加密数据带来的缺点:没有更有效的索引，没有查询优化，一般没有选择性查询......如果你打算加密数据库的大部分甚至整个数据库你应该更好地研究数据库本身提供的加密功能。如果您使用这种方法，您还应该使用 SSL/TLS 保护与数据库的连接，这一点很容易被忽视。这保留了“普通”数据库的所有优点，同时提供了您正在寻找的额外安全性。

关于丢失 key ，你是对的:那你就有大麻烦了:)但并不是所有的都丢失了，你仍然可以暴力破解 JCEKS key 存储文件的密码......

是什么让我们找到了那个资源。 key 存储和密码确实是一个鸡生蛋还是蛋生鸡的问题。唯一真正干净的解决方案是每次启动应用程序/数据库时手动输入密码。但这往往是一个真正的问题(想想:半夜崩溃)，所以人们倾向于将密码存储在文件系统上的文本文件中。只要您遵循一些准则，就可以接受:

• 理想情况下，此文件应位于访问受限的另一台计算机上
• 如果它必须在同一台机器上，限制对该文件夹的访问权限 - 但不要忘记允许该应用访问它
• 再次加密那个文件通常是没有用的，又是鸡生蛋还是蛋生鸡的问题。尽管对内容进行 BASE64 编码可能有助于对技术上不那么精通的人进行第一道防御
• 应该很少有人知道密码(不能经常说)
• 您应该将密码备份在保险箱中。
• 不惜一切代价避免 keystore 文件扩散

如果你真的想要严格(假设只有一两个人应该知道密码)，那么你可以另外安装一个 Secret Sharing方案，但根据您的要求，这可能有点矫枉过正。这样的方案将允许拥有(本身无用的) secret 部分的个人将部分组合起来以恢复实际 secret 。通过这种方式，您可以通过将部件分散到更大的组来降低丢失风险。