如何查找绑定特定AWS托管策略的IAC及策略全量使用位置

除了IAM角色详情页的Access Advisor关联资源排查外，你还需要覆盖以下核心排查点位，避免策略下线后触发权限报错：

注意：Access Advisor的数据仅回溯最近365天的访问记录，休眠超过1年的关联实体不会出现在Access Advisor结果中，必须通过附加实体列表核对，避免漏查长期未运行的资源

1. IAM实体直接附加关系排查 #

这是最容易漏过休眠资源的排查项。
操作步骤：

• 登录IAM控制台，左侧导航栏选择「策略」，搜索框输入AWSConfigRole定位到对应弃用托管策略
• 进入策略详情页，切换到「附加的实体」选项卡，逐一记录所有直接附加该策略的IAM用户、用户组、角色信息
• 多账号部署AWS Organization的场景下，通过管理账号进入IAM Access Analyzer组织视图，逐成员账号扫描该策略的直接附加实体，避免成员账号配置漏查
• 命令行快速全量排查可执行：aws iam list-entities-for-policy --policy-arn arn:aws:iam::aws:policy/AWSConfigRole，返回结果会直接列出所有关联的用户、组、角色

2. 权限边界与服务控制策略（SCP）关联排查 #

这类权限管控逻辑属于全局权限边界，不会被Access Advisor识别为策略直接关联资源。
操作步骤：

• 进入AWSConfigRole策略详情页，切换到「策略使用情况」面板，筛选使用类型为「权限边界」的条目，记录所有将该策略配置为权限边界的IAM实体
• 登录AWS Organization管理账号，进入「策略-服务控制策略」页面，逐份检查SCP的JSON内容，搜索AWSConfigRole对应的策略ARN，确认没有SCP引用该策略做权限判断逻辑
• 多账号场景下可通过AWS Config托管规则iam-policy-in-use批量扫描全账号的权限边界配置，提升排查效率

3. AWS Config服务链路关联角色排查 #

该托管策略原本为Config服务设计，服务本身的关联角色是最高优先级排查对象。
操作步骤：

• 逐区域进入AWS Config控制台，查看「设置」页面的配置记录器角色、合规规则执行角色、修正操作执行角色，核对这些角色的附加策略列表，确认没有直接挂载AWSConfigRole
• 检查Config跨账号聚合器配置：逐一核对被聚合账号给聚合器授权的角色权限，确认没有依赖该弃用策略
• 排查Config的第三方服务集成链路：包括给Security Hub、CloudWatch告警、SSM自动化推送数据/执行操作的关联角色，避免集成链路权限中断

4. IaC模板与自动化流水线排查 #

很多场景下线上实体已经解除了策略关联，但代码仓库中的模板仍保留了策略引用，下次部署会重新挂载，这类问题完全无法通过Access Advisor发现。
操作步骤：

• 全局检索所有基础设施即代码模板：包括CloudFormation、Terraform、CDK、SAM模板，搜索AWSConfigRole字符串，删除所有硬编码的该策略引用
• 逐区域检查CloudFormation活跃栈、栈集，筛选资源类型为AWS::IAM::Role、AWS::IAM::Policy的资源，核对其关联的托管策略配置
• 检查Service Catalog中的产品组合、预置产品，确认产品内置的IAM角色配置没有引用该弃用策略

5. CloudTrail历史操作日志回溯 #

通过日志回溯可以发现临时附加过该策略、已经被移除但可能被自动化流程重新附加的实体。
操作步骤：

• 进入CloudTrail控制台，打开「事件历史」，筛选事件来源为iam.amazonaws.com，检索近90天内包含AttachRolePolicy、AttachUserPolicy、AttachGroupPolicy操作且请求参数中策略ARN为arn:aws:iam::aws:policy/AWSConfigRole的事件，确认所有关联实体都已被记录
• 如果开启了CloudTrail日志归档到S3或CloudTrail Lake，可检索更长时间范围的操作记录，覆盖休眠周期更长的资源
• 筛选所有调用Config服务API的事件，核对调用主体的权限来源，确认没有主体仅依赖AWSConfigRole获取Config操作权限

排查完成后不建议直接下线策略，可先将该策略更新为默认Deny所有操作的版本，灰度观察72小时，确认没有权限报错后再正式执行停用操作，降低业务影响风险。

内容的提问来源于stack exchange，提问作者Ashirwad.nivalkar