应用集群数据加密
我有一个通过 SSL 访问的 Web 应用程序。为了增强后端的安全性，我们正在考虑为数据库添加对称加密。
该应用程序分布在 websphere 集群中的 6 台服务器上。
我们正在研究生成公共密钥的简单模型，并在隔离的 JCEKS 密钥库中的所有克隆之间传播密钥。
密码和密钥长度采用 AES (256)。
我的问题是这种方法安全吗？我担心的是我们创建了所有这些并加密了数据，但是如果我们丢失了密钥库或者他们丢失了密钥，我们的所有数据基本上都会永远丢失。
这只是备份密钥和密钥库以确保我们在发生灾难时始终在某处拥有副本的问题吗？
AES 仍然是可靠的密码吗？对称加密通常比非对称加密更快。使用 256 位密钥是否会对性能产生重大影响，或者对加密数据的大小是否有更大影响？
I have a web application accessed over SSL. To beef up security on the back end we are looking at adding in symmetric encryption for the database.
The application is spread across 6 servers in a websphere cluster.
We were looking at a simple model of generating a common key, propagating the key across all clones in an isolated JCEKS keystore.
Settled on AES (256) for the cipher and key length.
Question I have is how safe is this approach? My fear is we create all of this and encrypt the data, but if we lose the keystore or they key all our data is essentially lost forever.
Is this just a matter of backing up the key and keystore to ensure we always have a copy somewhere in case of a disaster?
Is AES still a solid cipher? and symmetric encryption is generally faster than asymmetric. is there any major performance impacts to using a 256 bit key or is it more on the size of the data being encrypted?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
AES
AES 仍然是官方的“高级加密标准”，因此对于对称密码来说它仍然是一个非常好的选择。与改进的安全性相比，较长密钥大小的速度损失可以忽略不计。
总体方法
首先，该方法本身似乎是合理的。但是您应该记住数据库中加密数据带来的缺点：没有更有效的索引，没有查询优化，一般没有选择性查询...如果您打算加密数据库的大部分甚至整个数据库，您应该更好地研究数据库本身提供的加密功能。如果您使用此方法，您还应该使用 SSL/TLS 保护与数据库的连接，这是很容易被忽视的。这保留了“普通”数据库的所有优点，同时提供了您正在寻找的附加安全性。
你对丢失密钥的看法是对的：那么你就有大麻烦了:)但并不是所有的都丢失了，你仍然可以暴力破解 JCEKS 密钥存储文件的密码......
是什么让我们找到了这个资源。对于密钥存储和密码来说，这确实是一个先有鸡还是先有蛋的问题。唯一真正干净的解决方案是每次启动应用程序/数据库时手动输入密码。但这往往是一个真正的问题（想想：半夜崩溃），因此人们倾向于将密码存储在文件系统上的文本文件中。只要您遵循一些准则，这是可以接受的：
如果您确实想要严格（假设只有一两个人应该知道密码），那么您可以另外安装 秘密共享 方案，但这可能有点过头了，具体取决于您的要求。这样的方案将允许拥有部分秘密（本身无用）的个人将这些部分组合起来以恢复实际的秘密。通过这种方式，您可以通过将零件分散到更大的群体来降低损失风险。
AES
AES is sill the official "Avanced Encryption Standard", so it's still a very good choice for a symmetric cipher. The speed penalty for longer key sizes is negligible compared to the improved security.
Overall approach
First of all, the approach itself seems sound. But you should keep in mind the disadvantages that encrypted data in the database introduces: no more efficient indexing, no query optimization, no selective queries in general... If you intend to encrypt large parts of the database or even the whole database you should better look into encryption functionality offered by the database itself. If you use this approach, you should additionally secure the connections to your database with SSL/TLS, something that is easily overlooked. This keeps all the benefits of a "normal" database while providing the added security you are looking for.
You're right about losing the keys: you're in big trouble then :) But not all is lost, you could still brute-force the password of the JCEKS key store file...
What brings us to that resource. It's really a hen-and-egg problem with key stores and passwords. The only really clean solution to this is entering the passwords manually each time the app/database is started. But this tends to be a real problem (think of: crash in the middle of the night), so people tend to store the passwords in a text file on the file system. It's acceptable as long as you follow some guidelines:
If you really want to be strict (let's say just one or two persons should know the password), then you could additionally install a Secret Sharing scheme but that might be overkill depending on your requirements. Such a scheme would allow individuals with a (in itself useless) part of a secret to combine parts in order to restore the actual secret. This way you can mitigate the risk of loss by spreading the parts to a larger group.