# AWS 合作伙伴的 IAM 临时委派
<a name="access_policies-temporary-delegation-partner-guide"></a>

## 概述
<a name="temporary-delegation-partner-overview"></a>

IAM 临时委派使 AWS 客户能够通过交互式指导工作流程将 AWS 合作伙伴产品无缝载入和/或集成到其 AWS 环境中。客户可以授予 AWS 合作伙伴有限的临时访问权限，以配置所需的 AWS 服务，从而减少载入摩擦并加快价值实现时间。

IAM 临时委派使合作伙伴能够：
+ 通过自动资源预置简化客户载入
+ 通过消除手动配置步骤来降低集成复杂性
+ 通过透明、经客户批准的权限建立信任
+ 使用权限边界实现具有长期访问模式的持续运行

## 工作原理
<a name="temporary-delegation-how-it-works"></a>

1. *合作伙伴创建委派请求*：合作伙伴创建请求，指定其需要哪些权限以及持续多长时间

1. *AWS 管理控制台中的客户审查*：客户可以准确查看合作伙伴请求的权限和原因

1. *客户批准*：客户批准请求并发放交换令牌。令牌将发送给此指定 SNS 主题的合作伙伴。

1. *合作伙伴接收临时凭证*：合作伙伴交换临时 AWS 凭证的令牌

1. *合作伙伴配置资源*：合作伙伴使用凭证在客户账户中设置所需的资源

## 合作伙伴资格认证
<a name="temporary-delegation-partner-qualification"></a>

