脱敏网关看不见“人”：共享账号让动态脱敏失效的三个环节

系统上线那天，验收是过的。策略配了，算法选了，柜台界面上客户的手机号变成星号，身份证号只显示前六位。三个月后稽核问了一句话：上月 12 号下午三点，谁查过这个客户的账户？

没人答得上来。日志里有这么一行：账号 app_query，来源 10.20.31.7，执行了一条 SELECT。

看得见星号，看不见人。这是动态脱敏上线后最常出现的一种失效——不是策略没配，是策略没有对象。动态脱敏的每一次判断都从一个问题开始：你是谁。这个问题答不上来，后面脱成什么样都是随机的。

一、先把判断链说清楚

动态脱敏不是给数据加一把锁，而是在数据被读取的那一瞬间，按访问者身份决定返回什么。它依赖一条完整的判断链：

识别访问者 → 查明其权限 → 匹配脱敏策略 → 改写返回结果 → 留下访问记录。

链条上任何一环断掉，结果都一样：要么该脱的没脱，要么不该脱的被误伤，要么事后查不清谁干的。而这条链的第一环，恰恰是最容易被忽略的一环——它不在脱敏产品里，在账号体系里。在一体化数据安全平台中提供多场景数据安全解决方案，覆盖企业在生产业务系统、数据开发利用、研发运维等不同场景中的数据安全需求，包括数据分类分级、动态脱敏、数据库审计、数据访问控制等能力。需要说清的是，这类平台能做的判断，前提是访问者身份可以被识别。身份识别这件事，平台只能承接，不能凭空创造。

二、第一个断点：连接复用，身份在应用层就丢了

业务系统连数据库，走的是连接池。一个池子里几十条连接，被几百个会话轮流借用。数据库那头看到的永远是同一个账号：app_rw、report_user、crm_app。

这不是配置疏忽，是应用架构的必然。

连接池的存在就是为了复用，而复用的代价，就是丢弃会话身份。用户在页面上登录的是“张某某”，到了数据库那一层，只剩一个应用账号。

这不是猜测，数据库厂商自己在文档里承认过。Oracle 讲代理认证时写得很直白：包括自家 E-Business Suite 在内，很多大型应用对所有连接使用单一用户名，这带来了审计问题——增删改从数据库角度看都是同一个用户做的。

于是出现一个尴尬的局面：脱敏策略可以按“柜员”“客户经理”“外包运维”配置，但代理层根本不知道这次请求是柜员发的还是客户经理发的。它能看到的只有“这是核心系统发来的”。

这一环的判断方法很简单：让一个只有最低权限的账号登录业务系统，再让一个高权限账号做同样的操作，看两次请求到达数据库时携带的标识是否不同。如果两次完全一样，说明身份在这一层已经断了。

三、第二个断点：机用账号被人工使用，账号背后是一群人

比连接复用更麻烦的，是一个数据库账号同时被多个自然人使用。

这个形态有个更准确的说法。工商银行数据中心在《中国金融电脑》上把应用、脚本、系统间调用使用的账号称为“机用用户”，并点出了风险所在：这类账号本来是给程序用的，但运维人员掌握着其中的高权限密码，一旦“人机用户混用”，机用账号就会被非法使用，越权访问业务数据。账号本身没变，用的人从程序变成了人，而且是一群人。

账号的生命周期也跟着系统走，不跟着人走。工商银行那篇文章把这一段写得很实在：运维人员可能因为顾虑改密码导致服务停止，或者担心脚本文件分散、改动有遗漏，干脆就不改，最终让这些高权限账号的密码长期不动；而人工发放回收的账号，还存在超期未回收导致滥用的风险。人员离职、系统下线之后，管理员通常记得回收个人账号，机用账号却一直挂着。

标准的要求写得更直接。《网络安全等级保护基本要求》（GB/T 22239-2019）要求“身份标识具有唯一性”“避免共享账户的存在”“审计覆盖到每个用户”——三条并起来看，共享账号本身就是不符合项。金融行业的标准更具体，《金融数据安全 数据生命周期安全规范》（JR/T 0223-2021）要求把“访问权限与实际访问者的身份或角色进行关联”，特权账号要“对使用者进行实名认证”，并详细记录其访问过程和操作记录。

处罚里能看到落地时的样子。2025 年 4 月，人民银行西双版纳州分行对景洪农商银行罚款 71.5 万元，七项事由里有两项落在征信查询用户上：“征信查询用户调岗离岗未及时停用”“未按规定备案”。同年 12 月，庆阳市分行对华池县农信社罚款 29.79 万元，事由里有一句“征信查询用户离岗后未立即停用”。两件事指向同一处：人走了，账号还在。2026 年 5 月，宁德金融监管分局以“数据安全管理不到位”为由罚屏南县农信社 65 万元，一名责任人禁业三年。

