波仔
🛡️ 第六章 组织机构的安全防范对策
📄 一句话概括

留存不少于六个月是《网络安全法》的硬性条款，但【有日志】和【日志能用】是两件事——前者靠存储，后者靠集中与关联。

📝 本节和前面几节的关系

6-5 讲的 MTTD（平均发现时间）和这一节直接相关：日志是发现能力的原材料——没有日志，检测规则就没有输入；日志不集中，最初 60 分钟会全部花在【先找到日志在哪台机器上】。 它和 6-11 是上下游：日志是最常见的一类电子证据；这一节讲【怎么把它留下来、串起来】，下一节讲【怎么让它站得住】。

一、先记住这条硬性规定

《中华人民共和国网络安全法》第二十一条第（三）项：

采取监测、记录网络运行状态、网络安全事件的技术措施，并按照规定留存相关的网络日志不少于六个月。

六个月约等于 183 天。这不是建议，是条款。 这一条在实践中的意义值得说清楚：

二、要覆盖的七类日志

只留一类日志的组织很常见，而这在调查时几乎一定不够。七类要覆盖到：

为什么必须多类并存？因为每一条单独的日志都只能看到【一部分真相】，而事件的真相在它们之间。举个例子：只看防火墙日志，你看到的是【有个连接出去了】；只看主机日志，你看到的是【有个进程启动了】；而把两者按时间对齐，你才能说出【这个进程是被谁启动的、它把数据发到了哪里】。 这正是第三段那个时间线演示要做的事。

七类里最容易被漏掉的是【运维操作】。原因很现实：它需要把命令行审计、堡垒机、配置管理系统这些【平时只用来干活】的工具，也打开日志并接入集中平台。但在事故调查里，运维操作日志往往是唯一能回答【是谁动了这台机器】的证据（1-4 讲的内部违规场景里，这一点尤其关键）。

三、动手 Demo：做一次留存达标体检

days = [("网络设备", 400), ("安全设备", 365), ("主机操作系统", 180),
        ("中间件", 90), ("应用访问", 30), ("运维操作", 730), ("身份认证", 200)]
need_d = 183                                   # 六个月的近似天数
ok = 0
for a, d in days:
    gap = need_d - d
    if gap > 0:
        res = "不达标"
    else:
        ok += 1
        res = "达标"

实跑输出：

三、做一次留存达标体检
  日志类型              实际留存      缺口          结论
  网络设备              400 天        -             达标
  安全设备              365 天        -             达标
  主机操作系统          180 天        3 天          不达标
  中间件                90 天         93 天         不达标
  应用访问              30 天         153 天        不达标
  运维操作              730 天        -             达标
  身份认证              200 天        -             达标
  达标率                4 / 7 = 57.1%
  → 三个不达标的系统，恰恰是出事时最需要它们的三个。

读这个输出：

四、从日志还原一条攻击时间线

这是集中存储真正的价值所在。下面是一次被还原出来的完整攻击链：

五、从日志还原一条攻击时间线
  时间          来源            事件
  09:02:11      身份认证        账号 svc_backup 从境外 IP 登录成功
  09:03:47      运维操作        该账号执行了一次权限提升
  09:06:02      中间件          Web 容器读取了 /etc/passwd
  09:11:30      主机 OS         新建用户 temp01 并加入管理员组
  09:15:08      网络设备        向某外部地址上传 82 MB 数据
  09:20:45      安全设备        该外部地址命中威胁情报黑名单
  → 单看任何一条都不算决定性，六条串起来就是一条完整攻击链。
     这就是集中存储真正的价值：日志分散在各处时，没人能串起来。

读这个输出（逐条看它来自哪类日志）：

注意这条链上最重要的一点：九分钟之内，六个环节各留下一条记录。如果这六类日志各自躺在自己的机器上（甚至部分已经轮转掉），那么调查到第 3 条就会断掉——你只能知道【有人提权了】，但说不出他做了什么、往哪发了。 这就是【集中存储】这四个字的实际含义：不是把日志抄一份放着，而是让它们能在同一个时间轴上被对齐。

