# IAM 中的跨账户资源访问
对于一些 Amazon 服务，您可以使用 IAM 授予对资源的跨账户访问权限。为此，您可以将资源策略直接附加到要共享的资源，也可以将角色用作代理。
要直接共享资源，要共享的资源必须支持[基于资源的策略](https://docs.amazonaws.cn/IAM/latest/UserGuide/introduction_access-management.html#intro-access-resource-based-policies)。与针对角色的基于身份的策略不同，基于资源的策略指定谁（哪个主体）可以访问该资源。
如果要访问另一个账户中不支持基于资源的策略的资源，请使用角色作为代理。
有关这些策略类型之间差异的详细信息，请参阅 [基于身份的策略和基于资源的策略](access_policies_identity-vs-resource.md)。
**注意**
IAM 角色和基于资源的策略仅在单个分区内跨账户委派访问权限。例如，假定您在标准 `aws` 分区的美国西部（北加利福尼亚）中有一个账户。您在 `aws-cn` 分区的中国也有一个账户。您不能使用中国账户中基于资源的策略，来允许标准 Amazon 账户中用户的访问权限。
## 使用角色进行跨账户访问
并非所有的 Amazon 服务都支持基于资源的策略。对于这些服务，在提供对多个服务的跨账户访问权限时，您可以使用跨账户 IAM 角色来集中管理权限。跨账户 IAM 角色是一种 IAM 角色，包含允许其他 Amazon 账户中的 IAM 主体担任该角色的[信任策略](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_roles.html#term_trust-policy)。简而言之，您可以在一个 Amazon 账户中创建一个角色，将特定权限委派给另一个 Amazon 账户。
有关将策略附加到 IAM 身份的信息，请参阅 [管理 IAM 策略](access_policies_manage.md)。
**注意**
当主体切换为某个角色，临时使用该角色的权限时，他们会放弃其原始权限，并获得分配给他们所担任之角色的权限。
让我们了解一下适用于需要访问客户账户的 APN 合作伙伴软件的整体流程。
1. 客户使用策略创建账户中的 IAM 角色，该角色允许访问 APN 合作伙伴所需的 Amazon S3 资源。在本示例中，角色名称为 `APNPartner`。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::bucket-name"
]
}
]
}
```
------
1. 然后，客户通过在 `APNPartner` 角色的 [信任策略](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_roles_create_for-custom.html) 中提供 APN 合作伙伴的 Amazon Web Services 账户 ID，指定合作伙伴的 Amazon 账户可以代入该角色。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/APN-user-name"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
1. 客户将角色的 Amazon 资源名称（ARN）提供给 APN 合作伙伴。ARN 是角色的完全限定名称。
```
arn:aws:iam::Customer-Account-ID:role/APNPartner
```
**注意**
我们建议在多租户情况下使用外部 ID。有关更多信息，请参阅 [访问第三方拥有的 Amazon Web Services 账户](id_roles_common-scenarios_third-party.md)。
1. 当 APN 合作伙伴的软件需要访问客户的账户时，软件会在 Amazon Security Token Service 中使用客户账户中角色的 ARN 调用 [AssumeRole](https://docs.amazonaws.cn/STS/latest/APIReference/API_AssumeRole.html) API。STS 返回允许软件执行其工作的临时 Amazon 凭证。
有关使用角色授予跨账户访问权限的另一个示例，请参阅 [在您拥有的其他 Amazon Web Services 账户 中 IAM 用户的访问权限](id_roles_common-scenarios_aws-accounts.md)。您也可以关注 [IAM 教程：使用 IAM 角色委托跨 Amazon 账户的访问权限](tutorial_cross-account-with-roles.md)。
## 使用基于资源的策略授予跨账户访问权限
当一个账户使用基于资源的策略通过另一个账户访问资源时，主体仍在可信账户中工作，并且无需放弃其权限来接收角色权限。换言之，主体既能够继续访问可信账户中的资源，又能继续访问信任账户中的资源。这对于向另一个账户中的共享资源复制信息或从中复制信息之类的任务非常有用。
可在基于资源的策略中指定的主体包括账户、IAM 用户、Amazon STS 联合用户主体、SAML 联合主体、OIDC 联合主体、IAM 角色、代入角色会话或 Amazon 服务。有关更多信息，请参阅[指定主体](https://docs.amazonaws.cn//IAM/latest/UserGuide/reference_policies_elements_principal.html#Principal_specifying)。
要了解您信任区域之外的账户（受信任的组织或账户）中的主体是否有权承担您的角色，请参阅[识别与外部实体共享的资源](https://docs.amazonaws.cn/IAM/latest/UserGuide/what-is-access-analyzer.html#what-is-access-analyzer-resource-identification)。
以下列表包括一些支持基于资源的策略的 Amazon 服务。有关支持向资源而非主体附加权限策略的更多 Amazon 服务的完整列表，请参阅 [使用 IAM 的 Amazon 服务](reference_aws-services-that-work-with-iam.md) 并寻找具有**基于资源**列中为**是**的服务。
+ **Amazon S3 存储桶** — 策略将附加到存储桶，但该策略可控制对存储桶和存储桶中对象的访问。有关更多信息，请参阅《Amazon Simple Storage Service 用户指南》**中的 [Amazon S3 的存储桶策略](https://docs.amazonaws.cn/AmazonS3/latest/userguide/bucket-policies.html)。在某些情况下，可能最好使用角色对 Amazon S3 进行跨账户访问。有关更多信息，请参阅 *Amazon Simple Storage Service 用户指南*中的[示例演练](https://docs.amazonaws.cn/AmazonS3/latest/userguide/example-walkthroughs-managing-access.html)。
+ **Amazon Simple Notification Service（Amazon SNS）主题** — 有关更多信息，请转至《Amazon Simple Notification Service 开发人员指南》**中的 [Amazon SNS 访问控制示例](https://docs.amazonaws.cn//sns/latest/dg/sns-access-policy-use-cases.html)。
+ **Amazon Simple Queue Service (Amazon SQS) 队列** — 有关更多信息，请转至 *Amazon Simple Queue Service 开发人员指南*中的[附录：访问策略语言](https://docs.amazonaws.cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-creating-custom-policies.html)
## 基于资源的策略，用于委派 Amazon 权限
如果资源向账户中的主体授予权限，则您随后可将这些权限委派给特定的 IAM 身份。身份是您账户中的用户、用户组或角色。可以通过将策略附加到身份来委派权限。您可以授予拥有资源的账户所允许的最多权限。
**重要**
在跨账户访问中，主体需要在身份策略**和**基于资源的策略中获得 `Allow`。
假定基于资源的策略允许您账户中的所有主体对资源进行完全管理访问。随后，您可以将完全访问权限、只读访问权限或任何其他部分访问权限委派给 Amazon 账户中的主体。或者，如果基于资源的策略仅允许列表权限，则您只能委派列表访问权限。如果您尝试委派的权限超出您的账户所拥有的权限，您的主体将只有列表访问权限。
有关如何做出这些决定的更多信息，请参阅[确定账户内的请求是被允许还是被拒绝](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_evaluation-logic_policy-eval-denyallow.html)。
**注意**
IAM 角色和基于资源的策略仅在单个分区内跨账户委派访问权限。例如，您不能在标准 `aws` 分区的账户与 `aws-cn` 分区中的账户之间添加跨账户访问权限。
例如，假定您管理 `AccountA` 和 `AccountB`。在 AccountA 中，您将有名为 `BucketA` 的 Amazon S3 存储桶。
![\[为 Amazon S3 存储桶创建的基于资源的策略向 AccountA 提供对 AccountB 的权限。\]](http://docs.amazonaws.cn/IAM/latest/UserGuide/images/access_policies-cross-account.png)
1. 您将基于资源的策略附加到 `BucketA`，这将允许 AccountB 中的所有主体对存储桶中的对象进行完全访问。这些主体可以创建、读取或删除该存储桶中的任何对象。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PrincipalAccess",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "s3:*",
"Resource": "arn:aws:s3:::BucketA/*"
}
]
}
```
------
AccountA 通过在基于资源的策略中将 AccountB 指定为主体来向 AccountB 提供对 BucketA 的完全访问权限。这样，AccountB 有权对 BucketA 执行任何操作，AccountB 管理员可向其在 AccountB 中的用户委派访问权限。
AccountB 根用户具有授予给该账户的所有权限。因此，根用户具有对 BucketA 的完全访问权限。
1. 在 AccountB 中，将策略附加到名为 User2 的 IAM 用户。该策略允许用户对 BucketA 中的对象进行只读访问。这意味着，User2 可以查看对象，但不能创建、编辑或删除对象。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect" : "Allow",
"Action" : [
"s3:Get*",
"s3:List*" ],
"Resource" : "arn:aws:s3:::BucketA/*"
}
]
}
```
------
AccountB 可委派的最大访问级别是授予给账户的访问级别。在此情况下，基于资源的策略授予了对 AccountB 的完全访问权限，但仅向 User2 授予了只读访问权限。
AccountB 管理员未向 User1 授予访问权限。默认情况下，除非明确授予，否则用户没有任何权限，因此 User1 没有对 BucketA 的访问权限。
IAM 将在主体发出请求时对主体的权限进行评估。因此，如果您使用通配符（\$1）向用户授予对资源的完全访问权限，则主体可以访问您的 Amazon 账户有权访问的任何资源。甚至对于您在创建用户策略后添加或获得其访问权的资源也是如此。
在上述示例中，如果 AccountB 已将允许对所有账户中的所有资源进行完全访问的策略附加到 User2，则 User2 将自动具有 AccountB 有权访问的任何资源的访问权限。这包括 BucketA 访问权限以及由 AccountA 中的基于资源的策略授予的对任何其他资源的访问权限。
有关角色的复杂用法（例如，授予对应用程序和服务的访问权限）的更多信息，请参阅 [IAM 角色的常见场景](id_roles_common-scenarios.md)。
**重要**
仅向信任实体授予访问权限，并提供最低级别的访问权限。只要可信实体是另一个 Amazon 账户，就可以授予任何 IAM 主体访问您的资源的权限。可信 Amazon 账户可委派的访问权限范围仅限于它所获得的访问权限；它委派的权限不能超出账户本身所获得的访问权限。
有关权限、策略以及用于编写策略的权限策略语言的信息，请参阅[适用于 Amazon 资源的 Access Management](access.md)。