mac*_*jna 7 security config pipe 12factor
我正在尝试找出 Web 应用程序配置的最佳方法。目标是：
根据12 因素应用程序Web 应用程序配置最好在环境变量中提供。它简单而灵活，但看起来有一些与此相关的安全问题。
另一种方法是将所有配置作为命令行参数传递。这对操作系统来说又是简单、灵活和自然的，但整个配置然后在主机的进程列表中可见。这可能是也可能不是问题（我不是操作系统专家），但解决方案至少很麻烦。
流行的Dropwizard框架采用了一种混合方法，其中命令行参数指定配置文件的位置，然后从那里读取配置。问题是它打破了对我的配置（本地文件）的位置做出假设的灵活性约束。它还使我的应用程序实现文件访问，虽然在大多数语言/框架/库中通常很容易实现，但本质上并不简单。
我正在考虑另一种方法，即在应用程序的stdin. 最终cat my-config-file.yml | ./my-web-app，在本地存储文件甚至wget https://secure-config-provider/my-config-file.yml | ./my-web-app. 管道看起来很简单并且是操作系统进程的本机。它似乎非常灵活，并且将配置如何提供给主机操作系统的问题分开了。
问题是它是否符合安全约束。假设一旦管道内容被消费它就永久消失是否安全？
我无法用谷歌搜索任何尝试这个的人，因此这个问题。
将机密写入stdin进程比环境变量更安全 -如果正确完成。
事实上，这是我所知道的将秘密从一个进程传递到另一个进程的最安全的方式——如果操作正确，也是如此。
当然，这适用于所有类似文件不具有文件系统的存在和它的输入，否则不能被其他进程打开，stdin只是其中的一个例子即是默认选项，易写。
无论如何，正如您链接的帖子所描述的那样，环境变量的关键在于，一旦您将某些内容放入环境变量中，它就会泄漏到所有子进程中，除非您小心清理它。
而且，以您的用户或任何特权/管理用户身份运行的其他进程也可以检查您正在运行的进程的环境。
例如，在 Linux 上，查看文件/proc/*/environ. 该文件存在于每个正在运行的进程中，您可以检查其内容以查找以您的用户身份运行的任何进程。如果是root，您可以查看任何用户的任何进程的环境。
这意味着任何本地代码执行漏洞，即使是一些非特权漏洞，都可以访问您环境变量中的秘密，这样做非常简单。仍然比将它们放在一个文件中要好，但也好不了多少。
但是，当您将事物通过管道stdin传输到进程中时，外部进程只能在它们能够使用调试系统调用“附加”到该进程并监视系统调用或扫描其内存的情况下才能拦截它。这是一个更复杂的过程，在哪里查看不太明显，最重要的是，它可以得到更多保护。
例如，Linux 可以配置为防止非特权用户进程甚至将调试器系统调用调用到由它们未启动的同一用户启动的其他进程上，并且一些发行版开始默认启用此功能。
这意味着stdin在几乎所有情况下，正确执行的数据写入至少与使用环境变量相同或更安全。
但是请注意，您必须“正确执行”。例如，这两个不会为您提供相同的安全优势：
my-command </some/path/my-secret-configcat /some/path/my-secret-config | my-command因为秘密仍然存在于磁盘上。因此，您可以获得更大的灵活性，但并没有获得更多的安全性。（但是，如果catis 实际上sudo cat或以其他方式对文件具有比 更高的特权访问权限my-command，那么这可能是一个安全优势。）
现在让我们看一个更有趣的案例：
echo "$my_secret_data" | my-command这比环境变量更安全还是更不安全？这取决于：
如果您在典型的 shell 中调用它，那么echo它可能是一个“内置”，这意味着 shell 永远不需要执行外部echo程序，并且变量在写入stdin.
但是如果你从 shell 外部调用这样的东西，那么这实际上是一个很大的安全漏洞，因为它会将变量放入执行的外部echo程序的命令行中，在许多系统上，任何其他运行的程序都可以看到它进程，即使是其他非特权用户！
因此，只要您理解这一点，并使用正确的功能来确保您直接从具有凭据的任何内容写入您的流程，stdin这可能是您拥有的最安全的选择。
TL;DR： stdin可以为您提供更小的数据泄漏“表面积”，这意味着它可以帮助您获得更高的安全性，但您是否这样做取决于您如何使用它以及其他方式您的系统已设置。
就我个人而言，我stdin尽可能用于传递秘密数据。