处理请求上下文 - Amazon Identity and Access Management
了解 PARC 模型请求上下文的重要性Amazon 如何使用请求上下文使用 PARC 模型的策略评估示例
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

处理请求上下文

在 Amazon 评估和授权请求时，它会将请求信息汇编到请求上下文中。请求上下文包含可用于策略评估的任何信息。

  • 主体：发送请求的用户、角色或联合用户。有关主体的信息包括与该主体关联的策略。

  • 操作 – 主体希望执行的一个或多个操作。

  • 资源 – 对其执行操作的一个或多个 Amazon 资源对象。

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

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

将此信息与适用的策略进行比较，以确定是允许还是拒绝该请求。您可以使用主体、操作、资源和条件 (PARC) 模型组织此属性信息，以更好地了解如何评估 Amazon 策略。

了解 PARC 模型

PARC 模型基于策略语言中的四个 JSON 元素来表示请求上下文：

  • Principal – 发出请求的实体。主体代表人类用户或编程工作负载，可对身份进行验证，然后向其授予在 Amazon Web Services 账户 中执行操作的权限。

  • Action – 正在执行的操作。该操作通常会映射到 API 操作。

  • Resource – 正在对其执行操作的 Amazon 资源。

  • Condition – 允许请求必须满足的附加约束。

下面展示了 PARC 模型如何表示请求上下文的示例：

Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:
- aws:UserId=AIDA123456789EXAMPLE:BobsSession
- aws:PrincipalAccount=123456789012
- aws:PrincipalOrgId=o-example
- aws:PrincipalARN=arn:aws:iam::AIDA123456789EXAMPLE:role/HR
- aws:MultiFactorAuthPresent=true
- aws:CurrentTime=...
- aws:EpochTime=...
- aws:SourceIp=...
- aws:PrincipalTag/dept=123
- aws:PrincipalTag/project=blue
- aws:RequestTag/dept=123

请求上下文的重要性

理解请求上下文及其与策略评估的交互方式对于以下方面至关重要：

  • 排查访问问题

  • 设计有效且安全的策略

  • 了解策略授予的权限的全部范围

  • 预测不同情景下的策略评估结果

通过使用 PARC 模型可视化请求上下文，您可以更轻松地了解 Amazon 如何做出授权决策并更有效地设计策略。

Amazon 如何使用请求上下文

评估策略时，Amazon 会将请求上下文中的信息与所有适用策略中指定的信息进行比较。这包括基于身份的策略、基于资源的策略、IAM 权限边界、组织 SCP、组织 RCP 和会话策略。

对于每种策略类型，Amazon 使用请求上下文来检查以下各项：

  • 根据主体，策略是否适用于请求。

  • 是否允许对指定的资源执行请求的操作。

  • 请求上下文是否满足策略中指定的任何条件。

Amazon 如何评估策略取决于适用于请求上下文的策略类型。可在单个 Amazon Web Services 账户中使用这些策略类型。有关这些策略类型的更多信息，请参阅Amazon Identity and Access Management 中的策略和权限。要了解 Amazon 如何评估跨账户访问策略，请参阅跨账户策略评估逻辑。

  • Amazon Organizations 资源控制策略（RCP）：Amazon Organizations RCP 指定组织或组织单位（OU）中账户内的资源的最大权限。RCP 适用于成员账户中的资源，并影响主体的有效权限，包括 Amazon Web Services 账户根用户，无论主体是否属于您的组织。RCP 不适用于组织管理账户中的资源和服务相关角色进行的调用。如果存在 RCP，则基于身份和基于资源的策略授予您的成员账户中的资源的权限仅在 RCP 允许操作时才有效。

  • Amazon Organizations 服务控制策略（SCP）：Amazon Organizations SCP 指定组织或组织单位（OU）中账户内的主体的最大权限。SCP 适用于成员账户中的主体，包括每个 Amazon Web Services 账户根用户。如果 SCP 存在，仅当 SCP 允许该操作时，基于身份和基于资源的策略向成员账户中的主体授予的权限才有效。唯一的例外是组织管理账户中的主体和服务相关角色。

  • 基于资源的策略：基于资源的策略为策略中指定的主体授予权限。权限定义主体可以对策略附加到的资源执行哪些操作。

  • IAM 权限边界 – 权限边界是一项功能，它设置基于身份的策略可以授予 IAM 实体（用户或角色）的最大权限。当您设置实体的权限边界时，该实体只能执行其基于身份的策略和其权限边界同时允许的操作。某些情况下，权限边界中的隐式拒绝可能会限制由基于资源的策略所授予的权限。有关更多信息，请参阅 Amazon 执行代码逻辑如何评估允许或拒绝访问的请求。

  • 基于身份的策略 — 基于身份的策略附加到 IAM 身份（用户、用户组或角色）并向 IAM 实体（用户和角色）授予权限。如果仅基于身份的策略适用于请求，则 Amazon 检查所有这些策略以找到至少一个 Allow 。

  • 会话策略：会话策略是一些策略，在以编程方式为角色或联合身份用户创建临时会话时，这些策略将作为参数进行传递。要以编程方式创建角色会话，请使用 AssumeRole* API 操作之一。在执行该操作并传递会话策略时，生成的会话的权限是 IAM 实体的基于身份的策略与会话策略的交集。要创建联合用户会话，您需要使用 IAM 用户的访问密钥以编程方式调用 GetFederationToken API 操作。有关更多信息，请参阅 会话策略。

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

注意

借助 Amazon Organizations 声明式策略，您可在整个组织中针对给定 Amazon Web Services 服务 大规模集中声明和强制执行所需的配置。声明式策略直接应用于服务级别，因此这些策略不会直接影响策略评估请求，也不会包含在请求上下文中。有关更多信息，请参阅《Amazon Organizations User Guide》中的 Declarative policies。

使用 PARC 模型的策略评估示例

为了说明请求上下文如何与策略评估进行交互，请考虑示例策略：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:CreateBucket",
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket1",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalTag/dept": "123"
        }
      }
    }
  ]
}

在此示例中，仅当请求上下文包含 aws:PrincipalTag/dept 值“123”且资源与 amzn-s3-demo-bucket1 存储桶名称匹配时，策略才会允许 CreateBucket 操作。下表显示了 Amazon 如何使用请求上下文来评估此策略并做出授权决策。

策略 请求上下文 评估结果 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:CreateBucket",
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket1",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalTag/dept": "123"
        }
      }
    }
  ]
}
 
Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:  
    - aws:PrincipalTag/dept=123

匹配

 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:CreateBucket",
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket1",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalTag/dept": "123"
        }
      }
    }
  ]
}
 
Principal: AIDA123456789EXAMPLE
Action: s3:DeleteBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:  
    - aws:PrincipalTag/dept=123

不匹配

 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:CreateBucket",
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket1",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalTag/dept": "123"
        }
      }
    }
  ]
}
 
Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:  
    - aws:PrincipalTag/dept=321

不匹配

 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:CreateBucket",
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket1",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalTag/dept": "123"
        }
      }
    }
  ]
}
 
Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:

请求中没有 aws:PrincipalTag。

不匹配