引言：一把授权卡，到底过了几个人的手

营业部早会结束，柜员打开终端，插入自己的柜员卡、输入密码进入柜面系统；遇到超权限交易，主管走过来刷授权卡、输授权密码，交易放行。这套流程在银行和证券营业部里运行了很多年，看起来天衣无缝。

但只要在场地上待过一天，就会看到另一面：主管的授权卡放在抽屉里，谁需要谁去拿；主管在里间开会，柜员拿着卡出来刷一下再送回去；两个柜员共用一个终端，前一个没签退后一个直接接着办；中午吃饭时间屏幕亮着，界面停在客户账户查询页。这些动作没有一个是恶意的，全部是为了"快一点",但它们共同造成一件事：系统里记录的操作人，和实际上做这个动作的人，可能不是同一个。

这个问题在柜面场景下后果特别重。柜面交易直接产生账务结果，涉及客户资金与个人信息；一旦出现差错、争议或案件，第一件事就是查"这笔交易是谁做的"。如果答案只能到"这个柜员号"这一层，而柜员号背后可能是三个人，调查就停在半路。

监管与内控的要求也一直指向同一个方向：身份要唯一、操作要可追溯、授权要真正由有权限的人做出。这些要求落到工程上，最终都要回到一个最基础的地方——终端操作系统的登录那一步。因为如果操作系统这一层是共用的、弱口令的、或者离岗不锁的，那么上面所有应用层的控制都可以被绕过：人可以直接走到那台已经登录的机器前面操作。

本文聚焦金融柜面：柜员终端的身份分层怎么划、一人一钥怎么落到操作系统层、双人复核怎么前置到登录与授权环节、交易留痕怎么做到可归因、离岗与交接班怎么管，以及检查时需要提交哪些证据。

背景：先把柜面的"系统—岗位—动作"三张表摊开

柜面身份治理的设计，必须从场地的真实构成出发。

第一张表是系统表。 营业部的终端上跑的东西比想象中多：

层级	典型系统	登录方式	身份特点
终端基础	操作系统、域账号、终端安全客户端	操作系统登录	常被共用，是最大短板
柜面主体	综合柜面系统、新一代柜面、集中运营平台	应用账号 + 柜员卡或令牌	柜员号，责任最重
专业功能	印鉴核验、票据影像、反洗钱报送、征信查询、理财双录、贵金属	应用内二次登录	部分仍为共用号
渠道与外设	自助设备清机、回单柜、叫号、高拍仪、密码键盘	外设账号或无账号	常被忽略
管理后台	事后监督、稽核、报表、运营管理平台	Web 登录	多为标准 Web

第二张表是岗位表。 柜员、综合柜员、授权主管、网点负责人、客户经理、理财经理、大堂经理、清机加钞人员、事后监督员、稽核员、以及分行下场检查人员。这些岗位里，柜员与授权主管是核心，清机加钞与事后监督是次核心，其余是通用办公。

第三张表是动作表。 柜面一天里真正的敏感动作集中在几处：开户与销户、存取与转账、挂失与解挂、密码重置、账户信息修改、大额与超限交易的授权、冲正与抹账、重要凭证领用与作废、尾箱交接、印鉴变更、理财与贵金属销售、客户信息查询与导出。

三张表交叉后，问题收敛成四个：同一台终端上怎么区分不同的人；需要两个人完成的动作怎么保证真的是两个人；每一笔交易怎么归因到自然人；人离开岗位时怎么保证机器不再可用。 下面逐一拆解。

技术拆解一：三次鉴别的分工——操作系统、柜面应用、业务授权

柜面的身份控制天然存在三次鉴别，很多机构的误区是只做中间那一次。

第一次，操作系统登录。 这是终端的门槛。它决定"谁有资格在这台机器上动键盘鼠标"。如果这一层是共用账号或弱口令，那么任何人在物理上接近终端就能操作。这一层也是最容易被忽略的一层，因为传统上它被认为"只是进系统而已"。

第二次，柜面应用登录。 这是业务的门槛，通常由柜员号加柜员卡或动态口令构成。它决定"这笔业务记在谁名下"。这一层各家机构建设得相对完善，但它的有效性依赖第一层——如果第一层已经被人占着，第二层就形同虚设。

