公司财务部和研发部共用一个内网，某天财务系统突然报错，登录异常。运维一查日志，发现是研发部某台测试机在凌晨三点反复尝试连接财务数据库端口——这台机器本不该有访问权限。问题很快定位：隔离策略没生效，而审计日志成了唯一能说清“谁、什么时候、干了什么”的证据。
隔离不是一堵墙，而是带记录的门禁
很多人以为部署了VLAN、防火墙或微隔离，网络就自动“安全”了。其实不然。隔离策略本身只是规则，它决定“能不能通”，但不回答“有没有人绕过、改过、误配过”。这时候，审计日志就是那本自动书写的值班日志：谁修改了防火墙ACL？哪台终端跨区访问了生产数据库？策略生效前是否有拒绝记录？这些细节全靠它留痕。
日志里藏着关键动作
典型的网络隔离设备（如下一代防火墙、SDN控制器、零信任网关）产生的审计日志，通常包含这几类字段：
- 时间戳：精确到毫秒，便于关联其他系统日志；
- 源/目的IP与端口：不只是地址，还包括所属区域标签（如“DMZ→核心业务区”）；
- 策略ID与匹配结果：例如“rule-205：DENY，因违反‘禁止开发网段访问数据库’”；
- 操作者信息：如果是管理员调整策略，会记录登录账号、来源IP、CLI命令或Web操作路径；
- 会话状态变化：如“连接建立→被拦截→连接重置”，反映策略实时生效情况。
别让日志变成摆设
见过太多企业开了日志功能，却把日志存在本地硬盘上，半年没人看，磁盘满了就自动覆盖。也有的把日志导出成Excel手动翻查，遇到一次批量扫描攻击，得花两小时筛数据。真正有用的审计日志，得满足三点：一是集中存储（比如对接SIEM平台），二是保留周期符合合规要求（金融行业通常不少于180天），三是支持按区域、协议、动作类型快速过滤。举个实际例子：
2024-06-12T03:17:22.891Z, DENY, src=10.20.5.112:54282, dst=10.10.1.8:1433, zone="dev-net"→"prod-db", rule_id="DB-ACC-RESTRICT", user="admin-jli", via="WebUI-v3.2.1"这条记录一眼就能看出：开发网段某IP试图连SQL Server，被策略拦截，管理员jli刚在网页后台更新过规则。没有它，你可能还在怀疑是不是数据库自己崩了。
日志不是万能，但没它真不行
某次客户现场排查慢查询，起初以为是数据库性能问题，后来翻隔离设备日志才发现：近一周每天凌晨都有来自运维跳板机的大批量TCP重传，源头是备份脚本误配了目标地址，持续冲击数据库区边界。策略本身没拦错，但日志暴露了配置疏漏——这种问题，光看流量图根本发现不了。