根据我自己的经验,你基本上有以下三个选项,相关的优点和缺点：

将数据存储在配置文件中.

采用这种方法时,理想情况下应将它们与存储库本身隔离开来,并确保它们位于应用程序存储其内容的区域之外.

好处：

>非常容易隔离和控制访问,特别是如果您使用SELinux或AppArmor之类的东西来提高整体系统安全性.
>通常很容易为非技术用户进行更改(这对已发布的软件有利,但不一定适用于您组织的特定软件).
>易于管理大型服务器组.那里有各种配置部署工具.
>合理地轻松验证所使用的确切配置是什么.
>对于编写良好的应用程序,通常可以通过更新配置文件然后向应用程序发送特定信号(通常是SIGHUP)来更改配置而不中断服务.

缺点：

>需要进行适当的规划以保证数据的安全.
>您可能需要学习不同的格式(尽管现在只有一小部分需要担心,而且它们的语法通常相似).
>确切的存储位置可能会在应用程序中进行硬编码,从而使部署成为可能存在问题.
>解析配置文件可能会有问题.

将数据存储在环境变量中.

通常这是通过从启动脚本中获取环境变量和值的列表来完成的,但在某些情况下,它可能只是在程序名称之前的命令行中声明它们.

好处：

>与解析配置文件相比,从环境变量中提取值在几乎任何编程语言中都是微不足道的.
>您不必担心意外发布配置.
>你通过默默无闻获得一定程度的安全性,因为这种做法并不常见,大多数黑客攻击你的应用程序都不会想到立即查看环境变量.
>访问可以由应用程序本身控制(当它生成子进程时,它可以轻松擦除环境以删除敏感信息).

缺点

>在大多数UNIX系统上,访问进程的环境变量非常容易.有些系统提供了缓解此问题的方法(例如,LInux上的/ proc的hidepid挂载选项),但默认情况下它们未启用,并且不能防止拥有该进程的用户的攻击.
>如果正确处理上述安全问题,可以查看正在使用的确切设置并非易事.
>您必须信任该应用程序在生成子进程时擦除环境,否则它将泄漏信息.
>如果没有完全重新启动应用程序,您将无法轻松更改配置.

使用命令行参数传入数据.

说真的,不惜一切代价避免这种情况,这是不安全的,维持这种麻烦是很痛苦的.

好处：

>在大多数语言中,解析比环境变量更简单.
>子进程不会自动继承数据.
>提供在开发应用程序时快速测试特定配置的简便方法.

缺点：

>就像环境变量一样,在大多数系统上很容易读取另一个进程的命令行.>更新配置非常繁琐.>对配置的时长(有时低至1024个字符)施加硬性限制.