第三次，业务授权。 这是交易的门槛，由授权主管或上级机构远程授权完成。它决定"这笔超权限交易是否合规放行"。这一层的关键是"授权人是否真的是有权限的那个人",而这恰恰是最容易在物理环节被绕过的：授权卡传递、授权密码被旁观、主管本人不在场。

三次鉴别不是重复建设，而是三道不同的门：第一道管物理接触，第二道管业务归属，第三道管风险放行。任何一道缺失，另外两道的效力都会打折。以安当SLA为例，它所解决的是第一道门——把第二因子嵌入 Windows、Linux 与国产操作系统的登录流程，让"进入这台终端"这件事本身就要求持有人出示一个物理或生物凭证，并支持拔出即锁屏，从而让第二道和第三道门有一个可靠的前提。

技术拆解二：一人一钥在操作系统层的落地

"一人一钥"这四个字在制度里写了多年，落地难在两点：一是钥匙形态怎么选，二是怎么保证钥匙跟着人走。

四种第二因子形态在柜面的适用差异。

• 国密 USBKey：与金融行业国密改造方向一致，私钥不可导出，支持 SM2 签名验签，既是登录凭证也是签名工具。适合柜员、授权主管这类固定岗位。它的最大优势是"拔走即锁"这一物理动作极其自然。
• 动态口令 OTP：成本较低，适合人员流动大的岗位或外设终端。需要注意的是手机令牌依赖网络与手机电量，硬件令牌更稳定但要管发放与回收。
• 指纹：识别快、体验好，适合高频操作。但在柜面要正视一个问题——指纹不可撤销，且湿手、脱皮会影响识别率，因此只能作为组合因子之一，不宜作为唯一因子。
• 掌纹或人脸：非接触、适合戴手套或不便接触的场景，但设备成本与环境依赖更高，多用于特定岗位而非全网点铺开。

"钥跟着人走"靠三条机制保证。 其一，拔出即锁：钥匙拔出或令牌离开，终端立即锁屏并结束当前会话，这一条必须做成系统行为而不是用户习惯。其二，一人一钥一绑定：钥匙与柜员号、与终端资产编号做绑定关系登记，谁领用、谁归还、在哪台机器上用，都要有台账。其三，钥匙本身有生命周期：领用、挂失、补发、离职回收全部走流程并留痕，钥匙丢失后要能在分钟级吊销。

离线可用是柜面场景的硬约束。 网点网络条件不一，遇到专线故障或域控不可达时，如果登录因子完全依赖中心服务，柜台就只能停办。因此第二因子的验证要能在终端本地完成——比如基于国密算法的离线挑战应答，或本地校验的动态口令。这一点在离行式自助银行、县域支行、以及临时网点尤其重要，也是选型时必须实测的项。

技术拆解三：双人复核怎么前置到登录与授权环节

双人复核在制度上是清晰的，在工程上却常常只落在"应用里点一下授权"这一个动作上。要让它真正成立，需要在三个位置各加一道约束。

位置一，授权身份的强认证。 授权动作必须由授权人本人的第二因子完成，而不是输入一个授权密码。密码会被旁观、会被代输；硬件因子或生物因子不能。具体形态可以是授权人插入自己的密钥并做一次签名，也可以是授权人本人在终端上完成一次带时效的生物识别。

位置二，物理同在的证明。 双人复核的本意是"两个人在场共同确认"。如果授权可以通过远程传话完成，复核就退化成了一次口头确认。工程上可做的约束包括：授权必须在同一终端上、在限定的时间窗内完成（比如操作发起后两分钟内），且操作人与授权人的终端会话必须处于同一活动状态。更严格的做法是要求两把钥匙在同一台终端上同时存在，物理上强制两人到场。

位置三，互斥关系的系统约束。 同一个自然人不能同时持有操作与授权两种身份，这条要在系统层面硬性约束，不能靠自觉。也就是：如果当前终端会话的操作人是张三，那么授权因子必须是另一个人；同一个人用自己的两把钥匙完成操作加授权，系统应直接拒绝。这一类互斥检查配置起来不复杂，但必须由系统执行才有意义。

授权记录要独立留痕。 授权动作本身是一条独立审计事件，字段至少包括：交易流水号、操作人、授权人、授权时间、授权方式（因子类型）、授权结果、以及授权时的终端标识。这条记录与交易记录分开存储、互相关联，事后才能回答"这笔交易是谁批的"。

