我最近正在为安全专业考试做准备，我遇到了一个问题，即在使用 Parameter Store 存储可以保存密码的秘密数据库连接 URL 或在 Lambda 中使用 KMS 加密环境变量之间进行选择。
IMO 环境变量更可取，因为否则对于每天调用数千或数十万次的 Lambda 函数，这可能会开始花费大量成本，甚至可能导致达到帐户限制。
此外，每次调用都增加了获取参数的延迟，这可能并不重要，但仍然会加起来。一般来说，我希望看到为 Lambda 环境变量实现的参考语法以解析为 AWS SSM 参数值，类似于现在为 Cloudformation 为 SSM 和秘密管理器实现的语法。
但在那之前，考虑到成本和延迟的增加，为什么 SSM 比使用 KMS 加密环境变量更受欢迎呢？（这是我在练习考试中看到的建议）
这篇文章有一些有用的观点：
- 难以跨项目共享配置
- 难以实现细粒度的访问控制
- 【SSM Parameter Store】记录变更历史
因此，使用 SSM 通常是一种更灵活的架构。也就是说，如果这些好处真的不适用于您，那么您仍然可以使用环境变量并减少延迟，正如您所指出的那样。与其说是一个错误，不如说是另一个通常被认为更像是一种“架构良好”的方法。但特定情况可能需要其他实现。
本文提到了它带来的更好的安全性。
“虽然这种方法 [使用环境变量] 简单明了，但它存在相当大的安全缺陷 - 环境中的秘密以明文形式存在。在该进程内运行的任何其他进程、库或依赖项都可以访问已经存在的环境被多次利用。”
安全性是一个重要的考虑因素，与不太安全的替代方案相比，为提高安全性所做的大多数事情都会带来延迟或处理成本。
需要考虑的其他一些想法：
想到的最大原因是能够以解耦的方式使用您的令牌/秘密，从而允许其他服务利用相同的令牌。例如，如果您有两个 lambda 都需要使用相同的 API 令牌调用外部服务，那么您只需要更新一个地方。如果您没有这样做，并且假设令牌被轮换，那么您将需要重新配置每个 lambda 以使用新令牌，而不是对 SSM 进行一次更新。
上面提到了 SSM 相对于常规环境变量的细粒度安全性和单一事实来源的优势。
为了避免延迟的缺点，本文提供了当前从 SSM 读取参数时避免延迟的最佳实践：
基本上你需要做的是全局读取环境变量一次。相同 lambda 的后续调用已经可以访问它们，因此不需要额外的 SSM 往返。