五、三条最常见的违规与正确做法

违规的形态很集中，就这三种：

正确做法里有一条是核心：日志要集中存储在受保护的、独立于生产环境的专用服务器或安全云服务上。这样做的意义只有一个：攻击者即使控制了生产环境，也删不掉你的日志。配套的两条要求是：① 写入之后不可篡改（比如一次写入、只能追加的存储）；② 访问日志本身也要被记录（【谁看了日志】这件事也是审计对象）。

第二条正确做法是【不能只为留存而留存】。日常审阅与自动化分析，能把安全防护从事后追溯提升到事中预警。这个提升的关键在于【关联】——上面那条时间线里，1、2两条单独看都不起眼，合起来就是强信号；而这类关联靠人盯着六个不同的控制台是不可能完成的，必须由 SIEM 这类工具自动做。

六、⚠️ 2026 现状

30 秒实验

今天做两个动作，各 15 秒：

  1. 找一个你每天在用的系统，问它一个问题：三个月前的登录记录，能查到吗？ 很多系统默认只保留 30 天甚至更短——而【三个月前】在事故调查里是很常见的回溯窗口（因为攻击者的驻留时间常常以月计）。
  2. 检查你的日志是不是【能自己删掉】的。关键问题是：一个拥有管理员权限的账号，能不能顺手把日志清掉？ 如果答案是【能】，那么日志在真正的攻击面前价值有限——因为这正是攻击者会做的第一件事。

这一节要带走的一句是：日志的价值不在【存了多少】，而在【出事后多少分钟内能串出一条时间线】——决定这个的是集中与关联，而不是容量。

常见误区

  1. 错误：日志留存六个月，就是找个硬盘存着。——纠正：【存着】和【能查】之间差着三件必要的事。① 集中——日志分散在各设备本地时，任何一次调查都要逐台登录，时间成本极高，而攻击者往往已经清掉了某些机器的日志；② 时间同步——不同机器的时钟不一致，日志就无法按时间对齐，那条六条记录的时间线根本拼不出来（NTP 看起来是个小配置，它是日志可用的前提）；③ 防篡改——可被删除的日志，在真实攻击面前不可依赖。这三件事里，第 ② 最容易在检查中被忽略，也最容易在实战中造成麻烦：当你看到两条来自不同机器的日志时间相差几分钟，你无法确定是【顺序如此】还是【时钟偏差】。

  2. 错误：日志级别越高越好，全开 DEBUG 最保险。——纠正：日志级别与可用性是反比关系。全开低级别日志会带来三个后果：① 存储成本爆炸（你要为六个月的全量 DEBUG 日志准备多大容量，可以先算一遍）；② 真正的信号被淹没——检测规则面对海量正常日志时，误报会多到没人再看；③ 应用性能下降（高频写日志会拖慢系统）。更实用的策略是【按类别定级别】：安全相关的动作（认证、授权、配置变更、敏感数据访问）用较低级别（记录详细），正常运行状态用较高级别（只记关键）。换句话说，日志策略要回答的不是【记多少】，而是【哪些动作必须留下痕迹】——这个清单其实可以从风险清单里直接推出来。

  3. 错误：日志是安全部门的事，应用日志由业务团队自己管就行。——纠正：事故调查需要的日志，往往正好落在业务团队手里。从上面那张七类表看：应用访问、身份认证、中间件这三类，通常都由开发或运维团队维护，而它们恰好是【到底发生了什么】最关键的三个位置。如果各团队只按自己的需求设计日志（为了排错、为了性能分析），那么安全侧最需要的字段（来源 IP、账号、操作对象、结果状态）很可能根本没被记录下来——这时候再回头改，历史数据的缺口是补不回来的。 所以正确的做法是：在项目立项或系统上线阶段，就由安全侧提出【必须记录的字段清单】，把它作为上线检查项之一（这和 4-11 讲的安全编码是同一类【前置动作】）。

  4. 错误：既然日志这么重要，那出事之后第一件事就是去看日志。——纠正：方向对，但顺序有个前提先要处理：先确认日志本身没被动过。攻击者在环境里停留一段时间后的常规动作，就是清理或篡改与自己相关的日志。所以看日志之前通常要先做两件事：① 确认集中存储的那一份还在且完整（这也是集中存储的价值所在——本地的可能已经被删了）；② 校验日志文件的完整性（和 6-11 用哈希校验是同一套方法）。另外一个实务细节是：【日志里没有记录】和【这件事没发生过】是两回事——前者可能是因为级别没开、可能是因为已被删除，也可能是因为该行为压根不在记录范围内。 调查结论里把这两者区分清楚，是专业与否的分界线。

