AWS Identity and Access Management
用户指南
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 Amazon AWS 入门

策略评估逻辑

在委托人尝试使用 AWS 管理控制台、AWS API 或 AWS CLI 时,该委托人将向 AWS 发送请求。在 AWS 服务收到请求时,AWS 会完成几个步骤来确定是允许还是拒绝该请求。

  1. 身份验证 – AWS 首先对发出请求的委托人进行身份验证(如有必要)。有一些服务(如 Amazon S3)不需要此步骤,它们允许来自匿名用户的某些请求。

  2. 处理请求上下文 – AWS 处理在请求中收集的信息以确定应用于请求的策略。

  3. 评估策略 – AWS 评估所有策略类型,这会影响策略的评估顺序。

  4. 确定是允许还是拒绝请求 – AWS 然后根据请求上下文处理策略以确定是允许还是拒绝请求。

处理请求上下文

AWS 处理请求以将以下信息收集到请求上下文中:

  • 操作 – 委托人希望执行的操作。

  • 资源 – 对其执行操作的 AWS 资源对象。

  • 委托人 – 发送请求的用户、角色、联合身份用户或应用程序。有关委托人的信息包括与该委托人关联的策略。

  • 环境数据 – 有关 IP 地址、用户代理、SSL 启用状态或当天时间的信息。

  • 资源数据 – 与请求的资源相关的数据。这可能包括 DynamoDB 表名称或 Amazon EC2 实例上的标签等信息。

AWS 随后使用此类信息来查找应用于请求上下文的策略。

评估策略

AWS 将基于策略类型和类别评估应用于请求上下文的策略。AWS 支持基于身份的策略、基于资源的策略、AWS Organizations SCP 和访问控制列表 (ACL)。这些策略类型可分类为权限策略权限边界。权限策略控制所附加到的对象的权限。这些包括基于身份的策略(最常见)、基于资源的策略和 ACL。权限边界是一项高级功能,让您可以使用策略来限制委托人可以具有的最大权限。这些边界可应用于 AWS Organizations 组织或者 IAM 用户或角色。您可以通过在 AWS STS 角色代入期间传递策略来进一步减少角色会话的权限。

如果不存在权限边界或 STS 代入角色策略,则权限策略独自控制访问。如果存在多种类型,则访问权限由所有适用的策略类型的交集决定。例如,考虑具有允许所有 Amazon EC2 和 CloudWatch 操作的权限边界的角色。该角色还具有仅允许 ec2:StartInstancesec2:StopInstancess3:ListBucket 操作的权限策略。在 AWS STS 角色代入期间,管理员传递仅允许启动和停止 MyCompanyInstance Amazon EC2 实例和列出 MyCompanyBucket Amazon S3 存储桶的权限策略。在 AWS 评估这三种策略类型时,生成的访问权限是这三种策略类型的交集。在此示例中,代入角色的任何人只能启动和停止 MyCompanyInstance Amazon EC2 实例。他们无法执行仅出现在一个或两个策略类型中的操作。

AWS 在评估权限策略之前,先评估用作权限边界或在 STS 角色代入期间传递的策略(如果适用)。

策略类型的评估

在 AWS 评估用户的权限策略和权限边界时,生成的权限是这两种类别的交集。这意味着,当您向具有现有权限策略的用户添加权限边界时,您可能会减少用户可以执行的操作。或者,当您从用户删除权限边界时,您可能会增加用户可以执行的操作。

权限策略和权限边界的评估

确定是允许还是拒绝请求

当委托人向 AWS 发送请求时,AWS 执行代码将决定是应允许还是应拒绝给定请求。下面简要概述了 AWS 评估逻辑:

  • 默认情况下,所有请求都将被拒绝。(通常,始终允许使用 AWS 账户根用户 凭证创建的访问该账户资源的请求。)

  • 权限策略中的显式允许覆盖此默认设置。

  • 权限边界(AWS Organizations SCP 或者用户或角色边界)或在 AWS STS 角色代入期间使用的策略将覆盖允许。如果存在其中一个或多个项目,它们必须都允许请求。否则,将隐式拒绝它。

  • 任何策略中的显式拒绝将覆盖任何允许。

