跨账户策略评估逻辑 - AWS Identity and Access Management
确定是否允许跨账户请求跨账户策略评估示例

跨账户策略评估逻辑

您可以允许一个账户中的主体访问另一个账户中的资源。这称为 cross-account access（跨账户存取）。当您允许跨账户访问时，主体所在的账户称为受信任 账户。资源所在的账户是信任 账户。

要允许跨账户访问，请将基于资源的策略附加到您要共享的资源。您还必须向在请求中充当主体的身份附加基于身份的策略。信任账户中基于资源的策略必须指定受信任账户中有权访问资源的主体。您可以指定整个账户或其 IAM 用户、联合身份用户、IAM 角色或代入角色会话。您还可以将 AWS 服务指定为主体。有关更多信息，请参阅 如何指定主体。

主体的基于身份的策略必须允许对信任服务中的资源进行请求的访问。您可以通过指定资源的 ARN 来执行此操作。

在 IAM 中，您可以将基于资源的策略附加到 IAM 角色，以允许其他账户中的主体代入该角色。角色的基于资源的策略称为角色信任策略。代入该角色之后，允许的主体可以使用生成的临时凭证访问您账户中的多个资源。此访问权限在角色的基于身份的权限策略中定义。如需了解使用角色允许跨账户访问与使用其他基于资源的策略允许跨账户访问之间的不同之处，请参阅IAM 中的跨账户资源访问。

重要

其他服务可能会影响策略评估逻辑。例如，AWS Organizations 支持可应用于一个或多个账户中的主体和资源的服务控制策略和资源控制策略。AWS Resource Access Manager 支持策略片段，用于控制允许主体对与其共享的资源执行哪些操作。

确定是否允许跨账户请求

对于跨账户请求，受信任账户 AccountA 中的请求者必须具有基于身份的策略。该策略必须允许他们向信任账户 AccountB 中的资源发出请求。此外，AccountB 中的基于资源的策略必须允许 AccountA 中的请求者访问资源。

当您发出跨账户请求时，AWS 会执行两个评估。AWS 评估信任账户和受信任账户中的请求。有关如何在单个账户中评估请求的更多信息，请参阅AWS 执行代码逻辑如何评估允许或拒绝访问的请求。仅当两个评估都返回 Allow 决策时，才允许该请求。

跨账户 评估

  1. 当一个账户中的主体发出请求以访问另一个账户中的资源时，这是一个跨账户请求。

  2. 请求主体存在于受信任账户 (AccountA) 中。当 AWS 评估此账户时，它会检查基于身份的策略以及可以限制基于身份的策略的任何策略。有关更多信息，请参阅 评估具有权限边界的基于身份的策略。

  3. 请求的资源存在于信任账户 (AccountB) 中。当 AWS 评估此账户时，它会检查附加到所请求资源的基于资源的策略，以及可以限制基于资源的策略的任何策略。有关更多信息，请参阅 评估基于身份的策略以及基于资源的策略。

  4. 仅当两个账户策略评估均允许该请求时，AWS 才允许该请求。

跨账户策略评估示例

以下示例演示了一个账户中基于资源的策略向另一个账户中的角色授予权限的情况。

假设 Carlos 是一名开发人员，在账户 111111111111 中具有名为 Demo 的 IAM 角色。他想要将文件保存到账户 222222222222 中的 amzn-s3-demo-bucket-production-logs Amazon S3 存储桶。

还假定将以下策略附加到 Demo IAM 角色。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowS3ListRead",
            "Effect": "Allow",
            "Action": "s3:ListAllMyBuckets",
            "Resource": "*"
        },
        {
            "Sid": "AllowS3ProductionObjectActions",
            "Effect": "Allow",
            "Action": "s3:*Object*",
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-production/*"
        },
        {
            "Sid": "DenyS3Logs",
            "Effect": "Deny",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::*log*",
                "arn:aws:s3:::*log*/*"
            ]
        }
    ]
}

此策略中的 AllowS3ListRead 语句允许 Carlos 查看 Amazon S3 中所有存储桶的列表。AllowS3ProductionObjectActions 语句允许 Carlos 对 amzn-s3-demo-bucket-production 存储桶中对象的完全访问权限。

此外，以下基于资源的策略（称为存储桶策略）附加到账户 222222222222 中的 amzn-s3-demo-bucket-production 存储桶。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject*",
                "s3:PutObject*",
                "s3:ReplicateObject",
                "s3:RestoreObject"
            ],
            "Principal": { "AWS": "arn:aws:iam::111111111111:role/Demo" },
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-production/*"
        }
    ]
}

此策略允许 Demo 角色访问 amzn-s3-demo-bucket-production 存储桶中的对象。该角色以创建和编辑存储桶中的对象，但不能删除。该角色无法管理存储桶本身。

当 Carlos 请求将文件保存到 amzn-s3-demo-bucket-production-logs 存储桶时，AWS 将确定应用于请求的策略。在这种情况下，附加到 Demo 角色的基于身份的策略是在账户 111111111111 中应用的唯一策略。在账户 222222222222 中，amzn-s3-demo-bucket-production-logs 存储桶没有附加基于资源的策略。AWS 评估账户 111111111111 时返回了决策 Deny。这是因为基于身份的策略中的 DenyS3Logs 语句明确拒绝访问任何日志存储桶。有关如何在单个账户中评估请求的更多信息，请参阅AWS 执行代码逻辑如何评估允许或拒绝访问的请求。

由于在一个账户中明确拒绝了请求，因此最终决策是拒绝请求。

向 amzn-s3-demo-bucket-production-logs 存储桶发出请求

假设随后 Carlos 意识到他的错误并尝试将文件保存到 Production 存储桶。AWS 首先检查账户 111111111111 以确定是否允许请求。仅基于身份的策略适用并允许请求。随后，AWS 检查账户 222222222222。仅附加到 Production 存储桶的基于资源的策略适用，并允许请求。由于两个账户均允许请求，因此最终决策是允许请求。

对 Production 存储桶的请求