要获得临时委派集成资格，合作伙伴必须满足以下要求：
+ *ISV Accelerate 参与*：您必须加入 [ISV Accelerate（ISVA）](https://aws.amazon.com/partners/programs/isv-accelerate/)计划。
+ *AWS Marketplace 上架商品*：您的产品必须已在 AWS Marketplace 上架，并带有“已在 AWS 上部署”徽章。

## 激活流程
<a name="temporary-delegation-onboarding-process"></a>

完成以下步骤以将临时委派集成到您的产品中：

1. *第 1 步：查看要求*

   查看此文档以了解资格认证要求并填写下面的合作伙伴问卷。

1. *第 2 步：提交您的载入请求*

   发送电子邮件至 aws-iam-partner-onboarding@amazon.com 或联系您的 AWS 代表。请随附填好的合作伙伴问卷，包括下面表格中的所有必填字段。

1. *第 3 步：AWS 验证和审查*

   AWS 会：
   + 验证您是否符合资格认证标准
   + 审查您的策略模板和权限边界
   + 提供您所提交构件的反馈

1. *第 4 步：优化您的策略*

   回复 AWS 反馈，根据需要提交更新的策略模板或权限边界。

1. *步骤 5：完成注册*

   获得批准后，AWS 将：
   + 为您指定的账户启用 API 访问权限
   + 共享您的策略模板和权限边界的 ARN（如果适用）

   载入完成后，您将收到确认信息。然后，您可以从注册的账户访问临时委派 API、CreateDelegationRequest 和 GetDelegatedAccessToken，并开始将委派请求工作流程集成到产品中。

## 合作伙伴问卷
<a name="temporary-delegation-partner-questionnaire"></a>

下表列出合作伙伴载入所需的信息：


| 信息 | 说明 | 必填 | 
| --- | --- | --- | 
| 合作伙伴中心账户 ID | 您在 [AWS 合作伙伴中心](https://partnercentral.awspartner.com/partnercentral2/s/login)注册 AWS 账户的账户 ID。 | 是 | 
| PartnerId | [AWS 合作伙伴中心](https://partnercentral.awspartner.com/partnercentral2/s/login)提供的合作伙伴 ID。 | 否 | 
| AWS Marketplace 产品 ID | [AWS 合作伙伴中心](https://partnercentral.awspartner.com/partnercentral2/s/login)所提供产品的产品 ID。 | 是 | 
| AWS accountIDs | 您要用于调用临时委派 API 的 AWS 账户 ID 列表。此列表应包含您的生产账户和非生产/测试账户。 | 是 | 
| 合作伙伴名称 | 客户查看您的临时委派请求时，此名称会在 AWS 管理控制台中向其显示。 | 是 | 
| 联系电子邮件 | 可用于与您联系集成相关事宜的一个或多个电子邮件地址。 | 是 | 
| 请求者域 | 您的域（例如 www.example.com） | 是 | 
| 集成描述 | 简要描述您希望使用此功能解决的使用案例。您可以包含指向您的文档或其他公开材料的参考链接。 | 是 | 
| 架构图 | 展示您的集成使用案例的架构图。 | 否 | 
| 策略模板 | 您必须为此功能注册至少一个策略模板。策略模板定义您要在客户 AWS 账户中请求的临时权限。有关更多信息，请参阅“策略模板”部分。 | 是 | 
| 策略模板名称 | 要注册的策略模板的名称。 | 是 | 
| 权限边界 | 如果您希望使用临时权限在客户的账户中创建 IAM 角色，则必须向 IAM 注册权限边界。权限边界将附加到您创建的 IAM 角色上，以限制该角色的最大权限。您可以使用选定的 AWS 托管策略作为权限边界，也可以注册新的自定义权限边界（JSON）。有关更多信息，请参阅“权限边界”部分。 | 否 | 
| 权限边界名称 | 权限边界的名称。格式为：arn:aws:iam::partner:policy/permission\$1boundary/<partner\$1domain>/<policy\$1name>\$1<date> 策略名称必须包含创建日期作为后缀。创建权限边界后，该名称将无法更新。如果您使用现有的 AWS 托管策略，请改为提供托管策略 ARN。 | 否 | 
| 权限边界描述 | 权限边界的描述。创建权限边界后，此描述将无法更新。 | 否 | 

# 了解您的集成
<a name="temporary-delegation-understanding-integration"></a>

完成载入流程后，您可以构建与 IAM 临时委派的集成。完整的集成通常涉及三个主要工作类别：

## 1. 用户体验和工作流程设计
<a name="temporary-delegation-user-experience"></a>

在合作伙伴应用程序中构建前端体验，指导客户完成临时委派工作流程。合作伙伴应用程序应该：
+ 提供清晰的载入或配置流程，客户可以在其中授予临时访问权限。明确标注此操作，例如“使用 IAM 临时委派进行部署”。
+ 使用 CreateDelegationRequest API 返回的控制台链接将客户重定向到 AWS 管理控制台以查看和批准委派请求
+ 提供适当的消息，说明正在请求哪些权限以及请求的原因。客户可以在委派请求详细信息页面上看到此消息。
+ 客户在 AWS 中完成批准后，处理其返回您应用程序的流程。

## 2. API 集成
<a name="temporary-delegation-api-integration"></a>

使用 IAM 临时委派 API 发送和管理委派请求。注册 AWS 账户后，您可访问以下 API：
+ *IAM CreateDelegationRequest*：为客户的 AWS 账户创建委派请求。此 API 会返回一个控制台链接，您可以将客户重定向到该链接以审查和批准请求。
+ *AWS STS GetDelegatedAccessToken*：在客户批准您的委派请求后检索临时 AWS 凭证。使用这些凭证在客户的账户中执行操作。

您的集成应处理委派请求的整个生命周期，包括创建请求、监控其状态以及在获得批准后检索临时凭证。

## 3. 资源配置与编排
<a name="temporary-delegation-resource-configuration"></a>

获得临时凭证后，编排必要的工作流程以配置客户 AWS 账户中的资源。这可能包括：
+ 直接调用 AWS 服务 API 创建和配置资源
+ 使用 AWS CloudFormation 模板部署基础设施
+ 创建用于持续访问的 IAM 角色（需要使用权限边界）

您的编排逻辑应具有幂等性，并且可以从容地处理故障，因为客户可能需要重试或修改其委派批准。

# 了解权限
<a name="temporary-delegation-understanding-permissions"></a>

作为功能载入流程的一部分，您需要向 IAM 注册策略，这些策略定义您要在客户 AWS 账户中请求的权限。注册流程为客户提供了更加一致的体验，并有助于避免策略制定中的常见陷阱。

在注册期间，AWS 根据一组验证来评估您的策略。这些验证旨在标准化策略格式和结构，并提供针对已知反模式的基本保护。验证还可以降低权限升级、意外跨账户访问以及广泛访问客户账户中高价值资源的风险。

## 权限类型
<a name="temporary-delegation-permission-types"></a>

AWS 将考虑两类权限：临时权限和长期权限。

### 临时权限
<a name="temporary-delegation-temporary-permissions"></a>

临时权限限制分配给任何临时委派访问会话的权限。临时权限如应用于委派会话的策略模板中所述。这些模板支持您在创建委派请求时提供的参数。这些参数值随后将绑定到会话。临时权限的工作方式与 AWS STS 目前提供的会话策略相同：这些策略限制了底层用户的能力，但不授予任何其他访问权限。有关更多信息，请参阅 AWS STS 文档中的会话策略。

### 长期权限
<a name="temporary-delegation-long-term-permissions"></a>

长期权限限制通过临时访问创建或管理的任何角色的权限。长期权限以 IAM 权限边界的形式实现。作为载入的一部分，您可以向 AWS 提交一个或多个权限边界。获得批准后，AWS 将与您共享一个策略 ARN，供您在策略中引用。

这些边界策略有两个值得注意的特征。首先，它们是不可变的。如果要更新权限，您可以注册新的权限边界。然后，您可以通过发送新的委派请求将新权限边界附加到客户的角色。其次，这些策略并非模板化。由于相同的边界策略是全局共享的，因此无法根据每个客户进行更改。

**重要**  
权限边界的最大大小限制为 6144 个字符。

**注意**  
如果您想更新权限边界或策略模板，请通过 aws-iam-partner-onboarding@amazon.com 与 IAM 联系。注册新的权限边界后，您可以向客户发送委派请求，以更新 IAM 角色并附加新注册的权限边界。有关更多详细信息，请参阅“示例”部分。

## 示例使用案例：数据处理工作负载
<a name="temporary-delegation-example-use-case"></a>

假设产品提供商在客户账户中运行数据处理工作负载。该提供商需要在初始载入期间设置基础设施，还需要持续访问权限才能运行工作负载。

*临时权限（用于初始设置）：*
+ 创建 Amazon EC2 实例、VPC 和安全组
+ 创建用于处理后数据的 Amazon S3 存储桶
+ 创建用于持续运行的 IAM 角色
+ 将权限边界附加到 IAM 角色

*长期权限（用于持续运行、具有权限边界的 IAM 角色）：*
+ 启动和停止 Amazon EC2 实例以运行处理作业
+ 从 Amazon S3 存储桶读取输入数据
+ 将处理的结果写入 Amazon S3 存储桶

临时权限仅在载入期间使用一次，用于配置基础设施。在此过程中创建的 IAM 角色具有权限边界，其最大权限仅限于持续工作负载管理所需的操作。这样便可确保即使修改了角色的策略，也不会超过边界中定义的权限。

# 策略评估指南
<a name="temporary-delegation-policy-evaluation-guidelines"></a>

AWS 将根据一组指南评估您提交的策略。相同的评估指南适用于策略模板和权限边界，但会酌情注明细微的差异。

出于评估目的，我们将服务分为不同的组。最重要的区别在于管理访问权限、凭证和密钥安全敏感型服务。授予对这些服务访问权限的策略需要严格限定于正在进行的工作。安全敏感型服务包括以下服务：AWS Identity and Access Management（IAM）、AWS Key Management Service（KMS）、AWS Resource Access Manager（RAM）、AWS IAM Identity Center、AWS Organizations 和 AWS Secrets Manager。

第二个区别是可以跨账户边界访问数据的服务。这些服务的策略必须包括保护措施，以防止意外的跨账户访问。

## 通用验证
<a name="temporary-delegation-common-validations"></a>

所有策略语句必须遵循以下指南：
+ 所有语句都必须依次包含 Effect、Action（或 NotAction）、Resource 和 Condition 字段
+ 单个语句中的所有操作必须按字母顺序列出
+ 策略中包含的所有 ARN 都必须遵循相关服务公共文档中定义的语法
+ NotAction 字段只能在 Deny 语句中使用
+ Allow 语句中的 Action 必须包含服务代码。不允许使用通用通配符 ("\$1")

## 安全敏感型服务限制
<a name="temporary-delegation-security-sensitive-restrictions"></a>

以下限制适用于上述安全敏感型服务：
+ Allow 语句中的 Action 必须比 [service] 更具体：\$1
+ 临时访问策略模板的 Allow 语句中的 Action 不得包含通配符
+ iam:PassRole 或 iam:CreateServiceLinkedRole 等敏感操作需要额外的范围限制，例如特定资源或条件检查。这些操作包括：
  + IAM 角色传递
  + IAM 角色修改操作
  + IAM 策略修改操作
  + AWS KMS 写入或加密操作
  + AWS RAM 写入或共享操作
  + 用于检索或修改密钥或者修改资源策略的 AWS Secrets Manager 操作
+ 可能使用通配符资源的其他操作，例如 iam:ListUsers 或 iam:GetPolicy
+ 管理凭证的操作（例如 iam:CreateAccessKey）将被阻止

## IAM 特定限制
<a name="temporary-delegation-iam-specific-restrictions"></a>

对于 IAM：
+ 只允许对 IAM 角色和策略执行有限的写入操作。您无法请求对用户、组和证书等其他 IAM 资源的权限。
+ 策略附件或内联策略管理操作仅限于具有权限边界的角色。权限边界必须由合作伙伴提供，或者位于允许的 AWS 托管策略列表中。如果 AWS 托管策略未授予高权限或管理权限，则可能会允许这些策略。例如，针对特定工作职能的 AWS 托管策略或 SecurityAudit 策略可能可接受。AWS 将在载入过程中根据具体情况审查每个 AWS 托管策略。
+ 只允许对具有以下合作伙伴特定路径的策略进行策略管理：arn:aws:iam::@\$1AccountId\$1:policy/partner\$1domain.com/[feature]\$1
+ 标签只能在资源创建期间应用，并且仅用于角色和策略
+ iam:PassRole 检查必须匹配特定名称或路径前缀

## AWS STS 特定限制
<a name="temporary-delegation-sts-specific-restrictions"></a>

对于 AWS STS：
+ sts:AssumeRole 必须限定为特定角色 ARN、角色 ARN 前缀，或仅限于一组账户或组织 ID /组织单位

## IAM Identity Center 限制
<a name="temporary-delegation-identity-center-restrictions"></a>

对于 AWS IAM Identity Center，将阻止以下操作：
+ 所有涉及权限管理的操作（例如，sso:AttachCustomerManagedPolicyReferenceToPermissionSet）
+ AWS Identity Store 的用户、组和成员资格修改
+ 标签管理

## AWS Organizations 限制
<a name="temporary-delegation-organizations-restrictions"></a>

对于 AWS Organizations，只允许读取操作。

## 其他服务特定验证
<a name="temporary-delegation-additional-service-validations"></a>
+ 获取密钥或凭证的操作（例如 glue:GetConnection 或 redshift:GetClusterCredentials）必须包含匹配完整 ARN、ARN 前缀或标签的条件
+ 对于 Amazon Redshift：redshift:GetClusterCredentials 只允许对特定数据库名称使用，而 redshift:GetClusterCredentialsWithIAM 只允许对特定工作组名称使用

**注意**  
管理账户中的 IAM 资源时，我们建议使用包含您名称的路径，例如 arn:aws:iam::111122223333:role/partner.com/rolename。这将有助于区分与您的集成关联的资源，让客户更轻松地进行发现、审计和分析。

## 跨账户访问要求
<a name="temporary-delegation-cross-account-requirements"></a>

可能允许跨账户访问的语句必须至少包含以下各项之一：
+ 指定资源账户或组织的条件（例如，与一个或多个预期值匹配的 aws:ResourceOrgId）
+ 包含特定账户的资源字段（例如，arn:aws:sqs:\$1:111122223333:\$1）
+ 包含非通配符账户和完整资源名称（例如，arn:aws:s3:::full-bucket-name）的资源字段

**注意**  
跨账户访问是一项敏感功能，需要明确的业务理由。AWS 将在载入过程中仔细审查是否需要跨账户访问。

# 策略模板
<a name="temporary-delegation-policy-templates"></a>

策略模板是一种新的 IAM 构造，旨在定义合作伙伴在客户账户中请求的临时权限。与常规 IAM 策略一样，其使用包含 Effect、Action、Resource 和 Condition 元素的语句来定义权限。关键区别在于，策略模板包含的参数（例如 @\$1bucketName\$1）在您创建委派请求时会替换为实际值。

## 策略模板工作原理
<a name="temporary-delegation-how-policy-templates-work"></a>

作为载入过程的一部分，您可以向 AWS 注册策略模板。AWS 为每个模板分配一个唯一的 ARN，您在创建委派请求时会引用该 ARN。

创建委派请求时，您将指定：
+ 策略模板 ARN
+ 要替换到模板中的参数值

AWS 将模板与您的参数值相结合，生成标准 IAM 策略。客户在批准您的委派请求时会审查这一最终呈现的策略，从而确切地了解将授予哪些权限。

**注意**  
最终呈现策略的最大大小限制为 2048 个字符。

以下是一个简单的示例，展示模板替换的工作原理。

策略模板：

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject"
            ],
            "Resource": "arn:aws:s3:::@{bucketName}/*"
        }
    ]
}
```

委派请求中提供的参数：

```
{
    "Name": "bucketName",
    "Values": ["customer-data-bucket"],
    "Type": "String"
}
```

最终呈现的策略（客户看到的内容）：

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject"
            ],
            "Resource": "arn:aws:s3:::customer-data-bucket/*"
        }
    ]
}
```

