AWS Identity and Access Management
用户指南
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 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 账户中使用以下策略类型,它们按使用频率顺序列出。有关这些策略类型的更多信息,请参阅策略和权限。要了解跨账户授权的信息,请参阅IAM 角色与基于资源的策略有何不同

  1. 基于身份的策略 – 基于身份的策略附加到 IAM 身份(用户、用户组或角色)并向 IAM 实体(用户和角色)授予权限。如果仅基于身份的策略适用于请求,则 AWS 检查所有这些策略以找到至少一个 Allow

  2. 基于资源的策略 – 基于资源的策略向指定为委托人的委托人实体(账户、用户、角色或联合身份用户)授予权限。权限定义委托人可以对策略附加到的资源执行哪些操作。如果基于资源的策略和基于身份的策略同时适用于请求,则 AWS 检查所有这些策略以找到至少一个 Allow

  3. IAM 权限边界 – 权限边界是一项高级功能,借助该功能,您可以设置基于身份的策略可以授予 IAM 实体(用户或角色)的最大权限。当您设置实体的权限边界时,该实体只能执行其基于身份的策略和其权限边界同时允许的操作。权限边界不影响基于资源的策略所授予的权限。

  4. AWS Organizations 服务控制策略 (SCP) – 组织 SCP 指定组织或组织单元 (OU) 的最大权限。SCP 最大权限适用于成员账户中实体的权限,包括每个 AWS 账户根用户。如果 SCP 存在,仅当基于身份的策略和基于资源的策略以及 SCP 允许该操作时,才向实体授予这些权限。如果权限边界和 SCP 同时存在,则边界、SCP 以及基于身份的策略必须全部允许操作。

  5. 会话策略 – 会话策略是当您以编程方式为角色或联合身份用户创建临时会话时作为参数传递的高级策略。要以编程方式创建角色会话,请使用 AssumeRole* API 操作之一。当您执行此操作并传递会话策略时,生成的会话仅具有由角色的基于身份的策略和会话策略这两者授予的权限。要创建联合身份用户会话,您使用 IAM 用户的访问密钥以编程方式调用 GetFederationToken API 操作。当您执行此操作并传递会话策略时,生成的会话仅具有由 IAM 用户的基于身份的策略和会话策略这两者授予的权限。基于资源的策略对于评估会话策略权限具有不同的影响,具体取决于用户或角色的 ARN 或会话的 ARN 是否在基于资源的策略中被列为委托人。有关更多信息,请参阅会话策略

请记住,任一项策略中的显式拒绝将覆盖允许。

评估基于身份的策略以及基于资源的策略

基于身份的策略和基于资源的策略向策略所附加到的身份或资源授予权限。当 IAM 实体(用户或角色)请求对同一账户中某项资源的访问权限时,AWS 评估由基于身份的策略和基于资源的策略授予的所有权限。生成的权限是指两种类型的权限的总和。如果基于身份的策略和/或基于资源的策略允许此操作,则 AWS 允许执行该操作。其中任一项策略中的显式拒绝将覆盖允许。


               评估基于身份的策略和基于资源的策略

评估具有权限边界的基于身份的策略

在 AWS 评估用户的基于身份的策略和权限边界时,生成的权限是这两种类别的交集。这意味着,当您通过现有基于身份的策略向用户添加权限边界时,您可能会减少用户可以执行的操作。或者,当您从用户删除权限边界时,您可能会增加用户可以执行的操作。其中任一项策略中的显式拒绝将覆盖允许。要查看有关如何使用权限边界评估其他策略类型的信息,请参阅评估具有边界的有效权限


               评估基于身份的策略和权限边界

评估具有 组织 SCP 的基于身份的策略

当 AWS 评估用户的基于身份的策略和用户账号所属组织的 SCP 时,生成的权限是两个类别的交集。这意味着,操作必须由基于身份的策略和 SCP 同时允许。其中任一项策略中的显式拒绝将覆盖允许。


               评估基于身份的策略和 SCP

确定是允许还是拒绝账户内的请求

当委托人向 AWS 发送请求以访问与委托人实体所在的相同账户中的资源时,AWS 执行代码将决定是应允许还是拒绝给定的请求。AWS 收集适用于请求上下文的所有策略。下面概括介绍了单个账户中有关这些策略的 AWS 评估逻辑。

  • 默认情况下,所有请求都被隐式拒绝。(或者,默认情况下,AWS 账户根用户 拥有完全访问权限。)

  • 基于身份或基于资源的策略中的显式允许将覆盖此默认值。

  • 如果存在权限边界、组织 SCP 或会话策略,它可能会使用隐式拒绝覆盖允许。

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

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


            评估流程图
  1. 拒绝评估 – 默认情况下,所有请求都被拒绝。这称为隐式拒绝。AWS 执行代码评估账户中应用于请求的所有策略。其中包含 AWS Organizations SCP、基于资源的策略、IAM 权限边界、角色会话策略和基于身份的策略。在所有这些策略中,执行代码查找应用于请求的 Deny 语句。这称为显式拒绝。如果代码找到一个适用的显式拒绝,则代码将返回最终决定拒绝。如果没有显式拒绝,则代码会继续。

  2. 组织 SCP – 然后,代码评估适用于请求的 AWS Organizations 服务控制策略 (SCP)。如果请求是在 SCP 附加到的账户中发出的,则 SCP 适用。如果执行代码没有在 SCP 中找到任何适用的 Allow 语句,则隐式拒绝请求。代码将返回拒绝最终决定。如果没有 SCP,或者 SCP 允许所请求的操作,则代码继续。

  3. 基于资源的策略 – 如果请求的资源具有基于资源的策略,该策略允许委托人实体执行请求的操作,代码将返回最终决定允许。如果没有基于资源的策略,或者如果策略不包含 Allow 语句,则代码会继续。

    注意

    如果您将 IAM 角色或用户的 ARN 指定为基于资源的策略的委托人,然后有人使用会话策略为角色或联合身份用户创建临时会话,则上述逻辑的行为有所不同。有关更多信息,请参阅会话策略

  4. IAM 权限边界 – 执行代码随后会检查委托人使用的 IAM 实体是否具有权限边界。如果用于设置权限边界的策略不允许所请求的操作,则请求会被隐式拒绝。代码将返回拒绝最终决定。如果没有权限边界,或者权限边界允许所请求的操作,则代码继续。

  5. 会话策略 – 代码随后会检查委托人实体是否在使用通过传递会话策略所代入的会话。您可以传递会话策略,同时使用 AWS CLI 或 AWS API 为某个角色或联合身份用户获取临时凭证。如果会话策略存在但不允许所请求的操作,则请求会被隐式拒绝。代码将返回拒绝最终决定。如果没有会话策略,或者策略允许所请求的操作,则代码继续。

  6. 基于身份的策略 – 代码随后会检查委托人实体的基于身份的策略。对于 IAM 用户,这包括用户策略和来自用户所属组的策略。如果任何适用的基于身份的策略中的任何语句允许所请求的操作,则执行代码将返回最终决定允许。如果没有语句允许所请求的操作,则请求会被隐式拒绝,代码将返回最终决定拒绝

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

基于身份的策略和基于资源的策略评估示例

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

假定 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": "*" } }