技术拆解四：交易留痕的可归因——三个标识怎么对齐

可归因的技术实质，是把三个标识在时间轴上对齐：终端会话标识、柜员号、交易流水号。

终端会话标识来自操作系统层的登录事件，它回答"这台机器当时是谁在用"。柜员号来自柜面应用，回答"这笔业务记在谁名下"。交易流水号来自核心系统，回答"具体发生了什么"。

三者缺一，归因就断：

• 只有柜员号没有终端会话：能知道记在谁名下，但无法证明"当时确实是他坐在那台机器前",也无法发现"别人用他的号在他已登录的机器上操作"。
• 只有终端会话没有柜员号：能知道谁在用机器，但关联不到具体交易。
• 两者都有但没有统一时间基准：跨系统关联错位，出现"交易发生在登录之前"这种不可能的时间关系。

因此改造的核心动作是三件：把操作系统层登录事件纳入统一审计（含登录账号、第二因子类型、终端资产编号、时间戳）；在柜面应用侧把柜员号与终端会话标识做绑定并写入交易上下文；强制所有相关系统统一时间源，并在审计记录里同时保留本地时间与统一时间。

归因要落到"自然人 + 认证方式"两层。 一条合格的柜面操作审计记录，不只是"柜员号 A 做了交易 T",还要写明"A 是用什么方式证明自己是 A 的"——是密钥签名、动态口令还是生物特征。因为在争议场景下，质疑的往往不是"是谁",而是"能不能证明是他"。

异常模式比单点记录更有用。 归因数据建起来之后，最有价值的用法是跑异常：同一柜员号在短时间内出现在两台终端上；同一终端在交接时刻出现两个柜员号并发操作；某柜员号的操作集中在非营业时间；某终端的登录与签退时间不匹配班次。这些模式是内部排查和飞单风险识别的抓手，比逐条看日志有效得多。

技术拆解五：离岗锁屏——三种触发与一个常被混淆的概念

柜面有一条铁律：人离柜，终端必须不可用。工程上要把它做成三件事。

触发一，空闲超时。 按岗位与业务敏感度分级设置：柜面交易类建议 1 到 3 分钟，查询与管理类可放宽到 5 到 10 分钟。超时后锁屏，且必须重新出示第二因子才能恢复，不能只输一个口令。

触发二，物理触发。 拔出密钥、离开工位感应、或柜员主动按下锁屏键。物理触发优于超时，因为它不依赖时间判断——人起身走了立刻锁上，中间没有可乘之机。

触发三，业务触发。 某些动作完成后强制锁屏或强制重新认证，比如重要凭证作废、尾箱交接完成、客户信息导出。这类触发是按动作设计的，针对性强。

必须区分"锁屏"与"签退"。 这是一个高频混淆点。锁屏只是终端不可用，柜面应用的会话可能还活着，恢复后直接回到业务界面；签退是真的结束了业务会话。柜面场景下，短暂离席（去洗手间、取凭证）用锁屏即可，但离岗用餐、下班、换人操作必须签退。工程上要做的约束是：锁屏超过一定时长自动转为签退；以及恢复锁屏时，如果检测到终端已换人（比如插入的是另一把钥匙），必须先签退前一个会话再建立新的，不允许直接接管。

交接与顶岗要留痕。 交接班时双方共同确认尾箱、凭证、现金与未结业务，系统记录交接时间、双方柜员号、终端标识与确认结果。顶岗（临时替班）要走临时授权：明确顶岗人、被顶岗人、时间窗、可用业务范围，到期自动失效。顶岗期间的操作必须同时关联顶岗人与被顶岗柜员号，否则事后无法解释"为什么这个时间段的操作不是本人做的"。

技术拆解六：柜员号共用的收口路径

柜员号共用在很多网点仍然存在，成因复杂：人员编制紧张、临时顶岗未走流程、系统限制必须按机构设号等。一刀切禁止会直接影响营业，可行的路径分三步。

第一步，先做到"共用号背后有真人"。 即使柜员号共用，也要求操作者用本人第二因子完成一次实名认证后才能调用，系统在审计里同时记录"柜员号 + 实际认证人"。这一步不改变业务系统，只改变登录入口，投入最小，立刻产生归因能力。

