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

IAM JSON 策略评估逻辑

策略评估基础知识

当 AWS 服务收到请求时,首先使用有关访问密钥 ID 和签名的信息验证该请求。(诸如 Amazon S3 的一些服务允许来自匿名用户的请求。)如果请求通过验证,AWS 将确定是否授权请求者执行请求的操作。

由 AWS 账户根用户创建的请求可以访问该账户中的资源。然而,如果请求是使用 IAM 用户的证书创建的,或者如果请求是使用由 AWS STS 授予的临时凭证签署的,则 AWS 将使用在一个或多个 IAM 策略中定义的许可来确定是否对用户请求授权。

注意

Amazon S3 支持访问控制列表 (ACL) 和用于存储段和数据元的资源级策略。使用 ACL 和存储桶级策略建立的权限可能会影响根用户可对存储桶执行的具体操作。有关更多信息,请参阅 Amazon Simple Storage Service 开发人员指南 中的有关使用可用访问策略选项的准则

AWS Organizations 对 IAM 策略的影响

通过 AWS Organizations 服务,您可以将企业拥有的 AWS 账户分为一组进行集中管理。如果在组织内启用了所有功能,则可对任意或全部账户应用服务控制策略 (SCP)。这些 SCP 充当“筛选器“或“护栏”,用于限制这些账户中的 IAM、用户、组和角色可以访问哪些服务和操作。如果附加到一个账户的 SCP 拒绝访问某一服务 (如 S3),则该账户中的所有用户都无法访问任何 S3 API,即使用户在该账户中拥有管理员权限也是如此。 即使是 AWS 账户根用户也不能访问 S3 API。

总之,在组织内某个账户中的 IAM 用户可以使用 组织 SCP 所允许权限与账户的管理员附加到该用户的 IAM 权限的交集。换言之,只能使用 IAM 和 组织 都允许的权限。

有关 组织 和 SCP 的更多信息,请参阅 AWS Organizations 用户指南 中的关于服务控制策略

请求上下文

当 AWS 授予请求时,将从多个源收集有关该请求的信息。

  • 委托人 (请求者),根据秘密访问密钥确定。这可能代表根用户、IAM 用户、联合用户 (通过 STS) 或担任的角色,并包含与该委托人相关联的聚合许可。

  • 环境数据,比如 IP 地址、用户代理、支持 SSL、当天时间等。此信息根据请求确定。

  • 资源数据,与请求的资源部分的信息相关。它可以包含诸如 DynamoDB 表名称、Amazon EC2 实例上的标记等信息。

此信息被收集到请求上下文,它是源自请求的信息集合。在评估期间,AWS 使用请求上下文中的值来确定是否允许或拒绝请求。例如,请求上下文中的操作是否匹配 Action 元素中的操作?如果不匹配,则拒绝请求。类似地,请求上下文中的资源是否匹配 Resource 元素中的某个资源?如果不匹配,则拒绝请求。

这也是您可以在 Condition 元素中使用的键的工作方式。例如,对于以下策略片段,AWS 将来自当前请求上下文的日期和时间用于 aws:CurrentTime 键,然后执行 DateGreaterThanDateLessThan 比较。

"Condition" : { "DateGreaterThan" : { "aws:CurrentTime" : "2013-08-16T12:00:00Z" }, "DateLessThan": { "aws:CurrentTime" : "2013-08-16T15:00:00Z" } }

类似 ${aws:username} 的策略变量的工作方式也与此相似。在以下策略片段中,AWS 从请求上下文中获取用户名称,并在发生 ${aws:username} 的位置在策略中使用它。

"Resource": [ "arn:aws-cn:s3:::mybucket/${aws:username}/*" ]

确定是否允许或拒绝请求

当创建请求时,AWS 产品决定是否应允许或拒绝给定的请求。评估逻辑遵循以下规则:

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

  • 显式允许将取代此默认设置。

  • 显式拒绝将覆盖任何允许。