四、第三个断点：绕开应用的访问，连账号都没有

前两个断点都还在“应用访问”这个范围内。真正难处理的是第三类：根本不走应用的访问。

运维用 Navicat、DBeaver、DataGrip 直连生产库；外包厂商通过跳板机连；开发写脚本批量取数；数据同步工具用配置里的账号跑批。这些访问路径上，没有业务系统的登录态，也没有“柜员”“客户经理”这些业务角色，只有一个数据库账号，甚至连账号都是借来的。

这几种路径的共同点，是都不经过业务系统的身份体系。上一节说的“审计覆盖到每个用户”，在这里最难做到——不是不想记，是记不到人。绕过统一入口的客户端直连，恰恰是最不知道操作者是谁的一类。

所以经常出现一种错位：业务系统上的页面对普通用户已经管得很严，但换个客户端直连，看到的就是明文全表。

五、三条访问路径，三种身份来源

把上面的分析收成一张表，会看得更清楚。三类访问的身份来源根本不同，能不能脱敏、怎么接，完全不一样。

这张表解释了一件事：同叫动态脱敏，接入位置不同，能管住的范围差得很远。 只在业务系统前端做遮蔽的方案，第二类和第三类路径完全覆盖不到；只做数据库代理的方案，如果账号本身是共享的，第一类路径也识别不出来。

六、真正管用的做法：把身份与账号解耦

解决思路在业内已经比较统一，叫做身份代填或者身份绑定。

具体是这样：使用者先通过统一身份认证登录（可以对接企业目录、多因素认证，也可以和人事系统联动），代理层根据策略选择对应的数据库账号代为填写、建立连接，同时在本地维护“自然人—账号—会话—SQL”的完整映射。对数据库来说看到的还是原来的应用账号，应用侧不需要改代码；对审计来说，每一条 SQL 都能还原到具体的人。

数据库自己也提供了类似机制。Oracle 的代理认证就是为此设计的，配置上只需一条 ALTER USER ... GRANT CONNECT THROUGH，文档里把好处写得很明白：把真实用户身份一直保留到数据库，让以该用户名义执行的操作可以被审计。工商银行的做法更彻底，运维人员不掌握任何密码，全部交由系统接管，访问时由访问控制服务器代理连接目标资源。

但这些原生机制需要应用配合改造，各家数据库实现不一，实际项目中用得并不普遍。

在这一层的做法，是把数据库代理做成策略执行点：访问者以个人身份进入，代理完成认证与代填，脱敏策略、行级控制、访问审计都在同一个执行点上生效。这样做的意义不在于多了一个功能，而在于“谁能看什么”和“谁看了什么”用的是同一套身份。

七、落地顺序：先治账号，再配策略

这一条是我最想强调的。很多项目把顺序做反了。

第一步，账号盘点。 把数据库里的账号拉一遍清单，标出四类：给应用用的、给人用的、给外包用的、没人认领的。每一类都要能说出归属系统、负责人、最近三十天有没有连接记录。连续长期没有连接行为的，基本可以判定为僵尸账号。

第二步，账号拆分与归位。 应用账号归应用，个人账号归个人，外包账号单独一套并设有效期。拆不动的地方，至少要启用身份透传，让日志能落到人。

第三步，才是配置脱敏策略。 这时候策略才有对象可指。

顺序做反的后果很具体：策略配得很细，按岗位分了七八套，上线后发现所有请求都来自同一个账号，七八套策略全落在一个分支上，等于只有一套生效。

八、几个常被问到的问题

Q：共享账号的问题，能不能靠改造应用解决？

A：能，但代价大。要让应用把登录用户标识透传到数据库会话，涉及代码改造、连接池配置、客户端组件适配，几十套系统逐个改，外采软件还要厂商配合排期。现实的做法是分层：核心系统改造，非核心系统用代理层兜住。

Q：已经上了堡垒机，还需要在数据库这一层做身份识别吗？

A：两者管的不是一件事。堡垒机管的是“谁通过什么通道连上来”，覆盖运维通道；它不决定某个字段该不该显示明文。而且堡垒机通常只管人，不管应用连接池发起的访问。

Q：应用完全不能改，身份还能传到数据库吗？

A：分两种情况。如果应用能在日志里记录操作发起人，可以用时间、来源 IP、SQL 特征做关联还原，精度取决于日志质量；如果连日志都没有，那就只能按应用维度管控，接受“分不到人”这个现实。这时候更该做的是行数限制和异常行为识别，而不是假装做到了字段级。

九、结语

动态脱敏的效力，取决于它能认出多少人。认不出人的脱敏，本质上只是给页面加了一层遮罩——挡得住截图，挡不住查询。