为什么你的系统必须记录日志？
公司刚上线的新版客户管理系统，运行一周后突然出现几笔异常订单。技术团队排查时发现，操作日志只保留了48小时，关键操作无法追溯。这类情况在中小型企业中并不少见，表面上省了存储开销，实则埋下合规风险。
根据《网络安全法》和《数据安全法》的要求，任何提供网络服务的单位都必须留存操作日志，并保证日志的完整性、真实性和可追溯性。这不是“建议”，而是法律层面的强制规定。
常见合规标准中的日志要求
不同行业和标准对日志的记录内容、保存周期、访问控制都有明确规范。例如：
- 等保2.0三级系统要求日志至少保存180天
- GDPR要求记录数据访问和修改行为，用于响应用户权利请求
- 金融行业的《网上银行系统信息安全通用规范》要求交易日志保存5年以上
这些要求不是纸面条文。某电商平台曾因未能提供完整审计日志，在用户投诉数据泄露事件中被监管部门重罚，根源就是日志策略配置不当。
日志该记什么？怎么记？
有效的审计日志不是把所有系统输出都扔进文件。它需要结构化设计，至少包含以下字段：
{
"timestamp": "2024-03-15T10:23:45+08:00",
"user_id": "u10086",
"action": "login_fail",
"ip": "192.168.1.100",
"device": "Mobile/iOS",
"details": "Invalid password"
}这种格式的日志便于后续分析和告警。比如当某个IP在短时间内触发多次登录失败，安全系统就能及时拦截，避免暴力破解。
日志存储与访问控制
日志本身也是敏感数据。不能随便放在应用服务器的/var/log目录下，更不能开放给所有运维人员随意查看。正确的做法是：
通过Syslog或ELK架构集中收集日志，原始日志仅允许安全管理员访问。普通运维查询需通过审计平台，所有查询行为再次记录，形成“日志的日志”。
有家公司曾发生内部泄密事件，调查发现运维人员用脚本批量导出用户操作日志转卖。问题就在于缺乏访问审计机制，权限过大且无监控。
定期审计才是闭环
光有日志不查，等于没记。每月执行一次日志抽查应成为固定流程。重点检查：
- 特权账户的操作记录
- 非工作时间的系统变更
- 失败的登录尝试是否集中在某些账号
发现问题及时调整策略。比如发现某接口频繁被爬取，就可以结合日志加限流规则，既保障服务稳定，也满足合规审查要求。