提升 SaaS 应用跨账户访问客户账户的方法

关键要点

本篇文章帮助独立软件供应商ISV和软件即服务SaaS提供商实现安全高效地访问客户的 Amazon Web ServicesAWS账户。我们将探讨三种提升跨账户访问实施的方法，以确保 SaaS 应用的安全性和功能正常运作。这些方法强调使用 AWS 身份与访问管理IAM角色、最小权限策略、角色链以及基于属性的访问控制ABAC等安全最佳实践。

多个独立软件供应商ISVs和软件即服务SaaS提供商需要访问其客户的 Amazon Web Services (AWS) 账户，特别是在 SaaS 产品需要访问客户环境中的数据时。SaaS 提供商在这一第三方访问场景中采用了多种变体。在某些情况下，供应商要求客户提供访问密钥和秘密密钥，但这并不推荐，因为它们是长期用户凭证，需要建立周期性旋转的流程。然而，在大多数情况下，供应商会提供集成指南，包含有关创建跨账户 AWS 身份与访问管理 (IAM) 角色的具体细节。

在所有这些场景中，作为 SaaS 供应商，您应在实施中增加必要的保护措施。在 AWS，安全性是首要任务，我们建议客户遵循最佳实践并在产品设计中融入安全措施。本文旨在帮助 SaaS 供应商，我将描述三种方法来提升您的跨账户访问实施。

为什么这很重要？

作为一名安全专家，我已经与多个 ISV 客户合作，提高他们产品的安全性，特别是在这个第三方跨账户访问的场景中。使用您的 SaaS 产品的消费者不希望授予超出产品正常运作所需的访问权限。同时，您还应维护并提供一个安全的 SaaS 产品，以保护客户和您自身的 AWS 账户免遭未授权访问或权限提升。

假设有一个简单的 SaaS 实施方案，其中客户计划使用一款 SaaS 产品。在下图所示中，该 SaaS 产品具有多个不同的组件，执行各自的功能。例如，这个 SaaS 产品可能拥有执行计算分析、存储分析和日志分析的分离组件。SaaS 提供商要求客户提供 IAM 用户凭证，并在其产品中使用这些凭证以访问客户资源。接下来，我们将探讨提升这一场景跨账户访问的三种技术。每种技术都是在前一种技术的基础上构建的，因此您可以采用渐进的方式来实现这些技术。

技术 1 使用 IAM 角色和外部 ID

如前所述，IAM 用户凭证是长期的，因此客户需要实施流程以定期旋转这些凭证并与 ISV 共享。

为了更好的选择，SaaS 产品组件可以使用 IAM 角色，IAM 角色为假定角色的组件提供短期凭证。这些凭证需要根据角色的会话持续时间设置进行刷新默认情况下一小时，以继续访问资源。IAM 角色还为审计提供了优势，因为每次 IAM 主体假定角色时，都会创建一个新的会话，这可以用于识别和审计不同会话的活动。

在使用 IAM 角色进行第三方访问时，一个重要的考虑因素是 混淆代理问题，即未授权实体可能会强迫产品组件对其他客户的资源执行某项操作。为了减轻这个问题，强烈建议在假定客户账户中的角色时使用 外部 ID 参数。建议您生成这些 外部 ID 参数，以确保它们对每个客户都是唯一的，例如，使用客户 ID 或类似属性。有关外部 ID 字符限制，请参阅 IAM 限制页面。客户将在其 IAM 角色的信任策略中使用该外部 ID，而您的产品组件将在所有 AssumeRole API 调用中将其作为参数传递给客户环境。以下是信任策略主体和条件块的示例，用于在客户账户中假定的角色：

jsonPrincipal {AWS ltSaaS 提供商的 AWS 账户 IDgt}Condition {StringEquals {stsExternalId ltSaaS 提供商分配的唯一 IDgt}}

技术 2 使用最小权限 IAM 策略和角色链

作为 IAM 最佳实践，我们建议 IAM 角色仅应拥有执行其功能所需的最小权限。当您的客户在技术 1 中创建 IAM 角色时，他们可能无意中提供了超过您产品所需的权限。这些角色可能拥有与多个 AWS 服务关联的权限，从而变得过于宽松。如果您为不同的 AWS 服务提供了细粒度的权限，您可能会达到策略大小限制或每角色的策略限制。有关更多信息，请查看 IAM 限制。因此，除了技术 1 之外，我们建议每个组件在客户账户中拥有一个单独的 IAM 角色，仅具备执行其功能所需的最小权限。