第二步，压降共用范围。 统计每个共用柜员号的使用频次、涉及的交易类型与时间段，把高频、高风险交易（开户、挂失、密码重置、大额转账、冲正）优先迁移到实名柜员号，低频的流程性操作暂时保留共用。这一步要用数据说话，否则会陷入无休止的争论。

第三步，对保留的共用号加约束。 限定可用终端、限定可用时段、限定并发数、高风险动作强制二次认证。约束之后，即便号被滥用，损失范围也可控。

外设与后台账号不能漏。 清机加钞终端、回单柜、事后监督、报表平台这些"非主柜台"的系统，往往还停留在共用账号加简单口令的状态，而它们恰恰能看到客户账户信息与交易明细。改造范围要把它们一并纳入，至少做到双人开箱与操作留痕。

改造路径：六步落地

第一步，终端与账号盘点。 建立三张清单：终端清单（资产编号、位置、用途、是否共用、操作系统版本）、账号清单（柜员号、类型、使用人、是否共用、最近一次变更）、钥匙清单（因子类型、持有人、领用时间、状态）。这一步必须现场清点，不能只看台账。

第二步，选一家网点做试点。 建议选一个业务量中等、配合度高的网点，覆盖柜员、授权主管、清机加钞三类角色。试点期重点验证两件事：登录耗时是否可接受、拔出即锁是否影响业务连续性。

第三步，跑通三次鉴别的联动。 操作系统登录加第二因子、柜面应用登录不动或轻量关联、授权环节加强认证与互斥检查。这一步的验收标准是"每一笔授权交易的授权人都能查到自然人与其认证方式"。

第四步，补齐归因链路。 把操作系统登录事件纳入统一审计，柜员号与终端会话标识绑定，全系统时间同步，跑通三个标识的关联查询。

第五步，铺开到全辖区并治理共用号。 按网点分批推广，同步推进共用柜员号的三步收口，并把外设与后台系统纳入。

第六步，建证据包并做模拟检查。 按下一节清单整理材料，随机抽一笔三个月前的授权交易，要求两小时内查出操作人、授权人、终端、时间与认证方式。

配置示例

以下示例用于说明策略形态，具体参数以实际环境为准。

柜面终端第二因子策略（终端侧，类 YAML 描述）：

terminalAuthPolicy:
  factorRequirements:
    teller:                       # 柜员：操作系统层必须有第二因子
      primary: password
      second: usbkey_sm2          # 国密 USBKey，SM2 签名验签
      offlineCapable: true        # 专线中断时仍可本地验证
    authorizer:                   # 授权主管
      primary: password
      second: usbkey_sm2
      offlineCapable: true
      mutualExclusiveWith: teller # 系统级互斥：同一人不得兼任操作与授权
    cash_vault:                   # 清机加钞
      primary: password
      second: usbkey_sm2
      requireDualPresence: true   # 双人同在
    back_office:                  # 事后监督、报表
      primary: password
      second: otp

  onFactorRemoved:
    action: lock_now              # 拔 Key 立即锁屏
    endAppSession: true           # 同时结束柜面应用会话，防"锁屏不签退"
    audit: true

  idleLock:
    teller: 180                   # 秒
    authorizer: 180
    back_office: 600
    lockToSignOffAfter: 900       # 锁屏超过 15 分钟自动转签退
    resumeRequiresSecondFactor: true

  handover:                       # 交接班与顶岗
    requireDualConfirm: true
    fields: [time, fromTeller, toTeller, terminalAssetNo, vaultStatus, unreconciledItems]
    tempCover:
      maxHours: 8
      autoExpire: true
      auditLink: [coverPerson, originalTeller]

授权环节的双人复核约束（柜面应用侧配合改造）：

dualControl:
  - transaction: [大额转账, 冲正抹账, 挂失解挂, 密码重置, 账户信息修改]
    requireAuthorizerSecondFactor: true
    authorizerMustDifferFromOperator: true   # 硬性互斥，系统校验
    sameTerminalRequired: true               # 授权须在同一终端
    timeWindowSeconds: 120                   # 操作发起后两分钟内完成授权
    concurrentSessionCheck: true             # 操作人与授权人会话须同时活动
    onViolation: reject_and_alert
    audit:
      independent: true                      # 授权事件独立留痕
      fields: [txnId, operator, authorizer, authTime, authFactor, terminalAssetNo, result]

审计记录样例（集中留存，可归因到自然人）：

