Ste*_*HHH 24 passwords environment-variables
我有一组服务器,每个服务器都有配置文件,这些文件当前包含敏感的关键任务系统(消息队列、数据存储和其他服务)的纯文本密码。
有些人将关键密码从配置文件中移到运行服务器进程的用户帐户的环境变量中。这样就可以将配置文件提交到版本控制,系统管理员只需要在服务器系统搭建时创建一个合适的环境变量即可。自然,对运行这些服务的帐户的访问受到很大限制。
这真的是避免纯文本配置文件中的密码的最佳方法,还是有更好的方法?
dan*_*uer 11
如果您使用的是 Linux 系统,请查看 /proc/*/environ 并确定环境变量是否适合存储敏感信息。/proc/self 是当前进程:
$ tr '\0' '\n' < /proc/self/environ
USER=me
LOGNAME=me
HOME=/home/me
PATH=/usr/bin:/bin:/usr/sbin:/sbin
MAIL=/var/mail/me
SHELL=/usr/bin/sh
SSH_CLIENT=1.2.3.4 58195 22
SSH_CONNECTION=1.2.3.4 58195 7.8.9.0 22
SSH_TTY=/dev/pts/1
TERM=xterm
Run Code Online (Sandbox Code Playgroud)
没关系,设置环境变量的事情可能是在某处读取文件。
要记住的是,使用密码意味着程序可以使用该密码。如果此密码不是由每次程序需要时都输入的用户提供,则该密码必须仅基于程序的访问权限才能访问。您可以在本地加密密码并使用密钥对程序进行解密,但这只是隐藏密码以防意外泄露;与程序具有相同访问权限的人可以执行程序可以执行的相同操作,包括读取加密密钥。
正确的方法是让应用程序作为受限帐户运行,并将密码存储在受文件系统级权限保护的文件中。希望您可以“包含”一个文件或类似文件,以便将密码排除在版本控制系统之外(假设 VCS 没有安全控制)。为防止无意泄露,请根据需要隐藏密码 - base64 对其进行编码,使用 pgp 进行加密,无论您的服务器程序的选项集是否有意义。如果您正在编写一个程序来执行此操作,那么您能做的最好的事情就是仅在需要时提示用户输入密码,然后在使用该密码后立即从内存中清除该密码。
最终,如果您有任何需要读取和写入的数据,您最终将使用密码保护某些东西(或者如果您真的很偏执,使用物理硬件智能卡和 PIN),不不管你有多少层加密。
这归结为系统安全性与便利性的基本问题。您可以通过拥有大量安全控制层来添加“深度防御”,恶意行为者必须破坏这些安全控制层才能获得“商品”,但是当合法行为者想要读取或更改某些数据时,他们必须通过一堆箍。另一种方法是文本文件中的明文密码。
如果我真的想保护关键任务系统中的某些信息,我会怎么做:
使用全盘加密,这样整个持久存储的内容都被加密。
限制对机器的物理访问。使用安全锁定机制锁定机器的底盘并控制对钥匙的物理访问。雇用肌肉(武装警卫)作为进入的守门人。
在设备的操作系统中实施细粒度的强制访问控制 (MAC)。您可以从 GNU/Linux 上的 SELinux 之类的东西开始,并将其设置为 Enforcing,然后根据生产软件的确切需求定制策略,允许这些帐户完全(且仅)获得他们需要的文件所需的权限。
如果您将拥有系统特定的密码和配置文件的版本控制,您真的希望避免将明文密码错误地提交给版本控制的可能错误,因为很难从VCS 的缓存。环境变量是为此的几个可行选项之一。另一个是程序启动时的密码提示,但随后重新启动机器和恢复运行状态是手动操作,不能自主完成,因此再次存在便利性与安全性的问题。
确保您手头有网络专家来处理防火墙权限,以最大程度地减少网络攻击的风险。审计(渗透测试以及白盒测试代码)任何与外部系统,尤其是公共互联网接口的软件。“接口”不仅包括直接的网络连接,还包括读取或写入“不受信任的”数据(其字节来自安全服务器的 RAM/磁盘/CPU 之外的数据)。
这不是一个完整的列表,但特别是第 4 点可能与您相关,尽管如果您不执行至少第 1 到第 3 步,考虑第 4 点和第 5 点不会对您有很大帮助,因为您的系统在相当基础的层面上并不安全。
归档时间: |
|
查看次数: |
21451 次 |
最近记录: |