## 模板语法
<a name="temporary-delegation-template-syntax"></a>

策略模板使用两项关键功能来提供灵活性：参数替换和条件语句。参数替换允许您在模板中定义占位符，这些占位符在创建委派请求时会替换为实际值。条件语句允许您根据参数值包含或排除整个策略语句。

### 参数替换和类型
<a name="temporary-delegation-parameter-substitution"></a>

使用 @\$1parameterName\$1 语法在策略模板中定义参数。创建委派请求时，您必须指定每个参数的类型。

#### 字符串
<a name="temporary-delegation-string-type"></a>

直接替换到模板中的单个值。

模板：

```
"Resource": "arn:aws:s3:::@{bucketName}/*"
```

参数：

```
{
    "Name": "bucketName",
    "Values": ["my-bucket"],
    "Type": "String"
}
```

呈现的结果：

```
"Resource": "arn:aws:s3:::my-bucket/*"
```

#### StringList
<a name="temporary-delegation-stringlist-type"></a>

生成多个资源条目的多个值。在资源 ARN 中使用 StringList 参数时，它会扩展为针对每个值创建单独的资源条目。

模板：

```
"Resource": "arn:aws:s3:::@{bucketNames}/*"
```

参数：

```
{
    "Name": "bucketNames",
    "Values": ["bucket-1", "bucket-2"],
    "Type": "StringList"
}
```