{
  "event_id": "BR-20260911-000317",
  "timestamp": "2026-09-11T10:42:19+08:00",
  "txn": { "id": "TXN2026091100421788", "type": "大额转账", "amount": 480000,
           "accountMasked": "6222**********3412" },
  "operator": { "tellerNo": "T0371", "employeeNo": "E20193", "name": "王某",
                "osLoginFactor": "usbkey_sm2", "terminalAssetNo": "BR-0211-PC03" },
  "authorizer": { "tellerNo": "A0102", "employeeNo": "E10077", "name": "赵某",
                  "authFactor": "usbkey_sm2", "authTime": "2026-09-11T10:43:02+08:00",
                  "sameTerminal": true },
  "session": { "osSessionId": "OS-20260911-0088", "appSessionId": "APP-20260911-0412",
               "shift": "早班", "handoverConfirmed": true },
  "policy": { "rule": "dualControl[0]", "result": "allowed" },
  "logIntegrity": { "seq": 317, "prevHash": "9a1c...", "selfHash": "4e7d..." }
}

验证：确认一人一钥与双人复核真正生效：

# 1. 拔出即锁验证：拔出密钥后终端应立即锁屏且应用会话结束
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4800} -MaxEvents 3 |
  Select-Object TimeCreated, Message
# 预期：锁屏事件在拔 Key 后 1 秒内产生；柜面应用同时回到登录界面

# 2. 互斥验证：同一人先后用操作钥匙与授权钥匙完成一笔需授权交易
# 预期：系统拒绝并告警，提示操作人与授权人不得为同一自然人

# 3. 离线验证：断开与中心服务的网络，仍应能用本地因子完成登录并留痕
# 预期：登录成功；恢复网络后审计记录自动补齐，不出现断档

验证方法：七条实测

1. 登录耗时实测。 在真实柜台上连续测十次从唤醒屏幕到进入柜面应用的耗时，取中位数。超过十五秒的方案，早高峰一定会被绕过。
2. 拔 Key 即锁测试。 拔出密钥后一秒内锁屏，且柜面应用会话同步结束，恢复后必须重新出示第二因子。
3. 互斥测试。 用同一个人的两把钥匙尝试完成操作加授权，应被拒绝并告警。
4. 双人同在测试。 尝试在授权人不在场的情况下通过传话完成授权，应因同终端或时间窗约束失败。
5. 离线登录测试。 断开中心服务与域控，验证本地因子仍可登录，且恢复后审计补齐。
6. 归因反查测试。 给定一笔三个月前的授权交易流水号，两小时内查出操作人、授权人、终端、时间与认证方式。
7. 离岗与交接测试。 模拟离岗用餐（锁屏超过阈值应自动转签退）与交接班（双方确认并留痕，未结业务有记录）。

第 1、5 条验证"业务跑得动",第 2、3、4 条验证"控制真的生效",第 6、7 条验证"事后查得到"。

风险与误区

误区一，只在应用层做控制。 柜面应用控制得再严，只要操作系统是共用且不锁的，人走过去就能用。第一道门不修，后面都是纸糊的。

误区二，把授权做成输入授权密码。 密码可以被旁观、被代输、被转述。授权必须是持证人的物理或生物凭证，且系统校验与操作人互斥。

误区三，把锁屏当成签退。 锁屏不等于结束业务会话。换人操作时若只锁屏不签退，前一个柜员的业务界面会直接暴露给下一个人。

误区四，忽略外设与后台系统。 清机加钞、回单柜、事后监督、报表平台常停留在共用账号加弱口令，却能看到完整的客户账户与交易信息。

误区五，离线能力没实测。 专线故障在县域与离行式网点并不罕见。上线前不做断网演练，第一次故障就是停业。

误区六，钥匙台账靠人工。 领用、挂失、补发、回收不做系统与台账管理，离职人员的钥匙往往长期在外，这是最典型的历史遗留风险。

误区七，只看单点日志不做异常建模。 归因数据的价值在于跑模式：同号双终端、交接时刻并发、非营业时间操作、登录与签退不匹配班次。没有建模，日志只是成本。

证据材料清单（监管检查与内控审计取证用）

