IAM 权限边界、撤销与应急访问#
验证：未记录
- 适用版本
- 未记录
- 验证范围
- 尚未登记验证记录。
人员经企业单点登录取得角色会话；构建、发布、运行时与应急身份分别授权。生产发布角色不能兼任密钥管理员，应用角色不能修改自身策略或角色信任。
1. 分清六层策略#
| 策略 | 回答的问题 | 易错点 |
|---|---|---|
| Trust policy（角色信任） | 谁能 AssumeRole 取得会话？ | 只限制入口，不定义资源操作权限 |
| Identity policy（身份策略） | 角色可以做什么？ | Action、Resource、条件必须一起收敛 |
| Resource policy（资源策略） | 桶、密钥等允许谁访问？ | 跨账号需检查两侧授权，不能只改角色 |
| Permissions boundary（权限边界） | 身份可被授予的最大范围？ | 本身不授予权限；不能当作所有资源授权的万能拦截器 |
| SCP（Service Control Policy，服务控制策略） | 组织账号内身份受哪些上限约束？ | 不授予权限；排障需检查组织层 |
| Session policy（会话策略） | 本次会话进一步收窄到哪里？ | 不能用它扩大角色权限 |
显式拒绝优先；资源策略直接授予用户或角色会话的场景有额外求值规则，不能把所有策略简单理解为“全部取交集”。另外检查密钥策略、端点策略及适用的资源控制策略。官方策略说明。
2. 可复用的验收方法#
先在隔离账号完成 GitHub 短期身份实践，使用真实制品路径：允许读取当前应用制品，拒绝列出其他应用前缀，并核对实际角色会话。
人员身份使用已配置的 IAM Identity Center profile：
export AWS_PROFILE='REPLACE_SSO_PROFILE'
aws sso login --profile "$AWS_PROFILE"
aws sts get-caller-identity --profile "$AWS_PROFILE"STS（Security Token Service，安全令牌服务）返回的账号和角色必须与预期一致。get-caller-identity 成功只确认身份，不证明业务权限有效；撤权后它也可能仍成功，必须重测实际资源操作。
验收至少包含：允许资源成功、越界资源拒绝、越权操作拒绝、撤权后旧会话拒绝。策略模拟器可预检，最终以实际调用及审计事件为准；权限错误需与资源不存在、网络超时、令牌过期区分。
3. 撤销：新会话与已有会话分别处理#
只修改信任策略或退出单点登录，不能保证已经签发的角色会话立即失效。正常离职/调岗先撤人员组及新会话入口；凭据泄漏同时处理现有会话和资源权限。
以下用于独立演练角色，平台管理员从另一个管理身份执行；会拒绝该角色截止时间之前签发的全部会话，不能对共享生产角色直接照搬：
export ROLE_NAME='REPLACE_ISOLATED_TEST_ROLE'
umask 077
aws iam get-role --role-name "$ROLE_NAME" --query Role.AssumeRolePolicyDocument > trust-before.json
export REVOKE_BEFORE=$(date -u '+%Y-%m-%dT%H:%M:%SZ')
python3 - <<'PYJSON' > revoke-before.json
import json, os
print(json.dumps({"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":"*","Resource":"*","Condition":{"DateLessThan":{"aws:TokenIssueTime":os.environ["REVOKE_BEFORE"]}}}]}))
PYJSON
aws iam put-role-policy --role-name "$ROLE_NAME" --policy-name RevokeOlderSessions --policy-document file://revoke-before.json先保存一个截止时间之前的测试会话，用其重测先前允许的资源操作，传播完成后应拒绝。不要让凭据工具自动换取新会话后误判撤销无效；会话在截止时间之后签发时不受此策略限制，因此泄漏处置还必须关闭受影响的信任入口。
拒绝策略不能立即删除，否则未过期旧会话可能重新获得权限。保留至受影响会话最长有效期结束，并完成资源权限与信任检查后再清理。角色已连接的数据库会话等下游状态需单独终止；AWS 凭据撤销不等于应用数据库密码轮换。官方会话撤销机制。
4. 应急访问与收尾#
应急访问采用独立身份、MFA（Multi-Factor Authentication，多因素认证）、限时授权与操作告警；恢复路径不能完全依赖发生故障的身份提供方。按演练流程验证登录、限定管理操作、撤权和审计，不共享 root 日常运维。
保留操作者、会话名、资源、允许/拒绝结果、时间和请求标识。对象访问等数据事件需事先按范围启用 CloudTrail，不能只在管理事件历史中搜索。结束时撤销临时授权与凭据，恢复已审查的配置；长期 Access Key 泄漏时先停用/轮换，再清理日志和仓库历史。