安全审计要求总览：等保2.0中安全审计的五个控制点（A1-A5）简述

做等保2.0项目这么多年，我最大的感触就是——安全审计这块经常被当成"凑数项"。很多人觉得只要把日志开了，随便存六个月就完事了。你想想看，如果审计日志本身有问题，那后续所有溯源、取证全都是白搭。等保2.0里专门把安全审计拆成了五个控制点（A1~A5），每个控制点对应一个关键能力。搞懂了这五点，你的审计体系才算真正立得住。

A1 – 安全审计事件（记什么）

A1是底座。它要求系统必须能记录哪些行为。说白了，就是得知道哪些操作需要进日志。

• 用户登录/登出：包括成功和失败的尝试。我曾经遇到一个客户，只记了成功登录，结果被暴力破解的日志全丢了，根本查不到攻击源。
• 特权操作：比如root执行命令、修改系统配置、添加账号。这些都是高危行为，一个都不能漏。
• 资源访问：谁读了什么文件、谁调了什么API。特别是数据库操作，必须记下来。
• 异常事件：网络中断、磁盘写满、服务崩溃。这类事件容易被忽略，但往往是故障的第一线索。

A2 – 安全审计记录（怎么记）

A2解决的是日志格式、存储和保留的问题。等保2.0的要求其实很具体：

• 记录内容：至少包含事件类型、发生时间、用户标识、源IP、操作描述、结果。缺一项就算不合规。
• 存储要求：日志必须集中存放，不能散落在各个终端上。我记得有家单位，每台服务器本地写日志，结果黑客把本地日志一删，什么都没留下。
• 保留期限：三级系统要求180天以上，二级系统6个月。时间不够，整改通不过。
• 时间同步：所有日志必须使用同一时钟源（比如NTP）。否则跨系统溯源时时间对不上，你会很头疼。

控制点	核心要求	常见翻车点
A1	覆盖用户登录、特权操作、资源访问、异常事件	只记成功不记失败；遗漏数据库操作
A2	日志内容完整，集中存储，保留≥180天，时间同步	本地存储不集中；时间不同步；日志格式缺字段
A3	能对日志进行分析、告警、关联	只存不分析；告警阈值不合理导致大量误报
A4	日志防篡改、防删除、访问控制	用root删日志；未配置日志轮转；无签名校验
A5	实时告警、自动阻断、追溯能力	告警延迟高；阻断误伤正常业务；无事后回放

A3 – 安全审计分析（怎么看）

A3是审计的灵魂。日志只存不看，等于没有。等保2.0要求系统能够对审计记录进行分析，发现异常行为。

• 规则分析：比如"同一IP在1分钟内登录失败5次"触发告警。这算最基础的。
• 关联分析：把来自不同系统的日志串起来。举个例子，用户从VPN登录，然后操作了数据库，这些节点之间的跳转必须能追踪。
• 用户行为画像：高级点儿的做法是给每个账号建立日常行为基线，一旦偏离就告警。我在做金融行业项目时，这个功能抓出过内部数据泄露。

A4 – 安全审计保护（怎么护）

A4要求审计记录本身必须是安全的。你想想看，如果黑客攻进来后把日志全改了或删了，那你还怎么查？

• 防篡改：日志写入后不能随意修改。常见做法是写保护（比如挂载为只读文件系统），或者使用区块链式哈希链校验。
• 防删除：即使管理员也不能轻易删日志。日志归档后应该设置保留策略，只能自动轮转，不能手动删除。
• 访问控制：审计日志的查看权限要独立分离。不能让业务管理员同时能删日志——权限拆分是等保2.0的底线。
• 日志传输加密：如果日志通过网络发送到集中平台，必须用TLS/SSL加密。否则中间人截获日志，等于裸奔。

我记得有个案例：某单位用syslog传日志，但没加密，结果攻击者在内网抓包，把管理员的操作日志看得一清二楚。所以A4不是小题大做。

A5 – 安全审计响应（怎么应）

A5是审计链条的最后一环——发现问题后怎么办。等保2.0要求：

• 实时告警：高危事件必须在分钟级内通知到安全管理员。邮件、短信、弹窗都行，但不能延迟。
• 自动阻断：对明确恶意的行为（如暴力破解、SQL注入）可以直接封锁IP或断开会话。但要注意别误伤。
• 追溯回放：事后能根据时间轴完整还原攻击路径。这一步取决于A2记录的质量和A3分析的关联能力。

五个控制点是一个整体——A1打地基，A2建仓库，A3装大脑，A4上锁，A5装报警器。缺一个，安全审计就站不住。

总结一下：A1决定你能看到什么，A2决定你能不能找到，A3决定你能不能看懂，A4决定这些证据还能不能信，A5决定你能不能及时止损。我的经验是——做审计规划时，先画一张类似的图，把每个控制点对应的现有工具、缺失项标出来，整改路径就清晰了。