本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# Identity and Access Management AWS Clean Rooms
AWS Identity and Access Management (IAM) AWS 服务 可帮助管理员安全地控制对 AWS 资源的访问权限。IAM 管理员控制谁可以*进行身份验证*（登录）和*授权*（拥有权限）使用 AWS Clean Rooms 资源。您可以使用 IAM AWS 服务 ，无需支付额外费用。
**Topics**
+ [受众](#security-iam-audience)
+ [使用身份进行身份验证](#security-iam-auth-with-identities)
+ [使用策略管理访问](#security-iam-managing-access)
+ [如何 AWS Clean Rooms 与 IAM 配合使用](security_iam_service-with-iam.md)
+ [基于身份的策略示例 AWS Clean Rooms](security_iam_id-based-policy-examples.md)
+ [AWS 的托管策略 AWS Clean Rooms](security-iam-awsmanpol.md)
+ [对 AWS Clean Rooms 身份和访问进行故障排除](security_iam_troubleshoot.md)
+ [防止跨服务混淆代理](cross-service-confused-deputy-prevention.md)
+ [AWS Clean Rooms ML 的 IAM 行为](ml-behaviors.md)
+ [洁净室机器学习自定义模型的 IAM 行为](ml-behaviors-byom.md)
## 受众
您的使用方式 AWS Identity and Access Management (IAM) 因您的角色而异：
+ **服务用户**：如果您无法访问功能，请从管理员处请求权限（请参阅[对 AWS Clean Rooms 身份和访问进行故障排除](security_iam_troubleshoot.md)）
+ **服务管理员**：确定用户访问权限并提交权限请求（请参阅[如何 AWS Clean Rooms 与 IAM 配合使用](security_iam_service-with-iam.md)）
+ **IAM 管理员**：编写用于管理访问权限的策略（请参阅[基于身份的策略示例 AWS Clean Rooms](security_iam_id-based-policy-examples.md)）
## 使用身份进行身份验证
身份验证是您 AWS 使用身份凭证登录的方式。您必须以 IAM 用户*身份或通过担 AWS 账户根用户任 IAM 角色进行身份验证*（登录 AWS）。
您可以使用通过身份源提供的凭据以 AWS 联合身份登录。 AWS IAM Identity Center （IAM Identity Center）用户或贵公司的单点登录身份验证就是联合身份的示例。当您以联合身份登录时，您的管理员以前使用 IAM 角色设置了身份联合验证。当你使用联合访问 AWS 时，你就是在间接扮演一个角色。
根据您的用户类型，您可以登录 AWS 管理控制台 或 AWS 访问门户。有关登录的更多信息 AWS，请参阅《*AWS 登录 用户指南》*[中的如何登录到您 AWS 账户](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)的。
如果您 AWS 以编程方式访问，则会 AWS 提供软件开发套件 (SDK) 和命令行接口 (CLI)，以便使用您的凭据对请求进行加密签名。如果您不使用 AWS 工具，则必须自己签署请求。有关使用推荐的方法自行对请求签名的更多信息，请参阅《AWS 一般参考》中的 [签名版本 4 签名流程](https://docs.aws.amazon.com//general/latest/gr/signature-version-4.html)**。
无论使用何种身份验证方法，您都可能需要提供其他安全信息。例如， AWS 建议您使用多重身份验证 (MFA) 来提高账户的安全性。要了解更多信息，请参阅《AWS IAM Identity Center 用户指南》**中的[多重身份验证](https://docs.aws.amazon.com//singlesignon/latest/userguide/enable-mfa.html)和《IAM 用户指南》**中的[在 AWS中使用多重身份验证（MFA）](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_mfa.html)。
### AWS 账户 root 用户
创建时 AWS 账户，首先要有一个登录身份，该身份可以完全访问账户中的所有资源 AWS 服务 和资源。此身份称为 AWS 账户 *根用户*，使用您创建账户时所用的电子邮件地址和密码登录，即可获得该身份。强烈建议您不要使用根用户执行日常任务。保护好根用户凭证，并使用这些凭证来执行仅根用户可以执行的任务。有关需要您以根用户身份登录的任务的完整列表，请参阅《AWS 一般参考》中的 [AWS 账户根用户 凭证和 IAM 身份](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root)**。
### 联合身份
作为最佳实践，要求人类用户使用与身份提供商的联合身份验证才能 AWS 服务 使用临时证书进行访问。
*联合身份是指*来自您的企业目录、Web 身份提供商的用户 Directory Service ，或者 AWS 服务 使用来自身份源的凭据进行访问的用户。联合身份代入可提供临时凭证的角色。
要集中管理访问权限，建议使用。 AWS IAM Identity Center有关更多信息，请参阅《AWS IAM Identity Center 用户指南》**中的[什么是 IAM Identity Center？](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)。
### IAM 用户和群组
*[IAM 用户](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*是对某个人员或应用程序具有特定权限的一个身份。建议使用临时凭证，而非具有长期凭证的 IAM 用户。有关更多信息，请参阅 *IAM 用户指南*[中的要求人类用户使用身份提供商的联合身份验证才能 AWS 使用临时证书进行访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)。
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)指定一组 IAM 用户，便于更轻松地对大量用户进行权限管理。有关更多信息，请参阅*《IAM 用户指南》*中的 [IAM 用户使用案例](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html)。
### IAM 角色
*[IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)*是具有特定权限的身份，可提供临时凭证。您可以通过[从用户切换到 IAM 角色（控制台）](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)或调用 AWS CLI 或 AWS API 操作来代入角色。有关更多信息，请参阅《IAM 用户指南》**中的[担任角色的方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html)。
IAM 角色对于联合用户访问、临时 IAM 用户权限、跨账户访问、跨服务访问以及在 Amazon EC2 上运行的应用程序非常有用。有关更多信息，请参阅《IAM 用户指南》**中的 [IAM 中的跨账户资源访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)。
## 使用策略管理访问
您可以 AWS 通过创建策略并将其附加到 AWS 身份或资源来控制中的访问权限。策略是其中的一个对象 AWS ，当与身份或资源关联时，它会定义其权限。 AWS 在委托人（用户、root 用户或角色会话）发出请求时评估这些策略。策略中的权限确定是允许还是拒绝请求。大多数策略都以 JSON 文档的 AWS 形式存储在中。有关 JSON 策略文档的结构和内容的更多信息，请参阅 *IAM 用户指南*中的 [JSON 策略概览](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)。
管理员可以使用 AWS JSON 策略来指定谁有权访问什么。也就是说，哪个**主体** 可以对什么**资源** 执行**操作**，以及在什么**条件** 下执行。
每个 IAM 实体（用户或角色）最初没有任何权限。原定设置情况下，用户什么都不能做，甚至不能更改他们自己的密码。要为用户授予执行某些操作的权限，管理员必须将权限策略附加到用户。或者，管理员可以将用户添加到具有预期权限的组中。当管理员为某个组授予访问权限时，该组内的全部用户都会获得这些访问权限。
IAM 策略定义操作的权限，无关乎您使用哪种方法执行操作。例如，假设您有一个允许 `iam:GetRole` 操作的策略。拥有该策略的用户可以从 AWS 管理控制台 AWS CLI、或 AWS API 获取角色信息。
### 基于身份的策略
基于身份的策略是可附加到身份（如 IAM 用户、用户组或角色）的 JSON 权限策略文档。这些策略控制用户和角色可在何种条件下对哪些资源执行哪些操作。要了解如何创建基于身份的策略，请参阅《IAM 用户指南》**中的[使用客户管理型策略定义自定义 IAM 权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)。
基于身份的策略可以进一步归类为*内联策略*或*托管式策略*。内联策略直接嵌入单个用户、组或角色中。托管策略是可以附加到 AWS 账户中的多个用户、组和角色的独立策略。托管策略包括 AWS 托管策略和客户托管策略。要了解如何在托管式策略和内联策略之间进行选择，请参阅 *IAM 用户指南*中的[在托管式策略与内联策略之间进行选择](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline)。
### 基于资源的策略
基于资源的策略是附加到资源的 JSON 策略文档。基于资源的策略的示例包括 IAM *角色信任策略*和 Amazon S3 *存储桶策略*。在支持基于资源的策略的服务中，服务管理员可以使用它们来控制对特定资源的访问。对于在其中附加策略的资源，策略定义指定主体可以对该资源执行哪些操作以及在什么条件下执行。您必须在基于资源的策略中[指定主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)。委托人可以包括账户、用户、角色、联合用户或 AWS 服务。
基于资源的策略是位于该服务中的内联策略。您不能在基于资源的策略中使用 IAM 中的 AWS 托管策略。
### 其他策略类型
AWS 支持其他不太常见的策略类型。这些策略类型可以设置更常用的策略类型向您授予的最大权限。
+ **权限边界**：权限边界是一个高级特征，用于设置基于身份的策略可以为 IAM 实体（IAM 用户或角色）授予的最大权限。您可为实体设置权限边界。这些结果权限是实体的基于身份的策略及其权限边界的交集。在 `Principal` 中指定用户或角色的基于资源的策略不受权限边界限制。任一项策略中的显式拒绝将覆盖允许。有关权限边界的更多信息，请参阅*IAM 用户指南*中的 [IAM 实体的权限边界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)。
+ **服务控制策略 (SCPs)** — SCPs 是 JSON 策略，用于指定中组织或组织单位 (OU) 的最大权限 AWS Organizations。 AWS Organizations 是一项用于对您的企业拥有的多 AWS 账户 项进行分组和集中管理的服务。如果您启用组织中的所有功能，则可以将服务控制策略 (SCPs) 应用于您的任何或所有帐户。SCP 限制成员账户中的实体（包括每个 AWS 账户根用户实体）的权限。有关 Organizations 和的更多信息 SCPs，[请参阅《AWS Organizations 用户指南》中的 SCPs工作](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_about-scps.html)*原理*。
+ **会话策略**：会话策略是当您以编程方式为角色或联合用户创建临时会话时作为参数传递的高级策略。结果会话的权限是用户或角色的基于身份的策略和会话策略的交集。权限也可以来自基于资源的策略。任一项策略中的显式拒绝将覆盖允许。有关更多信息，请参阅 *IAM 用户指南*中的[会话策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)。
### 多个策略类型
当多个类型的策略应用于一个请求时，生成的权限更加复杂和难以理解。要了解在涉及多种策略类型时如何 AWS 确定是否允许请求，请参阅 *IAM 用户指南*中的[策略评估逻辑](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)。
# 如何 AWS Clean Rooms 与 IAM 配合使用
在使用 IAM 管理访问权限之前 AWS Clean Rooms，请先了解哪些可用的 IAM 功能 AWS Clean Rooms。
**您可以搭配使用的 IAM 功能 AWS Clean Rooms**
| IAM 功能 | AWS Clean Rooms 支持 |
| --- | --- |
| [基于身份的策略](#security_iam_service-with-iam-id-based-policies) | 是 |
| [基于资源的策略](#security_iam_service-with-iam-resource-based-policies) | 部分 |
| [策略操作](#security_iam_service-with-iam-id-based-policies-actions) | 是 |
| [策略资源](#security_iam_service-with-iam-id-based-policies-resources) | 是 |
| [策略条件键（特定于服务）](#security_iam_service-with-iam-id-based-policies-conditionkeys) | 部分 |
| [ACLs](#security_iam_service-with-iam-acls) | 否 |
| [ABAC（策略中的标签）](#security_iam_service-with-iam-tags) | 是 |
| [临时凭证](#security_iam_service-with-iam-roles-tempcreds) | 是 |
| [转发访问会话（FAS）](#security_iam_service-with-iam-principal-permissions) | 是 |
| [服务角色](#security_iam_service-with-iam-roles-service) | 是 |
| [服务关联角色](#security_iam_service-with-iam-roles-service-linked) | 否 |
要全面了解大多数 IAM 功能的使用 AWS 服务 方式 AWS Clean Rooms 和其他功能，请参阅AWS 服务 IAM *用户指南中的[与 IA](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) M* 配合使用的内容。
## 基于身份的策略 AWS Clean Rooms
**支持基于身份的策略：**是
基于身份的策略是可附加到身份（如 IAM 用户、用户组或角色）的 JSON 权限策略文档。这些策略控制用户和角色可在何种条件下对哪些资源执行哪些操作。要了解如何创建基于身份的策略，请参阅《IAM 用户指南》**中的[使用客户管理型策略定义自定义 IAM 权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)。
通过使用 IAM 基于身份的策略，您可以指定允许或拒绝的操作和资源以及允许或拒绝操作的条件。要了解可在 JSON 策略中使用的所有元素，请参阅《IAM 用户指南》**中的 [IAM JSON 策略元素引用](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)。
### 基于身份的策略示例 AWS Clean Rooms
要查看 AWS Clean Rooms 基于身份的策略的示例，请参阅。[基于身份的策略示例 AWS Clean Rooms](security_iam_id-based-policy-examples.md)
## 内部基于资源的政策 AWS Clean Rooms
**支持基于资源的策略：**部分支持
基于资源的策略是附加到资源的 JSON 策略文档。基于资源的策略的示例包括 IAM *角色信任策略*和 Amazon S3 *存储桶策略*。在支持基于资源的策略的服务中，服务管理员可以使用它们来控制对特定资源的访问。对于在其中附加策略的资源，策略定义指定主体可以对该资源执行哪些操作以及在什么条件下执行。您必须在基于资源的策略中[指定主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)。委托人可以包括账户、用户、角色、联合用户或 AWS 服务。
要启用跨账户访问，您可以将整个账户或其他账户中的 IAM 实体指定为基于资源的策略中的主体。有关更多信息，请参阅《IAM 用户指南》**中的 [IAM 中的跨账户资源访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)。
该 AWS Clean Rooms 服务仅支持一种基于资源的策略，称为*配置的相似模型托管资源策略，该策略*附加到已配置的相似模型上。此策略定义了哪些主体可以对配置的相似模型执行操作。
要了解如何将基于资源的策略附加到配置的相似模型，请参阅**[AWS Clean Rooms ML 的 IAM 行为](ml-behaviors.md)**。
## 的政策行动 AWS Clean Rooms
**支持策略操作：**是
管理员可以使用 AWS JSON 策略来指定谁有权访问什么。也就是说，哪个**主体**可以对什么**资源**执行**操作**，以及在什么**条件**下执行。
JSON 策略的 `Action` 元素描述可用于在策略中允许或拒绝访问的操作。在策略中包含操作以授予执行关联操作的权限。
要查看 AWS Clean Rooms 操作列表，请参阅《*服务授权参考*》 AWS Clean Rooms中[定义的操作](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscleanrooms.html)。
正在执行的策略操作在操作前 AWS Clean Rooms 使用以下前缀。
```
cleanrooms
```
要在单个语句中指定多项操作，请使用逗号将它们隔开。
```
"Action": [
"cleanrooms:action1",
"cleanrooms:action2"
]
```
要查看 AWS Clean Rooms 基于身份的策略的示例，请参阅。[基于身份的策略示例 AWS Clean Rooms](security_iam_id-based-policy-examples.md)
## 的政策资源 AWS Clean Rooms
**支持策略资源：**是
管理员可以使用 AWS JSON 策略来指定谁有权访问什么。也就是说，哪个**主体**可以对什么**资源**执行**操作**，以及在什么**条件**下执行。
`Resource` JSON 策略元素指定要向其应用操作的一个或多个对象。作为最佳实践，请使用其 [Amazon 资源名称（ARN）](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html)指定资源。对于不支持资源级权限的操作，请使用通配符 (\$1) 指示语句应用于所有资源。
```
"Resource": "*"
```
要查看 AWS Clean Rooms 资源类型及其列表 ARNs，请参阅《*服务授权参考*[》 AWS Clean Rooms中定义的资源](https://docs.aws.amazon.com/service-authorization/latest/reference/list_your_service.html#your_service-resources-for-iam-policies)。要了解可以在哪些操作中指定每个资源的 ARN，请参阅 [AWS Clean Rooms定义的操作](https://docs.aws.amazon.com/service-authorization/latest/reference/list_your_service.html#your_service-actions-as-permissions)。
要查看 AWS Clean Rooms 基于身份的策略的示例，请参阅。[基于身份的策略示例 AWS Clean Rooms](security_iam_id-based-policy-examples.md)
## 的策略条件密钥 AWS Clean Rooms
**支持特定于服务的策略条件键：**部分
管理员可以使用 AWS JSON 策略来指定谁有权访问什么。也就是说，哪个**主体**可以对什么**资源**执行**操作**，以及在什么**条件**下执行。
`Condition` 元素根据定义的条件指定语句何时执行。您可以创建使用[条件运算符](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html)（例如，等于或小于）的条件表达式，以使策略中的条件与请求中的值相匹配。要查看所有 AWS 全局条件键，请参阅 *IAM 用户指南*中的[AWS 全局条件上下文密钥](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)。
要了解 AWS Clean Rooms ML 如何使用策略条件密钥，请参阅**[AWS Clean Rooms ML 的 IAM 行为](ml-behaviors.md)**。
## ACLs in AWS Clean Rooms
**支持 ACLs：**否
访问控制列表 (ACLs) 控制哪些委托人（账户成员、用户或角色）有权访问资源。 ACLs 与基于资源的策略类似，尽管它们不使用 JSON 策略文档格式。
## ABAC with AWS Clean Rooms
**支持 ABAC（策略中的标签）：**是
基于属性的访问权限控制（ABAC）是一种授权策略，该策略基于称为标签的属性来定义权限。您可以将标签附加到 IAM 实体和 AWS 资源，然后设计 ABAC 策略以允许在委托人的标签与资源上的标签匹配时进行操作。
要基于标签控制访问，您需要使用 `aws:ResourceTag/key-name``aws:RequestTag/key-name` 或 `aws:TagKeys` 条件键在策略的[条件元素](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)中提供标签信息。
如果某个服务对于每种资源类型都支持所有这三个条件键，则对于该服务，该值为**是**。如果某个服务仅对于部分资源类型支持所有这三个条件键，则该值为**部分**。
有关 ABAC 的更多信息，请参阅《IAM 用户指南》**中的[使用 ABAC 授权定义权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)。要查看设置 ABAC 步骤的教程，请参阅《IAM 用户指南》**中的[使用基于属性的访问权限控制（ABAC）](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)。
## 将临时凭证与配合使用 AWS Clean Rooms
**支持临时凭证：**是
临时证书提供对 AWS 资源的短期访问权限，并且是在您使用联合身份或切换角色时自动创建的。 AWS 建议您动态生成临时证书，而不是使用长期访问密钥。有关更多信息，请参阅《IAM 用户指南》**中的 [IAM 中的临时安全凭证](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)和[使用 IAM 的。AWS 服务](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)
## 转发访问会话 AWS Clean Rooms
**支持转发访问会话（FAS）：**是
转发访问会话 (FAS) 使用调用主体的权限 AWS 服务，再加上 AWS 服务 向下游服务发出请求的请求。有关发出 FAS 请求时的策略详情，请参阅[转发访问会话](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)。
## 的服务角色 AWS Clean Rooms
**支持服务角色：**是
服务角色是由一项服务担任、代表您执行操作的 [IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)。IAM 管理员可以在 IAM 中创建、修改和删除服务角色。有关更多信息，请参阅《IAM 用户指南》**中的[创建向 AWS 服务委派权限的角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)。
**警告**
更改服务角色的权限可能会中断 AWS Clean Rooms 功能。只有在 AWS Clean Rooms 提供操作指导时才编辑服务角色。
## 的服务相关角色 AWS Clean Rooms
**支持服务相关角色：**否
服务相关角色是一种与服务相关联的 AWS 服务服务角色。服务可以代入代表您执行操作的角色。服务相关角色出现在您的中 AWS 账户 ，并且归服务所有。IAM 管理员可以查看但不能编辑服务关联角色的权限。
有关创建或管理服务相关角色的详细信息，请参阅[能够与 IAM 搭配使用的AWS 服务](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)。在表中查找**服务相关角色**列中包含 `Yes` 的表。选择**是**链接以查看该服务的服务相关角色文档。
# 基于身份的策略示例 AWS Clean Rooms
默认情况下，用户和角色没有创建或修改 AWS Clean Rooms 资源的权限。要授予用户对所需资源执行操作的权限，IAM 管理员可以创建 IAM 策略。
要了解如何使用这些示例 JSON 策略文档创建基于 IAM 身份的策略，请参阅《IAM 用户指南》**中的[创建 IAM 策略（控制台）](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)。
有关由 AWS Clean Rooms定义的操作和资源类型（包括每种资源类型的格式）的详细信息，请参阅《*服务授权参考*》 AWS Clean Rooms中的[操作、资源和条件密钥](https://docs.aws.amazon.com/service-authorization/latest/reference/list_your_service.html)。 ARNs
**Topics**
+ [策略最佳实践](#security_iam_service-with-iam-policy-best-practices)
+ [使用控制 AWS Clean Rooms 台](#security_iam_id-based-policy-examples-console)
+ [允许用户查看他们自己的权限](#security_iam_id-based-policy-examples-view-own-permissions)
## 策略最佳实践
基于身份的策略决定了某人是否可以在您的账户中创建、访问或删除 AWS Clean Rooms 资源。这些操作可能会使 AWS 账户产生成本。创建或编辑基于身份的策略时，请遵循以下指南和建议：
+ **开始使用 AWS 托管策略并转向最低权限权限** — 要开始向用户和工作负载授予权限，请使用为许多常见用例授予权限的*AWS 托管策略*。它们在你的版本中可用 AWS 账户。我们建议您通过定义针对您的用例的 AWS 客户托管策略来进一步减少权限。有关更多信息，请参阅《IAM 用户指南》**中的 [AWS 托管策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)或[工作职能的AWS 托管策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)。
+ **应用最低权限**：在使用 IAM 策略设置权限时，请仅授予执行任务所需的权限。为此，您可以定义在特定条件下可以对特定资源执行的操作，也称为*最低权限许可*。有关使用 IAM 应用权限的更多信息，请参阅《IAM 用户指南》**中的 [IAM 中的策略和权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)。
+ **使用 IAM 策略中的条件进一步限制访问权限**：您可以向策略添加条件来限制对操作和资源的访问。例如，您可以编写策略条件来指定必须使用 SSL 发送所有请求。如果服务操作是通过特定的方式使用的，则也可以使用条件来授予对服务操作的访问权限 AWS 服务，例如 CloudFormation。有关更多信息，请参阅《IAM 用户指南》**中的 [IAM JSON 策略元素：条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)。
+ **使用 IAM Access Analyzer 验证您的 IAM 策略，以确保权限的安全性和功能性**：IAM Access Analyzer 会验证新策略和现有策略，以确保策略符合 IAM 策略语言（JSON）和 IAM 最佳实践。IAM Access Analyzer 提供 100 多项策略检查和可操作的建议，以帮助您制定安全且功能性强的策略。有关更多信息，请参阅《IAM 用户指南》**中的[使用 IAM Access Analyzer 验证策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html)。
+ **需要多重身份验证 (MFA**)-如果 AWS 账户您的场景需要 IAM 用户或根用户，请启用 MFA 以提高安全性。若要在调用 API 操作时需要 MFA，请将 MFA 条件添加到您的策略中。有关更多信息，请参阅《IAM 用户指南》**中的[使用 MFA 保护 API 访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)。
有关 IAM 中的最佳实操的更多信息，请参阅《IAM 用户指南》**中的 [IAM 中的安全最佳实践](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)。
## 使用控制 AWS Clean Rooms 台
要访问 AWS Clean Rooms 控制台，您必须拥有一组最低权限。这些权限必须允许您列出和查看有关您的 AWS Clean Rooms 资源的详细信息 AWS 账户。如果创建比必需的最低权限更为严格的基于身份的策略，对于附加了该策略的实体（用户或角色），控制台将无法按预期正常运行。
对于仅调用 AWS CLI 或 AWS API 的用户，您无需为其设置最低控制台权限。相反，只允许访问与其尝试执行的 API 操作相匹配的操作。
为确保用户和角色仍然可以使用 AWS Clean Rooms 控制台，还需要将 AWS Clean Rooms `FullAccess`或`ReadOnly` AWS 托管策略附加到实体。有关更多信息，请参阅《IAM 用户指南》**中的[为用户添加权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console)。
## 允许用户查看他们自己的权限
该示例说明了您如何创建策略，以允许 IAM 用户查看附加到其用户身份的内联和托管式策略。此策略包括在控制台上或使用 AWS CLI 或 AWS API 以编程方式完成此操作的权限。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# AWS 的托管策略 AWS Clean Rooms
AWS 托管策略是由创建和管理的独立策略 AWS。 AWS 托管策略旨在为许多常见用例提供权限，以便您可以开始为用户、组和角色分配权限。
请记住， AWS 托管策略可能不会为您的特定用例授予最低权限权限，因为它们可供所有 AWS 客户使用。我们建议通过定义特定于使用案例的[客户管理型策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)来进一步减少权限。
您无法更改 AWS 托管策略中定义的权限。如果 AWS 更新 AWS 托管策略中定义的权限，则更新会影响该策略所关联的所有委托人身份（用户、组和角色）。 AWS 最有可能在启动新的 API 或现有服务可以使用新 AWS 服务 的 API 操作时更新 AWS 托管策略。
有关更多信息，请参阅《IAM 用户指南》**中的 [AWS 托管式策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)。
## AWS 托管策略：`AWSCleanRoomsReadOnlyAccess`
您可以将 `AWSCleanRoomsReadOnlyAccess` 附加到 IAM 主体。
该策略授予 `AWSCleanRoomsReadOnlyAccess` 协作中的资源和元数据的只读权限。
**权限详细信息**
该策略包含以下权限：
+ `CleanRoomsRead` - 允许主体对服务进行只读访问。
+ `ConsoleDisplayTables`— 允许委托人对在控制台上显示有关基础 AWS Glue 表的数据所需的 AWS Glue 元数据的只读访问权限。
+ `ConsoleLogSummaryQueryLogs` - 允许主体查看查询日志。
+ `ConsoleLogSummaryObtainLogs` - 允许主体检索日志结果。
有关策略详细信息的 JSON 列表，请参阅*AWS 托管策略参考指南[AWSCleanRoomsReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCleanRoomsReadOnlyAccess.html)*中的。
## AWS 托管策略：`AWSCleanRoomsFullAccess`
您可以将 `AWSCleanRoomsFullAccess` 附加到 IAM 主体。
此策略授予管理权限，允许对 AWS Clean Rooms 协作中的资源和元数据进行完全访问（读取、写入和更新）。此策略包括执行查询的权限。
**权限详细信息**
该策略包含以下权限：
+ `CleanRoomsAccess`— 授予对所有资源执行所有操作的完全访问权限 AWS Clean Rooms。
+ `PassServiceRole` - 仅授予将服务角色传递给名称中带有“cleanrooms”的服务（`PassedToService` 条件）的访问权限。
+ `ListRolesToPickServiceRole`— 允许委托人列出其所有角色以便在使用 AWS Clean Rooms时选择服务角色。
+ `GetRoleAndListRolePoliciesToInspectServiceRole` - 允许主体在 IAM 中查看服务角色和相应的策略。
+ `ListPoliciesToInspectServiceRolePolicy` - 允许主体在 IAM 中查看服务角色和相应的策略。
+ `GetPolicyToInspectServiceRolePolicy` - 允许主体在 IAM 中查看服务角色和相应的策略。
+ `ConsoleDisplayTables`— 允许委托人对在控制台上显示有关基础 AWS Glue 表的数据所需的 AWS Glue 元数据的只读访问权限。
+ `ConsolePickQueryResultsBucketListAll` - 允许主体从查询结果写入的所有可用 S3 存储桶的列表中选择一个 Amazon S3 存储桶。
+ `SetQueryResultsBucket` - 允许主体选择查询结果写入的 S3 存储桶。
+ `ConsoleDisplayQueryResults` - 允许主体向客户显示从 S3 存储桶读取的查询结果。
+ `WriteQueryResults` - 允许主体将查询结果写入客户拥有的 S3 存储桶。
+ `EstablishLogDeliveries`— 允许委托人将查询日志传送到客户的 Amazon Lo CloudWatch gs 日志组。
+ `SetupLogGroupsDescribe`— 允许委托人使用 Amazon Logs CloudWatch 日志组的创建流程。
+ `SetupLogGroupsCreate`— 允许委托人创建 Amazon CloudWatch 日志组。
+ `SetupLogGroupsResourcePolicy`— 允许委托人在 Amazon Logs CloudWatch 日志组上设置资源策略。
+ `ConsoleLogSummaryQueryLogs` - 允许主体查看查询日志。
+ `ConsoleLogSummaryObtainLogs` - 允许主体检索日志结果。
有关策略详细信息的 JSON 列表，请参阅*AWS 托管策略参考指南[AWSCleanRoomsFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCleanRoomsFullAccess.html)*中的。
## AWS 托管策略：`AWSCleanRoomsFullAccessNoQuerying`
您可以将 `AWSCleanRoomsFullAccessNoQuerying` 附加到 IAM principals。
此策略授予管理权限，允许对 AWS Clean Rooms 协作中的资源和元数据进行完全访问（读取、写入和更新）。此策略不包括执行查询的权限。
**权限详细信息**
该策略包含以下权限：
+ `CleanRoomsAccess`— 授予对所有资源的所有操作的完全访问权限 AWS Clean Rooms，协作中查询除外。
+ `CleanRoomsNoQuerying` - 明确拒绝 `StartProtectedQuery` 和 `UpdateProtectedQuery`，阻止查询。
+ `PassServiceRole` - 仅授予将服务角色传递给名称中带有“cleanrooms”的服务（`PassedToService` 条件）的访问权限。
+ `ListRolesToPickServiceRole`— 允许委托人列出其所有角色以便在使用 AWS Clean Rooms时选择服务角色。
+ `GetRoleAndListRolePoliciesToInspectServiceRole` - 允许主体在 IAM 中查看服务角色和相应的策略。
+ `ListPoliciesToInspectServiceRolePolicy` - 允许主体在 IAM 中查看服务角色和相应的策略。
+ `GetPolicyToInspectServiceRolePolicy` - 允许主体在 IAM 中查看服务角色和相应的策略。
+ `ConsoleDisplayTables`— 允许委托人对在控制台上显示有关基础 AWS Glue 表的数据所需的 AWS Glue 元数据的只读访问权限。
+ `EstablishLogDeliveries`— 允许委托人将查询日志传送到客户的 Amazon Lo CloudWatch gs 日志组。
+ `SetupLogGroupsDescribe`— 允许委托人使用 Amazon Logs CloudWatch 日志组的创建流程。
+ `SetupLogGroupsCreate`— 允许委托人创建 Amazon CloudWatch 日志组。
+ `SetupLogGroupsResourcePolicy`— 允许委托人在 Amazon Logs CloudWatch 日志组上设置资源策略。
+ `ConsoleLogSummaryQueryLogs` - 允许主体查看查询日志。
+ `ConsoleLogSummaryObtainLogs` - 允许主体检索日志结果。
+ `cleanrooms` - 管理 AWS Clean Rooms 服务中的协作、分析模板、配置表、成员身份和关联资源。执行各种操作，例如创建、更新、删除、列出和检索有关这些资源的信息。
+ `iam`— 将名称包含 “`cleanrooms`” 的服务角色传递给 AWS Clean Rooms 服务。列出角色、策略，并检查服务角色和与 AWS Clean Rooms 服务相关的策略。
+ `glue`— 从中检索有关数据库、表、分区和架构的信息。 AWS Glue这是 AWS Clean Rooms 服务显示底层数据源并与之交互所必需的。
+ `logs`— 管理日志传送、日志组和 CloudWatch 日志资源策略。查询和检索与 AWS Clean Rooms 服务相关的日志。对于在服务中进行监控、审计和故障排除，必须具备这些权限。
该策略还明确拒绝 `cleanrooms:StartProtectedQuery` 和 `cleanrooms:UpdateProtectedQuery` 操作，以防用户直接执行或更新受保护的查询，这些操作应当通过 AWS Clean Rooms 受控机制完成。
有关策略详细信息的 JSON 列表，请参阅*AWS 托管策略参考指南[AWSCleanRoomsFullAccessNoQuerying](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCleanRoomsFullAccessNoQuerying.html)*中的。
## AWS 托管策略：`AWSCleanRoomsMLReadOnlyAccess`
您可以将 `AWSCleanRoomsMLReadOnlyAccess` 附加到 IAM 主体。
该策略授予 `AWSCleanRoomsMLReadOnlyAccess` 协作中的资源和元数据的只读权限。
该策略包含以下权限：
+ `CleanRoomsConsoleNavigation`— 授予查看 AWS Clean Rooms 控制台屏幕的权限。
+ `CleanRoomsMLRead` - 允许 Clean Rooms ML 对服务进行只读访问。
+ `PassCleanRoomsResources`— 授予传递指定 AWS Clean Rooms 资源的访问权限。
[有关策略详细信息的 JSON 列表，请参阅AWSClean《*AWS 托管策略参考指南》MLReadOnlyAccess中的 Rooms*。](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCleanRoomsMLReadOnlyAccess.html)
## AWS 托管策略：`AWSCleanRoomsMLFullAccess`
您可以将 `AWSCleanRoomsMLFullAcces` 附加到 IAM 主体。该策略授予管理权限，以允许对 Clean Rooms ML 所需的资源和元数据进行完全访问（读取、写入和更新）。
**权限详细信息**
该策略包含以下权限：
+ `CleanRoomsMLFullAccess` - 授予所有 Clean Rooms ML 操作的访问权限。
+ `PassServiceRole` - 仅授予将服务角色传递给名称中带有“cleanrooms-ml”的服务（`PassedToService` 条件）的访问权限。
+ `CleanRoomsConsoleNavigation`— 授予查看 AWS Clean Rooms 控制台屏幕的权限。
+ `CollaborationMembershipCheck`— 当您在协作中启动受众生成（相似区段）工作时，Clean Rooms ML 服务会调用`ListMembers`以检查协作是否有效，来电者是否为活跃成员，配置的受众模型所有者是否为活跃成员。始终需要该权限；仅控制台用户需要控制台导航 SID。
+ `PassCleanRoomsResources`— 授予传递指定 AWS Clean Rooms 资源的访问权限。
+ `AssociateModels` - 允许主体将 Clean Rooms ML 模型与您的协作相关联。
+ `TagAssociations` - 允许主体将标签添加到相似模型和协作之间的关联中。
+ `ListRolesToPickServiceRole`— 允许委托人列出其所有角色以便在使用 AWS Clean Rooms时选择服务角色。
+ `GetRoleAndListRolePoliciesToInspectServiceRole` - 允许主体在 IAM 中查看服务角色和相应的策略。
+ `ListPoliciesToInspectServiceRolePolicy` - 允许主体在 IAM 中查看服务角色和相应的策略。
+ `GetPolicyToInspectServiceRolePolicy` - 允许主体在 IAM 中查看服务角色和相应的策略。
+ `ConsoleDisplayTables`— 允许委托人对在控制台上显示有关基础 AWS Glue 表的数据所需的 AWS Glue 元数据的只读访问权限。
+ `ConsolePickOutputBucket` - 允许主体为配置的受众模型输出选择 Amazon S3 存储桶。
+ `ConsolePickS3Location` - 允许主体为配置的受众模型输出选择存储桶中的位置。
+ `ConsoleDescribeECRRepositories`— 允许委托人描述 Amazon ECR 存储库和映像。
有关策略详细信息的 JSON 列表，请参阅《*AWS 托管策略参考指南*》中的[AWSClean房间MLFull访问权限](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCleanRoomsMLFullAccess.html)。
## AWS Clean Rooms AWS 托管策略的更新
查看 AWS Clean Rooms 自该服务开始跟踪这些更改以来 AWS 托管策略更新的详细信息。要获得有关此页面变更的自动提醒，请订阅 “ AWS Clean Rooms 文档历史记录” 页面上的 RSS feed。
| 更改 | 描述 | 日期 |
| --- | --- | --- |
| [AWSCleanRoomsFullAccessNoQuerying](#security-iam-awsmanpol-fullaccess-noquery)— 更新现有政策 | 将洁净室:UpdateConfiguredTableAllowedColumns 和洁净室:UpdateConfiguredTableReference 添加到。CleanRoomsAccess | 2025 年 7 月 29 日 |
| [AWSCleanRoomsMLReadOnlyAccess](#ml-read-only) - 对现有策略的更新 | 已将 PassCleanRoomsResources 添加到 AWSCleanRoomsMLReadOnlyAccess。已将 PassCleanRoomsResources 和 ConsoleDescribeECRRepositories 添加到 AWSCleanRoomsMLFullAccess。 | 2025 年 1 月 10 日 |
| [AWSCleanRoomsFullAccessNoQuerying](#security-iam-awsmanpol-fullaccess-noquery) - 对现有策略的更新 | 已将 cleanrooms:BatchGetSchemaAnalysisRule 添加到 CleanRoomsAccess。 | 2024 年 5 月 13 日 |
| [AWSCleanRoomsFullAccess](#security-iam-awsmanpol-fullaccess) - 对现有策略的更新 | 在此策略中将 AWSCleanRoomsFullAccess 中的语句 ID 从 ConsolePickQueryResultsBucket 更新为 SetQueryResultsBucket，以更好地表示权限，因为无论使用控制台还是不使用控制台，都需要这些权限来设置查询结果存储桶。 | 2024 年 3 月 21 日 |
| [AWSCleanRoomsMLReadOnlyAccess](#ml-read-only) - 新策略 [AWSCleanRoomsMLFullAccess](#ml-full-access) - 新策略 | 添加AWSCleanRoomsMLReadOnlyAccess并AWSCleanRoomsMLFullAccess支持 AWS Clean Rooms ML。 | 2023 年 11 月 29 日 |
| [AWSCleanRoomsFullAccessNoQuerying](#security-iam-awsmanpol-fullaccess-noquery) - 对现有策略的更新 | 向 CleanRoomsAccess 添加了 cleanrooms:CreateAnalysisTemplate、cleanrooms:GetAnalysisTemplate、cleanrooms:UpdateAnalysisTemplate、 cleanrooms:DeleteAnalysisTemplate、cleanrooms:ListAnalysisTemplates、cleanrooms:GetCollaborationAnalysisTemplate、cleanrooms:BatchGetCollaborationAnalysisTemplate 和 cleanrooms:ListCollaborationAnalysisTemplates，以启用新的分析模板特征。 | 2023 年 7 月 31 日 |
| [AWSCleanRoomsFullAccessNoQuerying](#security-iam-awsmanpol-fullaccess-noquery) - 对现有策略的更新 | 向 CleanRoomsAccess 添加了 cleanrooms:ListTagsForResource、cleanrooms:UntagResource 和 cleanrooms:TagResource，以启用资源标记。 | 2023 年 3 月 21 日 |
| AWS Clean Rooms 已开始跟踪更改 | AWS Clean Rooms 开始跟踪其 AWS 托管策略的更改。 | 2023 年 1 月 12 日 |
# 对 AWS Clean Rooms 身份和访问进行故障排除
使用以下信息来帮助您诊断和修复在使用 AWS Clean Rooms 和 IAM 时可能遇到的常见问题。
**Topics**
+ [我无权在以下位置执行操作 AWS Clean Rooms](#security_iam_troubleshoot-no-permissions)
+ [我无权执行 iam：PassRole](#security_iam_troubleshoot-passrole)
+ [我想允许我以外的人 AWS 账户 访问我的 AWS Clean Rooms 资源](#security_iam_troubleshoot-cross-account-access)
## 我无权在以下位置执行操作 AWS Clean Rooms
如果您收到错误提示，指明您无权执行某个操作，则必须更新策略以允许执行该操作。
当 `mateojackson` IAM 用户尝试使用控制台查看有关虚构 `my-example-widget` 资源的详细信息，但不拥有虚构 `cleanrooms:GetWidget` 权限时，会发生以下示例错误。
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: cleanrooms:GetWidget on resource: my-example-widget
```
在此情况下，Mateo 的策略必须更新以允许其使用 `cleanrooms:GetWidget` 操作访问 `my-example-widget` 资源。
如果您需要帮助，请联系您的 AWS 管理员。您的管理员是提供登录凭证的人。
## 我无权执行 iam：PassRole
如果您收到一个错误，表明您无权执行 `iam:PassRole` 操作，则必须更新策略以允许您将角色传递给。 AWS Clean Rooms
有些 AWS 服务 允许您将现有角色传递给该服务，而不是创建新的服务角色或服务相关角色。为此，您必须具有将角色传递到服务的权限。
当名为 `marymajor` 的 IAM 用户尝试使用控制台在 AWS Clean Rooms中执行操作时，会发生以下示例错误。但是，服务必须具有服务角色所授予的权限才可执行此操作。Mary 不具有将角色传递到服务的权限。
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
在这种情况下，必须更新 Mary 的策略以允许她执行 `iam:PassRole` 操作。
如果您需要帮助，请联系您的 AWS 管理员。您的管理员是提供登录凭证的人。
## 我想允许我以外的人 AWS 账户 访问我的 AWS Clean Rooms 资源
您可以创建一个角色，以便其他账户中的用户或您组织外的人员可以使用该角色来访问您的资源。您可以指定谁值得信赖，可以担任角色。
要了解更多信息，请参阅以下内容：
+ 要了解是否 AWS Clean Rooms 支持这些功能，请参阅[如何 AWS Clean Rooms 与 IAM 配合使用](security_iam_service-with-iam.md)。
+ 要了解如何提供对您拥有的资源的访问权限 AWS 账户 ，请参阅 [IAM 用户*指南中的向您拥有 AWS 账户 的另一个 IAM 用户*提供访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)权限。
+ 要了解如何向第三方提供对您的资源的访问[权限 AWS 账户，请参阅 *IAM 用户指南*中的向第三方提供](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)访问权限。 AWS 账户
+ 要了解如何通过身份联合验证提供访问权限，请参阅《IAM 用户指南》**中的[为经过外部身份验证的用户（联合身份验证）提供访问权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html)。
+ 要了解使用角色和基于资源的策略进行跨账户存取之间的差别，请参阅《IAM 用户指南》**中的 [IAM 角色与基于资源的策略有何不同](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html)。
# 防止跨服务混淆代理
混淆代理问题是一个安全性问题，即不具有某操作执行权限的实体可能会迫使具有更高权限的实体执行该操作。在中 AWS，跨服务模仿可能会导致混乱的副手问题。一个服务（*呼叫服务*）调用另一项服务（*所谓的服务*）时，可能会发生跨服务模拟。可以操纵调用服务，使用其权限以在其他情况下该服务不应有访问权限的方式对另一个客户的资源进行操作。为防止这种情况， AWS 提供可帮助您保护所有服务的数据的工具，而这些服务中的服务主体有权限访问账户中的资源。
我们建议在资源策略中使用 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) 全局条件上下文键，以限制 AWSClean Rooms 授予其他服务对资源的权限。如果您只希望将一个资源与跨服务访问相关联，请使用。`aws:SourceArn`
防范混淆代理问题最有效的方法是使用 `aws:SourceArn` 全局条件上下文键和资源的完整 ARN。在中 AWSClean Rooms，您还必须与`sts:ExternalId`条件键进行比较。
`aws:SourceArn` 的值必须设置为所担任角色的成员身份的 ARN。
以下示例演示如何使用 AWSClean Rooms 中的 `aws:SourceArn` 全局条件上下文键来防范混淆代理问题。
**注意**
示例策略适用于 AWS Clean Rooms 用于访问已配置表的数据和元数据的服务角色的信任策略。
的值**需要设置为查询运行器的成员资格 ID。
协作的所有成员都可以查看已配置的表格元数据，因此每个成员资格 ARN 都必须包含在成员资格列表中。 ARNs
**注意**
通过 AWS Clean Rooms 控制台创建服务角色时，默认情况下，协作的所有当前成员都将包含在混乱的副手条件中。
如果您要向已配置与其关联的表格的协作中添加新成员，请务必使用新成员的成员资格 ARN 更新服务角色的混淆副手条件。
如果您在添加新成员后没有更新服务角色混乱的副手状况，则该新成员将无法访问使用 AWS Clean Rooms 该角色检索到的信息。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowIfExternalIdMatches",
"Effect": "Allow",
"Principal": {
"Service": "cleanrooms.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": {
"sts:ExternalId": "arn:aws:*:us-east-1:*:dbuser:*/*"
}
}
},
{
"Sid": "AllowIfSourceArnMatches",
"Effect": "Allow",
"Principal": {
"Service": "cleanrooms.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"ForAnyValue:ArnEquals": {
"aws:SourceArn": [
"arn:aws:cleanrooms:us-east-1:111122223333:membership/",
"arn:aws:cleanrooms:us-east-1:444455556666:membership/"
]
}
}
}
]
}
```
------
# AWS Clean Rooms ML 的 IAM 行为
## 跨账户作业
Clean Rooms ML AWS 账户 允许一个人在其帐户中安全地访问另一个人创建的某些资源 AWS 账户。当 AWS 账户 A 中的客户端调用 AWS 账户 B 拥有`StartAudienceGenerationJob`的`ConfiguredAudienceModel`资源时，Clean Rooms ML 会 ARNs 为该任务创建两个资源。一个 ARN 在 AWS 账户 A 中，另一个 ARN 在 B 中 AWS 账户 除了 ARNs 它们之外，它们是相同的 AWS 账户。
Clean Rooms ML ARNs 为任务创建了两个，以确保两个账户都可以将自己的 IAM 策略应用于任务。例如，两个账户都可以使用基于标签的访问控制并应用其 AWS 组织的策略。作业处理来自两个账户的数据，因此，两个账户都可以删除作业及其关联数据。两个账户都不能阻止另一个账户删除作业。
只能执行一个作业，两个账户可以在调用 `ListAudienceGenerationJobs` 时看到该作业。两个账户都可以使用自己 AWS 账户 的 `Export` APIs ID 的 ARN 调用`Delete`、和。`Get`
使用带有另一 AWS 账户 个 ID 的 ARN 时，两者都 AWS 账户 无法访问任务。
作业的名称在 AWS 账户中必须是唯一的。 AWS 账户 B 中的名字是*\$1accountA-\$1name*。在 B 中查看作业时 AWS 账户 ，A 选择的名称以 AWS 账户 A 为前缀。 AWS 账户
为了使跨账户`StartAudienceGenerationJob`成功， AWS 账户 B 必须使用类似于以下示例的资源策略允许对 AWS 账户 B 中的新任务和 AWS 账户 B `ConfiguredAudienceModel` 中的新任务执行该操作：
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Clean-Rooms-CAMA-ID",
"Effect": "Allow",
"Principal": {
"AWS": [
"111122223333"
]
},
"Action": [
"cleanrooms-ml:StartAudienceGenerationJob"
],
"Resource": [
"arn:aws:cleanrooms-ml:us-east-1:444455556666:configured-audience-model/id",
"arn:aws:cleanrooms-ml:us-east-1:444455556666:audience-generation-job/*"
],
"Condition":{"StringEquals":{"cleanrooms-ml:CollaborationId":"UUID"}}
}
]
}
```
------
**注意**
此 AWS Clean Rooms 机器学习资源策略引用了两种不同的策略 AWS 账户 IDs 来支持跨账户受众生成：
**111122223333**-该账户包含授权开始受众生成工作的委托人（用户、角色或服务）。此账户启动机器学习处理工作流程。
**444455556666**-这是拥有 AWS Clean Rooms 机器学习资源（配置的受众模型和受众生成作业）的账户。此账户托管 ML 模型并管理任务执行。
**其他配置说明：**
**报表 ID (Sid)**：`CAMA-ID`替换为您的实际 AWS Clean Rooms 受众模型应用程序 (CAMA) 标识符，以使政策声明易于识别。
**资源 IDs**：*id*替换为您配置的受众模型的实际 ID 和*UUID*您的特定协作 ID。
**条件**：该`cleanrooms-ml:CollaborationId`条件可确保受众生成作业只能在指定的 AWS Clean Rooms 协作环境中启动，从而提供了额外的安全边界。
这种跨账户配置支持这样的场景：一个组织管理机器学习模型和基础架构，同时允许授权合作伙伴在其合作协议的范围内启动受众生成流程。
如果您使用 [AWS Clean Rooms ML API](https://docs.aws.amazon.com/cleanrooms-ml/latest/APIReference/Welcome.html) 创建`manageResourcePolicies`设置为 true 的配置相似模型，则会为您 AWS Clean Rooms 创建此策略。
此外， AWS 账户 A 中来电者的身份策略需要获得`StartAudienceGenerationJob`许可`arn:aws:cleanrooms-ml:us-west-1:AccountA:audience-generation-job/*`。因此，有三个 IAM 资源可供操作`StartAudienceGenerationJob`： AWS 账户 A 作业、 AWS 账户 B 作业和 AWS 账户 B `ConfiguredAudienceModel`。
**警告**
启动 AWS 账户 该作业的用户会收到有关该作业的 AWS CloudTrail 审核日志事件。拥有 `ConfiguredAudienceModel` 的 AWS 账户 不会收到 AWS CloudTrail 审核日志事件。
## 标记作业
在您设置 `CreateConfiguredAudienceModel` 的 `childResourceTagOnCreatePolicy=FROM_PARENT_RESOURCE` 参数时，您的账户中通过该配置的相似模型创建的所有相似细分生成作业默认具有与配置的相似模型相同的标签。配置的相似模型是父模型，相似细分生成作业是子模型。
如果您在自己的账户中创建作业，作业的请求标签将覆盖父标签。其他账户创建的作业绝不会在您的账户中创建标签。如果您设置 `childResourceTagOnCreatePolicy=FROM_PARENT_RESOURCE` 并且另一个账户创建作业，则作业具有两个副本。您的账户中的副本具有父资源标签，作业提交者账户中的副本具有来自请求的标签。
## 验证协作者
向 AWS Clean Rooms 协作中的其他成员授予权限时，资源策略应包含条件键`cleanrooms-ml:CollaborationId`。这会强制要求`collaborationId`参数包含在[StartAudienceGenerationJob](https://docs.aws.amazon.com/cleanrooms-ml/latest/APIReference/API_StartAudienceGenerationJob.html)请求中。在请求中包含 `collaborationId` 参数时，Clean Rooms ML 验证协作是否存在，作业提交者是否为协作的活跃成员，以及配置的相似模型所有者是否为协作的活跃成员。
AWS Clean Rooms 管理您配置的相似模型资源策略（`manageResourcePolicies`参数在[CreateConfiguredAudienceModelAssociation 请求`TRUE`](https://docs.aws.amazon.com/clean-rooms/latest/apireference/API_CreateConfiguredAudienceModelAssociation.html)中）时，将在资源策略中设置此条件密钥。因此，必须在 in `collaborationId` 中指定[StartAudienceGenerationJob](https://docs.aws.amazon.com/cleanrooms-ml/latest/APIReference/API_StartAudienceGenerationJob.html)。
## 跨账户访问
只能跨账户调用 `StartAudienceGenerationJob`。所有其他 Clean Rooms ML APIs 只能与您自己账户中的资源一起使用。这可确保您的训练数据、相似模型配置和其他信息保持私密。
Clean Rooms ML 永远不会透露 Amazon S3 或各个账户 AWS Glue 的位置。训练数据位置、配置的相似模型输出位置和相似细分生成作业种子位置绝不会在账户之间可见。除非在协作中启用了查询日志记录，否则种子数据是否来自某个 SQL 查询以及查询本身在账户中都不可见。如果您获取 (`Get`) 另一个账户提交的受众生成作业，该服务不会显示种子位置。
# 洁净室机器学习自定义模型的 IAM 行为
## 跨账户作业
Clean Rooms ML 允许另一个人在其帐户中安全地访问与一个人 AWS 账户 创建的协作关联的某些资源 AWS 账户。 AWS 账户 A 中具有成员运行查询能力的客户可以调用`CreateTrainedModel``CreateMLInputChannel`、或`StartTrainedModelInferenceJob`对协作中其他成员拥有的`ConfiguredModelAlgorithmAssociation`资源进行调用，前提`ConfiguredModelAlgorithmAssociation`是使用创建的自定义分析规则允许`CreateConfiguredTableAnalysisRule`。
此外，协作中的任何活跃成员都可以通过`DeleteTrainedModelOutput`和删除与训练模型或机器学习输入通道关联的数据`DeleteMLInputChannelData` APIs。
## 跨账户访问
Clean Rooms ML 允许用户通过`GetCollaboration`和检索有关其他账户创建的资源的元数据`ListCollaboration` APIs。Clean Rooms ML 不会向其他账户透露 KMS 密钥 ARNs、标签、环境变量或超参数（用于`TrainedModel`操作）。
## 成员资格和协作访问权限
在 Clean Rooms ML 自定义模型的上下文中访问成员资格和协作资源时，用户的身份策略需要操作权限 `cleanrooms:PassMembership``cleanrooms:PassCollaboration`，或两者兼而有之。所有 APIs 接受的人都`membershipId`需要`cleanrooms:PassMembership`许可，而所有 APIs 接受的人都`collaborationId`需要`cleanrooms:PassCollaboration`许可。提供了一个角色的身份策略示例，该角色可以在成员身份 ID 的上下文`GetCollaborationTrainedModel`中调用，并且可以在协作 ID 的上下文中进行调用。`createTrainedModel`
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowCleanroomsMLActions",
"Effect": "Allow",
"Action": [
"cleanrooms:PassCollaboration",
"cleanrooms:PassMembership"
],
"Resource": [
"*"
]
},
{
"Sid": "AllowMembershipAccess",
"Effect": "Allow",
"Action": [
"cleanrooms:GetMembership"
],
"Resource": [
"arn:aws:cleanrooms:us-east-1:111122223333:membership/memberId"
]
},
{
"Sid": "AllowCollaborationAccess",
"Effect": "Allow",
"Action": [
"cleanrooms:GetCollaboration"
],
"Resource": [
"arn:aws:cleanrooms:us-east-1:111122223333:collaboration/collaborationId"
]
}
]
}
```
------