在Java Tomcat Web应用程序中存储加密密钥以加密/解密数据库中的敏感数据的最佳做法是什么？

在将某些敏感数据存储在PostgreSQL数据库之前,我们已经遇到了加密某些敏感数据的要求.我们的应用程序是一个运行在Tomcat之上的Spring应用程序.我们需要存储密钥,以便我们的Web应用程序可以在插入数据之前加密数据,并...

在将某些敏感数据存储在PostgreSQL数据库之前,我们已经遇到了加密某些敏感数据的要求.我们的应用程序是一个运行在Tomcat之上的Spring应用程序.我们需要存储密钥,以便我们的Web应用程序可以在插入数据之前加密数据,并在检索数据后解密数据.

我们希望避免在我们的配置文件(或由Maven过滤的文件)中存储此类事物,因为这些文件被检入源控件并且可由具有访问权限的任何人读取.我们似乎与数据库凭据有相同的问题,但看起来JNDI datasources可能会解决这些问题.

使用Tomcat时是否有最佳实践？环境变量之类的东西可能会起作用,但维护起来很麻烦.

编辑：为了澄清,我们试图防止由于未经授权访问实际数据库文件而导致的敏感数据丢失.我们的数据库与我们的应用服务器位于不同的物理盒上,因此我们可以轻松地将密钥保存在应用服务器所在的服务器上.

解决方法:

据我所知,围绕凭证的所有最佳实践都优化了易用性(针对运营团队)和代码简化(针对开发团队),而不是优化安全性.这非常令人失望.

我将该要求说明为：不要以未加密的形式存储任何凭证或加密密钥,无论是嵌入在属性/配置文件,源代码还是与应用程序分开管理的文件中.

这个要求的一些影响：

> JNDI数据源不适用于DB凭据,因为JNDI数据源的配置驻留在容器中的配置文件中.
>用于加密/解密的密码/密码短语(例如,用于数据库中的数据)不能驻留在代码或属性文件中.
>您必须为操作团队实施一种方法,以便在实例化时将秘密传递给应用程序.

您如何设计满足此要求的系统？

将所有秘密存储在集中位置的加密文件中(例如,在Amazon S3或硬件安全模块中).用于读取此加密数据的密码/凭证绝不能以数字方式存储 – 当应用程序旋转时,它被提供(例如,在POST的主体中).除了密码文件的密码,您还可能需要动态提供凭据以访问文件本身.

当应用程序收到密码文件的密码时,它会打开它并初始化它的内部(例如,创建DB数据源,初始化加密服务等).