1. 终端清单：资产编号、位置、用途、是否共用、操作系统版本、第二因子类型与启用时间。
2. 账号清单：柜员号、类型、使用人、是否共用、开通与最近一次变更时间、状态。
3. 钥匙台账：因子类型、持有人、领用时间、挂失与补发记录、离职回收记录、吊销时效说明。
4. 认证策略配置导出：各岗位的第二因子要求、空闲超时分级、锁屏转签退阈值、拔出即锁配置。
5. 双人复核配置与验证记录：需授权交易清单、互斥约束配置、同终端与时间窗规则、互斥与双人同在的实测结论。
6. 授权事件审计样本：含交易流水号、操作人、授权人、授权方式、时间、终端标识的独立记录（可脱敏）。
7. 归因链路说明：终端会话标识、柜员号、交易流水号三者绑定关系的技术说明与时间同步配置。
8. 离线能力验证记录：断网与域控失联场景下的登录测试步骤、结果、恢复后审计补齐情况。
9. 离岗与交接班材料：锁屏与签退的区分规则、交接确认单样本、顶岗临时授权的配置与到期失效记录。
10. 共用柜员号治理材料：共用号清单、使用频次统计、压降计划与执行进度、保留号的约束配置。
11. 异常监测规则与样例：同号双终端、非营业时间操作、交接时刻并发等规则的命中样例与处置记录。
12. 算法与产品合规材料：国密算法使用说明、密码产品检测认证证书、密钥不可导出的技术说明。

方案参考

金融柜面身份治理的落地，建议按下面的顺序推进：

• 把三次鉴别划清楚：操作系统登录管物理接触，柜面应用登录管业务归属，业务授权管风险放行。三道门缺一，另外两道都会打折。
• 先修第一道门。柜面应用控制再严密，只要终端操作系统共用且不锁，人走过去就能操作，应用层的所有投入都会被绕过。
• 一人一钥的三条机制要同时建：拔出即锁做成系统行为、钥匙与人和终端做绑定台账、钥匙全生命周期（领用、挂失、补发、回收、吊销）走流程并留痕。
• 第二因子形态按岗位选：柜员与授权主管用国密 USBKey，私钥不可导出且能复用为签名工具；流动岗位与外设终端用动态口令；指纹适宜作为组合因子，不宜作为唯一因子。
• 离线能力必须实测。专线故障与域控失联在县域、离行式网点并不罕见，本地可验证的第二因子是营业连续性的前提。
• 双人复核前置到工程约束：授权必须有授权人本人的第二因子、系统硬性校验操作人与授权人互斥、授权须在同一终端且在限定时间窗内完成，授权事件独立留痕。
• 归因的本质是把终端会话标识、柜员号、交易流水号三个标识在时间轴上对齐，前提是强制时间同步，并在审计里同时记录"是谁"和"用什么方式证明是自己"。
• 区分锁屏与签退：短暂离席锁屏即可，用餐、下班、换人必须签退；锁屏超时自动转签退，恢复时若检测到换人则强制结束前一会话。
• 交接班与顶岗必须留痕：交接双方确认并关联未结业务，顶岗走临时授权并限定时间窗与业务范围，到期自动失效，操作同时关联顶岗人与原柜员号。
• 柜员号共用分三步收口：先让共用号背后有真人，再按数据压降高风险场景，最后对保留号加终端、时段、并发与二次认证约束。
• 把外设与后台系统一并纳入改造范围，清机加钞、回单柜、事后监督与报表平台往往是最薄弱却能看到完整客户信息的一环。
• 归因数据建起来之后要跑异常模式，同号双终端、交接时刻并发、非营业时间操作、登录与签退不匹配班次，这些才是日常运营真正用得上的东西。
• 证据包提前建好并做模拟检查，验收标准就是"随机抽一笔三个月前的授权交易，两小时内查出操作人、授权人、终端、时间与认证方式"。

以安当SLA为例，其操作系统登录双因素将第二因子嵌入 Windows、Linux 与国产操作系统的登录流程，支持国密 USBKey、动态口令、指纹与掌纹四类因子，覆盖单机、联网与 SaaS 三种部署形态，并适配麒麟与统信等信创环境；在柜面场景中，其拔 Key 自动锁屏、离线应急口令与全链路审计能力，正好对应"人离柜即锁"“专线中断仍能营业”"每笔操作可归因"这三项最硬的现场要求，并可与统一身份认证平台对接，把终端侧的身份事件汇入全行统一审计。