对单个账户内的请求进行策略评估
AWS 如何评估策略取决于适用于请求上下文的策略类型。可在单个 AWS 账户 中使用以下策略类型,它们按使用频率顺序列出。有关这些策略类型的更多信息,请参阅AWS Identity and Access Management 中的策略和权限。要了解 AWS 如何评估跨账户访问策略,请参阅跨账户策略评估逻辑。
-
基于身份的策略 — 基于身份的策略附加到 IAM 身份(用户、用户组或角色)并向 IAM 实体(用户和角色)授予权限。如果仅基于身份的策略适用于请求,则 AWS 检查所有这些策略以找到至少一个
Allow
。 -
基于资源的策略:基于资源的策略为策略中指定的主体授予权限。权限定义主体可以对策略附加到的资源执行哪些操作。
-
IAM 权限边界:权限边界是一项功能,借助该功能,您可以设置基于身份的策略可以授予 IAM 实体(用户或角色)的最大权限。当您设置实体的权限边界时,该实体只能执行其基于身份的策略和其权限边界同时允许的操作。某些情况下,权限边界中的隐式拒绝可能会限制由基于资源的策略所授予的权限。要了解更多信息,请参阅 AWS 执行代码逻辑如何评估允许或拒绝访问的请求。
-
AWS Organizations 服务控制策略(SCP):Organizations SCP 指定组织或组织单位(OU)中账户内的主体的最大权限。SCP 适用于成员账户中的主体,包括每个 AWS 账户根用户。如果 SCP 存在,仅当 SCP 允许该操作时,基于身份和基于资源的策略向成员账户中的主体授予的权限才有效。唯一的例外是组织管理账户中的主体和服务相关角色。
-
AWS Organizations 资源控制策略(RCP):Organizations RCP 指定组织或组织单位(OU)中账户内的资源的最大权限。RCP 适用于成员账户中的资源,并影响主体的有效权限,包括 AWS 账户根用户,无论主体是否属于您的组织。RCP 不适用于组织管理账户中的资源和服务相关角色进行的调用。
-
会话策略:会话策略是一些策略,在以编程方式为角色或联合身份用户创建临时会话时,这些策略将作为参数进行传递。要以编程方式创建角色会话,请使用
AssumeRole*
API 操作之一。在执行该操作并传递会话策略时,生成的会话的权限是 IAM 实体的基于身份的策略与会话策略的交集。要创建联合用户会话,您需要使用 IAM 用户的访问密钥以编程方式调用GetFederationToken
API 操作。有关更多信息,请参阅 会话策略。
请记住,任一项策略中的显式拒绝将覆盖允许。
评估基于身份的策略以及基于资源的策略
基于身份的策略和基于资源的策略向策略所附加到的身份或资源授予权限。在 IAM 实体(用户或角色)请求访问同一账户中的资源时,AWS 评估基于身份的策略和基于资源的策略授予的所有权限。生成的权限是指两种类型的权限的联合。如果基于身份的策略和/或基于资源的策略允许此操作,则 AWS 允许执行该操作。其中任一项策略中的显式拒绝将覆盖允许。
评估具有权限边界的基于身份的策略
在 AWS 评估用户的基于身份的策略和权限边界时,生成的权限是这两种类别的交集。这意味着,当您通过现有基于身份的策略向用户添加权限边界时,您可能会减少用户可以执行的操作。或者,当您从用户删除权限边界时,您可能会增加用户可以执行的操作。其中任一项策略中的显式拒绝将覆盖允许。要查看有关如何使用权限边界评估其他策略类型的信息,请参阅评估具有边界的有效权限。
评估具有 Organizations SCP 或 RCP 的基于身份的策略
当一个用户属于组织成员账户且能够访问未配置基于资源的策略的资源,生成的权限是该用户的策略、服务控制策略(SCP)和资源控制策略(RCP)的交集。这意味着所有三种策略类型均必须允许某项操作。基于身份的策略、SCP 或 RCP 中的显式拒绝会覆盖该允许。
您可以在 AWS Organizations 中了解您的账户是否为某个组织的成员。组织成员可能会受 SCP 或 RCP 的影响。要使用 AWS CLI 命令或 AWS API 操作查看该数据,您必须具有 Organizations 实体的 organizations:DescribeOrganization
操作的权限。您必须具有额外的权限才能在 Organizations 控制台中执行该操作。要了解 SCP 或 RCP 是否拒绝访问特定的请求或更改您的有效权限,请与您的 AWS Organizations 管理员联系。
基于身份的策略和基于资源的策略评估示例
策略的最常见类型是基于身份的策略和基于资源的策略。当请求访问资源时,AWS 会评估策略为同一账户中至少一个允许所授予的所有权限。任一项策略中的显式拒绝将覆盖允许。
重要
如果同一账户中基于身份的策略或基于资源的策略其中一个允许该请求,而另一个不允许,仍可允许该请求。
假定 Carlos 具有用户名 carlossalazar
,他尝试将文件保存到 amzn-s3-demo-bucket-carlossalazar-logs
Amazon S3 存储桶。
还假定将以下策略附加到 carlossalazar
IAM 用户。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowS3ListRead", "Effect": "Allow", "Action": [ "s3:GetBucketLocation", "s3:GetAccountPublicAccessBlock", "s3:ListAccessPoints", "s3:ListAllMyBuckets" ], "Resource": "arn:aws:s3:::*" }, { "Sid": "AllowS3Self", "Effect": "Allow", "Action": "s3:*", "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar/*", "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar" ] }, { "Sid": "DenyS3Logs", "Effect": "Deny", "Action": "s3:*", "Resource": "arn:aws:s3:::*log*" } ] }
此策略中的 AllowS3ListRead
语句允许 Carlos 查看账户中的所有存储桶的列表。AllowS3Self
语句允许 Carlos 完全访问与其用户名同名的存储桶。DenyS3Logs
语句拒绝 Carlos 访问名称中包含 log
的任何 S3 存储桶。
此外,以下基于资源的策略(称为存储桶策略)附加到 amzn-s3-demo-bucket-carlossalazar
存储桶。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::
123456789012
:user/carlossalazar" }, "Action": "s3:*", "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar/*", "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar" ] } ] }
此策略指定只有 carlossalazar
用户可以访问 amzn-s3-demo-bucket-carlossalazar
存储桶。
当 Carlos 请求将文件保存到 amzn-s3-demo-bucket-carlossalazar-logs
存储桶时,AWS 将确定应用于请求的策略。在此示例中,仅基于身份的策略和基于资源的策略适用。这些都是权限策略。由于没有任何权限边界适用,评估逻辑将减少为以下逻辑。
AWS 首先检查应用于请求上下文的 Deny
语句。它找到一个,因为基于身份的策略显式拒绝 Carlos 访问用于日志记录的任何 S3 存储桶。拒绝 Carlos 访问。
假设他随后意识到自己的错误,尝试将文件保存到 amzn-s3-demo-bucket-carlossalazar
存储桶。AWS 检查 Deny
语句,但未找到。然后,它检查权限策略。基于身份的策略和基于资源的策略均允许请求。因此,AWS 允许请求。如果其中任何一个显式拒绝了语句,则将拒绝请求。如果其中一种策略类型允许请求,而另一种不允许,则仍允许请求。