我管理一个 php 应用程序，其关键变量（例如数据库服务器地址、数据库用户名和密码等）会根据其环境（开发、QA、生产等）而变化。
为了简化部署，我已经开始将一些与环境相关的变量从作为代码库一部分的 .ini 配置文件中移出，并移到 Ubuntu apache2 /etc/apache2/envvars 文件中。
我尚未将密码移至此文件，但正在考虑中。问题是这样的：如果只需要一个 phpinfo.php 文件来在“环境”部分中公开这些数据库密码，那么将数据库密码留在原处是否更安全，在位于 Web 根目录之外的 .ini 配置文件中？
我完全同意您的意见，即让 phpinfo() 转储您的数据库密码不是明智的做法。ini 文件似乎更好一点，您的应用程序可以在需要时检索密码。对于像 Symfony 这样的当前框架，这是要走的路。如果您将生产机器的访问权限限制为负责的管理员，则可以访问配置文件的人员范围有限。当然，ini 文件不应存储在公共存储库中。缺点是应用程序本身，您的网络服务器用户必须有权访问该文件，因此任何 PHP 脚本都可以读取和转储它。
这就提出了您是否愿意付出巨大努力来提高安全性的问题。
在 Java EE 世界中，您可以应用以下概念。您将企业应用程序部署到 GlassFish 或 JBoss 等应用程序服务器。在具体的 JDBC 配置中，您为密码设置了一个占位符。实际密码可以存储在加密的密码文件中，管理员必须在服务器启动时输入密码。这自然会阻止完全自动化的服务器启动。我个人不能向您保证这是 100% 防弹，但它使攻击者更难。
另一种可能性是“外包”您的密码。您可以使用密码服务（谷歌为“Cyber-Ark”，我认为他们有一个 API/SDK 可以将自己的应用程序连接到他们的密码库）工具来存储密码并控制访问。每次您的应用程序需要密码时，都必须从服务中检索该密码。当然，获得 API 访问权限和密码服务登录数据的人也可以请求密码。但是使用单独的服务，您至少可以选择记录访问权限以提供可用的审计跟踪。职责分离：如果密码服务有另一个管理员，一个人很难做不允许的事情，或者至少有机会跟踪这些事情。
如果使用php-fpm ，您可以在池配置文件中为每个池设置环境变量。这很好，有几个原因。
php-fpm 池配置文件应该rw-r-----归root:root. 因此 php-fpm 用户应该无法读取它们（注意父 php-fpm 守护进程可以，因为它是作为 root 生成的，然后派生出子进程）。
这些 php-fpm 池配置文件不能随应用程序源代码意外提交到 GitHub 等。
这是一个例子：
# in the php-fpm pool configuration file
env[MYSQL_PASSWORD] = somecrazylongpasswordhere
在处理密码文件时，我们必须看到只有那些“需要知道”密码的用户才能访问密码详细信息。在您的情况下，有权访问代码树（即 .ini 文件）的人是否需要知道数据库详细信息和密码，因为他们可能无权访问环境部分。如果他们可以访问代码树和环境，我认为您是对的，您可以将这些详细信息保留在 .ini 文件中，但要确保它位于 webcontent 目录之外。
目前我只能想到这个。
全部 - 请随时纠正我或添加我错过的任何内容。