呈现的结果：

```
"Resource": [
    "arn:aws:s3:::bucket-1/*",
    "arn:aws:s3:::bucket-2/*"
]
```

#### 交叉乘积行为
<a name="temporary-delegation-cross-product-behavior"></a>

在同一个资源 ARN 中使用多个参数时，StringList 参数会创建所有组合的交叉乘积。

模板：

```
"Resource": "arn:aws:s3:::@{bucketNames}/@{prefix}/*"
```

参数：

```
[
    {
        "Name": "bucketNames",
        "Values": ["bucket-1", "bucket-2"],
        "Type": "StringList"
    },
    {
        "Name": "prefix",
        "Values": ["data"],
        "Type": "String"
    }
]
```

呈现的结果：

```
"Resource": [
    "arn:aws:s3:::bucket-1/data/*",
    "arn:aws:s3:::bucket-2/data/*"
]
```

### 条件语句
<a name="temporary-delegation-conditional-statements"></a>

使用 @Enabled 指令可根据参数值有条件地包含或排除整个语句。

语法：
+ @Enabled: "parameterName"：参数值为“True”时包含语句
+ @Enabled: "\$1parameterName"：参数值不为“True”（否定）时包含语句

模板：

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": ["s3:GetObject"],
            "Resource": "*"
        },
        {
            "@Enabled": "ENABLE_S3_WRITE",
            "Effect": "Allow",
            "Action": ["s3:PutObject"],
            "Resource": "arn:aws:s3:::@{bucketName}/*"
        }
    ]
}
```

参数（ENABLE\$1S3\$1WRITE 为“True”时）：

```
[
    {
        "Name": "bucketName",
        "Values": ["my-bucket"],
        "Type": "String"
    },
    {
        "Name": "ENABLE_S3_WRITE",
        "Values": ["True"],
        "Type": "String"
    }
]
```

呈现的结果：

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": ["s3:GetObject"],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": ["s3:PutObject"],
            "Resource": "arn:aws:s3:::my-bucket/*"
        }
    ]
}
```

