AWS新工具自动推荐移除未使用的权限一次权限瘦身的完整实践记录很多团队在AWS上跑了一两年之后都会遇到一个特别头疼的问题IAM权限越堆越多越堆越乱。刚上线时每人只给三五条策略半年后一看某个开发账号下面挂了十几个策略很多权限从开通那天起就压根没碰过。你问谁谁都说“先留着吧万一以后用得上呢”谁都不敢动。结果就是权限膨胀越来越严重合规审计的时候越查越心虚万一哪天真被拖库了这些用不上的权限就是最容易被忽略的突破口。我一直在关注AWS这边权限治理的工具最近终于等到了一个很实用的新功能——AWS IAM Access Analyzer的未使用访问发现能力Unused Access analysis。说白了它能自动分析你账号里的IAM角色和用户找出过去指定时间段内从未被调用过的权限然后直接给出移除建议。这个功能我实测了一段时间基本解决了“权限黑盒”的痛点今天就把完整的使用思路、操作过程和踩坑记录整理出来希望对正在做权限收缩或合规整改的同学有实际帮助。1. 这个工具到底解决什么问题1.1 权限膨胀是所有云账号绕不过去的坎先聊聊为什么权限会失控。AWS上的权限管理逻辑其实不复杂IAM用户或角色通过附加策略来获得权限策略分为AWS托管策略和自定义策略最终生效权限是显式允许和显式拒绝叠加的结果。但问题就出在“管理”上。团队里的人来来去去项目改了一版又一版S3桶换了好几个Lambda函数删了又建。最初配置的策略可能早就覆盖不到真实的业务需求了可也没人专门去梳理哪些权限已经成了摆设。我见过一个比较典型的例子某业务团队为了排查线上问题给运维角色开通了AmazonS3ReadOnlyAccess、CloudWatchLogsReadOnlyAccess、EC2Describe权限等一堆只读策略后来问题解决了这些权限也没回收。半年后做安全审计发现这个角色居然还能列出账号下所有S3桶的对象列表——而这些桶里装的本来就是敏感数据。更麻烦的是谁都不记得这个角色到底还有哪些权限只能一份策略接一份策略地人工翻。这种“权限只增不减”的现象在AWS社区里有个专门的叫法权限蠕变permission creep。不夸张地说只要是稍微复杂的账号几年下来没做过权限清理的基本都会中招。1.2 Access Analyzer未使用访问发现机制的核心原理AWS IAM Access Analyzer其实早就有之前的定位是分析资源策略比如S3桶策略、KMS密钥策略找出哪些外部实体能访问你的资源属于“对外暴露面”的梳理。这次的新功能“未使用访问”换了个角度转向分析身份策略也就是直接看你的IAM用户和角色手里的权限到底用了没有。判断逻辑并不神秘核心就是基于CloudTrail的访问日志。你启用了未使用访问分析之后Access Analyzer会拉取账号里CloudTrail记录的历史API调用事件把这些事件和IAM实体上的策略做比对某个角色策略里允许了s3:ListBucket但在过去90天可配置的CloudTrail日志里完全找不到这个角色调用过s3:ListBucket的记录那么这条权限就会被标记为“未使用”。我第一次看到这个机制的时候第一反应是“这不就是查日志嘛我自己写脚本也能查”。但实际用下来发现AWS把它做成了产品级的服务省掉的功夫非常多不用自己写Athena查询、不用自己处理CloudTrail的JSON结构、不用自己设计“怎么判断某个API调用属于某个权限”的映射逻辑。而且它不只是查“整个服务是否被调用”还能精确到某个操作比如ec2:DescribeInstances用了但ec2:StopInstances没用这个粒度是手工很难做到的。选型上我当时也对比过第三方工具比如部分商业云安全平台也做权限分析但它们的统计口径不透明有的甚至只分析“策略是否被附加”而不是“权限是否被实际使用”成本也高得多。AWS这个原生能力最大的优势是数据来源可信——CloudTrail是你账号自己产的日志不存在采样偏差或者口径模糊的问题。1.3 这个功能最适合谁用从适用场景看下面三类团队受益最明显合规压力大的团队等保、SOC 2、ISO 27001这些审计里基本都有一条“最小权限原则”以前是拿人工梳理结果硬着头皮给审计看现在可以直接导出Access Analyzer的分析报告审计员更容易信服。动态与静态权限分离之后合规证据链会清晰很多。账号数量多的DevOps团队账号多了以后角色之间的交叉授权特别混乱哪个角色该不该有某个权限经常说不清。未使用访问分析相当于给每个角色做了一次“权限体检”你只需要看检查报告不用自己挨个角色翻策略。正要上微服务或Serverless的团队如果正准备做架构升级比如从单体迁移到Lambda或容器老账号里的很多旧权限本来就是给旧架构用的。迁移之前先用Access Analyzer梳理一遍哪些旧权限可以随老系统一起下线一清二楚。不推荐用的情况也有。如果你账号里的角色和用户本来就只有个位数而且权限都是建账号时精心配置的一步没多给那这个工具的意义确实不大。权限扩张的痛点是先有“多”才能谈“减”的。2. 实操准备与启用流程2.1 启用前必须满足的前提条件这个功能不是打开就能用的有几个前置条件必须先确认第一账号必须启用CloudTrail。我在测试环境里发现如果没有CloudTrail的trail在记录事件Access Analyzer会直接提示“无可用数据源”分析结果为空。如果你只有默认的CloudTrail事件历史记录90天也可以但建议开启正式trail并投递到S3这样数据保留时间更长分析窗口的选择也更灵活。第二分析窗口需要注意。AWS允许你选择14天到365天的时间范围作为分析周期。选的时间越长越能发现“低频但合法”的权限选的时间越短越容易误伤“还没轮到用”的新权限。我第一次测试的时候选了90天结果发现有个刚上线两周的新服务角色所有权限都被标记为未使用差点被自动清理工具误删后来才把窗口调回30天这些新角色的权限就恢复正常了。第三权限配置。你需要一个具有iam:ListRoles、iam:ListUsers、access-analyzer:ListFindings、access-analyzer:GetFinding等权限的IAM身份来操作Access Analyzer。最简单的方式是直接用AdministratorAccess但如果你本身就是在做权限治理建议单独建一个AccessAnalyzerAdmin角色策略如下{ Version: 2012-10-17, Statement: [ { Effect: Allow, Action: [ access-analyzer:*, iam:ListRoles, iam:ListUsers, iam:ListPolicies, iam:GetPolicyVersion, iam:GetRole, iam:GetUser ], Resource: * } ] }2.2 一步步启用未使用访问分析启用过程其实不复杂但有些入口藏得比较深第一次找的时候容易绕路。具体路径是控制台打开IAM服务左侧菜单最下面找到Access Analyzer进入之后选择Settings。在设置页里找到“Unused access”这个区域点Manage在这里配置三样东西分析周期14365天、要分析的身份类型IAM用户、IAM角色、两者都要、是否包含服务相关角色service-linked roles。建议不要勾选服务相关角色因为这类角色由AWS服务自动创建和更新权限也是AWS托管的你即使发现了未使用权限也改不了分析出来纯粹是噪音。配置完成后点击保存AWS会立即开始生成分析结果。如果你账号里实体数量不多一般几分钟之内就能看到第一批findings如果实体很多比如上千个角色可能要多等一会儿后台是异步扫描的。2.3 分析结果的视图和字段说明分析完成之后findings列表会自动生成。我看下来大部分团队用得最多的字段是这几个Finding ID每条未使用权限发现的唯一标识。Resource被分析的具体实体比如arn:aws:iam::123456789012:role/ci-deploy-role。Unused access type区分是未使用的角色权限还是未使用的用户权限。如果有活跃的访问密钥还会单独列出。Last accessed timestamp最后一次使用该权限的时间。这个字段特别关键看到时间戳就心里有数了比如一条权限停在“一年前”和“三天前”处理优先级完全不同。Suggested actionAWS给出的建议操作通常分为“移除权限”和“附加建议策略”两种。在列表页可以按类型筛选也可以按时间倒序排列优先处理“距离现在最久未使用”的条目。建议导出CSV做进一步分析AWS支持最多导出50000条finding对于绝大多数账号来说绝对够用了。3. 实战用未使用访问报告做一次完整权限收缩3.1 从报告到行动先区分“健康未使用”和“危险未使用”拿到报告后第一步不是急着改策略而是先分类。我通常会把发现项分为三类第一类是“确实该删的”。比如某个角色是两年前为临时数据迁移建的迁移完了之后角色一直躺着这种没有保留价值权限直接解绑甚至把角色删掉都行。第二类是“权限给多了但角色还在用”。比如一个前端项目的CI角色本身只需要s3:PutObject上传前端包但策略里还带着ec2:*和iam:*而这些从未调用过——这就是典型的最小权限违背应该把多余权限从策略中移除。第三类是“低频但必要的”。比如某些管理操作只会在故障演练时才执行一年用一两次统计窗口拉太长就容易被误报。这类权限的处理方式不是直接删而是做好标注和审批流程确保它是被有意保留的。一个我自己常用的判断策略所有超过180天未使用的权限默认可删30180天之间未使用的逐条评估30天以内的先不动。3.2 处理单个未使用权限的两种方式在Access Analyzer的findings详情页里AWS给出了直接操作入口。实操下来有两种常用处理路径。方式一直接修改身份策略如果finding定位到角色附加的某个自定义策略中某条Statement的权限未使用你可以直接在详情页选择“Review proposed policy”。AWS会生成一份“去掉未使用权限后的策略版本”你确认无误后直接应用即可。这个流程非常顺手特别是对那种一个策略里包含十几个action、其中两三个未使用的场景人工去改还要一行行核对用它的建议策略基本可以直接用。方式二从角色上解绑策略如果finding定位的是某个角色附加的整份托管策略比如AmazonS3FullAccess但实际只用了里面的一两个操作那推荐的做法不是继续加一个“Deny”来覆盖而是把AWS托管策略解绑换成一个自定义的最小权限策略。举个实际例子某数据分析角色附加了AmazonS3FullAccess但我拉取CloudTrail记录后发现过去90天它只调用了s3:GetObject、s3:ListBucket和s3:GetBucketLocation。直接解绑FullAccess新建自定义策略{ Version: 2012-10-17, Statement: [ { Effect: Allow, Action: [ s3:GetObject, s3:ListBucket, s3:GetBucketLocation ], Resource: [ arn:aws:s3:::data-lake-bucket, arn:aws:s3:::data-lake-bucket/* ] } ] }这样改完之后角色能正常访问业务但删除、写入、管理类的权限全部收走风险面立刻缩小。这里有个细节AWS托管策略解绑前先检查这个策略是否还附加给了其他实体。如果别的角色也在用就先别动先把当前角色的权限换成自定义策略再说。我曾经在一个账号里直接对AmazonEC2FullAccess做了“建议策略”替换结果另一个团队的启动模板构建任务瞬间开始报错排查了半天才发现他们用的是同一个托管策略。权限改动一定要先看关联范围。3.3 批量处理能力用CLI写拉取和变更脚本如果账号里只有几十条findings控制台点点就够了。但如果你管理的账号有几百上千条findings就得上脚本。Access Analyzer的CLI命令很完整我这里分享一下高频使用的几个# 列出所有未使用访问的findings aws accessanalyzer list-findings \ --analyzer-arn arn:aws:access-analyzer:us-east-1:123456789012:analyzer/my-analyzer \ --query findings[?statusACTIVE] \ --output table # 只筛出某种资源类型比如IAM角色 aws accessanalyzer list-findings \ --analyzer-arn arn:aws:access-analyzer:us-east-1:123456789012:analyzer/my-analyzer \ --query findings[?resourceTypeAWS::IAM::Role] \ --output json # 获取某一条finding的详细信息 aws accessanalyzer get-finding \ --analyzer-arn arn:aws:access-analyzer:us-east-1:123456789012:analyzer/my-analyzer \ --id 12345678-xxxx-xxxx-xxxx-xxxxxxxxxxxx写自动化变更流程的话一般是先拉取findings清单 - 筛选白名单外的item - 生成策略差量 - 调用iam:UpdateAssumeRolePolicy或iam:PutRolePolicy完成变更 - 记录变更日志。注意自动变更之前务必在测试账号跑一遍。权限治理这种操作“误删”的后果远比“没删干净”严重。3.4 灰度实操先拿只读账号做试点如果这是你第一次在这个账号里做权限收缩我强烈建议先选一个“只读性质、非核心业务”的角色作为试点。实际操作中我习惯用这个流程选一个测试角色确认它的策略里有哪些权限被标记为未使用。把建议策略先存为JSON文件不直接应用。手动在哪个角色上新建内联策略把“建议策略”附加上去同时保留原策略。验证核心功能是否正常比如原来能读S3的地方还能读、原来能查日志的地方还能查。验证通过后再移除原策略。这个流程看起来比直接“一键应用”多两步但能在不改动原策略的情况下完成验证出了任何状况都能秒级回滚。生产环境里的权限变更永远要给自己留后路。另外说一下Access Analyzer刚发布未使用访问分析功能的时候我就试过直接把所有未使用权限批量用SCP“Deny”掉来验证影响面结果差点把一个正在跑批任务的角色给“误杀”了。CloudTrail显示某条权限90天没用但那个批任务是季度任务刚好跨过了统计窗口。所以不要在没有业务确认的情况下做全自动的“Deny所有未使用权限”。4. 和周边服务的联动SAM、WAF与Well-Architected框架4.1 在SAM应用开发中天然契合权限最小化如果你在用AWS SAMServerless Application Model管理Lambda函数这个工具的价值会进一步放大。SAM模板里通常会写Lambda函数的执行角色权限Globals: Function: Timeout: 30 Runtime: python3.12 Policies: - S3ReadPolicy: BucketName: my-data-bucket - SQSPollerPolicy: QueueName: my-queue这个Policies段定义的是CloudFormation在部署时自动创建的执行角色权限。问题在于随着SAM应用迭代你可能加了某个权限后来又不再用了但模板里的Policies段一直没删。结果就是每次部署都基于旧的权限集创建角色权限只增不减。配合未使用访问分析你可以在每个环境dev/staging/prod创建对应的Access Analyzer分析器定期对比“SAM模板里声明的权限”和“实际调用日志里出现的权限”。不一致的部分优先在SAM模板里更新而不是直接在IAM控制台改角色——不然下一次sam deploy会把你的修改覆盖回去。实测小经验当Access Analyzer提示某条权限未使用后我先去SAM模板里搜对应的action关键字确认无用后删除然后重新部署。这样既保证了代码与基础设施一致又完成了权限治理。4.2 别把WAF的权限遗漏在治理范围外做安全的人往往会花很多精力在WAF上——Web ACL规则、托管规则集、速率限制、Bot控制这些。但有个很容易被忽略的点是WAF本身的运维权限也可能被闲置比如某些角色开通了wafv2:UpdateWebACL权限但从上线起就没人动过。我的建议是做权限治理的时候把AWS WAF相关的权限也纳入Access Analyzer的检查范围。WAF权限和其他服务权限一样会产生findings如果发现某个角色有WAF写权限但长期未使用也是一种风险信号——毕竟WAF配置的改动直接影响线上防护效果不必要的写权限都给潜在攻击者多了一个可利用面。另外AWS WAF的日志全量日志、采样请求会在CloudTrail里记录API调用所以Access Analyzer的检测结果对这些权限同样足够准确。对WAF这类写权限我主张“宁缺毋滥”可视化运维界面能用只读权限完成的操作一律不开写权限。真有紧急变更需求时临时提权加审批更稳。4.3 Well-Architected审查时未使用访问报告是现成的证据AWS Well-Architected框架的安全支柱里有一条专门的实践叫“保护数据”和“管理访问权限”。真实做Well-Architected ReviewWAR的人都知道安全支柱的问题通常是最好回答也最难证明的——你说“我们遵循了最小权限原则”怎么证明Access Analyzer的未使用访问报告就是很硬的证据。我在给一个业务部门做WAR安全审查时直接从Access Analyzer导出了一份过去90天的未使用权限报告标注了哪些角色已经清理、哪些正在处理中。审计员看到的是“策略建议 实际变更记录 验证结果”的完整链路比任何口头说明都有说服力。同时Well-Architected Review的成本优化支柱也可以顺手用一下未使用访问分析如果你删掉了未使用的角色、策略、访问密钥也就减少了IAM实体的管理成本更重要的是那些“逻辑上未使用但还是被创建的资源”如果关联了不必要的权限通常也意味着资源生命周期没有被好好管理这条线索往往能顺藤摸瓜找到一堆可以回收的资源。4.4 用CLI习惯串联日常自动化AWS CLI在这里的角色不只是查询还可以做成定期跑批的脚本。我最常用的场景是每周一拉一次所有active findings。过滤出“lastAccessedTimestamp早于180天”的条目。和上周的报告做对比识别“新增未使用权限”。推送到内部审计群让对应负责人确认是否剔除。这个近乎半自动的流程运行两三个月后团队的权限治理就从“毕其功于一役”变成了“经常性保养”效果比一次性大扫除好很多因为不会再产生新的权限堆积。5. 常见问题与排查技巧实录5.1 为什么有的权限明明用了却被标记为未使用这是最劝退的问题很多人第一次看到“误报”就对这个工具失去信心。我测下来常见原因有三个CloudTrail没有记录该服务的API调用。有些服务比如部分AWS服务的历史事件确实不会完全进入CloudTrail或者在账号里被单独关闭了数据事件记录。未使用访问分析依赖CloudTrail如果数据源本身不完整“看起来未使用”就不一定是真的。这是工具本身的机制限制。控制台操作走了不同的IAM上下文。你在控制台操作时如果是通过角色切换Switch Role完成的日志记录的角色ARN和你分析的角色不是同一个就会造成“这个角色没调用过该API”的错觉。统计窗口覆盖时间不够。季度性任务、月度报表任务如果刚好落在分析周期之前就会把低频权限误判为未使用。这个我前面已经踩过调整窗口期能解决大半。处理优先级建议是先确认CloudTrail是否完整记录再排查是否有角色切换的上下文干扰最后考虑是否加白名单保留。5.2 未使用访问分析和Trusted Advisor的权限检查有什么区别经常有人把这两个搞混。AWS Trusted Advisor也提供IAM使用相关的检查比如“轮换访问密钥”。但Trusted Advisor更偏向“账号层面的安全配置是否合理”比如你有没有用过Root账号、有没有闲置的IAM密钥。而Access Analyzer的未使用访问分析关注的是具体权限操作级别的分析粒度完全不同。另一个容易混淆的是Service Quotas的权限建议它关注的是配额使用率和权限本身的启用/禁用没有关系。实际做权限治理时这几个工具可以组合使用但核心的“哪些权限从未被调用”只能从Access Analyzer拿。5.3 通过SCP加白名单的方式处理低频权限如果你的账号用了AWS Organizations还有一个很实用的技巧把“低频但有意保留”的权限从Access Analyzer的“待办列表”中挪到SCP白名单里通过组织的服务控制策略来显式“记录”这些特殊保留项。实际做法是在根OU或指定OU的SCP里写一个带aws:RequestedRegion条件或者按角色路径限制的Allow策略确保这些低频权限只被允许在特定条件下使用。这样从审计视角来看Access Analyzer的findings列表会瘦身很多剩下的都是真正需要处理的“未使用权限”。但注意SCP本身不直接给身份授予权限它是“边界控制”所以不会造成权限扩大。5.4 误删权限之后的快速回滚方案一不小心删错了权限是我见过最多的事故类型。这里分享一个我自己一直沿用的回滚方案在动手对某个角色做权限变更之前先把当前角色的策略列表和对应的策略版本导出到本地aws iam list-attached-role-policies --role-name my-role aws iam get-role-policy --role-name my-role --policy-name my-policy如果是自定义策略导出PolicyVersion的JSON内容。然后把导出的内容放到一个backup/目录里再执行变更。出了任何问题把备份的JSON原样放回去权限即恢复原状。我这里有个真实的处置案例一次我在清理“未使用的kms:Decrypt”权限时业务方说这个权限从来没被调用过结果删掉的第二天一个老旧的加密服务开始报错——原来是依赖一个自定义KMS密钥做解密只是日志里对应当天的记录缺失才没被Access Analyzer统计到。好在有备份一条命令就把权限加回去了整体影响时间不到十分钟。5.5 不同资源类型下的推荐差异Access Analyzer对IAM角色、IAM用户、访问密钥的分析结果展示方式不同这里列一个我的对比速查资源类型主要发现内容建议处理动作IAM角色角色上附加的策略中未使用的权限建议生成更新后的策略待确认后应用IAM用户用户上的权限、以及用户的访问密钥使用情况若发现密钥未使用建议轮换或删除若权限未使用建议移除访问密钥Access Key活跃与不活跃的密钥使用状态不活跃的密钥建议直接禁用/删除服务相关角色通常是AWS服务自身使用不建议手动修改自动忽略不列入推荐变更范围上表里最需要注意的是“访问密钥”这一类。很多团队只盯着权限策略忽略了闲置密钥的风险但密钥泄漏才是真正的雷。Access Analyzer的未使用访问分析会把你账号里每个IAM用户关联的密钥使用情况都拉出来如果某个密钥已经超过90天没有任何调用记录就应该立刻禁用再确认无业务影响后删除。这类发现的安全价值我觉得比权限策略的发现还要高。6. 经验补充与后续设想6.1 别一项一项点先建好自己的审查清单操作层面最后再给大家整理一个我目前固定使用的审查清单虽然简单但每一栏都是我踩过坑之后沉淀下来的检查CloudTrail是否完整记录需要分析的服务确认配置无遗漏。分析窗口至少30天起步低频任务多的团队请选90天甚至更长。先处理访问密钥类finding再处理角色权限最后处理用户权限。任何修改哪怕是AWS建议的修改都必须有回滚方案。用SCP或权限边界给测试角色做保护禁止对生产角色做无脑自动清理。每周定期拉一次报告把新增的未使用权限及时处理掉。6.2 后续可以继续扩展的方向从权限治理这个点延伸出去团队如果已经能通过Access Analyzer持续清理权限了下一步可以考虑结合基础设施即代码如Terraform或CloudFormation把“权限基线”固化下来。哪类角色可以有哪些权限写进模板里审核时直接看代码diff比在控制台里口头约定靠谱得多。再进一步有些团队已经有比较完善的CI/CD流水线可以在流水线里加一个“权限合规检查”步骤每次部署前先调用Access Analyzer的API拉取该资源的最新findings如果有高危级别的未使用权限直接阻断部署。这个自动化做法我还在试验中但整体收益预期很高。还有一个小方向是配合IAM Access Analyzer的外部访问分析一起用先查身份策略侧的未使用权限内部收缩再查资源策略侧的外暴露面外部收敛两边一起改。如果你手上的账号已经做过一轮权限治理下一步大概率就要面对“资源策略被外部实体过度共享”的问题这个组合拳建议提前备好。这个工具我用下来最大的体会是它没法替你决定哪些权限应该删、哪些应该留思考这件事还得靠人。但它能诚实、可复现地把“到底哪些权限已经不需要了”摆到你面前。对我来说这就已经值回票价了。权限治理最难的从来不是“怎么删”而是“不知道有什么可删”和“不敢删”——前者靠它发现后者靠流程和备份兜底。希望这篇记录对你有参考价值。
