基于身份的策略与基于资源的策略

AWS 中的权限来自附加策略的两个位置：附加到身份（用户、组或角色），或附加到资源（例如 S3 存储桶或 KMS 密钥）。了解适用的是哪种类型，以及两者如何组合，对考试至关重要，因为跨账户访问完全取决于这一差异。

基于身份的策略附加到 IAM 主体，用于定义该主体可以执行的操作。它没有 Principal 元素，因为主体就是策略所附加到的对象。这类策略可以是 AWS 托管、客户托管或内联策略，也是授予权限最常见的方式。

基于资源的策略直接附加到资源，并包含用于指定获准访问者的 Principal 元素。示例包括 S3 存储桶策略、KMS 密钥策略、SQS 队列策略和 Lambda 函数策略。它们会在同一资源上同时指定访问者（Principal）和操作（Action）。

此 S3 存储桶策略授予另一个账户读取权限。Principal 指定了受信任的账户，而只有基于资源的策略才能做到这一点。

在单个账户内，基于身份的策略和基于资源的策略会合并为并集：只要任一策略授予权限，且没有任何策略拒绝，请求就会被允许。因此，只要用户策略或存储桶策略允许访问，就可以访问 S3 对象。任一方开放访问就足够了。

对于跨账户访问，规则更加严格：双方都必须允许访问。主体需要有允许执行该操作的基于身份的策略，另一账户中的基于资源的策略也必须向该主体授予访问权限。缺少任何一方，请求都会被拒绝。这是考试重点考查的区别。

角色上的信任策略从技术上说属于基于资源的策略，这就是为什么跨账户承担角色需要同时具备信任策略和调用方的 sts:AssumeRole 身份权限。将信任策略识别为基于资源的策略，有助于统一理解访问权限的授予方式。

并非所有服务都支持基于资源的策略。支持该功能的主要服务包括：S3、KMS、SQS、SNS、Lambda、Secrets Manager 和 ECR。当服务不支持资源策略时，必须改用承担角色的方式授予跨账户访问权限。考试可能会考查某种方法对于指定服务是否可行。

对于“这个团队可以执行这些操作”之类的一般权限，请使用基于身份的策略。当您必须向特定外部主体授予访问权限、在支持该功能的服务上启用跨账户共享，或设置随资源本身一同生效的权限时，请使用基于资源的策略。

由于访问权限可能来自任一方，审计时必须检查双方。IAM Access Analyzer 会检查基于资源的策略，以查找与外部或公开共享的资源。策略模拟和上次访问数据有助于检查身份一侧。完整的审查绝不能只查看一种类型。

同账户访问是并集（任一策略都可以允许访问），而跨账户访问要求身份策略和资源策略双方都允许访问。身份策略没有 Principal，资源策略则有。应根据场景匹配策略类型，并记住哪些服务支持基于资源的策略。

基于身份的策略附加到主体，不包含 Principal 元素；基于资源的策略附加到资源，并指定 Principal。同账户访问是两者的并集；跨账户访问要求双方都允许。只有部分服务（S3、KMS、SQS、SNS、Lambda、Secrets Manager、ECR）支持资源策略；否则应使用承担角色的方式。