同一份权限申请，先查日志还是先问人？

“这个账号为什么能看财务目录？同份”值班的小陈把截图甩进群里，配了一句，权限“日志里只有一条授权记录，申请申请人说没印象。先查”群里安静了两分钟，日志随后冒出两种声音：一种说先去翻系统日志，还先把时间线和操作人拉出来；另一种说别绕了，问人直接找申请人、同份找主管、权限找当时的申请审批人问一圈。两种做法都有人支持，先查也都有人吃过亏。日志扩展权限这类事，还先麻烦往往不在“有没有”，问人而在“凭什么有、同份谁认这笔账”。交叉验证信息，说白了就是别让单一来源替你做结论。

先翻日志：适合有留痕、可回放的场景

第一种做法是以系统记录为主线。具体动作很朴素：把账号、时间范围、操作类型定下来，先看授权变更日志，再看登录和访问日志，最后对照审批流里的单据编号。适合用的边界是——系统本身有审计功能，权限变更走的是线上流程，日志保留周期覆盖你要查的时间段。比如内部管理后台的目录权限、云资源的角色绑定、代码仓库的成员组调整，这类操作通常会留下操作者、时间、变更前后值。

选这条路的后果要提前想清楚。日志只能证明“某个账号在某个时刻被改成了什么”，证明不了“当时是不是本人操作、是不是被口头授意”。如果日志里只有一条孤零零的授权记录，没有对应的审批单号，你拿它去质问申请人，对方一句“我没点过”就能把话堵回来。更常见的失败是时间对不上：日志按服务器时区记，审批系统按本地时间记，差了八小时，你以为是同一天，其实是前一天晚上。下一步不是继续盯着日志看，而是把日志导出成表格，标出时区，再去审批系统里按单据号反查，找不到单据就转为问人。

还有一个反例值得记住。有人查扩展权限时只看“最近一次变更”，结果漏掉了半年前的一次组继承——用户没被直接授权，而是被加进了一个组，组又绑了角色。日志里那次组变更看起来跟本次问题无关，实际才是源头。所以翻日志要按“直接授权、组继承、角色绑定”三条线分别过一遍，别只查一条。

先问人：适合流程松散、记录残缺的场景

第二种做法是先找人。动作顺序是：先问申请人当时要这个权限做什么，再问直属主管是否知晓，最后找审批环节的经办人核对有没有口头或邮件同意。适用边界是——权限是线下批的、系统日志保留很短、或者变更发生在交接期，前任已经离职。小团队、临时项目、外包协作里这种情况不少，硬等日志往往等不出结果。

但先问人的风险在于记忆会互相污染。你问甲，甲说“好像是乙同意的”；你再去问乙，乙顺口说“对，我批的”。两个人一对话，原本模糊的事就变成了“有共识”。等你回头再查，发现根本没有书面记录，这时再想追责就很难。选错这条路的典型后果是：你把口头确认当成了交叉验证，其实只是把同一个不确定来源问了两遍。下一步应该是把口头信息当场落成文字，比如让对方在工单里补一句“某年某月某日，我同意某账号访问某目录”，再拿这条文字去和系统里的实际权限比对，对不上就说明中间还有一环没查清。

把两条线拧成一张核对表

实际处理时，比较稳的顺序是“先定范围，再并行，最后对账”。先定范围：这个账号、这个目录、这个时间段，别一上来就全库翻。然后并行做两件事——导出授权变更日志，同时给申请人和主管各发一条只问事实、不问评价的消息，比如“请确认某月某日是否申请过某目录的读取权限”。两边信息回来后再对账，重点看三处：时间是否对得上、审批单号是否存在、权限来源是直接授权还是组继承。

对账时可以用一张很土的核对表：第一列写权限名称，第二列写日志里的变更时间，第三列写审批单据号，第四列写被询问人的原话摘要，第五列写结论（一致、缺单据、缺日志、来源不明）。五列里只要有一列空着，就不要下“没问题”的结论。扩展权限的交叉验证，本质上就是让系统记录和人的陈述互相咬合，咬不上就继续查，而不是挑一个看起来顺眼的来源结案。

最后提醒一句边界：如果涉及的是财务、人事、生产控制这类敏感系统的权限，或者你发现日志被人为清理、审批单据缺失且当事人说法反复，就别在群里继续推理了，按单位的信息安全或审计流程上报，让有权限调取完整记录的人来处理。日常的目录权限、共享盘权限，用上面这套对账办法基本能理清；理不清的时候，把已核实的部分写清楚、把缺口标出来，比硬给一个结论更有用。