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

# 与其他 AWS Organizations 人一起使用 AWS 服务
<a name="orgs_integrate_services"></a>

您可以使用可*信访问权限*来启用您指定的受支持 AWS 服务（称为*可信服务*），以代表您在组织及其账户中执行任务。这涉及向可信服务授予权限，但*不会*以其他方式影响用户或角色的权限。当您允许访问时，信任服务可以在您组织的每个账户中创建一个名为*服务相关角色* 的 IAM 角色（只要需要该角色）。该角色具有允许可信服务执行该服务文档中所述任务的权限策略。这允许您指定您希望可信服务在代表您的组织账户中保持的设置和配置详细信息。信任服务仅在需要对账户执行管理操作时才会创建服务相关角色，而不一定在组织的所有账户中执行管理操作。<a name="important-note-about-integration"></a>

**重要**  
当该选项可用时，我们***强烈建议***您***仅***使用可信服务的控制台或其 AWS CLI 或 API 等效操作来启用和禁用可信访问。这使得信任服务在启用信任访问权限时执行任何必需的初始化，例如在禁用信任访问权限时创建任何必需的资源和任何必需的资源清理。  
有关如何使用信任服务启用或禁用对组织的信任服务访问的信息，请参阅[AWS 服务 你可以和它一起使用 AWS Organizations](orgs_integrate_services_list.md)中**了解详情**链接下的**支持信任访问权限**列。  
如果您使用 Organizations 控制台、CLI 命令或 API 操作禁用访问，则会导致发生以下操作：  
服务不能再在您组织的账户中创建服务相关角色。这意味着该服务无法代表您对组织中的任何新账户执行操作。该服务仍然可以在旧账户中执行操作，直到服务完全从 AWS Organizations中清理。
该服务不能再在组织中的成员账户中执行任务，除非附加到您的角色的 IAM policy 明确允许这些操作。这包括从成员账户到管理账户或委托管理员账户（如果相关）的任何数据聚合。
有些服务会检测到这一点并清理与集成相关的所有剩余数据或资源，而其他服务则停止访问组织，但会将所有历史数据和配置保留在合适位置，以支持重新启用集成的可能性。
相反，使用其他服务的控制台或命令禁用集成可确保其他服务可以清理仅用于集成的任何资源。服务清除组织账户中的资源的方式取决于该服务。有关更多信息，请参阅有关其他 AWS 服务的文档。

## 允许可信访问所需的权限
<a name="orgs_trusted_access_perms"></a>

