这似乎有点“先有鸡还是先有蛋”的问题。密码像 Hashicorp Vault for Linux 这样的密码管理器。
在为一些 Linux 服务器研究这个问题时，有人聪明地问道， “如果我们将所有秘密存储在秘密存储服务中，那么我们应该将该秘密存储服务的访问秘密存储在哪里？在我们的秘密存储服务中吗？”‡
我大吃一惊，因为如果我存储秘密的所有 Linux 服务器都有其访问令牌，那么使用单独的秘密存储服务就没有意义了。
例如，如果我将我的秘密移至 Vault，我是否仍然需要将秘密存储在 Linux 服务器上的某个地方才能访问 Hashicorp Vault？
有人讨论用一些创造性的方式来解决这个问题，至少让事情比现在更好。我们可以做一些聪明的事情，比如基于 CIDR 或密码混搭的身份验证。但仍然存在安全性的权衡。例如，如果黑客获得了对我的机器的访问权限，如果访问权限是基于 CIDR 的，他们就可以进入保险库。
这个问题可能没有答案，在这种情况下，答案是“不，这没有普遍接受的灵丹妙药，发挥创造力，找到你的权衡等等”
我想要以下具体问题的答案：
是否存在一种普遍接受的方法，将密码保护到现代 Linux 服务器上的远程自动化机密存储中，例如 Hashicorp Vault？
显然，明文是不可能的。
这个问题有标准答案吗？我问这个问题的地方对吗？我也考虑过 security.stackexchange.com，但这似乎只针对方式存储 Linux 服务器机密的方法。我知道这可能看起来太笼统，或基于个人观点，因此我欢迎您提出任何可能避免这种情况的编辑建议。
‡我们笑了，但我在这里得到的答案很可能是“在保险库里”。:/ 例如，Jenkins 服务器或其他东西有一个 6 个月的可撤销密码，用于生成一次性使用的令牌，然后他们可以使用该令牌从 Vault 获取自己的短暂（会话受限）密码，从而获得一段信息。
尽管这只是解决方案的一部分，但类似这样的事情似乎是同样的道理：使用 Puppet 管理服务密码
答案1
//，首先，这里讨论的问题超出了单纯传递秘密 0 或操作术语中所谓的“安全引入”的范围。
相反，这是为了确保秘密一旦收到就得到保护。
我没有灵丹妙药来解决这个问题。但有几个纵深防御选项：
- 使用响应包装传递秘密。
- 对密钥存储的令牌设置 CIDR 限制，以使令牌只能从特定的 IP 地址集使用，并使用可靠的协议（如 PROXY（而非 X-Forwarding））将 IP 地址传递到密钥存储（例如设置token_bound_cidrs使得只有一个子网可以使用令牌。）
- 将秘密仅存储在内存中，并用mlock锁定内存。
- 如果可能的话，对秘密本身设置时间限制，甚至允许秘密只能使用一次
- 监控密钥的异常使用情况，例如，如果一次性密钥不起作用（因为已经被使用过），常规客户端应该发出警报，如果有人试图在允许的 CIDR 范围之外使用密钥，服务器也应该发出警报
- 这有点冒险，但是如果可能的话，您可以允许“蜜罐”秘密与常规秘密一起存在于服务器上，从而让系统可以“访问”一组凭据，而这些凭据仅用于记录访问和警报。
- 每次使用本地存储的机密时都需要重新进行身份验证，这意味着每次使用时都需要应用除本地存储的机密之外的其他身份验证因素，例如计算实例或工作负载独有的签名元数据，或者在 Vault 中应用 Approle
- 禁用任何类型的磁盘缓存，以防止机密信息接触任何潜在的持久存储