参数（ENABLE\$1S3\$1WRITE 为“False”时）：

```
[
    {
        "Name": "bucketName",
        "Values": ["my-bucket"],
        "Type": "String"
    },
    {
        "Name": "ENABLE_S3_WRITE",
        "Values": ["False"],
        "Type": "String"
    }
]
```

呈现的结果：

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": ["s3:GetObject"],
            "Resource": "*"
        }
    ]
}
```

ENABLE\$1S3\$1WRITE 设置为“True”时，将包含条件语句。设置为“False”时，将从呈现的策略中排除该语句。

## 其他示例
<a name="temporary-delegation-additional-examples"></a>

以下示例展示在临时委派中使用策略模板的常见模式。其重点介绍如何创建具有权限边界的 IAM 角色以实现长期访问，并展示将权限范围限定为特定资源的不同策略。这些示例说明如何使用 ARN 前缀、资源标记和权限边界更新等技术，在灵活性与安全性之间取得平衡。

### 示例 1：授予对特定资源的长期访问权限
<a name="temporary-delegation-example-1"></a>

以下权限边界作为“partner.com”的“SQSAccessorBoundary”提交：

```
{
    "Effect": "Allow",
    "Action": [
        "sqs:DeleteMessage",
        "sqs:ReceiveMessage",
        "sqs:SendMessage"
    ],
    "Resource": "arn:aws:sqs:*:*:*",
    "Condition": {
        "StringEquals": {
            "aws:ResourceAccount": "${aws:PrincipalAccount}"
        }
    }
}
```

**注意**  
这包括一个同账户条件，以避免向其他账户中具有开放资源策略的队列授予访问权限。由于该边界在所有客户之间共享且无法进行模板化，因此不能直接引用客户的账户 ID。

由于这是此策略的第一个版本，其 ARN 为 arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary\$12025\$101\$115

已提交以下策略模板用于获取临时访问权限：

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sqs:ListQueues"
            ],
            "Resource": "arn:aws:sqs:*:*:*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:CreateRole",
                "iam:PutRolePermissionsBoundary",
                "iam:PutRolePolicy"
            ],
            "Resource": "arn:aws:iam::@{AccountId}:role/partner.com/SQSAccessor",
            "Condition": {
                "StringEquals": {
                    "iam:PermissionsBoundary": "arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary_2025_01_15"
                }
            }
        }
    ]
}
```

