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