治理与合规框架

日志策略：先决定「不记什么」

多数团队的日志策略是从「要记什么」开始的，于是越加越多。反过来做 —— 先定不记的，剩下的才容易说清理由。

字段	建议	理由
查询时间	记录	故障定位与容量分析的基础，本身信息量低
查询域名（QNAME）	按类别决定	这是敏感度最高的一项。它既是排障的关键，也是「能看出谁在访问什么」的根源
来源标识	记设备而非个人	排障只需要定位到设备。若确实需要关联到人，应当有单独审批，而不是默认具备
查询类型（A / AAAA / …）	记录	对判断「为什么某个应用失败」很有用，信息量低
响应内容	不记	排障极少需要完整响应体；而它一旦留存，等价于把「访问记录」放大成「访问内容」
客户端子网（ECS）	不记，且不向权威透传	ECS 会把你的位置信息带给权威服务器，等于把隐私边界又往外扩了一层

保留期：按类别定，并写明理由

不要全局取一个折中值。建议按分级治理的四类分别定：

必须可审计：能满足一次事件调查的长度（通常 90–180 天）
聚合指标：可长达一年，因为不含标识信息
隐私优先：不产生逐条记录
禁止名单命中：按安全事件处理，单独定

关键要求：每一条留存策略都要能写出「为什么需要留这么久」。写不出理由的保留期，在合规评审里是第一个被质疑的对象。

脱敏：注意它与「可用性」的冲突

常见的脱敏做法是哈希域名，但这里有个坑：域名空间是有限的，用固定的哈希函数处理 `example.com` 这类常见域名，很容易被字典反推回去。

因此：

若目标是「无法反推」→ 必须用带密钥的哈希（HMAC），且密钥与日志分开保管、定期轮换
若目标是「排障时能看」→ 那本质上是加密而非脱敏，需按敏感数据处理，并限制访问
若无密钥的普通哈希 → 不构成有效脱敏，不要这样写进制度

最后一条是最容易被误当成合规手段的做法。

权限模型：三类角色，各自不能做什么

分离的重点不是「谁能做什么」，而是谁能做什么而不被另一人知道。所以每一类都要写明它的禁区。

角色	可做	不可做（关键）
运维角色	配置解析器、调整上游与分流、查看聚合指标与实时排障视图	不能导出历史原始日志。否则「谁访问了什么」的完整数据会集中在一个日常操作岗上
安全角色	查询历史记录（按需）、处置安全事件、维护禁止名单	不能修改日志留存策略。否则它可以先缩短保留期、再实施行为，从而绕过审计
合规角色	审计留存策略与实际执行是否一致、审批例外申请、导出审计报告	不能修改解析器配置。否则它可以制造一条「不留痕」的通道

三者构成一个闭环：运维执行但看不到历史全貌，安全能查历史但改不了留存规则，合规管规则但不碰配置。任何两人合谋才能绕开审计 —— 这正是职责分离要达成的效果。
在实际组织里这三类人常由同一小组兼任。若确实无法分离，至少要保证 「改留存策略」这一动作需要第二人审批并留痕，用它替代角色分离。

例外流程：三个完整示例

「建立例外机制」这句话没有可执行性。下面三个例子写到了时限与责任人，可以直接改成你们的形式。

示例 1某业务需要直连一个不在受控通道内的解析器

申请：业务方提交域名/服务、原因、预期时长、以及不这样做的影响评估。
复核（2 个工作日内）：安全角色确认是否有替代方案；若有，先走替代方案。
批准：合规角色确认该例外不会使某一类数据脱离审计范围。
生效并留痕：例外写入清单，含到期时间与责任人。
自动到期：到期即失效并要求重新申请 —— 不设「默认续期」。

第 5 条是关键。绝大多数「临时例外」之所以变成永久，是因为续期不需要任何动作。

示例 2安全事件调查需要调取超出常规保留期的历史日志

申请：安全角色写明事件编号、需要的时间范围、以及为什么常规查询不足。
范围最小化：只取该事件涉及的域名类别与时间段，而不是「全量导出再筛」。
双人复核：合规角色确认范围合理，并记录调取原因。
限时访问：访问权限带到期时间；导出物加水印与访问记录。
事后销毁：调查结束后按约定销毁导出物，并记录销毁时间。

这一条针对的是「调查本身成为新的泄露面」—— 最容易出事的地方，往往不是日志系统，而是为调查导出的那份副本。

示例 3某类敏感域名（如医疗、法律咨询）需要临时排除出记录范围

申请：提出分类依据与受影响范围，说明为何属于敏感类别。
评审（5 个工作日内）：合规角色评估该排除是否符合当地法规；需要时引入业务负责人。
技术核对：运维角色确认排除在技术上确实生效（而不是只改了一条规则），并留存核对方式。
记录与复核：排除项在审计时逐项复核，确认它仍满足当初的理由。

第 3 条最容易被跳过。规则改了不等于生效 —— 分流规则常常有多层，常见的失效方式是「在入口处排除了，但从备用出口又记录了一遍」。

审计闭环：季度查什么

审计的价值在于发现「制度与现实的偏差」。下面五项都是容易长期偏离、又不容易被察觉的。

检查项	具体看什么	常见的偏差
留存策略 vs 实际数据	实际保留时长是否与制度一致	制度说 90 天，实际因存储扩容变成了「全部保留」
例外清单有效性	每条例外是否仍有理由、是否已过期	已过期的例外仍在生效（没人清理）
访问记录完整性	谁的哪次查询被谁查看了，是否都有记录	紧急情况下走了「先查后补」，而补录没做
脱敏有效性	对留存的脱敏数据做一次尝试还原	用了无密钥哈希，被字典轻易还原（见上文「脱敏」）
职责分离是否仍成立	权限分配是否与设计一致（人员变动后常失效）	某人换了岗位但权限没收回

五项里有四项都属于「当初设计正确、后来慢慢偏离」。所以审计的重点不是设计审查，而是比对现状与设计 —— 这一点与部署运行手册里「生效配置要从终端侧反查」是同一条经验。

度量指标：怎么知道治理在起作用

治理本身也需要被度量，否则无法判断投入是否有效。指标要能反映「边界是否清楚」，而不只是「系统是否在跑」。

反映「边界清楚」的指标

受控通道覆盖率 —— 走加密通道的查询占比。它反映治理推进程度，也暴露绕行规模
未识别出口流量 —— 既不走受控通道、也不匹配任何已知例外的流量。这个数字应当趋近于零
例外数量与平均存续时长 —— 两者都在上升，说明制度在退让

反映「制度在运转」的指标

例外申请的处理时长 —— 过长会促使人们绕过流程，反而降低治理效果
审计发现项的关闭率 —— 只看发现数量没有意义，要看是否被整改
日志访问次数与用途分布 —— 访问频繁本身不是问题，但用途不明的访问需要能解释

最后一个指标值得单独说明：如果例外申请的处理时长很长，人们会开始绕过流程。这与「封堵不如提供受控通道」是同一个道理 —— 治理机制的可用性，直接决定它是否会被遵守。