作为您集成指南的一部分，您应要求他们为这些 IAM 角色创建适当的 IAM 策略。产品组件必须有明确的职责分离和最小权限访问。例如，一个账户监控 SaaS 提供商可能会为 Amazon Elastic Compute Cloud (Amazon EC2) 监控使用一个单独的 IAM 角色，而为 AWS CloudTrail 监控另一个。您的组件也将使用您自身 AWS 账户中的单独 IAM 角色。然而，您可能想要向客户提供一个单一的集成 IAM 角色，以在他们的账户中建立与每个组件角色的信任关系。实际上，您将使用 角色链 的概念来访问客户的账户。客户端的审计机制将仅显示集成 IAM 角色的会话。

在使用角色链时，您需要注意某些陷阱和限制。您的组件将各自具有不同的角色：角色 A 将假定集成角色角色 B，然后使用角色 B 的凭证假定客户角色角色 C在客户账户中。您需要正确地定义这些角色的权限，因为在假定角色时之前角色的权限不会被传递。您可以可选地在假定角色时将一个称为会话策略的 IAM 策略文档 作为参数传递，有效权限将是传递的策略与角色附加权限的逻辑交集。有关会话策略的详细信息，请参阅 会话 策略。

使用角色链的另一个考虑是，它将 AWS 命令行界面AWS CLI或 AWS API 角色会话的持续时间限制为最长为一小时。这意味着您必须跟踪会话并每小时执行凭证刷新操作，以继续访问资源。

技术 3 使用角色标签和会话标签实现基于属性的访问控制

在您为角色链创建 IAM 角色时，您需要定义哪个实体可以假定该角色。您需要将每个组件特定的 IAM 角色添加到集成角色的信任关系中。随着您产品内组件数量的增加，您可能会达到角色信任策略的最大长度。有关更多信息，请参见 IAM 限制。

因此，除了上述两种技术外，我们建议使用基于属性的访问控制ABAC。ABAC 是一种授权策略，根据标签属性定义权限。您应使用角色标签标记所有组件 IAM 角色，并在集成角色的信任策略中使用这些 角色标签作为条件。您还可以选择在产品集成指南中提供有关使用某些角色标签标记客户 IAM 角色的说明，并修改集成角色的 IAM 策略以仅允许假定带有这些角色标签的角色。这有助于减少 IAM 策略的长度，并最大限度地降低达到 IAM 限制的风险。

jsonCondition { StringEquals {iamResourceTag/ltProductgt ltExampleSaaSProductgt}}

为了增强您产品的审计和可追溯性，一个额外的考虑是 IAM 角色会话标签。这对于使用 CloudTrail 日志事件在特定角色会话上进行警报非常有帮助。如果您的 SaaS 产品还依赖于 CloudTrail 日志，您可以利用这些会话标签来识别来自您的产品的不同会话。与角色标签不同，角色标签是附加在 IAM 角色上的标签，而会话标签是指在假定 IAM 角色时传递的键值对属性。这些标签可用于识别会话，并进一步控制或限制基于标签的资源访问。会话标签也可以与角色链一起使用。当您 在角色链中使用会话标签 时，您可以将这些键设置为可传递的，以确保它们能够传递到后续会话。相关的 CloudTrail 日志事件 将包含会话标签、可传递标签和角色也称为 主体标签。

结论

在本文中，我们讨论了三种相互关联的增量技术，这些技术对于 SaaS 提供商提高安全性和访问控制至关重要，同时在实施跨账户访问时确保客户安全。作为 SaaS 供应商，重要的是要确保您的产品遵循安全最佳实践。当您改善产品的安全性时，也是在为客户提高安全性。

要查看有关跨账户访问概念的更多教程，请访问 AWS 文档中的 IAM 角色、ABAC 和 会话标签。

如果您对此帖子有任何反馈，请在下面的评论部分中提交意见。如果您对此帖子的内容有任何疑问，请在 AWS 身份与访问管理 rePost 或 联系 AWS 支持。

想要获取更多 AWS 安全信息？请在 Twitter 上关注我们。

Ashwin Phadke

Ashwin 是一名高级解决方案架构师，与大型企业和 ISV 客户合作，构建高可用、可扩展且安全的应用程序，帮助他们成功导航云旅程。他对信息安全充满热情，并乐于为客户的安全挑战提供创造性解决方案。

标签 AWS 身份与访问管理 (IAM)、SaaS、安全博客