四种在AWS中授予跨账户访问权限的方法 安全博客

在 AWS 中授予跨帐户访问的四种方法

主要重点

在随著你的 Amazon Web Services (AWS) 环境增长时，授予跨帐户访问的需求会随之发生。这可能是因为需要在多个 AWS 帐户之间进行集中管理、在组织内的团队或项目之间共享资源，或是与第三方服务整合。然而，授予跨帐户访问需要仔细考虑安全性、可用性和可管理性的要求。

在本篇文章中，我们将探讨使用基于资源的策略授予跨帐户访问的四种不同方法。每种方法都有其特定的权衡，最佳选择取决于你的具体需求和使用案例。

评估不同的授予跨帐户访问技术

跨帐户访问 是通过 基于身份的策略和基于资源的策略 在 AWS 身份与访问管理 (IAM) 中授予的。基于身份的策略附加到 IAM 角色上，而基于资源的策略则附加到资源，如 Amazon 简单储存服务 (Amazon S3) 桶和 AWS 金钥管理服务 (AWS KMS) 键。基于资源的策略要求你指定一个或多个被允许访问该资源的主体IAM 用户或角色。

在基于资源的策略中如何指定主体会影响你解决方案在某些方面的机密性和可用性。了解这种影响并为你的使用案例做出正确的权衡是本篇文章的重点。

示例场景

假设你在你的 AWS 帐户帐户 A中有一个 S3 桶，需要让其他 AWS 帐户帐户 B中的不同主体访问。对于此场景，我们假设帐户 B 中的主体在其基于身份的策略中已有访问 S3 所需的权限，我们将重点关注在帐户 A 中编写基于资源的策略。虽然这里解释的方法使用的是 Amazon S3，但所讨论的概念适用于所有支持基于资源的策略的 AWS 服务。接下来的几个部分，我们将逐步介绍四种授予此场景跨帐户访问的方法，并讨论每种方法的权衡。

方法 1：使用资源策略的 Principal 元素授予特定 IAM 角色访问权限

在这个示例中，你使用 S3 桶策略通过在帐户 A 的策略中指定 IAM 角色的 Amazon 资源名称ARN来授予帐户 B 中的特定 IAM 角色RoleFromAccountB访问权限。

json{ Version 20121017 Statement [ { Sid AllowRoleInThePrincipalElement Principal { AWS arnawsiam111122223333role/RoleFromAccountB } Effect Allow Action s3GetObject Resource arnawss3amzns3demobucketaccounta/ } ]}

使用此桶策略，如果帐户 B 中的人删除或重新创建了角色RoleFromAccountB，那么该角色将无法再访问 amzns3demobucketaccounta 桶，即使该角色以相同名称重新创建。原因在于当你保存此策略时，角色 ARN 映射到了该角色的 唯一 ID。

此行为是有意的。策略只能让你在创建策略时设定的特定角色实例访问该资源。这帮助防止在删除角色后未更新你的资源策略而导致的未经授权访问。这种行为也会造成可用性风险，因为该角色在重新创建时将拥有新的唯一 ID，再也无法访问该桶。

你可能考虑选择此方法的情况：

方法 2：使用资源策略的 Principal 元素授予整个帐户访问权限

在这个示例中，你在资源策略的 Principal 元素中授予对特定帐户的访问权限。此帐户 A 的基于资源的策略允许帐户 B 中任何拥有授予他们读取对象权限的基于身份的策略的用户或角色。

注意： 你可以在 Principal 元素中使用 Principal {AWS 111122223333} 或 Principal {AWS arnawsiam111122223333root}，这两者是等效的。

json{ Version 20121017 Statement [ { Sid AllowAccountInThePrincipalElement Principal { AWS 111122223333 } Effect Allow Action s3GetObject Resource arnawss3amzns3demobucketaccounta/ } ]}

这种基于资源的策略避免了方法 1 中所讨论的潜在可用性问题。如果帐户 B 中的需要访问该桶的角色被重新创建，则在角色重新创建后仍将保留其访问权限。原因在于你没有在 Principal 元素中指定角色，而是指定了一个帐户。如果使用方法 2，你必须能够接受将访问控制决定授予拥有该帐户的拥有者帐户 B。

你可能考虑选择此方法的情况：

方法 3：使用 awsPrincipalArn 条件授予特定 IAM 角色访问权限

此方法扩展了方法 2，添加了一个条件，仅授予特定 IAM 角色的访问权限。与方法 2 相似，你在 Principal 元素中使用帐户号码作为值，但还使用 awsPrincipalArn 条件键来限制访问到帐户 B 中的特定主体。

awsPrincipalArn 条件键是全局条件键，将发送请求的主体的 ARN 与你在策略中指定的 ARN 进行比较。对于 IAM 角色，请求上下文返回角色的 ARN，而不是假设该角色的用户的 ARN。

json{ Version 20121017 Statement [ { Sid AllowAccountInPrincipalAndRoleInPrincipalArn Principal { AWS 111122223333 } Effect Allow Action s3GetObject Resource arnawss3amzns3demobucketaccounta/ Condition { ArnEquals { awsPrincipalArn arnawsiam111122223333role/RoleFromAccountB } } } ]}

此策略具有方法 2 中的相同可用性优势：存取此资源将在角色被重新创建后继续存在。因为当角色在 Principal 元素中使用时会转换为其唯一标识符，但当在条件中使用时不会转换。结果，方法 3 提供了可用性和安全性之间的平衡。

你可能考虑选择此方法的情况：

方法 4：授予整个 AWS Organization 组织的访问权限

此方法针对不同的用例，并不是前面列出方法的替代方案。如果你有一个资源例如 S3 桶，希望与整个组织共享，但不想与组织外的任何人共享，则可使用此方法。

json{ Version 20121017 Statement [ { Sid AllowAccessToAnEntireOrganization Principal { AWS } Effect Allow Action s3GetObject Resource arnawss3amzns3demobucketaccounta/ Condition { StringEquals { awsPrincipalOrgId o12345 } StringNotEquals { awsPrincipalAccount {awsResourceAccount} } } } ]}

在基于资源的策略中，无法通过 Principal 元素指定组织，因此必须使用 awsPrincipalOrgId 条件键来限制访问到特定组织。在此策略中，你在 Principal 元素中指定了通配符，表示任何人都可以访问该桶。接著，条件将“任何人”减少到那些属于指定组织并具有允许他们访问的基于身份的策略的 AWS 帐号主体。

你还可以添加额外的条件块，通过使用 策略变量 将 awsPrincipalAccount 条件键与 awsResourceAccount 条件键 进行比较。这个额外的条件块是可选的，排除了拥有此桶的帐户帐户 A。这样做的原因是，帐户 A 中的主体仍然需要在其基于身份的策略中明确的允许声明才能访问该桶。如果选择不排除此 awsPrincipalAccount 比较，帐户 A 中的主体将在没有其基于身份的策略中的明确允许声明的情况下访问该桶。

你可能考虑选择此方法的情况：

结论

选择授予跨帐户访问的方法需要仔细考虑你的需求和使用案例。本文中讨论的四种方法各有优缺点。理解这些方法及其影响，可以帮助你决定最合适的跨帐户访问策略。记得定期审查和审计你的基于资源的策略，以确保它们符合你的安全和访问要求。

要了解基于资源的策略如何与 Amazon S3 一起工作，请参阅博客文章 IAM 策略和桶策略与 ACL！对 S3 资源的控制访问。

如果你对这篇文章有任何意见，请在 评论 部分中提交。若对此文章有问题，联络 AWS 支持。

评论