Java 应用集群中的数据加密

Java 应用集群中的数据加密,java,cryptography,aes,encryption-symmetric,tde,Java,Cryptography,Aes,Encryption Symmetric,Tde,我有一个通过SSL访问的web应用程序。为了加强后端的安全性,我们正在考虑为数据库添加对称加密 该应用程序分布在websphere集群中的6台服务器上 我们正在研究一个生成公共密钥的简单模型,在一个孤立的JCEKS密钥库中跨所有克隆传播该密钥 密码和密钥长度采用AES(256) 我的问题是这种方法有多安全?我担心的是我们创建了所有这些并对数据进行加密,但是如果我们丢失了密钥库或密钥,那么我们的所有数据实际上将永远丢失 这只是一个备份密钥和密钥库的问题,以确保在发生灾难时,我们总是在某处拥有副本吗

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

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

我们正在研究一个生成公共密钥的简单模型,在一个孤立的JCEKS密钥库中跨所有克隆传播该密钥

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

我的问题是这种方法有多安全?我担心的是我们创建了所有这些并对数据进行加密,但是如果我们丢失了密钥库或密钥,那么我们的所有数据实际上将永远丢失

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

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

AES

AES是官方的“先进加密标准”,所以它仍然是对称密码的一个很好的选择。将更长密钥大小的速度惩罚与改进的安全性进行比较

总体方法

首先,这种方法本身似乎是合理的。但您应该记住数据库中加密数据带来的缺点:没有更有效的索引,没有查询优化,通常没有选择性查询。。。如果您打算对数据库的大部分甚至整个数据库进行加密,那么最好研究一下数据库本身提供的加密功能。如果使用这种方法,那么还应该使用SSL/TLS保护与数据库的连接,这是很容易被忽略的。这保留了“普通”数据库的所有优点,同时提供了您所需要的附加安全性

关于丢失密钥,您是对的:那么您就有大麻烦了:)但并不是所有的密钥都丢失了,您仍然可以强制执行JCEKS密钥存储文件的密码

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

  • 理想情况下,此文件将位于具有受限访问权限的另一台计算机上
  • 如果必须在同一台计算机上,请限制对该文件夹的访问权限,但不要忘记允许应用程序访问该文件夹
  • 再次加密该文件通常是没有用的,这又是个鸡毛蒜皮的问题。虽然BASE64编码的内容可以有利于对技术上不那么精明的人进行第一次防御
  • 很少有人应该知道密码(说得不够多)
  • 您应该将密码备份保存在保险箱中
  • 不惜一切代价避免密钥存储文件激增

如果你真的想严格要求(比如说只有一两个人知道密码),那么你可以另外安装一个方案,但根据你的要求,这可能会有些过分。这样的方案将允许拥有(本身无用的)部分秘密的个人组合部分,以恢复实际的秘密。通过这种方式,您可以通过将部件分散到更大的组中来降低丢失风险。

您希望保护数据免受什么样的威胁?也许使用数据库的加密机制就足够了(取决于产品)?我们需要防止有人简单地从数据库中读取数据。它是DB2V9。我宁愿放一些能够经受时间考验的东西,而不是特定于产品的东西。问题是,如果你在应用层加密(例如,数据库中的字段被加密),你首先会在算法强度上出现性能下降,其次你的查询将不再有效(例如,where条件)。或者你计划只加密某些字段(信用卡、出生日期等)?目的是只加密敏感信息。无论如何,通常无法在应用程序中直接搜索此信息。如果我们确实需要搜索这些字段,那么使用数据库中的内置加密机制是否允许我们保持现有查询的原样?它对应用层是透明的吗?通常是的。我只在Oracle上这样做,但是如果您在数据库级别加密,它对您来说是透明的。顺便说一句:记住,你可能还想在网络上加密(TCP流量)?感谢App-DB通信的更新,我们的雷达上当然没有。