结论先行：日志平台的采集范围如果只覆盖服务器、网络与安全设备，会留下一个很大的盲区：门禁、打卡、邮件、堡垒机这几类记录，恰恰是内部风险最有价值的证据。要不要收进来，判断标准不是「能不能采」，而是三个更实际的问题——收进来能回答哪个具体问题、谁有权限看、以及留存多久。答得清楚就收，答不清楚就别收，因为没有使用场景的数据只会增加成本与合规风险。

本文只谈非 IT 类日志（门禁、考勤、邮件、运维通道）该不该纳入日志平台、纳入前要想清什么，不谈日志采集的技术方式与字段标准化怎么做，也不谈日志平台上线前的合规项怎么定。

先看盲区有多大

行业公开资料里有一组常被引用的判断：多数数据泄露与内部威胁有关，相当比例的内部风险由员工或第三方的违规操作引发。这两个数字的具体取值不同来源有差异，但方向是一致的——真正的风险往往不在边界上，而在持有合法权限的人身上。

问题在于，判断「一个持有合法权限的人做了不该做的事」，光靠服务器日志是不够的。

举一个具体的场景。某台核心服务器在凌晨两点被登录，日志平台能看到登录记录、源 IP、执行了哪些命令。但它看不到另外两件事：那个时间点，这个账号的主人是不是真的在公司；以及这次登录用的凭据，是不是从这个人的办公电脑发起的。前一个问题的答案在门禁与考勤记录里，后一个问题的答案在堡垒机与终端日志里。

所以「服务器日志说了发生了什么」，「非 IT 记录说的是这个人当时在哪、用什么进来的」。两者合起来，才构成一个可用的判断。

四类非 IT 记录，各自能回答什么

数据源能回答的问题典型使用场景
门禁记录某人某时是否在某个物理区域核对「非工作时段远程登录」与「人在现场」是否矛盾
考勤打卡出勤与在岗时间的基线识别长期异常的到岗规律，与账号活动时间对照
邮件与外部通信敏感内容是否外发、发给了谁离职期与项目交接期的资料外流排查
堡垒机与运维通道谁在什么时候进了哪台设备、做了什么运维操作的追溯与审计留痕

这张表里，前三行属于「非 IT 数据」，第四行严格说属于 IT 但常被漏采——堡垒机的会话记录在很多企业里只留在堡垒机本地，没有进日志平台，结果审计时要一台台去导。

四类数据的共同特征是：单独看都看不出问题，串起来才有意义。这也是它们最容易被放弃采集的原因——单看一个门禁记录，确实没什么用。

该不该收，先答三个问题

不建议「能采就采」。非 IT 数据跟前三类不同，它涉及员工个人信息，采进来之后的管理责任会明显增加。

问题一，能回答哪个具体问题。这一条必须能用一句话说完。比如「核对非工作时段运维登录与人员在岗情况是否一致」，这是一个具体问题，有明确的比对动作。反过来，「为了更全面」不是答案。

问题二，谁能看。非 IT 数据的敏感程度高于设备日志，可见范围应该单独设计。可行的做法是按场景授权：安全团队可以看门禁与运维通道的关联结果，但不看原始门禁明细；人力资源相关的考勤数据只进统计口径，不进明细。这里的核心是「按用途给视图」，而不是「按人给全量」。

问题三，留多久。设备日志的留存期通常由合规要求决定，六个月是常见口径。非 IT 数据不必照搬这个周期——门禁明细留一年可能既无必要也增加风险，而堡垒机会话记录反而可能需要更长。可行的做法是按数据源分别定留存期，并在方案文档里写清依据。

三个问题里有任意一个答不出来，这一类数据就先不收。少收一类不会让平台失效，多收了没有用途的数据，反而会变成一个说不清的风险点。

收进来之后，用在哪三件事上

假设已经决定收，那么用途要提前定，否则这些数据会一直躺在库里。

其一，异常登录的时间与位置比对。把运维通道的登录时间与门禁、考勤记录对上，能筛出一批值得看的记录：非工作时段登录、登录地点与人员在岗地点不一致、长期不联网的设备突然上线。这类记录单看都不构成事件，攒起来才有形状。

其二，离职与交接期的资料外流排查。这一段的特征是「动作都合法，合起来可疑」：短时间内大量下载、把项目资料发到个人邮箱、频繁访问与自己岗位无关的目录。邮件与文档访问记录在这里是关键，因为服务器日志只能看到「访问了」，看不到「发给了谁」。

其三，审计与检查时的自证。这两年被检查得越来越多的，是「谁能证明这条规则是谁改的」。设备配置变更记录、堡垒机会话、审批工单三样齐全，才能完成一次自证。三样里缺一样，就只能靠人回忆。

三件事的共同点：都需要跨数据源关联。这也是为什么它们在过去难以实现——数据分散在不同系统里，人工比对一次要几个小时。日志平台的价值就在这里：不是多存了一类日志，而是把一个需要几小时的比对，变成一条可以保存下来的查询。

几个容易踩的坑

时区不统一。门禁系统、考勤系统、服务器的时间源常常不一致，有的差八小时，有的差几分钟。做关联分析时，这种偏差会直接导致结论错误。可行的做法是接入时就统一到一个时间基准，并在字段里保留原始时间。

人员标识对不上。门禁用的是卡号、考勤用工号、服务器用账号名、邮件用邮箱前缀。四套标识之间如果没有一张映射表，关联就做不成。这张表通常由人力资源系统提供，需要定期同步——因为人会入职、调岗、离职。

把「收进来」当成「管起来」。数据进平台之后，权限、审计、留存三项都要有对应机制。否则平台自己就变成了一个暴露面——这也是为什么日志平台自身的操作留痕要单独设计。

深圳市奇摩计算机有限公司在做日志分析类项目时，采集范围一般按「先覆盖能回答问题的数据源、再按场景扩展」的顺序推进，而不是一次性把能接的都接进来。这样做的原因很实际：范围一扩，权限与留存的讨论就会跟着扩，项目的沟通成本会翻倍。

落地清单

  • 先列出需要用日志回答的问题，再反推需要的非 IT 数据源，不要反过来。
  • 每一类非 IT 数据都写明「回答哪个问题」一句话，写不出来的先不收。
  • 可见范围按场景授权，给视图不给全量；人力资源相关数据只进统计口径。
  • 留存期按数据源分别定，不照搬设备日志的合规周期。
  • 接入时统一时间基准并保留原始时间字段。
  • 预先建好卡号、工号、账号、邮箱四套标识的映射表，并纳入定期同步。

若您正在规划日志平台的采集范围或做内部风险排查方案，欢迎 预约咨询。