评估策略的顺序对于评估结果没有影响。将评估所有策略,而且结果始终是允许或拒绝请求。

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

 评估流程图
  1. 通过假设将拒绝该请求,开始做出决定。

  2. 执行代码将评估适用于请求的所有基于用户和基于资源的策略 (根据资源、委托人、操作和条件)。

    执行代码评估策略的顺序不重要。

  3. 在所有这些策略中,执行代码将寻找一个能适用于请求的显式拒绝指令。

    即使代码找到一个适用的显式拒绝,则代码也将返回 Deny 决定,该过程结束。

  4. 如果没有找到显式拒绝,那么代码将寻找适用于请求的任何 Allow 指令。

    即使代码找到一个显式允许,则代码也将返回 Allow 决定,而且服务继续处理该请求。

  5. 如果找不到允许,最终决定为 Deny

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

以下示例说明如何使用显式拒绝来覆盖允许访问大量资源的广泛策略。假设您授予一个 IAM 组许可,以允许其使用您的 AWS 账户内任何名称以字符串 test 开头的 Amazon SQS 队列。

下图表示该队列集。

 名称以 开头的队列集 test

假设您有一个名为 test0 的队列,而您要删除组对该队列的访问权限。下图表示该队列集。

 名称以 开头的队列集,但不包含 testtest0

您可以向组添加其他策略,或者向现有策略添加其他语句,显式拒绝组访问 test0 队列。该组仍可访问所有其他名称以字符串 test 开头的队列。下图列出了策略中包含的这两份声明。

 “显式拒绝”置换“允许”的策略示例

当组中的任何用户请求使用队列 test0 时,显式拒绝将覆盖允许指令,并拒绝该用户访问此队列。

默认情况下的“拒绝”与“显式拒绝”的区别

如果策略不直接适用于请求,那么策略将导致“拒绝”的结果。例如,若用户请求使用 Amazon SQS,但适用于该用户的策略仅表示其可使用 Amazon S3,则请求将被拒绝。

若未满足声明中的条件,则策略也可导致“拒绝”的结果。如果声明中的所有条件都满足,那么根据策略中的 Effect 元素的值,策略将导致“允许”或“显式拒绝”的结果。若未满足某一条件,策略将不会指定具体的做法,则在这种情况下,结果为 Deny

例如,假设您想要阻止来自南极洲地区的请求。只要请求不是来自于南极洲地区,您编写的策略 (称作策略 A1) 将允许接受请求。下列示意图说明了该策略。

 如果请求不是来自南极洲区域,那么策略将允许请求

如果某人从美国发出请求,那么条件已经满足 (该请求不是来自南极洲)。因此,结果是 Allow。但是,如果某人从南极洲地区发出请求,那么条件未满足,因此,策略的结果将是 Deny

通过创建不同的策略 (称作策略 A2),您可以显式拒绝来自南极洲地区的访问,如下图所示。

如果请求来自南极洲地区,策略拒绝请求

如果该策略适用于从南极洲地区发送请求的用户,那么条件满足,因此,策略的结果将是 Deny

在默认情况下拒绝请求与策略中的显式拒绝的区别很重要。默认情况下,请求被拒绝,但这可以由允许置换。相反,如果策略显式拒绝请求,该拒绝无法被置换。

例如,假设有另一个策略,允许在 2010 年 6 月 1 日到达的请求。当与限制从南极洲地区访问的策略一起评估时,此策略将如何影响结果?当将基于日期的策略与上述策略 (A1 和 A2) 一起评估时,我们将对比结果。方案 1 是将策略 A1 与策略 B 一起评估,方案 2 是将策略 A2 与策略 B 一起评估。下图显示了如果于 2010 年 6 月 1 日从南极洲地区发送请求时的结果。

 覆盖默认拒绝

在方案 1 中,策略 A1 返回 Deny,因为仅在请求不是来自于南极洲地区时才允许请求;默认情况下将拒绝任何其他条件 (来自南极洲地区的请求)。策略 B 返回“允许”结果,因为请求于 2010 年 6 月 1 日到达。Policy B 返回的“允许”结果将置换 Policy A1 的“默认拒绝”结果,因此,请求获得允许。

在方案 2 中,策略 A2 返回了一个显式拒绝,如本节之前所描述的那样。此外,策略 B 返回了一个允许。然而,从策略 A2 发出的“显式拒绝”将取代从策略 B 发出的“允许”,因此该请求会被 Deny