本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 中的管理政策 Amazon Organizations 管理策略 管理策略使您能够集中配置 Amazon Web Services 服务 和管理其功能。这些策略如何影响继承它们的 OUs 和账户取决于您应用的管理策略的类型 Amazon Organizations。查看此部分中的主题，了解有关管理策略的相关术语和概念。 **Topics** + [先决条件和权限](orgs_manage_policies_prereqs.md) + [了解策略继承](orgs_manage_policies_inheritance_mgmt.md) + [查看有效策略](orgs_manage_policies_effective.md) + [无效的策略警报](invalid-policy-alerts.md) + [ # 声明式策略 ](orgs_manage_policies_declarative.md) + [ # 备份策略 ](orgs_manage_policies_backup.md) + [ # 标签策略 ](orgs_manage_policies_tag-policies.md) + [ # 聊天应用程序政策 ](orgs_manage_policies_chatbot.md) + [ # AI 服务选择退出策略 ](orgs_manage_policies_ai-opt-out.md) + [ # Security Hub 策略 ](orgs_manage_policies_security_hub.md) + [ # 亚马逊 Bedrock 政策 ](orgs_manage_policies_bedrock.md) + [ # 亚马逊 Inspector 政策 ](orgs_manage_policies_inspector.md) + [ # 升级推出政策 ](orgs_manage_policies_upgrade_rollout.md) + [ # Amazon S3 策略 ](orgs_manage_policies_s3.md) + [ # Amazon Shield 网络安全总监政策 ](orgs_manage_policies_network_security_director.md) # 的管理策略的先决条件和权限 Amazon Organizations 先决条件和权限 本页介绍了 Amazon Organizations管理策略的先决条件和所需权限。 **Topics** + [ ## 管理策略的先决条件 ](#manage-policies-prereqs-overview) + [ ## 管理策略的权限 ](#manage-policies-permissions) ## 管理策略的先决条件 要使用组织的管理策略，需要满足以下条件： + 您的组织必须[已启用所有功能](orgs_manage_org_support-all-features.md)。 + 您必须登录到组织的管理账户或成为委派管理员。 + 您的 Amazon Identity and Access Management (IAM) 用户或角色必须拥有下一节中列出的权限。 ## 管理策略的权限 以下示例 IAM 策略提供了在组织中使用管理策略的各个方面所需的权限。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "OrganizationPolicies", "Effect": "Allow", "Action": [ "organizations:AttachPolicy", "organizations:CreatePolicy", "organizations:DeletePolicy", "organizations:DescribeAccount", "organizations:DescribeCreateAccountStatus", "organizations:DescribeEffectivePolicy", "organizations:DescribeOrganization", "organizations:DescribeOrganizationalUnit", "organizations:DescribePolicy", "organizations:DetachPolicy", "organizations:DisableAWSServiceAccess", "organizations:DisablePolicyType", "organizations:EnableAWSServiceAccess", "organizations:EnablePolicyType", "organizations:ListAccounts", "organizations:ListAccountsForParent", "organizations:ListAWSServiceAccessForOrganization", "organizations:ListCreateAccountStatus", "organizations:ListOrganizationalUnitsForParent", "organizations:ListParents", "organizations:ListPolicies", "organizations:ListPoliciesForTarget", "organizations:ListRoots", "organizations:ListTargetsForPolicy", "organizations:UpdatePolicy" ], "Resource": "*" } ] } ``` ------ 有关 IAM 策略与权限的更多一般信息，请参阅 [IAM 用户指南](https://docs.amazonaws.cn/IAM/latest/UserGuide/)。 # 了解管理策略继承 了解策略继承 **重要** 本节中的信息***不***适用于授权策略：服务控制策略 (SCPs) 和资源控制策略 (RCPs)。有关 Amazon Organizations 层次结构中的 RCPs 工作方式 SCPs 和运作方式的更多信息，请参阅[SCP 评估](orgs_manage_policies_scps_evaluation.md)和[RCP 评估](orgs_manage_policies_rcps_evaluation.md)。 您可以将某个管理策略附加到组织中的组织实体（组织根、组织部门 (OU) 或账户）： + 当您将管理策略附加到组织根目录时，组织中的所有 OUs 和账户都将继承该策略。 + 当您将某个管理策略附加到特定 OU 时，直接位于该 OU 下的账户或任何子 OU 都将继承该策略。 + 当您将某个管理策略附加到特定账户时，它仅影响该账户。 由于您可以将管理策略附加到组织中的多个级别，因此账户可以继承多个策略。 本主题介绍如何将父策略和子策略转换为账户的有效策略。 **Topics** + [术语](inheritance-terminology.md) + [管理策略类型](syntax-inheritance.md) + [ # 继承运算符 ](policy-operators.md) + [ # 继承示例 ](inheritance-examples.md) # 继承术语 术语 本主题在讨论管理策略继承时将使用以下术语。 **策略继承** 组织内不同级别的策略之间的交互，从组织的顶层根下移经过组织单位 (OU) 层次结构直到单个账户。 您可以将策略附加到组织根账户 OUs、个人账户以及这些组织实体的任意组合。策略继承是指附加到组织根或 OU 的管理策略。管理策略所附加到的组织根或 OU 的所有成员账户都将*继承*该策略。 例如，当管理策略附加到组织根时，组织中的所有账户都将继承该策略。这是因为组织中的所有账户始终位于组织根之下。当您将某个策略附加到特定 OU 时，直接位于该 OU 下的账户或任何子 OU 将继承该策略。由于您可以将策略附加到组织中的多个级别，因此账户可以继承单个策略类型的多个策略文档。 **父策略** 附加到组织树中的策略，其位置高于附加到树中较低位置实体的策略。 例如，如果您将管理策略 A 附加到组织根，则它只是一个策略。如果您还将策略 B 附加到根下的一个 OU，则策略 A 是策略 B 的父策略。策略 B 是策略 A 的子策略。策略 A 和策略 B 合并以便为该 OU 中的账户创建有效标签策略。 **子策略** 在组织树中附加的级别低于父策略的策略。 **有效策略** 最后，指定应用于账户的规则的单个策略文档。有效策略是账户继承的任何策略以及直接附加到账户的任何策略的聚合。有关更多信息，请参阅 [查看有效管理策略](orgs_manage_policies_effective.md)。 **继承运算符** 控制继承策略如何合并到单个有效策略中的运算符。这些运算符被视为是一项高级功能。经验丰富的策略作者可以使用它们来限制子策略可以进行的更改以及如何合并策略中的设置。有关更多信息，请参阅 [继承运算符](policy-operators.md)。 # 管理策略类型的策略语法和继承 管理策略类型 策略究竟如何影响 OUs 和继承它们的账户取决于您选择的管理策略类型。管理策略类型包括： + [声明式策略](orgs_manage_policies_declarative.md) + [备份策略](orgs_manage_policies_backup.md) + [标签策略](orgs_manage_policies_tag-policies.md) + [聊天应用程序政策](orgs_manage_policies_chatbot.md) + [AI 服务选择退出策略](orgs_manage_policies_ai-opt-out.md) + [Security Hub 政策](orgs_manage_policies_security_hub.md) + [基岩政策](orgs_manage_policies_bedrock.md) + [Inspector政策](orgs_manage_policies_inspector.md) + [升级推出政策](orgs_manage_policies_upgrade_rollout.md) + [S3 策略](orgs_manage_policies_s3.md) + [Amazon Shield 网络安全总监政策](orgs_manage_policies_network_security_director.md) 管理策略类型的语法包括 *[继承运算符](policy-operators.md)*，这使您可以精细地指定应用父策略中的哪些元素，以及子策略和账户继承时可以覆盖或修改哪些元素。 OUs *有效的策略*是从组织根目录继承的一组规则， OUs 以及直接关联到账户的规则。有效策略指定适用于账户的最终规则集。您可以查看账户的有效策略，其中包含所应用策略中所有继承运算符的效果。有关更多信息，请参阅 [查看有效管理策略](orgs_manage_policies_effective.md)。 # 继承运算符 继承运算符控制继承的策略和账户策略如何合并到账户的有效策略中。这些运算符包括值设置运算符和子控制运算符。 在 Amazon Organizations 控制台中使用可视化编辑器时，只能使用`@@assign`操作员。其他运算符被视为高级功能。要使用其他运算符，您必须手动编写 JSON 策略。经验丰富的策略作者可以使用继承运算符来控制应用于有效策略的值，并限制子策略可以进行的更改。 有关策略继承在组织中工作原理的信息，请参阅[继承示例](inheritance-examples.md)。 ## 值设置运算符 您可以使用以下值设置运算符来控制策略与其父策略交互的方式： + `@@assign` – 用指定设置**覆盖**任何继承的策略设置。如果未继承指定的设置，则此运算符会将该设置添加到有效策略中。此运算符可以应用于任何类型的任何策略设置。 + 对于单值设置，此运算符将继承的值替换为指定值。 + 对于多值设置（JSON 数组），此运算符将删除所有继承的值，并将其替换为此策略指定的值。 + `@@append` – 向继承的设置**添加**指定的设置（而不删除任何设置）。如果未继承指定的设置，则此运算符会将该设置添加到有效策略中。只能将此运算符用于多值设置。 + 此运算符将指定的值添加到继承数组中的任何值。 + `@@remove` – 从有效策略中**删除**指定的继承设置（如果存在）。只能将此运算符用于多值设置。 + 此运算符仅从继承自父策略的值数组中删除指定值。其他值可以继续存在于数组中，并且可由子策略继承。 ## 子控制运算符 使用子控制运算符是可选的。您可以使用 `@@operators_allowed_for_child_policies` 运算符控制子策略可以使用哪些值设置运算符。您可以允许所有运算符、一些特定运算符或不允许运算符。默认情况下，允许所有运算符 (`@@all`)。 + `"@@operators_allowed_for_child_policies"`: `["@@all"]` — 儿童 OUs 和账户可以在政策中使用任何运算符。默认情况下，子策略中允许使用所有运算符。 + `"@@operators_allowed_for_child_policies"`: `["@@assign", "@@append", "@@remove"]` — 子账号 OUs 和账户只能使用子政策中的指定运算符。您可以在此子控制运算符中指定一个或多个值设置运算符。 + `"@@operators_allowed_for_child_policies"`: `["@@none"]` — 儿童 OUs 和账户不能在策略中使用运算符。可以使用此运算符有效锁定在父策略中定义的值，以使子策略无法添加、追加或删除这些值。 **注意** 如果继承的子控制运算符限制使用某个运算符，您无法在子策略中反转该规则。如果您在父策略中包括子控制运算符，则它们会在所有子策略中限制值设置运算符。 # 继承示例 这些示例通过演示如何将父标签策略和子标签策略合并到某个账户的有效标签策略，来说明策略继承的工作原理。 这些示例假定您具有下图所示的组织结构。 ![\[一个拥有一个根账户 OUs、两个账户和多个账户的组织。\]](http://docs.amazonaws.cn/organizations/latest/userguide/images/org-structure-inheritance.png) **Topics** + [ ## 示例 1：允许子策略*仅* 覆盖标签值 ](#example-assign-operator) + [ ## 示例 2：将新值附加到继承的标签 ](#example-append-operator) + [ ## 示例 3：从继承标签中删除值 ](#example-remove-operator) + [ ## 示例 4：限制对子策略的更改 ](#example-restrict-child) + [ ## 示例 5：与子控制运算符的冲突 ](#multiple-same-node-operators) + [ ## 示例 6：在相同层次结构级别附加值的冲突 ](#multiple-same-node-values) ## 示例 1：允许子策略*仅* 覆盖标签值 以下标签策略定义了 `CostCenter` 标签键和可接受的值，即 `Development` 和 `Support`。如果您将其附加到组织根，则标签策略对组织中的所有账户都有效。 **策略 A – 组织根标签策略** ``` { "tags": { "costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@assign": [ "Development", "Support" ] } } } } ``` 假设您希望用户 OU1 对密钥使用不同的标签值，并且您想对特定资源类型强制执行标签策略。由于策略 A 没有指定允许使用哪些子控制运算符，因此允许所有运算符。您可以使用`@@assign`运算符并创建如下所示的标签策略以附加到 OU1。 **策略 B — OU1 标签策略** ``` { "tags": { "costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@assign": [ "Sandbox" ] }, "enforced_for": { "@@assign": [ "redshift:*", "dynamodb:table" ] } } } } ``` 在策略 A 和策略 B 合并以形成账户的*有效标签策略*时，为标签指定 `@@assign` 运算符会执行以下操作： + 策略 B 覆盖在父策略（即策略 A）中指定的两个标签值。最终，`Sandbox` 成为了 `CostCenter` 标签键唯一的合规值。 + 添加 `enforced_for` 以指定 `CostCenter` 标签*必须*是所有 Amazon Redshift 资源和 Amazon DynamoDB 表上的指定标签值。 如图所示， OU1 包括两个账户：111111111111和222222222222。 **产生的账户 111111111111 和 222222222222 的有效标签策略** **注意** 您不能直接将显示的有效策略的内容用作新策略的内容。语法不包括控制与其他子策略和父策略合并所需的运算符。展示的有效政策只是为了了解合并的结果。 ``` { "tags": { "costcenter": { "tag_key": "CostCenter", "tag_value": [ "Sandbox" ], "enforced_for": [ "redshift:*", "dynamodb:table" ] } } } ``` ## 示例 2：将新值附加到继承的标签 在某些情况下，您可能希望为组织中的所有账户指定一个标签键以及可接受值的短列表。对于一个 OU 中的账户，您可能希望允许只有这些账户在创建资源时才能指定的其他值。此示例指定如何使用 `@@append` 运算符来执行此操作。`@@append` 运算符是一个高级功能。 与示例 1 类似，此示例从用于组织根标签策略的策略 A 开始。 **策略 A – 组织根标签策略** ``` { "tags": { "costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@assign": [ "Development", "Support" ] } } } } ``` 在本示例中，将策略 C 附加到 OU2。此示例的区别在于，在策略 C 中使用 `@@append` 运算符会*添加* 而不是覆盖可接受值和 `enforced_for` 规则的列表。 **策略 C — 用于附加值的 OU2 标签策略** ``` { "tags": { "costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@append": [ "Marketing" ] }, "enforced_for": { "@@append": [ "redshift:*", "dynamodb:table" ] } } } } ``` 当策略 A 和策略 C 合并形成账户的有效标签策略时，将策略 C 附加到会产生以下影响： OU2 + 由于策略 C 包含 `@@append` 运算符，它允许*添加* 而不是覆盖在策略 A 中指定的可接受标签值列表。 + 与在策略 B 中一样，添加 `enforced_for` 以指定 `CostCenter` 标签必须用作所有 Amazon Redshift 资源和 Amazon DynamoDB 表上的指定标签值。如果父策略不包含限制子策略可指定值的子控制运算符，则覆盖 (`@@assign`) 和添加 (`@@append`) 具有相同的效果。 如图所示， OU2 包括一个账户：999999999999。策略 A 和策略 C 合并以便为账户 999999999999 创建有效标签策略。 **适用于账户 999999999999 的有效标签策略** **注意** 您不能直接将显示的有效策略的内容用作新策略的内容。语法不包括控制与其他子策略和父策略合并所需的运算符。展示的有效政策只是为了了解合并的结果。 ``` { "tags": { "costcenter": { "tag_key": "CostCenter", "tag_value": [ "Development", "Support", "Marketing" ], "enforced_for": [ "redshift:*", "dynamodb:table" ] } } } ``` ## 示例 3：从继承标签中删除值 在某些情况下，附加到组织的标签策略定义的标签值数量多于您希望账户使用的数量。此示例说明如何使用 `@@remove` 运算符修改标签策略。`@@remove` 是一项高级功能。 与其他示例类似，此示例从用于组织根标签策略的策略 A 开始。 **策略 A – 组织根标签策略** ``` { "tags": { "costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@assign": [ "Development", "Support" ] } } } } ``` 对于此示例，将策略 D 附加到账户 999999999999。 **策略 D – 账户 999999999999 标签策略，用于删除值** ``` { "tags": { "costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@remove": [ "Development", "Marketing" ], "enforced_for": { "@@remove": [ "redshift:*", "dynamodb:table" ] } } } } } ``` 当策略 A、策略 C 和策略 D 合并以形成有效标签策略时，将策略 D 附加到账户 999999999999 具有以下效果： + 假设您执行了前面的所有示例，那么策略 B、C 和 C 是 A 的子政策。策略 B 仅附加到 OU1，因此它对账户 9999999999999 没有影响。 + 对于账户 9999999999999，`CostCenter` 标签键的唯一可接受值是 `Support`。 + 不对 `CostCenter` 标签键强制执行合规性。 **适用于账户 999999999999 的新有效标签策略** **注意** 您不能直接将显示的有效策略的内容用作新策略的内容。语法不包括控制与其他子策略和父策略合并所需的运算符。展示的有效政策只是为了了解合并的结果。 ``` { "tags": { "costcenter": { "tag_key": "CostCenter", "tag_value": [ "Support" ] } } } ``` 如果您稍后向其中添加更多账户 OU2，则其有效标签策略将与账户 999999999999 的有效标签策略不同。这是因为限制性更强的策略 D 仅在账户级别附加，而不附加到 OU。 ## 示例 4：限制对子策略的更改 在某些情况下，您可能希望限制子策略中的更改。此示例说明如何使用子控制运算符来执行此操作。 此示例从新的组织根标签策略开始，并假定标签策略尚未附加到组织实体。 **策略 E – 用于限制子策略中的更改的组织根标签策略** ``` { "tags": { "project": { "tag_key": { "@@operators_allowed_for_child_policies": ["@@none"], "@@assign": "Project" }, "tag_value": { "@@operators_allowed_for_child_policies": ["@@append"], "@@assign": [ "Maintenance", "Escalations" ] } } } } ``` 将策略 E 附加到组织根时，该策略会阻止子策略更改 `Project` 标签键。但是，子策略可以覆盖或附加标签值。 假定您随后将以下策略 F 附加到 OU。 **策略 F – OU 标签策略** ``` { "tags": { "project": { "tag_key": { "@@assign": "PROJECT" }, "tag_value": { "@@append": [ "Escalations - research" ] } } } } ``` 合并策略 E 和策略 F 会对 OU 的账户产生以下效果： + 策略 F 是策略 E 的子策略。 + 策略 F 尝试更改案例处理，但无法完成。这是因为策略 E 为标签键包含了 `"@@operators_allowed_for_child_policies": ["@@none"]` 运算符。 + 但是，策略 F 可以为键附加标签值。这是因为策略 E 为标签值包含了 `"@@operators_allowed_for_child_policies": ["@@append"]`。 **OU 中账户的有效策略** **注意** 您不能直接将显示的有效策略的内容用作新策略的内容。语法不包括控制与其他子策略和父策略合并所需的运算符。展示的有效政策只是为了了解合并的结果。 ``` { "tags": { "project": { "tag_key": "Project", "tag_value": [ "Maintenance", "Escalations", "Escalations - research" ] } } } ``` ## 示例 5：与子控制运算符的冲突 附加到组织层次结构中同一级别的标签策略中可以存在子控制运算符。发生这种情况时，在合并策略以形成账户的有效策略时，使用允许运算符的交集。 假定策略 G 和策略 H 附加到组织根。 **策略 G – 组织根标签策略 1** ``` { "tags": { "project": { "tag_value": { "@@operators_allowed_for_child_policies": ["@@append"], "@@assign": [ "Maintenance" ] } } } } ``` **策略 H – 组织根标签策略 2** ``` { "tags": { "project": { "tag_value": { "@@operators_allowed_for_child_policies": ["@@append", "@@remove"] } } } } ``` 在此示例中，位于组织根的一个策略定义只能附加标签键的值。附加到组织根的另一个策略允许子策略附加和删除值。为子策略使用这两个权限的交集。结果是子策略可以附加值，但不能删除值。因此，子策略可以将值附加到标签值的列表，但不能删除 `Maintenance` 值。 ## 示例 6：在相同层次结构级别附加值的冲突 您可以将多个标签策略附加到每个组织实体。执行此操作时，附加到同一组织实体的标签策略可能包含冲突的信息。将按照这些策略附加到组织实体的顺序来评估这些策略。要更改首先评估哪个策略，您可以分离策略，然后重新附加策略。 假定策略 J 第一个附加到组织根，然后将策略 K 附加到组织根。 **策略 J – 附加到组织根的第一个标签策略** ``` { "tags": { "project": { "tag_key": { "@@assign": "PROJECT" }, "tag_value": { "@@append": ["Maintenance"] } } } } ``` **策略 K – 附加到组织根的第二个标签策略** ``` { "tags": { "project": { "tag_key": { "@@assign": "project" } } } } ``` 在此示例中，标签键 `PROJECT` 在有效标签策略中使用，因为定义它的策略首先附加到组织根。 **策略 JK – 账户的有效标签策略** 账户的有效策略如下。 **注意** 您不能直接将显示的有效策略的内容用作新策略的内容。语法不包括控制与其他子策略和父策略合并所需的运算符。展示的有效政策只是为了了解合并的结果。 ``` { "tags": { "project": { "tag_key": "PROJECT", "tag_value": [ "Maintenance" ] } } } ``` # 查看有效管理策略 查看有效策略 确定组织中任何账户的有效管理策略。 ## 什么是有效管理策略？ >什么是有效策略？ *有效策略*用于指定对于某个管理策略类型，适用于 Amazon Web Services 账户 的最终规则。这是账户所继承的管理策略，加上直接附加到该账户的任何该管理策略类型的策略的聚合。将管理策略附加到组织根时，该策略将适用于组织中的所有账户。当您将管理策略附加到组织单位 (OU) 时，它适用于属于 OUs 该组织单位的所有账户。当您将管理策略直接附加到账户时，它仅适用于该账户 Amazon Web Services 账户。 有关如何将策略组合到最终有效策略中的信息，请参阅[了解管理策略继承](orgs_manage_policies_inheritance_mgmt.md)。 **备份策略示例** 附加到组织根的备份策略可能指定组织中的所有账户以每周一次的默认备份频率备份所有 Amazon DynamoDB 表。直接附加到一个成员账户的单独备份策略（在表中包含关键信息）可以用每天一次的值覆盖该频率。这些备份策略的组合构成有效备份策略。该有效备份策略是为组织中的每个账户单独确定的。此示例中的结果是，组织中的所有账户每周备份一次自己的 DynamoDB 表，但有一个账户每天备份它的表。 **标签策略示例** 附加到组织根的标签策略可以定义具有四个合规值的 `CostCenter` 标签。附加到账户的单独标签策略可能会将 `CostCenter` 限制为四个合规值中的两个。这些标签策略的组合组成了有效标签策略。结果是，在组织根标签策略中定义的四个合规标签值中，只有两个符合该账户的要求。 **聊天应用程序政策示例** 聊天应用程序中的 Amazon Q 开发者版将根据有效的聊天应用程序政策，重新评估聊天应用程序中任何先前创建的 Amazon Q 开发者版配置，如果这些配置与有效策略中允许的设置和护栏一致，则会拒绝所有先前允许的操作。成员账户的有效策略定义了允许的设置和护栏。例如，假设将某个会拒绝访问公有 Slack 频道的聊天应用程序政策应用于成员账户，则该成员账户中公有 Slack 频道的现有聊天应用程序中的 Amazon Q 开发者版配置将被禁用。聊天应用程序中的 Amazon Q 开发者版不会发送通知，频道成员也无法在被阻止的频道中运行任何任务。聊天应用程序中的 Amazon Q 开发者版控制台会将受影响的频道标记为已禁用，并在其旁边显示相应的错误消息。 **AI 服务选择退出策略示例** 附加到组织根目录的 AI 服务选择退出政策可能会规定组织中的所有账户都选择不允许所有 Amazon 机器学习服务使用内容。直接附加到一个成员账户的单独 AI 服务选择退出策略指定它只为 Amazon Rekognition 选择启用内容使用服务。这些 AI 服务选择退出策略的组合构成了有效的 AI 服务选择退出策略。结果是，除了一个选择加入 Amazon Rekognition 的账户外，组织中的所有 Amazon Web Services 服务账户都选择退出所有账户。 ## 如何查看有效管理策略 如何查看有效策略 您可以通过 Amazon Web Services 管理控制台、 Amazon API 或查看账户管理策略类型的有效策略 Amazon Command Line Interface。 **最小权限** 要查看账户的管理策略类型的有效策略，您必须要有运行以下操作的权限： `organizations:DescribeEffectivePolicy` `organizations:DescribeOrganization` – 仅当使用 Organizations 控制台时才需要 ------ #### [ Amazon Web Services 管理控制台 ] **查看账户的管理策略类型的有效策略** 1. 登录 [Amazon Organizations 控制台](https://console.amazonaws.cn/organizations/v2)。您必须以 IAM 用户的身份登录，担任 IAM 角色；或在组织的管理账户中以根用户的身份登录（[不推荐](https://docs.amazonaws.cn/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)）。 1. 在 **[Amazon Web Services 账户](https://console.amazonaws.cn/organizations/v2/home/accounts)**页面上，选择要查看其有效策略的账户的名称。您可能需要展开 OUs （选择![\[Gray cloud icon representing cloud computing or storage services.\]](http://docs.amazonaws.cn/organizations/latest/userguide/images/console-expand.png)）才能找到所需的帐户。 1. 在**策略**选项卡上，选择要查看其有效策略的管理策略类型。 1. 选择**查看此 Amazon Web Services 账户的有效策略**。 控制台显示应用于指定账户的有效策略。 **注意** 您无法复制和粘贴有效策略，并在不进行重大更改的情况下将其用作其他策略的 JSON。策略文档必须包含[继承运算符](policy-operators.md)，用来指定如何将每个设置合并到最终的有效策略中。 ------ #### [ Amazon CLI & Amazon SDKs ] **查看账户的管理策略类型的有效策略** 您可以使用以下方法之一查看有效策略： + Amazon CLI: [describe-effective-policy](https://docs.amazonaws.cn/cli/latest/reference/organizations/describe-effective-policy.html) 以下示例显示了账户的有效 AI 服务选择退出策略。 ``` $ aws organizations describe-effective-policy \ --policy-type AISERVICES_OPT_OUT_POLICY \ --target-id 123456789012 { "EffectivePolicy": { "PolicyContent": "{\"services\":{\"comprehend\":{\"opt_out_policy\":\"optOut\"}, ....TRUNCATED FOR BREVITY.... "opt_out_policy\":\"optIn\"}}}", "LastUpdatedTimestamp": "2020-12-09T12:58:53.548000-08:00", "TargetId": "123456789012", "PolicyType": "AISERVICES_OPT_OUT_POLICY" } } ``` + Amazon SDKs: [DescribeEffectivePolicy](https://docs.amazonaws.cn/organizations/latest/APIReference/API_DescribeEffectivePolicy.html) ------ 有关有效策略可能失效的情况的信息，请参阅[查看无效策略警报](https://docs.amazonaws.cn//organizations/latest/userguide/invalid-policy-alerts.html)。 # 关于无效的有效策略警报 无效的策略警报 *无效的策略警报*会让您知道无效的有效策略，并提供机制 (APIs) 来识别具有无效策略的账户。 Amazon Organizations 当您的一个账户的有效策略无效时，会异步通知您。通知以横幅形式显示在 Amazon Organizations 控制台页面中，并记录为 Amazon CloudTrail 事件。 ## 检测组织中无效的有效管理策略 您可以通过多种方式查看组织中无效的有效管理策略：从 Amazon 管理控制台、 Amazon API、 Amazon 命令行界面 (CLI) 或以 Amazon CloudTrail 事件的形式查看。 **最小权限** 要查找组织中与管理策略类型无效的有效策略相关的信息，您必须具有执行以下操作的权限： `organizations:ListAccountsWithInvalidEffectivePolicy` `organizations:ListEffectivePolicyValidationErrors` `organizations:ListRoots`：仅当使用 Organizations 控制台时才需要 ------ #### [ Amazon Web Services 管理控制台 ] **从控制台查看无效的有效管理策略** 1. 登录 [Amazon Organizations 控制台](https://console.amazonaws.cn/organizations/v2)。您必须以 IAM 用户的身份登录，担任 IAM 角色；或在组织的管理账户中以根用户的身份登录（[不推荐](https://docs.amazonaws.cn/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)）。 1. 在 **[Amazon Web Services 账户](https://console.amazonaws.cn/organizations/v2/home/accounts)** 页面上，如果组织有无效的有效策略，则会在页面顶部显示警告横幅。 1. 在横幅中，点击**查看检测到的问题**，可查看组织中具有无效的有效策略的所有账户的列表。 1. 对于列表中的每个账户，选择**查看问题**，获取有关本页**有效策略问题**部分下显示的每个账户错误的更多信息。 ------ #### [ Amazon CLI & Amazon SDKs ] **查看账户的管理策略类型的有效策略** 以下命令可帮助您查看具有无效的有效策略的账户 + Amazon CLI: [list-accounts-with-invalid-有效政策](https://docs.amazonaws.cn/cli/latest/reference/organizations/list-accounts-with-invalid-effective-policy.html) + Amazon SDKs: [ListAccountsWithInvalidEffectivePolicy](https://docs.amazonaws.cn/organizations/latest/APIReference/API_ListAccountsWithInvalidEffectivePolicy.html) **以下命令可帮助您查看有关账户的有效策略错误** + Amazon CLI: [list-effective-policy-validation-错误](https://docs.amazonaws.cn/cli/latest/reference/organizations/list-effective-policy-validation-errors.html) + Amazon SDKs: [ListEffectivePolicyValidationErrors](https://docs.amazonaws.cn/organizations/latest/APIReference/API_ListEffectivePolicyValidationErrors.html) ------ **Amazon CloudTrail** 您可以使用 Amazon CloudTrail 事件来监控组织中的账户何时有无效的有效管理策略以及策略何时修复。有关更多信息，请参阅[了解 Amazon Organizations 日志文件条目](https://docs.amazonaws.cn//organizations/latest/userguide/orgs_cloudtrail-integration.html#understanding-service-name-entries)中的*有效策略示例*。 如果您收到无效的有效策略通知，则可以浏览 Amazon Organizations 控制台或 APIs 从您的管理或委托管理员账户拨打控制台，以了解有关特定账户和策略状态的更多详细信息： + `ListAccountsWithInvalidEffectivePolicy`：返回组织中具有指定类型无效的有效策略的账户列表。 + `ListEffectivePolicyValidationErrors`：返回指定账户和管理策略类型的验证错误列表。验证错误包含详细信息，包括导致有效策略无效的错误代码、错误描述和贡献策略。 ## 何时可认为有效管理策略无效 如果账户的有效策略违反了为特定策略类型定义的限制，则这些策略可能会失效。例如，某个策略可能在最终有效策略中缺少所需参数，或者超过了为该策略类型定义的特定配额。 **备份策略示例** 假设您创建了一个包含九条备份规则的备份策略，并将其附加到组织的根目录。稍后，您为同一个备份计划创建了另一个备份策略（有两条额外规则），然后将其附加到组织中的任何账户。在这种情况下，该账户具有无效的有效策略。该策略之所以无效，是因为这两个策略的聚合为备份计划定义了 11 条规则。一个计划中的备份规则数量限制为 10 条。 **警告** 如果组织中的任何账户具有无效的有效策略，则该账户将无法收到针对特定策略类型的有效政策更新。除非所有错误都已修复，否则它将继续使用该账户上次应用的有效的有效策略。 **有效策略可能出现的错误示例** + `ELEMENTS_TOO_MANY`：当有效策略中的特定属性超过允许的限制时发生，例如为备份计划提供的规则超过 10 条时。 + `ELEMENTS_TOO_FEW`：当有效策略中的特定属性未达到最低限制时发生，例如没有为备份计划定义区域时。 + `KEY_REQUIRED`：当有效策略中缺少所需配置时发生，例如备份计划缺少备份规则时。 Amazon Organizations 在将有效策略应用于组织中的账户之前，先对其进行验证。如果您的组织结构庞大，并且组织的策略由多个团队管理，则此审计过程尤其有用。 # 声明式策略 声明式策略允许您在整个组织中大规模地集中声明和强制执行所需的配置。 Amazon Web Services 服务 连接后，当服务添加新功能或时，配置将始终保持不变 APIs。使用声明性策略来防止不合规操作。例如，您可以屏蔽整个组织中对 Amazon VPC 资源的公共互联网访问权限。 使用声明性策略的主要优势在于： + **易用性**：您可以通过 Amazon Organizations 和 Amazon Control Tower 控制台中的几个选项或使用 Amazon CLI & 使用几个命令来强制执行基本配置 Amazon SDKs。 Amazon Web Services 服务 + **设置一次就算了**：的基准配置始终保持 Amazon Web Services 服务 不变，即使服务引入了新功能或 APIs。当向组织添加新账户或创建新的主体和资源时，也会保持基准配置。 + **透明度**：账户状态报告允许您查看范围内账户的声明性策略支持的所有属性的当前状态。您还可以创建可自定义的错误消息，这可以帮助管理员将终端用户重定向到内部 Wiki 页面，或者提供描述性消息，帮助终端用户了解操作失败的原因。 有关支持的属 Amazon Web Services 服务 性和属性的完整列表，请参阅[支持 Amazon Web Services 服务 和属性](#orgs_manage_policies_declarative-supported-controls)。 **Topics** + [ ## 声明性策略的工作原理 ](#orgs_manage_policies_declarative-how-work) + [自定义错误消息](#orgs_manage_policies_declarative-custom-message) + [账户状态报告](#orgs_manage_policies_declarative-account-status-report) + [受支持的服务](#orgs_manage_policies_declarative-supported-controls) + [开始使用](orgs_manage_policies-declarative_getting-started.md) + [最佳实践](orgs_manage_policies_declarative_best-practices.md) + [生成账户状态报告](orgs_manage_policies_declarative_status-report.md) + [ # 声明性策略语法和示例 ](orgs_manage_policies_declarative_syntax.md) ## 声明性策略的工作原理 声明式策略是在服务的控制平面中强制执行的，这与[诸如服务控制策略 (SCPs) 和资源控制策略 () 之类的授权策略](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_authorization_policies.html)有重要区别。RCPs虽然授权策略规范访问权限 APIs，但声明性策略直接应用于服务级别，以强制执行持久意图。这样可以确保始终强制执行基准配置，即使服务引入了新功能或新功能 APIs 也是如此。 下表有助于说明这种区别，表中还提供了一些使用案例。 **** | | 服务控制策略 | 资源控制策略 | 声明式策略 | | --- | --- | --- | --- | | 为什么？ | 集中定义并大规模强制执行对主体（例如 IAM 用户和 IAM 角色）的一致访问控制。 | 集中定义并大规模强制执行对资源的一致访问控制 | 集中定义并大规模强制执行 Amazon 服务的基准配置。 | | 操作方法 | 在 API 级别控制主体的最大可用访问权限。 | 在 API 级别控制资源的最大可用访问权限。 | 通过在 Amazon Web Services 服务 不使用 API 操作的情况下强制执行所需的配置。 | | 是否管理服务关联角色？ | 否 | 否 | 是 | | 反馈机制 | 不可自定义的访问被拒绝的 SCP 错误。 | 不可自定义的访问被拒绝的 RCP 错误。 | 可自定义的错误消息。有关更多信息，请参阅 [声明性策略的自定义错误消息](#orgs_manage_policies_declarative-custom-message)。 | | 策略示例 | [拒绝成员账户退出组织](https://github.com/aws-samples/service-control-policy-examples/blob/main/Privileged-access-controls/Deny-member-accounts-from-leaving-your-AWS-organization.json) | [限制仅通过 HTTPS 连接访问您的资源](https://github.com/aws-samples/resource-control-policy-examples/blob/main/Restrict-resource-access-patterns/Restrict-access-to-only-HTTPS-connections-to-your-resources.json) | [允许的映像设置](orgs_manage_policies_declarative_syntax.md#declarative-policy-ec2-ami-allowed-images) | 在您[创建](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_policies_create.html#create-declarative-policy-procedure)并[附加](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_policies_attach.html)声明性策略后，将在整个组织中应用和强制执行该策略。声明式策略可以应用于整个组织、组织单位 (OUs) 或帐户。加入组织的账户将自动继承组织中的声明性策略。有关更多信息，请参阅 [了解管理策略继承](orgs_manage_policies_inheritance_mgmt.md)。 *有效的策略*是从组织根目录继承的一组规则， OUs 以及直接关联到账户的规则。有效策略指定适用于账户的最终规则集。有关更多信息，请参阅 [查看有效管理策略](orgs_manage_policies_effective.md)。 如果[分离](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_policies_detach.html)了声明性策略，则属性状态将回滚到附加该声明性策略之前的状态。 ## 声明性策略的自定义错误消息 自定义错误消息 声明性策略允许您创建自定义错误消息。例如，如果由于声明性策略而导致 API 操作失败，则可以设置错误消息或提供自定义 URL，例如指向内部 Wiki 的链接或描述该失败的消息的链接。如果您未指定自定义错误消息，则会 Amazon Organizations 提供以下默认错误消息：`Example: This action is denied due to an organizational policy in effect`。 您还可以使用审核创建声明性策略、更新声明性策略和删除声明性策略的过程。 Amazon CloudTrail CloudTrail 可以标记由于声明式策略而导致的 API 操作失败。有关更多信息，请参阅[日志记录和监控](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_security_incident-response.html)。 **重要** 请勿在自定义错误消息中包含*个人身份信息（PII）*或其他敏感信息。PII 包括可用于识别或定位个人的一般信息，涵盖财务、医疗、教育或就业等记录。PII 示例包括地址、银行账号和电话号码。 ## 声明性策略的账户状态报告 账户状态报告 *账户状态报告*允许您查看范围内账户的声明性策略支持的所有属性的当前状态。您可以选择要包含在报告范围内的账户和组织单位 (OUs)，也可以通过选择根目录来选择整个组织。 此报告提供区域细分来帮助您评估就绪情况，并评测属性的当前状态是*跨账户统一*（通过 `numberOfMatchedAccounts`）还是*不一致*（通过 `numberOfUnmatchedAccounts`）。您还可以看到*最常见值*，即该属性中最常观察到的配置值。 图 1 中生成了一份账户状态报告，其中显示了以下属性的账户间一致性：VPC 屏蔽公共访问权限和映像屏蔽公共访问权限。这意味着，对于每个属性，范围内的所有账户对该属性的配置都相同。 生成的账户状态报告显示了以下属性的不一致账户：允许的映像设置、实例元数据默认值、Serial Console 访问权限和快照屏蔽公共访问权限。在此示例中，不一致账户的每个属性都是因为存在一个账户具有不同的配置值。 如果存在最常见值，则会显示在相应的列中。有关每个属性所控制内容的更多详细信息，请参阅[声明性策略语法和示例策略](orgs_manage_policies_declarative_syntax.md)。 您也可以展开属性查看区域明细。在此示例中，展开了“映像屏蔽公共访问权限”项，在每个区域中，您都可以看到具备账户间的统一性。 是否选择附加声明性策略来强制执行基准配置，取决于具体的使用案例。在附加声明性策略之前，使用账户状态报告来帮助评测就绪情况。 有关更多信息，请参阅[生成账户状态报告](orgs_manage_policies_declarative_status-report.md)。 ![\[VPC 屏蔽公共访问权限和映像屏蔽公共访问权限具备跨账户一致性的示例账户状态报告\]](http://docs.amazonaws.cn/organizations/latest/userguide/images/declarative-status-report.png) *图 1：VPC 屏蔽公共访问权限和映像屏蔽公共访问权限具备跨账户一致性的示例账户状态报告。* ## 支持 Amazon Web Services 服务 和属性 受支持的服务 ### EC2 的声明性策略支持的属性 下表显示了 Amazon EC2 相关服务支持的属性。 **EC2 的声明性策略** [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_declarative.html) # 声明性策略入门 开始使用 请按照以下步骤开始使用声明性策略。 1. [了解执行声明性策略任务所必须具备的权限](orgs_manage_policies_prereqs.md)。 1. [为您的组织启用声明性策略](enable-policy-type.md)。 **注意** **需要启用信任访问权限** 您必须为声明性策略将在其中强制执行基准配置的服务，启用可信访问权限。这将创建一个只读的服务关联角色，用于生成组织内账户现有配置的账户状态报告。 **使用控制台** 如果您使用 Organizations 控制台，则此步骤属于启用声明性策略过程的一部分。 **使用 Amazon CLI** 如果您使用 Amazon CLI，则有两个分开的 APIs： [EnablePolicyType](https://docs.amazonaws.cn/organizations/latest/APIReference/API_EnablePolicyType.html)，您可以使用它来启用声明式策略。 [启用AWSService访问权限](https://docs.amazonaws.cn/organizations/latest/APIReference/API_EnableAWSServiceAccess.html)，用于启用可信访问。 有关如何为特定服务启用可信访问权限的更多信息， Amazon CLI 请参阅 [Amazon Web Services 服务 ，您可以与一起使用 Amazon Organizations](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_integrate_services_list.html)。 1. [运行账户状态报告](orgs_manage_policies_declarative_status-report.md)。 1. [创建声明性策略](orgs_policies_create.md)。 1. [将声明性策略附加到组织的根、OU 或账户](orgs_policies_attach.md)。 1. [查看应用于账户的合并有效声明性策略](orgs_manage_policies_effective.md)。 对于上述所有步骤，您必须以 IAM 用户的身份登录，担任 IAM 角色，或在组织的管理账户中以根用户的身份登录（[不推荐](https://docs.amazonaws.cn/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)）。 **其他信息** + [了解声明性策略语法并查看示例策略](orgs_manage_policies_declarative_syntax.md) # 使用声明性策略的最佳实践 最佳实践 Amazon 推荐使用声明式策略的以下最佳实践。 ## 利用就绪情况评测 使用声明性策略*账户状态报告*，来评估范围内账户的声明性策略支持的所有属性的当前状态。您可以选择要包含在报告范围内的账户和组织单位 (OUs)，也可以通过选择根目录来选择整个组织。 此报告提供区域细分来帮助您评估就绪情况，并评测属性的当前状态是*跨账户统一*（通过 `numberOfMatchedAccounts`）还是*不一致*（通过 `numberOfUnmatchedAccounts`）。您还可以看到*最常见值*，即该属性中最常观察到的配置值。 是否选择附加声明性策略来强制执行基准配置，取决于具体的使用案例。 有关更多信息以及说明性示例，请参阅[声明性策略的账户状态报告](orgs_manage_policies_declarative.md#orgs_manage_policies_declarative-account-status-report)。 ## 从小处着手，然后逐步扩展 要简化调试，请从测试策略开始。在进行下一个更改之前，验证每个更改的行为和影响。此方法可以减少出现错误或意外结果时必须考虑的变量数量。 例如，您可以从非关键测试环境中附加到单个账户的测试策略开始。在确认该政策符合您的规格后，您可以逐步将该策略在组织结构中向上移动到更多账户和更多组织单位（OUs）。 ## 建立审查流程 实施相关流程，以监控新的声明性属性、评估策略例外情况并进行调整，以确保符合组织的安全性和操作要求。 ## 使用 `DescribeEffectivePolicy` 验证更改 更改声明性策略后，请检查低于您更改级别的代表账户的有效策略。您可以[通过使用 Amazon Web Services 管理控制台、或使用 [DescribeEffectivePolicy](https://docs.amazonaws.cn/organizations/latest/APIReference/API_DescribeEffectivePolicy.html)API 操作或其变体 Amazon CLI 或 Amazon SDK 变体之一来查看有效的策略](orgs_manage_policies_effective.md)。确保您所做的更改对有效策略产生预期影响。 ## 沟通与培训 确保您的组织了解声明性策略的目的和影响。就预期行为以及如何处理因执行策略而导致的失败提供明确的指导。 # 生成声明性策略的账户状态报告 生成账户状态报告 *账户状态报告*允许您查看范围内账户的声明性策略支持的所有属性的当前状态。您可以选择要包含在报告范围内的账户和组织单位 (OUs)，也可以通过选择根目录来选择整个组织。 此报告提供区域细分来帮助您评估就绪情况，并评测属性的当前状态是*跨账户统一*（通过 `numberOfMatchedAccounts`）还是*不一致*（通过 `numberOfUnmatchedAccounts`）。您还可以看到*最常见值*，即该属性中最常观察到的配置值。 是否选择附加声明性策略来强制执行基准配置，取决于具体的使用案例。 有关更多信息以及说明性示例，请参阅[声明性策略的账户状态报告](orgs_manage_policies_declarative.md#orgs_manage_policies_declarative-account-status-report)。 ## 先决条件 在生成账户状态报告前，必须先执行下列步骤 1. 只有组织的管理账户或委派管理员才能调用 `StartDeclarativePoliciesReport` API。 1. 您必须拥有 S3 存储桶才能生成报告（创建新存储桶或使用现有存储桶），该存储桶必须位于发出请求的同一区域中，并且必须具有相应的 S3 存储桶策略。有关示例 S3 策略，请参阅《Amazon EC2 API Reference》**中 [Examples](https://docs.amazonaws.cn/AWSEC2/latest/APIReference/API_StartDeclarativePoliciesReport.html#API_StartDeclarativePoliciesReport_Examples) 下的 *Sample Amazon S3 policy* 1. 您必须为声明性策略将在其中强制执行基准配置的服务，启用可信访问权限。这将创建一个只读的服务关联角色，用于生成组织内账户现有配置的账户状态报告。 **使用控制台** 对于 Organizations 控制台，此步骤属于启用声明性策略过程的一部分。 **使用 Amazon CLI** 对于 Amazon CLI，请使用[启用AWSService访问权限](https://docs.amazonaws.cn/organizations/latest/APIReference/API_EnableAWSServiceAccess.html) API。 有关如何为特定服务启用可信访问权限的更多信息， Amazon CLI 请参阅 [Amazon Web Services 服务 ，您可以与一起使用 Amazon Organizations](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_integrate_services_list.html)。 1. 每个组织一次只能生成一个报告。如果在生成一个报告的同时尝试生成另一个报告，将会导致错误。 ## 访问合规性状态报告 **最小权限** 要生成合规性状态报告，您需要具有运行以下操作的权限： `ec2:StartDeclarativePoliciesReport` `ec2:DescribeDeclarativePoliciesReports` `ec2:GetDeclarativePoliciesReportSummary` `ec2:CancelDeclarativePoliciesReport` `organizations:DescribeAccount` `organizations:DescribeOrganization` `organizations:DescribeOrganizationalUnit` `organizations:ListAccounts` `organizations:ListDelegatedAdministrators` `organizations:ListAWSServiceAccessForOrganization` `s3:PutObject` **注意** 如果您的 Amazon S3 存储桶使用 SSE-KMS 加密，您还必须在策略中包含 `kms:GenerateDataKey` 权限。 ------ #### [ Amazon Web Services 管理控制台 ] 使用以下步骤来生成账户状态报告。 **生成账户状态报告** 1. 登录 [Amazon Organizations 控制台](https://console.amazonaws.cn/organizations/v2)。您必须以 IAM 用户的身份登录，担任 IAM 角色；或在组织的管理账户中以根用户的身份登录（[不推荐](https://docs.amazonaws.cn/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)）。 1. 在**策略**页面上，选择 **EC2 的声明性策略**。 1. 在 **EC2 的声明性策略**页面上，从**操作**下拉菜单中选择**查看账户状态报告**。 1. 在**查看账户状态报告**页面上，选择**生成状态报告**。 1. 在 “**组织结构**” 控件中，指定要在报告中包含哪些组织单位 (OUs)。 1. 选择**提交**。 ------ #### [ Amazon CLI & Amazon SDKs ] **生成账户状态报告** 使用以下操作生成合规性状态报告、检查其状态并查看报告： + `ec2:start-declarative-policies-report`：生成账户状态报告。报告并非同步生成，可能需要几个小时才能完成。有关更多信息，请参阅 *Amazon EC2 API 参考*中的 [StartDeclarativePoliciesReport](https://docs.amazonaws.cn/AWSEC2/latest/APIReference/API_StartDeclarativePoliciesReport.html)。 + `ec2:describe-declarative-policies-report`：描述账户状态报告的元数据，包括报告的状态。有关更多信息，请参阅 *Amazon EC2 API 参考*中的 [DescribeDeclarativePoliciesReports](https://docs.amazonaws.cn/AWSEC2/latest/APIReference/API_DescribeDeclarativePoliciesReports.html)。 + `ec2:get-declarative-policies-report-summary`：检索账户状态报告摘要。有关更多信息，请参阅 *Amazon EC2 API 参考*中的 [GetDeclarativePoliciesReportSummary](https://docs.amazonaws.cn/AWSEC2/latest/APIReference/API_GetDeclarativePoliciesReportSummary.html)。 + `ec2:cancel-declarative-policies-report`：取消生成账户状态报告。有关更多信息，请参阅 *Amazon EC2 API 参考*中的 [CancelDeclarativePoliciesReport](https://docs.amazonaws.cn/AWSEC2/latest/APIReference/API_CancelDeclarativePoliciesReport.html)。 在生成报告之前，请授予 EC2 声明性策略主体对将存储该报告的 Amazon S3 存储桶的访问权限。要执行该操作，请将以下策略附加到该存储桶。将 `amzn-s3-demo-bucket` 替换为实际的 Amazon S3 存储桶名称，并将 `identity_ARN` 替换为用于调用 `StartDeclarativePoliciesReport` API 的 IAM 身份。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DeclarativePoliciesReportDelivery", "Effect": "Allow", "Principal": { "AWS": "identity_ARN" }, "Action": [ "s3:PutObject" ], "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*", "Condition": { "StringEquals": { "aws:CalledViaLast": "organizations.amazonaws.com" } } } ] } ``` ------ ------ # 声明性策略语法和示例 本页将介绍声明性策略语法并提供示例。 ## 注意事项 + 当您使用声明式策略配置服务属性时，它可能会影响多个 APIs属性。任何不合规的操作都将失败。 + 账户管理员将无法在个人账户级别修改服务属性的值。 ## 声明性策略的语法 声明性策略是一个纯文本文件，根据 [JSON](http://json.org) 的规则设置结构。声明性策略的语法遵循所有管理策略类型的语法。有关该语法的完整讨论，请参阅[管理策略类型的策略语法和继承](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_inheritance_mgmt.html)。本主题重点介绍如何使用该常规语法来满足声明性策略类型的特定要求。 以下示例展示了声明性策略的基本语法： ``` { "ec2_attributes": { "exception_message": { "@@assign": "Your custom error message.https://myURL" } } } ``` + `ec2_attributes` 字段键名称。声明式策略始终以给 Amazon Web Services 服务定密钥的固定密钥名称开头。它是上面示例策略中的顶行。目前，声明性策略仅支持与 Amazon EC2 相关的服务。 + 在 `ec2_attributes` 下，您可以使用 `exception_message` 设置自定义错误消息。有关更多信息，请参阅[声明性策略的自定义错误消息](orgs_manage_policies_declarative.md#orgs_manage_policies_declarative-custom-message)。 + 在 `ec2_attributes` 下，您可以插入一个或多个支持的声明性策略。有关这些架构，请参阅[支持的声明性策略](#declarative-policy-examples)。 ## 支持的声明性策略 以下是声明式策略支持的 Amazon Web Services 服务 和属性。在以下某些示例中，可能会压缩 JSON 空白格式以节省空间。 + VPC 屏蔽公共访问权限 + Serial Console 访问权限 + 映像屏蔽公共访问权限 + 允许的映像设置 + 实例元数据 + 快照屏蔽公共访问权限 ------ #### [ VPC Block Public Access ] **策略效果** 控制 Amazon VPCs 和子网中的资源能否通过互联网网关访问互联网（IGWs）。有关更多信息，请参阅《Amazon Virtual Private Cloud 用户指南》**中的[互联网访问配置](https://docs.amazonaws.cn/vpc/latest/userguide/vpc-igw-internet-access.html)。 **策略内容** ``` { "ec2_attributes": { "vpc_block_public_access": { "internet_gateway_block": { "mode": { "@@assign": "block_ingress" }, "exclusions_allowed": { "@@assign": "enabled" } } } } } ``` 以下是此属性的可用字段： + `"internet_gateway"`: + `"mode"`: + `"off"`：VPC BPA 未启用。 + `"block_ingress"`：所有通往 VPCs （不包括的子网除外）的 VPCs 互联网流量都已被阻止。仅允许进出 NAT 网关和仅出口互联网网关的流量，因为这些网关仅允许建立出站连接。 + `"block_bidirectional"`：所有进出互联网网关和仅限出口的互联网网关（排除的 VPCs 和子网除外）的流量都被阻止。 + `"exclusions_allowed"`：排除是一种可以应用于单个 VPC 或子网的模式，可将其排除在账户的 VPC BPA 模式之外，并允许双向或仅出口访问。 + `"enabled"`：可由账户创建排除项。 + `"disabled"`：无法由账户创建排除项。 **注意** 您可以使用该属性配置是否允许排除项，但不能使用该属性本身创建排除项。要创建排除项，必须在拥有 VPC 的账户中创建。有关创建 VPC BPA 排除项的更多信息，请参阅《Amazon VPC 用户指南》**中的[创建和删除排除项](https://docs.amazonaws.cn//vpc/latest/userguide/security-vpc-bpa.html#security-vpc-bpa-exclusions)。 **注意事项** 如果在声明性策略中使用此属性，则无法使用以下操作来修改范围内账户的强制配置。此列表并不详尽： + `ModifyVpcBlockPublicAccessOptions` + `CreateVpcBlockPublicAccessExclusion` + `ModifyVpcBlockPublicAccessExclusion` ------ #### [ Serial Console Access ] **策略效果** 控制 EC2 Serial Console 是否可访问。有关 EC2 Serial Console 的更多信息，请参阅《Amazon Elastic Compute Cloud 用户指南》**中的 [EC2 Serial Console](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/ec2-serial-console.html)。 **策略内容** ``` { "ec2_attributes": { "serial_console_access": { "status": { "@@assign": "enabled" } } } } ``` 以下是此属性的可用字段： + `"status"`: + `"enabled"`：允许访问 EC2 Serial Console。 + `"disabled"`：阻止访问 EC2 Serial Console。 **注意事项** 如果在声明性策略中使用此属性，则无法使用以下操作来修改范围内账户的强制配置。此列表并不详尽： + `EnableSerialConsoleAccess` + `DisableSerialConsoleAccess` ------ #### [ Image Block Public Access ] **策略效果** 控制 Amazon 机器映像 (AMIs) 是否可公开共享。有关更多信息 AMIs，请参阅《[亚马逊*弹性计算云用户指南》中的亚马逊系统*映像 (AMIs)](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/AMIs.html)。 **策略内容** ``` { "ec2_attributes": { "image_block_public_access": { "state": { "@@assign": "block_new_sharing" } } } } ``` 以下是此属性的可用字段： + `"state"`: + `"unblocked"`: 对公开共享没有限制 AMIs。 + `"block_new_sharing"`: 阻止新的公开共享 AMIs。 AMIs 已经公开分享的内容仍然是公开的。 **注意事项** 如果在声明性策略中使用此属性，则无法使用以下操作来修改范围内账户的强制配置。此列表并不详尽： + `EnableImageBlockPublicAccess` + `DisableImageBlockPublicAccess` ------ #### [ Allowed Images Settings ] **策略效果** 使用 “允许” 控制在 Amazon EC2 中发现和使用亚马逊系统映像 (AMI) AMIs。有关更多信息 AMIs，请参阅[《亚马逊*弹性计算云用户指南*》中的 “允许控制 Amazon EC2 AMIs 中 AMI 的发现和使用](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/ec2-allowed-amis.html)”。 **策略内容** 以下是此属性的可用字段： ``` { "ec2_attributes": { "allowed_images_settings": { "state": { "@@assign": "enabled" }, "image_criteria": { "criteria_1": { "allowed_image_providers": { "@@append": [ "amazon" ] } } } } } } ``` + `"state"`: + `"enabled"`：该属性处于活动状态且已强制执行。 + `"disabled"`：该属性处于活动状态且未强制执行。 + `"audit_mode"`：该属性处于审核模式。这意味着它会识别不合规的映像，但不会阻止其使用。 + `"image_criteria"`：条件列表。最多支持 10 个条件，名称从 criteria\$11 到 criteria\$110 + `"allowed_image_providers"`: 亚马逊、aws\$1marketplace、aws\$1backup\$1vault 的 12 位账户 IDs 或所有者别名的逗号分隔列表。 + `"image_names"`：允许的映像的名称。名称可以包含通配符（? 和 \$1）。长度：1–128 个字符。使用 ? 时，最小长度为 3 个字符。 + `"marketplace_product_codes"`：允许的图片的 Amazon Marketplace 商品代码。长度：1–25 个字符，有效字符：字母（A–Z、a–z）和数字（0–9） + `"creation_date_condition"`：允许的映像的最大期限。 + `"maximum_days_since_created"`：自映像创建以来经过的最长天数。有效范围：最小值为 0。最大值为 2147483647。 + `"deprecation_time_condition"`：自弃用允许的映像以来的最长期限。 + `"maximum_days_since_deprecated"`：自映像弃用以来经过的最长天数。有效范围：最小值为 0。最大值为 2147483647。 **注意事项** 如果在声明性策略中使用此属性，则无法使用以下操作来修改范围内账户的强制配置。此列表并不详尽： + `EnableAllowedImagesSettings` + `ReplaceImageCriteriaInAllowedImagesSettings` + `DisableAllowedImagesSettings` ------ #### [ Instance Metadata ] **策略效果** 控制所有新 EC2 实例启动时的 IMDS 默认值和 IMDSv2 强制执行。有关 IMDS 默认值和 IMDSv2 强制执行的更多信息，请参阅 *Amazon [EC2 用户指南中的使用实例元数据管理您](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)的 EC2* 实例。 **策略内容** 以下是此属性的可用字段： ``` { "ec2_attributes": { "instance_metadata_defaults": { "http_tokens": { "@@assign": "required" }, "http_put_response_hop_limit": { "@@assign": "4" }, "http_endpoint": { "@@assign": "enabled" }, "instance_metadata_tags": { "@@assign": "enabled" }, "http_tokens_enforced": { "@@assign": "enabled" } } } } ``` + `"http_tokens"`: + `"no_preference"`：其他默认值适用。例如 AMI 默认值（如适用）。 + `"required"`: IMDSv2 必须使用。 IMDSv1 是不允许的。 + `"optional"`: 两者 IMDSv1 IMDSv2 都允许。 **注意** **元数据版本** 在设置`http_tokens`为`required`（IMDSv2 必须使用）之前，请确保您的所有实例都没有进行 IMDSv1 调用。有关更多信息，请参阅 *Amazon EC2 用户指南*中的[步骤 1：使用 IMDSv2 =optional 识别实例并审计 IMDSv1 使用情况](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html#path-step-1)。 + `"http_put_response_hop_limit"`: + `"Integer"`：-1 至 64 之间的整数值，表示元数据令牌可以传输的最大跃点数。要表示无首选项，请指定 -1。 **注意** **跃点限制** 如果将 `http_tokens` 设置为 `required`，则建议至少将 `http_put_response_hop_limit` 设置为 2。有关更多信息，请参阅《Amazon Elastic Compute Cloud 用户指南》**中的[实例元数据访问注意事项](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html#imds-considerations)。 + `"http_endpoint"`: + `"no_preference"`：其他默认值适用。例如 AMI 默认值（如适用）。 + `"enabled"`：实例元数据服务端点可访问。 + `"disabled"`：实例元数据服务端点不可访问。 + `"instance_metadata_tags"`: + `"no_preference"`：其他默认值适用。例如 AMI 默认值（如适用）。 + `"enabled"`：可以从实例元数据访问实例标签。 + `"disabled"`：无法从实例元数据访问实例标签。 + `"http_tokens_enforced":` + `"no_preference"`：其他默认值适用。例如 AMI 默认值（如适用）。 + `"enabled"`: IMDSv2 必须使用。尝试启动 IMDSv1 实例或 IMDSv1 在现有实例上启用将失败。 + `"disabled"`: 两者 IMDSv1 IMDSv2 都允许。 **警告** **IMDSv2 执法** 在允许 IMDSv1 和 IMDSv2（令牌可选）的同时启用 IMDSv2 强制将导致启动失败 IMDSv1 ，除非通过启动参数或 AMI 默认值明确禁用。有关更多信息，请参阅 *Amazon EC2 用户指南*中的[启动 IMDSv1启用实例失败](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/troubleshooting-launch.html#launching-an-imdsv1-enabled-instance-fails)。 ------ #### [ Snapshot Block Public Access ] **策略效果** 控制 Amazon EBS 快照是否可以公开访问。有关 EBS 快照的更多信息，请参阅《Amazon Elastic Block Store User Guide》**中的 [Amazon EBS snapshots](https://docs.amazonaws.cn/ebs/latest/userguide/ebs-snapshots.html)。 **策略内容** ``` { "ec2_attributes": { "snapshot_block_public_access": { "state": { "@@assign": "block_new_sharing" } } } } ``` 以下是此属性的可用字段： + `"state"`: + `"block_all_sharing"`：阻止所有公开共享快照的行为。已公开共享的快照将被视为私有快照，不可再公开访问。 + `"block_new_sharing"`：阻止新的公开共享快照的行为。已经公开共享的快照仍可公开访问。 + `"unblocked"`：对快照的公开共享不设限制。 **注意事项** 如果在声明性策略中使用此属性，则无法使用以下操作来修改范围内账户的强制配置。此列表并不详尽： + `EnableSnapshotBlockPublicAccess` + `DisableSnapshotBlockPublicAccess` ------ # 备份策略 Backup 策略允许您集中管理备份计划并将其应用于组织账户中的 Amazon 资源。 [Amazon Backup](https://docs.amazonaws.cn/aws-backup/latest/devguide/)使您能够创建定义如何[备份 Amazon 资源的备份计划](https://docs.amazonaws.cn/aws-backup/latest/devguide/about-backup-plans.html)。计划中的规则包括各种设置，例如备份频率、备份发生的时间窗口、 Amazon Web Services 区域 包含要备份的资源以及存储备份的存储库。然后，您可以将备份计划应用于使用标签标识的 Amazon 资源组。您还必须确定一个 Amazon Identity and Access Management (IAM) 角色，该角色授予代表您执行备份操作的 Amazon Backup 权限。 Backup 策略 Amazon Organizations 将所有这些部分合并到 [JSON](https://json.org) 文本文档中。您可以将备份策略附加到组织结构中的任何元素，例如根帐户、组织单位 (OUs) 和个人帐户。Organizations 应用继承规则来合并组织根目录 OUs、任何父级或账户关联的策略。这将为每个账户生成[有效备份策略](orgs_manage_policies_effective.md)。这项有效的政策指导 Amazon Backup 如何自动备份您的 Amazon 资源。 ## 备份策略的工作原理 备份策略使您能够精确地控制在组织需要的任何级别上备份资源。例如，您可以在附加到组织根的策略中指定必须备份所有 Amazon DynamoDB 表。此策略可以包含默认备份频率。然后，您可以根据每个 OU 的要求将备份策略附加到该策略以覆盖备份频率。 OUs 例如，`Developers` OU 可能指定每周一次的备份频率，而 `Production` OU 指定每天一次。 您可以创建部分备份策略，这些策略分别只包含成功备份资源所需的部分信息。您可以将这些策略附加到组织树的不同部分，例如根组织或父 OU，目的是让这些部分策略由较低级别 OUs 和账户继承。当 Organizations 通过使用继承规则合并账户的所有策略时，生成的有效策略必须具有所有必需元素。否则，会 Amazon Backup 认为该策略无效，并且不会备份受影响的资源。 **重要** Amazon Backup 只有当具有所有必需元素的*完全*有效的策略调用备份时，才能成功执行备份。 虽然前面所述的部分策略可以起作用，但如果某个账户的有效策略不完整，则会生成错误或未成功备份的资源。作为备选策略，请考虑要求所有备份策略本身都完整且有效。使用层次结构中较高的附加策略提供的默认值，并通过包括[继承子控制运算符](policy-operators.md)在子策略中根据需要覆盖这些默认值。 组织 Amazon Web Services 账户 中每个人的有效备份计划作为该账户的不可变计划显示在 Amazon Backup 控制台中。您可以查看该计划，但不能更改。但是，您可以使用[TagResource](https://docs.amazonaws.cn/aws-backup/latest/devguide/API_TagResource.html)和添加或删除备份计划标签[UntagResource](https://docs.amazonaws.cn/aws-backup/latest/devguide/API_UntagResource.html) APIs。 当根据策略创建的备份计划 Amazon Backup 开始备份时，您可以在 Amazon Backup 控制台中看到备份任务的状态。成员账户中的用户可以查看该成员账户中的备份作业的状态和任何错误。如果您还使用启用可信服务访问权限 Amazon Backup，则组织管理账户中的用户可以看到组织中所有备份任务的状态和错误。有关更多信息，请参阅《Amazon Backup 开发人员指南》**中的[启用跨账户管理](https://docs.amazonaws.cn/aws-backup/latest/devguide/manage-cross-account.html#enable-cross-account)。 # 备份策略入门 开始使用 请按照以下步骤开始使用备份策略。 1. [了解执行备份策略任务所必须具备的权限](orgs_manage_policies_prereqs.md)。 1. [了解我们在使用备份策略时建议的一些最佳实践](orgs_manage_policies_backup_best-practices.md)。 1. [为您的组织启用备份策略](enable-policy-type.md)。 1. [创建备份策略](orgs_policies_create.md#create-backup-policy-procedure)。 1. [将备份策略附加到组织根、OU 或账户](orgs_policies_attach.md)。 1. [查看应用于账户的合并的有效备份策略](orgs_manage_policies_effective.md)。 对于上述所有步骤，您必须以 IAM 用户的身份登录，担任 IAM 角色，或在组织的管理账户中以根用户的身份登录（[不推荐](https://docs.amazonaws.cn/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)）。 **其他信息** + [了解备份策略语法并查看示例策略](orgs_manage_policies_backup_syntax.md) # 使用备份策略的最佳实践 最佳实践 Amazon 推荐使用备份策略的以下最佳实践。 ## 决定备份策略 您可以创建不完整的备份策略，然后继承并合并这些策略以便为每个成员账户生成完整的策略。这样做后，如果您在一个级别进行更改，而没有仔细考虑该更改对该级别以下的所有账户的影响，则最终会出现有效策略不完整的风险。为防止出现这种情况，我们建议您改为确保在所有级别实施的备份策略本身完整。将父策略视为可由子策略中指定的设置覆盖的默认策略。这样，即使子策略不存在，继承的策略也是完整的，并使用默认值。您可以使用[子控制继承运算符](policy-operators.md#child-control-operators)来控制可以添加到子策略、由子策略更改或删除的设置。 ## 使用 `GetEffectivePolicy` 验证对备份策略的更改 更改备份策略后，请检查有效策略中低于您进行更改的级别的代表账户。您可以使用 Amazon Web Services 管理控制台、或[使用 [GetEffectivePolicy](https://docs.amazonaws.cn/organizations/latest/APIReference/API_GetEffectivePolicy.html)API 操作或其变体 Amazon CLI 或 Amazon SDK 变体之一来查看有效的策略](orgs_manage_policies_effective.md)。确保您所做的更改对有效策略产生预期影响。 ## 简单开始并进行一些小更改 要简化调试，请先从简单策略开始，然后一次更改一个项目。在进行下一个更改之前，验证每个更改的行为和影响。此方法可以减少出现错误或意外结果时必须考虑的变量数量。 ## 将备份副本存储在组织中的其他账户 Amazon Web Services 区域 和账户中 为了增强灾难恢复能力，您可以存储备份的副本。 + **不同的区域** — 如果您将备份副本存储在其他区域 Amazon Web Services 区域，则可以帮助保护备份在原始区域中免遭意外损坏或删除。使用策略的 `copy_actions` 部分，在运行备份计划的同一账户的一个或多个区域中指定文件库。若要执行此操作，请在指定要在其中存储备份副本的备份文件库的 ARN 时，使用 `$account` 变量来识别账户。`$account ` 变量会在运行时自动替换为运行备份策略的账户 ID。 + **不同的帐户** — 如果您将备份副本存储在其他地方 Amazon Web Services 账户，则会添加安全屏障，以防恶意行为者入侵您的一个帐户。使用策略的 `copy_actions` 部分，在组织中的一个或多个账户中指定文件库，该账户与运行备份计划的账户分开。若要执行此操作，请在指定要在其中存储备份副本的备份文件库的 ARN 时，使用其实际账户 ID 号来识别账户。 ## 限制每个策略的计划数量 包含多个计划的策略的问题排查更加复杂，因为必须全部验证的输出数量更多。相反，让每个策略包含一个且只有一个备份计划，以简化调试和问题排查。然后，您可以添加别的具有其他计划的策略以满足其他要求。此方法有助于将某个计划的任何问题隔离到一个策略中，并防止这些问题使其他策略及其计划的问题的排查复杂化。 ## 使用堆栈套创建所需的备份文件库和 IAM 角色 使用 Amazon CloudFormation 堆栈集与 Organizations 集成，在组织中的每个成员账户中自动创建所需的备份存储库和 Amazon Identity and Access Management (IAM) 角色。您可以创建一个堆栈集，其中包含您希望在组织中的每个 Amazon Web Services 账户 资源中自动可用的资源。此方法使您能够在运行备份计划时确保已满足依赖关系。有关更多信息，请参阅《Amazon CloudFormation 用户指南》**中的[创建具有自行管理权限的堆栈套](https://docs.amazonaws.cn/AWSCloudFormation/latest/UserGuide/stacksets-getting-started-create.html#create-stack-set-service-managed-permissions)。 ## 通过查看在每个账户中创建的第一个备份来检查您的结果 当您对策略进行一项更改时，请检查该更改后创建的下一个备份，以确保该更改产生了预期的影响。此步骤不仅要考虑有效的策略，还要确保它能 Amazon Backup 解释您的策略并按照您的预期实施备份计划。 # 使用 Amazon CloudTrail 事件监控组织中的备份策略 使用 Amazon CloudTrail 事件监视备份策略 您可以使用 Amazon CloudTrail 事件来监控何时创建、更新或从组织中的任何帐户中删除备份策略，或者何时存在无效的组织备份计划。有关更多信息，请参阅《*Amazon Backup 开发人员指南*》中的[记录跨账户管理事件](https://docs.amazonaws.cn/aws-backup/latest/devguide/logging-using-cloudtrail.html#logging-cam-events)。 # 备份策略语法和示例 本页介绍备份策略语法并提供示例。 ## 备份策略的语法 备份策略是一个纯文本文件，根据 [JSON](http://json.org) 的规则设置结构。备份策略的语法遵循所有管理策略类型的语法。有关更多信息，请参阅[管理策略类型的策略语法和继承](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_inheritance_mgmt.html)。本主题重点介绍如何将该常规语法应用于备份策略类型的特定要求。 有关 Amazon Backup 套餐的更多信息，请参阅[CreateBackupPlan](https://docs.amazonaws.cn/aws-backup/latest/devguide/API_CreateBackupPlan.html)《*Amazon Backup 开发人员指南》*。 ## 注意事项 **策略语法** JSON 中会拒绝重复的键名称。 策略必须指定要备份的 Amazon Web Services 区域 和资源。 策略必须指定 Amazon Backup 担任的 IAM 角色。 在同一级别使用 `@@assign` 运算符可能会覆盖现有设置。有关更多信息，请参阅[子策略覆盖父策略中的设置](#backup-policy-example-5)。 继承运算符控制继承的策略和账户策略如何合并到账户的有效策略中。这些运算符包括值设置运算符和子控制运算符。 有关更多信息，请参阅[继承运算符](policy-operators.md)和[备份策略示例](#backup-policy-examples)。 **IAM 角色** 首次创建备份计划时必须存在 IAM 角色。 IAM 角色必须有权访问标签查询标识的资源。 IAM 角色必须具有执行备份的权限。 **Backup 保管库** 在运行备份计划 Amazon Web Services 区域 之前，每个指定的文件库都必须存在。 每个收到有效策略的 Amazon 账户都必须存在文件库。有关更多信息，请参阅《Amazon Backup Developer Guide》**中的 [Backup vault creation and deletion](https://docs.amazonaws.cn/aws-backup/latest/devguide/create-a-vault.html)。 我们建议您使用 Amazon CloudFormation 堆栈集及其与 Organizations 的集成，为组织中的每个成员账户自动创建和配置备份库和 IAM 角色。有关更多信息，请参阅《Amazon CloudFormation 用户指南》**中的[创建具有自行管理权限的堆栈集](https://docs.amazonaws.cn/AWSCloudFormation/latest/UserGuide/stacksets-getting-started-create.html#create-stack-set-service-managed-permissions)。 **配额** 有关配额列表，请参阅《Amazon Backup Developer Guide》**中的 [Amazon Backup quotas](https://docs.amazonaws.cn/aws-backup/latest/devguide/aws-backup-limits.html#aws-backup-policies-quotas-table)。 ## 备份语法：概述 备份策略语法包括以下组件： ``` { "plans": { "PlanName": { "rules": { ... }, "regions": { ... }, "selections": { ... }, "advanced_backup_settings": { ... }, "backup_plan_tags": { ... }, "scan_settings": { ... } } } } ``` **备份策略元素** | Element | 说明 | 必填 | | --- | --- | --- | | [规则](#backup-policy-rules) | 备份规则列表。每条规则都定义了备份开始时间以及 regions 和 selections 元素中指定资源的执行窗口。 | 是 | | [区域](#backup-plan-regions) | 备份策略可以保护资源 Amazon Web Services 区域 的地方列表。 | 是 | | [selections](#backup-plan-selections) | 受备份 rules 保护的指定 regions 中的一个或多个资源类型。 | 是 | | [advanced\$1backup\$1settings](#advanced-backup-settings) | 特定备份情境的配置选项。 目前，唯一支持的高级备份设置是为在 Amazon EC2 实例上运行的 Windows 或 SQL Server 启用 Microsoft 卷影复制服务（VSS）备份。 | 否 | | [backup\$1plan\$1tags](#backup-plan-tags) | 想要与备份计划关联的标签。每个标签都是由用户定义的键和值组成的标签。 标签有助于您管理、识别、组织、搜索和筛选备份计划。 | 否 | | [扫描设置](#scan-settings) | 扫描设置的配置选项。目前唯一支持的扫描设置是启用 Amazon GuardDuty 恶意软件防护 Amazon Backup。 | 否 | ## 备份语法：rules `rules` 策略键指定 Amazon Backup 对选定资源执行的计划备份任务。 **备份规则元素** | Element | 说明 | 必填 | | --- | --- | --- | | schedule\$1expression | UTC 中的 Cron 表达式，用于指定何时 Amazon Backup 启动备份作业。 有关 cron 表达式的信息，请参阅 A *mazon EventBridge 用户*[指南中的使用 cron 和速率表达式调度规则](https://docs.amazonaws.cn/eventbridge/latest/userguide/eb-scheduled-rule-pattern.html)。 | 是 | | target\$1backup\$1vault\$1name | 存储备份的备份文件库。 Backup 保管库由用于创建备份存储库的帐户及其创建 Amazon Web Services 区域 位置所独有的名称进行标识。 | 是 | | target\$1logically\$1air\$1gapped\$1backup\$1vault\$1arn | 存储备份的逻辑间隙保管库 ARN。 如果提供，则支持的完全托管资源将直接备份到逻辑上空隙的保管库，而其他支持的资源则在备份保管库中创建临时（可计费）快照，然后将其复制到逻辑上空隙的保管库中。不支持的资源只能备份到指定的备份存储库。 ARN 必须使用特殊占位符`$region`和。`$account`例如，对于名为的文件库`AirGappedVault`，正确的值为`arn:aws:backup:$region:$account:backup-vault:AirGappedVault`。 | 否 | | start\$1backup\$1window\$1minutes | 如果备份作业未成功启动，则取消备份作业前需要等待的分钟数。 如果包含此值，则必须至少为 60 分钟才能避免错误。 | 否 | | complete\$1backup\$1window\$1minutes | 备份作业成功启动之后必须在该时间之前完成的分钟数，否则将会被 Amazon Backup取消。 | 否 | | enable\$1continuous\$1backup | 指定是否 Amazon Backup 创建连续备份。 `True`导致创建 Amazon Backup 能够 point-in-time恢复的连续备份 (PITR)。 `False`（或未指定）创建快照备份的原因 Amazon Backup 。 有关连续备份的更多信息，请参阅《*Amazon Backup 开发人员指南》中的 [P re oint-in-time co](https://docs.amazonaws.cn/aws-backup/latest/devguide/point-in-time-recovery.html) very*。 **注意：**启用 PITR 的备份最多可保留 35 天。 | 否 | | lifecycle | 指定何 Amazon Backup 时将备份转换为冷存储以及何时过期。 《Amazon Backup Developer Guide》**的 [Feature availability by resources](https://docs.amazonaws.cn/aws-backup/latest/devguide/backup-feature-availability.html#features-by-resource) 中按资源划分的功能可用性表中列出了可以转换为冷存储的资源类型。 每个生命周期都包含以下元素： [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_backup_syntax.html) **注意：**转换为冷存储的备份必须在冷存储中存储至少 90 天。 这意味着 `delete_after_days` 必须比 `move_to_cold_storage_after_days` 多 90 天。 | 否 | | copy\$1actions | 指定是 Amazon Backup 将备份复制到一个还是多个其他位置。 每个复制操作都包含以下元素： [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_backup_syntax.html) **注意：**转换为冷存储的备份必须在冷存储中存储至少 90 天。 这意味着 `delete_after_days` 必须比 `move_to_cold_storage_after_days` 多 90 天。 | 否 | | recovery\$1point\$1tags | 想要分配给从备份中还原的资源的标签。 每个标签都包含以下元素： [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_backup_syntax.html) | 否 | | index\$1actions | 指定是否 Amazon Backup 为您的 Amazon EBS 快照 and/or 创建 Amazon S3 备份的备份索引。创建备份索引是为了搜索备份的元数据。有关备份索引创建和备份搜索的更多信息，请参阅 [Backup search](https://docs.amazonaws.cn//aws-backup/latest/devguide/backup-search.html#backup-search-overview)。 **注意：**创建 Amazon EBS 快照备份索引需要其他 [IAM 角色权限](https://docs.amazonaws.cn//aws-backup/latest/devguide/backup-search.html#backup-search-access)。 每个索引操作都包含以下元素：`resource_types`，其中支持用于索引的资源类型为 Amazon EBS 和 Amazon S3。此参数指定将选择哪种资源类型用于索引。 | 否 | | scan\$1actions | 指定是否为给定规则启用扫描操作。您必须指定`ScanMode`。要成功启动扫描作业，必须将备份策略元素与`scan_actions`结合使用。`scan_settings`还请确保您拥有正确的 [IAM 角色权限](https://docs.amazonaws.cn//aws-backup/latest/devguide/malware-protection.html#malware-access)。 [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_backup_syntax.html) | 否 | ## 备份语法：regions `regions`策略密钥指定 Amazon Web Services 区域 在哪些资源中 Amazon Backup 查找与`selections`密钥中的条件相匹配的资源。 **备份区域元素** | Element | 说明 | 必填 | | --- | --- | --- | | regions | 指定 Amazon Web Services 区域 代码。例如：`["us-east-1", "eu-north-1"]`。 | 是 | ## 备份语法：selections `selections` 策略键指定由备份策略中的规则备份的资源。 有两个互斥的元素：`tags` 和 `resources`。一项有效策略**必须**在选择中包含 tags 或 `resources` 才能生效。 如果您想要同时包含标签条件和资源条件的选择，请使用 `resources` 键。 **备份选择元素：Tags** | Element | 说明 | 必填 | | --- | --- | --- | | iam\$1role\$1arn | Amazon Backup 负责查询、发现和备份指定区域内资源的 IAM 角色。该角色必须具有足够的权限，才能根据标签条件查询资源，并对匹配的资源执行备份操作。 | 是 | | tag\$1key | 要搜索的标签键名称。 | 是 | | tag\$1value | 必须与匹配的 tag\$1key 关联的值。Amazon Backup 仅在 tag\$1key 和 tag\$1value 都匹配（区分大小写）时才会包含该资源。 | 是 | | conditions | 想要包含或排除的标签键和值 使用 string\$1equals 或 string\$1not\$1equals 来包含或排除完全匹配项的标签。 使用 string\$1like 和 string\$1not\$1like 来包含或排除包含或不包含特定字符的标签 **注意：**每项选择限 30 个条件。 | 否 | **备份选择元素：Resources** | Element | 说明 | 必填 | | --- | --- | --- | | iam\$1role\$1arn | Amazon Backup 负责查询、发现和备份指定区域内资源的 IAM 角色。该角色必须具有足够的权限，才能根据标签条件查询资源，并对匹配的资源执行备份操作。 **注意：**在中 Amazon GovCloud (US) Regions，您必须将分区的名称添加到 ARN。 例如，“`arn:aws:ec2:*:*:volume/*`”必须是“`arn:aws-us-gov:ec2:*:*:volume/*`”。 | 是 | | resource\$1types | 要包含在备份计划中的资源类型。 | 是 | | not\$1resource\$1types | 要从备份计划中排除的资源类型。 | 否 | | conditions | 想要包含或排除的标签键和值 使用 string\$1equals 或 string\$1not\$1equals 来包含或排除完全匹配项的标签。 使用 string\$1like 和 string\$1not\$1like 来包含或排除包含或不包含特定字符的标签 **注意：**每项选择限 30 个条件。 | 否 | **支持的资源类型** Organizations 支持 `resource_types` 和 `not_resource_types` 元素的以下资源类型： + Amazon Backup gateway 虚拟机：`"arn:aws:backup-gateway:*:*:vm/*"` + Amazon CloudFormation 堆栈：`"arn:aws:cloudformation:*:*:stack/*"` + Amazon DynamoDB 表：`"arn:aws:dynamodb:*:*:table/*"` + Amazon EC2 实例：`"arn:aws:ec2:*:*:instance/*"` + Amazon EBS 卷：`"arn:aws:ec2:*:*:volume/*"` + Amazon EFS 文件系统：`"arn:aws:elasticfilesystem:*:*:file-system/*"` + 亚马逊 Aurora/Amazon DocumentDB/Amazon Neptune `"arn:aws:rds:*:*:cluster:*"` + Amazon RDS 数据库：`"arn:aws:rds:*:*:db:*"` + Amazon Redshift 集群：`"arn:aws:redshift:*:*:cluster:*"` + Amazon S3：`"arn:aws:s3:::*"` + 适用于 SAP 的 Amazon Systems Manager HANA 数据库：`"arn:aws:ssm-sap:*:*:HANA/*"` + Amazon Storage Gateway 网关：`"arn:aws:storagegateway:*:*:gateway/*"` + Amazon Timestream 数据库：`"arn:aws:timestream:*:*:database/*"` + Amazon FSx 文件系统：`"arn:aws:fsx:*:*:file-system/*"` + Amazon 的 FSx 交易量：`"arn:aws:fsx:*:*:volume/*"` + 亚马逊 Elastic Kubernetes Service 卷：`"arn:aws:eks:*:*:cluster/*"` **代码示例** 有关更多信息，请参阅[使用标签块指定资源](#backup-policy-example-6)和[使用资源块指定资源](#backup-policy-example-7)。 ## 备份语法：advanced backup settings `advanced_backup_settings` 键指定了特定备份情境的配置选项。每个设置都包含以下元素： **高级备份设置元素** | Element | 说明 | 必填 | | --- | --- | --- | | advanced\$1backup\$1settings | 指定特定备份情境的设置。此键包含一个或多个设置。每个设置都是一个 JSON 对象字符串，其中包含以下元素：目前，唯一支持的高级备份设置是为在 Amazon EC2 实例上运行的 Windows 或 SQL Server 启用 Microsoft 卷影复制服务（VSS）备份。 每个高级备份设置都包含以下元素： [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_backup_syntax.html) | 否 | **示例**： ``` "advanced_backup_settings": { "ec2": { "windows_vss": { "@@assign": "enabled" } } }, ``` ## 备份语法：backup plan tags `backup_plan_tags` 策略键可指定附加到备份计划本身的标签。这不会影响为 `rules` 或 `selections` 指定的标签。 **备份计划标签元素** | Element | 说明 | 必填 | | --- | --- | --- | | backup\$1plan\$1tags | 每个标签都是由用户定义的键和值组成的标签：[\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_backup_syntax.html) | 否 | ## Backup 语法：扫描设置 `scan_settings`策略密钥指定使用 Amazon 恶意软件防护进行 GuardDuty 恶意软件扫描的配置 Amazon Backup。要成功启动扫描作业，您必须在备份规则`scan_actions`中结合使用`scan_settings`。 **扫描设置元素** | Element | 说明 | 必填 | | --- | --- | --- | | scan\$1settings | 扫描设置的配置选项。目前唯一支持的扫描设置是启用 Amazon GuardDuty 恶意软件防护 Amazon Backup。必须指定`ResourceTypes`和`ScannerRoleArn`。 [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_backup_syntax.html) | 否 | **示例**： 以下内容显示了如何在备份规则和`scan_settings`计划级别进行配置`scan_actions`以启用 Amazon GuardDuty 恶意软件防护扫描。 `scan_actions`在规则中： ``` "scan_actions": { "GUARDDUTY": { "scan_mode": { "@@assign": "INCREMENTAL_SCAN" } } } ``` `scan_settings`在计划层面： ``` "scan_settings": { "GUARDDUTY": { "resource_types": { "@@assign": ["EBS"] }, "scanner_role_arn": { "@@assign": "arn:aws:iam::$account:role/MyGuardDutyScannerRole" } } } ``` ## 备份策略示例 下面的示例备份策略仅供参考。在以下某些示例中，可能会压缩 JSON 空白格式以节省空间。 + [示例 1：分配给父节点的策略](#backup-policy-example-1) + [示例 2：父级策略与子级策略合并](#backup-policy-example-2) + [示例 3：家长政策禁止子女政策进行任何更改](#backup-policy-example-3) + [示例 4：父级策略禁止子级策略更改一个备份计划](#backup-policy-example-4) + [示例 5：儿童政策会覆盖家长策略中的设置](#backup-policy-example-5) + [示例 6：使用标签块指定资源](#backup-policy-example-6) + [示例 7：使用资源块指定资源](#backup-policy-example-7) + [示例 8：带有 Amazon GuardDuty 恶意软件防护扫描功能的 Backup 计划](#backup-policy-example-8) ### 示例 1：分配给父节点的策略 以下示例显示了分配给账户的父节点之一的备份策略。 **父策略** – 此策略可以附加到组织根，或附加到作为所有预期账户父级的任何 OU。 ``` { "plans": { "PII_Backup_Plan": { "regions": { "@@assign": [ "ap-northeast-2", "us-east-1", "eu-north-1" ] }, "rules": { "Hourly": { "schedule_expression": { "@@assign": "cron(0 5/1 ? * * *)" }, "start_backup_window_minutes": { "@@assign": "480" }, "complete_backup_window_minutes": { "@@assign": "10080" }, "lifecycle": { "move_to_cold_storage_after_days": { "@@assign": "180" }, "delete_after_days": { "@@assign": "270" }, "opt_in_to_archive_for_supported_resources": { "@@assign": "false" } }, "target_backup_vault_name": { "@@assign": "FortKnox" }, "target_logically_air_gapped_backup_vault_arn": { "@@assign": "arn:aws:backup:$region:$account:backup-vault:AirGappedVault" }, "index_actions": { "resource_types": { "@@assign": [ "EBS", "S3" ] } }, "copy_actions": { "arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault": { "target_backup_vault_arn": { "@@assign": "arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault" }, "lifecycle": { "move_to_cold_storage_after_days": { "@@assign": "30" }, "delete_after_days": { "@@assign": "120" }, "opt_in_to_archive_for_supported_resources": { "@@assign": "false" } } }, "arn:aws:backup:us-west-1:111111111111:backup-vault:tertiary_vault": { "target_backup_vault_arn": { "@@assign": "arn:aws:backup:us-west-1:111111111111:backup-vault:tertiary_vault" }, "lifecycle": { "move_to_cold_storage_after_days": { "@@assign": "30" }, "delete_after_days": { "@@assign": "120" }, "opt_in_to_archive_for_supported_resources": { "@@assign": "false" } } } } } }, "selections": { "tags": { "datatype": { "iam_role_arn": { "@@assign": "arn:aws:iam::$account:role/MyIamRole" }, "tag_key": { "@@assign": "dataType" }, "tag_value": { "@@assign": [ "PII", "RED" ] } } } }, "advanced_backup_settings": { "ec2": { "windows_vss": { "@@assign": "enabled" } } } } } } ``` 如果账户没有继承或附加其他保单，则每个适用政策中提供的有效政策如下例所 Amazon Web Services 账户 示。CRON 表达式会使备份每小时运行一次。账户 ID 123456789012 将是每个账户的实际账户 ID。 ``` { "plans": { "PII_Backup_Plan": { "regions": [ "us-east-1", "ap-northeast-3", "eu-north-1" ], "rules": { "hourly": { "schedule_expression": "cron(0 0/1 ? * * *)", "start_backup_window_minutes": "60", "target_backup_vault_name": "FortKnox", "target_logically_air_gapped_backup_vault_arn": "arn:aws:backup:$region:$account:backup-vault:AirGappedVault", "index_actions": { "resource_types": { "@@assign": [ "EBS", "S3" ] } }, "lifecycle": { "delete_after_days": "2", "move_to_cold_storage_after_days": "180", "opt_in_to_archive_for_supported_resources": "false" }, "copy_actions": { "arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault": { "target_backup_vault_arn": { "@@assign": "arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault" }, "lifecycle": { "delete_after_days": "28", "move_to_cold_storage_after_days": "180", "opt_in_to_archive_for_supported_resources": "false" } }, "arn:aws:backup:us-west-1:111111111111:backup-vault:tertiary_vault": { "target_backup_vault_arn": { "@@assign": "arn:aws:backup:us-west-1:111111111111:backup-vault:tertiary_vault" }, "lifecycle": { "delete_after_days": "28", "move_to_cold_storage_after_days": "180", "opt_in_to_archive_for_supported_resources": "false" } } } } }, "selections": { "tags": { "datatype": { "iam_role_arn": "arn:aws:iam::123456789012:role/MyIamRole", "tag_key": "dataType", "tag_value": [ "PII", "RED" ] } } }, "advanced_backup_settings": { "ec2": { "windows_vss": "enabled" } } } } } ``` ### 示例 2：父策略与子策略合并 在以下示例中，继承的父级策略和子级策略要么继承，要么直接附加到 Amazon Web Services 账户 合并，形成有效的策略。 **父策略** – 此策略可以附加到组织根或任何父 OU。 ``` { "plans": { "PII_Backup_Plan": { "regions": { "@@append":[ "us-east-1", "ap-northeast-3", "eu-north-1" ] }, "rules": { "Hourly": { "schedule_expression": { "@@assign": "cron(0 0/1 ? * * *)" }, "start_backup_window_minutes": { "@@assign": "60" }, "target_backup_vault_name": { "@@assign": "FortKnox" }, "index_actions": { "resource_types": { "@@assign": [ "EBS", "S3" ] } }, "lifecycle": { "move_to_cold_storage_after_days": { "@@assign": "28" }, "delete_after_days": { "@@assign": "180" }, "opt_in_to_archive_for_supported_resources": { "@@assign": "false" } }, "copy_actions": { "arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault" : { "target_backup_vault_arn" : { "@@assign" : "arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault" }, "lifecycle": { "move_to_cold_storage_after_days": { "@@assign": "28" }, "delete_after_days": { "@@assign": "180" }, "opt_in_to_archive_for_supported_resources": { "@@assign": "false" } } } } } }, "selections": { "tags": { "datatype": { "iam_role_arn": { "@@assign": "arn:aws:iam::$account:role/MyIamRole" }, "tag_key": { "@@assign": "dataType" }, "tag_value": { "@@assign": [ "PII", "RED" ] } } } } } } } ``` **子策略** – 此策略可以直接附加到账户，或附加到父策略所附加到的级别以下的任何级别的 OU。 ``` { "plans": { "Monthly_Backup_Plan": { "regions": { "@@append":[ "us-east-1", "eu-central-1" ] }, "rules": { "Monthly": { "schedule_expression": { "@@assign": "cron(0 5 1 * ? *)" }, "start_backup_window_minutes": { "@@assign": "480" }, "target_backup_vault_name": { "@@assign": "Default" }, "lifecycle": { "move_to_cold_storage_after_days": { "@@assign": "30" }, "delete_after_days": { "@@assign": "365" }, "opt_in_to_archive_for_supported_resources": { "@@assign": "false" } }, "copy_actions": { "arn:aws:backup:us-east-1:$account:backup-vault:Default" : { "target_backup_vault_arn" : { "@@assign" : "arn:aws:backup:us-east-1:$account:backup-vault:Default" }, "lifecycle": { "move_to_cold_storage_after_days": { "@@assign": "30" }, "delete_after_days": { "@@assign": "365" }, "opt_in_to_archive_for_supported_resources": { "@@assign": "false" } } } } } }, "selections": { "tags": { "MonthlyDatatype": { "iam_role_arn": { "@@assign": "arn:aws:iam::$account:role/MyMonthlyBackupIamRole" }, "tag_key": { "@@assign": "BackupType" }, "tag_value": { "@@assign": [ "MONTHLY", "RED" ] } } } } } } } ``` **生成的有效策略** – 应用于账户的有效策略包含两个计划，每个计划都有自己的规则集以及要应用这些规则的资源集。 ``` { "plans": { "PII_Backup_Plan": { "regions": [ "us-east-1", "ap-northeast-3", "eu-north-1" ], "rules": { "hourly": { "schedule_expression": "cron(0 0/1 ? * * *)", "start_backup_window_minutes": "60", "target_backup_vault_name": "FortKnox", "index_actions": { "resource_types": { "@@assign": [ "EBS", "S3" ] } }, "lifecycle": { "delete_after_days": "2", "move_to_cold_storage_after_days": "180", "opt_in_to_archive_for_supported_resources": { "@@assign": "false" } }, "copy_actions": { "arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault" : { "target_backup_vault_arn" : { "@@assign" : "arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault" }, "lifecycle": { "move_to_cold_storage_after_days": "28", "delete_after_days": "180", "opt_in_to_archive_for_supported_resources": { "@@assign": "false" } } } } } }, "selections": { "tags": { "datatype": { "iam_role_arn": "arn:aws:iam::$account:role/MyIamRole", "tag_key": "dataType", "tag_value": [ "PII", "RED" ] } } } }, "Monthly_Backup_Plan": { "regions": [ "us-east-1", "eu-central-1" ], "rules": { "monthly": { "schedule_expression": "cron(0 5 1 * ? *)", "start_backup_window_minutes": "480", "target_backup_vault_name": "Default", "lifecycle": { "delete_after_days": "365", "move_to_cold_storage_after_days": "30", "opt_in_to_archive_for_supported_resources": { "@@assign": "false" } }, "copy_actions": { "arn:aws:backup:us-east-1:$account:backup-vault:Default" : { "target_backup_vault_arn": { "@@assign" : "arn:aws:backup:us-east-1:$account:backup-vault:Default" }, "lifecycle": { "move_to_cold_storage_after_days": "30", "delete_after_days": "365", "opt_in_to_archive_for_supported_resources": { "@@assign": "false" } } } } } }, "selections": { "tags": { "monthlydatatype": { "iam_role_arn": "arn:aws:iam::&ExampleAWSAccountNo3;:role/MyMonthlyBackupIamRole", "tag_key": "BackupType", "tag_value": [ "MONTHLY", "RED" ] } } } } } } ``` ### 示例 3：父策略阻止子策略进行任何更改 在以下示例中，继承的父策略使用[子控制运算符](policy-operators.md#child-control-operators)强制执行所有设置，并防止它们被子策略更改或覆盖。 **父策略** – 此策略可以附加到组织根或任何父 OU。策略的每个节点都存在 `"@@operators_allowed_for_child_policies": ["@@none"]` 意味着，子策略不能对计划进行任何类型的更改。子策略也不能将其他计划添加到有效策略。此策略将成为其附加到的每个 OU 以及 OU 下的账户的有效策略。 ``` { "plans": { "@@operators_allowed_for_child_policies": ["@@none"], "PII_Backup_Plan": { "@@operators_allowed_for_child_policies": ["@@none"], "regions": { "@@operators_allowed_for_child_policies": ["@@none"], "@@append": [ "us-east-1", "ap-northeast-3", "eu-north-1" ] }, "rules": { "@@operators_allowed_for_child_policies": ["@@none"], "Hourly": { "@@operators_allowed_for_child_policies": ["@@none"], "schedule_expression": { "@@operators_allowed_for_child_policies": ["@@none"], "@@assign": "cron(0 0/1 ? * * *)" }, "start_backup_window_minutes": { "@@operators_allowed_for_child_policies": ["@@none"], "@@assign": "60" }, "target_backup_vault_name": { "@@operators_allowed_for_child_policies": ["@@none"], "@@assign": "FortKnox" }, "index_actions": { "@@operators_allowed_for_child_policies": ["@@none"], "resource_types": { "@@assign": [ "EBS", "S3" ] } }, "lifecycle": { "@@operators_allowed_for_child_policies": ["@@none"], "move_to_cold_storage_after_days": { "@@operators_allowed_for_child_policies": ["@@none"], "@@assign": "28" }, "delete_after_days": { "@@operators_allowed_for_child_policies": ["@@none"], "@@assign": "180" }, "opt_in_to_archive_for_supported_resources": { "@@operators_allowed_for_child_policies": ["@@none"], "@@assign": "false" } }, "copy_actions": { "@@operators_allowed_for_child_policies": ["@@none"], "arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault": { "@@operators_allowed_for_child_policies": ["@@none"], "target_backup_vault_arn": { "@@assign": "arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault", "@@operators_allowed_for_child_policies": ["@@none"] }, "lifecycle": { "@@operators_allowed_for_child_policies": ["@@none"], "delete_after_days": { "@@operators_allowed_for_child_policies": ["@@none"], "@@assign": "28" }, "move_to_cold_storage_after_days": { "@@operators_allowed_for_child_policies": ["@@none"], "@@assign": "180" }, "opt_in_to_archive_for_supported_resources": { "@@operators_allowed_for_child_policies": ["@@none"], "@@assign": "false" } } } } } }, "selections": { "@@operators_allowed_for_child_policies": ["@@none"], "tags": { "@@operators_allowed_for_child_policies": ["@@none"], "datatype": { "@@operators_allowed_for_child_policies": ["@@none"], "iam_role_arn": { "@@operators_allowed_for_child_policies": ["@@none"], "@@assign": "arn:aws:iam::$account:role/MyIamRole" }, "tag_key": { "@@operators_allowed_for_child_policies": ["@@none"], "@@assign": "dataType" }, "tag_value": { "@@operators_allowed_for_child_policies": ["@@none"], "@@assign": [ "PII", "RED" ] } } } }, "advanced_backup_settings": { "@@operators_allowed_for_child_policies": ["@@none"], "ec2": { "@@operators_allowed_for_child_policies": ["@@none"], "windows_vss": { "@@assign": "enabled", "@@operators_allowed_for_child_policies": ["@@none"] } } } } } } ``` **生成的有效策略** – 如果存在任何子备份策略，则会忽略这些策略，而父策略将成为有效策略。 ``` { "plans": { "PII_Backup_Plan": { "regions": [ "us-east-1", "ap-northeast-3", "eu-north-1" ], "rules": { "hourly": { "schedule_expression": "cron(0 0/1 ? * * *)", "start_backup_window_minutes": "60", "target_backup_vault_name": "FortKnox", "index_actions": { "resource_types": { "@@assign": [ "EBS", "S3" ] } }, "lifecycle": { "delete_after_days": "2", "move_to_cold_storage_after_days": "180", "opt_in_to_archive_for_supported_resources": "false" }, "copy_actions": { "target_backup_vault_arn": "arn:aws:backup:us-east-1:123456789012:backup-vault:secondary_vault", "lifecycle": { "move_to_cold_storage_after_days": "28", "delete_after_days": "180", "opt_in_to_archive_for_supported_resources": "false" } } } }, "selections": { "tags": { "datatype": { "iam_role_arn": "arn:aws:iam::123456789012:role/MyIamRole", "tag_key": "dataType", "tag_value": [ "PII", "RED" ] } } }, "advanced_backup_settings": { "ec2": {"windows_vss": "enabled"} } } } } ``` ### 示例 4：父策略阻止子策略对一个备份计划进行更改 在以下示例中，继承的父策略使用[子控制运算符](policy-operators.md#child-control-operators)强制执行单个计划的设置，并防止它们被子策略更改或覆盖。子策略仍然可以添加其他计划。 **父策略** – 此策略可以附加到组织根或任何父 OU。此示例与前一个示例类似，所有子继承运算符都被阻止，但 `plans` 顶级处除外。该级别的 `@@append` 设置使子策略能够将其他计划添加到有效策略中的集合。对继承计划的任何更改仍被阻止。 为清楚起见，截断了计划中的相应部分。 ``` { "plans": { "@@operators_allowed_for_child_policies": ["@@append"], "PII_Backup_Plan": { "@@operators_allowed_for_child_policies": ["@@none"], "regions": { ... }, "rules": { ... }, "selections": { ... } } } } ``` **子策略** – 此策略可以直接附加到账户，或附加到父策略所附加到的级别以下的任何级别的 OU。此子策略定义一个新计划。 为清楚起见，截断了计划中的相应部分。 ``` { "plans": { "MonthlyBackupPlan": { "regions": { ... }, "rules": { ... }, "selections": { … } } } } ``` **生成的有效策略** – 有效策略包括这两个计划。 ``` { "plans": { "PII_Backup_Plan": { "regions": { ... }, "rules": { ... }, "selections": { ... } }, "MonthlyBackupPlan": { "regions": { ... }, "rules": { ... }, "selections": { … } } } } ``` ### 示例 5：子策略覆盖父策略中的设置 在以下示例中，子策略使用[值设置运算符](policy-operators.md#value-setting-operators)来覆盖从父策略继承的某些设置。 **父策略** – 此策略可以附加到组织根或任何父 OU。子策略可以覆盖任何设置，因为在没有阻止子策略的[子控制运算符](policy-operators.md#child-control-operators)的情况下，默认行为是允许子策略执行 `@@assign`、`@@append` 或 `@@remove`。父策略包含有效备份计划所需的所有元素，因此，如果它按原样继承，则会成功备份您的资源。 ``` { "plans": { "PII_Backup_Plan": { "regions": { "@@append": [ "us-east-1", "ap-northeast-3", "eu-north-1" ] }, "rules": { "Hourly": { "schedule_expression": {"@@assign": "cron(0 0/1 ? * * *)"}, "start_backup_window_minutes": {"@@assign": "60"}, "target_backup_vault_name": {"@@assign": "FortKnox"}, "index_actions": { "resource_types": { "@@assign": [ "EBS", "S3" ] } }, "lifecycle": { "delete_after_days": {"@@assign": "2"}, "move_to_cold_storage_after_days": {"@@assign": "180"}, "opt_in_to_archive_for_supported_resources": {"@@assign": false} }, "copy_actions": { "arn:aws:backup:us-east-1:$account:backup-vault:t2": { "target_backup_vault_arn": {"@@assign": "arn:aws:backup:us-east-1:$account:backup-vault:t2"}, "lifecycle": { "move_to_cold_storage_after_days": {"@@assign": "28"}, "delete_after_days": {"@@assign": "180"}, "opt_in_to_archive_for_supported_resources": {"@@assign": false} } } } } }, "selections": { "tags": { "datatype": { "iam_role_arn": {"@@assign": "arn:aws:iam::$account:role/MyIamRole"}, "tag_key": {"@@assign": "dataType"}, "tag_value": { "@@assign": [ "PII", "RED" ] } } } } } } } ``` **子策略** – 子策略仅包含需要与继承的父策略不同的设置。必须有一个继承的父策略，该策略在合并到有效策略时提供其他所需设置。否则，有效备份策略会包含无效的备份计划，无法按预期备份您的资源。 ``` { "plans": { "PII_Backup_Plan": { "regions": { "@@assign": [ "us-west-2", "eu-central-1" ] }, "rules": { "Hourly": { "schedule_expression": {"@@assign": "cron(0 0/2 ? * * *)"}, "start_backup_window_minutes": {"@@assign": "80"}, "target_backup_vault_name": {"@@assign": "Default"}, "lifecycle": { "move_to_cold_storage_after_days": {"@@assign": "30"}, "delete_after_days": {"@@assign": "365"}, "opt_in_to_archive_for_supported_resources": {"@@assign": false} } } } } } } ``` **生成的有效策略** – 有效策略包括来自这两个策略的设置，由子策略提供的设置将覆盖从父级继承的设置。在此示例中，将发生以下更改： + 区域列表替换为完全不同的列表。如果要将区域添加到继承的列表中，请在子策略中使用 `@@append` 而不是 `@@assign`。 + Amazon Backup 每隔一小时执行一次，而不是每小时执行一次。 + Amazon Backup 允许开始备份的时间为 80 分钟，而不是 60 分钟。 + Amazon Backup 使用保`Default`管库而不是`FortKnox`。 + 向冷存储转移和最终删除备份的生命周期都会延长。 ``` { "plans": { "PII_Backup_Plan": { "regions": [ "us-west-2", "eu-central-1" ], "rules": { "hourly": { "schedule_expression": "cron(0 0/2 ? * * *)", "start_backup_window_minutes": "80", "target_backup_vault_name": "Default", "index_actions": { "resource_types": { "@@assign": [ "EBS", "S3" ] } }, "lifecycle": { "delete_after_days": "365", "move_to_cold_storage_after_days": "30", "opt_in_to_archive_for_supported_resources": "false" }, "copy_actions": { "arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault": { "target_backup_vault_arn": {"@@assign": "arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault"}, "lifecycle": { "move_to_cold_storage_after_days": "28", "delete_after_days": "180", "opt_in_to_archive_for_supported_resources": "false" } } } } }, "selections": { "tags": { "datatype": { "iam_role_arn": "arn:aws:iam::$account:role/MyIamRole", "tag_key": "dataType", "tag_value": [ "PII", "RED" ] } } } } } } ``` ### 示例 6：使用 `tags` 块指定资源 以下示例包括所有带有 `tag_key` = `“env”` 和 `tag_value` = `"prod"` 或的资源`"gamma"`。此示例不包括 `tag_key` = `"backup"` 和 `tag_value` = `"false"` 的资源。 ``` ... "selections":{ "tags":{ "selection_name":{ "iam_role_arn": {"@@assign": "arn:aws:iam::$account:role/IAMRole"}, "tag_key":{"@@assign": "env"}, "tag_value":{"@@assign": ["prod", "gamma"]}, "conditions":{ "string_not_equals":{ "condition_name1":{ "condition_key": { "@@assign": "aws:ResourceTag/backup" }, "condition_value": { "@@assign": "false" } } } } } } }, ... ``` ### 示例 7：使用 `resources` 块指定资源 以下是使用 `resources` 块指定资源的示例。 ------ #### [ Example: Select all resources in my account ] 布尔逻辑与您在 IAM 策略中可能使用的逻辑类似。`"resource_types"` 块使用布尔值 `AND` 来组合资源类型。 ``` ... "resources":{ "resource_selection_name":{ "iam_role_arn":{"@@assign": "arn:aws:iam::$account:role/IAMRole"}, "resource_types":{ "@@assign": [ "*" ] } } }, ... ``` ------ #### [ Example: Select all resources in my account, but exclude Amazon EBS volumes ] 布尔逻辑与您在 IAM 策略中可能使用的逻辑类似。`"resource_types"` 和 `"not_resource_types"` 块使用布尔值 `AND` 来组合资源类型。 ``` ... "resources":{ "resource_selection_name":{ "iam_role_arn":{"@@assign": "arn:aws:iam::$account:role/IAMRole"}, "resource_types":{ "@@assign": [ "*" ] }, "not_resource_types":{ "@@assign": [ "arn:aws:ec2:*:*:volume/*" ] } } }, ... ``` ------ #### [ Example: Select all resources tagged with "backup" : "true", but exclude Amazon EBS volumes ] 布尔逻辑与您在 IAM 策略中可能使用的逻辑类似。`"resource_types"` 和 `"not_resource_types"` 块使用布尔值 `AND` 来组合资源类型。`"conditions"` 块使用布尔值 `AND`。 ``` ... "resources":{ "resource_selection_name":{ "iam_role_arn":{"@@assign": "arn:aws:iam::$account:role/IAMRole"}, "resource_types":{ "@@assign": [ "*" ] }, "not_resource_types":{ "@@assign": [ "arn:aws:ec2:*:*:volume/*" ] }, "conditions":{ "string_equals":{ "condition_name1":{ "condition_key": { "@@assign":"aws:ResourceTag/backup"}, "condition_value": { "@@assign":"true" } } } } } }, ... ``` ------ #### [ Example: Select all Amazon EBS volumes and Amazon RDS DB instances tagged with both "backup" : "true" and "stage" : "prod" ] 布尔逻辑与您在 IAM 策略中可能使用的逻辑类似。`"resource_types"` 块使用布尔值 `AND` 来组合资源类型。`"conditions"` 块使用布尔值 `AND` 来组合资源类型和标签条件。 ``` ... "resources":{ "resource_selection_name":{ "iam_role_arn":{"@@assign": "arn:aws:iam::$account:role/IAMRole"}, "resource_types":{ "@@assign": [ "arn:aws:ec2:*:*:volume/*", "arn:aws:rds:*:*:db:*" ] }, "conditions":{ "string_equals":{ "condition_name1":{ "condition_key":{"@@assign":"aws:ResourceTag/backup"}, "condition_value":{"@@assign":"true"} }, "condition_name2":{ "condition_key":{"@@assign":"aws:ResourceTag/stage"}, "condition_value":{"@@assign":"prod"} } } } } }, ... ``` ------ #### [ Example: Select all Amazon EBS volumes and Amazon RDS instances tagged with "backup" : "true" but not "stage" : "test" ] 布尔逻辑与您在 IAM 策略中可能使用的逻辑类似。`"resource_types"` 块使用布尔值 `AND` 来组合资源类型。`"conditions"` 块使用布尔值 `AND` 来组合资源类型和标签条件。 ``` ... "resources":{ "resource_selection_name":{ "iam_role_arn":{"@@assign": "arn:aws:iam::$account:role/IAMRole"}, "resource_types":{ "@@assign": [ "arn:aws:ec2:*:*:volume/*", "arn:aws:rds:*:*:db:*" ] }, "conditions":{ "string_equals":{ "condition_name1":{ "condition_key":{"@@assign":"aws:ResourceTag/backup"}, "condition_value":{"@@assign":"true"} } }, "string_not_equals":{ "condition_name2":{ "condition_key":{"@@assign":"aws:ResourceTag/stage"}, "condition_value":{"@@assign":"test"} } } } } }, ... ``` ------ #### [ Example: Select all resources tagged with "key1" and a value which begins with "include" but not with "key2" and value that contains the word "exclude" ] 布尔逻辑与您在 IAM 策略中可能使用的逻辑类似。`"resource_types"` 块使用布尔值 `AND` 来组合资源类型。`"conditions"` 块使用布尔值 `AND` 来组合资源类型和标签条件。 在此示例中，请注意 `include*`、`*exclude*` 和 `arn:aws:rds:*:*:db:*` 中使用了通配符 `(*)`。您可以在字符串的开头、结尾和中间使用通配符 `(*)`。 ``` ... "resources":{ "resource_selection_name":{ "iam_role_arn":{"@@assign": "arn:aws:iam::$account:role/IAMRole"}, "resource_types":{ "@@assign": [ "*" ] }, "conditions":{ "string_like":{ "condition_name1":{ "condition_key":{"@@assign":"aws:ResourceTag/key1"}, "condition_value":{"@@assign":"include*"} } }, "string_not_like":{ "condition_name2":{ "condition_key":{"@@assign":"aws:ResourceTag/key2"}, "condition_value":{"@@assign":"*exclude*"} } } } } }, ... ``` ------ #### [ Example: Select all resources tagged with "backup" : "true" except Amazon FSx file systems and Amazon RDS resources ] 布尔逻辑与您在 IAM 策略中可能使用的逻辑类似。`"resource_types"` 和 `"not_resource_types"` 块使用布尔值 `AND` 来组合资源类型。`"conditions"` 块使用布尔值 `AND` 来组合资源类型和标签条件。 ``` ... "resources":{ "resource_selection_name":{ "iam_role_arn":{"@@assign": "arn:aws:iam::$account:role/IAMRole"}, "resource_types":{ "@@assign": [ "*" ] }, "not_resource_types":{ "@@assign":[ "arn:aws:fsx:*:*:file-system/*", "arn:aws:rds:*:*:db:*" ] }, "conditions":{ "string_equals":{ "condition_name1":{ "condition_key":{"@@assign":"aws:ResourceTag/backup"}, "condition_value":{"@@assign":"true"} } } } } }, ... ``` ------ ### 示例 8：带有 Amazon GuardDuty 恶意软件防护扫描功能的 Backup 计划 以下示例显示了在备份恢复点上启用 Amazon GuardDuty 恶意软件防护扫描的备份策略。该策略在规则`scan_actions`中用于启用扫描，`scan_settings`在计划级别使用该策略来配置扫描仪。 要使用此功能，您必须拥有相应的 IAM 角色权限。有关更多信息，请参阅《*Amazon Backup 开发者指南》中的 A [cces](https://docs.amazonaws.cn//aws-backup/latest/devguide/malware-protection.html#malware-access) s*。 ``` { "plans": { "Malware_Scan_Backup_Plan": { "regions": { "@@assign": [ "us-east-1", "us-west-2" ] }, "rules": { "Daily_With_Incremental_Scan": { "schedule_expression": { "@@assign": "cron(0 5 ? * * *)" }, "start_backup_window_minutes": { "@@assign": "60" }, "target_backup_vault_name": { "@@assign": "Default" }, "lifecycle": { "delete_after_days": { "@@assign": "35" } }, "scan_actions": { "GUARDDUTY": { "scan_mode": { "@@assign": "INCREMENTAL_SCAN" } } } }, "Monthly_With_Full_Scan": { "schedule_expression": { "@@assign": "cron(0 5 1 * ? *)" }, "start_backup_window_minutes": { "@@assign": "60" }, "target_backup_vault_name": { "@@assign": "Default" }, "lifecycle": { "delete_after_days": { "@@assign": "365" } }, "scan_actions": { "GUARDDUTY": { "scan_mode": { "@@assign": "FULL_SCAN" } } } } }, "selections": { "tags": { "scan_selection": { "iam_role_arn": { "@@assign": "arn:aws:iam::$account:role/MyBackupRole" }, "tag_key": { "@@assign": "backup" }, "tag_value": { "@@assign": [ "true" ] } } } }, "scan_settings": { "GUARDDUTY": { "resource_types": { "@@assign": [ "EBS" ] }, "scanner_role_arn": { "@@assign": "arn:aws:iam::$account:role/MyGuardDutyScannerRole" } } } } } } ``` 此示例中的关键点是： + `scan_actions`在每条规则中指定。扫描仪名称`GUARDDUTY`用作密钥。每日规则使用`INCREMENTAL_SCAN`，每月规则使用`FULL_SCAN`。 + `scan_settings`是在计划层面指定的（不是在规则内部）。它配置要扫描的扫描器角色和资源类型。 + `scanner_role_arn`必须引用附有`AWSBackupGuardDutyRolePolicyForScans`托管策略的 IAM 角色和允许`malware-protection.guardduty.amazonaws.com`服务委托人担任该角色的信任策略。 # 标签策略 标签策略允许您标准化附加到组织账户中 Amazon 资源的标签。 您可以使用标签策略来维护一致的标签，包括标签键和标签值的首选大小写处理。 ## 标签是什么？ *标签*是您分配或 Amazon 分配给 Amazon 资源的自定义属性标签。每个 标签具有两个部分： + *标签键*（例如，`CostCenter`、`Environment` 或 `Project`）。标签键区分大小写。 + 一个称为*标签值* 的可选字段（例如，`111122223333` 或 `Production`）。省略标签值与使用空字符串效果相同。与标签键一样，标签值区分大小写。 本页的其余部分描述了标签策略。有关标签的更多信息，请参阅以下资源： + 有关标记的一般信息，包括命名和使用惯例，请参阅《[https://docs.amazonaws.cn/tag-editor/latest/userguide/tagging.html](https://docs.amazonaws.cn/tag-editor/latest/userguide/tagging.html)指南》。 + 有关支持使用标签的服务的列表，请参阅[https://docs.amazonaws.cn/resourcegroupstagging/latest/APIReference/Welcome.html](https://docs.amazonaws.cn/resourcegroupstagging/latest/APIReference/Welcome.html)。 + 有关使用标签对资源进行分类的信息，请参阅《[https://docs.amazonaws.cn/whitepapers/latest/tagging-best-practices/tagging-best-practices.html](https://docs.amazonaws.cn/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)》白皮书。 + 有关标记 Organizations 资源的信息，请参阅[标记资源 Amazon Organizations注意事项](orgs_tagging.md)。 + 有关为其他资源添加标签的信息 Amazon Web Services 服务，请参阅该服务的文档。 ## 什么是标签策略？ *标签策略* 是策略的一种类型，可帮助您在组织账户中跨资源标准化标签。在标签策略中，您可以指定在标记资源时适用于资源的标记规则。 例如，标签策略可以指定当 `CostCenter` 标签附加到资源时，它必须使用标签策略定义的大小写处理和标签值。标签策略还可以指定在指定资源类型上*强制执行* 不合规的标记操作。换句话说，阻止在指定的资源类型上完成不合规的标记操作。不会评估未标记的资源或未在标签策略中定义的标签是否符合标签策略。 使用标签策略涉及使用多个 Amazon Web Services 服务： + 使用 **Amazon Organizations** 管理*标签策略*。登录到组织的管理账户时，您可以使用 Organizations 启用标签策略功能。您必须以 IAM 用户的身份登录，担任 IAM 角色；或在组织的管理账户中以根用户的身份登录（[不推荐](https://docs.amazonaws.cn/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)）。然后，您可以创建标签策略并将其附加到组织实体，以使这些标记规则生效。 + 使用 **Amazon Resource Groups** 管理与标签策略的*合规性*。登录组织中的账户时，您可以使用 Resource Groups 查找账户中资源的不合规标签。您可以在创建资源的 Amazon 服务中更正不合规的标签。您还可以使用[标签编辑器](https://docs.amazonaws.cn/tag-editor/latest/userguide/tag-editor.html)和[资源组标记](https://docs.amazonaws.cn/resourcegroupstagging/latest/APIReference/overview.html) API 来标记来自多个服务的资源以及取消标记。 如果您登录组织的管理账户，则可以查看组织所有账户的合规性信息。 标签策略仅在[启用所有功能](orgs_manage_org_support-all-features.md)的组织中可用。有关使用标签策略所需条件的更多信息，请参阅[的管理策略的先决条件和权限 Amazon Organizations](orgs_manage_policies_prereqs.md)。 **重要** 要开始使用标签策略， Amazon 强烈建议您先按照中所述的示例工作流程进行操作，[标签策略入门](orgs_manage_policies_tag-policies-getting-started.md)然后再继续使用更高级的标签策略。在将标签策略扩展到整个 OU 或组织之前，最好了解将一个简单标签策略附加到单个账户的效果。在*强制实施* 与任何标签策略的合规性之前，了解某个标签策略的影响尤为重要。[标签策略入门](orgs_manage_policies_tag-policies-getting-started.md)页面上的表还提供了更多高级策略相关任务的说明的链接。 # 使用标签策略的最佳实践 最佳实践 Amazon 推荐使用标签策略的以下最佳实践。 ## 确立标签大小写策略 确定您希望如何设定标签的大小写并在所有资源类型中一致地实施该策略。例如，决定是使用 `Costcenter`、`costcenter` 还是 `CostCenter`，以及是否对所有标签使用相同的约定。为了在合规性报告中获得一致的结果，请避免使用具有不一致大小写处理的类似标签。此策略将帮助您定义组织的标签策略。 ## 使用推荐的工作流程 从小事开始做，创建一个简单的标签策略。然后将其附加到用于测试用途的会员账户。使用[标签策略入门](orgs_manage_policies_tag-policies-getting-started.md)中描述的工作流。 ## 确定标记规则 这将取决于您组织的需求。例如，您可能需要指定将`CostCenter`标签附加到 Amazon Secrets Manager 密钥时，它必须使用指定的大小写处理。创建定义合规标签的标签策略，并将其附加到希望这些标记规则生效的组织实体。 ## 培训账户管理员 当您准备扩展标签策略的使用时，请按照以下方式对账户管理员进行培训： + 沟通您的标签策略。 + 强调管理员需要对特定资源类型使用标签。 这一点很重要，因为未标记的资源在合规性结果中不会显示为不合规。 + 提供有关使用标签策略检查合规性的指导。指导管理员使用《标记资源用户指南》中[评估账户合规性中描述的步骤查找和更正其账户中 Amazon 资源上的不合规](https://docs.amazonaws.cn/tag-editor/latest/userguide/tag-policies-orgs-finding-noncompliant-tags.html)*标签*。告知他们您希望的合规性检查频率。 ## 在强制执行合规性时要谨慎 强制执行合规性可能会阻止组织账户中的用户标记他们所需的资源。查看[强制标记一致性](orgs_manage_policies_tag-policies-enforcement.md)中的信息。另请参阅[标签策略入门](orgs_manage_policies_tag-policies-getting-started.md)中描述的工作流。 ## 注意标签限制 Amazon 服务通常有 50 个用户定义的标签上限，这些标签无法修改。在使用诸如 “报告必填标签” 之类的功能时，请确保贵组织的有效政策不超过任何给定资源类型的必需标签。超过此限制可能会导致两个问题：资源可能无法在合规性摘要中达到合规性状态；当根据需要定义超过 50 个标签时，基础设施即代码 (IaC) 平台可能无法创建资源。 ## 考虑创建 SCP 以围绕资源创建请求设置防护机制 从未附加标签的资源在报告中不会显示为不合规。账户管理员仍然可以创建未标记的资源。在某些情况下，您可以使用服务控制策略 (SCP) 来设置有关资源创建请求的防护机制。 要了解某项 Amazon 服务是否支持使用标签控制访问权限 [Amazon Web Services 服务 ，请参阅 IAM 用户指南中的与 I](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) *AM* 配合使用。在 **ABAC（基于标签的授权）**列中查找显示为**是**的服务。选择服务名称以查看该服务的授权和访问控制文档。 # 标签策略入门 开始使用 使用标签策略涉及使用多个 Amazon Web Services 服务。要开始使用，请查看以下页面。然后按照此页面上的工作流来熟悉标签策略及其效果。 + [的管理策略的先决条件和权限 Amazon Organizations](orgs_manage_policies_prereqs.md) + [使用标签策略的最佳实践](orgs_manage_policies_tag-policies-best-practices.md) ## 首次使用标签策略 首次使用标签策略时，请按照以下步骤开始。 | Task | 要登录的账户 | Amazon 要使用的服务控制台 | | --- | --- | --- | | 步骤 1：[为您的组织启用标签策略。](enable-policy-type.md) | 组织的管理账户。¹ | [Amazon Organizations](https://console.amazonaws.cn/organizations/) | | 步骤 2：[创建标签策略](orgs_policies_create.md#create-tag-policy-procedure)。 保持第一个标签策略简单。输入您要使用的一个大小写处理标签键，并将所有其他选项保留为默认值。 | 组织的管理账户。¹ | [Amazon Organizations](https://console.amazonaws.cn/organizations/) | | 步骤 3：[将标签策略附加到可用于测试的单个成员账户。](orgs_policies_attach.md) 在下一步中您需要登录此账户。 | 组织的管理账户。¹ | [Amazon Organizations](https://console.amazonaws.cn/organizations/) | | 步骤 4：创建一些具有合规标签的资源，以及一些具有不合规标签的资源。 | 您用于测试目的的成员账户。 | 任何您满意的 Amazon 服务。例如，您可以使用 [Amazon Secrets Manager](https://console.amazonaws.cn/secretsmanager/) 并按照[创建基本密钥](https://docs.amazonaws.cn/secretsmanager/latest/userguide/manage_create-basic-secret.html)中的过程创建具有合规和不合规密钥的密钥。 | | 步骤 5：[查看有效标签策略并评估账户的合规性状态。](https://docs.amazonaws.cn/tag-editor/latest/userguide/tag-policies-orgs-finding-noncompliant-tags.html) | 您用于测试目的的成员账户。 | [R](https://console.amazonaws.cn/resource-groups/) esource Amazon Groups 和创建资源的服务。 如果您创建了具有合规和不合规标签的资源，则应在结果中看到不合规标签。 | | 步骤 6：重复查找和纠正合规性问题的过程，直到测试账户中的资源均符合标签策略。 | 您用于测试目的的成员账户。 | [R](https://console.amazonaws.cn/resource-groups/) esource Amazon Groups 和创建资源的服务。 | | 您可以随时[评估组织级的合规性](https://docs.amazonaws.cn/ARG/latest/userguide/tag-policies-orgs-evaluating-org-wide-compliance.html)。 | 组织的管理账户。¹ | [资源组](https://console.amazonaws.cn/resource-groups/) | ¹ 您必须以 IAM 用户的身份登录，担任 IAM 角色；或在组织的管理账户中以根用户的身份登录（[不推荐](https://docs.amazonaws.cn/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)）。 ## 扩大标签策略的使用 您可以按任意顺序执行以下任务以扩展标签策略的使用范围。 | 高级任务 | 要登录的账户 | Amazon 要使用的服务控制台 | | --- | --- | --- | | [创建更多高级标签策略](orgs_policies_create.md#create-tag-policy-procedure)。 遵循与初次用户相同的流程，但尝试其他任务。例如，定义其他键或值，或为标签键指定不同的大小写处理。 您可以使用[了解管理策略继承](orgs_manage_policies_inheritance_mgmt.md)和[标签策略语法](orgs_manage_policies_example-tag-policies.md#tag-policy-syntax-reference)中的信息创建更详细的标签策略。 | 组织的管理账户。¹ | [Amazon Organizations](https://console.amazonaws.cn/organizations/) | | [将标签策略附加到其他账户或 OUs.](orgs_policies_attach.md) 在将更多策略附加到账户或账户是其成员的任何 OU 之后，检查[账户的有效标签策略](orgs_manage_policies_effective.md)。 | 组织的管理账户。¹ | [Amazon Organizations](https://console.amazonaws.cn/organizations/) | | 创建 SCP，以便在任何人创建新资源时要求标签。 | 组织的管理账户。¹ | [Amazon Organizations](https://console.amazonaws.cn/organizations/) | | [当账户更改时，继续根据有效标签策略评估账户的合规性状态。更正不合规标签。](https://docs.amazonaws.cn/ARG/latest/userguide/tag-policies-orgs-finding-noncompliant-tags.html) | 具有有效标签策略的成员账户。 | [R](https://console.amazonaws.cn/resource-groups/) esource Amazon Groups 和创建资源的服务。 | | [评估组织级的合规性](https://docs.amazonaws.cn/ARG/latest/userguide/tag-policies-orgs-evaluating-org-wide-compliance.html)。 | 组织的管理账户。¹ | [资源组](https://console.amazonaws.cn/resource-groups/) | ¹ 您必须以 IAM 用户的身份登录，担任 IAM 角色；或在组织的管理账户中以根用户的身份登录（[不推荐](https://docs.amazonaws.cn/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)）。 ## 首次强制执行标签策略 要首次强制执行标签策略，请遵循类似于首次使用标签策略使用测试账户的工作流。 **警告** 在强制执行合规性时要谨慎。请确保您了解使用标签策略的效果并遵循推荐的工作流。在将强制执行扩展到更多账户之前，在测试账户中测试强制执行的影响。否则，您可能会阻止组织账户中的用户标记他们所需的资源。有关更多信息，请参阅 [强制标记一致性](orgs_manage_policies_tag-policies-enforcement.md)。 | 强制执行任务 | 要登录的账户 | Amazon 要使用的服务控制台 | | --- | --- | --- | | 步骤 1：[创建标签策略](orgs_policies_create.md#create-tag-policy-procedure)。 保持第一个强制执行的标签策略简单。输入您要使用的一个大小写处理标签键，然后选择 **Prevent noncompliant operations for this tag (防止此标签的不合规操作)** 选项。然后指定要在其上强制执行的资源类型。继续我们之前的例子，您可以选择在 Secrets Manager 密钥上强制执行它。 | 组织的管理账户。¹ | [Amazon Organizations](https://console.amazonaws.cn/organizations/) | | 步骤 2：[将标签策略附加到单个测试账户。](orgs_policies_attach.md) | 组织的管理账户。¹ | [Amazon Organizations](https://console.amazonaws.cn/organizations/) | | 步骤 3：尝试创建一些具有合规标签的资源，一些具有不合规标签的资源。不允许在标签策略中指定的带有不兼容标签类型的资源上创建标签。 | 您用于测试目的的成员账户。 | 任何您满意的 Amazon 服务。例如，您可以使用 [Amazon Secrets Manager](https://console.amazonaws.cn/secretsmanager/) 并按照[创建基本密钥](https://docs.amazonaws.cn/secretsmanager/latest/userguide/manage_create-basic-secret.html)中的过程创建具有合规和不合规密钥的密钥。 | | 步骤 4：[根据有效标签策略评估账户的合规性状态，并更正不合规的标签。 ](https://docs.amazonaws.cn/ARG/latest/userguide/tag-policies-orgs-finding-noncompliant-tags.html) | 您用于测试目的的成员账户。 | [R](https://console.amazonaws.cn/resource-groups/) esource Amazon Groups 和创建资源的服务。 | | 步骤 5：重复查找和纠正合规性问题的过程，直到测试账户中的资源均符合标签策略。 | 您用于测试目的的成员账户。 | [R](https://console.amazonaws.cn/resource-groups/) esource Amazon Groups 和创建资源的服务。 | | 您可以随时[评估组织级的合规性](https://docs.amazonaws.cn/ARG/latest/userguide/tag-policies-orgs-evaluating-org-wide-compliance.html)。 | 组织的管理账户。¹ | [资源组](https://console.amazonaws.cn/resource-groups/) | ¹ 您必须以 IAM 用户的身份登录，担任 IAM 角色；或在组织的管理账户中以根用户的身份登录（[不推荐](https://docs.amazonaws.cn/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)）。 # 报告标签合规性 标签策略为 “基本合规性规则” 和 “必需的标签密钥” 提供了报告模式。您可以使用此模式来评估组织中某个账户是否符合其有效标签策略。生成的报告仅包含生命周期中任何时候至少有一个用户定义标签的资源。 **重要** 未标记的资源不会在结果中显示为不合规。 要在您的账户中查找未标记的资源，请使用 Amazon 资源管理器并使用`tag:none`查询。有关更多信息，请参阅《[资源管理器用户指南》中的搜索未标记](https://docs.amazonaws.cn/resource-explorer/latest/userguide/using-search-query-examples.html#example-1)*的Amazon 资源*。 **Topics** + [ ## 报告 “基本合规规则” ](#reporting-basic-compliance-rules) + [ ## 报告 “必需的标签密钥” ](#reporting-required-tag-key) + [ # 生成组织级的合规性报告 ](enforcement-report.md) ## 报告 “基本合规规则” 通过报告基本合规性规则，您可以生成标签合规性报告，根据大小写和允许的标签值检查合规性。 **要举报，** 在可视化编辑器选项卡中，输入要报告合规性的标签密钥的值。下面的屏幕截图显示了 “CostCenter” 标签密钥的客户合规报告。在此示例中，如果标记的资源仅与 “” 标签键的小写值匹配，则该报告将突出显示该资源为合规，这意味着该字符串等于 “costcenterCostCenter”。 ![\[可视化编辑器选项卡，显示带有 Legal 和 HR 值的 CostCenter 标签的标签策略配置\]](http://docs.amazonaws.cn/organizations/latest/userguide/images/tag-policies-basic-compliance-reporting.png) 下面的 JSON 会根据 “CostCenter” 标签键的小写值生成资源的合规性报告。 ``` { "tags": { "CostCenter": {} } } ``` **要报告资本化情况，** 在 “可视化编辑器” 选项卡中，输入要报告合规性的标签键的值，然后选择 “大写” 选项。下面的屏幕截图显示了带有大写字母的 “CostCenter” 标签密钥的客户合规报告。在此示例中，如果标记的资源与 “CostCenter” 标签键完全匹配的字符串，则该报告将突出显示该资源为合规。 ![\[可视化编辑器选项卡，显示大写 CostCenter 标签的标签策略配置\]](http://docs.amazonaws.cn/organizations/latest/userguide/images/tag-policies-basic-compliance-capitalization.png) 下面的 JSON 会针对带大写字母的 “CostCenter” 标签键生成资源的合规性报告。 ``` { "tags": { "CostCenter": { "tag_key": { "@@assign": "CostCenter" } } } } ``` **要使用大写来报告允许的标签值，** 在可视化编辑器选项卡中，输入要报告合规性的标签键的值，选择允许的值选项，然后输入允许的标签值的值。下面的屏幕截图显示了 “CostCenter” 标签键的客户合规报告，其中包含大写字母和允许的标签值。在此示例中，如果标记的资源与 “” 标签键完全匹配，并且标签值为 “HRCostCenter” 或 “Legal”，则该报告将突出显示该资源为合规。 ![\[可视化编辑器选项卡，显示带有大写字母和允许 CostCenter 标签值的标签策略配置 HR 和 Legal\]](http://docs.amazonaws.cn/organizations/latest/userguide/images/tag-policies-basic-compliance-allowed-tag-values-with-capitalization.png) 下面的 JSON 会根据 “CostCenter” 标签键生成资源合规性报告，该报告包含大写字母和允许的标签值 “HR” 和 “Legal”。 ``` { "tags": { "CostCenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@assign": [ "HR", "Legal" ] } } } } ``` ## 报告 “必需的标签密钥” **警告** Res Amazon ource Groups 控制台目前不支持在评估账户合规性时报告所需的标签密钥。缺少所需标签密钥的不合规资源不会出现在**带有不合规标签的资源**部分，也不会将该账户标记为不合规。改用组织范围的合规性报告来查找缺少所需标签密钥的不合规资源。 通过报告所需的标签密钥，您可以评估您的资源创建操作是缺少必需的标签密钥还是必需的标签密钥。在 CLI 中运行以下命令，列出账户有效标签策略中定义的必需标签密钥。您可以使用此信息手动验证您创建的资源是否包含账户管理员定义的所有必需标签。 ``` $ aws resourcegroupstaggingapi list-required-tags ``` **要报告所需的标签密钥，** 在 “可视化编辑器” 选项卡中，输入要报告合规性的标签键的值，然后选择 “将**标记为报告所需的**标记” 选项。下面的屏幕截图显示了 “CostCenter” 标签密钥的客户合规报告，其中包含所需标签密钥的大写和报告。在此示例中，如果标记的资源包含确切的字符串 “CostCenter” 作为标签键，则该报告将突出显示该资源为合规。 **重要** 您需要根据报告选项的要求同时选择 “大写” 和 “标记” 标签，以生成缺少精确所需标签的选定资源类型的报告。例如，当您尝试检查是否与 “CostCenter” 标签键完全匹配时，将同时使用这两个选项。 您只能选择 “将标签标记为报告所需的标记” 选项，以生成缺少所需标签的选定资源类型的报告。在这种情况下，如果资源有 “”、“CostCenter”、“Costcenter”、CostCenter “costcenter” 或任何类似的变体，则生成的报告将标记为合规。此功能允许您为选定的资源类型生成合规性报告，而不是为账户中的所有已标记资源生成合规性报告。 仅选择 “大写” 将生成所有已标记资源的报告，如果标签键的字符串不完全匹配，则将这些资源标记为不合规。 ![\[可视化编辑器选项卡，显示所需标签报告的标签策略配置\]](http://docs.amazonaws.cn/organizations/latest/userguide/images/tag-policies-basic-compliance-required-tag.png) 下面的 JSON 会根据 “CostCenter” 标签键为资源生成合规性报告，并使用大写字母和标记标签作为报告所必需的标记。 ``` { "tags": { "CostCenter": { "tag_key": { "@@assign": "CostCenter" }, "report_required_tag_for": { "@@assign": [ "ec2:ALL_SUPPORTED" ] } } } } ``` **为了强制执行，** 您可以将报告与 IaC 工具（例如 Amazon CloudFormation Terraform 和 Pulumi）一起使用，以警告开发人员或阻止缺少所需标签的部署。现在，你可以使用一种有效的标签策略，该策略可以跨越 Amazon CloudFormation Terraform和Pulumi。有关更多详细信息，请参阅[使用 IaC 强制执行 “必需的标签密钥”](enforce-required-tag-keys-iac.md)。 # 生成组织级的合规性报告 生成组织级的合规性报告 您可以随时生成一份报告，列出 Amazon Web Services 账户 整个组织中所有已标记的资源。报告显示每个资源是否符合有效标签策略。请注意，您对标签策略或资源所做的更改，最多可能需要 48 小时才能反映在组织范围内的合规性报告中。例如，如果您的标签策略为资源类型定义了新的标准化标签，则该类型中没有此标签的资源将在最长 48 小时的时间内在报告中显示为合规。 您可以从 `us-east-1` 区域中的组织管理账户生成报告，前提是该账户具有对 Amazon S3 存储桶的访问权限。存储桶必须具有附加的存储桶策略，如[用于存储报告的 Amazon S3 存储桶策略](https://docs.amazonaws.cn/ARG/latest/userguide/tag-policies-prereqs.html#bucket-policy)中所示。若要生成报告，请运行以下命令： ``` $ aws resourcegroupstaggingapi start-report-creation --region us-east-1 ``` 您一次可以生成一个报告。 完成报告可能需要一些时间。您可以通过运行以下命令来检查状态： ``` $ aws resourcegroupstaggingapi describe-report-creation --region us-east-1 { "Status": "SUCCEEDED" } ``` 当上述命令返回 `SUCCEEDED` 时，您可以从 Amazon S3 存储桶打开报告。 # 强制标记一致性 标签策略提供了两种功能来帮助您在 Amazon 环境中强制执行标签一致性：“基本合规性规则” 和 “必需的标签密钥”。您可以将这些功能与两种标签策略模式结合使用：强制执行和报告。本节重点介绍这两种功能的强制执行模式。有关这两种功能的报告模式的详细信息，请参阅 “报告标签合规性”。 **Topics** + [ ## 强制执行 “基本合规规则” ](#basic-compliance-rules) + [ ## 最佳实践 ](#best-practices) + [ # 使用 IaC 强制执行 “必需的标签密钥” ](enforce-required-tag-keys-iac.md) + [ # 标签策略语法和示例 ](orgs_manage_policies_example-tag-policies.md) ## 强制执行 “基本合规规则” 通过强制执行基本合规性规则，您可以防止使用不符合标签策略中指定要求的标签值创建资源。例如，如果提供的 “” 标签密钥的标签值不是 “商业” 或 “合法CostCenter”，则您可以定义一项策略，该策略将阻止 Amazon EC2 创建操作。基本合规性规则还允许您根据标签密钥的大小写来实施强制执行。启用大小写可确保标签键的字符串精确匹配。Capital CostCenter 将 “”、“CostCenter” 和 “Costcenter” 视为唯一的标签密钥，这意味着标签密钥的强制执行区分大小写。强制使用大写可以防止团队意外创建标签变体。标签一致性对于成本跟踪的准确性和基于属性的访问控制 (ABAC) 安全策略至关重要，后者依赖精确的标签匹配来授予或拒绝资源访问权限。 **重要** 基本合规性规则不会对创建的没有标签的资源强制执行标签合规性。此功能不会强制执行缺失的标签密钥。您不能使用此功能来确保在创建资源时配置了必需或必需的标签密钥。在 “必填标签密钥” 中使用报告模式，为由 IaC 工具（例如 Terraform 和 Pulumi）创建的资源强制使用所需的标签密钥。 Amazon CloudFormation如果请求不包含指定标签，则用于 SCPs 防止目标账户中的 IAM 用户和角色创建某些资源类型。 要使用标签策略强制执行基本合规性规则，请在[创建标签策略](orgs_policies_create.md)时执行以下操作之一： + 在 “**可视化编辑器**” 选项卡中，选择 “**防止对此标签进行不合规操作**” 选项。有关如何[创作和附加标签策略的步骤，请参阅创建](orgs_policies_create.md)标签策略部分。 + 在 **JSON** 选项卡中，使用 `enforced_for` 字段。有关标签策略语法的信息，请参阅[标签策略语法和示例](orgs_manage_policies_example-tag-policies.md)。 下图显示了 “可视化编辑器” 选项卡的控制台体验。在此示例中，客户正在定义一个标签策略，该策略将仅对标签策略支持的 Amazon EC2 资源类型强制执行标签值验证。当为亚马逊 EC2 资源类型提供的标签密钥为 “” 时，此政策将检查标签值是 “合法” 还是 “HRCostCenter”。此策略还强制使用大写，这意味着策略正在寻找与 “CostCenter” 标签键完全匹配的字符串。 ![\[可视化编辑器选项卡，显示带有 Legal 和 HR 值的 CostCenter 标签的标签策略配置\]](http://docs.amazonaws.cn/organizations/latest/userguide/images/tag-policies-basic-compliance.png) 下面的 JSON 是上述 “CostCenter” 示例中生成的标签策略。 **重要** 我们建议您在首次定义标签策略时使用可视化编辑器。可视化编辑器可确保您的标签策略语法有效，无需执行其他步骤，并为您提供定义标签策略的简化可点击体验。您可以使用可视化编辑器或 JSON 选项卡来定义标签策略。 ``` { "tags": { "CostCenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@assign": [ "HR", "Legal" ] }, "enforced_for": { "@@assign": [ "ec2:ALL_SUPPORTED" ] } } } } ``` ## 最佳实践 使用 “基本合规性规则” 和 “IaC 必需的标签密钥” 以及标签策略遵循以下最佳执法实践： + **强制合规性时要谨慎行事** — 确保您了解使用标签策略的效果并遵循中描述的推荐工作流程[标签策略入门](orgs_manage_policies_tag-policies-getting-started.md)。在将测试账号扩展到更多账户或组织单位之前，先测试其实施方式。否则，您可能会阻止组织账户中的用户创建他们所需的资源。 + **了解可以对哪些资源类型强制执行** – 您只能对[支持资源类型](orgs_manage_policies_supported-resources-enforcement.md)上的标签策略强制执行合规性。当您使用可视化编辑器构建标签策略时，将列出支持强制执行合规性的资源类型。 + **了解与某些服务的交互** — 有些服务 Amazon Web Services 服务 具有类似容器的资源分组，可以自动为您创建资源，并将标签从一项服务中的资源传播到另一项服务。例如，亚马逊 EC2 群组和 Amazon EMR 集群上的标签可以自动传播到包含的亚马逊实例。 EC2 您对亚马逊 EC2 的标签政策可能比针对群组或 Amazon EMR 集群的标签政策更为严格。如果您启用强制执行，则标签策略会阻止对标记资源，并可能会阻止动态扩展和预配置。 以下各部门介绍如何查找不符合要求的资源，以及如何将其更正为合规。 **Topics** + [识别和修复标签不一致之处](orgs_manage_policies_tag-policies-identify-remediate.md) # 使用 IaC 强制执行 “必需的标签密钥” 标签策略可帮助您在基础设施即代码 (IaC) 部署中保持一致的标记。使用 “必填标签密钥”，您可以确保通过 IaC 工具（例如 Amazon CloudFormation Terraform 和 Pulumi）创建的所有资源都包含组织定义的强制性标签。 在创建资源之前，此功能会根据组织的标签策略检查您的 IaC 部署。当部署缺少必需的标签时，您可以将 IaC 设置配置为警告开发团队或完全阻止部署。这种积极主动的方法从创建资源的那一刻起就保持了标签合规性，而不必在以后需要手动修复。使用单一标签策略定义跨多个 IaC 工具强制执行，无需为组织使用的每种工具配置单独的标记规则。 **Topics** + [ ## 强制执行 Amazon CloudFormation ](#enforce-with-cloudformation) + [ ## 使用 Terraform 强制执行 ](#enforce-with-terraform) + [ ## 使用 Pulumi 强制执行 ](#enforce-with-pulumi) ## 强制执行 Amazon CloudFormation **注意** 要使用强制使用所需的标签密钥 Amazon CloudFormation，您必须在标签策略中为资源类型指定必需的标签。有关更多详细信息，请参阅[报告 “必需的标签密钥”](orgs_manage_policies_tag-policies-report-tagging-compliance.md#reporting-required-tag-key) 一节。 **为 Amazon::TagPolicies: TaggingComplianceValidator Hook 设置执行角色** 在激活`Amazon::TagPolicies::TaggingComplianceValidator`挂钩之前，必须创建挂钩用来访问 Amazon 服务的执行角色。该角色必须附加以下信任策略： ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "resources.cloudformation.amazonaws.com", "hooks.cloudformation.amazonaws.com" ] }, "Action": [ "sts:AssumeRole" ] } ] } ``` 执行角色还必须具有至少具有以下权限的角色策略： ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "tag:ListRequiredTags" ], "Resource": "*" } ] } ``` 有关为公共扩展设置执行角色的更多信息，请参阅 Amazon CloudFormation 用户指南中的[使用 IAM 权限配置执行角色和公有扩展访问权限的信任策略](https://docs.amazonaws.cn/AWSCloudFormation/latest/UserGuide/registry-public.html#registry-public-enable-execution-role)。 **激活 Amazon:::TagPolicies: TaggingComplianceValidator Hook** **重要** 在继续操作之前，请确认您拥有使用 Hook 所需的权限，并从控制 CloudFormation 台查看主动控件。有关更多信息，请参阅[授予 CloudFormation Hook 的 IAM 权限](https://docs.amazonaws.cn/cloudformation-cli/latest/hooks-userguide/grant-iam-permissions-for-hooks.html)。 更新标签策略后，您必须在要强制执行所需标签合规性的每个 Amazon 账户和区域中激活该`Amazon::TagPolicies::TaggingComplianceValidator`挂钩。 这个 Amazon托管挂钩可以在两种模式下配置： + **警告模式**：允许继续部署，但在缺少所需标签时会生成警告 + **失败模式**：阻止缺少必需标签的部署 要使用 Amazon CLI 激活挂钩，请执行以下操作： ``` aws cloudformation activate-type \ --type HOOK \ --type-name AWS::TagPolicies::TaggingComplianceValidator \ --execution-role-arn arn:aws:iam::123456789012:role/MyHookExecutionRole \ --publisher-id aws-hooks \ --region us-east-1 ``` ``` aws cloudformation set-type-configuration \ --configuration '{"CloudFormationConfiguration":{"HookConfiguration":{"HookInvocationStatus": "ENABLED", "FailureMode": "WARN", "TargetOperations": ["STACK"], "Properties":{}}}}' \ --type-arn "arn:aws:cloudformation:us-east-1:123456789012:type/hook/AWS-TagPolicies-TaggingComplianceValidator" \ --region us-east-1 ``` `region`替换为目标 Amazon 区域，`"FailureMode":"WARN"`如果您更喜欢警告模式，请更改`"FailureMode":"FAIL"`为。 **使用 Amazon以下方式激活:TagPolicies::: 跨多个账户和区域的TaggingComplianceValidator 挂钩 Amazon CloudFormation StackSets** 对于拥有多个 Amazon 账户的组织，您可以使用 Amazon Amazon CloudFormation StackSets 在所有账户和地区同时激活标签合规性挂钩。 Amazon CloudFormation StackSets 允许您通过一次操作将同一个 Amazon CloudFormation 模板部署到多个账户和区域。这种方法可确保在整个 Amazon 组织中实现一致的标签强制执行，而无需在每个账户中进行手动配置。 要 Amazon CloudFormation StackSets 用于此目的，请执行以下操作： 1. 创建激活标签合规性挂钩的 Amazon CloudFormation 模板 1. 使用部署模板 Amazon CloudFormation StackSets 来定位您的组织单位或特定客户 1. 指定要在其中启用强制措施的所有区域 该 Amazon CloudFormation StackSets 部署将自动处理所有指定账户和地区的激活流程，从而确保整个组织内统一的标签合规性。要了解如何将 Amazon CloudFormation Hook 部署到具有服务管理功能的组织 Amazon CloudFormation StackSets，请参阅此[Amazon 博客](https://www.amazonaws.cn/blogs/devops/deploy-cloudformation-hooks-to-an-organization-with-service-managed-stacksets/)。 *使用以下 Amazon CloudFormation 模板 Amazon CloudFormation StackSets 为组织中的账户激活 Amazon TagPolicies:::: TaggingComplianceValidator Hook。* **重要** 这个钩子只能用作 StackHook. 当用作资源挂钩时，它没有任何效果。 ``` Resources: # Activate the AWS-managed hook type HookTypeActivation: Type: AWS::CloudFormation::TypeActivation Properties: AutoUpdate: True PublisherId: "AWS" TypeName: "AWS::TagPolicies::TaggingComplianceValidator" # Configure the hook HookTypeConfiguration: Type: AWS::CloudFormation::HookTypeConfig DependsOn: HookTypeActivation Properties: TypeName: "AWS::TagPolicies::TaggingComplianceValidator" TypeArn: !GetAtt HookTypeActivation.Arn Configuration: !Sub | { "CloudFormationConfiguration": { "HookConfiguration": { "TargetStacks": "ALL", "TargetOperations": ["STACK"], "Properties": {}, "FailureMode": "Warn", "TargetFilters": { "Actions": [ "CREATE", "UPDATE" ]} } } } ``` **注意** 有关运行 Amazon CloudFormation 挂钩的更多信息，请参阅在[账户中激活基于主动控制的挂钩](https://docs.amazonaws.cn/cloudformation-cli/latest/hooks-userguide/proactive-controls-hooks-activate-hooks.html)。 ## 使用 Terraform 强制执行 要使用 Terraform 强制执行所需的标签密钥，您需要将 Terraform Amazon 提供程序更新到 6.22.0 或更高版本，并在提供程序配置中启用标签策略验证。有关实现细节和配置示例，请参阅有关[标签策略实施的 Terraform Prov Amazon ider 文档](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/guides/tag-policy-compliance)。 ## 使用 Pulumi 强制执行 要使用 Pulumi 强制执行所需的标签密钥，您需要在 Pulumi Cloud 中启用标签策略报告策略包，并使用标签策略读取权限配置您的 IAM 角色。有关实现细节和配置示例，请参阅 [Pulumi 关于标签策略实施的文档](https://www.pulumi.com/docs/insights/policy/integrations/aws-organizations-tag-policies/#aws-organizations-tag-policies)。 # 标签策略语法和示例 本页介绍标签策略语法并提供示例。 **Topics** + [ ## 标签策略语法 ](#tag-policy-syntax-reference) + [ ## 标签策略示例 ](#tag-policy-examples) + [ ## 示例 1：定义组织级的标签键大小写 ](#tag-policy-example-key-case) + [ ## 示例 2：防止使用标签键 ](#tag-policy-example-prevent-key) + [ ## 示例 3：为特定 Amazon 服务支持的所有资源类型指定标签策略 ](#tag-policy-example-all-supported) + [ ## 示例 4：强制执行所需的标签密钥以实现合规性 ](#tag-policy-example-required-tags) ## 标签策略语法 标签策略是一个纯文本文件，根据 [JSON](http://json.org) 的规则设置结构。标签策略的语法遵循管理策略类型的语法。有关该语法的完整讨论，请参阅[了解管理策略继承](orgs_manage_policies_inheritance_mgmt.md)。本主题重点介绍如何将该常规语法应用于标签策略类型的特定要求。 以下标签策略显示了基本标签策略语法： ``` { "tags": { "costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@assign": [ "100", "200", "300*" ] }, "enforced_for": { "@@assign": [ "secretsmanager:ALL_SUPPORTED" ] } } } } ``` 标签策略语法包括以下元素： + `tags` 字段键名称。标签策略始终以此固定键名开头。它是上面示例策略中的顶行。 + 唯一标识策略语句的*策略键*。它必须与*标签键* 的值相匹配，除了大小写处理。策略值区分大小写。 在此示例中，`costcenter` 是策略键。 + 至少有一个*标签键*，指定允许的标签键（具有您希望资源遵循的大小写）。如果未定义大小写处理，则标签键的默认大写处理是小写。标签键的值必须与策略键的值匹配。但是，由于策略键值不区分大小写，所以大小写可以不同。 在此示例中，`CostCenter` 是标签键。这是符合标签策略要求所需的大小写处理。为此标签键使用其他大小写处理的资源不符合标签策略要求。 您可以在一个标签策略中定义多个标签键。 + （可选）标签键的一个或多个可接受*标签值* 的列表。如果标签策略没有为标签键指定标签值，则任何值（包括没有值）都将视为合规。 在此示例中，`CostCenter` 标签键的可接受值为 `100`、`200` 和 `300*`。 + （可选）一个 `enforced_for` 选项，指示是否阻止对指定服务和资源执行任何不合规标记操作。在控制台中，这是用于创建标签策略的可视化编辑器中的 **Prevent noncompliant operations for this tag (防止此标签的不合规操作)** 选项。此选项的默认设置为空。 示例标签策略指定应用于所有 Amazon Secrets Manager 资源的`CostCenter`标签必须符合此策略。 **警告** 只有当您具有使用标签策略经验的情况下，才可以更改默认选项。否则，您可能会阻止组织账户中的用户创建他们所需的资源。 + *运算符*指定标记策略如何与组织树中的其他标记策略合并，以创建账户的[有效标签策略](orgs_manage_policies_effective.md)。在此示例中，`@@assign` 用于将字符串分配给 `tag_key`、`tag_value` 和 `enforced_for`。有关运算符的更多信息，请参阅[继承运算符](policy-operators.md)。 + 您可以在标签值中使用 `*` 通配符。 + 您仅可以为每个标签值使用一个通配符。例如，允许使用 `*@example.com`，但不允许使用 `*@*.com`。 + 您可以将`enforced_for`字段中的`ALL_SUPPORTED`通配符与某些服务一起使用，以启用对该服务所有支持的资源的强制执行。有关支持 `enforced_for` 的服务和资源类型的列表，请参阅[支持强制执行的服务和资源类型](orgs_manage_policies_supported-resources-enforcement.md)。 + 您不能使用通配符指定所有服务或指定所有服务的某个资源。 ## 标签策略示例 下面的示例[标签策略](orgs_manage_policies_tag-policies.md) 仅供参考。 **注意** 尝试在组织中使用这些示例标签策略之前，请注意以下事项： 确保您已按照[推荐的工作流](orgs_manage_policies_tag-policies-getting-started.md)开始使用标签策略。 您应根据您的独特要求仔细查看和自定义这些标签策略。 标签策略中的所有字符都受到[最大大小](orgs_reference_limits.md#min-max-values)的约束。本指南中的示例演示了使用额外空白编排格式的标签策略，以提高其可读性。但是，要在策略大小接近最大大小时节省空间，您可以删除任何空白。空白的示例包括引号外部的空格字符和换行符。 未标记的资源不会在结果中显示为不合规。 ## 示例 1：定义组织级的标签键大小写 以下示例显示了一个标签策略，该策略仅定义了两个标签键和您希望组织中的账户标准化所采用的大小写。 **策略 A – 组织根标签策略** ``` { "tags": { "CostCenter": { "tag_key": { "@@assign": "CostCenter", "@@operators_allowed_for_child_policies": ["@@none"] } }, "Project": { "tag_key": { "@@assign": "Project", "@@operators_allowed_for_child_policies": ["@@none"] } } } } ``` 此标签策略定义两个标签键：`CostCenter` 和 `Project`。将此标签策略附加到组织根具有以下效果： + 组织中的所有账户继承此标签策略。 + 组织中的所有账户都必须使用定义的大小写处理以实现合规性。具有 `CostCenter` 和 `Project` 标签的资源符合要求。为标签键（例如，`costcenter`、`Costcenter` 或 `COSTCENTER`）使用其他大小写处理的资源不符合要求。 + `@@operators_allowed_for_child_policies": ["@@none"]` 行锁定标签键。附加在组织树（子策略）下方的标签策略不能使用值设置运算符来更改标签键，包括其大小写处理。 + 对于所有标签策略，不会评估未标记的资源或未在标签策略中定义的标签是否符合标签策略。 Amazon 建议您使用此示例作为指南，为要使用的标签密钥创建类似的标签策略。将其附加到组织根。然后创建类似于下一个示例的标签策略，该策略仅为已定义的标签键定义可接受值。 ### 下一步：定义值 假定您将以前的标签策略附加到组织根。接下来，您可以创建类似于下文的标签策略并将其附加到账户。此策略定义 `CostCenter` 和 `Project` 标签键的可接受值。 **策略 B – 账户标签策略** ``` { "tags": { "CostCenter": { "tag_value": { "@@assign": [ "Production", "Test" ] } }, "Project": { "tag_value": { "@@assign": [ "A", "B" ] } } } } ``` 如果将策略 A 附加到组织根，并将策略 B 附加到账户，则这些策略将合并，以便为该账户创建以下有效标签策略： **策略 A \$1 策略 B = 账户的有效标签策略** ``` { "tags": { "Project": { "tag_value": [ "A", "B" ], "tag_key": "Project" }, "CostCenter": { "tag_value": [ "Production", "Test" ], "tag_key": "CostCenter" } } } ``` 有关策略继承的更多信息，包括继承运算符的工作原理示例和有效标签策略示例，请参阅[了解管理策略继承](orgs_manage_policies_inheritance_mgmt.md)。 ## 示例 2：防止使用标签键 要防止使用标签键，您可以将类似以下内容的标签策略附加到组织实体。 此示例策略指定 `Color` 标签键不接受任何值。它还指定子标签策略中不允许[运算符](policy-operators.md)。因此，受影响账户中的资源上的任何 `Color` 标签都被视为不符合要求。但是，`enforced_for` 选项实际上可防止受影响的账户***仅***使用 `Color` 标签标记 Amazon DynamoDB 表。 ``` { "tags": { "Color": { "tag_key": { "@@operators_allowed_for_child_policies": [ "@@none" ], "@@assign": "Color" }, "tag_value": { "@@operators_allowed_for_child_policies": [ "@@none" ], "@@assign": [] }, "enforced_for": { "@@assign": [ "dynamodb:table" ] } } } } ``` ## 示例 3：为特定 Amazon 服务支持的所有资源类型指定标签策略 要为特定 Amazon 服务的所有支持的资源类型指定标签策略，请使用`ALL_SUPPORTED`通配符。 此策略使用了 `ALL_SUPPORTED` 通配符来指定，所有带有 `Environment` 标签键的 Amazon EC2 实例只能具有 `Prod` 或 `Non-prod` 标签值。此通配符提供了一种有效的单行替代方案，无需单独列出每个 Amazon EC2 实例。有关支持 `ALL_SUPPORTED` 通配符的服务和资源类型的列表，请参阅[支持强制执行的服务和资源类型](orgs_manage_policies_supported-resources-enforcement.md)。 ``` { "tags": { "Environment": { "tag_key": { "@@assign": "Environment", "@@operators_allowed_for_child_policies": ["@@none"] }, "tag_value": { "@@assign": [ "Prod", "Non-prod" ], "@@operators_allowed_for_child_policies": ["@@none"] }, "enforced_for": { "@@assign": [ "ec2:ALL_SUPPORTED" ] } } } } ``` ## 示例 4：强制执行所需的标签密钥以实现合规性 此示例演示如何定义要求所有资源都包含强制合规性标签的标签策略。Organizations 通常使用这种模式来确保适当的成本分配、所有权跟踪和环境识别。 ``` { "tags": { "CostCenter": { "report_required_tag_for": { "@@assign": [ "ec2:instance", "s3:bucket", "rds:db", "lambda:function" ] }, "tag_key": { "@@assign": "CostCenter" } }, "Environment": { "report_required_tag_for": { "@@assign": [ "ec2:ALL_SUPPORTED", "rds:ALL_SUPPORTED", "s3:ALL_SUPPORTED" ] }, "tag_key": { "@@assign": "Environment" }, "tag_value": { "@@assign": [ "Production", "Staging", "Development", "Test" ] } }, "Owner": { "report_required_tag_for": { "@@assign": [ "ec2:ALL_SUPPORTED" ] }, "tag_key": { "@@assign": "Owner" } } } } ``` 当您应用此策略并使用标签策略强制配置您的 IaC 工具时： + CostCenter: EC2 实例、S3 存储桶、RDS 数据库和 Lambda 函数所必需的 + 环境：所有 EC2、RDS 和 S3 资源均为必填项，允许的值仅限于生产、暂存、开发或测试 + 所有者：您组织中的所有 EC2 资源都必须填写 符合此政策的基础设施代码示例： ``` EC2Instance: Type: AWS::EC2::Instance Properties: ImageId: ami-0c02fb55956c7d316 InstanceType: t2.micro Tags: - Key: CostCenter Value: CC-12345 - Key: Environment Value: Test - Key: Owner Value: john.doe@company.com ``` 如果您尝试创建不带所需标签的资源，则根据您的配置，IaC 部署将失败或在规划阶段生成警告。如果配置为失败模式，则在创建任何资源之前会阻止部署。在警告模式下配置时，部署会继续进行，但会提醒您的团队注意缺少的标签。验证错误消息可以准确识别缺少哪些必需的标签以及哪些资源需要它们。 有关您的 iaC 工具的具体配置说明： + **Amazon CloudFormation**: [强制执行 Amazon CloudFormation](enforce-required-tag-keys-iac.md#enforce-with-cloudformation) 要激活标签合规性挂钩，请参阅 + **Terraform**：[使用 Terraform 强制执行](enforce-required-tag-keys-iac.md#enforce-with-terraform)要在提供程序中启用标签策略验证，请参阅 Amazon + **Pulumi**：[使用 Pulumi 强制执行](enforce-required-tag-keys-iac.md#enforce-with-pulumi)要启用 “标签策略报告” 策略包，请参阅 # 识别和修复标签不一致之处 在组织中实施标签策略后，您可以识别带有不合规标签的资源并对其进行修复，以确保整个环境的一致性。 Amazon 本节提供有关发现和更正标记不一致的指导。 **Topics** + [ # 使用资源管理器为您的组织查找未标记和错误标记的资源 ](finding-untagged-mistagged-resources.md) + [ # 更正资源中的不合规标签 ](enforcement-correcting.md) + [ # 使用 Amaz EventBridge on 监控不合规标签 ](orgs_manage_policies_tag-policies-cwe.md) # 使用资源管理器为您的组织查找未标记和错误标记的资源 查找未标记和错误标记的资源 要在您的账户中查找未标记的资源，请 Amazon 资源探索器 与使用的查询一起使用`tag:none`。Resource Explorer 提供全面的搜索功能，可识别组织中缺乏适当标记或标签值不一致的资源。 *有关使用资源管理器查找未标记和错误标记的资源的详细说明，请参阅《用户指南》中的[搜索未标记的资源](https://docs.amazonaws.cn/resource-explorer/latest/userguide/using-search-query-examples.html#example-1)。Amazon 资源探索器 * # 更正资源中的不合规标签 更正资源中的不合规标签 找到不符合标签后，请使用以下任意方法进行更正。您必须登录到具有不合规标签的资源的账户： + 使用创建不合规资源的 Amazon 服务的控制台或标记 API 操作。 + 使用 Amazon Resource Groups [TagResources](https://docs.amazonaws.cn/resourcegroupstagging/latest/APIReference/API_TagResources.html)和[UntagResources](https://docs.amazonaws.cn/resourcegroupstagging/latest/APIReference/API_UntagResources.html)操作添加符合有效策略的标签或删除不合规的标签。 # 使用 Amaz EventBridge on 监控不合规标签 您可以使用亚马逊 EventBridge（前身为 Amazon E CloudWatch vents）来监控何时引入了不合规标签。在以下示例事件中，`tag-policy-compliant` 的 `"false"` 值表示新标签不符合有效标签策略。 ``` { "detail-type": "Tag Change on Resource", "region": "us-east-1", "resources": [ "arn:aws:ec2:us-east-1:123456789012:instance/i-0000000aaaaaaaaaa" ], "detail": { "changed-tag-keys": [ "a-new-key" ], "service": "ec2", "resource-type": "instance", "version": 3, "tag-policy-compliant": "false", "tags": { "a-new-key": "tag-value-on-new-key-just-added" } } } ``` 您可以订阅事件并指定要监控的字符串或模式。有关的更多信息 EventBridge，请参阅 *[Amazon EventBridge 用户指南](https://docs.amazonaws.cn/eventbridge/latest/userguide/)*。 # 支持强制执行的服务和资源类型 以下服务和资源类型支持使用标签策略强制执行： [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_supported-resources-enforcement.html) + 有关 [Terraform Provider 中的资源类型支持，请参阅 Ter Amazon raform 文档](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/guides/tag-policy-compliance)。 + 有关 [Pulumi Cloud 中的资源类型支持，请参阅 Pulumi 文档](https://www.pulumi.com/docs/insights/policy/integrations/aws-organizations-tag-policies/#aws-provider-types)。 # 支持的区域： 标签策略功能在以下区域中可用： | 区域名称 | 区域参数 | | --- | --- | | 美国东部（弗吉尼亚北部）区域¹ | **`us-east-1`** | | 美国东部（俄亥俄州）区域 | `us-east-2` | | 美国西部（北加利福尼亚）区域 | `us-west-1` | | 美国西部（俄勒冈州）区域 | `us-west-2` | | 非洲（开普敦）区域² | `af-south-1` | | 亚太地区（香港）区域² | `ap-east-1` | | 亚太地区（台北）² | `ap-east-2` | | 亚太地区（孟买）区域 | `ap-south-1` | | 亚太地区（海得拉巴）² | `ap-south-2` | | 亚太地区（东京）区域 | `ap-northeast-1` | | 亚太地区（首尔）区域 | `ap-northeast-2` | | 亚太地区（大阪）区域 | `ap-northeast-3` | | 亚太地区（新加坡）区域 | `ap-southeast-1` | | 亚太地区（悉尼）区域 | `ap-southeast-2` | | 亚太地区（雅加达）区域² | `ap-southeast-3` | | 亚太地区（墨尔本）² | `ap-southeast-4` | | 亚太地区（马来西亚）区域 | `ap-southeast-5` | | 亚太地区（新西兰）² | `ap-southeast-6` | | 亚太地区（泰国） | `ap-southeast-7` | | 加拿大（中部）区域 | `ca-central-1` | | 加拿大西部（卡尔加里）² | `ca-west-1` | | 中国（北京）区域 | `cn-north-1` | | 中国（宁夏）区域 | `cn-northwest-1` | | 欧洲地区（法兰克福）区域 | `eu-central-1` | | 欧洲（苏黎世）² | `eu-central-2` | | 欧洲（米兰）区域² | `eu-south-1` | | 欧洲（西班牙）² | `eu-south-2` | | 欧洲地区（爱尔兰）区域 | `eu-west-1` | | 欧洲地区（伦敦）区域 | `eu-west-2` | | 欧洲（巴黎）区域 | `eu-west-3` | | 欧洲地区（斯德哥尔摩）区域 | `eu-north-1` | | 墨西哥（中部）区域 | `mx-central-1` | | 中东（阿联酋）区域² | `me-central-1` | | 中东（巴林）区域² | `me-south-1` | | 南美洲（圣保罗）区域 | `sa-east-1` | | 以色列（特拉维夫）² | `il-central-1` | | Amazon GovCloud （美国东部） | `us-gov-east-1` | | Amazon GovCloud （美国西部） | `us-gov-west-1` | **¹调用以下 Organizations 操作时必须指定 `us-east-1` 区域：** + [DeletePolicy](https://docs.amazonaws.cn/organizations/latest/APIReference/API_DeletePolicy.html) + [DisablePolicyType](https://docs.amazonaws.cn/organizations/latest/APIReference/API_DisablePolicyType.html) + [EnablePolicyType](https://docs.amazonaws.cn/organizations/latest/APIReference/API_EnablePolicyType.html) + 对组织根目录进行的任何其他操作，例如[ListRoots](https://docs.amazonaws.cn/organizations/latest/APIReference/API_ListRoots.html)。 **调用以下作为标签策略功能一部分的 Resource Groups 标记 API 操作时，您也必须指定 `us-east-1` 区域：** + [DescribeReportCreation](https://docs.amazonaws.cn/resourcegroupstagging/latest/APIReference/API_DescribeReportCreation.html) + [GetComplianceSummary](https://docs.amazonaws.cn/resourcegroupstagging/latest/APIReference/API_GetComplianceSummary.html) + [StartReportCreation](https://docs.amazonaws.cn/resourcegroupstagging/latest/APIReference/API_StartReportCreation.html) **注意** 要评估组织范围的标签策略合规性，您还必须能够访问美国东部（弗吉尼亚北部）区域中的 Amazon S3 存储桶以进行报告存储。有关更多信息，请参阅《*标记 Amazon 资源用户指南》*[中的 Amazon S3 存储桶报告存储策略](https://docs.amazonaws.cn/ARG/latest/userguide/tag-policies-prereqs.html#bucket-policy)。 ² 这些区域必须手动启用。要了解有关启用和禁用 Amazon Web Services 区域的更多信息，请参阅《Amazon 账户管理参考指南》**中的 [Specify which Amazon Web Services 区域 your account can use](https://docs.amazonaws.cn/accounts/latest/reference/manage-acct-regions.html)。在这些区域中，Resource Groups 控制台不可用。 # 聊天应用程序政策 中的聊天应用程序策略 Amazon Organizations 使您可以控制聊天应用程序（例如 Slack 和 Microsoft Teams）对组织帐户的访问权限。 [聊天应用程序中的 Amazon Q](https://docs.amazonaws.cn/chatbot/latest/adminguide/what-is.html) Developer 是一项 Amazon 服务，它使 DevOps 软件开发团队能够使用消息传递程序聊天室来监控和响应其中的操作事件 Amazon Web Services 云。聊天应用程序中的 Amazon Q Developer 会处理来自亚马逊简单通知服务 (Amazon SNS) Simple Notification Service 的 Amazon Web Services 服务 通知，然后将其转发到聊天室，这样团队就可以随时对其进行分析并采取行动，无论身在何处。 ## 聊天应用程序政策的工作原理 使用聊天应用程序政策时，组织的管理账户或委派管理员可以在整个组织中执行以下操作： + 强制可以使用哪些受支持的聊天应用程序（Amazon Chime、Microsoft Teams 和 Slack）。 + 将聊天客户端的访问权限范围限定为具体的工作区（Slack）和团队（Microsoft Teams）。 + 将 Slack 频道的可见性限制为公有或私有频道。 + 设置和强制执行特定的[角色设置](https://docs.amazonaws.cn/chatbot/latest/adminguide/understanding-permissions.html#role-settings)。 聊天应用程序政策会限制并优先于账户级别的设置，例如[角色设置](https://docs.amazonaws.cn/chatbot/latest/adminguide/understanding-permissions.html#role-settings)和[频道护栏策略](https://docs.amazonaws.cn/chatbot/latest/adminguide/understanding-permissions.html#channel-guardrails)。您可以从聊天应用程序中的 Amazon Q 开发者版或 Organizations 控制台访问和修改聊天应用程序政策。 将策略附加到账户和组织单元（OU）后，范围内账户的任何当前和未来聊天应用程序中的 Amazon Q 开发者版配置都将自动遵守治理和权限设置。有关更多信息，请参阅[了解管理策略继承](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_inheritance_mgmt.html)。 如果您尝试执行受聊天应用程序政策限制的操作，则会显示一条错误消息，通知您聊天应用程序政策不允许执行该操作，并建议您联系组织的管理账户或委派管理员。 **注意** 聊天应用程序政策在运行时进行验证。这意味着要持续检查现有资源的合规性。目前不支持将基于运行时的 IAM 权限用于发送通知或与聊天应用程序中的 Amazon Q 开发者版进行交互，因此与现有的 IAM 权限没有重叠。 # 聊天应用程序政策入门 开始使用 请按照以下步骤开始使用聊天应用程序政策。 1. [了解执行聊天应用程序政策任务所必须具备的权限](orgs_manage_policies_prereqs.md)。 1. [为组织启用聊天应用程序政策](enable-policy-type.md)。 1. [创建聊天应用程序政策](orgs_policies_create.md)。 1. [将聊天应用程序政策附加到组织的根、OU 或账户](orgs_policies_attach.md)。 1. [查看应用于账户的合并有效聊天应用程序政策](orgs_manage_policies_effective.md)。 对于上述所有步骤，您必须以 IAM 用户的身份登录，担任 IAM 角色，或在组织的管理账户中以根用户的身份登录（[不推荐](https://docs.amazonaws.cn/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)）。 **其他信息** + [了解聊天应用程序政策语法并查看示例策略](orgs_manage_policies_chatbot_syntax.md) # 聊天应用程序政策语法和示例 本主题将介绍聊天应用程序政策语法并提供示例。 ## 聊天应用程序政策的语法 聊天应用程序政策是一个纯文本文件，根据 [JSON](http://json.org) 的规则设置结构。聊天应用程序政策的语法遵循管理策略类型的语法。有关该语法的完整讨论，请参阅[了解管理策略继承](orgs_manage_policies_inheritance_mgmt.md)。本主题重点介绍如何使用该常规语法来满足聊天应用程序政策类型的特定要求。 以下示例展示了聊天应用程序政策的基本语法： ``` { "chatbot":{ "platforms":{ "slack":{ "client":{ "@@assign":"enabled" // enabled | disabled }, "workspaces": { // limit 255 "@@assign":[ "Slack-Workspace-Id" ] }, "default":{ "supported_channel_types":{ "@@assign":[ "private" // public | private ] }, "supported_role_settings":{ "@@assign":[ "user_role" // user_role | channel_role ] } }, "overrides":{ // limit 255 "Slack-Workspace-Id":{ "supported_channel_types":{ "@@assign":[ "public" // public | private ] }, "supported_role_settings":{ "@@assign":[ "user_role" // user_role | channel_role ] } } } }, "microsoft_teams":{ "client":{ "@@assign":"enabled" }, "tenants":{ // limit 36 "Microsoft-Teams-Tenant-Id":{ // limit 36 "@@assign":[ "Microsoft-Teams-Team-Id" ] } }, "default":{ "supported_role_settings":{ "@@assign":[ "user_role" // user_role | channel_role ] } }, "overrides":{ // limit 36 "Microsoft-Teams-Tenant-Id":{ // limit 36 "Microsoft-Teams-Team-Id":{ "supported_role_settings":{ "@@assign":[ "user_role" // user_role | channel_role ] } } } } }, "chime":{ "client":{ "@@assign":"disabled" // enabled | disabled } } }, "default":{ "client":{ "@@assign":"disabled" // enabled | disabled } } } } ``` 此聊天应用程序政策包含以下元素： + `chatbot` 字段键名称。聊天应用程序政策始终以此固定键名称开头。这是此示例策略中的第一行。 + 在 `chatbot` 下有一个 `platforms` 块，其中包含不同受支持聊天应用程序的配置：Slack、Microsoft Teams 和 Amazon Chime。 + 对于 Slack，有以下字段可用： + `"client"`: + `"enabled"`：Slack 客户端已启用。允许 Slack 集成。 + `"disabled"`：Slack 客户端已禁用。不允许 Slack 集成。 + `"workspaces"`：允许的 Slack 工作区列表，以逗号分隔。在此示例中，允许的 Slack 工作区为和。*Slack-Workspace-Id1* *Slack-Workspace-Id2* + `"default"`：Slack 工作区的默认设置。 + `"supported_channel_types"`: + `"public"`：默认情况下，范围内的 Slack 工作区会允许公有 Slack 频道。 + `"private"`：默认情况下，范围内的 Slack 工作区会允许私有 Slack 频道。 + `supported_role_settings`: + `"user_role"`: 默认情况下，范围内的 Slack 工作区会允许用户级别的 IAM 角色。 + `"channel_role"`: 默认情况下，范围内的 Slack 工作区会允许频道级别的 IAM 角色。 + `"overrides"`：Slack 工作区的覆盖设置。 + `Slack-Workspace-Id2`：适用覆盖设置的 Slack 工作区列表，以逗号分隔。在此示例中，Slack 工作空间为*Slack-Workspace-Id2*。 + `"supported_channel_types"`: + `"public"`：覆盖有关范围内的 Slack 工作区是否允许公有 Slack 频道的设置。 + `"private"`：覆盖有关范围内的 Slack 工作区是否允许私有 Slack 频道的设置。 + `supported_role_settings`: + `"user_role"`：覆盖范围内的 Slack 工作区是否允许用户级别的 IAM 角色的设置。 + `"channel_role"`：覆盖范围内的 Slack 工作区是否允许频道级别的 IAM 角色的设置。 + 对于 Microsoft Teams，有以下字段可用： + `"client"`: + `"enabled"`：Microsoft Teams 客户端已启用。允许 Microsoft Teams 集成。 + `"disabled"`：Microsoft Teams 客户端已禁用。不允许 Microsoft Teams 集成。 + `"tenants"`：允许的 Microsoft Teams 租户列表，以逗号分隔。在此示例中，允许的租户是*Microsoft-Teams-Tenant-Id*。 + `Microsoft-Teams-Tenant-Id`：该租户内允许的团队列表，以逗号分隔。在此示例中，允许的队伍是*Microsoft-Teams-Team-Id*。 + `"default"`：该租户内团队的默认设置。 + `supported_role_settings`: + `"user_role"`：默认情况下，范围内的团队会允许用户级别的 IAM 角色。 + `"channel_role"`：默认情况下，范围内的团队会允许频道级别的 IAM 角色。 + `"overrides"`：Microsoft Teams 租户的覆盖设置。 + `Microsoft-Teams-Tenant-Id`：适用覆盖设置的租户列表，以逗号分隔。在此示例中，租户是*Microsoft-Teams-Tenant-Id*。 + `Microsoft-Teams-Team-Id`：该租户内的团队列表，以逗号分隔。在此示例中，允许的队伍是*Microsoft-Teams-Team-Id*。 + `supported_role_settings`: + `"user_role"`：覆盖范围内的团队是否允许用户级别的 IAM 角色的设置。 + `"channel_role"`：覆盖范围内的团队是否允许频道级别的 IAM 角色的设置。 + 对于 Amazon Chime，有以下字段可用： + `"client"`: + `"enabled"`：Amazon Chime 客户端已启用。允许 Amazon Chime 集成。 + `"disabled"`：Amazon Chime 客户端已禁用。不允许 Amazon Chime 集成。 + 在 `chatbot` 下有一个 `default` 块，除非在更低级别被覆盖，否则该块会在整个组织中禁用聊天应用程序中的 Amazon Q 开发者版。此默认设置还会禁用聊天应用程序中的 Amazon Q 开发者版支持的任何新聊天应用程序。例如，假设聊天应用程序中的 Amazon Q 开发者版支持某个新聊天应用程序，则此默认设置也会禁用该新受支持的聊天应用程序。 **注意** 有关频道级别 IAM 角色和用户级别 IAM 角色的更多信息，请参阅《Amazon Q Developer in chat applications Administrator Guide》**中的 [Understanding Amazon Q Developer in chat applications permissions](https://docs.amazonaws.cn/chatbot/latest/adminguide/understanding-permissions.html)。 ## 聊天应用程序政策示例 下面的示例策略仅供参考。 ### 示例 1：仅允许特定工作区内的私有 Slack 频道，禁用 Microsoft Teams，支持所有身份验证模式 以下策略侧重于控制 Slack 和 Microsoft Teams 聊天机器人集成的允许配置。 ``` { "chatbot": { "platforms": { "slack": { "client": { "@@assign": "enabled" }, "workspaces": { "@@assign": [ "Slack-Workspace-Id" ] }, "default": { "supported_channel_types": { "@@assign": [ "private" ] }, "supported_role_settings": { "@@assign": [ "channel_role", "user_role" ] } } }, "microsoft_teams": { "client": { "@@assign": "disabled" } }, "chime":{ "client":{ "@@assign":"disabled" } }, "default":{ "client":{ "@@assign":"disabled" } } } } } ``` **Slack** + Slack 客户端已启用。 + 只允许使用特定的 Slack 工作空间*Slack-Workspace-Id*。 + 默认设置为仅允许私有 Slack 频道、频道级别 IAM 角色和用户级别 IAM 角色。 **Microsoft Teams** + Microsoft Teams 客户端已禁用。 **Amazon Chime** + Amazon Chime 客户端已禁用。 **其他详细信息** + 底部的 `default` 块将客户端设置为禁用，除非在更低级别被覆盖，否则将在整个组织中禁用聊天应用程序中的 Amazon Q 开发者版。此默认设置还会禁用聊天应用程序中的 Amazon Q 开发者版支持的任何新聊天应用程序。例如，假设聊天应用程序中的 Amazon Q 开发者版支持某个新聊天应用程序，则此默认设置也会禁用该新受支持的聊天应用程序。 ### 示例 2：仅允许使用用户级别 IAM 角色的 Slack 集成 以下策略对 Slack 采取更宽松的方法，允许所有 Slack 工作区，但将身份验证模式限定为仅限用户级别 IAM 角色。 ``` { "chatbot":{ "platforms":{ "slack":{ "client":{ "@@assign":"enabled" }, "workspaces": { "@@assign":[ "*" ] }, "default":{ "supported_role_settings":{ "@@assign":[ "user_role" ] } } }, "microsoft_teams":{ "client":{ "@@assign":"disabled" } }, "chime":{ "client":{ "@@assign":"disabled" } } }, "default":{ "client":{ "@@assign":"disabled" } } } } ``` **Slack** + Slack 客户端已启用。 + 没有使用通配符 `"*"` 定义任何特定的 Slack 工作区，因此允许使用所有工作区。 + 默认设置为仅允许用户级别 IAM 角色。 **Microsoft Teams** + Microsoft Teams 客户端已禁用。 **Amazon Chime** + Amazon Chime 客户端已禁用。 **其他详细信息** + 底部的 `default` 块将客户端设置为禁用，除非在更低级别被覆盖，否则将在整个组织中禁用聊天应用程序中的 Amazon Q 开发者版。此默认设置还会禁用聊天应用程序中的 Amazon Q 开发者版支持的任何新聊天应用程序。例如，假设聊天应用程序中的 Amazon Q 开发者版支持某个新聊天应用程序，则此默认设置也会禁用该新受支持的聊天应用程序。 ### 示例 3：仅允许特定租户中的 Microsoft Teams 集成 以下示例策略将组织锁定，从而仅允许指定租户内的 Microsoft Teams 聊天机器人集成，同时完全阻止 Slack 集成。 ``` { "chatbot":{ "platforms":{ "slack":{ "client": { "@@assign": "disabled" }, }, "microsoft_teams":{ "client": { "@@assign": "enabled" }, "tenants":{ "Microsoft-Teams-Tenant-Id":{ "@@assign":[ "*" ] } } }, "chime": { "client":{ "@@assign": "disabled" } } } } } ``` **Slack** + Slack 客户端已禁用。 **Microsoft Teams** + *Microsoft-Teams-Tenant-Id*仅允许特定租户，使用通配符`"*"`允许该租户中的所有团队。 **Amazon Chime** + Amazon Chime 客户端已禁用。 **其他详细信息** + 底部的 `default` 块将客户端设置为禁用，除非在更低级别被覆盖，否则将在整个组织中禁用聊天应用程序中的 Amazon Q 开发者版。此默认设置还会禁用聊天应用程序中的 Amazon Q 开发者版支持的任何新聊天应用程序。例如，假设聊天应用程序中的 Amazon Q 开发者版支持某个新聊天应用程序，则此默认设置也会禁用该新受支持的聊天应用程序。 ### 示例 4：允许聊天应用程序中的 Amazon Q 开发者版对 Slack 工作区和 Microsoft Teams 租户进行受限访问 以下策略允许聊天应用程序中的 Amazon Q 开发者版对选定的 Slack 工作区和 Microsoft Teams 租户进行受限访问。 ``` { "chatbot":{ "platforms":{ "slack":{ "client":{ "@@assign":"enabled" }, "workspaces": { "@@assign":[ "Slack-Workspace-Id1", "Slack-Workspace-Id2" ] }, "default":{ "supported_channel_types":{ "@@assign":[ "private" ] }, "supported_role_settings":{ "@@assign":[ "user_role" ] } }, "overrides":{ "Slack-Workspace-Id2":{ "supported_channel_types":{ "@@assign":[ "public", "private" ] }, "supported_role_settings":{ "@@assign":[ "channel_role", "user_role" ] } } } }, "microsoft_teams":{ "client":{ "@@assign":"enabled" }, "tenants":{ "Microsoft-Teams-Tenant-Id":{ "@@assign":[ "Microsoft-Teams-Team-Id" ] } }, "default":{ "supported_role_settings":{ "@@assign":[ "user_role" ] } }, "overrides":{ "Microsoft-Teams-Tenant-Id":{ "Microsoft-Teams-Team-Id":{ "supported_role_settings":{ "@@assign":[ "channel_role", "user_role" ] } } } } } }, "default":{ "client":{ "@@assign":"disabled" } } } } ``` **Slack** + Slack 客户端已启用。 + 允许的 Slack 工作区是和。*Slack-Workspace-Id1* *Slack-Workspace-Id2* + Slack 的默认设置为仅允许私有频道和用户级别 IAM 角色。 + 工作空间有一个替代项*Slack-Workspace-Id2*，允许公共和私有渠道以及频道级别 IAM 角色和用户级 IAM 角色。 **Microsoft Teams** + Microsoft Teams 客户端已启用。 + 允许的 Team *Microsoft-Teams-Tenant-Id* s 租户加入团队*Microsoft-Teams-Team-Id*。 + 默认设置为仅允许用户级别 IAM 角色。 + 租户有一个替代项*Microsoft-Teams-Tenant-Id*，允许团队同时使用频道级别 IAM 角色和用户级 IAM 角色*Microsoft-Teams-Team-Id*。 **其他详细信息** + 底部的 `default` 块将客户端设置为禁用，除非在更低级别被覆盖，否则将在整个组织中禁用聊天应用程序中的 Amazon Q 开发者版。这意味着此示例中禁用了 Amazon Chime。此默认设置还会禁用聊天应用程序中的 Amazon Q 开发者版支持的任何新聊天应用程序。例如，假设聊天应用程序中的 Amazon Q 开发者版支持某个新聊天应用程序，则此默认设置也会禁用该新受支持的聊天应用程序。 # AI 服务选择退出策略 Amazon AI 服务可能会使用和存储客户内容来改进服务，例如修复运营问题、评估服务性能、调试或模型训练。为此，我们可能会将此类内容存储在您使用服务的地点 Amazon Web Services 区域 以外 Amazon Web Services 区域 的地方。您可以使用选择退出政策 Amazon Organizations 选择不使用您的内容来改善服务。 您可以为单个人工智能服务或人工智能服务退出政策支持的所有服务创建退出策略。您还可以查询适用于每个账户的有效策略，以查看设置选择的效果。 有关更多详细信息，请参阅服务条款中的 M [Amazon achine Learning 和人工智能 Amazon 服务](https://www.amazonaws.cn/service-terms)。有关人工智能服务退出政策支持的服务列表，请参阅[支持的人工智能服务列表](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_ai-opt-out_all.html#ai-opt-out-all-list)。 **Topics** + [注意事项](#orgs_manage_policies-ai-opt-out-considerations) + [开始使用](orgs_manage_policies-ai-opt-out_getting-started.md) + [选择退出所有 AI 服务](orgs_manage_policies_ai-opt-out_all.md) + [ # AI 服务选择退出策略语法和示例 ](orgs_manage_policies_ai-opt-out_syntax.md) ## 使用 AI 服务选择退出策略时的注意事项 注意事项 **选择退出会删除所有相关的历史内容** 当您选择不让 Amazon AI 服务使用内容时，该服务会删除在您设置该选项 Amazon 之前与之共享的所有关联历史内容。此删除仅限于对提供服务功能非必需的已存储内容。 例如，当您选择加入时使用某项服务，该服务可能会存储您的内容副本用于服务改进。当您选择退出时，为此目的而由服务存储的所有副本都将被删除，但用于向您提供服务的任何内容都不会被删除。 # AI 服务选择退出策略入门 开始使用 请按照以下步骤操作，开始使用人工智能（AI）服务选择退出策略。 1. [了解执行备份策略任务所必须具备的权限](orgs_manage_policies_prereqs.md)。 1. [为您的组织启用 AI 服务选择退出策略](enable-policy-type.md)。 1. [创建 AI 服务选择退出策略](orgs_policies_create.md#create-ai-opt-out-policy-procedure)。 1. [将 AI 服务选择退出策略附加到组织根、OU 或账户](orgs_policies_attach.md)。 1. [查看应用于账户的合并的有效 AI 服务选择退出策略](orgs_manage_policies_effective.md)。 在所有这些步骤中，您可以以 Amazon Identity and Access Management (IAM) 用户身份登录、担任 IAM 角色或以根用户身份登录（[不推荐](https://docs.amazonaws.cn/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)）在组织的管理账户中登录。 **其他信息** + [了解 AI 服务选择退出策略的策略语法，并查看策略示例](orgs_manage_policies_ai-opt-out_syntax.md) # 选择退出所有支持的 Amazon AI 服务 选择退出所有 AI 服务 **本主题内容：** + 您可以在 Amazon Organizations 控制台中通过一键选择来选择退出。 + 您可以通过使用 Amazon CLI & Amazon SDKs 附加提供的示例策略来选择退出。 + 您可以查看 AI 服务选择退出政策 Amazon Web Services 服务 支持的列表。 ## 选择退出所有支持的 AI 服务 选择退出所有 AI 服务 您可以通过创建并附加 AI 服务选择退出策略，来选择不将其内容用于服务改进。此政策适用于所有当前和将来支持的 Amazon AI 服务。成员账户无法更新此策略。 ------ #### [ Amazon Web Services 管理控制台 ] **选择退出所有 AI 服务** 1. 登录 [Amazon Organizations 控制台](https://console.amazonaws.cn/organizations/v2)。您必须以 IAM 用户的身份登录，担任 IAM 角色；或在组织的管理账户中以根用户的身份登录（[不推荐](https://docs.amazonaws.cn/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)）。 1. 在 **[AI 服务选择退出策略](https://console.amazonaws.cn/organizations/v2/home/policies/aiservices-opt-out-policy)**页面上，选中**选择退出所有服务**。 1. 在**选择退出所有服务**确认页面上，选中**选择退出所有服务**。 ------ #### [ Amazon CLI & Amazon SDKs ] **选择退出所有 AI 服务** 1. 复制 [AI 服务选择退出示例](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_ai-opt-out_syntax.html#ai-opt-out-policy-examples)中的“示例 1：选择退出组织中所有账户的所有 AI 服务”。 1. 按照[附加和分离 AI 服务选择退出](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_ai-opt-out_attach.html)中的说明进行操作。 ------ **注意** 选择退出 Amazon Monitron 需要执行额外的步骤。有关更多信息，请参阅 [Amazon 服务条款](https://www.amazonaws.cn/service-terms/#81._Industrial_AI_Services)。 ## AI 服务选择退出策略支持的服务列表 支持的 AI 服务列表 以下是 AI 服务选择退出政策 Amazon Web Services 服务 支持的列表： + [Amazon AI 操作](https://www.amazonaws.cn/what-is/aiops) + [Amazon Chime SDK 语音分析](https://docs.amazonaws.cn/chime-sdk/latest/dg/voice-analytics.html) + [Amazon CloudWatch](https://docs.amazonaws.cn/cloudwatch) + [Amazon P CodeGuru rofiler](https://docs.amazonaws.cn/codeguru) + [亚马逊 CodeWhisperer](https://docs.amazonaws.cn/codewhisperer)（现在是 [Amazon Q 开发者](https://docs.amazonaws.cn/amazonq)的一部分） + [Amazon Comprehend](https://docs.amazonaws.cn/comprehend) + [Amazon Connect](https://docs.amazonaws.cn/connect) + [Amazon Connect Optimization](https://docs.amazonaws.cn/connect) + [Amazon Connect Contact Lens](https://docs.amazonaws.cn/connect/latest/adminguide/contact-lens.html) + [Amazon 数据库迁移服务](https://docs.amazonaws.cn/dms) + [亚马逊 DataZone](https://docs.amazonaws.cn/datazone)（和[亚马逊 SageMaker 数据代理](https://docs.amazonaws.cn/sagemaker-unified-studio/latest/userguide/sagemaker-data-agent.html)） + [Amazon DevOps 代理](https://docs.amazonaws.cn/devopsagent/latest/userguide/about-aws-devops-agent.html) + [Amazon Entity Resolution 数据匹配服务](https://docs.amazonaws.cn/entityresolution) + [Amazon Fraud Detector](https://docs.amazonaws.cn/frauddetector) + [Amazon Glue](https://docs.amazonaws.cn/glue) + [Amazon GuardDuty](https://docs.amazonaws.cn/guardduty) + [Amazon Lex](https://docs.amazonaws.cn/lex) + [Amazon Polly](https://docs.amazonaws.cn/polly) + [Amazon Q](https://docs.amazonaws.cn/amazonq) + [Amazon Quick](https://docs.amazonaws.cn/quicksight) + [Amazon Rekognition](https://docs.amazonaws.cn/rekognition) + [Amazon Security Lake](https://docs.amazonaws.cn/security-lake/) + [Amazon Supply Chain](https://docs.amazonaws.cn/aws-supply-chain) + [Amazon Textract](https://docs.amazonaws.cn/textract) + [Amazon Transcribe](https://docs.amazonaws.cn/transcribe) + [Amazon 转换](https://docs.amazonaws.cn/transform/latest/userguide/what-is.html) + [Amazon Translate](https://docs.amazonaws.cn/translate) + [Amazon WorkSpaces](https://docs.amazonaws.cn/workspaces) + [Amazon Security Hub](https://docs.amazonaws.cn/securityhub) # AI 服务选择退出策略语法和示例 本主题介绍人工智能（AI）服务选择退出策略语法并提供示例。 ## AI 服务选择退出策略的语法 AI 服务选择退出策略是一个纯文本文件，根据 [JSON](http://json.org) 的规则设置结构。AI 服务选择退出策略的语法遵循管理策略类型的语法。有关该语法的完整讨论，请参阅[了解管理策略继承](orgs_manage_policies_inheritance_mgmt.md)。本主题重点介绍如何将该常规语法应用于 AI 服务选择退出策略类型的特定要求。 **重要** 本部分中讨论的值的大写十分重要。使用大写和小写字母输入值，如本主题所示。如果您使用意外的大写，则策略不起作用。 以下策略显示了基本的 AI 服务选择退出策略语法。如果此示例直接附加到账户，则该账户将被明确选择退出一个服务，然后选择启用另一个服务。从更高级别（OU 或根策略）继承的策略可以选择启用或选择退出其他服务。 ``` { "services": { "rekognition": { "opt_out_policy": { "@@assign": "optOut" } }, "lex": { "opt_out_policy": { "@@assign": "optIn" } } } } ``` 设想附加到组织根的以下策略示例。它设置组织选择退出所有 AI 服务的默认设置。这将自动包括任何未明确豁免的 AI 服务，包括 Amazon 可能会在以后部署的任何 AI 服务。您可以将子女政策附加到账户， OUs 也可以直接将子政策附加到账户，以覆盖除Amazon Comprehend之外的任何 AI 服务的此设置。以下示例中的第二个条目使用 `@@operators_allowed_for_child_policies` 将该设置设为 `none` 以防止覆盖。示例中的第三个条目在整个组织范围内为 Amazon Rekognition 提供豁免。它在整个组织中选择启用该服务，但策略确实允许在适当的情况下覆盖子策略。 ``` { "services": { "default": { "opt_out_policy": { "@@assign": "optOut" } }, "comprehend": { "opt_out_policy": { "@@operators_allowed_for_child_policies": ["@@none"], "@@assign": "optOut" } }, "rekognition": { "opt_out_policy": { "@@assign": "optIn" } } } } ``` AI 服务选择退出策略语法包括以下元素： + `services` 元素。AI 服务选择退出策略由此固定名称标识为最外层包含元素的 JSON。 AI 服务选择退出策略可以在 `services` 元素下拥有一个或多个语句。每个语句包含以下元素： + 标识 Amazon AI *服务的服务名称密钥*。以下键名称是此字段的有效值： + **`default`** – 代表**所有**当前可用的 AI 服务，并隐式和自动包括将来可能添加的任何 AI 服务。 + `aiops` + `aidevops` + `awssupplychain` + `chimesdkvoiceanalytics` + `cloudwatch` + `codeguruprofiler` + `codewhisperer` + `comprehend` + `connect` + `connectamd` + `connectoptimization` + `contactlens` + `datazone` + `dms` + `entityresolution` + `frauddetector` + `glue` + `guardduty` + `lex` + `polly` + `q` + `quicksightq` + `rekognition` + `securitylake` + `textract` + `transcribe` + `transform` + `translate` + `workspaces` + `securityhub` 由服务名称键标识的每个策略语句都可以包含以下元素： + `opt_out_policy` 密钥。此键必须存在。这是您可以放置在服务名称键下的唯一键。 `opt_out_policy` 键***仅***包含具有以下值之一的 `@@assign` 运算符： + `optOut` – 您可以选择退出指定 AI 服务的内容使用。 + `optIn` – 您可以选择启用指定 AI 服务的内容使用。 **注意** 您不能在 AI 服务选择退出策略中使用 `@@append` 和 `@@remove` 继承运算符。 您不能在 AI 服务选择退出策略中使用 `@@enforced_for` 运算符。 + 在任何级别上，您都可以指定 `@@operators_allowed_for_child_policies` 运算符来控制子策略可以执行哪些操作来覆盖父策略施加的设置。可以指定以下值之一： + `@@assign` – 此策略的子策略可以通过 `@@assign` 运算符使用其他值来覆盖继承值。 + `@@none` – 此策略的子策略不能更改该值。 `@@operators_allowed_for_child_policies` 的行为取决于您放置它的位置。您可以使用以下位置： + `services` 键下 – 控制子策略是否可以添加或更改有效策略中的服务列表。 + 在特定 AI 服务的键或 `default` 键下 – 控制子策略是否可以添加或更改此特定条目下的键列表。 + 特定服务的 `opt_out_policies` 键下 – 控制子策略是否只能更改此特定服务的设置。 ## AI 服务选择退出策略示例 下面的示例策略仅供参考。 ### 示例 1：选择退出组织中所有账户的所有 AI 服务 以下示例显示了一个策略，您可以将该策略附加到组织的根，以选择退出组织中的账户的 AI 服务。 **提示** 如果您使用示例右上角的复制按钮复制以下示例，则副本不包括行号。它已准备好粘贴。 ``` | { | "services": { [1] | "@@operators_allowed_for_child_policies": ["@@none"], | "default": { [2] | "@@operators_allowed_for_child_policies": ["@@none"], | "opt_out_policy": { [3] | "@@operators_allowed_for_child_policies": ["@@none"], | "@@assign": "optOut" | } | } | } | } ``` + [1] – `services` 下的 `"@@operators_allowed_for_child_policies": ["@@none"]` 会阻止任何子策略为单个服务添加除已存在 `default` 部分之外的任何新部分。`Default` 是表示“所有 AI 服务”的占位符。 + [2] – `default` 下的 `"@@operators_allowed_for_child_policies": ["@@none"]` 会阻止任何子策略添加除已存在 `opt_out_policy` 部分之外的任何新部分。 + [3] – `opt_out_policy` 下的 `"@@operators_allowed_for_child_policies": ["@@none"]` 会阻止子策略更改 `optOut` 设置的值或添加任何其他设置。 ### 示例 2：为所有服务设置组织默认设置，但允许子策略覆盖单个服务的设置 以下示例策略为所有 AI 服务设置了组织范围内的默认设置。`default` 的值阻止子策略更改 `optOut` 服务的 `default` 值，它是所有 AI 服务的占位符。如果通过将此策略附加到根策略或 OU 而将其作为父策略应用，则子策略仍然可以更改单个服务的选择退出设置，如第二个策略所示。 + 因为 `services` 键没有 `"@@operators_allowed_for_child_policies": ["@@none"]`，子策略可以为单个服务添加新部分。 + `default` 下的 `"@@operators_allowed_for_child_policies": ["@@none"]` 会阻止任何子策略添加除已存在 `opt_out_policy` 部分之外的任何新部分。 + `opt_out_policy` 下的 `"@@operators_allowed_for_child_policies": ["@@none"]` 会阻止子策略更改 `optOut` 设置的值或添加任何其他设置。 **组织根用户 AI 服务选择退出父策略** ``` { "services": { "default": { "@@operators_allowed_for_child_policies": ["@@none"], "opt_out_policy": { "@@operators_allowed_for_child_policies": ["@@none"], "@@assign": "optOut" } } } } ``` 以下示例策略假定上一个示例策略已附加到组织根或父 OU，并且您将此示例附加到受父策略影响的账户。它会覆盖默认的选择退出设置，并明确仅选择启用 Amazon Lex 服务。 **AI 服务选择退出子策略** ``` { "services": { "lex": { "opt_out_policy": { "@@assign": "optIn" } } } } ``` 由此产生的有效政策 Amazon Web Services 账户 是，账户只能选择加入 Amazon Lex，而选择退出所有其他 Amazon AI 服务，因为继承了父政策的`default`选择退出设置。 ### 示例 3：为单个服务定义组织范围内的 AI 服务选择退出策略 以下示例显示了 AI 服务选择退出策略，该策略定义了单个 AI 服务的 `optOut` 设置。如果此策略附加到组织的根，则会阻止任何子策略覆盖此服务的 `optOut` 设置。本政策未涉及其他服务，但可能会受到其他 OUs 或账户中儿童政策的影响。 ``` { "services": { "rekognition": { "opt_out_policy": { "@@assign": "optOut", "@@operators_allowed_for_child_policies": ["@@none"] } } } } ``` # Security Hub 策略 Amazon Security Hub 策略为安全团队提供了一种集中式方法来管理其中的安全配置 Amazon Organizations。利用这些策略，您可以通过集中配置机制建立和维护一致的安全控制措施。通过这种集成，您可以通过创建符合组织安全要求的策略并将其集中应用于各个账户和组织部门（OUs）来解决安全覆盖范围的漏洞。 Security Hub 策略与完全集成 Amazon Organizations，允许管理账户或受托管理员定义和强制执行安全配置。当有账户加入您的组织时，它们会根据其在组织层次结构中的位置自动继承适用的策略。这样可以确保在组织不断发展的过程中，您的安全标准得到始终一致的应用。这些策略尊重现有的组织结构，灵活地分配安全配置，同时保持对关键安全设置的集中控制。 ## 主要功能和优势 Security Hub 策略提供了一套全面的功能，可帮助您在整个 Amazon 组织中管理和实施安全配置。这些功能简化了安全管理，同时确保对多账户环境实施一致的控制。 + 在组织中跨账户和区域集中[启用 Security Hub](https://docs.amazonaws.cn/securityhub/latest/userguide/security-hub-adv-getting-started-enable.html#security-hub-adv-getting-started-enable-org-account) + 创建安全策略来定义您的跨账户的安全配置 OUs + 新账户加入组织时，会自动应用安全配置 + 确保整个组织内安全设置的一致性 + 防止成员账户修改组织级别的安全配置 ## 什么是 Security Hub 策略？ Security Hub Amazon Organizations 策略是对组织账户中的安全配置进行集中控制的策略。这些策略与 Amazon Organizations 无缝协作，帮助您在多账户环境中建立和维护一致的安全标准。 在实施 Security Hub 策略时，您能够定义可在整个组织中自动传播的特定安全配置。这样可以确保所有账户（包括新创建的账户）都符合组织的安全要求和最佳实践。 这些策略还能够强制执行一致的安全控制措施并防止个人账户修改组织级别的安全设置，从而帮助您保持合规性。这种集中式方法大大减少了在大型复杂 Amazon 环境中管理安全配置的管理开销。 ## Security Hub 策略的工作原理 当您将 Security Hub 策略附加到组织或组织单元时， Amazon Organizations 会自动评估该策略并根据您定义的范围进行应用。策略执行过程遵循特定的冲突解决规则： 区域同时出现在启用和禁用列表中时，禁用配置优先。例如，如果启用配置和禁用配置中都列出了某个区域，则该区域的 Security Hub 将被禁用。 如果启用时指定了 `ALL_SUPPORTED`，则除非明确禁用，否则将在所有当前和未来区域中启用 Security Hub。这使您能够在 Amazon 扩展到新区域时保持全面的安全保障。 子策略可以使用继承运算符修改父策略设置，从而允许在不同的组织级别实现精细控制。这种分层方法可确保特定的组织单元在保持基准控制的同时，可以自定义其安全设置。 ## 术语 本主题在讨论 Security Hub 策略时将使用以下术语。 **Security Hub 策略术语** | 租期 | 定义 | | --- | --- | | 有效策略 | 合并所有继承的策略后，应用于某个账户的最终策略。 | | 策略继承 | 账户从父级组织单元继承策略的过程。 | | 委派管理员 | 指定代表组织来管理 Security Hub 策略的账户。 | | 服务相关角色 | 允许 Security Hub 与其他 Amazon 服务进行交互的 IAM 角色。 | ## Security Hub 策略的使用案例 Security Hub 策略解决了多账户环境中常见的安全管理挑战。以下使用案例演示了组织通常如何实施这些策略来增强其安全状况。 ### 示例使用案例：区域合规性要求 一家跨国公司需要针对不同的地理区域使用不同的 Security Hub 配置。他们使用 `ALL_SUPPORTED` 创建了一个在所有区域中启用 Security Hub 的父策略，然后使用子策略禁用需要不同安全控制的特定区域。这样，他们既能够遵守地区法规，又能确保全面的安全覆盖范围。 ### 示例使用案例：开发团队安全标准 一个软件开发组织实施了 Security Hub 策略，允许在生产区域中进行监控，同时保持开发区域不受管理。他们在策略中使用明确的区域列表而不是 `ALL_SUPPORTED`，以精确控制安全监控的覆盖范围。使用这种方法，他们能够在生产环境中实施更严格的安全控制，同时保持开发领域具有灵活性。 ## 策略继承和强制执行 了解策略的继承和执行方式对于在整个组织中实现有效的安全管理至关重要。继承模型遵循 Amazon Organizations 层次结构，确保策略应用的可预测性和一致性。 + 在根级别附加的策略适用于所有账户 + 账户从其父级组织单元继承策略 + 多个策略可应用于单个账户 + 更具体的策略（层次结构中更接近账户的策略）优先级更高 ## 策略验证 创建 Security Hub 策略时，需要进行以下验证： + 区域名称必须是有效的 Amazon 区域标识符 + 区域必须受 Security Hub 支持 + 策略结构必须遵循 Amazon Organizations 策略语法规则 + 必须同时存在 `enable_in_regions` 和 `disable_in_regions` 列表，但这两个列表都可以为空 ## 区域注意事项和支持的区域 Security Hub 策略跨多个区域运行，因此需要仔细考虑您的全局安全需求。了解区域行为有助于您在组织的全局范围内实施有效的安全控制。 + 策略在每个区域内独立执行 + 您可以指定在策略中包括或排除哪些区域 + 使用 `ALL_SUPPORTED` 选项时，新区域将自动包含在内 + 政策仅适用于 Security Hub 可用的区域 ## 后续步骤 要开始使用 Security Hub 策略，请执行以下操作： 1. 查看“Security Hub 策略入门”中的先决条件 1. 使用我们的最佳实践指南规划您的策略 1. 了解策略语法并查看示例策略 # Security Hub 策略入门 开始使用 在配置 Security Hub 策略之前，请确保您了解先决条件和实施要求。本主题将指导您完成在组织中设置和管理这些策略的过程。 ## 开始前的准备工作 在实施 Security Hub 策略之前，请查看以下要求： + 您的账户必须是 Amazon Organizations 组织的一部分 + 您必须使用以下任一身份登录： + 组织的管理账户 + 具有管理 Security Hub 策略权限的委派管理员账户 + 您必须为组织中的 Security Hub 启用可信访问权限 + 您必须在组织根中启用 Security Hub 策略类型 此外，请确认： + 您想要应用策略的区域支持 Security Hub + 您的管理账户中已配置 `AWSServiceRoleForSecurityHubV2` 服务关联角色。要验证此角色是否存在，请运行 `aws iam get-role --role-name AWSServiceRoleForSecurityHubV2`。如果需要创建此角色，可以从您的管理账户在任何区域运行 `aws securityhub enable-security-hub-v2`，也可以通过运行 `aws iam create-service-linked-role --aws-service-name securityhubv2.amazonaws.com` 直接创建。 ## 实现步骤 要有效地实施 Security Hub 策略，请按顺序执行以下步骤。每个步骤都可确保配置正确，并有助于在设置过程中避免常见问题。管理账户或授权管理员可以通过 Amazon Organizations 控制台、 Amazon 命令行界面 (Amazon CLI) 或执行这些步骤 Amazon SDKs。 1. [启用 Security Hub 的可信访问权限](orgs_integrate_services.md#orgs_how-to-enable-disable-trusted-access)。 1. [为组织启用 Security Hub 策略](enable-policy-type.md)。 1. [创建 Security Hub 策略](orgs_policies_create.md#create-security-hub-policy-procedure)。 1. [将 Security Hub 策略附加到组织的根、OU 或账户](orgs_policies_attach.md)。 1. [查看应用于账户的合并有效 Security Hub 策略](orgs_manage_policies_effective.md)。 在所有这些步骤中，您可以以 Amazon Identity and Access Management (IAM) 用户身份登录、担任 IAM 角色或以根用户身份登录（[不推荐](https://docs.amazonaws.cn/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)）在组织的管理账户中登录。 **其他信息** + [了解 Security Hub 策略的策略语法，并查看策略示例](orgs_manage_policies_security_hub_syntax.md) # 使用 Security Hub 策略的最佳实践 最佳实践 在整个组织中实施 Security Hub 策略时，遵循既定的最佳实践有助于确保成功部署和维护安全配置。这些指南专门针对了 Security Hub 策略管理和实施的独特方面 Amazon Organizations。 ## 策略设计原则 在创建 Security Hub 策略之前，请先确立明确的策略结构原则。保持策略简洁明了，避免使用复杂的交叉属性或嵌套规则，以免难以确定最终结果。首先在组织根级别制定宽泛策略，然后根据需要通过子策略进行细化。 考虑策略性地使用空区域列表。如果您只需要在特定区域禁用 Security Hub，则可以将 `enable_in_regions` 留空，或者将 `disable_in_regions` 留空以使某些区域不受策略管理。这种灵活性有助于您精确控制安全监控的覆盖范围。 ## 区域管理策略 在通过 Security Hub 策略管理区域时，请考虑这些经验证的方法。如果您想要自动将未来区域纳入安全覆盖范围，请使用 `ALL_SUPPORTED`。要进行更精细的控制，请明确列出区域而不是依赖 `ALL_SUPPORTED`，尤其是在不同区域需要不同安全配置的情况下。 记录您的区域特定要求，特别是： + 需要特定配置的合规性规定区域 + 开发环境与生产环境存在差异 + 有特殊注意事项的选择加入区域 + 必须禁用 Security Hub 的区域 ## 策略继承规划 仔细规划您的策略继承结构，在保持有效安全控制的同时兼顾必要的灵活性。记录哪些组织单元可以修改继承的策略以及允许进行哪些修改。当您需要强制执行严格的安全控制措施时，可以考虑在父级限制继承运算符（@@assign、@@append、@@remove）。 ## 监控和验证 实施定期监控措施，确保您的策略持续有效。定期审查策略附件，尤其是在组织发生变更之后。验证区域配置是否符合您的预期安全覆盖范围，尤其是在使用 `ALL_SUPPORTED` 或管理多个区域列表时。 ## 对策略进行问题排查 在对 Security Hub 策略进行问题排查时，首先要关注策略优先级和策略继承。请记住，如果区域出现在两个列表中，禁用配置的优先级高于启用配置。检查策略继承链，了解父策略和子策略如何组合起来为每个账户创建有效策略。 # Security Hub 策略语法和示例 Security Hub 策略遵循标准化 JSON 语法，该语法定义了如何在组织中启用和配置 Security Hub。了解策略结构有助于您根据自己的安全需求创建有效策略。 ## 注意事项 在创建 Security Hub 策略之前，请了解以下有关策略语法的关键点： + 策略中必须同时包含 `enable_in_regions` 和 `disable_in_regions` 列表，但这两个列表都可以为空 + 处理有效策略时，`disable_in_regions` 优先级高于 `enable_in_regions` + 除非明确限制，否则子策略可以使用继承运算符修改父策略 + `ALL_SUPPORTED` 指定包含当前区域和未来区域 + 区域名称必须有效且在 Security Hub 中可用 ## 基本策略结构 Security Hub 策略使用以下基本结构： ``` { "securityhub": { "enable_in_regions": { "@@append": ["ALL_SUPPORTED"], "@@operators_allowed_for_child_policies": ["@@all"] }, "disable_in_regions": { "@@append": [], "@@operators_allowed_for_child_policies": ["@@all"] } } } ``` ## 策略组件 Security Hub 策略包含以下关键组件： `securityhub` 策略设置的顶级容器 所有 Security Hub 策略均必需 `enable_in_regions` 应启用 Security Hub 的区域列表 可以包含特定区域名称或 `ALL_SUPPORTED` 必填字段，但可以为空 使用 `ALL_SUPPORTED` 时，包含未来区域 `disable_in_regions` 应禁用 Security Hub 的区域列表 可以包含特定区域名称或 `ALL_SUPPORTED` 必填字段，但可以为空 区域同时出现在两个列表中时，优先级高于 `enable_in_regions` 继承运算符 @@assign：覆盖继承的值 @@append：将新值添加到现有值中 @@remove：从继承的设置中移除特定值 ## Security Hub 策略示例 以下示例演示了常见的 Security Hub 策略配置。 以下示例在所有当前和未来区域中启用了 Security Hub。此策略在 `enable_in_regions` 列表中使用了 `ALL_SUPPORTED` 并将 `disable_in_regions` 留空，这样可确保在新区域可用时实现全面的安全覆盖范围。 ``` { "securityhub":{ "enable_in_regions":{ "@@assign":[ "ALL_SUPPORTED" ] }, "disable_in_regions":{ "@@assign":[ ] } } } ``` 此示例在所有区域（包括任何未来区域）中禁用了 Security Hub，因为 `disable_in_regions` 列表优先级高于 `enable_in_regions`。 ``` { "securityhub":{ "enable_in_regions":{ "@@assign":[ "us-east-1", "us-west-2" ] }, "disable_in_regions":{ "@@assign":[ "ALL_SUPPORTED" ] } } } ``` 以下示例演示了子策略如何使用继承运算符修改父策略的设置。这种方法既能实现精细控制，又能保持策略结构的整体性。子策略向 `enable_in_regions` 添加了一个新区域，并从 `disable_in_regions` 中移除了一个区域。 ``` { "securityhub":{ "enable_in_regions":{ "@@append":[ "eu-central-1" ] }, "disable_in_regions":{ "@@remove":[ "us-west-2" ] } } } ``` 此示例说明如何在不使用 `ALL_SUPPORTED` 的情况下，在多个特定区域中启用 Security Hub。这样可以精确控制哪些区域启用了 Security Hub，同时使未指定的区域不受该策略的管理。 ``` { "securityhub":{ "enable_in_regions":{ "@@assign":[ "us-east-1", "us-west-2", "eu-west-1", "ap-southeast-1" ] }, "disable_in_regions":{ "@@assign":[ ] } } } ``` 以下示例演示了如何通过在大多数区域中启用 Security Hub，同时在特定位置明确禁用 Security Hub 来满足区域合规性要求。`disable_in_regions` 列表具有优先级，确保无论其他策略设置如何，这些区域的 Security Hub 始终处于禁用状态。 ``` { "securityhub":{ "enable_in_regions":{ "@@assign":[ "ALL_SUPPORTED" ] }, "disable_in_regions":{ "@@assign":[ "ap-east-1", "me-south-1" ] } } } ``` # 亚马逊 Bedrock 政策 Amazon Bedrock 策略允许您在组织结构中的任何元素中自动实施在 Amazon Bedrock Guardrails 中配置的保护措施，以应对对 Amazon Bedrock 的所有模型推理调用。这样就无需为每个账户配置单独的防护。Amazon Bedrock Guardrails 提供可配置的保护措施，以帮助安全地大规模构建生成式 AI 应用程序，其标准方法适用于各种基础模型，包括：Amazon Bedrock 中支持的模型、经过微调的模型和托管在 Amazon Bedrock 之外的模型。 Organizations 中的 Amazon Bedrock 政策允许您 Amazon 以 JSON 格式引用在您的管理账户中创建的护栏。您可以将任何策略附加到组织结构的必需元素，例如根账户、组织单位 (OUs) 和个人账户。 Amazon Organizations 应用继承规则来合并这些策略，从而为每个账户制定有效的政策，规定如何为您的生成式 AI 应用程序实施保障措施。 ## 工作原理 借助 Amazon Bedrock 政策，您可以控制在多个账户的护栏内自动强制执行安全措施，从而允许您在所有或部分模型上强制执行护栏，以便对 Amazon Bedrock 进行推理调用。您需要在政策中引用相应护栏的特定版本，同时遵守组织负责任的人工智能要求。这特定于您的护栏所在 Amazon 区域，您需要为每个想要实施安全控制的 Amazon 区域设置不同的护栏。然后，您可以将此策略附加到组织中的任何节点，然后该节点下的账户将自动继承这些保护措施，并将其应用于对 Amazon Bedrock 的每次模型调用。 Amazon Bedrock 政策可帮助您确保在整个组织中实现一致的安全控制，并提供一种集中式方法来安全地大规模构建生成式 AI 应用程序。 # 开始使用 Amazon Bedrock 政策 开始使用 在配置 Amazon Bedrock 策略之前，请确保您了解先决条件和实施要求。本主题将指导您完成在组织中设置和管理这些策略的过程。 ## 开始前的准备工作 在实施 Amazon Bedrock 政策之前，请查看以下要求： + 您的账户必须是 Amazon 组织的一部分 + 您必须使用以下任一身份登录： + 组织的管理账户 + 有权管理 Amazon Bedrock 策略的委托管理员账户 + 您必须在组织根目录中启用 Amazon Bedrock 策略类型 ## 实现步骤 要有效实施 Amazon Bedrock 政策，请按顺序执行以下步骤。每个步骤都可确保配置正确，并有助于在设置过程中避免常见问题。管理账户或授权管理员可以通过 Amazon Organizations 控制台、 Amazon 命令行界面 (Amazon CLI) 或执行这些步骤 Amazon SDKs。 1. [为您的组织启用 Amazon Bedrock 政策](enable-policy-type.md)。 1. [创建 Amazon Bedrock 政策](orgs_manage_policies_bedrock_syntax.md)。 1. [将 Amazon Bedrock 政策附加到贵组织的根目录、组织单位或账户](orgs_policies_attach.md)。 1. [查看适用于账户的合并生效 Amazon Bedrock 政策](orgs_manage_policies_effective.md)。 # 使用 Amazon Bedrock 政策的最佳实践 最佳实践 ## 使用有效的护栏标识符 不正确或格式错误的标识符将导致目标组织中的所有 Amazon Bedrock API 调用失败。[监控无效 CloudTrail 的有效策略警报，以快速检测错误配置](https://docs.amazonaws.cn/organizations/latest/userguide/invalid-policy-alerts.html)。 ## 排除自动推理策略 组织层面的执法不支持包含自动推理策略的防护栏。确认您选择的 Amazon Bedrock Guardrail 中不包含护栏。 ## 授予必要的 IAM 权限 使用 [Amazon Bedrock Guardrails 基于资源的策略](https://docs.amazonaws.cn/bedrock/latest/userguide/guardrails-resource-based-policies.html)向组织及其成员账户授予在运行时评估强制性护栏的权限。 ## 查看 Amazon Bedrock 护栏的服务限制 使用 Amazon Bedrock 政策的会员账户通话将计入该会员的服务配额。查看 Service Quotas 控制台，确保您的 Guardrails 运行时限制足以满足您的呼叫量。 ## 从小处着手，然后扩大规模 首先，将您的保单附加到几个账户，确保按照您预期的方式应用政策。请务必测试 Guardrail 权限是否已配置为允许跨账户访问。 ## 使用验证对您的 Amazon Bedrock 政策的更改 DescribeEffectivePolicy 在您对 Amazon Bedrock 政策进行更改后，请查看低于您更改级别的代表账户的有效政策。您可以使用 Amazon 管理控制台、`DescribeEffectivePolicy` API 操作或其 Amazon CLI 或 Amazon SDK 变体之一来查看有效策略。确保您所做的更改对有效策略产生预期影响。 ## 沟通与培训 确保您的组织了解您的 Amazon Bedrock 政策的目的和影响。就 Amazon Bedrock Guardrails 的行为和预期情况提供明确的指导。 # Amazon Bedrock 政策语法和示例 Amazon Bedrock 政策是一个按照 JSON 规则构造的纯文本文件。Amazon Bedrock 策略的语法遵循所有管理策略类型的语法。有关更多信息，请参阅[管理策略类型的策略语法和继承](orgs_manage_policies_inheritance_mgmt.md)。本主题重点介绍如何将该通用语法应用于 Amazon Bedrock 策略类型的特定要求。 以下 Amazon Bedrock 策略示例显示了基本的亚马逊 Bedrock 策略语法： ``` { "bedrock": { "guardrail_inference": { "us-east-1": { "config_1": { "identifier": { "@@assign": "arn:aws:bedrock:us-east-1:123456789012:guardrail/hu1dlsv9wy1d:1" }, "selective_content_guarding": { "system": { "@@assign": "selective" }, "messages": { "@@assign": "comprehensive" } }, "model_enforcement": { "included_models": { "@@assign": ["ALL"] }, "excluded_models": { "@@assign": ["amazon.titan-embed-text-v2:0", "cohere.embed-english-v3"] } } } } } } } ``` ## Amazon Bedrock 策略语法包括以下元素 `"bedrock"` Amazon Bedrock 政策文件的顶级密钥。 `"guardrail_inference"` 定义护栏强制配置。 `` 将实施政策的区域。例如 `"us-east-1"`。 `"config_1"` 护栏设置的配置标识符。 `"identifier"`（必填） Guardrail ARN，其次是护栏版本`:version`。 + 护栏必须归管理账户所有。您无法使用其他账户的 Guardrail 创建策略。 + 护栏必须有版本，并且该版本不能是草稿。要创建护栏的版本，请参阅 Amazon B [edrock 用户指南中的创建护栏版本](https://docs.amazonaws.cn/bedrock/latest/userguide/guardrails-versions-create.html)。 + Guardrail 必须有基于资源的政策，允许组织成员拨打电话。`ApplyGuardrail` + 护栏必须在指定区域创建和使用。 `"selective_content_guarding"`（可选） Amazon Bedrock APIs 允许在输入中标记呼叫者希望护栏处理的特定内容。这些设置允许执法人员控制是否尊重来电者做出的内容标记决定。如果指定，则必须`"messages"`为`"system"`或之一。 `"system"`（可选） 选择护栏如何处理系统提示。未指定`comprehensive`时默认为。 + `"comprehensive"`: 评估所有内容，而不考虑警卫内容标签。 + `"selective"`：仅评估防护内容标签内的内容。未指定标签时不评估任何内容。 `"messages"`（可选） 选择护栏如何处理带有用户和助手对话的消息内容。未指定`comprehensive`时默认为。 + `"comprehensive"`: 评估所有内容，而不考虑警卫内容标签。 + `"selective"`：仅评估防护内容标签内的内容。未指定标签时，评估消息中的所有内容。 `"model_enforcement"`（可选） 强制护栏配置的特定型号信息。如果不存在，则将在所有型号上强制执行该配置。 `"included_models"`（必填） 用于加强护栏的型号清单。如果为空，则对所有模型应用强制执行。还接受关键字 “ALL” 以明确包含所有模型。 `"excluded_models"`（必填） 排除在护栏强制执行范围之外的模型。如果为空，则不会将任何模型排除在强制执行范围之外。如果模型同时出现在包括和排除的模型列表中，则将其排除在外。 # 亚马逊 Inspector 政策 Amazon Inspector 政策允许您集中启用和管理 Amazon 组织中各个账户的亚马逊 Inspector。使用 Amazon Inspector 政策，您可以指定哪些组织实体（根或账户）已自动启用 Amazon Inspector 并将其关联到 Amazon Inspector 委托的管理员账户。 OUs您可以使用 Amazon Inspector 政策来简化整个服务的入门流程，并确保在所有现有和新创建的账户中一致启用亚马逊 Inspector。 ## 主要特点和优点 Amazon Inspector 策略允许您定义应为您的组织或其子集启用哪些扫描类型，从而确保覆盖范围一致并减少手动工作。实施后，它们可以帮助您自动注册新帐户，并在组织规模扩大时保持扫描基准。 ## 工作原理 当您将亚马逊检查员策略附加到组织实体时，该策略会自动为该范围内的所有成员账户启用亚马逊检查器。此外，如果您通过为 Amazon Inspector 注册委托管理员来完成 Amazon Inspector 的设置，则该账户将对组织中启用了 Amazon Inspector 的账户进行集中漏洞可见性。 Amazon Inspector 政策可以应用于整个组织、特定的组织单位 (OUs) 或个人账户。加入组织或加入附有 Amazon Inspector 政策的 OU 的账户会自动继承该政策，并启用 Amazon Inspector 并将其关联到 Amazon Inspector 委托的管理员。Amazon Inspector 策略允许您启用亚马逊扫 EC2 描、亚马逊 ECR 扫描、Lambda 标准和代码扫描以及代码安全。可以通过组织的委派管理员帐户管理特定的配置设置和禁止规则。 当您将Amazon Inspector策略附加到您的组织或组织单位时， Amazon Organizations会自动评估该政策并根据您定义的范围进行应用。策略执行过程遵循特定的冲突解决规则： + 区域同时出现在启用和禁用列表中时，禁用配置优先。例如，如果在启用和禁用配置中都列出了某个区域，则该区域的 Amazon Inspector 将被禁用。 + 如果指定启用，`ALL_SUPPORTED`则除非明确禁用 Amazon Inspector，否则将在当前和未来的所有地区启用。这使您能够在 Amazon 扩展到新区域时保持全面的覆盖范围。 + 子策略可以使用继承运算符修改父策略设置，从而允许在不同的组织级别实现精细控制。这种分层方法可确保特定的组织单元在保持基准控制的同时，可以自定义其安全设置。 ### 术语 本主题在讨论 Amazon Inspector 政策时使用以下术语。 | 租期 | 定义 | | --- | --- | | 有效策略 | 合并所有继承的策略后，应用于某个账户的最终策略。 | | 策略继承 | 账户从父级组织单元继承策略的过程。 | | 委派管理员 | 指定代表组织管理 Amazon Inspector 政策的账户。 | | 服务相关角色 | 一个 IAM 角色，允许 Amazon Inspector 与其他 Amazon 服务进行交互。 | ### Amazon Inspector 政策的用例 跨多个账户启动大规模工作负载的组织可以使用此策略来确保所有账户立即启用正确的扫描类型并避免漏洞。监管或合规性驱动的环境可以使用子政策来覆盖或限制 OU 的扫描类型。快速增长的环境可以自动启用新创建的帐户，因此它们始终符合基准。 ### 策略继承和强制执行 了解策略的继承和执行方式对于在整个组织中实现有效的安全管理至关重要。继承模型遵循Organiz Amazon ations的层次结构，确保了可预测和一致的策略应用。 + 在根级别附加的策略适用于所有账户 + 账户从其父级组织单元继承策略 + 多个策略可应用于单个账户 + 更具体的策略（层次结构中更接近账户的策略）优先级更高 ### 策略验证 创建 Amazon Inspector 策略时，需要进行以下验证： + 区域名称必须是有效的 Amazon 区域标识符 + Amazon Inspector 必须支持区域 + 策略结构必须遵循 Amazon Organizations 策略语法规则 + 必须同时存在 `enable_in_regions` 和 `disable_in_regions` 列表，但这两个列表都可以为空 ### 区域注意事项和支持的区域 Amazon Inspector 政策仅适用于可使用亚马逊 Inspector 和 Or Amazon ganizations 可信访问的地区。了解区域行为有助于您在组织的全局范围内实施有效的安全控制。 + 策略在每个区域内独立执行 + 您可以指定在策略中包括或排除哪些区域 + 使用 `ALL_SUPPORTED` 选项时，新区域将自动包含在内 + 政策仅适用于提供 Amazon Inspector 的地区 ### 分离行为 如果您取消了 Amazon Inspector 政策，则在之前涵盖的账户中，Amazon Inspector 仍处于启用状态。但是，未来对组织结构的更改（例如新账户加入或现有账户迁入 OU）将不再自动启用 Amazon Inspector。任何进一步的启用都必须手动或通过重新附加策略来执行。 ## 其他详细信息 ### 委托管理员 一个组织中只能为一名委托管理员注册 Amazon Inspector。在附加 Amazon Inspector 策略 APIs 之前，您必须在 Amazon Inspector 控制台中或通过进行配置。 ### 先决条件 您必须为 Organization Amazon s 启用可信访问权限，注册 Amazon Inspector 的委托管理员，并在所有账户中使用服务相关角色。 ### 支持的区域： 所有提供 Amazon Inspector 的区域。 # 开始使用 Amazon Inspector 政策 开始使用 在配置 Amazon Inspector 策略之前，请确保您了解先决条件和实施要求。本主题将指导您完成在组织中设置和管理这些策略的过程。 ## 了解所需权限 要启用或附加 Amazon Inspector 政策，您必须在管理账户中拥有以下权限： + `inspector2.amazonaws.com` 的 `organizations:EnableAWSServiceAccess` + `inspector2.amazonaws.com` 的 `organizations:RegisterDelegatedAdministrator` + `organizations:AttachPolicy`, `organizations:CreatePolicy`, `organizations:DescribeEffectivePolicy` + `inspector2:Enable`（适用于管理账号和委派管理员） ## 开始前的准备工作 在实施 Amazon Inspector 政策之前，请查看以下要求： + 您的账户必须是 Amazon 组织的一部分 + 您必须使用以下任一身份登录： + 组织的管理账户 + Organ Amazon izations 委托管理员有权管理 Amazon Inspector 政策 + 您必须为组织中的 Amazon Inspector 启用可信访问权限 + 您必须在组织根目录中启用 Amazon Inspector 策略类型 此外，请确认： + 您要应用政策的区域支持 Amazon Inspector + 您的管理账户中已配置 `AWSServiceRoleForInspectorV2` 服务关联角色。要验证此角色是否存在，请运行 `aws iam get-role --role-name AWSServiceRoleForInspectorV2`。如果需要创建此角色，可以从您的管理账户在任何区域运行 `aws inspector2 enable`，也可以通过运行 `aws iam create-service-linked-role --aws-service-name inspector2.amazonaws.com` 直接创建。 ## 实现步骤 要有效实施 Amazon Inspector 政策，请按顺序执行以下步骤。每个步骤都可确保配置正确，并有助于在设置过程中避免常见问题。管理账户或授权管理员可以通过 Amazon Organizations 控制台、 Amazon 命令行界面 (Amazon CLI) 或执行这些步骤 Amazon SDKs。 1. [为 Amazon Inspector 启用可信访问权限](orgs_integrate_services.md#orgs_how-to-enable-disable-trusted-access)。 1. [为您的组织启用 Amazon Inspector 政策](enable-policy-type.md)。 1. [创建 Amazon Inspector 政策](orgs_manage_policies_inspector_syntax.md)。 1. [将 Amazon Inspector 政策附加到贵组织的根目录、组织单位或账户](orgs_policies_attach.md)。 1. [查看适用于账户的合并生效 Amazon Inspector 政策](orgs_manage_policies_effective.md)。 ## 创建 Amazon Inspector 政策 ### 最小权限 要创建 Amazon Inspector 策略，您需要以下权限： + `organizations:CreatePolicy` ### Amazon 管理控制台 **创建 Amazon Inspector 政策** 1. 登录 [Amazon Organizations 控制台](https://console.amazonaws.cn/organizations/v2)。您必须以 IAM 用户的身份登录，担任 IAM 角色；或在组织的管理账户中以根用户的身份登录（[不推荐](https://docs.amazonaws.cn/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)）。 1. 在 Amazon Inspector 控制台中为正在使用的服务设置委托管理员。 1. 为 Amazon Inspector 设置委托管理员后，请访问 Amazon 组织控制台设置政策。在 Amazon 组织控制台上，访问 Amazon Inspector **政策页面，选择创建策略**。 1. 在**创建新的 Amazon Inspector 政策****页面上，输入策略名称**和可选的**政策描述**。 1. （可选）您可以向策略添加一个或多个标签，方法是选择 **Add tag (添加标签)**，然后输入一个键和可选的值。将值留空，设置为空字符串；它并非 `null`。您最多可以向策略附加 50 个标签。有关更多信息，请参阅 [标记资源 Amazon Organizations注意事项](orgs_tagging.md)。 1. 在 JSON 代码框中输入或粘贴策略文本。有关 Amazon Inspector 策略语法以及可以用作起点的示例策略的信息，请参阅[Amazon Inspector 策略语法和示例](orgs_manage_policies_inspector_syntax.md)。 1. 编辑完策略后，选择位于页面右下角的 **Create policy (创建策略)**。 # 使用 Amazon Inspector 政策的最佳实践 最佳实践 在整个组织中实施 Amazon Inspector 政策时，遵循既定的最佳实践有助于确保成功部署和维护。 ## 简单开始并进行一些小更改 首先，在有限的组织单位（例如，“安全试点”）启用 Amazon Inspector 政策，以便在向所有账户推出之前验证预期行为。这种渐进式方法允许您在更广泛的部署之前识别并解决受控环境中的潜在问题。 ## 建立审查流程 定期监控是否有新账户加入您的组织，并确认他们会自动继承 Amazon Inspector 启用。每季度审查一次保单附件范围，确保您的安全覆盖范围与您的组织结构和安全要求保持一致。 ## 使用验证更改 DescribeEffectivePolicy 附加或修改政策后，请运行`DescribeEffectivePolicy`代表账户，以确保正确反映 Amazon Inspector 的启用。此验证步骤可帮助您确认您的政策变更是否在整个组织中产生了预期效果。 ## 沟通与培训 告知账户所有者，亚马逊检查器将自动启用，一旦他们与亚马逊检查员授权的管理员相关联，发现结果可能会出现在他们的 Security Hub 或 Amazon Inspector 控制面板中。清晰的沟通有助于确保账户所有者了解已实施的安全监控，并能够对发现的结果做出适当的回应。 ## 规划您的委派管理员策略 指定一个安全或合规账户作为 Amazon Inspector 的委托管理员。从 Amazon Inspector 控制台或通过 Amazon Organizations 设置委托管理员 APIs。这种方法可在整个组织中实现一致的安全监控和管理。 ## 处理区域注意事项 在您的工作负载运行的区域启用 Amazon Inspector。在确定哪些地区需要 Amazon Inspector 覆盖范围时，请考虑您的合规要求和运营需求。记录您的区域特定要求，以便在整个基础设施中保持一致的安全监控。 # Amazon Inspector 策略语法和示例 Amazon Inspector 策略遵循标准化的 JSON 语法，该语法定义了如何在您的组织中启用和配置 Amazon Inspector。Amazon Inspector 策略是一份根据 Amazon 组织管理策略语法结构的 JSON 文档。它定义了哪些组织实体将自动启用 Amazon Inspector。 ## 基本策略结构 Amazon Inspector 政策使用以下基本结构： ``` { "inspector": { "enablement": { "ec2_scanning": { "enable_in_regions": { "@@assign": ["us-east-1", "us-west-2"] }, "disable_in_regions": { "@@assign": ["eu-west-1"] } } } } } ``` ## 策略组件 Amazon Inspector 政策包含以下关键组成部分： `inspector` Amazon Inspector 政策文件的顶级密钥，这是所有亚马逊 Inspector 政策所必需的。 `enablement` 定义如何在整个组织中启用 Amazon Inspector，并包含扫描类型配置。 `Regions (Array of Strings)` 指定应自动启用 Amazon Inspector 的区域。 ## 亚马逊 Inspector 政策示例 以下示例演示了常见的 Amazon Inspector 策略配置。 ### 示例 1 — 在组织范围内启用 Amazon Inspector 以下示例`us-west-2`为组织根目录中的`us-east-1`所有账户启用 Amazon Inspector。 创建 `inspector-policy-enable.json` 文件： ``` { "inspector": { "enablement": { "lambda_standard_scanning": { "enable_in_regions": { "@@assign": [ "us-east-1", "us-west-2" ] }, "disable_in_regions": { "@@assign": [ "eu-west-1" ] }, "lambda_code_scanning": { "enable_in_regions": { "@@assign": [ "us-east-1", "us-west-2" ] }, "disable_in_regions": { "@@assign": [ "eu-west-1" ] } } }, "ec2_scanning": { "enable_in_regions": { "@@assign": [ "us-east-1", "us-west-2" ] }, "disable_in_regions": { "@@assign": [ "eu-west-1" ] } }, "ecr_scanning": { "enable_in_regions": { "@@assign": [ "us-east-1", "us-west-2" ] }, "disable_in_regions": { "@@assign": [ "eu-west-1" ] } }, "code_repository_scanning": { "enable_in_regions": { "@@assign": [ "us-east-1", "us-west-2" ] }, "disable_in_regions": { "@@assign": [ "eu-west-1" ] } } } } } ``` 连接到根目录后，组织中的所有账户都会自动启用 Amazon Inspector，其扫描结果可供亚马逊检查员授权的管理员使用。 创建并附加策略： ``` POLICY_ID=$(aws organizations create-policy \ --content file://inspector-policy-enable.json \ --name InspectorOrgPolicy \ --type INSPECTOR_POLICY \ --description "Inspector organization policy to enable all resources in IAD and PDX." \ --query 'Policy.PolicySummary.Id' \ --output text) aws organizations attach-policy --policy-id $POLICY_ID --target-id ``` 任何加入组织的新账户都会自动继承启用。 如果已分离，现有账户将保持启用状态，但是 future 账户不会自动启用： ``` aws organizations detach-policy --policy-id $POLICY_ID --target-id ``` ### 示例 2 — 为特定 OU 启用 Amazon Inspector 创建 `inspector-policy-eu-west-1.json` 文件： ``` { "inspector": { "enablement": { "lambda_standard_scanning": { "enable_in_regions": { "@@assign": [ "eu-west-1" ] }, "disable_in_regions": { "@@assign": [ "eu-west-2" ] }, "lambda_code_scanning": { "enable_in_regions": { "@@assign": [ "eu-west-1" ] }, "disable_in_regions": { "@@assign": [ "eu-west-2" ] } } }, "ec2_scanning": { "enable_in_regions": { "@@assign": [ "eu-west-1" ] }, "disable_in_regions": { "@@assign": [ "eu-west-2" ] } }, "ecr_scanning": { "enable_in_regions": { "@@assign": [ "eu-west-1" ] }, "disable_in_regions": { "@@assign": [ "eu-west-2" ] } }, "code_repository_scanning": { "enable_in_regions": { "@@assign": [ "eu-west-1" ] }, "disable_in_regions": { "@@assign": [ "eu-west-2" ] } } } } } ``` 将其附加到 OU 以确保中的所有生产账户都`eu-west-1`将启用 Amazon Inspector 并将其关联到 Amazon Inspector 委托的管理员： ``` aws organizations update-policy --policy-id $POLICY_ID --content file://inspector-policy-eu-west-1.json --description "Inspector organization policy - Enable all (eu-west-1)" aws organizations attach-policy --policy-id $POLICY_ID --target-id ou-aaaa-12345678 ``` OU 之外的账户不受影响。 # 升级推出政策 Amazon Organizations 升级推出策略允许您集中管理和错开组织中多个 Amazon 资源和帐户的自动升级。通过这些策略，您可以定义资源接受升级的顺序，从而确保更改在进入生产之前在不太重要的环境中得到验证。 在当今复杂的云环境中，管理大量资源和账户的升级可能具有挑战性。升级推出政策通过提供实施升级的系统方法来应对这一挑战。通过使用这些政策，您可以使升级过程与组织的变更管理实践保持一致，从而降低风险并提高运营效率。 升级推出策略利用的分层结构 Amazon Organizations 将策略应用于整个组织或特定组织单位 (OUs)。这种集成允许您大规模管理升级，无需手动协调或自定义自动化脚本。 ## 主要功能和优势 升级推出策略为管理升级提供了全面的功能，同时为跨多个账户和环境管理资源的组织提供了显著的优势。下表概述了主要功能及其相关优势： **升级推出政策的特点和优势** [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_upgrade_rollout.html) 有关策略继承的更多信息，请参阅[了解管理策略继承](orgs_manage_policies_inheritance_mgmt.md)。 ## 什么是升级推出政策？ 升级推出策略是一组规则，用于确定如何以及何时将自动升级应用于您的 Amazon 资源。这些策略允许您为资源指定不同的升级顺序，通常与您的开发、测试和生产环境保持一致。通过这样做，您可以确保首先将升级应用于不太重要的系统，从而使您能够在任何问题影响生产工作负载之前发现并解决这些问题。 这些策略支持三个升级订单：第一个、第二个和最后一个。这些命令创建了一种分阶段的升级方法，指定为 “第一” 的资源最初接受升级，然后在等待期后获得 “第二”，在另一个等待期之后最后是 “最后”。这种错开的方法使您有时间在升级进入更关键的系统之前在每个阶段对其进行验证。 升级推出政策对于具有复杂的多账户结构或具有严格变更管理要求的组织特别有价值。它们在维护 up-to-date系统和最大限度地降低与升级相关的关键服务中断风险之间取得了平衡。 ## 升级推出政策的工作原理 升级推出策略可与您的现有 Amazon 基础架构和流程无缝集成。当您创建升级推出策略并将其附加到组织单位时，该策略将应用于该组织单位内的所有账户。然后，您可以使用资源标签或补丁单来指定应按哪个顺序升级哪些资源。 当支持的 Amazon 服务发布升级时，它会参考升级推出政策，以确定资源应按何种顺序接收升级。该服务首先在配置的维护时段内将升级应用于标记为 “第一” 的资源。在服务特定的等待期（通常为一周左右）之后，标记为 “第二” 的资源将有资格进行升级。最后，经过另一个等待期，标记为 “Last” 的资源将获得升级。 此过程可确保以可控、可预测的方式在整个组织中应用升级。它允许您在每个阶段监控升级的影响，并在更改到达最关键的环境之前根据需要采取纠正措施。此过程的自动化性质减少了管理升级的运营开销，同时仍为您提供维护 Amazon 资源稳定性和安全性所需的控制和可见性。 ## 术语 以下是您在使用升级推出策略时应了解的关键术语： **升级推出政策条款** | 租期 | 定义 | | --- | --- | | 活跃日期 | amVu 在 “描述待处理的维护操作” API 中变为可见并可供应用程序使用的日期。 | | amVu（自动次要版本升级） | 数据库引擎次要版本的自动升级过程。 | | 有效策略 | 在考虑所有继承和直接关联的策略后，适用于账户或资源的最后一组规则。 | | 维护窗口 | 可以对资源应用自动升级的重复时间段。升级推出策略在这些配置的维护时段内起作用。 | | 组织部门（OU） | 组织中 Amazon 账户的容器。可以在 OU 级别附加升级推出政策，以影响其中的所有账户。 | | 补丁顺序 | 资源获得升级的顺序（第一个、第二个、最后一个）。 | | 政策目标 | 升级推出政策的适用范围，可以是整个组织 OUs、特定账户或个人账户。 | | 资源标签 | 键值对，可用于确定哪些资源应遵循策略中的特定升级顺序。 | | 日程安排窗口 | 特定补丁顺序的资源获得升级的时间范围。 | | 特定服务的等待期 | 升级不同升级顺序的资源之间的指定时间间隔。此期限因 Amazon 服务和升级类型而异。 | | 升级顺序 | 一种指定，用于确定资源何时获得相对于其他资源的升级。可以设置为 “第一个”、“第二个” 或 “最后一个”。 | | 升级推出政策 | 用于管理跨资源的升级计划的 Amazon Organizations 策略类型。 | ## 升级推出策略的用例 不同规模和行业的组织可以从升级推出政策中受益。以下虚拟场景演示了常见的升级管理难题以及升级推出策略如何提供有效的解决方案。这些示例基于典型的客户体验，但经过简化以突出关键优势和实施模式。 许多组织面临着类似的挑战：他们需要将资源 up-to-date保留在最新版本上，同时最大限度地降低生产环境的风险。如果没有基于策略的集中式方法，团队通常会诉诸手动流程或复杂的自动化脚本。以下示例演示了两个不同的组织如何使用升级推出策略来解决类似的难题： ### 示例用例：全球金融服务公司 一家金融服务公司在多个账户中运营着数百个 Aurora PostgreSQL 数据库。 Amazon 在制定升级推出政策之前，他们的 DevOps 团队每月花几天时间手动协调数据库升级，确保更改在进入生产系统之前在开发环境中进行测试。通过实施升级推出政策，他们： + 使用升级顺序标记为 “First” 的开发数据库 + 已将 QA 数据库分配到升级顺序 “第二” + 将生产数据库指定为升级顺序 “Last” + 将升级协调时间从几天缩短到几分钟 + 首先在较低的环境中自动验证更改 + 保持对变更管理要求的合规性 ### 示例用例：物联网设备平台提供商 一家物联网公司每天使用多个 Amazon RDS 数据库处理数百万个设备事件。他们需要确保自动次要版本升级不会中断其生产服务。使用升级推出策略，他们： + 制定了适用于其组织结构的政策 + 已将金丝雀环境配置为先接收升级 + 在早期升级环境中设置监控 + 在产品升级之前，有时间检测和响应任何问题 + 用简单的策略取代了复杂的自定义升级自动化 + 保持其生产工作负载的高可用性，同时保持数据库版本的最新状态 ## 支持的 Amazon 服务 升级推出策略与以下 Amazon 服务集成，同时支持自动次要版本升级： **升级推出策略支持的服务** | 服务名称 | 用途 | | --- | --- | | Amazon Aurora PostgreSQL 兼容版 | [自动次要版本升级](https://docs.amazonaws.cn/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html#Aurora.Maintenance.AMVU) | | Amazon Aurora MySQL 兼容版 | [自动次要版本升级](https://docs.amazonaws.cn/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html#Aurora.Maintenance.AMVU) | | 适用于 PostgreSQL 的亚马逊关系数据库服务 | [自动次要版本升级](https://docs.amazonaws.cn/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.PostgreSQL.Minor.html) | | 适用于 SQL Server 的 Amazon Relational Database Service | [自动次要版本升级](https://docs.amazonaws.cn/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.SQLServer.html) | | 适用于 Oracle 的亚马逊关系数据库 Service | [自动次要版本升级](https://docs.amazonaws.cn/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.Oracle.Minor.html#oracle-minor-version-upgrade-tuning-on) | | 适用于 MariaDB 的亚马逊关系数据库服务 | [自动次要版本升级](https://docs.amazonaws.cn/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MariaDB.Minor.html) | | 适用于 MySQL 的亚马逊关系数据库服务 | [自动次要版本升级](https://docs.amazonaws.cn/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MySQL.Minor.html) | | 适用于 Db2 的亚马逊关系数据库服务 | [自动次要版本升级](https://docs.amazonaws.cn/AmazonRDS/latest/UserGuide/Db2.Concepts.VersionMgmt.html) | ## 先决条件 以下是在中管理升级推出策略所需的先决条件和必需权限： Amazon Organizations + Amazon Organizations 管理账户或委派管理员访问权限 + 支持的服务（目前为 Amazon Aurora 和亚马逊关系数据库服务数据库引擎）中的资源 + 管理升级推出策略的正确 IAM 权限 ## 后续步骤 要开始使用升级推出策略，请执行以下操作： 1. 查看[升级推出政策入门](orgs_manage_policies_upgrade_getting_started.md)以了解如何创建和管理策略 1. 探索如何[使用升级推出策略的最佳实践](orgs_manage_policies_upgrade_best_practices.md)实施升级推出政策 1. 明白 [升级推出策略语法和示例](orgs_manage_policies_upgrade_syntax.md) # 升级推出政策入门 按照以下步骤在您的组织中实施升级推出政策。每个步骤都链接到详细信息，以帮助您成功完成实施。 ## 开始前的准备工作 确保您具备以下条件： + 对的管理访问权限 Amazon Organizations + 支持的 Amazon 服务（例如 Aurora 或 Amazon Relational Database Service）中的资源 + 已配置必要的 IAM 权限 ## 实现步骤 1. [为您的组织启用升级推出政策。](enable-policy-type.md) 1. [了解升级推出政策的工作原理。](orgs_manage_policies_upgrade_rollout.md#orgs_manage_policies_upgrade_rollout_how_work) + 识别开发、测试和生产环境 + 确定哪些资源应该先升级、第二次升级、最后一次升级 + 记录您的标记策略以进行资源识别 1. [创建升级推出策略](orgs_policies_create.md#create-upgrade-rollout-policy-procedure): + 定义默认部署顺序（组织单位或账户级别） + 使用标签指定资源定位 + 配置所有策略排除项 1. [将升级推出政策附加到可用于测试的单个成员账户。](orgs_policies_attach.md) : + 从测试组织单元开始 + 验证策略继承 + 确认策略附件状态 1. 根据您的升级顺序策略标记您的资源： + 将标签应用于开发资源以进行首次升级 + 标记用于二阶升级的测试资源 + 为最后一笔订单升级指定生产资源 1. 监控和验证策略： + 查看升级订单分配 + 验证策略对测试资源的影响 1. 测试升级过程： + 等待服务升级可用 + 在您的环境中监控升级进度 + 验证升级是否遵循您的指定顺序 1. 根据需要为其他组织单位启用升级推出策略 **其他信息** + [了解升级推出策略语法并查看策略示例](orgs_manage_policies_upgrade_syntax.md) # 使用升级推出策略的最佳实践 Amazon 为使用升级推出策略推荐了以下最佳实践。 **Topics** + [ ## 从小规模开始，逐步扩展规模 ](#orgs_manage_policies_upgrade_best_practices_scale) + [ ## 建立审查流程 ](#orgs_manage_policies_upgrade_best_practices_review) + [ ## 有效验证政策变更 ](#orgs_manage_policies_upgrade_best_practices_validate) + [ ## 监控和传达变更 ](#orgs_manage_policies_upgrade_best_practices_monitor) + [ ## 维护合规性和安全性 ](#orgs_manage_policies_upgrade_best_practices_compliance) + [ ## 优化运营效率 ](#orgs_manage_policies_upgrade_best_practices_optimize) ## 从小规模开始，逐步扩展规模 在非关键环境中，先将测试策略附加到单个账户。这种方法使您能够验证升级推出策略的行为和影响，而不会造成关键工作负载中断的风险。确认该政策按预期运行后，请逐步将其向上移动组织结构，以包括更多的账户和组织单位。 这种渐进式扩展有助于您在实施过程的早期发现和解决任何问题。考虑创建一组试点资源，既能代表环境的多样性，又能将运营风险降至最低。记录每个扩展阶段的结果，为未来的政策推出和调整提供信息。 ## 建立审查流程 实施定期审查流程，以监控新的升级推出策略属性并评估政策异常。这些审查应符合贵组织的安全和运营要求。制定审查政策有效性的时间表，并保存所做任何调整的文档。 您的审查流程应包括定期评估哪些资源受政策管辖，验证升级订单是否符合您的预期策略，以及评估任何政策例外情况。考虑为何时需要更新策略制定标准，并维护变更日志，以跟踪策略随时间的演变。 ## 有效验证政策变更 对升级推出政策进行更改后，请查看组织各个级别的代表性客户的有效政策。使用 Amazon 管理控制台或 `DescribeEffectivePolicy` API 操作来验证您的更改是否产生了预期影响。这种验证应包括检查不同组织单位的资源，并确认继承是否按预期进行。 要特别注意分配了明确升级命令的资源，而不是使用默认值的资源。制定验证清单，包括验证基于标签的定位、确认维护时段对齐以及测试策略继承。 ## 监控和传达变更 对您的升级推出政策进行全面监控，并为共享升级相关信息创建清晰的沟通渠道。记录处理升级失败的明确程序，并针对不同的情况制定响应计划。 与管理受升级政策影响的资源的团队保持定期沟通。可以考虑创建仪表板，以便了解即将进行的升级及其在您的环境中的预期进展。 ## 维护合规性和安全性 定期审核您的升级推出政策，确保它们符合您的合规性要求。记录所有政策决策，并清晰记录升级模式和异常情况。围绕策略修改实施安全控制，并使用对策略变更进行审计跟踪 Amazon CloudTrail。 定期查看策略管理功能的访问权限，并对策略管理实施最低权限访问权限。创建紧急策略修改程序，并保存与安全相关的升级要求的文档。 ## 优化运营效率 设计您的策略以最大限度地减少运营开销，同时保持必要的控制。为防止意外行为，请勿在不同的用例中重复使用标签。尽可能自动检查策略合规性，并为常见的策略管理任务创建标准操作程序。 考虑为不同类型的升级方案创建模板，并保留成功策略模式的文档。定期审查运营指标可以帮助确定政策优化和流程改进的机会。 # 升级推出策略语法和示例 升级推出策略定义了 Amazon 服务如何对您的资源进行自动升级。了解策略语法有助于您创建符合组织升级要求的有效策略。 **Topics** + [ ## 注意事项 ](#orgs_manage_policies_upgrade_syntax_considerations) + [ ## 基本策略结构 ](#orgs_manage_policies_upgrade_syntax_structure) + [ ## 策略组件 ](#orgs_manage_policies_upgrade_syntax_components) + [ ## 升级推出策略示例 ](#orgs_manage_policies_upgrade_syntax_examples) ## 注意事项 在实施升级推出策略时，请考虑以下重要因素： + 策略名称在您的组织中必须是唯一的，并且应清晰且具有描述性。选择能反映政策目的和范围的名称。有关更多信息，请参阅 [优化运营效率](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_optimize)。 + 在广泛部署之前，测试至关重要。首先在非生产环境中验证新策略，然后逐步扩展以确保所需的行为。有关更多信息，请参阅 [从小规模开始，逐步扩展规模](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_scale)。 + 政策变更可能需要几个小时才能在整个组织中传播。相应地规划您的实施，并确保进行适当的监控。有关更多信息，请参阅 [监控和传达变更](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_monitor)。 + JSON 格式必须有效，并且保持在 5,120 字节的最大策略大小之内。在满足您的要求的同时，尽可能简化政策结构。 + 定期的政策审查有助于保持有效性。安排对您的政策进行定期评估，以确保它们继续满足您的组织需求。有关更多信息，请参阅 [建立审查流程](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_review)。 + 未分配升级顺序的资源默认为 “第二” 顺序。考虑为关键资源明确设置升级顺序，而不是依赖默认值。有关更多信息，请参阅 [有效验证政策变更](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_validate)。 + 手动升级优先于策略定义的升级订单。确保您的变更管理流程同时考虑自动和手动升级方案。有关更多信息，请参阅 [建立审查流程](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_review)。 **注意** 在管理账户中实施基于标签的升级推出策略时，请注意，管理账户无法直接查看或访问成员账户中的资源级标签。我们建议建立一个流程，让成员账户应用一致的资源标签，然后创建引用这些标签的组织级策略。这确保了资源级标记和组织策略实施之间的适当协调。在整个组织中[标签策略](orgs_manage_policies_tag-policies.md)对资源进行标记时，您还可以使用来帮助保持标签的一致性。 ## 基本策略结构 升级推出策略使用包含以下主要元素的 JSON 结构： + 策略元数据（例如版本信息） + 资源定位规则 + 升级订单规格 + 可选的异常消息 + 特定于服务的属性 以下示例显示了基本的升级部署策略结构： ``` { "upgrade_rollout":{ "default":{ "patch_order":{ "@@assign":"last" } }, "tags":{ "devtag":{ "tag_values":{ "tag1":{ "patch_order":{ "@@assign":"first" } }, "tag2":{ "patch_order":{ "@@assign":"second" } }, "tag3":{ "patch_order":{ "@@assign":"last" } } } } } } } ``` ## 策略组件 升级推出策略由两个关键组件组成，它们协同工作以控制如何在您的资源中应用升级。这些组件包括默认行为和基于标签的覆盖的配置选项。了解这些组件的交互方式有助于您制定符合组织需求的有效策略。 ### 默认补丁顺序设置 当您在不指定任何资源特定覆盖的情况下创建升级推出策略时，所有资源都默认为基本升级顺序。您可以使用策略中的 “默认” 字段设置此默认值。没有通过标签明确分配升级顺序的资源将遵循此默认顺序。 **注意** 当今的主机体验需要指定默认顺序。 以下示例说明如何将所有资源设置为在默认情况下最后接收升级，除非被标签覆盖。当您想要确保大多数资源在升级周期的后期更新时，这种方法非常有用： ``` "upgrade_rollout": { "default": { "patch_order": "last" } } ``` ### 通过标签覆盖资源级别 您可以使用标签覆盖特定资源的默认升级顺序。这使您可以精细控制哪些资源按哪个顺序接受升级。例如，您可以根据环境类型、开发阶段或工作负载重要程度分配不同的升级顺序。 以下示例说明如何将开发资源配置为先接收升级，将生产资源配置为最后接收升级。此配置可确保您的开发环境可以在升级进入生产环境之前对其进行验证： ``` "upgrade_rollout": { "tags": { "environment": { "tag_values": { "development": { "patch_order": "first" }, "production": { "patch_order": "last" } } } } } ``` ## 升级推出策略示例 以下是常见的升级推出策略方案： ### 示例 1：首先是开发环境 此示例说明如何在开发环境中配置资源以首先接收升级。通过定位带有 “开发” 环境标签的资源，可以确保您的开发环境是第一个接收和验证新升级的环境。此模式有助于在升级到达更关键的环境之前识别潜在的问题： ``` { "tags": { "environment": { "tag_values": { "development": { "upgrade_order": "first" } } } } } ``` ### 示例 2：生产环境最后一个 此示例演示如何确保您的生产环境最后获得升级。通过将带有生产标签的资源明确设置为上次升级顺序，可以保持生产环境的稳定性，同时允许在预生产环境中进行充分的测试。这种方法对于具有严格变更管理要求的组织特别有用： ``` { "tags": { "environment": { "tag_values": { "production": { "upgrade_order": "last" } } } } } ``` ### 示例 3：使用标签的多个升级订单 以下示例演示如何使用具有不同值的单个标签键来指定所有三个升级顺序。当您想通过单一标记方案管理升级订单时，这种方法非常有用： ``` { "upgrade_rollout":{ "default":{ "patch_order":{ "@@assign":"last" } }, "tags":{ "devtag":{ "tag_values":{ "tag1":{ "patch_order":{ "@@assign":"first" } }, "tag2":{ "patch_order":{ "@@assign":"second" } }, "tag3":{ "patch_order":{ "@@assign":"last" } } } } } } } ``` # Amazon S3 策略 Amazon S3 策略允许您集中管理组织中各个账户的 Amazon S3 资源的大规模配置。Amazon S3 策略目前支持用于阻止公共访问的设置。 您可以使用 Amazon S3 策略来指定是启用还是禁用所有四个阻止公共访问设置，该规范将适用于选定账户中的所有 Amazon S3 资源。您可以使用 Amazon S3 策略中的 “阻止公共访问” 设置，在整个组织中实施一致的安全态势，并消除管理个人账户配置的运营开销。 ## 工作原理 当您将 Amazon S3 策略附加到组织实体时，它会定义适用于该范围内账户内所有 Amazon S3 资源的设置。这些配置会覆盖账户级别的设置，允许您集中管理 Amazon S3 设置。 Amazon S3 策略可以应用于整个组织、组织单位 (OUs) 或个人账户。加入组织的账户将根据其在组织层次结构中的位置自动继承任何 Amazon S3 政策。 分离行为：如果解除了 Amazon S3 政策，账户会自动恢复到之前的账户级别配置。Amazon S3 保留原始账户级别设置以实现无缝恢复。 ## 主要 功能 + 统一控制：所有四个阻止公共访问设置（BlockPublicAcls BlockPublicPolicy、 IgnorePublicAcls、、 RestrictPublicBuckets）都作为单个配置一起控制 + 自动继承：新账户根据其组织位置自动继承策略 + 覆盖保护：当组织策略处于活动状态时，防止账户级别的修改 + 无缝恢复：取消策略后，原始账户设置会被保留和恢复 ## 先决条件 在使用 Amazon S3 策略之前，请确保您已具备以下条件： + 处于全功能模式的 Amazon 组织 + 管理 Amazon Organizations 策略的权限（组织：CreatePolicyAttachPolicy、组织：等） + 为您的组织启用的 Amazon S3 策略类型 # 使用 Amazon S3 策略的最佳实践 最佳实践 在整个组织中实施 Amazon S3 策略时，遵循既定的最佳实践有助于确保成功部署和维护。 ## 简单开始并进行一些小更改 要简化调试，请先从简单策略开始，然后一次更改一个项目。在进行下一个更改之前，验证每个更改的行为和影响。此方法可以减少出现错误或意外结果时必须考虑的变量数量。 ## 建立审查流程 实施流程以监控新的策略属性，评估政策异常情况，并进行调整以保持与组织安全和运营要求的一致性。 ## 使用验证对您的 Amazon S3 政策的更改 DescribeEffectivePolicy 更改 Amazon S3 政策后，请查看更改级别以下的代表账户的有效政策。您可以使用 Amazon 管理控制台、 DescribeEffectivePolicy API 操作或其 Amazon CLI 或 Amazon SDK 变体之一来查看有效策略。确保您所做的更改对有效策略产生预期影响。 ## 沟通与培训 确保您的组织了解您的政策的目的和影响。就预期行为以及如何处理因执行策略而导致的失败提供明确的指导。 ## 为合法的公共访问需求做好计划 在实施组织级策略之前，请确定需要公共 Amazon S3 存储桶用于合法业务目的（例如静态网站托管）的账户。考虑使用 OU 级别或账户级别的政策附件将这些账户排除在外，或者将公共存储桶需求整合到专用账户中。 ## 监控策略执行情况 Amazon CloudTrail 用于监控策略附件和强制执行操作。设置 EventBridge 规则以自动响应违反政策或变更的情况。 # Amazon S3 策略语法和示例 [Amazon S3 策略是一个按照 JSON 规则构造的纯文本文件。](http://json.org)Amazon S3 策略的语法遵循所有管理策略类型的语法。有关更多信息，请参阅 [了解管理策略继承](orgs_manage_policies_inheritance_mgmt.md)。本主题重点介绍如何将该通用语法应用于 Amazon S3 策略的具体要求以及它们帮助管理的阻止公共访问设置。 以下 Amazon S3 策略示例显示了基本策略语法： ``` { "s3_attributes": { "public_access_block_configuration": { "@@assign": "all" } } } ``` ## Amazon S3 策略语法包括以下元素 `s3_attributes` Amazon S3 策略配置的顶级密钥。 `public_access_block_configuration` 定义组织的 “阻止公共访问” 行为。 `@@assign` 接受以下两个值之一的赋值运算符： + `"all"`-在组织级别启用所有四个 Amazon S3 阻止公共访问设置 + `"none"`-禁用组织级别的控制，允许个人账户管理自己的 “阻止公共访问权限” 设置 Amazon S3 阻止公共访问有四种控制公共访问的设置： 1. **BlockPublicAcls**-Amazon S3 将阻止应用于新添加的存储桶或对象的公共访问权限，并阻止为现有存储桶和对象创建新的公共访问控制列表 (ACLs)。此设置不会更改允许公众使用访问 Amazon S3 资源的任何现有权限 ACLs。 1. **BlockPublicPolicy**-Amazon S3 将阻止新的存储桶和接入点策略，这些策略授予对存储桶和对象的公开访问权限。此设置不会更改任何允许公众访问 Amazon S3 资源的现有策略。 1. **IgnorePublicAcls**-Amazon S3 将忽略所有授予 ACLs 对存储桶和对象的公开访问权限的内容。 1. **RestrictPublicBuckets**-Amazon S3 将忽略存储桶或访问点的公有和跨账户访问权限，其策略允许公众访问存储桶和对象。 设置`@@assign`为时`"all"`，所有四项设置都将在组织级别合并启用，从而提供全面保护，防止组织中所有账户的公开访问。 # Amazon Shield 网络安全总监政策 Amazon Shield Network Security Director 通过发现您的计算、网络和网络安全资源来帮助保护您的 Amazon 环境。Network Security Director 通过根据 Amazon 最佳实践和威胁情报分析网络拓扑和安全配置，评估每种资源的安全配置。 Amazon Shield Network Security Director 策略允许您集中启用和管理 Amazon 组织中各个账户的网络安全总监。使用 Network Security Director 策略 OUs，您可以指定哪些组织实体（根或账户）启用了网络安全总监。当有账户加入您的组织时，它们会根据其在组织层次结构中的位置自动继承适用的策略。这样可以确保随着组织的发展，对您的资源进行网络安全配置差距的分析。这些政策尊重现有的组织结构，为确定要分析哪些账户提供了灵活性。 Amazon Shield 网络安全控制器目前提供预览版。 ## 工作原理 当您将 Amazon Shield 网络安全控制器策略附加到组织实体时，该策略会自动为该范围内的所有成员帐户启用网络安全总监。此外，如果您通过注册授权管理员完成了 Amazon Shield 网络安全控制器的设置，则该帐户将可以集中查看组织中启用了网络安全控制器的帐户的 Amazon Shield 网络安全状况。 Amazon Shield Network Security Director 策略可以应用于整个组织、特定的组织单位 (OUs) 或个人帐户。加入组织或迁入附有策略的 OU 的账户会自动继承该策略，并且启用了 Network Security Director 并将其链接到 Amazon Shield 网络安全总监委派的管理员。Network Security Director 策略允许您启用网络分析，查看资源的网络拓扑和网络安全发现，并接收解决配置差距的补救建议。可以通过组织的 Network Security Director 委托管理员帐户来管理特定的配置设置和对个别发现的隐藏。 当你将 Amazon Shield Network Security Director 策略附加到你的组织或组织单位时， Amazon Organizations 会自动评估该策略并根据你定义的范围进行应用。策略实施逻辑遵循特定的冲突解决规则： + 区域同时出现在启用和禁用列表中时，禁用配置优先。例如，如果在启用和禁用配置中都列出了某个区域，则该区域的 Amazon Shield 网络安全控制器将被禁用。 + 当指定启用`ALL_SUPPORTED`时，除非明确禁用，否则 Amazon Shield 网络安全控制器将在所有当前和将来的区域中启用。这使您能够在 Amazon 扩展到新区域时保持全面的覆盖范围。 # Amazon Shield 网络安全总监策略入门 开始使用 在配置 Network Security Director 策略之前，请确保您了解先决条件和实施要求。本主题将指导您完成在组织中设置和管理这些策略的过程。 ## 开始前的准备工作 在实施 Amazon Shield 网络安全总监策略之前，请查看以下要求： + 您的账户必须是 Amazon 组织的一部分 + 您必须使用以下任一身份登录： + 组织的管理账户 + Or Amazon ganizations 委托管理员有权管理 Amazon Shield 网络安全总监策略 + 您必须为组织中的网络安全总监启用可信访问权限 + 您必须在组织根目录中启用 “网络安全总监” 策略类型 此外，请确认： + Amazon Shield 您要应用策略的区域支持网络安全总监 + 您的管理账户中配置了 Amazon Shield 网络安全总监服务相关角色。如果需要创建此角色，则可以通过运行直接创建它`aws iam create-service-linked-role --aws-service-name network-director.amazonaws.com`。 ## 实现步骤 要有效实施网络安全总监策略，请按顺序执行以下步骤。每个步骤都可确保配置正确，并有助于在设置过程中避免常见问题。这些步骤可以通过 Amazon Organizations 控制台、 Amazon 命令行界面 (Amazon CLI) 或 Amazon SDKs。 1. [为 Amazon Shield 网络安全控制器启用可信访问](orgs_integrate_services.md#orgs_how-to-enable-disable-trusted-access)。 1. [为您的组织启用 Amazon Shield 网络安全总监策略](enable-policy-type.md)。 1. [创建 Amazon Shield 网络安全总监策略](orgs_manage_policies_network_security_director_syntax.md)。 1. [将策略附加到您组织的根目录、组织单位或账户](orgs_policies_attach.md)。 1. [查看适用于账户的有效网络安全总监组合策略](orgs_manage_policies_effective.md)。 # Amazon Shield 网络安全总监策略语法和示例 网络安全总监策略遵循标准化的 JSON 语法，该语法定义了如何在整个组织中启用和配置网络安全总监。 Amazon Shield 网络安全总监策略是根据 Organizations 管理策略语法 Amazon 结构的 JSON 文档。它定义了哪些组织实体将自动启用 Amazon Shield 网络安全总监。 ## 基本策略结构 Amazon Shield 网络安全总监策略使用以下基本结构： ``` { "network_security_director": { "enablement": { "network_security_scan": { "enable_in_regions": { "@@assign": ["us-east-1", "eu-west-1"] }, "disable_in_regions": { "@@assign": [] } } }, } } } ``` ## 策略组件 Amazon Shield 网络安全总监策略包含以下关键组件： `network_security_director` 网络安全总监策略文档的顶级密钥，这是所有网络安全总监策略所必需的。 `enablement` 定义如何在整个组织中启用 Network Security Director，并包含扫描配置。 `network_security_scan` 定义网络安全扫描的强制配置。 `enable_in_regions` 区域设置的配置标识符。定义应在何处启用网络安全扫描。 `disable_in_regions` 区域设置的配置标识符。定义应在何处禁用网络安全扫描。