日志平台和堡垒机，到底谁记什么

结论先行：已经有堡垒机、数据库审计、终端管控的单位，上日志平台时最常听到的质疑是「重复建设」。这个质疑不对，但也不是没有来由——三者确实都能查操作、都能出报表、都提合规。真正的分工依据是记录单位不同：堡垒机记的是「一次会话」，日志平台记的是「一个事件」。会话只能覆盖走它进去的操作，事件覆盖的是所有留下痕迹的地方。按绕过路径分三块，谁记什么就不用争了。

本文只谈日志平台与既有审计类设备之间的记录范围怎么划，不谈该采购哪一类设备，也不谈等保条款对审计的具体要求。

为什么会有「重复建设」的感觉

三个来源，每个都成立，所以这个感觉很难一句两句打消。

其一，都能查「谁做了什么」。堡垒机里有操作录像，日志平台里能检索到同一次登录的认证记录。看起来是同一件事记了两遍。

其二，都能出报表。两边都能导出「高危操作统计」「账号使用情况」，交上去的形态差不多。

其三，都挂在合规这个理由下面。采购时的立项说法接近，验收时看的材料也接近，于是容易被理解成两个同一功能的系统。

问题在于，这三个「都」都停留在功能名称层面。往下看一层，记录对象根本不是一回事。

两者的记录单位不同

这张表最关键的一行是「典型盲区」。堡垒机管的是「进门」，它记录的是通过门的人；但楼里还有不少窗户。日志平台管的是「屋里发生的事」，它不管人从哪进来。

三条绕过路径决定分工

判断某类操作该由谁记，不用争功能，只需问一句：这件事有没有可能不经过堡垒机。

其一，本地登录与带外管理。设备面板、控制台、带外管理口，这些路径通常不经过堡垒机。一旦有人从这条路进去改了什么，堡垒机上是空的，只有设备自身的日志里有记录。这一类必须落到日志平台。

其二，系统之间的直连。应用连数据库、服务调服务、批处理跑脚本，这些连接不走人操作的通道，堡垒机看不到。数据库侧的变更、账号提权、表结构改动，要靠数据库自身的日志与系统日志补上。

其三，系统内部的动作。计划任务、定时脚本、策略自动下发、配置中心推送——这些动作没有对应的「人」，但会改变系统状态。出问题时最容易被问住的正是这一类：「这个改动是谁做的」，答案是「没有人，是一个任务」。

三类路径都能被堡垒机全覆盖的情况几乎不存在。反过来也一样：堡垒机能回放操作过程，日志平台做不到这件事。所以问题不是「留一个删一个」，而是「哪一类痕迹由哪个系统负责，写清楚」。

已经有堡垒机，日志平台先接哪三类

1. 被管理设备的系统日志。补上堡垒机的盲区，尤其本地登录、特权命令、账号增删这几类。
2. 数据库与中间件的运行日志。覆盖应用直连路径，包括慢查询、连接异常、权限变更。
3. 业务与安全设备的告警日志。防火墙、入侵检测、终端防护这些设备的告警，需要和操作痕迹放在一起看，才能判断「这次改动是不是引来了异常流量」。

接入顺序建议按「盲区大小」排，而不是按设备重要性排。盲区最大的那类先接，能最快把「查不到」的情况消掉。

报表重复怎么处理

两边都能出的报表，不需要删掉一个，但要把「谁出给谁签」定下来。

• 操作过程类报表（谁在什么时间对哪台设备做了什么操作），以堡垒机为准，因为它有会话依据。
• 行为趋势类报表（某账号近三十天的访问规律、异常时段分布），以日志平台为准，因为它有跨系统的长周期数据。
• 合规交付类报表，两家数据都取，但只出一份，落款与签批走同一个出口。两份报表数字不一致，是审计现场最容易出问题的地方。

判断是否真的重复：四个问题

如果这四个问题里有三个答不上来，那这两套系统在你们单位确实是重复的——不是功能重复，是责任重复。

1. 本地登录能不能被现有设备完整记录？
2. 应用直连数据库的变更，现在从哪查？
3. 计划任务造成的状态改变，有没有留下执行者信息？
4. 同一个操作在两边看到的记录，能不能对上时间？

第四个问题经常被忽略。两套系统的时间源不同步，同一条操作在两边差几分钟，就足以让「谁先谁后」说不清。做法不复杂：统一时间源，并在两边的记录里都保留可对齐的标识。

边界与前提

三点说明。其一，本文讨论的是记录范围的分工方法，不构成对任何具体产品能力的判断，实际覆盖范围要以本项目 PoC 实测为准。其二，文中涉及的留存周期、报表频次为参考做法，具体应按所属行业监管要求与本单位制度确定。其三，日志平台与审计类设备之间的对接方式取决于双方版本与接口开放情况，落地前需要做一次接口验证。

深圳市奇摩计算机有限公司在交付日志类项目时，通常先把这张「谁记什么」的表和客户的信息部门一起填完，再决定接哪些日志源——先接后议，往往要重接一遍。

如果你正卡在「重复建设」这个质疑上，预约咨询，可以拿你现有的设备清单一起把这张表填出来。