嘘,我需要您保守秘密:AWS Secrets Manager初探

如今,网络安全已成为大新闻已不是秘密(双关语意)。 每天,我们都会听到有关数据泄露,泄露的个人信息和密码被盗的信息。 这些事件中的许多事件都与凭据管理不当有关,例如加密密钥的不正确存储,管理员帐户默认或没有密码的数据库以及存储在GitHub或未受保护的对象存储桶中的应用程序源代码中的访问密钥。 当公司迁移到公共云时,问题变得更加复杂,因为安全实施中的错误被放大了。

亚马逊网络服务首席技术官沃纳·沃格斯(Werner Vogels)在最近的会议主题演讲中宣称“每个开发人员都应该是安全工程师”,并且“安全是每个人的责任。”以行动作为后盾,亚马逊网络服务(AWS)一直在努力推动推出新的安全服务,例如GuardDuty和Amazon S3存储桶的默认加密。 他们的安全产品组合的最新版本之一是AWS Secrets Manager,该产品最近在旧金山的AWS峰会上宣布。

得益于像Hashicorp这样的人们的努力,秘密管理一直是热门话题,甚至在AWS尚未加入游戏之前。 他们已经向IT社区介绍了有关机密的知识,以及他们使用开源工具Vault管理机密的愿景。 根据Hashicorp的定义,秘密是“您想要严格控制访问的任何内容,例如API密钥,密码,证书等。”秘密管理涉及秘密的存储,保护,生命周期管理和审核。 这包括加密机密,这样任何人都无法访问它,而无法访问解密密钥,按需或根据策略轮换凭证。 并跟踪未经授权的访问。 我认为最重要的组成部分是生命周期管理。 加密和存储秘密并不困难; 您可以仅使用加密的S3存储桶或加密的DynamoDB表来执行该任务。 但是,用户通常会面临挑战,因此要大规模管理秘密的生命周期,并确保成功定期定期旋转秘密,并在凭据遭到破坏时将其撤销。

管理机密一直很重要,但是随着云计算和微服务的采用,对机密的需求也在增加。 虽然我们以前可能只需要担心公司防火墙后面的两台服务器之一中的机密,但现在必须为公共云中的实例队列保护和管理机密。 因此,AWS看来适合进军这一市场也就不足为奇了。

根据官方用户指南,AWS Secrets Manager是“一项AWS服务,可让您更轻松地管理用于访问AWS的机密信息,例如数据库凭证,密码,第三方API密钥甚至任意文本, AWS提供的典型示例是用于访问具有共同用户凭证的大量数据库的用例。 用户可以将凭证作为加密的机密存储在AWS Secrets Manager中,而不是将这些凭证以纯文本的形式存储在需要访问这些数据库的应用程序服务器上。 然后可以修改应用程序服务器,以通过API调用以编程方式请求数据库凭据。 当凭据定期轮换使用时,Secrets Manager可以自动执行此操作,并且应用程序服务器只需很少的更改即可获取凭据。

您可以从用户指南和Randall Hunt的博客文章中获得有关功能和操作方法的更多详细信息。 相反,我想专注于体系结构以及对服务的一些观察。

Secrets Manger上的可用资源非常少,这是一项新服务所期望的。 产品页面和用户指南从本质上将Secrets Manager讨论为与一些AWS服务集成的黑匣子。 根据已发布的内容,其外观如下:

  • Secrets Manager服务负责存储秘密,并使用AWS Key Management Service(KMS)提供的密钥对秘密进行加密。
  • Lambda函数提供自动机密轮换,由机密管理器中的调度程序基于时间的事件触发
  • 如用户指南中所述,CloudTrail和CloudWatch用于监视和记录Secrets Manager,并利用简单通知服务(SNS)进行警报。

如果我想进一步推测,我认为Secrets Manager很可能是集成了AWS服务集合的无服务器应用程序。 它可能看起来像这样:

  • 我认为机密可能存储在通过KMS加密的S3存储桶中。 这似乎是存储被建模为键值对的大量机密的最合逻辑的地方。 机密命名约定符合S3对象命名约定,并且加密似乎正在映射为使用KMS的S3默认加密。
  • 在我看来,正在使用两类Lambda函数。 一组功能执行特定的管理任务,例如创建和存储机密,而第二组可以定制和添加的功能则执行自动化的生命周期管理任务,例如机密轮换。 我假设将为其他任务开箱即用地添加其他功能。
  • 如果我正确地认为Secrets Manager的所有计算都利用Lambda,则我认为AWS可能正在使用DynamoDB存储有关临时或自动运行的任务的状态信息。
  • 如用户指南中所述,CloudTrail和CloudWatch用于监视和记录Secrets Manager,并利用SNS进行警报。 由于自动轮换使用时间触发器,因此我相信CloudWatch也可用于提供该触发器。

