带宽跑满、CPU 却闲得发慌，日志翻出来干干净净——这种半夜的电话我最不愿意接。接下来两个小时基本就是在猜：是备份任务在跑，还是有人在往外搬东西。数据泄露检测这件事，难的不是工具不够多，是很多人一上来就把观察面选窄了，要么只盯日志，要么只盯流量，剩下那一半线索等于主动放弃。
数据泄露检测，先回答清楚三个问题
真出了事，你要回答的无非三句：有没有发生、丢了什么、从哪儿出去的。这三个问题的答案来源不一样。日志擅长回答「谁、什么时候、做了什么」——某个账号在凌晨导出了一批记录，某个接口被反复调用，某个数据库账号头一回从内网另一台机器连过来。流量擅长回答「多少、往哪个方向、跟平时的节奏对不对」——出口比平时多出一大截，某个陌生目的地址连着几天收到小量上传。
所以别把这两样当竞品。它们更像两条腿，一条管人，一条管量。只有日志，你能知道有人动了数据库，但不知道他到底搬走没；只有流量，你能看出有东西在往外走，但不知道是谁干的、从哪个应用走的。
日志这一头，好用，但脆
日志的好处是细。应用日志里能看到用户标识、来源 IP、请求路径、响应码；数据库的审计日志能看到谁执行了什么语句；WAF 日志能告诉你哪个 payload 被拦下来了。想还原一次操作的来龙去脉，离开日志根本没法谈。
问题是它脆。第一个坑是采不全，不少站点只留了 nginx 的 access log，应用层的导出、下载、批量查询压根不记。第二个坑是会被改，进场之后先清 /var/log、顺手 truncate 掉审计表，这属于常规操作，日志服务器要是和业务跑在同一台机器上，基本等于没有。第三个坑是时间，几台机器的时区、NTP 没对齐，日志和流量图差着十几分钟，对时间线的时候能把自己逼疯。
还有个更隐蔽的：日志轮转。忙的时候一盘日志几天就滚过去，等你想起去查，那段正好被覆盖。留多久合适没有标准答案，看你的盘、也看业务合规要求，涉及监管留存的以官方页面或监管口径为准，别拿别人的数字硬套。
流量这一头，不容易被糊弄
流量最大的优势是它不依赖业务代码有没有写日志。交换机镜像口、NetFlow 或 sFlow、主机上的 ss -tunp 和 conntrack，甚至 eBPF 挂上去看 socket，都能拿到「谁和谁在通信、传了多少」。日志能删，链路上已经流过去的字节删不掉。
看流量别只盯入站，出站才是泄露的方向。做法很土但管用：先给正常时段画基线，白天多少、夜里多少、备份窗口多少，然后看偏离。偏离不一定坏，但值得追。深夜出口比平时多出一截、某个陌生域名连着几天稳定地收到小流量上传、内网一台 Web 机突然去连数据库以外的端口，这些都算信号。
局限也得说清楚：TLS 一加密，内容就看不见了，你只能靠元数据——目的域名、连接时长、上下行字节数、SNI。所以 DNS 查询日志和出口目的清单，往往比抓包更有用。真要靠内容判断，得在出口做解密，成本和合规风险都不小，不是小站该随便上的。
内鬼和外部入侵，重点不一样
外部入侵的典型路径是先拿一个低权限入口，再横向，再外带，所以你要看的是「新出现的通信关系」——一台机器连了以前从没连过的地方。内鬼是另一回事，他用的全是合法权限，流量上未必异常，这时候日志里的行为序列更值钱：谁在非工作时间查了不属于他业务范围的记录，谁把查询结果导成了文件。
别指望一套规则通吃。先想清楚你更怕哪一种，配置的重心就放哪边。嘴上都说怕外部攻击，实际最容易出事的往往是权限给太宽。
预算有限，先补哪一头
我的顺序是先立两样东西，都很便宜：一是统一时间，所有机器 NTP 对齐，这步不花钱但能救命；二是出口基线加目的清单。这两样做完，再谈买不买探针、上不上大平台。
日志侧的优先级我一般这么排：应用层的关键动作——登录、导出、下载、权限变更、批量查询——先把字段补齐，带上用户标识和来源 IP；数据库审计单独开，注意慢查询日志不是审计日志，它记的是性能不是人；日志往一台独立机器上送，别和业务同生共死。
几个看着在干活、实际白忙的动作
只统计登录失败次数。撞库成功那一次返回的是 200，失败告警响成一片的时候，成功的那条安安静静躺在 access log 里。
只看请求数不看响应体积。一个接口被调了十来次没人管，但每次都返回几十兆，这种事在日志里完全正常，在流量里很刺眼。
告警阈值写死。业务有促销有峰谷，固定阈值不是天天误报就是天天沉默，后面大家干脆把告警静音，等于没做。
探针买了，报表没人看。安全设备最大的成本不是买，是有人每周真的去翻一次。还有时间没同步这一条，前面提过，但还得再说一遍，因为它最容易被忽略又最耽误事。
真出事那天，先留证据再动手
第一反应是重装系统、改密码、删可疑文件的，十个里大概有八个会把证据一起格式化掉。合理顺序是先掐外联——把机器的出口隔离掉，但别关机；然后做内存和流量的快照，抓一段包、导一份进程列表和连接列表；再把日志备份到另一台机器上，保留原始文件的时间戳。
之后才是处置：改凭据、清后门、补漏洞、复盘。数据泄露检测真正有效的做法，是把日志和流量并排摆到同一条时间轴上对一遍，问题往往出在「两边都有一点，但谁都没连起来」的地方。
回到那个问题：盯日志还是盯流量。答案是都要，但如果只能先做一件，我建议先把出口基线做出来，它便宜、见效快，也不依赖开发改代码。日志是精装修，得有，但别指望它在你没采全的时候就显灵。再顺手提醒一句，方案落地之后隔段时间真拿一条日志去流量里找、拿一条流量去日志里找人，对不上就说明链路断了，这比任何报表都实在。
【版权声明】：本站内容若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
