Aws lambda Lambda的参数存储与加密环境变量

我最近正在准备安全专业考试，我得到了一个问题，可以选择使用参数存储来存储可以保存密码的秘密数据库连接URL，或者在Lambda中使用KMS加密的环境变量

IMO环境变量更可取，因为对于每天调用数千次或数十万次的Lambda函数，这可能会开始花费大量成本，甚至可能导致达到帐户限制

此外，每次调用获取参数都会增加延迟，这可能并不重要，但会增加延迟。总的来说，我希望看到为Lambda环境变量实现的参考语法能够解析为AWS SSM参数值，类似于现在为SSM和secrets manager的Cloudformation实现的语法

---

但在此之前，考虑到成本和延迟的增加，为什么SSM比使用KMS加密环境变量更受欢迎？（这是我在实践考试中看到的建议）

想到的最大原因是能够以解耦的方式使用您的令牌/机密，从而允许其他服务利用相同的令牌。例如，如果您有两个lambda都需要使用相同的API令牌调用外部服务，那么您只需要更新一个位置。如果您没有这样做，并且假设令牌被旋转，那么您需要重新配置每个lambda以使用新令牌，而不是对SSM进行单个更新。

有一些有用的要点：

• 难以跨项目共享配置
• 难以实现细粒度访问控制
• [SSM参数存储]记录更改的历史记录

因此，使用SSM通常是一种更灵活的体系结构。也就是说，如果这些好处真的不适用于您，那么您仍然可以使用环境变量并减少延迟，正如您所指出的。与其说一个是错误的，还不如说另一个更被认为是“设计良好”的方法。但在特定情况下，可能需要其他实现

提到了它带来的更好的安全性

“虽然这种方法[使用环境变量]非常简单 简单来说，它有相当多的安全缺陷- 秘密以明文形式存在于环境中。任何其他过程， 库或进程内部运行的依赖项可以访问 已被多次利用的环境。”

安全性是一个重要的考虑因素，与安全性较差的备选方案相比，为提高安全性而做的大多数事情都会带来延迟或处理成本

需要考虑的其他一些想法：

---

上面提到了SSM相对于常规环境变量的细粒度安全性和单一真实来源优势

为了避免延迟的缺点，本文提供了当前从SSM读取参数时避免延迟的最佳实践：

---

基本上，您需要做的是在全局范围内读取一次环境变量。相同lambda的后续调用已经可以访问它们，因此不需要额外的SSM往返。

这是一个好的观点，我没有想到，大多数时候我通常只有一个lambda，但如果许多lambda都有相同的秘密，那就更尴尬了。“最后，函数执行了65毫秒，其中63.5毫秒是对参数存储的GetParametersByPath调用。”-我有时会有小于10毫秒的lambda。这不好。