特权账号会话审计实战：堡垒机操作留痕配置

作者

特权账号审计是等保与内控的硬性要求，但在很多中小规模环境里，root 操作完全没有留痕：谁改了配置、谁删了数据、谁在生产库执行了 DROP，事后无从追溯。本文给出不依赖重型商业堡垒机的落地方案：用 sudo I/O 日志 + tlog 会话录制 + auditd 特权命令审计三层组合，实现特权账号操作的全量留痕与回放。

适用场景

  • 运维团队多人共用特权账号，需要区分“是谁干的”
  • 需要满足等保二级/三级对操作审计与日志留存的要求
  • 不便采购商业堡垒机，希望用开源组件自建审计能力

前置条件

  • CentOS/RHEL 8+ 或 Ubuntu 20.04+，systemd 环境
  • 已配置集中日志服务器（rsyslog 或 journald 转发）
  • 具备 sudo 权限，且操作员使用个人账号登录后再提权

原理说明

完整的特权审计需要回答四个问题：谁、在什么时间、做了什么、结果如何。单靠 syslog 只能记录“执行了 sudo 命令”，看不到交互式 Shell 里的具体输入。

sudo I/O 日志（log_output）记录命令的输入输出；tlog 通过绑定到用户会话的伪终端，把整个交互过程录制成可回放的会话日志；auditd 则在内核层捕获 execve 系统调用，作为兜底，防止绕过前两层。三层各司其职：auditd 保证“必有”（内核层不可绕过），sudo 日志保证“可查”（结构化文本），tlog 保证“可回放”（完整人机交互上下文）。

很多团队只启用 auditd，结果日志里只有一条 execve /usr/bin/sudo，看不到后续 Shell 里的具体命令；只启用 sudo 日志，又会被“先 su 到 root 再操作”绕过。tlog 弥补了交互过程，但它是用户态程序，理论上可被 root 关闭；auditd 在内核层最难绕过，可读性却最差。三者叠加，才能同时满足完整性、可读性、可回放性。

操作步骤

第一步：启用 sudo I/O 日志

# /etc/sudoers.d/audit  （用 visudo -f 编辑，切勿直接改 /etc/sudoers）
Defaults log_output
Defaults log_input, !log_output
Defaults iolog_dir=/var/log/sudo-io/%{user}
Defaults iolog_file=%{seq}

用 sudoreplay 回放：

sudo sudoreplay -l
sudo sudoreplay <ID>

第二步：部署 tlog 会话录制

# 安装
sudo dnf install -y tlog      # RHEL/CentOS
sudo apt install -y tlog      # Ubuntu
# 将 tlog 绑定到所有交互式会话
sudo tee /etc/profile.d/tlog.sh <<'EOF'
if [ -n "$TLOG_REC" ] && [ "$USER" != "root" ]; then
  exec /usr/bin/tlog-rec-session
fi
EOF

通过 sssd 作为会话 provider 时，tlog 会自动接管录屏，录制文件默认落在 /var/log/tlog/。

第三步：auditd 内核层兜底

# 审计所有特权命令执行
-a always,exit -F arch=b64 -S execve -F euid=0 -k priv_cmd
# 审计 sudoers 与 sshd 关键文件变更
-w /etc/sudoers -p wa -k sudoers_change
-w /etc/ssh/sshd_config -p wa -k sshd_change
# 重载规则
sudo augenrules --load
sudo systemctl restart auditd

查询：ausearch -k priv_cmd | aureport -x。

第四步：日志集中外发与防篡改

# /etc/rsyslog.d/50-audit.conf  实时转发到集中日志服务器
*.* @@logserver.example.com:514
# auditd 事件通过 audisp-remote 直推远端
sudo tee -a /etc/audit/auditd.conf <<'EOF'
log_format = RAW
EOF

更严格的做法是启用 audisp-remote 把 auditd 事件直接推送到远端，避免本地文件被篡改；同时把 tlog 录制目录通过 rsync 或对象存储做只增不改的归档。

审计日志的核心价值在于可信。如果运维人员在操作后能顺手删除或修改本地日志，审计就形同虚设。因此集中化不只是“方便查询”，更是“防止抵赖”的技术手段：日志一旦落到自己没有写权限的服务器，事后任何本地清理都无法改变既成事实。配合只增不改的归档策略，才能形成完整的证据链。

第五步：特权账号收敛

# 禁止 root 直接 SSH 登录
sed -i 's/^#*PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
# 操作员统一用个人账号，再按需提权
# /etc/sudoers.d/ops
ops ALL=(ALL) /usr/bin/systemctl restart nginx, /usr/bin/journalctl
Defaults env_reset, timestamp_timeout=5

配置验证

  • 用普通账号执行 sudo whoami，检查 /var/log/sudo-io/ 是否生成会话目录
  • sudoreplay -l 能列出纪录，回放可见完整命令
  • ausearch -k priv_cmd -ts recent 能查到刚执行的提权命令
  • 确认日志已转发到集中日志服务器，本地被删也不影响取证

与 4A 模型的对应关系

成熟的特权访问管理（PAM）体系通常包含 4A：认证（Authentication）、授权（Authorization）、账号（Account）、审计（Audit）。本文方案聚焦其中的“审计”一环，需与账号收敛、命令白名单（授权）配合才能形成闭环：账号统一到个人、权限收敛到最小、操作全程留痕，三者缺一不可。只有审计而没有账号收敛，日志里仍会出现“root 操作”这类无法归责的记录；同样，只做录屏而不做命令白名单，日志会变成海量噪声，真正的敏感操作反而被淹没在正常运维记录里。

从“事后追溯”到“事中告警”

# 巡检提权敏感操作，命中即告警到 SIEM / 企业微信
ausearch -k priv_cmd -ts today | grep -E 'useradd|usermod|crontab|iptables|firewall|passwd'
# 巡检审计服务状态，停止即告警
systemctl is-active auditd tlog-rec-session

把上述命令封装为定时巡检脚本，命中结果推送企业微信或邮件，即可在事后追溯之外补上事中告警能力，把发现窗口从“天”缩短到“分钟”。

常见问题

FAQ 1：录屏日志体积增长太快怎么办？

tlog 与 sudo-io 日志会随会话时长线性增长。建议配置 logrotate 按天轮转 + 压缩，并设置保留周期（如 180 天，满足合规最低留存）；对超长会话可设置最大录制时长与磁盘配额。回放用的 tlog-play 不需把全部日志读入内存，冷数据可归档到对象存储。

FAQ 2：运维人员能否绕过审计？

理论上单机审计总能被 root 关闭，因此关键是实时外发 + 集中存储：把 auditd 与 tlog 日志实时转发到运维人员无权限的日志服务器，本地日志即使被清也不影响取证。同时对 systemctl stop auditd、rm /var/log/tlog/* 这类操作本身设置告警。

FAQ 3：审计日志留存多久才合规？

《网络安全法》与等保 2.0 要求网络日志留存不少于 6 个月；对三级及以上系统或涉及敏感数据的场景，建议延长至 12 个月甚至更久。留存不仅是存储问题，更要保证可检索、可回放、防篡改，因此集中存储 + 哈希校验 + 定期归档是必要动作。

总结

特权账号审计的目标不是“防住所有操作”，而是让每一次提权都可追溯到人、可回放内容、可验证真伪。sudo I/O 日志 + tlog 录制 + auditd 内核兜底的三层组合，不依赖商业堡垒机即可满足大多数合规要求；再叠加日志实时转发，就能形成一套成本可控、可落地的运维审计体系。