问题描述
我最近已经准备好参加安全专业考试，并且遇到一个问题，可以选择使用参数存储来存储可以保存密码的秘密数据库连接URL，还是在Lambda中使用KMS加密的环境变量。
IMO环境变量是可取的，因为否则，对于每天调用成千上万次的Lambda函数，这可能会花费大量成本，甚至可能导致达到帐户限制。
此外，每次调用获取参数都增加了延迟，这可能并不重要，但总的来说还是会增加。通常，我希望看到为Lambda环境变量实现的引用语法，以解析为AWS SSM参数值，类似于现在为SSM和Secrets Manager的Cloudformation实现的值。
但是在此之前，考虑到成本增加和延迟增加，为什么SSM优先于使用KMS加密的环境变量？ （这是我在练习考试中看到的推荐内容）
解决方法
想到的最大原因是能够以分离的方式使用令牌/秘密，从而允许其他服务利用相同的令牌。例如，如果您有两个lambda，它们都需要使用相同的API令牌调用外部服务，那么您只需要更新一个位置即可。如果您没有这样做，并且可以说令牌已经旋转，那么您将需要重新配置每个lambda以使用新令牌，而不是对SSM进行单个更新。
,This article有一些要点：
- 很难在项目之间共享配置
- 难以实施细粒度的访问控制
- [SSM参数存储]记录更改的历史记录
因此，使用SSM通常是更灵活的体系结构。就是说，如果您确实无法获得这些好处，那么您仍然可以使用环境变量并减少延迟，如您所指出的那样。一个人的错误并不多，但一般来说，另一种错误更像是一种“结构合理”的方法。但是具体情况可能需要其他实现方式。
This article提到了它带来的更好的安全性。
“尽管此方法[使用环境变量]很简单且 简单明了，但它具有相当大的安全缺陷- 机密在环境中以明文形式存在。任何其他过程， 库或在进程内部运行的依赖项可以访问 已经被多次利用的环境。”
安全性是一个重要的考虑因素，与不那么安全的替代方案相比，大多数用于提高安全性的措施都会带来延迟或处理成本。
要考虑的其他一些想法：
- https://dev.to/dvddpl/where-do-you-keep-credentials-for-your-lambda-functions-5dno
- https://www.stackery.io/blog/serverless-secrets/
SSM 相对于常规 env var 的细粒度安全性和单一真实来源优势已在上面作为优势提到。
为了避免延迟的缺点，本文提供了当前从 SSM 读取参数时避免延迟的最佳实践：
基本上你需要做的是在全局读取一次环境变量。同一 lambda 的后续调用已经可以访问它们，因此不需要额外的 SSM 往返。