日志被人删了，泄密就变成"没发生过"

有个做电子模组的客户，去年碰到一件很窝火的事：他们给某品牌做的一款新品，结构还没对外公布，对手那边已经拿着几乎一样的方案去报价了，时间比他们早了半个月。

内部肯定有问题，这不用猜。IT 部门去查记录，结果让人无话可说——那台存 BOM 和结构图的文件服务器，日志只保留 7 天，正好把关键时间窗覆盖掉了；而且日志就存在本机，管理员账号有删除权限。也就是说，只要有人想删，删完就干净了。

最后的处理结果是：全员重签保密承诺书，涉事的三个人调岗。案子没查出来，证据链在第一步就断了。

日志这件事，五个坑踩一个就白搭

坑一：留存太短。很多系统默认滚动 7 天或者 30 天，磁盘满了就覆盖最老的。可数据泄密这种事，往往两三个月后才在市场上有反应，等你去查的时候，记录早就被自己覆盖了。等保要求日志留存不少于六个月，这不是形式主义，是给追溯留时间。

坑二：管理员既是运动员又是裁判。系统管理员能改配置、能删日志、还能删自己的操作记录。真要有内鬼，第一个动作往往是清痕迹。日志的写入权和删除权，必须跟系统管理权分开。

坑三：时间对不上。服务器、终端、文件网关各走各的时钟，互相差个十几分钟很常见。查一起事件时，A 机器显示 14:02 拷出，B 机器显示 13:51 登录，怎么也对不到一起。时间不统一，日志再多也是散的。

坑四：只记"登录成功"。大部分系统默认只记录登录和错误，文件被读了、被复制了、被压缩打包了、被解密了，一概不记。这些才是真正要看的动作。

坑五：日志本身没保护。日志明文存在业务服务器本地，勒索病毒一进来，第一个加密的就是它。攻击者很懂这个道理——先毁记录，再谈条件。

能追责的日志，长什么样

日志要外送，不要留在本地。终端、服务器、文件网关、加密系统的日志，实时推送到一台独立的日志服务器，业务机上只留很短的缓冲。这样即使业务机被攻破、被加密，记录还在另一台机器上。

写进去就不能改。日志目录设置成只追加，写入账号和读取账号分离；有条件的话用哈希链或者一次写多次读的存储，事后能验证"这段记录有没有被动过"。

三权分立。系统管理员管配置，安全管理员管策略，审计员只看不改。审计员的账号不能用来登录业务系统，系统管理员也没有权限碰审计库。这个结构在小公司看着别扭，但它是唯一能防住"内部人清痕迹"的办法。

该记的动作一个不能少。U 盘拷出、批量解密、外发审批通过与拒绝、打印、截屏、另存到本地、非工作时间访问敏感目录、连续多次打开同一份图纸——这八类动作是泄密案子里出现频率最高的，必须留痕，而且记录里要带人、带时间、带文件名、带目标位置。

统一时钟。所有设备指向同一组内网时间源，时区统一。

有了这套，事情会怎么变

最直接的变化是威慑。员工知道拷贝图纸这件事会被完整记下来，而且删不掉，很多"顺手带走"的念头在动手前就消失了。

第二个变化是办案速度。以前查一起泄密要靠猜、靠谈话、靠互相指认，现在是从时间点倒查：谁在那个时间段访问了这份文件、拷到了哪里、之后有没有外发。半天能出结果的事，不用拖三个月。

第三个变化是对外交代得过去。客户审厂、等保测评、司法举证，问的其实都是同一个问题："你怎么证明你的管控是有效的？"拿得出一份完整的、连续的、没被改过的记录，比拿十页制度文件管用。

上邦在给制造企业做这套落地时，通常建议先把"文件服务器 + 加密系统 + 终端"三处日志接进来，不用一次上全套。这三处覆盖了八成的泄密路径，成本可控，见效也快。剩下的，等这套跑顺了再扩。

说到底，日志不是给 IT 看的，是给未来的自己留的一份证词。真出事那天，它要么救你，要么什么都不是——区别就在平时有没有人认真对待它。