本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 安全性 AWS Resource Groups 云安全 AWS 是重中之重。作为 AWS 客户，您可以受益于专为满足大多数安全敏感型组织的要求而构建的数据中心和网络架构。 安全是双方共同承担 AWS 的责任。[责任共担模式](https://aws.amazon.com/compliance/shared-responsibility-model/)将其描述为云*的* 安全性和云*中* 的安全性： + **云安全** — AWS 负责保护在 AWS 云中运行 AWS 服务的基础架构。 AWS 还为您提供可以安全使用的服务。作为 [AWS 合规性计划](https://aws.amazon.com/compliance/programs/)的一部分，第三方审核人员将定期测试和验证安全性的有效性。要了解适用于 AWS Resource Groups的合规性计划，请参阅[合规性计划范围内的AWS 服务](https://aws.amazon.com/compliance/services-in-scope/)。 + **云端安全**-您的责任由您使用的 AWS 服务决定。您还需要对其他因素负责，包括您的数据的敏感性、您公司的要求以及适用的法律法规。 此文档将帮助您了解如何在使用 Resource Groups 时应用责任共担模式。以下主题说明如何配置 Resource Groups 以实现您的安全性和合规性目标。您还将学习如何使用其他 AWS 服务来帮助您监控和保护您的 Resource Groups 资源。 **Topics** + [中的数据保护 AWS Resource Groups](security_data-protection.md) + [的身份和访问管理 AWS Resource Groups](security-iam.md) + [Resource Groups 中的日志记录和监控](security_logging-monitoring.md) + [Resource Group 的合规性验证](security_compliance.md) + [Resource Group 中的恢复能力](security_resilience.md) + [Resource Groups 中的基础设施安全性](security_infrastructure.md) + [AWS Resource Groups 使用接口端点进行访问 (AWS PrivateLink)](vpc-interface-endpoints.md) + [Resource Groups 的安全最佳实践](security_best-practices.md) # 中的数据保护 AWS Resource Groups 分 AWS [担责任模型](https://aws.amazon.com/compliance/shared-responsibility-model/)适用于中的数据保护 AWS Resource Groups。如本模型所述 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 服务 使用资源组或其他资源组 AWS CLI时 AWS SDKs。在用于名称的标签或自由格式文本字段中输入的任何数据都可能会用于计费或诊断日志。如果您向外部服务器提供 URL，强烈建议您不要在网址中包含凭证信息来验证对该服务器的请求。 ## 数据加密 与其他 AWS 服务相比， AWS Resource Groups 它的攻击面最小，因为它不提供更改、添加或删除除组之外的 AWS 资源的方式。Resource Groups 会向您收集以下特定于服务的信息。 + 组名称（未加密，非私有） + 组描述（未加密，但为私有） + 组中的成员资源（这些资源存储在未加密的日志中） ### 静态加密 没有其他方法可以隔离特定于 Resource Groups 的服务或网络流量。如果适用，请使用 AWS特定隔离。您可以在 VPC 中使用 Resource Groups API 和控制台来帮助最大限度地提高隐私和基础设施安全。 ### 传输中加密 AWS Resource Groups 数据在传输到服务的内部数据库进行备份时会经过加密。用户无法对其进行配置。 ### 密钥管理 AWS Resource Groups 当前未与集成 AWS Key Management Service ，也不支持 AWS KMS keys。 ## 互联网络流量隐私 AWS Resource Groups Resource Groups 用户和 AWS之间的所有传输都使用 HTTPS。Resource Groups 使用传输层安全性协议（TLS）1.2，但也支持 TLS 1.0 和 1.1。 # 的身份和访问管理 AWS Resource Groups AWS Identity and Access Management (IAM) AWS 服务 可帮助管理员安全地控制对 AWS 资源的访问权限。IAM 管理员控制谁可以通过*身份验证*（登录）和*授权*（有权限）使用 Resource Groups 资源。您可以使用 IAM AWS 服务 ，无需支付额外费用。 **Topics** + [受众](#security_iam_audience_arg-te) + [使用身份进行身份验证](#security_iam_authentication_arg-te) + [使用策略管理访问](#security_iam_access-manage-arg-te) + [Resure Groups 如何与 IAM 结合使用](security_iam_service-with-iam.md) + [AWS 的托管策略 AWS Resource Groups](security_iam_awsmanpol.md) + [为 Resource Groups 使用服务相关角色](security_iam_service-linked-roles.md) + [AWS Resource Groups 基于身份的策略示例](security_iam_id-based-policy-examples.md) + [对 AWS Resource Groups 身份和访问进行故障排除](security_iam_troubleshoot.md) ## 受众 您的使用方式 AWS Identity and Access Management (IAM) 因您的角色而异： + **服务用户**：如果您无法访问功能，请从管理员处请求权限（请参阅[对 AWS Resource Groups 身份和访问进行故障排除](security_iam_troubleshoot.md)） + **服务管理员**：确定用户访问权限并提交权限请求（请参阅[Resure Groups 如何与 IAM 结合使用](security_iam_service-with-iam.md)） + **IAM 管理员**：编写用于管理访问权限的策略（请参阅[AWS Resource Groups 基于身份的策略示例](security_iam_id-based-policy-examples.md)） ## 使用身份进行身份验证 身份验证是您 AWS 使用身份凭证登录的方式。您必须以 IAM 用户身份进行身份验证 AWS 账户根用户，或者通过担任 IAM 角色进行身份验证。 您可以使用来自身份源的证书 AWS IAM Identity Center （例如（IAM Identity Center）、单点登录身份验证或 Google/Facebook 证书，以联合身份登录。有关登录的更多信息，请参阅《AWS 登录 用户指南》**中的[如何登录您的 AWS 账户](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)。 对于编程访问， AWS 提供 SDK 和 CLI 来对请求进行加密签名。有关更多信息，请参阅*《IAM 用户指南》*中的[适用于 API 请求的AWS 签名版本 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)。 ### AWS 账户 root 用户 创建时 AWS 账户，首先会有一个名为 AWS 账户 *root 用户的*登录身份，该身份可以完全访问所有资源 AWS 服务 和资源。我们强烈建议不要使用根用户进行日常任务。有关要求根用户凭证的任务，请参阅*《IAM 用户指南》*中的[需要根用户凭证的任务](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)。 ### 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 在委托人提出请求时评估这些政策。大多数策略都以 JSON 文档的 AWS 形式存储在中。有关 JSON 策略文档的更多信息，请参阅*《IAM 用户指南》*中的 [JSON 策略概述](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)。 管理员使用策略，通过定义哪个**主体**可以在什么**条件**下对哪些**资源**执行哪些**操作**来指定谁有权访问什么。 默认情况下，用户和角色没有权限。IAM 管理员创建 IAM 策略并将其添加到角色中，然后用户可以担任这些角色。IAM 策略定义权限，与执行操作所用的方法无关。 ### 基于身份的策略 基于身份的策略是您附加到身份（用户、组或角色）的 JSON 权限策略文档。这些策略控制身份可以执行什么操作、对哪些资源执行以及在什么条件下执行。要了解如何创建基于身份的策略，请参阅《IAM 用户指南》**中的[使用客户管理型策略定义自定义 IAM 权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)。 基于身份的策略可以是*内联策略*（直接嵌入到单个身份中）或*托管策略*（附加到多个身份的独立策略）。要了解如何在托管策略和内联策略之间进行选择，请参阅*《IAM 用户指南》*中的[在托管策略与内联策略之间进行选择](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html)。 ### 基于资源的策略 基于资源的策略是附加到资源的 JSON 策略文档。示例包括 IAM *角色信任策略*和 Amazon S3 *存储桶策略*。在支持基于资源的策略的服务中，服务管理员可以使用它们来控制对特定资源的访问。您必须在基于资源的策略中[指定主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)。 基于资源的策略是位于该服务中的内联策略。您不能在基于资源的策略中使用 IAM 中的 AWS 托管策略。 ### 访问控制列表 (ACLs) 访问控制列表 (ACLs) 控制哪些委托人（账户成员、用户或角色）有权访问资源。 ACLs 与基于资源的策略类似，尽管它们不使用 JSON 策略文档格式。 Amazon S3 和 Amazon VPC 就是支持的服务示例 ACLs。 AWS WAF要了解更多信息 ACLs，请参阅《*亚马逊简单存储服务开发者指南*》中的[访问控制列表 (ACL) 概述](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html)。 ### 其他策略类型 AWS 支持其他策略类型，这些策略类型可以设置更常见的策略类型授予的最大权限： + **权限边界** – 设置基于身份的策略可以授予 IAM 实体的最大权限。有关更多信息，请参阅《 IAM 用户指南》**中的 [IAM 实体的权限边界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)。 + **服务控制策略 (SCPs)**-在中指定组织或组织单位的最大权限 AWS Organizations。有关更多信息，请参阅《AWS Organizations 用户指南》**中的[服务控制策略](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)。 + **资源控制策略 (RCPs)**-设置账户中资源的最大可用权限。有关更多信息，请参阅《*AWS Organizations 用户指南》*中的[资源控制策略 (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.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)。 # Resure Groups 如何与 IAM 结合使用 在使用 IAM 管理对 Resource Groups 的访问之前，您应了解哪些 IAM 功能可与 Resource Groups 结合使用。要大致了解 Resource Groups 和其它 AWS 服务如何与 IAM 一起使用，请参阅 *IAM 用户指南*中的[与 IAM 一起使用的AWS 服务](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)。 **Topics** + [Resource Groups 基于身份的策略](#security_iam_service-with-iam-id-based-policies-arg-te) + [基于资源的策略](#security_iam_resource-based-policies) + [基于 Resource Groups 标签的授权](#security_iam_tags) + [Resource Groups IAM 角色](#security_iam_roles) ## Resource Groups 基于身份的策略 通过使用 IAM 基于身份的策略，您可以指定允许或拒绝的操作和资源以及允许或拒绝操作的条件。Resource Groups 支持特定的操作、资源和条件键。要了解在 JSON 策略中使用的所有元素，请参阅《IAM 用户指南》** 中的 [IAM JSON 策略元素参考](https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_policies_elements.html)。 ### 操作 管理员可以使用 AWS JSON 策略来指定谁有权访问什么。也就是说，哪个**主体**可以对什么**资源**执行**操作**，以及在什么**条件**下执行。 JSON 策略的 `Action` 元素描述可用于在策略中允许或拒绝访问的操作。在策略中包含操作以授予执行关联操作的权限。 Resource Groups 中的策略操作在操作前使用以下前缀：`resource-groups:`。标签编辑器操作完全在控制台中执行，但在日志条目中带有前缀 `resource-explorer`。 例如，要授予某人使用 Resource Groups `CreateGroup` API 操作创建 Resource Groups 组的权限，您应将 `resource-groups:CreateGroup` 操作纳入其策略中。策略语句必须包含 `Action` 或 `NotAction` 元素。Resource Groups 定义了一组自己的操作，以描述您可以使用该服务执行的任务。 要在单个语句中指定多项 Resource Groups 和标签编辑器操作，请使用逗号将它们隔开，如下所示： ``` "Action": [ "resource-groups:action1", "resource-groups:action2", "resource-explorer:action3" ``` 您也可以使用通配符（\$1）指定多个操作。例如，要指定以单词 `List` 开头的所有操作，包括以下操作： ``` "Action": "resource-groups:List*" ``` 要查看 Resource Groups 操作的列表，请参阅 *IAM 用户指南* 中的 [AWS Resource Groups的操作、资源和条件键](https://docs.aws.amazon.com//IAM/latest/UserGuide/list_awsresourcegroups.html)。 ### 资源 管理员可以使用 AWS JSON 策略来指定谁有权访问什么。也就是说，哪个**主体**可以对什么**资源**执行**操作**，以及在什么**条件**下执行。 `Resource` JSON 策略元素指定要向其应用操作的一个或多个对象。作为最佳实践，请使用其 [Amazon 资源名称（ARN）](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html)指定资源。对于不支持资源级权限的操作，请使用通配符 (\$1) 指示语句应用于所有资源。 ``` "Resource": "*" ``` 唯一的 Resource Groups 资源是*组*。组资源采用以下 ARN 格式： ``` arn:${Partition}:resource-groups:${Region}:${Account}:group/${GroupName} ``` 有关格式的更多信息 ARNs，请参阅 [Amazon 资源名称 (ARNs) 和 AWS 服务命名空间](https://docs.aws.amazon.com//general/latest/gr/aws-arns-and-namespaces.html)。 例如，要在语句中指定 `my-test-group` 资源组，请使用以下 ARN： ``` "Resource": "arn:aws:resource-groups:us-east-1:123456789012:group/my-test-group" ``` 要指定属于特定账户的所有组，请使用通配符（\$1）： ``` "Resource": "arn:aws:resource-groups:us-east-1:123456789012:group/*" ``` 无法对特定资源执行某些 Resource Groups 操作，例如，用于创建资源的操作。在这些情况下，您必须使用通配符（\$1)。 ``` "Resource": "*" ``` 一些 Resource Groups API 操作可涉及多种资源。例如，`DeleteGroup` 删除群组，因此调用主体必须具有删除特定组或所有组的权限。要在单个语句中指定多个资源，请 ARNs 用逗号分隔。 ``` "Resource": [ "resource1", "resource2" ] ``` 要查看 Resource Groups 资源类型及其列表 ARNs，并了解您可以使用哪些操作来指定每种资源的 ARN，请参阅 *IAM 用户*指南 AWS Resource Groups中的[操作、资源和条件密钥](https://docs.aws.amazon.com//IAM/latest/UserGuide/list_awsresourcegroups.html)。 ### 条件键 管理员可以使用 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)。 Resource Groups 定义了自己的一组条件键，还支持使用一些全局条件键。要查看所有 AWS 全局条件键，请参阅 *IAM 用户指南*中的[AWS 全局条件上下文密钥](https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_policies_condition-keys.html)。 要查看 Resource Groups 条件键的列表，并了解可以对哪些操作和资源使用条件键，请参阅 *IAM 用户指南*中的 [AWS Resource Groups的操作、资源和条件键](https://docs.aws.amazon.com//IAM/latest/UserGuide/list_awsresourcegroups.html)。 ### 示例 要查看基于 Resource Groups 身份的策略示例，请参阅 [AWS Resource Groups 基于身份的策略示例](security_iam_id-based-policy-examples.md)。 ## 基于资源的策略 Resource Groups 不支持基于资源的策略。 ## 基于 Resource Groups 标签的授权 您可以将标签附加到 Resource Groups 中的组，或者在请求中将标签传递给 Resource Groups。要基于标签控制访问，您需要使用 `aws:ResourceTag/key-name``aws:RequestTag/key-name` 或 `aws:TagKeys` 条件键在策略的[条件元素](https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_policies_elements_condition.html)中提供标签信息。在创建或更新组时，可以将标签应用于此组。有关在 Resource Groups 中为组添加标签的更多信息，请参阅本指南中的 [在中创建基于查询的群组 AWS Resource Groups](gettingstarted-query.md) 和 [更新中的群组 AWS Resource Groups](updating-resource-groups.md)。 要查看基于身份的策略（用于根据资源上的标签来限制对该资源的访问）的示例，请参阅 [查看基于标签的组](security_iam_id-based-policy-examples.md#security_iam_policy-examples-view-tags)。 ## Resource Groups IAM 角色 I [AM 角色](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles.html)是您的 AWS 账户中具有特定权限的实体。Resource Groups 没有或不使用服务角色。 ### 将临时凭证用于 Resource Groups 在 Resource Groups 中，您可以使用临时凭证进行联合身份登录，担任 IAM 角色或担任跨账户角色。您可以通过调用[AssumeRole](https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html)或之类的 AWS STS API 操作来获取临时安全证书[GetFederationToken](https://docs.aws.amazon.com//STS/latest/APIReference/API_GetFederationToken.html)。 ### 服务关联角色 [服务相关角色](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role)允许 AWS 服务访问其他服务中的资源以代表您完成操作。 Resource Groups 没有服务相关角色，也没有使用服务相关角色。 ### 服务角色 此功能允许服务代表您担任[服务角色](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-role)。 Resource Groups 没有或不使用服务角色。 # AWS 的托管策略 AWS Resource Groups 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)。 **Resource Groups 的AWS托管策略** + [ResourceGroupsServiceRolePolicy](#security-iam-awsmanpol-ResourceGroupsServiceRolePolicy) + [ ResourceGroupsTaggingAPITagUntagSupportedResources](#security-iam-awsmanpol-ResourceGroupsTaggingAPITagUntagSupportedResources) + [ResourceGroupsTaggingAPITagUntagSupportedResources](#security-iam-awsmanpol-ResourceGroupsTaggingAPITagUntagSupportedResources.title) ## AWS 托管策略： ResourceGroupsServiceRolePolicy 您不能将 `ResourceGroupsServiceRolePolicy` 附加到自己的 IAM 实体。此附加到服务相关角色的策略允许 Resource Groups 代表您执行操作。有关更多信息，请参阅 [为 Resource Groups 使用服务相关角色](security_iam_service-linked-roles.md)。 此策略授予 Resource Groups 检索有关您的资源组中的资源以及这些资源所属的任何 CloudFormation 堆栈的信息所需的权限。这允许 Resource Groups 为群组生命周期事件功能生成 CloudWatch 事件。 要查看此 AWS 托管策略的最新版本，请参阅 IAM 控制台`[ResourceGroupsServiceRolePolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/ResourceGroupsServiceRolePolicy)`中的。 ## AWS 托管策略： ResourceGroupsandTagEditorFullAccess 将策略附加到委托人实体时，即向该实体授予策略中定义的权限。 AWS 与必须自己编写策略相比，托管策略使您可以更轻松地为用户、组和角色分配适当的权限。 此策略授予对 Resource Groups 和标签编辑器功能的完全访问所需的权限。 要查看此 AWS 托管策略的最新版本，请参阅 IAM 控制台`[ResourceGroupsandTagEditorFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/ResourceGroupsandTagEditorFullAccess)`中的。 有关此策略的更多信息，请参阅[ ResourceGroupsandTagEditorFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ResourceGroupsandTagEditorFullAccess.html)《*AWS 托管策略参考指南》*。 ## AWS 托管策略： ResourceGroupsandTagEditorReadOnlyAccess 将策略附加到委托人实体时，即向该实体授予策略中定义的权限。 AWS 与必须自己编写策略相比，托管策略使您可以更轻松地为用户、组和角色分配适当的权限。 此策略授予对 Resource Groups 和标签编辑器功能的只读访问所需的权限。 要查看此 AWS 托管策略的最新版本，请参阅 IAM 控制台`[ResourceGroupsandTagEditorReadOnlyAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/ResourceGroupsandTagEditorReadOnlyAccess)`中的。 有关此策略的更多信息，请参阅[ ResourceGroupsandTagEditorReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ResourceGroupsandTagEditorReadOnlyAccess.html)《*AWS 托管策略参考指南》*。 ## AWS 托管策略： ResourceGroupsTaggingAPITagUntagSupportedResources 将策略附加到委托人实体时，即向该实体授予策略中定义的权限。 AWS 与必须自己编写策略相比，托管策略使您可以更轻松地为用户、组和角色分配适当的权限。 此策略授予标记和取消标记标记 API 支持的所有资源类型所需的权限`AWS::ApiGateway`，**但、`AWS::CloudFormation``AWS::CodeBuild`、和除外**。 AWS Resource Groups `AWS::ServiceCatalog`标记和取消标记这些被排除的资源类型需要额外的服务特定权限，这些权限允许除标记和取消标记之外的其他操作。以下列表描述了标记和取消标记策略中排除的资源类型需要哪些权限： + `AWS::ApiGateway`资源类型需要 API Gateway 资源的`apigateway:Patch`权限，标签子资源需要`apigateway:Put`、`apigateway:Get`、`apigateway:Delete`权限。 + `AWS::CloudFormation`资源类型需要`cloudformation:UpdateStack`和`cloudformation:UpdateStackSet`权限。 + `AWS::CodeBuild`资源类型需要`codebuild:UpdateProject`权限。 + `AWS::ServiceCatalog`资源类型需要`servicecatalog:TagResource`、`servicecatalog:UntagResource``servicecatalog:UpdatePortfolio`、和`servicecatalog:UpdateProduct`权限。 此策略还授予通过资源组标记 API 检索所有已标记或以前标记的资源所需的权限。 要查看此 AWS 托管策略的最新版本，请参阅 IAM 控制台`[ ResourceGroupsTaggingAPITagUntagSupportedResources](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/ResourceGroupsTaggingAPITagUntagSupportedResources)`中的。 有关此策略的更多信息，请参阅[ ResourceGroupsTaggingAPITagUntagSupportedResources](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ResourceGroupsTaggingAPITagUntagSupportedResources.html)《*AWS 托管策略参考指南》*。 ## Resource Groups 对 AWS 托管策略的更新 查看自该服务开始跟踪资源组（Resource Groups） AWS 托管策略变更以来这些更新的详细信息。有关此页面更改的自动提示，请订阅 [Resource Groups 文档历史记录](doc-history.md)页面上的 RSS 源。 | 更改 | 描述 | 日期 | | --- | --- | --- | | 更新后的政策 — [ResourceGroupsTaggingAPITagUntagSupportedResources](#security-iam-awsmanpol-ResourceGroupsTaggingAPITagUntagSupportedResources.title) | Resource Groups 更新了此政策，增加了八项新服务的权限，包括亚马逊应用程序恢复控制器 (ARC) 和亚马逊 VPC Lattice。策略中添加了以下权限： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/ARG/latest/userguide/security_iam_awsmanpol.html) | 2024 年 12 月 20 日 | | 新政策 — [ResourceGroupsTaggingAPITagUntagSupportedResources](#security-iam-awsmanpol-ResourceGroupsTaggingAPITagUntagSupportedResources.title) | Resource Groups 添加了一项新策略，以提供标记和取消标记标记 API 支持的所有资源类型所需的权限。 AWS Resource Groups | 2024 年 10 月 11 日 | | 政策更新 — [ResourceGroupsandTagEditorFullAccess](#security-iam-awsmanpol-ResourceGroupsandTagEditorFullAccess.title) | Resource Groups 更新了一项策略，使其包含了其他 AWS CloudFormation 权限。 | 2023 年 8 月 10 日 | | 政策更新 — [ResourceGroupsandTagEditorReadOnlyAccess](#security-iam-awsmanpol-ResourceGroupsandTagEditorReadOnlyAccess.title) | Resource Groups 更新了一项策略，使其包含了其他 AWS CloudFormation 权限。 | 2023 年 8 月 10 日 | | 新政策 — [ResourceGroupsServiceRolePolicy](#security-iam-awsmanpol-ResourceGroupsServiceRolePolicy.title) | Resource Groups 添加一项新策略来支持其服务关联角色。 | 2022 年 11 月 17 日 | | Resource Groups 开始跟踪更改 | Resource Groups 开始跟踪其 AWS 托管策略的更改。 | 2022 年 11 月 17 日 | # 为 Resource Groups 使用服务相关角色 AWS Resource Groups 使用 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 角色，它与 Resource Groups 直接相关。服务相关角色由 Resource Groups 预定义，并包含该服务代表您调用其它 AWS 服务 服务所需的一切权限。 服务相关角色可让您更轻松地设置 Resource Groups，因为您不必手动添加必要的权限。Resource Groups 定义了其服务相关角色的权限，并为每个角色设置信任策略以确保仅有 Resource Groups 服务可担任其角色。定义的权限包括信任策略和权限策略，以及不能附加到任何其他 IAM 实体的权限策略。 有关支持服务相关角色的其他服务的信息，请参阅与 [IAM 配合使用的AWS 服务，](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)并在**服务相关角色**列中查找标有 “**是**” 的服务。选择**是**和链接，查看该服务的服务关联角色文档。 ## Resource Groups 的服务相关角色权限 Resource Groups 使用以下服务相关角色来支持组生命周期事件。在创建角色后，选择角色名称上的链接，即可在 IAM 控制台中查看该角色。 + `[AWSServiceRoleForResourceGroups](https://console.aws.amazon.com/iamv2/home#/roles/details/AWSServiceRoleForResourceGroups)` Resource Groups 使用此角色的 AWS 服务 权限来查询拥有您的资源的人，以帮助解决群组成员资格问题并保留该群组 up-to-date。它允许 Resource Groups 向亚马逊 EventBridge 服务发送与服务相关的事件。 `AWSServiceRoleForResourceGroups`服务相关角色***仅信任***以下服务来担任该角色： + `resourcegroups.amazonaws.com` 附加到该角色的权限来自以下 AWS 托管策略。选择策略名称上的链接，在 IAM 控制台中查看策略。 + `AWS 的托管策略 AWS Resource Groups` ## 为 Resource Groups 创建服务相关角色 **重要** 如果您在其他需要此角色所支持功能的服务中完成某个操作，此服务相关角色可以出现在您的账户中。有关更多信息，请参阅 “[我的” 中出现了一个新角色 AWS 账户](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared)。 要创建服务相关角色，[请开启组生命周期事件功能](monitor-groups-turn-on.md)。 ## 编辑 Resource Groups 的服务相关角色 Resource Groups 不允许您编辑 AWSServiceRoleForResourceGroups 服务相关角色。在创建服务相关角色后，您将无法更改角色的名称，因为可能有多种实体引用该角色。不过，您可以使用 IAM 编辑角色的说明。有关更多信息，请参阅《IAM 用户指南》**中的[编辑服务关联角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)。 ## 删除 Resource Groups 的服务相关角色 只有在关闭组生命周期事件之后，您才可以删除服务相关角色。 **重要** AWS 防止您移除服务相关角色，直到您首次[关闭创建该角色的群组生命周期事件功能](monitor-groups-turn-off.md)。 我们建议您不要删除服务相关角色，前提是您的 AWS 账户资源组中包含任何资源组。如果您删除此角色，Resource Groups 服务将无法与其他人交互 AWS 服务 来管理您的群组。 ### 手动删除服务相关角色 使用 IAM 控制台 AWS CLI、或 AWS API 删除 AWSServiceRoleForResourceGroups服务相关角色。有关更多信息，请参阅《IAM 用户指南》**中的[删除服务关联角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)。 ------ #### [ Console ] **删除 Resource Groups 服务相关角色** 1. 打开 [IAM 控制台的“角色”页面](https://console.aws.amazon.com/iam/home#/roles)。 1. 找到名为的角色 AWSServiceRoleForResourceGroups，然后选中其旁边的复选框。 1. 选择**删除**。 1. 在框中输入角色的名称，然后选择**删除**，以确认您打算删除该角色。 角色从 IAM 控制台中的角色列表中消失。 ------ #### [ AWS CLI ] **删除 Resource Groups 服务相关角色** 要删除角色，请输入以下命令，其参数如图所示。不要替换任何值。 ``` $ aws iam delete-service-linked-role \ --role-name AWSServiceRoleForResourceGroups { "DeletionTaskId": "task/aws-service-role/resource-groups.amazonaws.com/AWSServiceRoleForResourceGroups/34e58943-e9a5-4220-9856-fc565EXAMPLE" } ``` 该命令返回一个任务 ID。实际的角色删除是异步进行的。您可以通过将提供的任务标识符传递给以下 AWS CLI 命令来检查角色删除的状态。 ``` $ aws iam get-service-linked-role-deletion-status \ --deletion-task-id "task/aws-service-role/resource-groups.amazonaws.com/AWSServiceRoleForResourceGroups/34e58943-e9a5-4220-9856-fc565EXAMPLE" { "Status": "SUCCEEDED" } ``` ------ ## Resource Groups 服务相关角色支持的区域 Resource Groups 支持在所有提供服务 AWS 区域 的地方使用与服务相关的角色。有关更多信息，请参阅 [AWS 区域和端点](https://docs.aws.amazon.com/general/latest/gr/rande.html)。 # AWS Resource Groups 基于身份的策略示例 默认情况下，IAM 主体（例如角色和用户）没有创建或修改 Resource Groups 资源的权限。他们也无法使用 AWS 管理控制台 AWS CLI、或 AWS API 执行任务。IAM 管理员必须创建 IAM 策略，以便为主体授予权限以对所需的指定资源执行特定的 API 操作。然后，管理员必须将这些策略附加到需要这些权限的主体。 要了解如何使用这些示例 JSON 策略文档创建 IAM 基于身份的策略，请参阅《IAM 用户指南》**中的[在 JSON 选项卡上创建策略](https://docs.aws.amazon.com//IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor)。 **Topics** + [策略最佳实践](#security_iam_policy-best-practices) + [使用 Resource Groups 控制台和 API](#security_iam_policy-examples-console) + [允许用户查看他们自己的权限](#security_iam_policy-examples-own-permissions) + [查看基于标签的组](#security_iam_policy-examples-view-tags) ## 策略最佳实践 基于身份的策略确定某个人是否可以创建、访问或删除您账户中的 Resource Groups 资源。这些操作可能会使 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)。 ## 使用 Resource Groups 控制台和 API 要访问 AWS Resource Groups 和标签编辑器控制台和 API，您必须拥有一组最低权限。这些权限必须允许您列出和查看 AWS 账户中 Resource Groups 资源的详细信息。如果您创建的基于身份的策略比所需的最低权限更严格，则无法为具有该策略的主体（IAM 角色或用户）按预期运行该控制台和 API 命令。 要确保这些实体仍可使用 Resource Groups，可向实体附加以下策略（或包含以下策略中列出的权限的策略）。有关更多信息，请参阅《IAM 用户指南》中的[为用户添加权限](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console)**： ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "resource-groups:*", "cloudformation:DescribeStacks", "cloudformation:ListStackResources", "tag:GetResources", "tag:TagResources", "tag:UntagResources", "tag:getTagKeys", "tag:getTagValues", "resource-explorer:List*" ], "Resource": "*" } ] } ``` ------ 有关授权访问 Resource Groups 的更多信息，请参阅本指南中的 [授予使用 AWS Resource Groups 和标签编辑器的权限](gettingstarted-prereqs-permissions-howto.md)。 ## 允许用户查看他们自己的权限 该示例说明了您如何创建策略，以允许 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": "*" } ] } ``` ## 查看基于标签的组 您可以在基于身份的策略中使用条件，以便基于标签控制对 Resource Groups 资源的访问。该示例说明了如何创建策略以允许查看资源，在此示例中为资源组。但是，仅当组标签 `project` 具有与调用主体附加的 `project` 标签相同的值时，才会授予权限。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "resource-groups:GetGroup", "Resource": "arn:aws:resource-groups:us-east-1:111122223333:group/group_name", "Condition": { "StringEquals": {"aws:ResourceTag/project": "${aws:PrincipalTag/project}"} } } ] } ``` ------ 您可以将此策略附加到您账户中的主体。如果具有标签键 `project` 和标签值 `alpha` 的主体尝试查看资源组，则还必须对该组标记 `project=alpha`。否则，该用户将被拒绝访问。条件标签键 `project` 匹配 `Project` 和 `project`，因为条件键名称不区分大小写。有关更多信息，请参阅 *IAM 用户指南* 中的 [IAM JSON 策略元素：条件](https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_policies_elements_condition.html)。 # 对 AWS Resource Groups 身份和访问进行故障排除 使用以下信息可帮助您诊断和修复在将 Resource Groups 和 IAM 一起使用时可能遇到的常见问题。 **Topics** + [我无权在 Resource Groups 中执行操作](#security_iam_troubleshoot-permissions-arg-te) + [我无权执行 iam：PassRole](#security_troubleshoot-passrole) + [我想允许 AWS 账户之外的人访问我的 Resource Groups](#security_troubleshoot-cross-account) ## 我无权在 Resource Groups 中执行操作 如果 AWS 管理控制台 告诉您您无权执行某项操作，则必须联系管理员寻求帮助。管理员是向您提供登录凭证的人。 当 `mateojackson` 用户尝试使用控制台查看组的详细信息，但不具有 `resource-groups:ListGroups` 权限时，会发生以下示例错误。 ``` User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: resource-groups:ListGroups on resource: arn:aws:resource-groups::us-west-2:123456789012:group/my-test-group ``` 在这种情况下，Mateo 请求他的管理员更新其策略，以允许他使用 `resource-groups:ListGroups` 操作访问 `my-test-group` 资源。 ## 我无权执行 iam：PassRole 如果您收到一个错误，表明您无权执行 `iam:PassRole` 操作，则必须更新策略以允许您将角色传递给 Resource Groups。 有些 AWS 服务 允许您将现有角色传递给该服务，而不是创建新的服务角色或服务相关角色。为此，您必须具有将角色传递到服务的权限。 当名为 `marymajor` 的 IAM 用户尝试使用控制台在 Resource Groups 中执行操作时，会发生以下示例错误。但是，服务必须具有服务角色所授予的权限才可执行此操作。Mary 不具有将角色传递到服务的权限。 ``` User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole ``` 在这种情况下，必须更新 Mary 的策略以允许她执行 `iam:PassRole` 操作。 如果您需要帮助，请联系您的 AWS 管理员。您的管理员是提供登录凭证的人。 ## 我想允许 AWS 账户之外的人访问我的 Resource Groups 您可以创建一个角色，以便其他账户中的用户或您组织外的人员可以使用该角色来访问您的资源。您可以指定谁值得信赖，可以代入角色。对于支持基于资源的策略或访问控制列表 (ACLs) 的服务，您可以使用这些策略向人们授予访问您的资源的权限。 要了解更多信息，请参阅以下内容： + 要了解 Resource Groups 是否支持这些功能，请参阅 [Resure Groups 如何与 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/access_policies-cross-account-resource-access.html)。 # Resource Groups 中的日志记录和监控 所有 AWS Resource Groups 操作均已登录 AWS CloudTrail。 ## 使用记录 AWS Resource Groups API 调用 AWS CloudTrail AWS Resource Groups 和标签编辑器与一项服务集成 AWS CloudTrail，该服务提供用户、角色或 AWS 服务在 Resource Groups 或标签编辑器中执行的操作的记录。 CloudTrail 将资源组的所有 API 调用捕获为事件，包括来自资源组或标签编辑器控制台的调用以及对资源组的代码调用 APIs。如果您创建了跟踪，则可以将 CloudTrail 事件持续传输到 Amazon S3 存储桶，包括资源组的事件。如果您未配置跟踪，您仍然可以在 CloudTrail 控制台的事件**历史记录中查看最新的事件**。通过收集的信息 CloudTrail，您可以确定向 Resource Groups 发出的请求、发出请求的 IP 地址、谁发出了请求、何时发出请求以及其他详细信息。 要了解更多信息 CloudTrail，请参阅[AWS CloudTrail 用户指南](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/)。 ### 中的 Resource Groups 信息 CloudTrail CloudTrail 在您创建 AWS 账户时已在您的账户上启用。当活动发生在 Resource Groups 或标签编辑器控制台中时，该活动会与其他 AWS 服务 CloudTrail事件一起记录在**事件历史**记录中。您可以在自己的 AWS 账户中查看、搜索和下载最近发生的事件。有关更多信息，请参阅[使用事件历史记录查看 CloudTrail 事件](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/view-cloudtrail-events.html)。 要持续记录您的 AWS 账户中的事件，包括 Resource Groups 的事件，请创建跟踪。跟踪允许 CloudTrail 将日志文件传输到 Amazon S3 存储桶。默认情况下，在控制台中创建跟踪记录时，此跟踪记录应用于所有区域。跟踪记录 AWS 分区中所有区域的事件，并将日志文件传送到您指定的 Amazon S3 存储桶。此外，您可以配置其他 AWS 服务，进一步分析在 CloudTrail 日志中收集的事件数据并采取行动。有关更多信息，请参阅: + [创建跟踪概述](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html) + [CloudTrail 支持的服务和集成](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html) + [配置 Amazon SNS 通知 CloudTrail](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/getting_notifications_top_level.html) + [从多个区域接收 CloudTrail 日志文件](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html)和[从多个账户接收 CloudTrail 日志文件](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html) 所有 Resource Groups 操作都由 API 参考记录 CloudTrail 并记录在 [AWS Resource Groups API 参考](https://docs.aws.amazon.com//ARG/latest/APIReference/)中。中的 Resource CloudTrail Groups 操作显示为以 API 端点`resource-groups.amazonaws.com`为来源的事件。例如，对`CreateGroup``GetGroup`、和`UpdateGroupQuery`操作的调用会在 CloudTrail 日志文件中生成条目。控制台中的标签编辑器操作由 CloudTrail记录并显示为以内部 API 端点`resource-explorer`为来源的事件。 每个事件或日志条目都包含有关生成请求的人员信息。身份信息可帮助您确定以下内容： + 请求是使用根用户凭证还是 IAM 用户凭证发出的。 + 请求是使用角色还是联合用户的临时安全凭证发出的。 + 请求是否由其他 AWS 服务发出。 有关更多信息，请参阅 [CloudTrail `userIdentity` 元素](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html)。 ### 了解 Resource Groups 日志文件条目 跟踪是一种配置，允许将事件作为日志文件传输到您指定的 Amazon S3 存储桶。 CloudTrail 日志文件包含一个或多个日志条目。一个事件表示来自任何源的一个请求，包括有关所请求的操作、操作的日期和时间、请求参数等方面的信息。 CloudTrail 日志文件不是公用 API 调用的有序堆栈跟踪，因此它们不会以任何特定顺序显示。 以下示例显示了演示该操作的 CloudTrail 日志条目`CreateGroup`。 ``` {"eventVersion":"1.05", "userIdentity":{ "type":"AssumedRole", "principalId":"ID number:AWSResourceGroupsUser", "arn":"arn:aws:sts::831000000000:assumed-role/Admin/AWSResourceGroupsUser", "accountId":"831000000000","accessKeyId":"ID number", "sessionContext":{ "attributes":{ "mfaAuthenticated":"false", "creationDate":"2018-06-05T22:03:47Z" }, "sessionIssuer":{ "type":"Role", "principalId":"ID number", "arn":"arn:aws:iam::831000000000:role/Admin", "accountId":"831000000000", "userName":"Admin" } } }, "eventTime":"2018-06-05T22:18:23Z", "eventSource":"resource-groups.amazonaws.com", "eventName":"CreateGroup", "awsRegion":"us-west-2", "sourceIPAddress":"100.25.190.51", "userAgent":"console.amazonaws.com", "requestParameters":{ "Description": "EC2 instances that we are using for application staging.", "Name": "Staging", "ResourceQuery": { "Query": "string", "Type": "TAG_FILTERS_1_0" }, "Tags": { "Key":"Phase", "Value":"Stage" } }, "responseElements":{ "Group": { "Description":"EC2 instances that we are using for application staging.", "groupArn":"arn:aws:resource-groups:us-west-2:831000000000:group/Staging", "Name":"Staging" }, "resourceQuery": { "Query":"string", "Type":"TAG_FILTERS_1_0" } }, "requestID":"de7z64z9-d394-12ug-8081-7zz0386fbcb6", "eventID":"8z7z18dz-6z90-47bz-87cf-e8346428zzz3", "eventType":"AwsApiCall", "recipientAccountId":"831000000000" } ``` # Resource Group 的合规性验证 要了解是否属于特定合规计划的范围，请参阅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/)。 # Resource Group 中的恢复能力 AWS Resource Groups 自动备份到内部服务资源。这些备份不可由用户配置。静态和传输中的备份均经过加密。Resource Groups 将客户数据存储在 Amazon DynamoDB 中。 AWS 全球基础设施是围绕 AWS 区域 可用区构建的。 AWS 区域 提供多个物理隔离和隔离的可用区，这些可用区通过低延迟、高吞吐量和高度冗余的网络连接。利用可用区，您可以设计和操作在可用区之间无中断地自动实现失效转移的应用程序和数据库。与传统的单个或多个数据中心基础架构相比，可用区具有更高的可用性、容错性和可扩展性。 即使用户资源组完全丢失也不会导致客户数据丢失，因为大多数客户数据都是跨 AWS 可用区复制的（AZs）。如果您意外删除组，请联系 [AWS 支持 中心](https://console.aws.amazon.com/support/home#/)。 有关 AWS 区域 和可用区的更多信息，请参阅[AWS 全球基础设施](https://aws.amazon.com/about-aws/global-infrastructure/)。 # Resource Groups 中的基础设施安全性 没有其他方法来隔离 Resource Groups 提供的服务或网络流量。如果适用，请使用 AWS特定隔离。您可以在 VPC 中使用 Resource Groups API 和控制台来帮助最大限度地提高隐私和基础设施安全。 作为一项托管服务 AWS Resource Groups ，受 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 调用通过网络访问 Resource Groups。客户端必须支持以下内容： + 传输层安全性协议（TLS）。我们要求使用 TLS 1.2，建议使用 TLS 1.3。 + 具有完全向前保密（PFS）的密码套件，例如 DHE（临时 Diffie-Hellman）或 ECDHE（临时椭圆曲线 Diffie-Hellman）。大多数现代系统（如 Java 7 及更高版本）都支持这些模式。 Resource Groups 不支持基于资源的策略。 # AWS Resource Groups 使用接口端点进行访问 (AWS PrivateLink) 您可以使用 AWS PrivateLink 在您的 VPC 和之间创建私有连接 AWS Resource Groups。您可以像访问您的 VPC 一样访问资源组，无需使用互联网网关、NAT 设备、VPN 连接或 Direct Connect 连接。您的 VPC 中的实例不需要公有 IP 地址即可访问 Resource Groups。 您可以通过创建由 AWS PrivateLink提供支持的*接口端点*来建立此私有连接。我们将在您为接口端点启用的每个子网中创建一个端点网络接口。这些是请求者管理的网络接口，用作发往 Resource Groups 的流量的入口点。 有关更多信息，请参阅*AWS PrivateLink 指南 AWS PrivateLink*中的[AWS 服务 通过访问](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html)。 ## 资源组的注意事项 在为 Resource Groups 设置接口端点之前，请查看*AWS PrivateLink 指南*中的[注意事项](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#considerations-interface-endpoints)。 Resource Groups 支持通过接口端点调用其所有 API 操作。 ## 为 Resource Groups 创建接口端点 您可以使用 Amazon VPC 控制台或 AWS Command Line Interface (AWS CLI) 为 Resource Groups 创建接口终端节点。有关更多信息，请参阅《AWS PrivateLink 指南》**中的[创建接口端点](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws)。 使用以下服务名称为 Resource Groups 创建接口终端节点： ``` com.amazonaws.region.resource-groups ``` 如果您为接口终端节点启用私有 DNS，则可以使用资源组的默认区域 DNS 名称向 Resource Groups 发出 API 请求。例如 `resource-groups.us-east-1.amazonaws.com`。 ## 为 VPC 端点创建端点策略 端点策略是一种 IAM 资源，您可以将其附加到接口端点。默认终端节点策略允许通过接口终端节点完全访问资源组。要控制允许从您的 VPC 访问 Resource Groups 的权限，请将自定义终端节点策略附加到接口终端节点。 端点策略指定以下信息： + 可执行操作的主体（AWS 账户、IAM 用户和 IAM 角色）。 + 可执行的操作。 + 可对其执行操作的资源。 有关更多信息，请参阅《AWS PrivateLink 指南》**中的[使用端点策略控制对服务的访问权限](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html)。 **示例：Resource Groups 操作的 VPC 终端节点策略** 以下是自定义端点策略的示例。当您将此策略附加到接口终端节点时，它会授予所有委托人对所有资源执行列出的 Resource Groups 操作的访问权限。 ``` { "Statement": [ { "Principal": "*", "Effect": "Allow", "Action": [ "resource-groups:CreateGroup", "resource-groups:GetAccountSettings", "resource-groups:GetGroupQuery" ], "Resource":"*" } ] } ``` # Resource Groups 的安全最佳实践 以下最佳实践是一般指导原则，并不代表完整安全解决方案。这些最佳实践可能不适合环境或不满足环境要求，请将其视为有用的考虑因素而不是惯例。 + **使用最低权限**授予组访问权限的原则。Resource Groups 支持资源级权限。仅在特定用户需要时才授予特定组的访问权限。避免在向所有用户或所有组分配权限的策略声明中使用星号。有关最低权限的更多信息，请参阅 *IAM 用户指南*中的[授予最低权限](https://docs.aws.amazon.com//IAM/latest/UserGuide/best-practices.html#grant-least-privilege)。 + **避免在公共字段中包含私有信息。**组的名称视为服务元数据。组名称未加密。请勿在组名称中输入敏感信息。组描述是私有信息。 请勿在标签键或标签值中放入私有或敏感信息。 + 在适当时**使用基于标记的授权**。Resource Groups 支持基于标签的授权。您可以为组添加标签，然后更新附加到您的 IAM 主体（例如用户和角色）的策略，以根据应用于组的标签来设置其访问级别。有关如何使用基于标签的授权的更多信息，请参阅 *IAM 用户指南*中的[使用 AWS 资源标签控制对资源的访问权限](https://docs.aws.amazon.com//IAM/latest/UserGuide/access_tags.html)。 许多 AWS 服务都支持基于其资源的标签进行授权。请注意，可能会为组中的成员资源配置基于标签的授权。如果对组资源的访问受到标签的限制，则未经授权的用户或组可能无法对这些资源执行操作或自动化。例如，如果您的一个组中的某个 Amazon EC2 实例的`Confidentiality`标签键为，标签值为`High`，并且您无权对已标记的资源运行命令`Confidentiality:High`，则即使资源组中的其他资源成功执行操作，您对该 EC2 实例执行的操作或自动化也将失败。有关哪些服务支持对其资源进行基于标签的授权的更多信息，请参阅 *IAM 用户指南*中的[与 IAM 配合使用的AWS 服务](https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)。 有关为 AWS 资源制定标签策略的更多信息，请参阅[AWS 标记](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/)策略。