折腾WAF时，我发现最麻烦的往往不是安装，而是配置。很多人在第一次接触“等保2.0”时，第一反应是喊来安全厂商报个价，然后被一堆“安全审计”“日志留存”“集中管控”的术语吓住。
但如果你自己手上有几个网站或API服务，想先了解一下到底要做什么、云原生WAF（Web应用防火墙）能不能帮上忙，这篇文章就是为你写的。
我不会上来就贴法规条款原文，而是用一个真实场景：你负责一个日活5万的电商平台，最近公司要过等保2.0二级，安全审计是必须项。审计组要求：Web访问日志、WAF攻击日志、用户操作日志全部记录，且至少保留180天，并支持事后回溯分析。
如果靠人工去配置服务器syslog、购买独立日志服务器、做备份轮转，成本高还易出错。而使用云原生WAF（比如阿里云WAF、腾讯云EdgeOne或第三方SaaS WAF），它可以原生提供安全审计日志生成、加密传输和长期存储，甚至自带合规报表模板。
下面我一步步讲清楚：等保2.0的审计要求到底是什么？云原生WAF怎么帮你满足？集中合规配置怎么做才不会踩坑？
等保2.0中的安全审计到底审什么
等保2.0（即《网络安全等级保护基本要求》GB/T 22239-2019）把安全审计归在安全计算环境和安全管理中心两个层面。
审计内容三要素
- 覆盖主体：对所有用户（包括管理员、普通用户、匿名用户）的访问行为、操作行为进行记录。
- 覆盖对象：对Web应用、数据库、中间件、服务器操作系统产生的安全事件、异常流量、配置变更进行审计。
- 记录字段：必须包含时间、主体、客体、操作类型、结果、源IP、目的IP等关键要素。
简单说，就是“谁在什么时间、从哪里、对哪个资源做了什么操作，成功了还是失败了”。WAF产生的攻击日志、拦截日志、绕过日志正是审计的重要组成部分。
日志留存要求
法规要求安全审计日志保存时间不少于180天。这里的“保存”不只是存下来，还要满足：
- 防篡改（日志文件不能随便改）
- 可查询（支持按时间、IP、事件类型快速检索）
- 可导出（方便审计人员带走或打印）
很多团队以为在服务器上开个access.log就行，但实际上合规检查时会看日志是否集中管理、是否有备份、是否有权限控制。分散在每台ECS上的日志很难通过检查。
相关阅读：此处可内链到“WAF常见问题”专题。
为什么云原生WAF是合规的“捷径”
云原生WAF与传统的硬件WAF或自建Nginx日志方案最大的区别在于：日志从产生到存储到分析，全部在云平台内部闭环，不需要你单独搭建ELK或Splunk。
天生满足“集中审计”
等保2.0要求安全审计功能必须集中管理。云原生WAF的控制台天然就是一个安全管理中心，所有域名的访问日志、规则命中日志、CC攻击日志在同一个界面展示。不需要你跑脚本收集多个服务器日志。
自动支持日志加密与防篡改
云原生WAF的日志在传输过程中使用HTTPS/TLS加密，存储时通常会做哈希校验（或写不可变存储），保证日志生成后无法被篡改。这一点在合规检查时很容易通过，因为你可以直接拉出日志的MD5或数字签名。
日志保留周期可配置
大部分云WAF支持自定义日志保存时长，默认可能只有30天，但你可以打开“合规模式”或购买日志扩展包，直接拉到180天甚至365天。无需手动做logrotate。
云原生WAF安全审计日志的集中合规配置步骤
下面的操作以“某云WAF”为例，但其实主流平台的思路类似，差别只在菜单名称上。你需要做的是开启安全审计日志功能 + 配置日志转存到对象存储 + 设置访问权限。
第一步：启用WAF安全审计日志
在WAF实例管理页找到日志服务或安全审计模块，打开“记录所有Web请求”开关。
注意：这里要区分“访问日志”和“攻击日志”。等保2.0要求记录所有用户行为，所以不能只记录被拦截的请求。你需要把正常请求也记录，否则审计范围不完整。当然，全量记录会大幅增加日志量，但180天后可以压缩归档。
第二步：设置日志保留周期为180天
在日志存储配置中，将保留周期从默认的15天或30天改为180天。如果平台提示需要额外付费，请评估成本——通常1GB/天的日志量，180天大约180GB，按对象存储价格算大约几十元，比自建ES集群便宜得多。
第三步：配置日志实时转存到对象存储
绝大多数云WAF支持将日志实时同步到对象存储OSS/S3中，这是实现集中保管和合规备份的关键。
- 创建一个专用于日志存储的Bucket，设置禁止公开访问，并开启服务端加密。
- 在WAF日志配置中，填入Bucket名称和访问密钥（建议使用RAM角色授权，不要用主账号AK）。
- 选择日志格式为“JSON格式”，方便后续查询。
这样做的好处是：日志从产生到写入OSS，不经过任何中间服务器，WAF直接推送，减少了日志丢失风险。
第四步：设置日志查询和导出权限
等保2.0要求只有授权人员才能查看审计日志。在对象存储的访问策略中：
- 创建一个只读权限的子账号，仅允许对该Bucket进行GetObject、ListBucket操作。
- 在WAF控制台关闭“控制台直接查看原始日志”功能（如果有），避免非授权人员通过Web界面看到敏感数据（如用户密码参数——虽然WAF默认脱敏，但审计日志里可能包含URL参数）。
- 开启操作日志（即谁在什么时间查询/导出了审计日志），形成审计链条。
第五步：验证合规性
完成配置后，你需要模拟一次审计检查：
- 尝试删除一个过期的日志文件，看是否有权限阻止。
- 尝试修改一个已生成的日志文件（通过API修改或直接改内容），看WAF是否有防护机制（通常对象存储不可变版本控制可以阻止覆盖）。
- 导出一段时间的日志，确认字段完整性（时间、IP、UA、URL、状态码、规则ID）。
如果以上验证通过，基本就能满足等保2.0安全审计日志留存要求。但注意，等保2.0还有对审计过程本身的审计（如谁修改了审计策略），这部分云WAF通常也自动记录在平台操作审计里，别忘了导出一份。
进阶阅读：此处可内链到“WAF性能优化”指南。
常见的三大踩坑点
只记录攻击日志，不记录正常请求
很多人觉得“我只想查攻击，正常请求没什么用”。但等保2.0要求“覆盖所有用户行为”，如果只记攻击日志，那么一个正常用户盗用他人账号的操作也无法追溯。所以一定要开启全量日志（可以设置采样率，但合规严格场景下建议全量）。
日志存储与日志查询耦合
有些团队用WAF控制台的“日志查询”功能直接当长期存储用。这会导致两个问题：第一，控制台通常最多保存7-30天数据；第二，等保检查时要求导出原始日志，控制台导出的格式可能不全。正确做法是：WAF控制台只用作实时查看诊断，长期保存和合规导出必须依赖对象存储。
忽略日志的时区一致性
WAF默认使用UTC时间，但你公司合规团队可能要求记录北京时间。如果日志中时间戳没有标注时区，审计时换算会很麻烦。建议在日志转存配置中统一设置为Asia/Shanghai，或者在日志字段中额外添加一个本地时间字段。
延伸阅读：此处可内链到“WAF配置案例”相关文章。
想继续深入：此处可内链到“WAF优化清单”文章。
回到开头那个场景：电商平台如何通过检查
容易忽略的细节
假设你按上述步骤配置了云原生WAF：
- 所有HTTP请求被WAF记录，JSON格式实时投递到OSS-合规存储桶。
- 存储桶开启版本控制（不可覆盖），保留180天+自动过期删除。
- 只有安全负责人有只读权限，所有查询行为被平台操作审计记录。
现场检查时，审计人员打开你提供的查询页面（可能是你基于OSS日志用Athena做的简单查询），输入一段SQL，展示出最近180天任意一天的日志，再随机抽查几条日志的完整性，全部通过。
整个过程不需要你搭建ELK，不需要你维护日志服务器，也不需要你自己写logrotate脚本。这就是云原生WAF在等保2.0合规场景下的核心价值：用产品能力替代人工运维，用平台合规背书替代自己写审计代码。
当然，本文只涉及安全审计日志这一个控制点。等保2.0还覆盖访问控制、入侵防范、数据备份恢复等若干要求。但如果你能把日志留存这个最基础也最容易出问题的点做扎实，剩下的工作会顺畅很多。后续只要定期检查关键指标，WAF就不会变成维护负担。
延伸阅读