审计“开着”的三种含义
审计子系统最常见的假象是“装了 auditd 就等于在审计”。真正的验收要看三件事：服务在运行、规则条数不为零、日志文件确实在增长。服务停了意味着事件不再产生；规则为空意味着只记了默认的少量事件；日志不增长则可能是磁盘满、写入失败或日志被重定向到了别处。这三项缺任何一条，审计结论都应当判为不可用，而不是“部分合规”。
基本信息
| 加固项 | 审计子系统运行状态核查 |
|---|---|
| 适用平台 | Linux（auditd、内核审计子系统） |
| 权限要求 | root |
| 达标判据 | 服务 active、规则条数非零、日志持续增长 |
| 相关命令 | systemctl、auditctl -s、auditctl -l |
典型使用场景
- 等保测评前自检审计是否真的在运行
- 安全事件后发现审计缺失，追溯能力归零
- 巡检确认规则没有被误删或被重载清空
- 磁盘写满导致审计失效后的恢复确认
- 容器化环境明确哪些主机需要宿主机层核查
三项验收命令
三项验收命令
systemctl is-active auditd # 第一项：服务状态，期望 active
systemctl is-enabled auditd # 顺带确认开机自启
sudo auditctl -s | head -6 # 第二项：内核审计状态，看 enabled 与 pid
auditctl -l 2>/dev/null | wc -l # 第三项之一：生效规则条数，期望大于 0
ls -l /var/log/audit/ && df -h /var/log # 日志目录与磁盘余量
stat -c '%s %y' /var/log/audit/audit.log # 隔 30 秒再执行一次，对比文件大小是否变化常见异常与处置
常见异常与处置
systemctl restart auditd # 服务未运行（注意：部分发行版用 service 命令更稳）
auditctl -s | grep -E 'enabled|pid|lost' # enabled=1 但 pid=0 说明守护没跑
journalctl -u auditd --since today | tail -20 # 看启动失败原因
# 规则被清空或未落盘：重建 rules.d 文件后重载
augenrules --check && augenrules --load三项判定与异常含义
| 检查项 | 正常表现 | 异常含义 |
|---|---|---|
| 服务状态 | active (running) 且已设开机自启 | 停止或不自启，事件不再产生 |
| auditctl -s 的 enabled | 1（已启用） | 0 表示审计关闭 |
| auditctl -s 的 pid | 非 0 | 为 0 说明守护进程没在跑 |
| auditctl -l 条数 | 大于 0 且与预期规则集一致 | 为 0 说明只有默认规则或规则被清空 |
| audit.log 大小与时间 | 持续增长 | 不增长说明写入失败或磁盘满 |
巡检记录建议固定三要素：服务状态、规则条数、最新日志时间，报告里三个值都要出现，而不是写“审计已开启”这样的定性描述。数值化的记录还能横向比较不同主机，快速发现哪台机器规则少了一半。
容器环境里 audit 子系统通常不可用或受限制，属正常现象，报告里应注明“审计在宿主机层核查”，而不是直接判该容器不达标。反过来，宿主机审计如果缺失，容器里的所有动作都将失去可追溯性，因此宿主机的这一项更关键。