本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 安全性 AWS Clean Rooms 云安全 AWS 是重中之重。作为 AWS 客户，您可以受益于专为满足大多数安全敏感型组织的要求而构建的数据中心和网络架构。 安全是双方共同承担 AWS 的责任。[责任共担模式](https://aws.amazon.com/compliance/shared-responsibility-model/)将此描述为云的安全性和云中的安全性： + **云安全** — AWS 负责保护在 AWS 云中运行 AWS 服务的基础架构。 AWS 还为您提供可以安全使用的服务。作为[AWS 合规计划合规计划合规计划合](https://aws.amazon.com/compliance/programs/)的一部分，第三方审计师定期测试和验证我们安全的有效性。要了解适用于的合规计划 AWS Clean Rooms，请参阅按合规计划划分[的 AWS 范围内服务 AWS 按合规计划](https://aws.amazon.com/compliance/services-in-scope/)。 + **云端安全**-您的责任由您使用的 AWS 服务决定。您还需要对其他因素负责，包括您的数据的敏感性、您公司的要求以及适用的法律法规。 本文档可帮助您了解在使用时如何应用分担责任模型 AWS Clean Rooms。它向您展示了如何进行配置 AWS Clean Rooms 以满足您的安全和合规性目标。您还将学习如何使用其他 AWS 服务来帮助您监控和保护您的 AWS Clean Rooms 资源。 **Topics** + [数据保护](data-protection.md) + [使用服务关联角色](using-service-linked-roles.md) + [数据留存](data-retention.md) + [最佳实践](best-practices.md) + [身份和访问管理](security-iam.md) + [合规性验证](SERVICE-compliance.md) + [恢复能力](disaster-recovery-resiliency.md) + [基础结构安全性](infrastructure-security.md) + [AWS PrivateLink](vpc-interface-endpoints.md) # 中的数据保护 AWS Clean Rooms 分 AWS [担责任模型](https://aws.amazon.com/compliance/shared-responsibility-model/)适用于中的数据保护 AWS Clean Rooms。如本模型所述 AWS ，负责保护运行所有内容的全球基础架构 AWS 云。您负责维护对托管在此基础结构上的内容的控制。您还负责您所使用的 AWS 服务 的安全配置和管理任务。有关数据隐私的更多信息，请参阅[数据隐私常见问题](https://aws.amazon.com/compliance/data-privacy-faq/)。有关欧洲数据保护的信息，请参阅 *AWS Security Blog* 上的 [AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) 博客文章。 出于数据保护目的，我们建议您保护 AWS 账户 凭证并使用 AWS IAM Identity Center 或 AWS Identity and Access Management (IAM) 设置个人用户。这样，每个用户只获得履行其工作职责所需的权限。还建议您通过以下方式保护数据： + 对每个账户使用多重身份验证（MFA）。 + 用于 SSL/TLS 与 AWS 资源通信。我们要求使用 TLS 1.2，建议使用 TLS 1.3。 + 使用设置 API 和用户活动日志 AWS CloudTrail。有关使用 CloudTrail 跟踪捕获 AWS 活动的信息，请参阅*AWS CloudTrail 用户指南*中的[使用跟 CloudTrail 踪](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html)。 + 使用 AWS 加密解决方案以及其中的所有默认安全控件 AWS 服务。 + 使用高级托管安全服务（例如 Amazon Macie），它有助于发现和保护存储在 Amazon S3 中的敏感数据。 + 如果您在 AWS 通过命令行界面或 API 进行访问时需要经过 FIPS 140-3 验证的加密模块，请使用 FIPS 端点。有关可用的 FIPS 端点的更多信息，请参阅《美国联邦信息处理标准（FIPS）第 140-3 版》[https://aws.amazon.com/compliance/fips/](https://aws.amazon.com/compliance/fips/)。 强烈建议您切勿将机密信息或敏感信息（如您客户的电子邮件地址）放入标签或自由格式文本字段（如**名称**字段）。这包括您使用控制台、API AWS Clean Rooms 或以其他 AWS 服务 方式使用控制台 AWS CLI、API 或时 AWS SDKs。在用于名称的标签或自由格式文本字段中输入的任何数据都可能会用于计费或诊断日志。如果您向外部服务器提供 URL，强烈建议您不要在网址中包含凭证信息来验证对该服务器的请求。 ## 静态加密 AWS Clean Rooms 始终对所有静态服务元数据进行加密，无需任何其他配置。使用时会自动进行加密 AWS Clean Rooms。 Clean Rooms ML 对存储在服务中的所有静态数据进行加密。 AWS KMS如果您选择提供自己的 KMS 密钥，则相似模型和相似细分生成作业内容将使用您的 KMS 密钥进行静态加密。 使用 AWS Clean Rooms 自定义 ML 模型时，该服务会对所有静态存储的数据进行加密。 AWS KMS AWS Clean Rooms 支持使用您创建、拥有和管理的对称客户托管密钥来加密静态数据。如果未指定客户管理的密钥，则默认使用 AWS 拥有的密钥 这些密钥。 AWS Clean Rooms 使用授权和密钥策略来访问客户托管的密钥。您可以随时撤销授予访问权限，或删除服务对客户托管密钥的访问权限。如果这样做，将 AWS Clean Rooms 无法访问由客户托管密钥加密的任何数据，这会影响依赖该数据的操作。例如，如果您尝试从 AWS Clean Rooms 无法访问的加密机器学习输入通道创建经过训练的模型，则该操作将返回`ValidationException`错误。 **注意** 您可以利用 Amazon S3 中的加密选项来保护静态数据。 有关更多信息，请参阅《Amazon S3 用户指南》**中的[指定 Amazon S3 加密](https://docs.aws.amazon.com/AmazonS3/latest/userguide/specifying-s3-encryption.html)。 在中使用 ID 映射表时 AWS Clean Rooms，该服务会对所有静态存储的数据进行加密。 AWS KMS如果您选择提供自己的 KMS 密钥，则会通过 KMS 密钥对您的 ID 映射表中的内容进行静态加密 AWS Entity Resolution 数据匹配服务。有关使用 ID 映射工作流程进行加密所需的权限的更多详细信息，请参阅**《AWS Entity Resolution 数据匹配服务 用户指南》中的[为 AWS Entity Resolution 数据匹配服务创建工作流程作业角色](https://docs.aws.amazon.com/entityresolution/latest/userguide/create-workflow-job-role.html)。 ## 传输中加密 AWS Clean Rooms 使用传输层安全 (TLS) 对传输过程进行加密。与的 AWS Clean Rooms 通信始终通过 HTTPS 完成，因此无论数据存储在 Amazon S3、Amazon Athena 还是 Snowflake 中，您的数据在传输过程中始终处于加密状态。这包括使用 Clean Rooms ML 时的所有传输中数据。 ## 加密底层数据 有关如何解密您的底层数据的更多信息，请参阅[加密计算 Clean Rooms](crypto-computing.md)。 ## 密钥策略 密钥策略控制对客户自主管理型密钥的访问。每个客户托管式密钥必须只有一个密钥策略，其中包含确定谁可以使用密钥以及如何使用密钥的声明。创建客户托管式密钥时，可以指定密钥策略。有关更多信息，请参阅《 AWS Key Management Service 开发人员指南》中的管理客户托管密钥的访问权限。 要将客户托管密钥用于您的 AWS Clean Rooms 自定义 ML 模型，必须在密钥策略中允许以下 API 操作： + `kms:DescribeKey`— 提供客户管理的密钥详细信息 AWS Clean Rooms 以允许验证密钥。 + `kms:Decrypt`— 提供访问权限 AWS Clean Rooms 以解密加密数据并将其用于相关作业。 + `kms:CreateGrant`-Clean Rooms ML 通过为 Amazon ECR 创建补助金来加密 Amazon ECR 中静态的训练和推理图像。要了解更多信息，请参阅 [Amazon ECR 中的静态加密](https://docs.aws.amazon.com/AmazonECR/latest/userguide/encryption-at-rest.html)。Clean Rooms ML 还使用 SageMaker Amazon AI 来运行训练和推理作业，并为 SageMaker AI 创建补助金，用于加密附加到实例的 Amazon EBS 卷以及 Amazon S3 中的输出数据。要了解更多信息，请参阅[在 Amazon A SageMaker I 中使用加密保护静态数据](https://docs.aws.amazon.com/sagemaker/latest/dg/encryption-at-rest.html)。 + `kms:GenerateDataKey`-Clean Rooms ML 使用服务器端加密对存储在 Amazon S3 中的静态数据进行加密。 AWS KMS keys要了解更多信息，请参阅在 A [mazon S3 中使用服务器端加密 AWS KMS keys (SSE-KMS)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html)。 以下是您可以为以下资源添加 AWS Clean Rooms 的策略声明示例： **带有合成数据的 ML 输入通道** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "Allow access to principals authorized to use AWS Clean Rooms ML", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::666666666666:role/ExampleRole" }, "Action": [ "kms:GenerateDataKey", "kms:CreateGrant", "kms:Decrypt" ], "Resource": "*", "Condition": { "StringEquals": { "kms:ViaService": "cleanrooms-ml.us-east-1.amazonaws.com" }, "ForAllValues:StringEquals": { "kms:GrantOperations": [ "Decrypt", "Encrypt", "GenerateDataKeyWithoutPlaintext", "ReEncryptFrom", "ReEncryptTo", "CreateGrant", "DescribeKey", "RetireGrant", "GenerateDataKey" ] }, "BoolIfExists": { "kms:GrantIsForAWSResource": true } } }, { "Sid": "Allow describe key for principals authorized to use AWS Clean Rooms ML", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::444455556666:role/ExampleRole" }, "Action": [ "kms:DescribeKey" ], "Resource": "*", "Condition": { "StringEquals": { "kms:ViaService": "cleanrooms-ml.us-east-1.amazonaws.com" } } }, { "Sid": "Allow grant operations for AWS Clean Rooms ML service principal", "Effect": "Allow", "Principal": { "Service": "cleanrooms-ml.amazonaws.com" }, "Action": [ "kms:GenerateDataKey", "kms:CreateGrant", "kms:Decrypt" ], "Resource": "*", "Condition": { "ForAllValues:StringEquals": { "kms:GrantOperations": [ "Decrypt", "Encrypt", "GenerateDataKeyWithoutPlaintext", "ReEncryptFrom", "ReEncryptTo", "CreateGrant", "DescribeKey", "RetireGrant", "GenerateDataKey" ] } } }, { "Sid": "Allow describe key for AWS Clean Rooms ML service principal", "Effect": "Allow", "Principal": { "Service": "cleanrooms-ml.amazonaws.com" }, "Action": [ "kms:DescribeKey" ], "Resource": "*" } ] } ``` **没有合成数据的 ML 输入通道** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "Allow access to principals authorized to use AWS Clean Rooms ML", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::666666666666:role/ExampleRole" }, "Action": [ "kms:DescribeKey", "kms:GenerateDataKey", "kms:Decrypt" ], "Resource": "*", "Condition": { "StringEquals": { "kms:ViaService": "cleanrooms-ml.us-east-1.amazonaws.com" } } }, { "Sid": "Allow access to AWS Clean Rooms ML service principal", "Effect": "Allow", "Principal": { "Service": "cleanrooms-ml.amazonaws.com" }, "Action": [ "kms:DescribeKey", "kms:GenerateDataKey", "kms:Decrypt" ], "Resource": "*" } ] } ``` ------ **经过训练的模型作业或经过训练的模型推理作业** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "Allow grant operations for principals authorized to use AWS Clean Rooms ML", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::666666666666:role/ExampleRole" }, "Action": [ "kms:GenerateDataKey", "kms:CreateGrant", "kms:Decrypt" ], "Resource": "*", "Condition": { "StringEquals": { "kms:ViaService": "cleanrooms-ml.us-east-1.amazonaws.com" }, "ForAllValues:StringEquals": { "kms:GrantOperations": [ "Decrypt", "Encrypt", "GenerateDataKeyWithoutPlaintext", "ReEncryptFrom", "ReEncryptTo", "CreateGrant", "DescribeKey", "RetireGrant", "GenerateDataKey" ] }, "BoolIfExists": { "kms:GrantIsForAWSResource": true } } }, { "Sid": "Allow describe key for principals authorized to use AWS Clean Rooms ML", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::444455556666:role/ExampleRole" }, "Action": [ "kms:DescribeKey" ], "Resource": "*", "Condition": { "StringEquals": { "kms:ViaService": "cleanrooms-ml.us-east-1.amazonaws.com" } } }, { "Sid": "Allow grant operations for AWS Clean Rooms ML service principal", "Effect": "Allow", "Principal": { "Service": "cleanrooms-ml.amazonaws.com" }, "Action": [ "kms:GenerateDataKey", "kms:CreateGrant", "kms:Decrypt" ], "Resource": "*", "Condition": { "ForAllValues:StringEquals": { "kms:GrantOperations": [ "Decrypt", "Encrypt", "GenerateDataKeyWithoutPlaintext", "ReEncryptFrom", "ReEncryptTo", "CreateGrant", "DescribeKey", "RetireGrant", "GenerateDataKey" ] } } }, { "Sid": "Allow describe key for AWS Clean Rooms ML service principal", "Effect": "Allow", "Principal": { "Service": "cleanrooms-ml.amazonaws.com" }, "Action": [ "kms:DescribeKey" ], "Resource": "*" } ] } ``` ------ Clean Rooms ML 不支持在客户托管密钥策略中指定服务加密上下文或源上下文。客户可以在中看到服务内部使用的加密上下文 CloudTrail。 # 将服务相关角色用于 AWS Clean Rooms AWS Clean Rooms 使用 AWS Identity and Access Management (IAM) [服务相关角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role)。服务相关角色是一种与之直接关联的 IAM 角色的独特类型。 AWS Clean Rooms服务相关角色由服务预定义 AWS Clean Rooms ，包括该服务代表您调用其他 AWS 服务所需的所有权限。 服务相关角色使设置变得 AWS Clean Rooms 更加容易，因为您不必手动添加必要的权限。 AWS Clean Rooms 定义其服务相关角色的权限，除非另有定义，否则 AWS Clean Rooms 只能担任其角色。定义的权限包括信任策略和权限策略，以及不能附加到任何其他 IAM 实体的权限策略。 只有在首先删除相关资源后，您才能删除服务关联角色。这样可以保护您的 AWS Clean Rooms 资源，因为您不会无意中删除访问资源的权限。 有关支持服务相关角色的其他服务的信息，请参阅与 [IAM 配合使用的AWS 服务，](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)并在**服务相关角色**列中查找标有 “**是**” 的服务。选择**是**和链接，查看该服务的服务关联角色文档。 ## 的服务相关角色权限 AWS Clean Rooms AWS Clean Rooms 使用名为 R **AWSServiceRoleForAWSCleanoo** ms 的服务相关角色向您的 AWS 账户发布与 Clean Room CloudWatch s 相关的指标。 R AWSService RoleFor AWSClean ooms 服务相关角色信任以下服务来代替该角色： + `cleanrooms.amazonaws.com` 名为的角色权限策略 AWSCleanRoomsServiceRolePolicy AWS Clean Rooms 允许对指定资源完成以下操作： + 操作：`all AWS resources, restricted to the AWS Clean Rooms namespace` 上的 `cloudwatch:PutMetricData` 您必须配置使用户、组或角色能够创建、编辑或删除服务相关角色的权限。有关更多信息，请参阅*《IAM 用户指南》*中的[服务相关角色权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)。 ## 为创建服务相关角色 AWS Clean Rooms 您可以使用 IAM 控制台在 R **AWSServiceRoleForAWSCleanoo** ms 用例中创建服务相关角色。在 AWS CLI 或 AWS API 中，使用服务名称创建服务相关角色。`cleanrooms.amazonaws.com`有关更多信息，请参阅 *IAM 用户指南* 中的[创建服务相关角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role)。如果您删除了此服务相关角色，可以使用同样的过程再次创建角色。 ## 编辑的服务相关角色 AWS Clean Rooms AWS Clean Rooms 不允许您编辑 Rooms AWSService RoleFor AWSClean 服务相关角色。创建服务关联角色后，您将无法更改角色的名称，因为可能有多种实体引用该角色。但是可以使用 IAM 编辑角色描述。有关更多信息，请参阅《IAM 用户指南》**中的[编辑服务关联角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)。 ## 删除的服务相关角色 AWS Clean Rooms 如果不再需要使用某个需要服务关联角色的功能或服务，我们建议您删除该角色。这样就没有未被主动监控或维护的未使用实体。但是，必须先清除服务相关角色的资源，然后才能手动删除它。 要删除聊天**AWSServiceRoleForAWSClean室**，您必须先删除其中的所有[协作](https://docs.aws.amazon.com/clean-rooms/latest/userguide/delete-collaboration.html)和[成员资格](https://docs.aws.amazon.com/clean-rooms/latest/userguide/leave-collab.html)。 AWS 账户 **注意** 如果您尝试删除资源时 AWS Clean Rooms 服务正在使用该角色，则删除可能会失败。如果发生这种情况，请等待几分钟后重试。 **使用 IAM 手动删除服务关联角色** 使用 IAM 控制台 AWS CLI、或 AWS API 删除 R AWSService RoleFor AWSClean ooms 服务相关角色。有关更多信息，请参阅《IAM 用户指南》**中的[删除服务关联角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)。 ## AWS Clean Rooms 服务相关角色支持的区域 AWS Clean Rooms 支持在提供服务的所有区域中使用服务相关角色。有关更多信息，请参阅[AWS 区域和端点](https://docs.aws.amazon.com/general/latest/gr/clean-rooms.html#clean-rooms_region)。 # 数据保留在 AWS Clean Rooms 查询完成后，任何临时读入 AWS Clean Rooms 协作的数据都会被删除。 在您创建相似模型时，Clean Rooms ML 读取您的训练数据，将其转换为适合我们的机器学习模型的格式，并将训练的模型参数存储在 Clean Rooms ML 中。Clean Rooms ML 不会保留您的训练数据的副本。 AWS Clean Rooms 查询运行后，SQL 查询不会保留您的任何数据。然后，Clean Rooms ML 使用训练的模型总结您的所有用户的行为。只要您的相似模型处于活跃状态，Clean Rooms ML 就会为您的数据中的每个用户存储用户级数据集。 当您启动相似区段生成作业时，Clean Rooms ML 会读取种子数据，从关联的相似模型中读取行为摘要，然后创建存储在服务中的相似区段。 AWS Clean Rooms Clean Rooms ML 不会保留您的种子数据的副本。只要作业处于活跃状态，Clean Rooms ML 就会存储作业的用户级输出。 如果您的种子数据来自 SQL 查询，则该查询的输出仅在作业持续期间存储在服务中。查询结果会进行静态和传输中加密。 如果要删除相似模型或相似细分生成作业数据，请使用 API 将其删除。Clean Rooms ML 异步删除与模型或作业关联的所有数据。在该过程完成后，Clean Rooms ML 删除模型或作业的元数据，而不再在 API 中显示这些数据。Clean Rooms ML 会将删除的数据保留 3 天以防进行灾难恢复。在 API 中不再显示作业或模型并且经过 3 天后，将永久删除与模型或作业关联的所有数据。 # 中数据协作的最佳实践 AWS Clean Rooms 本主题介绍在 AWS Clean Rooms中开展数据协作的最佳实践。 AWS Clean Rooms 遵循[AWS 分担责任模型](https://aws.amazon.com/compliance/shared-responsibility-model/)。 AWS Clean Rooms 提供了[分析规则](analysis-rules.md)，您可以配置这些规则以增强在协作中保护敏感数据的能力。您在中配置的分析规则 AWS Clean Rooms 将强制执行您配置的限制（查询控件和查询输出控件）。您负责确定限制并相应地配置分析规则。 数据协作可能涉及的不仅仅是您的使用。 AWS Clean Rooms为了帮助您最大限度地发挥数据协作的优势，我们建议您在使用分析规则时执行以下最佳实践 AWS Clean Rooms ，特别是分析规则。 **Topics** + [最佳实践 AWS Clean Rooms](#best-practices-with-clean-rooms) + [在中使用分析规则的最佳实践 AWS Clean Rooms](#best-practices-for-analysis-rules) ## 最佳实践 AWS Clean Rooms 您负责评估每个数据协作的风险，并将其与您的隐私要求（例如外部和内部合规性计划和策略）进行比较。我们建议您在使用时采取其他措施 AWS Clean Rooms。这些操作可能有助于进一步管理风险，并有助于防范第三方试图重新识别您的数据（例如，差异攻击或侧信道攻击）。 例如，考虑对您的其他协作者进行尽职调查，并在进行协作*之前* 与他们签订法律协议。要监控数据的使用情况，还要考虑在使用 AWS Clean Rooms时采用其他审计机制。 ## 在中使用分析规则的最佳实践 AWS Clean Rooms 中的分析规则 AWS Clean Rooms 允许您通过在已配置的表上设置查询控件来限制可以运行的查询。例如，您可以设置查询控制，以确定如何联接配置表以及可以选择哪些列。您还可以通过设置查询结果控制（例如输出行的聚合阈值）来限制查询输出。该服务拒绝任何查询，并删除不符合成员在查询中配置表上设置的分析规则的行。 对于在配置表上使用分析规则，我们推荐以下 *10 种最佳实践*： + 为不同的查询使用案例（例如受众规划或归因）创建单独的配置表。您可以使用同一底层 AWS Glue 表创建多个配置表。 + 在分析规则中指定协作中查询所必需的列（例如维度列、列表列、联接列）。这可能有助于降低差异攻击的风险或使其他成员能够对您的数据进行逆向工程。使用**允许列表列**功能记下将来可能要设置为可查询的其他列。要自定义可用于特定协作的列，请使用相同的基础表创建其他已配置 AWS Glue 表。 + 在分析规则中指定协作中分析所必需的函数。这有助于降低因罕见的函数错误而带来的风险，这些错误可能会显示单个数据点的信息。要自定义可用于特定协作的函数，请使用同一底层 AWS Glue 表创建其他配置表。 + 对行级值敏感的任何列添加聚合约束。这包括您的配置表中的列，这些列也存在于其他协作成员的表中，并且有分析规则作为聚合约束。这也包括您的配置表中不可查询的列，即配置表中有但不在分析规则中的列。聚合约束可以帮助降低将查询结果与协作之外的数据关联起来的风险。 + 创建测试协作和分析规则，以测试使用指定分析规则创建的限制。 + 查看协作者配置表和成员对配置表的分析规则，以检查它们是否符合协作商定的内容。这可以帮助降低其他成员设计自己的数据以运行未商定的查询所带来的风险。 + 查看提供的示例查询（仅限控制台），该查询在设置分析规则后在配置表上启用。 **注意** 除了提供的示例查询外，还可以根据分析规则和其他协作成员表和分析规则进行其他查询。 + 您可以为协作中的配置表添加或更新分析规则。完成后，请查看与配置表关联的所有协作及其产生的影响。这有助于确保任何协作都不会使用过时的分析规则。 + 审核协作中运行的查询，检查查询是否与协作中商定的使用案例或查询相匹配。（打开**查询日志记录**功能后，可在查询日志中查看查询）。这可以帮助降低成员运行未商定的分析和潜在攻击（例如侧信道攻击）带来的风险。 + 审核协作成员分析规则和查询中使用的配置表列，检查它们是否与协作中商定的内容相匹配。（打开该功能后，可在查询日志中查看查询。） 这可以帮助降低其他成员设计自己的数据以进行未商定的查询所带来的风险。 # 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" ] } ] } ``` ------ # 合规性验证 AWS Clean Rooms 要了解是否属于特定合规计划的范围，请参阅AWS 服务 “[按合规计划划分的范围](https://aws.amazon.com/compliance/services-in-scope/)” ”，然后选择您感兴趣的合规计划。 AWS 服务 有关一般信息，请参阅[AWS 合规计划AWS](https://aws.amazon.com/compliance/programs/)。 您可以使用下载第三方审计报告 AWS Artifact。有关更多信息，请参阅中的 “[下载报告” 中的 “ AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)。 您在使用 AWS 服务 时的合规责任取决于您的数据的敏感性、贵公司的合规目标以及适用的法律和法规。有关您在使用时的合规责任的更多信息 AWS 服务，请参阅[AWS 安全文档](https://docs.aws.amazon.com/security/)。 # 韧性在 AWS Clean Rooms AWS 全球基础设施是围绕 AWS 区域和可用区构建的。各区域提供多个在物理上独立且隔离的可用区，这些可用区通过延迟低、吞吐量高且冗余性高的网络连接在一起。利用可用区，您可以设计和操作在可用区之间无中断地自动实现故障转移的应用程序和数据库。与传统的单个或多个数据中心基础设施相比，可用区具有更高的可用性、容错能力和可扩展性。 有关 AWS 区域和可用区的更多信息，请参阅[AWS 全球基础设施](https://aws.amazon.com/about-aws/global-infrastructure/)。 # 中的基础设施安全 AWS Clean Rooms 作为一项托管服务 AWS Clean Rooms ，受 AWS 全球网络安全的保护。有关 AWS 安全服务以及如何 AWS 保护基础设施的信息，请参阅[AWS 云安全](https://aws.amazon.com/security/)。要使用基础设施安全的最佳实践来设计您的 AWS 环境，请参阅 S * AWS ecurity Pillar Well-Architected Fram* ework 中的[基础设施保护](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html)。 您可以使用 AWS 已发布的 API 调用 AWS Clean Rooms 通过网络进行访问。客户端必须支持以下内容： + 传输层安全性协议（TLS）。我们要求使用 TLS 1.2，建议使用 TLS 1.3。 + 具有完全向前保密（PFS）的密码套件，例如 DHE（临时 Diffie-Hellman）或 ECDHE（临时椭圆曲线 Diffie-Hellman）。大多数现代系统（如 Java 7 及更高版本）都支持这些模式。 ## 网络安全 在查询执行期间从 S3 存储桶 AWS Clean Rooms 读取数据时，与 Amazon S3 AWS Clean Rooms 之间的流量将通过 AWS 私有网络安全路由。飞行中的流量使用亚马逊签名版本 4 协议 (SIGv4) 进行签名，并使用 HTTPS 进行加密。此流量根据您为配置表设置的 IAM 服务角色进行授权。 您可以 AWS Clean Rooms 通过终端节点以编程方式连接到。有关服务端点的列表，请参阅《AWS 一般参考》**中的 [AWS Clean Rooms 端点和配额](https://docs.aws.amazon.com/general/latest/gr/clean-rooms.html#clean-rooms_region)。 所有服务端点都只支持 HTTPS。如果您想从 VPC 连接但又不想连接互联 AWS Clean Rooms 网，则可以使用亚马逊虚拟私有云 (VPC) 终端节点。有关更多信息，请参阅*AWS PrivateLink 指南 AWS PrivateLink*中的[通过访问 AWS 服务](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html)。 您可以为您的 IAM 委托人分配 IAM 策略，这些委托人使用 aws[: SourceVpce 上下文密钥](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcevpce)来限制您的 IAM 委托人只能通过 VPC 终端节点进行调用，而不能 AWS Clean Rooms 通过互联网进行调用。 # 使用接口端点进行访问 AWS Clean Rooms 或 AWS Clean Rooms ML (AWS PrivateLink) 您可以使用 AWS PrivateLink 在您的虚拟私有云 (VPC) 和/ AWS Clean Rooms 或 AWS Clean Rooms ML 之间创建私有连接。您可以像在 VPC 中一样访问 AWS Clean Rooms 或 AWS Clean Rooms ML，无需使用互联网网关、NAT 设备、VPN 连接或 Direct Connect 连接。VPC 中的实例不需要公有 IP 地址即可访问 AWS Clean Rooms。 您可以通过创建由 AWS PrivateLink提供支持的*接口端点*来建立此私有连接。我们将在您为接口端点启用的每个子网中创建一个端点网络接口。这些是请求者托管的网络接口，用作发往 AWS Clean Rooms的流量的入口点。 有关更多信息，请参阅《AWS PrivateLink 指南》**中的[通过 AWS PrivateLink访问 AWS 服务](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html)。 ## 的注意事项 AWS Clean Rooms 在为设置接口端点之前 AWS Clean Rooms，请查看*AWS PrivateLink 指南*中的[注意事项](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#considerations-interface-endpoints)。 AWS Clean Rooms 而且 AWS Clean Rooms ML 支持通过接口端点调用其所有 API 操作。 AWS Clean Rooms 或 AWS Clean Rooms ML 不支持 VPC 终端节点策略。默认情况下，允许通过接口端点对 AWS Clean Rooms 和 AWS Clean Rooms ML 进行完全访问。或者，您可以将安全组与端点网络接口关联，以控制通过接口终端节点 AWS Clean Rooms 传入或 AWS Clean Rooms 机器学习的流量。 ## 为创建接口终端节点 AWS Clean Rooms 您可以使用 Amazon VPC 控制台 AWS Clean Rooms 或 AWS Command Line Interface (AWS CLI) 为或 AWS Clean Rooms ML 创建接口终端节点。有关更多信息，请参阅《AWS PrivateLink 指南》**中的[创建接口端点](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws)。 AWS Clean Rooms 使用以下服务名称创建接口终端节点。 ``` com.amazonaws.region.cleanrooms ``` 使用以下服务名称为 AWS Clean Rooms ML 创建接口终端节点。 ``` com.amazonaws.region.cleanrooms-ml ``` 如果为接口端点启用私有 DNS，则可使用其默认区域 DNS 名称向 AWS Clean Rooms 发出 API 请求。例如 `cleanrooms-ml.us-east-1.amazonaws.com`。