结论先行：行为分析上线之后，很多告警指向的「人」根本不成立——同一个员工在邮件、工号、堡垒机、数据库、门禁里各有各的账号，同一个人被算成几个人；反过来，一个共用账号背后又站着好几个人。这一层不对齐，建基线、调阈值、算风险分都是在错的单位上做运算。可行的做法是先把四件事定下来：拿什么当人的主键、映射表存在哪、每条映射给多少置信度、原始账号值要不要留。本文只谈把账号对齐到人这一层数据工作，不谈建什么样的基线，也不谈发现异常之后怎么处置。
告警里那个「人」，其实不是一个实体
拿一条真实场景来说明。某个账号在周五晚上从一台陌生终端登录了三台服务器，触发了横向移动类的告警。分析的人去查这个账号是谁的，从账号命名规则看像是某位工程师；再对 HR 系统的在职名单，发现这个人两个月前已经转岗；再看门禁记录，当晚在楼里的却是另一位同事。三条线索指向三个答案，这条告警最后大概率会被判成「误报」关掉。
问题不在告警规则，在于这套数据里没有「人」这个实体，只有一堆账号。而行为分析的每一个结论——这个人是不是异常、他所在岗位的常态是什么、他属于哪个群体——都以「人」为单位。单位错了，结论只是看起来有道理。
三处对不上
其一，一人多号
同一名员工，邮箱是拼音、工号是数字、堡垒机是缩写、数据库是部门加序号、业务系统是手机号。这些账号之间在数据里没有任何字段能直接连起来，除非有人手工维护一张对照表。日积月累，这张表会变成全公司最容易被忽略也最要命的资产：它一旦过期，所有依赖它的分析都跟着偏。
其二，一号多人
高权限账号几个人共用，是很多环境里的既成事实。这类账号在日志里是一串稳定的操作记录，看起来像一个人，实际上是一组人。基于它的任何个体判断都不成立，因为「他」的日常工作时段跨越了三个班次，「他」的访问范围覆盖了三个部门的系统。这件事本身就是一个需要单独盘点的对象，不能混在个体分析里处理。
其三，账号与物理身份脱钩
门禁卡、工牌、手机号、姓名，这几类身份凭证各自存在于一套系统里，彼此不通信。有些异常只能靠把两类身份放在一起看才成立：一个人登录系统的时间与他的门禁记录矛盾，或者一张门禁卡在物理上不可能的时间内出现在两个楼层。这类判断的前提，是数字身份和物理身份有一个共同的锚点。
对齐要做四件事
定主键。先选一个在人员入职到离职之间不变的标识当锚点。工号通常更合适，因为它在 HR 系统里不重复、在岗期间不变；手机号和邮箱会变，姓名会重名，都不适合当主键。没有统一工号的组织，退一步用 HR 系统的员工编号，但要在映射表里标注来源。
建映射表。每个业务系统的账号，都要有一条指向主键的记录。映射表本身要能被人看、能被人改，而不是埋在代码里。实践中比较省事的做法是让系统侧提供定期导出，再做一次自动匹配加人工确认：先按姓名、部门、邮箱等字段自动匹配出大部分，剩下的少量人工过一遍。自动匹配的结果必须标出来源，不能和人工确认的混成同一层可信度。
每条映射给置信度。这是最容易被跳过、事后又最要紧的一步。姓名完全匹配、邮箱前缀一致、工号在备注里出现过——这几种证据的强度完全不同。可行的分层是：人工确认的映射为高置信度，多字段一致的为中，仅姓名一致的为低。低置信度的映射在分析里只能作为参考，不能直接作为定责依据。把置信度写进数据里，后面才解释得清为什么某条结论只到「疑似」这一档。
保留原始值。对齐之后不要把原始账号字段覆盖掉。日志分析里最常出现的返工，是某次分析结论被人质疑，回头想核却发现原始账号已经被映射表替换，查不到当时到底是哪个账号。原始值留在字段里，映射结果另开一列。
对齐到什么程度算够
不需要追求全员覆盖。可以用三个信号判断这套东西是否已经在起作用：新入职员工的账号能在当天进映射表；跨系统的同一人操作能被串成一条时间线；对不上的人有一个明确的数目，并且这个数目在下降。
反过来，出现下面这些情况就说明对齐还停在纸面：分析结论经常需要临时去问人；同一个人的两条记录在报表里被算成两个人；共用账号的处理每次都靠个案判断。
边界与前提
本文讨论的是数据侧的身份对齐工作，它不解决人员管理问题——共用账号该不该禁、代刷门禁该不该处理，属于制度范畴，不是对齐能替代的。
另有两个前提需要提前说明。其一，映射表涉及员工个人信息，采集哪些字段、保存多久、谁能查，要按个人信息保护的要求先定规则，不建议把全量字段直接铺开。其二，映射的准确率取决于源系统的数据质量，HR 名单本身不准的组织，要先修名单再做对齐。
深圳市奇摩计算机有限公司在为客户做日志与行为分析的落地时，通常会把这一步单独列成一个前置阶段：先把账号对齐、把对不上的部分建成带置信度的映射表，再谈检测规则与基线。跳过这一步直接上模型，通常会在三个月后因为误报堆积而被弃用。
如果正在评估行为分析类平台的落地路径，可以先盘一遍自家有多少套账号体系、其中哪几套能拿到稳定的导出。这一步往往比选平台更能决定后面走不走得通。预约咨询