使用管理组织的访问权限 AWS Organizations - AWS Organizations

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

使用管理组织的访问权限 AWS Organizations

所有 AWS 资源,包括组织中的根OUs、账户和策略,均归属于 AWS 账户,创建或访问资源的权限受权限策略的约束。对于一个组织,其管理账户拥有所有资源。账户管理员可以通过为IAM身份(用户、群组和角色)附加权限策略来控制对 AWS 资源的访问权限。

注意

账户管理员 (或管理员用户) 是具有管理员权限的用户。有关更多信息,请参阅《IAM用户指南》IAM中的安全最佳实践

在授予权限时,您要决定谁获得权限,获得对哪些资源的权限,以及您允许对这些资源执行的具体操作。

默认情况下,IAM用户、组和角色没有权限。作为组织管理账户的管理员,您可以执行管理任务或将管理员权限委托给管理账户中的其他IAM用户或角色。为此,您需要为IAM用户、组或角色附加IAM权限策略。默认情况下,用户没有权限;这有时称为隐式拒绝。该策略将使用显式允许 覆盖隐式拒绝,这将指定用户可以执行哪些操作以及可对哪些资源执行这些操作。如果将权限授予了角色,则组织中其他账户的用户可以代入该角色。

AWS Organizations 资源和运营

本节讨论 AWS Organizations 概念如何映射到它们的IAM等效概念。

资源

在中 AWS Organizations,您可以控制对以下资源的访问权限:

  • 组织层次结构OUs的根源和构成组织层次结构的根源

  • 组织的成员账户

  • 您附加到组织中实体的账户

  • 用于更改组织状态的握手

这些资源中的每一个都有一个与之关联的唯一 Amazon 资源名称 (ARN)。您可以通过在权限策略的Resource元素ARN中指定资源来控制对资源的访问IAM权限。有关中使用的资源ARN格式的完整列表 AWS Organizations,请参阅《服务授权参考》 AWS Organizations中定义的资源类型

操作

AWS 提供了一组操作来使用组织中的资源。利用这些操作,您可以对资源进行创建、列出、修改、访问其内容以及删除。大多数操作都可以在IAM策略的Action元素中引用,以控制谁可以使用该操作。有关可在IAM策略中用作权限的 AWS Organizations 操作列表,请参阅《服务授权参考》中组织定义的操作

在将 ActionResource 组合到一个权限策略 Statement 中后,可以准确控制可对哪些资源执行该组特定操作。

条件键

AWS 提供了条件键,您可以通过查询这些条件键来对某些操作进行更精细的控制。您可以在IAM策略Condition元素中引用这些条件键来指定必须满足的其他条件才能将该语句视为匹配。

