等保合规中容器日志审计的常见误区与对策

不少团队在等保整改时都踩过同一个坑：宿主机加固一条条落实了，镜像签名、禁用特权也都做了，结果测评机构一问“操作日志拿来看看”，大家面面相觑——容器早就删了，日志也跟着没了。容器日志审计这块，扣分往往不是因为大家不重视安全，而是对“该留什么、留多久、放哪存”理解有偏差。

常见的几个误区

最典型的是把日志留在容器本地。容器的 stdout 日志、daemon 日志如果只存在本机，容器一删除就一起消失，测评时根本拿不出证据。这就像把账本放在临时板房里，房子一拆，账也没了。

第二个误区是只盯应用日志，漏了另外两类。等保的“安全审计”控制点要求审计记录覆盖到每个用户，容器标准也要求镜像仓库的访问日志保存并定期审查。也就是说，除了容器 stdout，daemon 的操作日志、registry 的推送拉取日志同样得留——谁在 daemon 上执行了什么操作、谁往仓库推过镜像，都得能对上号。

第三个误区更离谱：把“数据不留痕”理解反了。这个要求说的是敏感业务数据不能残留，绝不是把审计痕迹一起抹掉。有的团队清理环境时顺手把日志也清了，等于自己把监控录像删了，出了事想回放都没得看。

对策其实不复杂

先把三类日志集中外送到日志系统，别留在容器本地随生命周期消失。然后保证日志能定位到“人”：本地操作走 sudo 保留命令审计记录，远程管理 daemon 启用 TLS 双向认证，这样每条记录才知道是谁干的。留存周期上，《网络安全法》要求相关网络日志不少于六个月，等保测评也会核查日志的完整性和保存周期，这条没得商量。最后别忘了“定期审查”——日志存着从不翻看，跟没存区别不大。

还有个省力的做法：把日志外送这些配置直接写进部署模板和 CI/CD 流水线，让每次发布自动带上，而不是测评前突击补。等测评机构问起来，能直接拿出审计日志和配置记录，这比任何口头解释都有说服力。