可信访问需要两个服务的权限： AWS Organizations 和可信服务。要允许可信访问，请选择以下场景之一：
+ 如果您拥有同时拥有同时 AWS Organizations 拥有可信服务权限的证书，请使用可信服务提供的工具（控制台或 AWS CLI）启用访问权限。这允许该服务 AWS Organizations 代表您启用可信访问权限，并创建该服务在您的组织中运行所需的任何资源。

  这些凭证的最低权限如下：
  + `organizations:EnableAWSServiceAccess`。您还可以将 `organizations:ServicePrincipal` 条件键与此操作搭配使用，以将这些操作发出的请求限制为已批准的服务委托人名称列表。有关更多信息，请参阅 [条件键](orgs_permissions_overview.md#orgs_permissions_conditionkeys)。
  + `organizations:ListAWSServiceAccessForOrganization`— 如果您使用 AWS Organizations 控制台，则为必填项。
  + 可信服务所需的最低权限取决于此服务。有关更多信息，请参阅可信服务的文档。
+ 如果一个人拥有在中具有权限的证书， AWS Organizations 但其他人拥有在可信服务中拥有权限的证书，请按以下顺序执行这些步骤：

  1. 拥有权限的凭证的人员 AWS Organizations 应使用 AWS Organizations 控制台 AWS CLI、或 AWS SDK 为可信服务启用可信访问权限。这为另一服务授予在执行以下步骤 (步骤 2) 后在组织中执行其所需配置的权限。

     最低 AWS Organizations 权限如下：
     + `organizations:EnableAWSServiceAccess`
     + `organizations:ListAWSServiceAccessForOrganization`— 只有在使用 AWS Organizations 控制台时才需要

     有关在中启用可信访问的步骤 AWS Organizations，请参阅[如何允许或禁止可信访问](#orgs_how-to-enable-disable-trusted-access)。

  1. 拥有在可信服务中具有权限的凭证的人可启用此服务以使用 AWS Organizations。这指示此服务执行任何所需初始化 (如，创建可信服务在组织中运行所需的任何资源)。有关信息，请参阅[AWS 服务 你可以和它一起使用 AWS Organizations](orgs_integrate_services_list.md)处的服务特定说明。

## 禁止可信访问所需的权限
<a name="orgs_trusted_access_disable_perms"></a>

当您不再需要允许可信服务在您的组织或其账户上运行时，请选择以下场景之一。

**重要**  
禁止可信服务访问***不*** 会阻止具有相应权限的用户和角色使用该服务。要完全阻止用户和角色访问 AWS 服务，您可以移除授予该访问权限的 IAM 权限，也可以使用中的[服务控制策略 (SCPs)](orgs_manage_policies_scps.md) AWS Organizations。  
您只能 SCPs 申请成员账户。 SCPs 不适用于管理账户。建议您[不要在管理账户中运行服务。](orgs_best-practices_mgmt-acct.md#bp_mgmt-acct_use-mgmt)取而代之的是，在成员帐户中运行它们，您可以通过使用来控制安全性 SCPs。
+ 如果您拥有同时 AWS Organizations 对可信服务具有权限的证书，请使用可信服务可用的工具（控制台或 AWS CLI）禁用访问权限。该服务之后将通过删除不再需要的资源并代表您在 AWS Organizations 中禁止此服务的可信访问来清理。

  这些凭证的最低权限如下：
  + `organizations:DisableAWSServiceAccess`。您还可以将 `organizations:ServicePrincipal` 条件键与此操作搭配使用，以将这些操作发出的请求限制为已批准的服务委托人名称列表。有关更多信息，请参阅 [条件键](orgs_permissions_overview.md#orgs_permissions_conditionkeys)。
  + `organizations:ListAWSServiceAccessForOrganization`— 如果您使用 AWS Organizations 控制台，则为必填项。
  + 可信服务所需的最低权限取决于此服务。有关更多信息，请参阅可信服务的文档。
+ 如果具有权限的证书 AWS Organizations 不是在可信服务中具有权限的证书，请按以下顺序执行以下步骤：

  1. 在可信服务中具有权限的人首先使用此服务禁止访问。这将指示可信服务通过删除可信服务所需的资源进行清理。有关信息，请参阅[AWS 服务 你可以和它一起使用 AWS Organizations](orgs_integrate_services_list.md)处的服务特定说明。

  1. 然后，拥有权限的 AWS Organizations 人员可以使用 AWS Organizations 控制台 AWS CLI、或 S AWS DK 来禁用可信服务的访问权限。这将从组织及其账户中删除可信服务的权限。

     最低 AWS Organizations 权限如下：
     + `organizations:DisableAWSServiceAccess`
     + `organizations:ListAWSServiceAccessForOrganization`— 只有在使用 AWS Organizations 控制台时才需要

     有关在中禁用可信访问的步骤 AWS Organizations，请参阅[如何允许或禁止可信访问](#orgs_how-to-enable-disable-trusted-access)。

## 如何允许或禁止可信访问
<a name="orgs_how-to-enable-disable-trusted-access"></a>

如果您仅拥有其他服务的权限， AWS Organizations 并且想要代表其他 AWS 服务的管理员启用或禁用对组织的可信访问权限，请使用以下步骤。

**重要**  
当该选项可用时，我们***强烈建议***您***仅***使用可信服务的控制台或其 AWS CLI 或 API 等效操作来启用和禁用可信访问。这使得信任服务在启用信任访问权限时执行任何必需的初始化，例如在禁用信任访问权限时创建任何必需的资源和任何必需的资源清理。  
有关如何使用信任服务启用或禁用对组织的信任服务访问的信息，请参阅[AWS 服务 你可以和它一起使用 AWS Organizations](orgs_integrate_services_list.md)中**了解详情**链接下的**支持信任访问权限**列。  
如果您使用 Organizations 控制台、CLI 命令或 API 操作禁用访问，则会导致发生以下操作：  
服务不能再在您组织的账户中创建服务相关角色。这意味着该服务无法代表您对组织中的任何新账户执行操作。该服务仍然可以在旧账户中执行操作，直到服务完全从 AWS Organizations中清理。
该服务不能再在组织中的成员账户中执行任务，除非附加到您的角色的 IAM policy 明确允许这些操作。这包括从成员账户到管理账户或委托管理员账户（如果相关）的任何数据聚合。
有些服务会检测到这一点并清理与集成相关的所有剩余数据或资源，而其他服务则停止访问组织，但会将所有历史数据和配置保留在合适位置，以支持重新启用集成的可能性。
相反，使用其他服务的控制台或命令禁用集成可确保其他服务可以清理仅用于集成的任何资源。服务清除组织账户中的资源的方式取决于该服务。有关更多信息，请参阅其他 AWS 服务的文档。

------
#### [ AWS 管理控制台 ]

**启用信任服务访问权限**

1. 登录 [AWS Organizations 控制台](https://console.aws.amazon.com/organizations/v2)。您必须以 IAM 用户的身份登录，担任 IAM 角色；或在组织的管理账户中以根用户的身份登录（[不推荐](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)）。

1. 在 **[Services (服务)](https://console.aws.amazon.com/organizations/v2/home/services)** 页面上，找到要启用的服务所在的行，然后选择其名称。

1. 选择 **Enable trusted access (启用可信访问)**。

1. 在确认对话框中，选中 **Show the option to enable trusted access (显示启用信任访问权限的选项)**，在框中输入 **enable**，然后选择 **Enable trusted access (启用信任访问权限)**。

1. 如果您正在*启用*访问权限，请告诉其他 AWS 服务的管理员，他们现在可以启用其他服务了 AWS Organizations。

**禁用信任服务访问权限**

1. 登录 [AWS Organizations 控制台](https://console.aws.amazon.com/organizations/v2)。您必须以 IAM 用户的身份登录，担任 IAM 角色；或在组织的管理账户中以根用户的身份登录（[不推荐](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)）。

1. 在 **[Services (服务)](https://console.aws.amazon.com/organizations/v2/home/services)** 页面上，找到要禁用的服务所在的行，然后选择其名称。

1. 请一直等到其他服务的管理员告知您已禁用此服务且已清理资源。

1. 在确认对话框中输入 **disable**，然后选择 **Disable trusted access (禁用信任访问权限)**。

------
#### [ AWS CLI, AWS API ]

**允许或禁止信任服务访问**  
您可以使用以下 AWS CLI 命令或 API 操作来启用或禁用可信服务访问权限：
+ AWS CLI: AWS 组织 [enable-aws-service-access](https://docs.aws.amazon.com/cli/latest/reference/organizations/enable-aws-service-access.html)
+ AWS CLI: AWS 组织 [disable-aws-service-access](https://docs.aws.amazon.com/cli/latest/reference/organizations/disable-aws-service-access.html)
+ AWS API：[启用AWSService访问权限](https://docs.aws.amazon.com/organizations/latest/APIReference/API_EnableAWSServiceAccess.html)
+ AWS API：[禁用AWSService访问权限](https://docs.aws.amazon.com/organizations/latest/APIReference/API_DisableAWSServiceAccess.html)

------

## AWS Organizations 和服务相关角色
<a name="orgs_integrate_services-using_slrs"></a>

AWS Organizations 使用 [IAM 服务相关角色](https://aws.amazon.com/blogs/security/introducing-an-easier-way-to-delegate-permissions-to-aws-services-service-linked-roles/)使可信服务能够在您组织的成员账户中代表您执行任务。当您配置可信服务并授权其与您的组织集成时，该服务可请求 AWS Organizations 在其成员账户中创建服务相关角色。可信服务按需异步执行此操作，同时并非所有组织账户都需要。此服务相关角色具有预定义的 IAM 权限，此权限允许信任服务在账户内仅执行特定任务。一般而言， AWS 将管理所有服务相关角色，这意味着，您通常无法更改角色或附加的策略。

为实现上述操作，当您在组织中创建账户或接受邀请以将现有账户加入组织时， AWS Organizations 将使用名为 `AWSServiceRoleForOrganizations` 的服务相关角色预置成员账户。只有 AWS Organizations 服务本身才能担任此角色。该角色具有允许 AWS Organizations 为其他 AWS 服务人创建服务相关角色的权限。此服务相关角色存在于所有组织中。

如果您的组织仅启用了[整合账单功能](orgs_getting-started_concepts.md#feature-set-cb-only)（但我们建议不要这样做），则绝不使用名为 `AWSServiceRoleForOrganizations` 的服务相关角色并且可删除它。如果您之后要在组织中启用[所有功能](orgs_getting-started_concepts.md#feature-set-all)，则此角色是必需的并且您必须还原它。在您开始启用所有功能的流程时，将进行以下检查：
+ **对于*已受邀加入*组织的每个成员账户** – 账户管理员将收到同意启用所有功能的请求。要成功同意此请求，如果服务相关角色 (`organizations:AcceptHandshake`) 不存在，此管理员必须同时具有 * *和`iam:CreateServiceLinkedRole` `AWSServiceRoleForOrganizations` 权限。如果 `AWSServiceRoleForOrganizations` 角色已存在，则管理员只需 `organizations:AcceptHandshake` 权限即可同意该请求。管理员同意请求后，如果服务相关角色尚不存在，则 AWS Organizations 创建该角色。
+ **对于已在组织中*创建*的每个成员账户** – 账户管理员将收到重新创建服务相关角色的请求。（成员账户的管理员不会收到启用所有功能的请求，因为管理账户（此前称为“主账户”）的管理员被视为所创建成员账户的所有者。）如果成员账户管理员同意该请求，则 AWS Organizations 将创建服务相关角色。管理员必须同时具有 `organizations:AcceptHandshake` *和* `iam:CreateServiceLinkedRole` 权限才能成功接受握手。

在组织中启用所有功能后，您无法再删除任何账户中的 `AWSServiceRoleForOrganizations` 服务相关角色。

**重要**  
AWS Organizations SCPs 永远不会影响与服务相关的角色。这些角色将免受任何 SCP 限制。

## 使用 AWSServiceRoleForDeclarativePoliciesEC2报告服务相关角色
<a name="ec2-report-policy"></a>

Organizations 使用 `AWSServiceRoleForDeclarativePoliciesEC2Report` 服务关联角色来描述成员账户的账户属性状态，以创建声明性策略报告。角色的权限在 [AWS 托管策略：DeclarativePoliciesEC2Report](orgs_reference_available-policies.md#security-iam-awsmanpol-DeclarativePoliciesEC2Report) 中定义。