# IAM 实体的权限边界
AWS 对于 IAM 实体（用户或角色）支持*权限边界*。权限边界是一个高级功能，它使用托管策略设置基于身份的策略可以为 IAM 实体授予的最大权限。实体的权限边界仅允许实体执行其基于身份的策略和权限边界同时允许的操作。
有关策略类型的更多信息，请参阅[策略类型](access_policies.md#access_policy-types)。
**重要**
如果基于资源的策略语句包含对附加了权限边界策略的 IAM 用户或角色具有 `Deny` 效果的 `NotPrincipal` 策略元素，则不要使用这种策略语句。具有 `Deny` 效果的 `NotPrincipal` 元素将始终拒绝任何附加了权限边界策略的 IAM 主体，无论 `NotPrincipal` 元素中指定的值为何。这会导致本来可以访问该资源的某些 IAM 用户或角色失去访问权限。我们建议更改基于资源的策略语句，以将 [`ArnNotEquals`](reference_policies_elements_condition_operators.md#Conditions_ARN) 条件运算符和 [`aws:PrincipalArn`](reference_policies_condition-keys.md#condition-keys-principalarn) 上下文键结合使用来限制访问权限，而不是使用 `NotPrincipal` 元素。有关 `NotPrincipal` 元素的信息，请参阅 [AWS JSON 策略元素：NotPrincipal](reference_policies_elements_notprincipal.md)。
您可以使用 AWS 托管策略或客户托管策略为 IAM 实体（用户或角色）设置边界。该策略限制用户或角色的最大权限。
例如，假设名为 `Shirley` 的 IAM 用户应仅允许管理 Amazon S3、Amazon CloudWatch 和 Amazon EC2。要执行此规则，您可以使用以下策略为 `Shirley` 用户设置权限边界：
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*",
"cloudwatch:*",
"ec2:*"
],
"Resource": "*"
}
]
}
```
------
当使用策略为用户设置权限边界时，它会限制用户的权限，但自己不提供权限。在本示例中，策略设置 `Shirley` 的最大权限作为 Amazon S3、CloudWatch 和 Amazon EC2 中的所有操作。Shirley 无法在任何其他服务（包括 IAM）中执行操作，即使她有一个允许这样做的权限策略也是如此。例如，您可以将以下策略添加给 `Shirley` 用户：
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "iam:CreateUser",
"Resource": "*"
}
}
```
------
此策略允许在 IAM 中创建用户。如果您将此权限策略附加到 `Shirley` 用户，然后 Shirley 尝试创建用户，该操作会失败。它由于权限边界不允许执行 `iam:CreateUser` 操作而失败。鉴于这两个策略，Shirley 无权在 AWS 中执行任何操作。您必须添加不同的权限策略以允许其他服务中的操作，例如 Amazon S3。或者，您也可以更新权限边界，以允许她在 IAM 中创建用户。
## 评估具有边界的有效权限
IAM 实体（用户或角色）的权限边界设置实体可以具有的最大权限。这可以更改该用户或角色的有效权限。实体的有效权限是影响用户或角色的所有策略所授予的权限。在账户中，基于身份的策略、基于资源的策略、权限边界、AWS Organizations SCP 或会话策略可以影响实体的权限。有关不同类型的策略的更多信息，请参阅[AWS Identity and Access Management 中的策略和权限](access_policies.md)。
如果以下任一策略类型显式拒绝操作的访问权限，则请求会被拒绝。多个权限类型向实体授予的权限更复杂。有关 AWS 如何评估策略的更多信息，请参阅[策略评估逻辑](reference_policies_evaluation-logic.md)。
**基于身份的策略及边界** - 基于身份的策略是附加到用户、用户组或角色的内联或托管策略。基于身份的策略向实体授予权限，而权限边界限制这些权限。有效的权限是两种策略类型的交集。其中任一项策略中的显式拒绝将覆盖允许。
![\[评估基于身份的策略和权限边界\]](http://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/images/permissions_boundary.png)
**基于资源的策略** - 基于资源的策略控制指定的主体可以访问策略附加到的资源。
*针对 IAM 用户的基于资源的策略*
在同一账户中，向 IAM 用户 ARN（即非 AWS STS 联合用户主体会话）授予权限的基于资源的策略不受基于身份的策略或权限边界中的隐式拒绝限制。
![\[评估基于资源的策略、权限边界和基于身份的策略\]](http://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/images/EffectivePermissions-rbp-boundary-id.png)
*针对 IAM 用户的基于资源的策略*
**IAM 角色** — 授予 IAM 角色 ARN 权限的基于资源的策略受权限边界或会话策略中隐式拒绝的限制。
**IAM 角色会话** — 在同一账户中，向 IAM 角色会话 ARN 授予权限的基于资源的策略直接向所担任的角色会话授予权限。直接授予会话的权限不受基于身份的策略、权限边界或会话策略中的隐式拒绝的限制。当您担任角色并提出请求时，发出请求的主体是 IAM 角色会话 ARN，而不是角色本身的 ARN。
*针对 AWS STS 联合用户主体会话的基于资源的策略*
**AWS STS 联合用户主体会话**：AWS STS 联合用户主体会话是通过调用 [`GetFederationToken`](id_credentials_temp_request.md#api_getfederationtoken) 创建的会话。当联合身份用户发出请求时，发出请求的主体是联合身份用户 ARN，而不是联合身份的 IAM 用户的 ARN。在同一个账户中，将权限授予联合身份用户 ARN 的基于资源的策略直接将权限授予会话。直接授予会话的权限不受基于身份的策略、权限边界或会话策略中的隐式拒绝的限制。
但是，如果基于资源的策略向联合身份的 IAM 用户的 ARN 授予权限，则 AWS STS 联合用户主体在会话期间发出的请求将受权限边界或会话策略中隐式拒绝的限制。
**AWS Organizations SCP**：SCP 适用于整个 AWS 账户。它们限制账户中的主体所提出的每个请求的权限。IAM 实体（用户或角色）可能会发出受 SCP、权限边界和基于身份的策略影响的请求。在这种情况下，只有在所有三种策略类型都允许时，才允许发出该请求。有效的权限是的所有三种策略类型的交集。任一项策略中的显式拒绝将覆盖允许。
![\[评估 SCP、权限边界和基于身份的策略\]](http://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/images/EffectivePermissions-scp-boundary-id.png)
您可以在 AWS Organizations 中了解[您的账户是否为某个组织的成员](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_details.html#orgs_view_account)。组织成员可能会受 SCP 的影响。要使用 AWS CLI 命令或 AWS API 操作查看该数据，您必须具有 AWS Organizations 实体的 `organizations:DescribeOrganization` 操作的权限。您必须具有额外的权限才能在 AWS Organizations 控制台中执行该操作。要了解 SCP 是否拒绝访问特定的请求或更改您的有效权限，请与您的 AWS Organizations 管理员联系。
**会话策略**：会话策略是当您以编程方式为角色或联合用户创建临时会话时作为参数传递的高级策略。会话的权限来自用于创建会话的 IAM 实体（用户或角色）和会话策略。该实体的基于身份的策略权限受会话策略和权限边界所限制。这组策略类型的有效权限是所有三种策略类型的交集。任一项策略中的显式拒绝将覆盖允许。有关会话策略的更多信息，请参阅[会话策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)。
![\[评估会话策略、权限边界和基于身份的策略\]](http://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/images/EffectivePermissions-session-boundary-id.png)
## 使用权限边界将责任委派给其他人
您可以使用权限边界将权限管理任务（如用户创建）委派给您账户中的 IAM 用户。这允许其他人在特定权限边界内代表您执行任务。
例如，假定 María 是 X 公司 AWS 账户 的管理员。她希望将用户创建责任委派给 Zhang。但是，她必须确保 Zhang 创建的用户符合以下公司规则：
+ 用户不能使用 IAM 来创建或管理用户、组、角色或策略。
+ 拒绝用户访问 Amazon S3 `logs` 存储桶，并且用户无法访问 `i-1234567890abcdef0` Amazon EC2 实例。
+ 用户无法删除自己的边界策略。
为执行这些规则，María 完成以下任务，下面包括其详细信息：
1. María 创建 `XCompanyBoundaries` 托管策略以用作账户中的所有新用户的权限边界。
1. María 创建 `DelegatedUserBoundary` 托管策略并将其指定为 Zhang 的权限边界。Maria 记录了其管理员 用户的 ARN，并在策略中使用它来阻止 Zhang 访问它。
1. María 创建 `DelegatedUserPermissions` 托管策略并将其作为 Zhang 的权限策略进行附加。
1. María 告诉 Zhang 他的新责任和限制。
**任务 1：**María 必须首先创建托管策略来为新用户定义边界。María 将允许 Zhang 向用户授予他们所需的权限策略，但她希望限制这些用户。为此，她创建以下名为 `XCompanyBoundaries` 的客户托管策略。该策略执行以下操作：
+ 允许用户完全访问一些服务
+ 允许在 IAM 控制台中进行有限的自我管理访问。这意味着，他们可以在登录控制台后更改密码。他们不能设置初始密码。要允许此操作，请将 `"*LoginProfile"` 操作添加到 `AllowManageOwnPasswordAndAccessKeys` 语句。
+ 拒绝用户访问 Amazon S3 日志存储桶或 `i-1234567890abcdef0` Amazon EC2 实例
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ServiceBoundaries",
"Effect": "Allow",
"Action": [
"s3:*",
"cloudwatch:*",
"ec2:*",
"dynamodb:*"
],
"Resource": "*"
},
{
"Sid": "AllowIAMConsoleForCredentials",
"Effect": "Allow",
"Action": [
"iam:ListUsers",
"iam:GetAccountPasswordPolicy"
],
"Resource": "*"
},
{
"Sid": "AllowManageOwnPasswordAndAccessKeys",
"Effect": "Allow",
"Action": [
"iam:*AccessKey*",
"iam:ChangePassword",
"iam:GetUser",
"iam:*ServiceSpecificCredential*",
"iam:*SigningCertificate*"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "DenyS3Logs",
"Effect": "Deny",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::logs",
"arn:aws:s3:::logs/*"
]
},
{
"Sid": "DenyEC2Production",
"Effect": "Deny",
"Action": "ec2:*",
"Resource": "arn:aws:ec2:*:*:instance/i-1234567890abcdef0"
}
]
}
```
------
每个语句用于不同目的：
1. 此策略的 `ServiceBoundaries` 语句允许完全访问指定的 AWS 服务。这意味着，新用户在这些服务中的操作仅受附加到该用户的权限策略的限制。
1. `AllowIAMConsoleForCredentials` 语句允许访问以列出所有 IAM 用户。要在 AWS 管理控制台中导航**用户**页面，此访问权限是必需的。它还允许查看账户的密码要求，这在更改自己的密码时是必需的。
1. `AllowManageOwnPasswordAndAccessKeys` 语句允许用户仅管理其自己的控制台密码和编程访问密钥。这在 Zhang 或其他管理员为新用户分配了具有完全 IAM 访问权限的权限策略时将非常重要。在这种情况下，该用户可能会更改自己或其他用户的权限。此语句可防止这种情况的发生。
1. `DenyS3Logs` 语句显式拒绝对 `logs` 存储桶的访问。
1. `DenyEC2Production` 语句显式拒绝对 `i-1234567890abcdef0` 实例的访问。
**任务 2：**María 希望允许 Zhang 创建所有 X 公司用户，但仅具有 `XCompanyBoundaries` 权限边界。她创建以下名为 `DelegatedUserBoundary` 的客户托管策略。此策略定义 Zhang 可以具有的最大权限。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CreateOrChangeOnlyWithBoundary",
"Effect": "Allow",
"Action": [
"iam:AttachUserPolicy",
"iam:CreateUser",
"iam:DeleteUserPolicy",
"iam:DetachUserPolicy",
"iam:PutUserPermissionsBoundary",
"iam:PutUserPolicy"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/XCompanyBoundaries"
}
}
},
{
"Sid": "CloudWatchAndOtherIAMTasks",
"Effect": "Allow",
"Action": [
"cloudwatch:*",
"iam:CreateAccessKey",
"iam:CreateGroup",
"iam:CreateLoginProfile",
"iam:CreatePolicy",
"iam:DeleteGroup",
"iam:DeletePolicy",
"iam:DeletePolicyVersion",
"iam:DeleteUser",
"iam:GetAccountPasswordPolicy",
"iam:GetGroup",
"iam:GetLoginProfile",
"iam:GetPolicy",
"iam:GetPolicyVersion",
"iam:GetRolePolicy",
"iam:GetUser",
"iam:GetUserPolicy",
"iam:ListAccessKeys",
"iam:ListAttachedRolePolicies",
"iam:ListAttachedUserPolicies",
"iam:ListEntitiesForPolicy",
"iam:ListGroups",
"iam:ListGroupsForUser",
"iam:ListMFADevices",
"iam:ListPolicies",
"iam:ListPolicyVersions",
"iam:ListRolePolicies",
"iam:ListSSHPublicKeys",
"iam:ListServiceSpecificCredentials",
"iam:ListSigningCertificates",
"iam:ListUserPolicies",
"iam:ListUsers",
"iam:SetDefaultPolicyVersion",
"iam:SimulateCustomPolicy",
"iam:SimulatePrincipalPolicy",
"iam:UpdateGroup",
"iam:UpdateLoginProfile",
"iam:UpdateUser"
],
"NotResource": "arn:aws:iam::123456789012:user/Maria"
},
{
"Sid": "NoBoundaryPolicyEdit",
"Effect": "Deny",
"Action": [
"iam:CreatePolicyVersion",
"iam:DeletePolicy",
"iam:DeletePolicyVersion",
"iam:SetDefaultPolicyVersion"
],
"Resource": [
"arn:aws:iam::123456789012:policy/XCompanyBoundaries",
"arn:aws:iam::123456789012:policy/DelegatedUserBoundary"
]
},
{
"Sid": "NoBoundaryUserDelete",
"Effect": "Deny",
"Action": "iam:DeleteUserPermissionsBoundary",
"Resource": "*"
}
]
}
```
------
每个语句用于不同目的：
1. `CreateOrChangeOnlyWithBoundary` 语句允许 Zhang 创建 IAM 用户，但仅当他使用 `XCompanyBoundaries` 策略设置权限边界时。此语句还允许他为现有用户设置权限边界，但仅使用该相同策略。最后，此语句允许 Zhang 管理设置了此权限边界的用户的权限策略。
1. `CloudWatchAndOtherIAMTasks` 语句允许 Zhang 完成其他用户、组和策略管理任务。他有权重置密码并为 `NotResource` 策略元素中未列出的任何 IAM 用户创建访问密钥。这使他能够帮助用户解决登录问题。
1. `NoBoundaryPolicyEdit` 语句拒绝 Zhang 访问以更新 `XCompanyBoundaries` 策略。不允许他更改用于为自己或其他用户设置权限边界的任何策略。
1. `NoBoundaryUserDelete` 语句拒绝 Zhang 访问以便为他或其他用户删除权限边界。
María 然后将 `DelegatedUserBoundary` 策略指定为 `Zhang` 用户的[权限边界](id_users_change-permissions.md#users_change_permissions-set-boundary-console)。
**任务 3：**由于权限边界限制最大权限，但自己不授予访问权限，Maria 必须为 Zhang 创建权限策略。她创建以下名为 `DelegatedUserPermissions` 的策略。此策略定义 Zhang 在定义的边界内可以执行的操作。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "IAM",
"Effect": "Allow",
"Action": "iam:*",
"Resource": "*"
},
{
"Sid": "CloudWatchLimited",
"Effect": "Allow",
"Action": [
"cloudwatch:GetDashboard",
"cloudwatch:GetMetricData",
"cloudwatch:ListDashboards",
"cloudwatch:GetMetricStatistics",
"cloudwatch:ListMetrics"
],
"Resource": "*"
},
{
"Sid": "S3BucketContents",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::ZhangBucket"
}
]
}
```
------
每个语句用于不同目的：
1. 此策略的 `IAM` 语句允许 Zhang 完全访问 IAM。但是，由于他的权限边界只允许某些 IAM 操作，他的有效 IAM 权限仅受他的权限边界限制。
1. `CloudWatchLimited` 语句允许 Zhang 在 CloudWatch 中执行五种操作。他的权限边界允许 CloudWatch 中的所有操作，因此他的有效 CloudWatch 权限仅受他的权限策略限制。
1. `S3BucketContents` 语句允许 Zhang 列出 `ZhangBucket` Amazon S3 存储桶。但是，他的权限边界不允许任何 Amazon S3 操作，因此无论他的权限策略如何，他都无法执行任何 S3 操作。
**注意**
Zhang 的策略允许他创建一个用户，然后可以访问自己无法访问的 Amazon S3 资源。通过委托这些管理操作，Maria 实际上相信张能够访问 Amazon S3。
María 然后将 `DelegatedUserPermissions` 策略作为 `Zhang` 用户的权限策略进行附加。
**任务 4：**她向 Zhang 提供创建新用户的说明。她告诉他，他可以创建具有所需任何权限的新用户，但他必须为他们分配 `XCompanyBoundaries` 策略作为权限边界。
Zhang 完成以下任务：
1. Zhang 使用 AWS 管理控制台 创建用户。他为该用户键入用户名 `Nikhil` 并启用控制台访问。他清除 **Requires password reset**（需要重置密码）旁边的复选框，因为上述策略仅允许用户在登录到 IAM 控制台后才能更改密码。
1. 在 **Set permissions (设置权限)** 页面上，Zhang 选择允许 Nikhil 执行其工作的 **IAMFullAccess** 和 **AmazonS3ReadOnlyAccess** 权限策略。
1. Zhang 跳过**设置权限边界**部分，忘记 María 的说明。
1. Zhang 查看用户详细信息并选择**创建用户**。
操作失败，并且拒绝访问。Zhang 的 `DelegatedUserBoundary` 权限边界要求他创建的任何用户都将 `XCompanyBoundaries` 策略用作权限边界。
1. Zhang 返回到上一页。在**设置权限边界**部分中，他选择了 `XCompanyBoundaries` 策略。
1. Zhang 查看用户详细信息并选择**创建用户**。
将创建用户。
当 Nikhil 登录时，他有权访问 IAM 和 Amazon S3，但权限边界拒绝的操作除外。例如，他可以在 IAM 中更改自己的密码，但无法创建另一个用户或编辑他的策略。Nikhil 具有对 Amazon S3 的只读访问权限。
如果某个人在 `logs` 存储桶中添加基于资源的策略以允许 Nikhil 将对象放入该存储桶中，他仍然无法访问该存储桶。原因是，其权限边界显式拒绝对 `logs` 存储桶执行的任何操作。任何策略类型中的显式拒绝都会导致请求被拒绝。不过，如果附加到 Secrets Manager 密钥的基于资源的策略允许 Nikhil 执行 `secretsmanager:GetSecretValue` 操作，则 Nikhil 可以检索和解密该密钥。原因是，其权限边界未显式拒绝 Secrets Manager 操作，并且权限边界中的隐式拒绝不限制基于资源的策略。