auditd是Linux系统级操作日志唯一可靠方案，需将规则写入/etc/audit/rules.d/并用augenrules加载，显式指定arch，聚焦敏感路径，通过audispd分流日志，用ausearch/aureport结构化查询，容器环境须监控宿主机rootfs路径并启用containerid字段。

Linux 系统级操作日志：auditd 是唯一靠谱的选择

想靠 history 或简单 shell 脚本记录谁在服务器上干了什么，基本等于没记。真正能落地的审计必须依赖内核级机制——auditd。它不依赖用户登录 shell，能捕获 root 权限下的 exec、文件访问、系统调用等行为，且日志独立存储、防篡改。

常见错误是只开 auditctl -e 1 就以为万事大吉，结果发现日志里全是 syscall 编号，根本看不懂；或者把规则写在命令行里，重启服务后全丢。

• 必须把规则写进 /etc/audit/rules.d/ 下的 .rules 文件（如 audit.rules），再运行 augenrules --load
• 关键规则要显式指定 -F arch=b64（x86_64）或 b32（兼容 32 位），否则 64 位系统可能漏掉部分 execve 事件
• 避免无差别监控 -w /etc -p wa，会引发海量日志和性能抖动；优先聚焦敏感路径：/etc/shadow、/etc/passwd、/usr/bin/sudo、/var/log/audit/

多实例隔离：每个服务用独立 auditd 配置不现实

auditd 本身不支持“多实例”——它是系统级守护进程，全局唯一。所谓“隔离”，实际是指按业务/租户维度做日志分流与权限控制，不是起多个 auditd。

典型踩坑：试图用 systemd --scope 启动第二个 auditd，结果被 kernel 拒绝，报错 Operation not permitted；或误以为 auditctl -r 可以重载规则而不影响已有审计流，其实会清空所有规则缓存。

• 真隔离靠日志路由：用 audispd 插件（如 audisp-remote 或自定义 audisp-python）把匹配特定字段（如 uid、comm）的事件发往不同 Kafka Topic 或文件
• 若需按用户分日志，优先在规则里加 -F uid!=0 或 -F auid>=1000，再用 ausearch --input-logs --auid 1001 单独查
• 不要给普通用户开放 /var/log/audit/audit.log 读权限，应通过 ausearch/aureport 提供受限查询接口

日志留存与检索：raw log 不可直接分析

/var/log/audit/audit.log 是二进制兼容文本格式，直接 grep 会漏字段、乱序、解码失败。审计日志的价值不在存储，而在可追溯的结构化查询。

常见错误是定时 logrotate 后就不管了，半年后发现磁盘爆满却查不出谁删了关键文件；或用 journalctl -u auditd 查审计事件，其实那只是 auditd 自身状态，不是审计事件本身。

• 必须配置 max_log_file 和 num_logs（在 /etc/audit/auditd.conf 中），例如 max_log_file = 50（MB）、num_logs = 10，防止日志无限增长
• 定期用 aureport --start today --key sudo_exec --format csv > /tmp/sudo-today.csv 导出结构化数据，比原始日志快 10 倍以上
• 敏感操作建议额外触发告警：用 audispd 的 audisp-remote 插件将含 key="privileged" 的事件实时推送到 SIEM

容器环境怎么办：auditd 规则对容器内进程默认无效

宿主机启了 auditd，但容器里 rm -rf /etc 在日志里找不到对应记录？因为默认情况下，容器进程的 pid、uid、comm 虽可见，但文件路径是容器视角（如 /etc/passwd），而 auditd 监控的是宿主机路径（如 /var/lib/docker/overlay2/xxx/merged/etc/passwd）。

别指望 Docker 官方插件或 sysdig 替代审计核心能力——它们无法替代内核级 syscall 捕获，且权限模型更松散。

• 必须用 -w /var/lib/docker/overlay2 -p wa -k docker_write 这类规则，监控容器 rootfs 所在目录，而非容器内路径
• 启用 containerid 字段：在 /etc/audit/rules.d/container.rules 中加 -a always,exit -F arch=b64 -S execve -F containerid!=0 -k container_exec，然后用 ausearch --containerid xxx 查询
• Podman 用户注意：--cgroup-manager=cgroupfs 时 containerid 可能为空，需改用 systemd cgroup 管理器并确保 auditd 加载 containerid 支持模块

最麻烦的从来不是开开关关，而是规则粒度和日志生命周期管理——一条没设 -F key 的监控规则，可能让每天日志量从 100MB 涨到 2GB；一次没清理的旧规则，会在升级后导致 auditd 启动失败且无明确报错。