### 示例 2：使用 ARN 前缀
<a name="temporary-delegation-example-2"></a>

权限边界可以指定资源 ARN 前缀来限制访问权限：

```
"Resource": "arn:aws:sqs:*:@{AccountId}:PartnerPrefix*"
```

这可将访问仅限于带有该前缀的资源，从而缩小可访问资源的范围。

### 示例 3：使用标签进行资源访问控制
<a name="temporary-delegation-example-3"></a>

您可以在临时委派的访问期间为资源添加标签，并依靠这些标签进行长期访问控制。

允许访问带标签资源的权限边界：

```
{
    "Effect": "Allow",
    "Action": [
        "sqs:DeleteMessage",
        "sqs:ReceiveMessage",
        "sqs:SendMessage"
    ],
    "Resource": "arn:aws:sqs:*:*:*",
    "Condition": {
        "Null": {
            "aws:ResourceTag/ManagedByPartnerDotCom": "false"
        },
        "StringEquals": {
            "aws:ResourceAccount": "${aws:PrincipalAccount}"
        }
    }
}
```

在创建新队列时为其添加标签的策略模板：

```
{
    "Effect": "Allow",
    "Action": [
        "sqs:CreateQueue",
        "sqs:TagQueue"
    ],
    "Resource": "arn:aws:sqs:*:*:*",
    "Condition": {
        "Null": {
            "aws:RequestTag/ManagedByPartnerDotCom": "false"
        }
    }
}
```

为既有队列添加标签并创建角色的策略模板：

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sqs:TagQueue"
            ],
            "Resource": "arn:aws:sqs:*:@{AccountId}:@{QueueName}",
            "Condition": {
                "ForAllValues:StringEquals": {
                    "aws:TagKeys": "ManagedByPartnerDotCom"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:CreateRole",
                "iam:PutRolePermissionsBoundary",
                "iam:PutRolePolicy"
            ],
            "Resource": "arn:aws:iam::@{AccountId}:role/partner.com/SQSAccessor",
            "Condition": {
                "StringEquals": {
                    "iam:PermissionsBoundary": "arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary_2025_01_15"
                }
            }
        }
    ]
}
```

这种方法允许客户显式确认可以长期访问哪些特定资源。

### 示例 4：更新权限边界
<a name="temporary-delegation-example-4"></a>

要更新权限边界，请注册带有新日期后缀的新版本，并请求替换该版本的权限。

具有额外权限的更新权限边界：

```
{
    "Effect": "Allow",
    "Action": [
        "sqs:DeleteMessage",
        "sqs:PurgeQueue",
        "sqs:ReceiveMessage",
        "sqs:SendMessage"
    ],
    "Resource": "arn:aws:sqs:*:*:*",
    "Condition": {
        "StringEquals": {
            "aws:ResourceAccount": "${aws:PrincipalAccount}"
        }
    }
}
```

作为第二个版本，此策略的 ARN 为：arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary\$12025\$101\$120

更新现有角色权限边界的策略模板：

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "iam:PutRolePermissionsBoundary"
            ],
            "Resource": "arn:aws:iam::@{AccountId}:role/partner.com/SQSAccessor",
            "Condition": {
                "StringEquals": {
                    "iam:PermissionsBoundary": "arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary_2025_01_20"
                }
            }
        }
    ]
}
```

客户必须批准此委派请求，才能更新现有角色的权限边界。

# 构建您的集成
<a name="temporary-delegation-building-integration"></a>

## 了解请求生命周期
<a name="temporary-delegation-request-lifecycle"></a>

在构建集成之前，了解委派请求从创建到完成的过程非常重要。

### 请求状态
<a name="temporary-delegation-request-states"></a>

委派请求会经历以下状态：


| 州 | 说明 | 
| --- | --- | 
| 未分配 | 请求已创建，但尚未与客户账户和 IAM 主体关联。该请求可能是在未指定目标账户的情况下创建的，也可能已指定目标账户 ID 但账户所有者尚未认领。 | 
| 已分配 | 与客户账户关联且正在等待审查的请求 | 
| 待批准 | 客户已将请求转发给管理员进行批准 | 
| 已接受 | 请求已获得客户批准，但交换令牌尚未发放 | 
| 已最终确定 | 交换令牌已发放给产品提供商。委派期限（交换令牌有效期）从请求达到“已最终确定”状态时开始 | 
| 已拒绝 | 请求被客户拒绝 | 
| 已过期 | 由于不活动或超时，请求已过期 | 

### 状态变换
<a name="temporary-delegation-state-transitions"></a>

