6.2 一次 AccessDenied 事故排错实录

6.2 一次 AccessDenied 事故排错实录

本节摘要：备份系统集体报 AccessDenied,变更记录却一片空白。本节按真实时间线复盘：复现、trace 抓现场、审计日志回放取证、策略绑定比对，最终揪出根因——一次"清理闲置策略"的例行维护误伤了生产绑定。文末沉淀一张报错速查表。

事故现场

周二上午十点零七分，备份平台告警群连响：所有备份任务失败，日志里全是同一个词——AccessDenied。值班工程师的第一反应按顺序排过三个假设：备份系统凭证配错、MinIO 集群故障、昨晚有人改了权限。前两个很快排除：凭证没人动过，集群健康检查全绿，手动用同一套凭证跑一次上传，同样被拒。于是只剩第三个假设——但变更记录显示 MinIO 侧最近的变更是一周前的证书续期。

取证从这一刻开始：不猜，看数据。

第一步：trace 抓现行

MinIO 的 trace 命令能实时打印每个请求的处置明细，先把"被拒"这件事钉死在具体原因上：

# 实时追踪 S3 API 的拒绝请求
mc admin trace --verbose --path "s3.PutObject" fleet 2>&1 | grep -A5 AccessDenied
​

输出很快给出第一条线索：请求的拒绝发生在策略评估阶段，返回体里没有附加任何策略引用信息。这排除了"对象锁定拦截""配额拦截"等带特定错误码的路径，把嫌疑集中到 IAM 层。

第二步：审计日志回放

trace 只能看当下，要看"昨晚发生了什么"，需要审计日志。这套集群从上线第一天就开启了审计输出（这正是本章开头的流程纪律），审计事件通过 webhook 持续推送到日志平台：

# 审计输出的开启方式（本例集群早已配置,此处仅为记录配置位置）
mc admin config set fleet audit_webhook:primary enable=on endpoint=http://audit-collector.internal:8080/audit

# 回放昨晚的审计事件:过滤 IAM 相关操作
# 在日志平台按 event Category 筛选 iam,时间窗设为前一天 20:00 到当天 10:00
​

审计流水里，昨晚 23:41 的一段记录浮出水面。有个管理账号连续执行了多个策略解绑（DetachPolicy）与删除操作，操作来源是一台运维跳板机，执行者是自动化运维平台的一次例行任务，名字叫"清理闲置策略"。

第三步：比对策略绑定，锁定根因

顺着审计流水核对该任务的执行清单，根因清晰了：清理任务判定"闲置"的标准是策略最近 90 天没有变更记录——它把"策略文件没改过"当成了"策略没在用"。被清理的策略里包括一条绑定在备份服务账号上的自定义策略 backup-writer（6.1 刚好拿它做过示例）。策略连同绑定一起删除后，服务账号瞬间跌回"隐式拒绝"状态：没有任何 allow,所有写请求一律被拒。而备份任务每天只跑一次，直到第二天上午才有人发现——这就是变更记录空白的真相：变更确实发生过，只是它由自动化平台执行，没有走人工变更流程。

修复动作两分钟完成：从配置库里恢复 backup-writer 策略定义，重新附加到服务账号，备份任务下一轮全部恢复。但复盘的价值在修复之外——这次事故暴露的是"自动化维护任务的判定标准未经评审"这个流程漏洞。

图 6-2 排错路径决策树

事故速查表：报错码与根因

把这次事故和历年同类工单汇总成表，值班时按行排查：

复盘落下的三条流程改进

这次事故最终沉淀了三条规矩。规矩一：自动化维护任务的判定标准必须过评审——"闲置"的定义写错了，自动化只会更高效地制造事故。规矩二：策略与绑定纳入配置库管理——任何解绑删除都可从版本历史一键恢复，修复时间从小时级降到分钟级。规矩三：审计日志是权限体系的标配——这次能在两小时内结案，全靠审计流水从第一天就在记录。工具层面的结论只有一句：trace、审计、绑定核对，三件套齐了，AccessDenied 就不再是玄学。

本节要点回顾

• 先取证后动刀：trace 钉死拒绝阶段，审计日志回放历史，管理命令核对现状，顺序不可颠倒。
• 隐式拒绝是头号根因：allow 消失（策略被解绑）与 allow 从未存在，症状完全相同。
• 报错码是路标：InvalidAccessKeyId 指向凭证，SignatureDoesNotMatch 指向密钥与时钟，AccessDenied 指向策略。
• 流程漏洞比配置错误更值钱：自动化的判定标准要过评审，配置要进版本库，审计要常开。

人这一关排完了，下一节把数据本身的保密性补上：传输加密与静态加密的三把钥匙。