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 启动失败且无明确报错。