*正常流程（批准路径）*
+ 未分配 → 已分配：客户将请求与其账户关联
+ “已分配 → 已接受”或“已分配 → 待批准”：客户直接批准请求或转发给管理员进行审查
+ 待批准 → 已接受：管理员批准该请求
+ 已接受 → 已最终确定：客户发放交换令牌

*拒绝路径*
+ 已分配 → 已拒绝：客户拒绝该请求
+ 待批准 → 已拒绝：管理员拒绝该请求
+ 已接受 → 已拒绝：客户在发放令牌之前撤销批准

*到期路径*

如果在指定时间范围内未采取任何行动，则请求将自动过期：
+ 未分配 → 已过期（1 天）
+ 已分配 → 已过期（7 天）
+ 待批准 → 已过期（7 天）
+ 已接受 → 已过期（7 天）
+ 已拒绝 → 已过期（7 天）
+ 已最终确定 → 已过期（7 天）

*终端状态*

以下状态是终止状态（不再有进一步的转换）：
+ 已最终确定：交换令牌已发送
+ 已拒绝：请求被拒绝
+ 已过期：请求超时或委派期限结束

保留期过后，过期的请求最终会从系统中删除。

### 管理应用程序中的委派请求状态
<a name="temporary-delegation-managing-states"></a>

作为合作伙伴，您必须在系统中跟踪委派请求状态，并将其呈现给客户。当您收到有关状态变更的 SNS 通知时，请将这些更新存储在后端，并在面向客户的 UI 中显示。请特别注意“待批准”状态：当客户将请求转发给管理员进行审查时，AWS 会向您发送待批准通知。在等待管理员操作期间，请求可以保持此状态长达 7 天。在此期间，在您的应用程序中向客户展示其请求正在等待管理员的批准。考虑提供指向 AWS 管理控制台的深层链接，客户可以在其中查看请求状态或与其管理员跟进沟通。正确处理后端的状态机并在每个阶段向客户呈现正确的状态信息对于获得良好的集成体验非常重要。

