3

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

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

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

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

我的问题是这种方法有多安全？我担心我们会创建所有这些并加密数据，但是如果我们丢失了密钥库或者他们对我们的所有数据进行了密钥处理，我们的所有数据都将永远丢失。

这只是备份密钥和密钥库的问题，以确保我们在发生灾难时始终在某个地方拥有副本吗？

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

4

1 回答 1

3

AES

AES 仍然是官方的“高级加密标准”，因此它仍然是对称密码的一个非常好的选择。与改进的安全性相比，较长密钥大小的速度损失可以忽略不计。

整体方法

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

您丢失密钥是对的：那么您遇到了大麻烦:) 但并非所有内容都丢失了，您仍然可以暴力破解 JCEKS 密钥存储文件的密码...

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

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

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

于 2011-08-01T16:07:26.267 回答