以下流程图提供了如何做出决定的详细信息。

 评估流程图
  1. 拒绝评估。决定从默认拒绝所有请求的位置开始。这称为隐式拒绝。有关更多信息,请参阅 显式拒绝和隐式拒绝之间的区别

  2. 执行代码评估账户中应用于请求的所有策略。这些包括权限策略(基于身份、基于资源和 ACL)和权限边界(AWS Organizations SCP、用户或角色边界和 STS 代入角色边界)。考虑所有策略元素。执行代码评估显式拒绝策略的顺序不重要。

  3. 在所有这些策略中,执行代码查找应用于请求的 Deny 语句。如果代码找到一个适用的显式拒绝,代码将返回拒绝决定,该过程结束。这称为显式拒绝。有关更多信息,请参阅 显式拒绝和隐式拒绝之间的区别

  4. 组织和边界。如果没有找到显式拒绝,代码将开始评估服务控制策略 (SCP) 所定义的 AWS Organizations 权限边界。如果发出请求的委托人是属于该组织成员的账户的成员,则 SCP 适用。

  5. 如果执行代码没有在适用的 SCP 中找到任何 Allow 语句,则隐式拒绝请求。代码将返回拒绝决定,该过程结束。

  6. 用户或角色权限边界。如果代码在适用的 SCP 中找到一个 Allow 语句,或者没有适用的 SCP,那么执行代码将继续。然后,它将检查适用的用户或角色的权限边界。

  7. 如果执行代码没有在适用策略中找到任何 Allow 语句,则隐式拒绝请求。代码将返回拒绝决定,该过程结束。

  8. STS 代入角色策略。如果代码在用户或角色边界中找到一个 Allow 语句,或者没有适用的用户或角色边界,则执行代码将继续。然后,它将检查使用 AWS STS 代入的角色。

  9. 如果执行代码没有在适用策略中找到任何 Allow 语句,则隐式拒绝请求。代码将返回拒绝决定,该过程结束。

  10. 权限.如果代码在角色代入期间所传递的策略中找到一个 Allow 语句,或者没有适用的策略,则执行代码将继续。然后,它将评估所有权限策略(基于身份、基于资源和 ACL)。将一起检查适用的权限策略,顺序并不重要。

  11. 如果代码在适用的权限策略中找到一个 Allow 语句,那么执行代码将返回允许决定,该过程结束。如果没有 Allow 语句,则将隐式拒绝请求。代码将返回拒绝决定,该过程结束。

如果执行代码在评估过程中的任意点遇到错误,它将生成异常并关闭。

示例评估

策略的最常见类型是基于身份的策略和基于资源的策略。

假定 Carlos 具有用户名 carlossalazar,他尝试将文件保存到 carlossalazar-logs Amazon S3 存储桶。

还假定将以下策略附加到 carlossalazar IAM 用户。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowS3ListRead", "Effect": "Allow", "Action": [ "s3:ListAllMyBuckets", "s3:HeadBucket" ], "Resource": "*" }, { "Sid": "AllowS3Self", "Effect": "Allow", "Action": "s3:*", "Resource": [ "arn:aws:s3:::carlossalazar/*", "arn:aws:s3:::carlossalazar" ] }, { "Sid": "DenyS3Logs", "Effect": "Deny", "Action": "s3:*", "Resource": [ "arn:aws:s3:::*log*", "arn:aws:s3:::*log*/*" ] } ] }

此策略中的 AllowS3ListRead 语句允许 Carlos 查看账户中的所有存储桶的列表。AllowS3Self 语句允许 Carlos 完全访问与其用户名同名的存储桶。DenyS3Logs 语句拒绝 Carlos 访问名称中包含 log 的任何 S3 存储桶。

此外,以下基于资源的策略(称为存储桶策略)附加到 carlossalazar 存储桶。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:*", "Principal": { "AWS": "arn:aws:iam::111122223333:user/carlossalazar" }, "Resource": "*" } ] }

此策略指定只有 carlossalazar 用户可以访问 carlossalazar 存储桶。

当 Carlos 请求将文件保存到 carlossalazar-logs 存储桶时,AWS 将确定应用于请求的策略。在此示例中,仅基于身份的策略和基于资源的策略适用。这些都是权限策略。由于没有任何权限边界适用,评估逻辑将减少为以下逻辑。

 评估流程图

AWS 首先检查应用于请求上下文的 Deny 语句。它找到一个,因为基于身份的策略显式拒绝 Carlos 访问用于日志记录的任何 S3 存储桶。拒绝 Carlos 访问。

假设他随后意识到自己的错误,尝试将文件保存到 carlossalazar 存储桶。AWS 检查 Deny 语句,但未找到。然后,它检查权限策略。基于身份的策略允许请求。基于身份的策略允许请求。因此,AWS 允许请求。如果其中任何一个显式拒绝了语句,则将拒绝请求。

显式拒绝和隐式拒绝之间的区别

如果适用策略包含 Deny 语句,则请求会导致显式拒绝。如果应用于请求的策略包含一个 Allow 语句和一个 Deny 语句,Deny 语句优先于 Allow 语句。将显式拒绝请求。

当没有适用的 Deny 语句但也没有适用的 Allow 语句时,会发生隐式拒绝。由于默认拒绝 IAM 用户、角色或联合身份用户访问,必须显式允许他们执行操作。否则,将隐式拒绝他们访问。

在设计授权战略时,您必须创建包含 Allow 语句的策略才能允许委托人成功发出请求。但是,您可以选择显式拒绝和隐式拒绝的任意组合。例如,您可以创建以下策略以允许管理员用户完全访问 AWS 中的所有资源,但显式拒绝访问账单。如果有人向此管理员用户添加了另一个策略以授权他们访问账单,仍会因为此显式拒绝而遭到拒绝。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" }, { "Effect": "Deny", "Action": "aws-portal:*", "Resource": "*" } ] }

或者,您可以创建以下策略来允许一个用户管理 IAM 中的用户,但不管理组或任何其他资源。隐式拒绝这些操作,就像其他服务中的操作一样。但是,如果某人向该用户添加了一个策略来允许其执行这些其他操作,则会允许。

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "iam:AttachUserPolicy", "iam:CreateUser", "iam:DeleteUser", "iam:DeleteUserPolicy", "iam:DetachUserPolicy", "iam:GetUser", "iam:GetUserPolicy", "iam:ListAttachedUserPolicies", "iam:ListUserPolicies", "iam:ListUsers", "iam:PutUserPolicy", "iam:UpdateUser" ], "Resource": "*" } }