以下条件键特别适用于以下用途 AWS Organizations:

  • aws:PrincipalOrgID – 简化在基于资源的策略中指定 Principal 元素的过程。此全局密钥提供了一种替代方法,而不是列出组织 AWS 账户 中所有人的所有账户IDs。您可以在 元素中指定组织 IDCondition,而不是列出作为组织成员的所有账户。

    注意

    此全局条件也适用于组织的管理账户。

    有关更多信息,请参阅《IAM用户指南PrincipalOrgID中对AWS 全局条件上下文键的描述。

  • aws:PrincipalOrgPaths – 使用此条件键可以匹配特定组织根、OU 或其子项的成员。当发出请求的委托人(root 用户、IAM用户或角色)位于指定的组织路径中时,aws:PrincipalOrgPaths条件键返回 true。路径是 AWS Organizations 实体结构的文本表示形式。有关路径的更多信息,请参阅IAM用户指南》中的了解 AWS Organizations 实体路径。有关使用此条件键的更多信息,请参阅《IAM用户指南》PrincipalOrgPaths中的 a ws:

    例如,以下条件元素匹配同一组织OUs中两个成员中任一的成员。

    "Condition": { "ForAnyValue:StringLike": { "aws:PrincipalOrgPaths": [ "o-a1b2c3d4e5/r-f6g7h8i9j0example/ou-def0-awsbbbbb/", "o-a1b2c3d4e5/r-f6g7h8i9j0example/ou-jkl0-awsddddd/" ] } }
  • organizations:PolicyType— 您可以使用此条件键将 Organizations 策略相关的API操作限制为仅适用于指定类型的组织策略。您可以将此条件键应用于任何包含与 Organizations 策略交互的操作的策略语句。

    可以将以下值与此条件键结合使用:

    • SERVICE_CONTROL_POLICY

    • BACKUP_POLICY

    • TAG_POLICY

    • CHATBOT_POLICY

    • AISERVICES_OPT_OUT_POLICY

    例如,以下示例策略允许用户执行任何 Organizations 操作。但是,如果用户执行采用策略参数的操作,则仅当指定的策略是标记策略时才允许该操作。如果用户指定任何其他类型的策略,则该操作将失败。

    { "Version": "2012-10-17", "Statement": [ { "Sid": "IfTaggingAPIThenAllowOnOnlyTaggingPolicies", "Effect": "Allow", "Action": "organizations:*", "Resource": "*", "Condition": { "StringLikeIfExists": { "organizations:PolicyType": [ "TAG_POLICY" ] } } } ] }
  • organizations:ServicePrincipal— 如果您使用 E A nableAWSService c cess 或 D isableAWSService Access 操作启用或禁用对其他 AWS 服务的可信访问,则可用作条件。您可以使用 organizations:ServicePrincipal 来将这些操作发出的请求限制为已批准的服务委托人名称列表。

    例如,以下策略允许用户仅在启用和禁用可信访问 AWS Firewall Manager 时进行指定 AWS Organizations。

    { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowOnlyAWSFirewallIntegration", "Effect": "Allow", "Action": [ "organizations:EnableAWSServiceAccess", "organizations:DisableAWSServiceAccess" ], "Resource": "*", "Condition": { "StringLikeIfExists": { "organizations:ServicePrincipal": [ "fms.amazonaws.com" ] } } } ] }

有关可在IAM策略中用作权限 AWS Organizations的所有特定条件密钥的列表,请参阅《服务授权参考》 AWS Organizations中的条件密钥

了解资源所有权

AWS 账户 拥有在账户中创建的资源,无论谁创建了这些资源。具体而言,资源所有者是 AWS 账户 对资源创建请求进行身份验证的委托人实体(即根IAM用户、用户或IAM角色)。对于组织来说,这始终是管理账户。您无法从成员账户调用大多数创建或访问组织资源的操作。以下示例说明了它的工作原理:

  • 如果您使用管理账户的根账户凭证创建 OU,您的管理账户即为该资源的拥有者。(在中 AWS Organizations,资源是 OU)。

  • 如果您在管理账户中创建IAM用户并向该用户授予创建 OU 的权限,则该用户可以创建 OU。但是,管理账户(即该用户所属的账户)拥有 OU 资源。

  • 如果您在管理账户中创建具有创建 OU 权限的IAM角色,则任何能够担任该角色的人都可以创建 OU。管理账户(即该角色而非代入用户所属的账户)拥有 OU 资源。

管理对 资源的访问

权限策略规定谁可以访问哪些内容。下一节介绍创建权限策略时的可用选项。

注意

本节讨论IAM在的上下文中使用 AWS Organizations。它不提供有关IAM服务的详细信息。有关完整的IAM文档,请参阅《IAM用户指南》。有关IAM策略语法和描述的信息,请参阅《IAM用户指南》中的IAMJSON策略参考

附加到身份的策略称为基于IAM身份的策略(IAM策略)。附加到资源的策略称为基于资源的策略。 AWS Organizations 仅支持基于身份的策略(IAM策略)。

基于身份的权限策略(IAM 策略)

您可以将策略附加到IAM身份,以允许这些身份对 AWS 资源执行操作。例如,您可以执行以下操作:

  • 将@@ 权限策略附加到您账户中的用户或群组-要向用户授予创建 AWS Organizations 资源(例如服务控制策略 (SCP) 或 OU 的权限,您可以将权限策略附加到该用户或用户所属的群组。用户或组必须位于组织的管理账户中。

  • 将@@ 权限策略附加到角色(授予跨账户权限)-您可以将基于身份的权限策略附加到IAM角色,以向组织授予跨账户访问权限。例如,管理账户中的管理员可以创建一个角色来向成员账户中的用户授予跨账户权限,如下所示:

    1. 管理账户管理员创建一个IAM角色并向该角色附加权限策略,该策略向该角色授予对组织资源的权限。

    2. 管理账户管理员向将成员账户 ID 标识为能够担任该角色的 Principal 的角色附加信任策略。

    3. 随后,成员账户管理员可以委派权限以将角色代入成员账户中的任何用户。通过执行此操作,成员账户中的用户将能够在管理账户和组织中创建和访问资源。如果您想向 AWS 服务授予担任该角色的权限,则信任策略中的委托人也可以是 AWS 服务委托人。

    有关使用委派权限IAM的更多信息,请参阅《IAM用户指南》中的访问管理

以下是允许用户在您的组织中执行 CreateAccount 操作的策略示例。

{ "Version":"2012-10-17", "Statement":[ { "Sid":"Stmt1OrgPermissions", "Effect":"Allow", "Action":[ "organizations:CreateAccount" ], "Resource":"*" } ] }

您也可以在策略Resource元素ARN中提供部分内容以指明资源的类型。

{ "Version":"2012-10-17", "Statement":[ { "Sid":"AllowCreatingAccountsOnResource", "Effect":"Allow", "Action":"organizations:CreateAccount", "Resource":"arn:aws:organizations::*:account/*" } ] }

您也可以拒绝创建不包含所创建账户的特定标签的账户。

{ "Version":"2012-10-17", "Statement":[ { "Sid":"DenyCreatingAccountsOnResourceBasedOnTag", "Effect":"Deny", "Action":"organizations:CreateAccount", "Resource":"*", "Condition":{ "StringEquals":{ "aws:ResourceTag/key":"value" } } } ] }

有关用户、群组、角色和权限的更多信息,请参阅《用户指南》中的IAM身份(用户、IAM用户组和角色)

基于资源的策略

一些服务(如 Amazon S3)支持基于资源的权限策略。例如,您可以将策略附加到 Amazon S3 存储桶,以管理对该存储桶的访问权限。 AWS Organizations 目前不支持基于资源的策略。

指定策略元素:操作、条件、效果和资源

对于每种 AWS Organizations 资源,该服务都定义了一组或多项API操作,这些操作或操作可以以某种方式与该资源交互或操纵该资源。要授予这些操作的权限,请 AWS Organizations 定义一组可以在策略中指定的操作。例如,对于 OU 资源, AWS Organizations 定义如下操作:

  • AttachPolicyDetachPolicy

  • CreateOrganizationalUnitDeleteOrganizationalUnit

  • ListOrganizationalUnitsDescribeOrganizationalUnit

在某些情况下,执行一项API操作可能需要多个操作的权限,并且可能需要对多个资源的权限。

以下是可以在IAM权限策略中使用的最基本元素:

  • Action – 使用此关键字标识要允许或拒绝的操作。例如,根据指定的Effectorganizations:CreateAccount允许或拒绝用户执行 AWS Organizations CreateAccount操作的权限。有关更多信息,请参阅《IAM用户指南》中的IAMJSON策略元素:操作

  • 资源-使用此关键字ARN指定策略声明适用的资源。有关更多信息,请参阅《IAM用户指南》中的IAMJSON策略元素:资源

  • Condition – 使用此关键字指定要应用策略语句必须满足的条件。Condition 通常指定为使策略匹配必须存在的额外情况。有关更多信息,请参阅《IAM用户指南》中的IAMJSON策略元素:条件

  • Effect – 使用此关键字指定策略语句是允许还是拒绝对资源进行的操作。如果没有明确授予 (或允许) 对资源的访问权,则隐式拒绝访问。您也可以明确拒绝对资源的访问权,这样做可确保用户无法对指定资源执行指定操作,即使其他策略授予了访问权也是如此。有关更多信息,请参阅《IAM用户指南》中的IAMJSON策略元素:效果

  • 委托人 — 在基于身份的策略(IAM策略)中,策略所关联的用户自动且隐式地成为委托人。对于基于资源的策略,您可以指定要获得权限的用户、账户、服务或其他实体(仅适用于基于资源的策略)。 AWS Organizations 目前仅支持基于身份的策略,不支持基于资源的策略。

要了解有关IAM策略语法和描述的更多信息,请参阅《IAM用户指南》中的IAMJSON策略参考