对于我们的产品，我们决定实施一个秘密管理工具（AWS秘密管理器），该工具将安全地存储和管理我们的所有秘密，例如数据库凭证，密码和API密钥等。
通过这种方式，机密信息不会存储在代码，数据库或应用程序中的任何位置。我们必须提供AWS凭证-访问密钥ID和密钥访问密钥，才能以编程方式访问密钥管理器的API。
现在出现的最大问题是，在哪里保留此初始信任-用于认证AWS Secrets Manager的凭据。这是一个引导问题。同样，我们必须在秘密存储区之外，配置文件中或其他地方维护某些内容。我觉得，如果这被妥协了，那么将所有内容存储在Secret Management工具中就没有真正的意义。
我阅读了AWS开发工具包开发人员指南，并了解了一些存储AWS凭证的标准方法，例如–将它们存储在环境变量中，具有不同配置文件的凭证文件中，以及通过对Amazon EC2实例使用IAM角色。
我们不会在Amazon云中运行/托管应用程序，我们只想使用AWS云中的AWS Secrets Manger服务。因此，配置IAM角色可能不是我们的解决方案。
是否有最佳做法（或最佳地点）来保存初始Trust凭据？
答案 0 :(得分：3)
如果要从EC2实例，ECS docker容器，Lambda函数访问机密，则可以将“角色”与允许访问Secrets Manager的策略一起使用。
如果没有IAM角色选项，则可以使用联合身份验证登录来获取具有允许访问Secrets Manager的策略的临时凭据（IAM角色）。
答案 1 :(得分：1)
正如@TomaszBreś所说，如果您已经在使用Active directory or Kerberos之类的本地Auth系统，则可以使用联合身份验证。
如果包装盒上没有任何类型的凭据，则有两个选择：将凭据存储在文件中并使用文件系统权限来保护它们，或使用HSM或TPM等硬件进行加密或加密。储存您的信誉。
无论如何，当您将信用凭证存储在文件箱中（即使是AD / Kerberos）时，也应确保只有应用程序所有者才有权访问该文件箱（对于独立应用程序而不是共享CLI）。您还应该通过关闭所有不必要的软件和访问方法来强化防护。