Syslog 本身不能替代权限审计，但通过强化配置、结构化日志、基线告警及与 auditd/journald 协同可显著提升审计质量。
直接用 Syslog 记录异常操作本身不能替代权限审计，但能显著提升其质量——关键在于让日志具备可追溯性、完整性与上下文关联性。
聚焦 auth 和 authpriv 设施，捕获真实权限行为
默认的 auth.log（或 /var/log/secure）只记录 PAM 登录事件，容易遗漏 sudo、su、setuid 程序调用等关键动作。需主动强化配置：
- 在 rsyslog 中显式捕获 sudo 日志：添加规则 local2.* /var/log/sudo.log，并在 /etc/sudoers 中启用 Defaults logfile="/var/log/sudo.log"
- 确保 auditd 启用并协同工作：Syslog 不记录内核级系统调用（如 execve、openat），必须靠 auditd 捕获，再通过 audispd 插件将 audit 日志转发至 rsyslog 的 local0 设施
- 禁用匿名或模糊日志：避免出现 “user unknown” 或 “invalid user” 类泛化记录，应强制要求服务（如 SSH）记录完整用户名、源 IP、TTY 和时间戳
结构化日志格式 + 关键字段提取
原始 Syslog 行是半结构化文本，人工排查效率低。提升质量的第一步是统一字段表达：
- 启用 rsyslog 的 RSYSLOG_SyslogProtocol23Format 模式，使日志符合 RFC5424，自带 structured-data 字段（如 [origin ip="10.1.2.3"]）
- 对 auth.log 做预处理：用 awk 或 logrotate 配合 script 提取并重写关键字段，例如将 "Failed password for invalid user alice from 192.168.5.22" 标准化为 event=login_fail user=alice src_ip=192.168.5.22 reason=invalid_user
- 为每条日志打上唯一 trace_id（如用 UUID 或 session ID 关联多个事件），便于串联一次登录后的全部命令执行链
设置可验证的审计基线与偏差告警
单纯“有日志”不等于“能审计”，需定义什么是“正常”，才能识别“异常”：
- 建立用户行为基线：统计各账号每日平均登录次数、常用登录时段、高频执行命令（如运维账号常跑 ansible，开发账号极少用 sudo）
- 配置 rsyslog + imfile + omelasticsearch 实时写入 ELK，用 Kibana 建立 watch：当某用户在非工作时间触发 3 次 sudo su - root，或同一 IP 在 5 分钟内尝试 5 个不同账号登录，立即触发告警
- 保留至少 90 天的完整日志，并启用 logrotate 的 create 0600 root root 权限控制，防止日志被低权限进程篡改或覆盖
与 auditd 和 systemd-journald 形成三层证据链
Syslog 是审计证据链中的一环，不是全部。高质量内部权限审计依赖三类日志交叉验证：
- auditd 层：记录系统调用级动作（谁、何时、以什么权限、执行了哪个二进制文件），不可绕过，是事实源头
- systemd-journald 层：提供服务启停、unit 状态变更、环境变量快照，补全上下文（如某次 sudo 执行后 nginx 服务意外重启）
- rsyslog 层：整合前两层+应用日志（如数据库审计日志），做归一化、转发与长期存储，支撑查询与报告
三者时间戳需同步（chrony/NTP），且所有日志均启用 imjournal 或 auditd 插件接入 rsyslog，避免日志孤岛。