![\[alt text not found\]](http://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/images/delegation-states.png)


## 配置 通知
<a name="temporary-delegation-configuring-notifications"></a>

IAM 使用 Amazon Simple Notification Service（SNS）向您传达委派请求状态的更改。创建委派请求时，必须提供注册 AWS 账户中的 SNS 主题 ARN。IAM 将向该主题发布重要事件的消息，包括客户批准或拒绝请求时以及交换令牌准备就绪时。

**注意**  
SNS 主题不能位于可选择加入的 AWS 区域。您的 SNS 主题必须位于默认启用的 AWS 区域中。有关选择加入区域的列表，请参阅 AWS 账户管理指南中的“管理 AWS 区域”。

### SNS 主题配置
<a name="temporary-delegation-sns-topic-configuration"></a>

要接收委派请求通知，您必须将 SNS 主题配置为授予向其发布消息的 IAM 权限。将以下策略语句添加到 SNS 主题策略：

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowIAMServiceToPublish",
            "Effect": "Allow",
            "Principal": {
                "Service": "iam.amazonaws.com"
            },
            "Action": "SNS:Publish",
            "Resource": "arn:aws:sns:REGION:ACCOUNT-ID:TOPIC-NAME"
        }
    ]
}
```

**重要**  
SNS 主题必须位于您的其中一个注册 AWS 账户中。IAM 不接受来自其他账户的 SNS 主题。如果主题策略配置不正确，您将不会收到状态更改通知或交换令牌。

### 通知类型
<a name="temporary-delegation-notification-types"></a>

IAM 发送两种类型的通知：

*StateChange 通知*

当委派请求转换到新状态（已分配、待批准、已接受、已最终确定、已拒绝、已过期）时发送。

*ExchangeToken 通知*

当客户发放委派令牌时发送（状态为“已最终确定”）。此通知包含您获取凭证所需的交换令牌。

### 通知系统
<a name="temporary-delegation-notification-states"></a>

您将收到以下委派请求状态的通知：


| 州 | 通知类型 | 说明 | 
| --- | --- | --- | 
| 已分配 | StateChange | 请求已与客户账户关联 | 
| 待批准 | StateChange | 客户已将请求转发给管理员进行批准 | 
| 已接受 | StateChange | 客户已批准请求，但尚未发放令牌 | 
| 已最终确定 | StateChange | 客户已发放交换令牌 | 
| 已最终确定 | ExchangeToken | 此通知包含交换令牌 | 
| REJECTED | StateChange | 客户已拒绝该请求 | 
| EXPIRED | StateChange | 请求在完成前已过期 | 

### 通知消息格式
<a name="temporary-delegation-notification-message-format"></a>

IAM 发布标准 SNS 通知。委派请求信息以 JSON 字符串的形式包含在“消息”字段中。

*常用字段（所有通知）*


| 字段 | Type | 说明 | 
| --- | --- | --- | 
| 类型 | 字符串 | “StateChange”或“ExchangeToken” | 
| RequestId | 字符串 | IAM 委派请求 ID | 
| RequestorWorkflowId | 字符串 | 您在创建请求时提供的工作流程 ID | 
| 州 | 字符串 | 请求的当前状态 | 
| OwnerAccountId | 字符串 | 客户的 AWS 账户 ID | 
| UpdatedAt | 字符串 | 状态更改时的时间戳（ISO 8601 格式） | 

*其他字段（仅限 ExchangeToken 通知）*


| 字段 | Type | 说明 | 
| --- | --- | --- | 
| ExchangeToken | 字符串 | 使用 AWS STS GetDelegatedAccessToken API 交换凭证的令牌 | 
| ExpiresAt | 字符串 | 委派访问权限过期时间（ISO 8601 格式） | 

### 示例通知
<a name="temporary-delegation-example-notifications"></a>

*StateChange 通知*

```
{
  "Type": "Notification",
  "MessageId": "61ee8ad4-6eec-56b5-8f3d-eba57556aa13",
  "TopicArn": "arn:aws:sns:us-east-1:123456789012:partner-notifications",
  "Message": "{\"RequestorWorkflowId\":\"workflow-12345\",\"Type\":\"StateChange\",\"RequestId\":\"dr-abc123\",\"State\":\"ACCEPTED\",\"OwnerAccountId\":\"111122223333\",\"UpdatedAt\":\"2025-01-15T10:30:00.123Z\"}",
  "Timestamp": "2025-01-15T10:30:00.456Z",
  "SignatureVersion": "1",
  "Signature": "...",
  "SigningCertURL": "...",
  "UnsubscribeURL": "..."
}
```

*ExchangeToken 通知*

```
{
  "Type": "Notification",
  "MessageId": "e44e5435-c72c-5333-aba3-354406782f5b",
  "TopicArn": "arn:aws:sns:us-east-1:123456789012:partner-notifications",
  "Message": "{\"RequestId\":\"dr-abc123\",\"RequestorWorkflowId\":\"workflow-12345\",\"State\":\"FINALIZED\",\"OwnerAccountId\":\"111122223333\",\"ExchangeToken\":\"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...\",\"ExpiresAt\":\"2025-01-15T18:30:00.123Z\",\"UpdatedAt\":\"2025-01-15T10:30:00.456Z\",\"Type\":\"ExchangeToken\"}",
  "Timestamp": "2025-01-15T10:30:00.789Z",
  "SignatureVersion": "1",
  "Signature": "...",
  "SigningCertURL": "...",
  "UnsubscribeURL": "..."
}
```

## 交换令牌
<a name="temporary-delegation-exchange-tokens"></a>

当客户接受并最终确定委派请求时，IAM 会发布交换令牌或交易令牌。产品提供商使用此交换或交易令牌调用 AWS AWS STS GetDelegatedAccessToken API 以获取具有客户批准权限的临时 AWS 凭证。交换令牌本身不授予对 AWS 资源的访问权限；必须通过 AWS STS 将其交换为实际凭证。

交换令牌只能由创建委派请求的产品提供商账户兑换。请求账户嵌入在令牌中，确保只有授权的产品提供商才能获得访问客户账户的凭证。

### 访问持续时间
<a name="temporary-delegation-access-duration"></a>

委派期限从客户发放交换令牌时开始，而不是从产品提供商兑换令牌时开始。客户发放令牌后：
+ 产品提供商通过 SNS 通知接收令牌
+ 其可以立即用该令牌交换凭证
+ 凭证到期时间：发放时间 \$1 批准的持续时间
+ 如果需要，产品提供商可以在令牌到期前多次交换该令牌以获取新的凭证

### 多次兑换
<a name="temporary-delegation-multiple-redemptions"></a>

产品提供商可以在有效期内多次交换令牌以获得新的凭证。但是，根据您发放令牌的时间，从同一个交换令牌获得的所有凭证会同时过期。

示例：如果您批准了 2 小时的委派请求并在上午 10:00 发放令牌：


| 令牌发放时间 | 令牌交换时间 | 凭证到期时间 | 可用时间 | 
| --- | --- | --- | --- | 
| 10:00 am | 10:00 am | 12:00 pm | 2 小时 | 
| 10:00 am | 10:20 am | 12:00 pm | 1 小时 40 分钟 | 
| 10:00 am | 11:40 am | 12:00 pm | 20 分钟 | 
| 10:00 am | 12:10 pm | 失效（令牌已过期） | 0 分钟 | 

如表中所示，在有效期内较晚的时间交换令牌会导致产品提供商的可用时间缩短。