问题描述
我们有一个在JBoss和Linux上运行的Java Web应用程序。生产环境数据库连接参数来自仅存在于生产环境应用服务器上的配置文件。该配置文件只能由运行应用程序的用户ID读取（让我们称之为用户appuser），只有能够登录到生产环境服务器和sudo到appuser的人才是我们运营团队的成员。生产环境本身可以防御所有其他环境。
We have a Java web application running on JBoss and Linux. Production environment database connection parameters come from a configuration file that only exists on the production environment app servers. That config file is only readable by the user ID that also runs the application, (let's call that user appuser) and the only people who can log into production environment servers and sudo to appuser are members of our Operations team. The production environment itself is firewalled off from all other environments.
我们希望使其更加安全。具体来说，我们希望阻止操作团队读取数据库连接密码和当前配置文件中的其他密钥。
We would like to make this more secure. Specifically we would like to prevent the operations team from reading the database connection password and other keys that are currently in the configuration file.
要记住的另一个因素是运营团队负责构建和部署应用程序。
Another factor to keep in mind is that the operations team is responsible for building and deploying the application.
我们有哪些选择？该解决方案需要支持手动重启应用程序以及在操作系统重新启动时自动启动应用程序。
What are our options? The solution needs to support manually restarting the application as well as automatically starting the application if the OS reboots.
更新
我正在调查的解决方案（向Adamski提示他的建议，大致转换为第1步）：
The solution I am investigating now (tip to Adamski for his suggestion, which roughly translates into step 1):
-
将一个包装器可执行文件
setuid写入启动/停止应用程序的用户，并拥有JBoss目录树中的配置文件和所有内容。
Write a wrapper executable that is
setuidto a user that starts/stops the applications and owns the configuration files and everything in the JBoss directory tree.
使用 jarsigner 在构建WAR后对其进行签名。 WAR的构建将通过开发完成。 setuid 包装器将验证签名，验证WAR未被篡改。
Use jarsigner to sign the WAR after it is built. The building of the WAR will be done by development. The setuid wrapper will verify the signature, validating that the WAR has not been tampered with.
更改部署过程仅部署已签名的WAR。 setuid 包装器也可以将WAR移动到JBoss部署目录中。
Change the deployment process to only deploy the signed WAR. The setuid wrapper can also move the WAR into place in the JBoss deploy directory.
推荐答案
为什么不为操作团队创建第二个用户sudo to，其中只有一个文件权限的子集与应用程序的用户ID相比？
Why not just create a second user for the Operations team to sudo to, which only has a subset of file permissions compared with your application's user ID?
无需更改代码;好又简单。
No code changes necessary; nice and simple.
这篇关于在生产环境中保护密码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！