随着关于Secrets Manager的更多细节的出现,我最终对体系结构有多大错是很有趣的。

自发布以来,我一直有机会探索AWS Secrets Manager,尽管它有一些缺点,我将在以后进行讨论,但我看到该服务的光明前景,并相信随着时间的推移它将变得更好。 历史上,AWS发布了针对特定用例的新服务,然后通过添加新功能来逐步扩展这些用例。 这是我的一些具体观察。

第一个Secrets Manager版本值得称赞,尤其是如果您大量使用AWS服务(例如KMS和Relational Database Service(RDS))时。

  • 使用控制台或CLI可以轻松开始使用Secrets Manager。 控制台界面很干净,可以很好地引导用户完成存储和旋转秘密的步骤。

创建和存储机密时生成的示例代码有助于更新将访问机密的应用程序。

此外,与AWS服务(如KMS和Identity Access and Management(IAM))的现成集成使现有AWS用户的入门非常容易。

  • 秘密管理器显然是设计为与RDS最佳配合使用的。 如果将Secrets Manager与受支持的RDS数据库之一一起使用,则创建,存储和自动旋转机密非常简单。 用于旋转的Lambda函数已经创建并可用。

如果您是RDS用户,并且当前未使用秘密管理系统,则AWS Secrets Manager的开箱即用集成功能非常引人注目。

  • AWS旨在使用户免于执行“毫不费力的繁琐工作”。通过将机密管理作为一项完全托管的服务提供,Amazon消除了用户安装和维护自己的机密管理系统的需求。 除了一个例外,我将在下一节中讨论,秘密管理器抽象出了复杂性,例如加密密钥管理。

第一版中的任何产品都会有问题,AWS Secrets Manager也不例外。 我对该服务的主要批评是,需要对许多用例具有AWS Lambda的使用知识。 请注意,我不是在这里批评Lambda的使用,而是需要了解Lambda的事实。

要将机密旋转到RDS数据库将要使用的内容之外,您需要知道如何在Lambda(AWS无服务器服务)中编写函数。 实际上,如果要轮换在EC2实例上运行并管理自己的数据库的机密,则必须编写自己的Lambda函数以自动执行机密轮换。

我希望AWS将创建新的Lambda轮换功能来解决RDS以外的用例。 但是直到那时,为非RDS用例编写Lambda的需求增加了解决方案的复杂性。

我认为,AWS Secrets Manager的版本1更多是具有某些管理功能的秘密存储,而不是完整的秘密管理系统。 我希望最终会有所改变,但就目前而言,“秘密管理器”中的管理似乎仅限于秘密轮换。 沿着这些思路,我认为缺少一些关键功能:

  • 我很失望地看到Secrets Manager不支持动态机密。 动态机密是按需生成的,通常具有附加的租约,该租约会在设置的时间后到期。 例如,只有在应用程序需要访问资源并且帐户在1小时后自动删除时才创建的IAM用户。 您将能够对数据库凭证和API密钥执行相同的操作。 以下是Hashicorp Vault如何实现动态机密的示例。

动态机密的好处包括缓解安全性差的应用程序的安全,因为应用程序安全性可能会“泄漏”日志和工件中的凭据。 由于凭证可以设置为映射到特定请求的一次性使用的一次性凭证,因此它也限制了凭证泄漏的影响。

  • 我惊讶地发现Secret Manager没有提供手动撤消机密的功能。 强制撤消或手动撤消是在危及机密的情况下用户应该能够执行的操作程序。 我希望看到用户撤销秘密的能力,该秘密将覆盖所有轮换时间表,并使该秘密中正在引用的所有凭证无效。

总体而言,AWS Secrets Manager是服务的完整版本1,对于当前正在使用或计划使用RDS的AWS用户特别有价值。 但是Secrets Manager缺少诸如Hashicorp Vault之类的产品的功能和成熟度,而Hashicorp Vault也具有不与特定的云提供商捆绑在一起的优势。但是,我期待将来的发行版中将会有什么。


最初于 2018 年4月15日 发布在 cloudarchitectmusings.com 上。