自测三问（点开对答案） 1. 为什么【日志集中存储】这件事本身就有安全价值？ —— 因为**它改变了攻击者与防守方之间的成本结构**。**如果日志分散在各机器本地，攻击者只要拿到一台机器的管理权限，就可以顺手删掉这台机器上的日志**——**而防守方往往在几天甚至几周后才发现，那时本地日志已经无法恢复**。**集中存储把这条路径切断**：**日志在采集那一刻就离开生产环境，写入一个攻击者不易触碰的地方**（**独立网段、独立凭据、只允许追加的存储**）。**攻击者要掩盖痕迹，就必须先攻破集中平台本身**——**那是一个显著更高的门槛，而且这个过程本身也会留下痕迹。** **所以【集中】不是为了方便查询（虽然它确实方便了），它的首要目的是让日志在被需要时确实存在。** **配套要做对三件事才有这个效果**：**写入通道与生产环境的管理凭据分离、存储不可篡改（一次写入）、以及对日志的访问本身也记录日志。** 2. 为什么日志要覆盖七类而不是只留关键的一两类？ —— 因为**安全事件的真相出现在【不同类型的记录相互印证】的地方，而不在任何单一来源里**。**从那段时间线看得很清楚**：**身份认证只告诉你【谁登录了】，运维操作只告诉你【执行了什么】，中间件只告诉你【读了什么文件】，主机只告诉你【建了什么账号】，网络设备只告诉你【发了什么数据】**——**每一条单独看都可能被解释成正常行为**（**服务账号登录很常见、读配置文件很常见、新增账号很常见**）。**只有把它们对齐到同一条时间轴上，【九分钟内六件事依次发生】这个模式才浮现出来**。**这也解释了为什么【集中】比【多留】更重要**：**日志再多，如果分散在不同控制台、用不同格式、时钟还不同步，就无法形成这种印证。** **实务上，七类不一定每类都要留满六个月**（**成本要算**），**但七类都要【接得进来、能对齐时间】这件事是最低要求**——**而这就需要在采集和字段规范上投入。** 3. 日志留存六个月和【数据最小化】原则会不会冲突？ —— **表面对立，实际不冲突，因为它们管的不是同一批数据**。**数据最小化针对的是【可识别到个人的业务数据】**（**比如客户名单、身份证号、交易明细**），**要求【只在必要范围内收集、只保留必要时间】**；**而日志留存针对的是【系统与操作的记录】**，**法律明确要求不少于六个月**。**冲突点出现在日志里混进了业务数据的时候**——**比如某些应用把完整的请求体（含用户信息）写进了访问日志**。**这时候的正确处理不是【少留日志】，而是【日志脱敏】**：**记录【谁在什么时候访问了哪个接口、结果如何】，但不记录请求体里的敏感字段**（**附录 A.8.11 的数据脱敏就是这一项**）。**所以实务上要把日志里的字段分成两类**：**审计必需的（保留）与业务明细（脱敏或不记）**。**这件事越早做越好**——**日志一旦按原样攒了两年，回头脱敏的成本会非常高。**

相关笔记