结论先行：日志平台建成之后，最容易被放过的一件事是「谁能看什么」。日志里同时混着系统线索、账号信息、个人信息与业务明细，而绝大多数查询需求只用到其中一小部分。可行的做法是把数据先按敏感度分层，再按角色划定可见范围，个人信息类字段在采集侧完成脱敏，原始字段的调阅走单独授权并全程留痕。
为什么日志权限总被拖到最后
多数团队把日志平台当成「运维工具」，默认使用者都是可信的内部人，于是权限处理成了上线后的收尾工作。但日志的敏感性比想象中高，原因有三层。
- 内容跨度大。一批日志里可能同时有主机名、接口路径、登录账号、来源地址、手机号、证件号与订单字段。
- 一次检索就能批量取数。一个条件加上导出，几条命令就能把成规模的个人信息带走，这比逐条查看风险高得多。
- 账号权限容易越给越大。上线初期为了「先能用」，往往先给管理员角色，之后就没人再收回来。
结果是：日志平台在安全侧是资产，在合规侧却可能成为个人信息泄露的通道。
先把日志按敏感度分层
分层的目的是让「必须看的能看、不必须的不看」。可以按四类落地。
| 层级 | 典型字段 | 可见范围 | 处理方式 |
|---|---|---|---|
| 系统与链路类 | 主机、服务、接口、错误码、耗时 | 运维与研发按系统授权 | 原样保留，便于排障 |
| 身份与账号类 | 登录账号、来源地址、会话标识 | 安全与运维按需授权 | 保留，调阅留痕 |
| 个人信息类 | 手机号、证件号、客户账号 | 默认不可见 | 采集侧脱敏，原始值单独授权 |
| 业务明细类 | 交易流水、订单字段、金额 | 按业务域隔离 | 跨域调阅需审批 |
这张表的用法很简单：先给现网日志做一次字段盘点，把每个字段归到某一层；归不了层的字段，说明连用途都还没说清，正好借这次机会确认要不要采。
权限从三个维度给
- 按角色。谁能登录平台、能做什么操作（查询、导出、改规则、管账号）要分开，不要一个管理员角色包打天下。
- 按数据域。同一批日志里，不同业务域的数据可以隔离授权，跨域查询默认不允许。
- 按字段。同一份日志，不同角色看到的字段集合可以不同：普通使用者只看脱敏后的内容，原始值只对指定角色开放。
脱敏放在哪一层，取舍不同
| 位置 | 优点 | 代价 |
|---|---|---|
| 采集侧 | 源头就处理掉，落库即安全，后续环节不用反复判断 | 原始值不可回溯，遇个别排障场景需要另开通道 |
| 存储侧 | 保留原始值，按角色分流 | 对存储与访问控制要求更高，一处配错就漏 |
| 展示侧 | 改动最小，界面层按角色显示 | 导出与接口容易绕过，需要逐个出口把关 |
更稳妥的组合是：个人信息类在采集侧处理，排障必需的身份类字段保留但单独授权。接口输出与导出这两条出口单独设一道关，避免只在界面上做了限制、换个通道就绕开。
调阅留痕与定期复核
留痕要能回答三个问题：谁在什么时候、用什么条件查了哪些数据、导出了多少条。原始数据与跨域数据的调阅走申请与审批，并设置授权时效，到期自动回收。此外建议固定两个动作：定期复核权限清单，把不再需要的授权收掉；人员离职或转岗时，权限回收并入流程，而不是靠人记得。
边界与前提
- 脱敏不是越狠越好。把排障必需的字段也一起处理掉，等于用合规换来了定位能力的下降。先确认哪些字段是定位真的需要的。
- 权限收得太紧会催生绕行。正常业务需求如果每次都要走长流程，很容易出现私下导数据的情况，风险反而更大。要给常规需求留一条便捷通路。
- 分级要和业务方一起定。哪些字段算敏感、谁该看到，运维单方面定的口径大概率与实际业务对不上。
落地清单
- 对现网日志做一次字段盘点，逐个字段归入敏感度层级。
- 把无法归层的字段列出来，确认是否必要，不必要的不采。
- 按角色拆分平台操作权限，查询、导出、改规则、管账号分开授权。
- 为个人信息类字段在采集侧配置脱敏规则，保留必要字段的单独授权通道。
- 核查接口与导出两条出口，确认限制不只在界面上生效。
- 建立原始数据调阅的申请与审批流程，设置授权时效。
- 把权限复核与离职回收写进例行工作，并按季度执行一次。
日志平台的价值在于「能查、查得准」，能不能长期用下去，则取决于「谁该看、谁不该看」是不是写清楚了。奇摩在日志与可观测平台的落地中，通常先把字段分层与授权口径和业务方对齐，再谈采集与检索的调优。如果你希望先把日志平台的数据权限与脱敏口径过一遍，欢迎 预约咨询。