应用集群中的数据加密

Question

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

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

我们正在研究一个生成公共密钥的简单模型，将密钥传播到隔离的JCEKS密钥库中的所有克隆。

在AES（256）上设置密码和密钥长度。

我的问题是这种方法有多安全？我担心的是我们创建所有这些并加密数据，但是如果我们丢失了密钥库或者它们关键，我们所有的数据基本上都会丢失。

这只是备份密钥和密钥库的问题，以确保在发生灾难时我们总是有一个副本吗？

AES仍然是一个坚实的密码吗？对称加密通常比非对称加密更快。是否对使用256位密钥有任何重大的性能影响，还是更多的是加密数据的大小？

Answer 1

<强> AES

AES是官方的“Avanced加密标准”，所以对于对称密码来说它仍然是一个非常好的选择。与改进的安全性相比，较长密钥大小的速度惩罚为negligible。

整体方法

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

你丢失钥匙是对的：你遇到了大麻烦:)但是并非所有都丢失了，你仍然可以强行破解JCEKS密钥库文件的密码......

是什么把我们带到那个资源。密钥存储和密码确实是一个鸡蛋和蛋的问题。对此唯一真正干净的解决方案是每次启动应用程序/数据库时手动输入密码。但这往往是一个真正的问题（想想：半夜崩溃），所以人们倾向于将密码存储在文件系统的文本文件中。只要您遵循一些指导原则，这是可以接受的：

• 理想情况下，此文件将位于具有受限访问权限的其他计算机上
• 如果必须在同一台计算机上，请限制对该文件夹的访问权限 - 但不要忘记允许该应用访问它
• 再次加密该文件通常没用，再次出现鸡蛋问题。虽然BASE64编码内容可以有利于对技术上不那么精明的第一道防线
• 很少有人知道密码（经常说不够）
• 您应该将密码备份保存在保险箱中。
• 不惜一切代价避免密钥库文件扩散

如果你真的想要严格（假设只有一两个人应该知道密码），那么你可以另外安装一个Secret Sharing方案，但根据你的要求，这可能是过度的。这样的方案将允许具有（本身无用的）秘密部分的个体组合部分以恢复实际秘密。这样，您可以通过将部件分散到更大的组来降低损失风险。