安当DBG：保险理赔系统怎么给证件号、银行卡与病历字段上字段级加密——客服坐席按角色最小可见、外包公估脱敏留证的落地路径-平芜编程栈

引言：理赔系统里最该保护、也最容易被看光的字段

保险业务的核心是"理赔"，而理赔系统的核心数据，是三类高度敏感、又必须被反复查询的字段：被保人证件号、理赔收款银行卡号、以及出险病历与诊断结论。这三类字段有两个共同特点，恰好让它们成为数据安全的"重灾区"。

第一，它们查询频率极高。客服坐席每接一通电话要核对证件号，财务每笔付款要核对银行卡，核赔员每审一单要看病历。字段就在 SQL 的 SELECT 列表里、就在接口返回里、就在坐席屏幕里，几乎无法靠"少查"来降风险。

第二，它们可见范围极广。一条理赔记录从进件、初审、查勘、核赔、付款到归档，要经过客服、查勘员、公估机构、核赔员、财务人员、甚至外部合作医院与数据公司，任何一环都能看到明文，任何一环出问题都是大面积的个人信息泄露。这些年监管对保险行业个人信息保护、病历数据出境与使用的处罚，几乎都绕不开这三类字段。

但很多保险公司的数据库安全建设还停留在"库前加一道防火墙、库后做一份备份"的阶段。库里的证件号、银行卡、病历全是明文，谁能连上库谁就能 SELECT 出来；应用接口把字段原样返给前端，坐席屏幕、外包坐席屏幕、公估平台屏幕照单全收。这种"库外严防、库内裸奔"的格局，正是内部泄露与外部合规风险的交汇点。

本文要讲清楚的是：在不改写理赔系统一行代码的前提下，怎样用字段级加密网关把这三类字段在存储侧加密、在查询侧按角色动态脱敏，让客服只看见该看的、让外包公估只拿到能用的脱敏结果、让整个链路留下可被监管检查的证据。

背景：理赔系统里到底有哪些"看字段"的角色与通道

要谈保护，先得把"谁能看到字段、通过什么通道看到"这件事列清楚。保险理赔系统的字段可见链条，远比一张表复杂。

角色维度。至少可以拆出七类主体：报案客服坐席（核对证件号、登记银行卡）、理赔初审员（看基本信息与初步材料）、现场查勘员（看出险地点与基本信息）、外部公估机构（评估损失、看相关病历）、核赔员（看全部材料定损）、财务付款岗（看银行卡与金额）、以及合作医院与数据服务方（提供病历与诊疗数据）。这七类角色对证件号、银行卡、病历的"可见必要度"完全不同：客服只需核对证件号后四位，财务只需银行卡号与户名，公估只需与定损相关的病历片段，核赔才需要相对完整的信息。

通道维度。字段从库里出来，至少走四条通道：应用服务端 SQL 查询后返回接口（坐席前端、移动查勘端）；运维与数据人员直连数据库做排查（DBA、数据工程师）；批量作业抽取（日终对账、精算建模、监管报送的数据抽取）；以及对外接口（与合作医院、公估平台、再保公司的数据交换）。四条通道里，前两条是日常主通道，后两条是批量与外联通道，风险点各不相同。

系统维度。典型理赔系统不是一个库，而是核心业务库（存保单与理赔主表）、影像与病历库（存病历 PDF、影像、诊断结构化字段）、财务库（存收款账户）、以及数据中台（做抽取与建模）。字段分散在 MySQL、SQL Server、Oracle、甚至达梦、人大金仓等国产化库里，跨库、跨类型，统一加密与脱敏策略如果逐库做，运维成本会失控。

把三个维度合起来看，问题就清楚了：保护的不是"字段"本身，而是"字段在不同角色、不同通道、不同系统下的可见形态"。这正是字段级加密网关与动态脱敏三视图要解决的事。

技术拆解一：字段级加密与动态脱敏是两件不同的事，但共用一条链路

很多方案把"加密"和"脱敏"混为一谈，结果要么全加密导致业务查不了，要么全脱敏导致库里没有真值。正确的理解是两者解决不同环节，且应串联在一条透明代理链路上。

环节一，存储加密（落库即密文）。字段级加密网关部署在应用与数据库之间，对指定的列（证件号、银行卡号、病历关键字段）在写入时加密、在读出时解密，数据库落盘文件里存的是密文。它的价值是：即便 DBA 直连生产库、即便数据库文件被拖走、即便云上管理员看到数据文件，看到的也只是密文。这解决了"库内裸奔"的问题，属于"静态保护"。

环节二，查询侧脱敏（按角色给不同视图）。但存储加密只解决"库里"的安全。应用查出来之后，坐席、外包、公估看到的还是明文。所以网关在读出解密之后、返回应用之前，还要按访问主体的角色再做一次"动态脱敏"——同样的 SQL、同样的行，客服看到证件号打码、核赔看到完整、公估看到脱敏后的可用结果。这解决的是"库外可见范围"的问题，属于"动态保护"。

两者串在一条链路上（安当DBG 即以"透明加密网关 + 运维管控网关"双模式支撑这条链路）：透明加密网关负责字段级加密存储，运维管控网关负责明文存储场景下的输出脱敏与 SQL 级拦截。对理赔系统更推荐前者——落库即密文，从根上消除明文泄露面。以安当DBG为例，它在应用与数据库之间做透明代理，对列级字段加密存储，同时按角色策略在结果集上做动态脱敏，应用零改造就能同时拿到"存储安全"和"可见收敛"两层收益。

技术拆解二：三类字段各自的加密与脱敏设计

三类字段的业务语义不同，加密与脱敏策略要分开设计，不能一刀切。

证件号（身份证）。这是核对型字段：客服要"验证是不是这个人"，财务要"跟银行卡户名对不对得上"，但日常不需要看到完整十八位。加密侧用字段级加密（国密 SM4）落库；脱敏侧按角色给视图：客服坐席返回"310***********1234"（保留前三位与后四位，中间掩码）；核赔与风控返回完整；外包与公估只返回"已核验通过/未通过"的状态位，不返回明文。关键点是，证件号经常要参与相等判断（“查这个人的所有保单”），所以加密要支持等值查询——这正是保留格式加密（FPE）的价值：加密后仍可 LIKE、可等值比对，业务查询不中断。

银行卡号。这是付款型字段：财务要看完整卡号与户名做付款，客服只需核对后四位防填错。加密侧同样字段级加密；脱敏侧客服返回后四位掩码、财务返回完整、公估与医院侧根本不应出现在查询权限里。银行卡号还会被用于"查重"（同一卡号多笔理赔可能是欺诈信号），所以同样依赖 FPE 的等值比对能力，加密后仍能在库内做去重与关联，无需解密。

病历与诊断。这是内容型字段：结构化字段（诊断编码、科室、用药）与半结构化字段（病历 PDF、影像报告）并存。结构化部分按列加密、按角色脱敏（核赔看完整、公估看与定损相关片段、客服不看）；半结构化部分（PDF、报告文本）建议做全文加密存储，对外部公估平台只输出"脱敏后的结构化摘要"，绝不出原始病历文本。病历还涉及病历数据合规使用边界，对外提供必须最小化，这一条在策略里要写成硬规则。

三类字段的设计原则可以归纳为一句话：能等值比对的用 FPE 保查询，能掩码的按角色掩，内容型的只给摘要不给原文。

技术拆解三：客服坐席按角色最小可见，策略怎么写

“最小可见"落到字段级加密网关上，就是给每个角色定义一套"字段可见策略”。这套策略不是写在应用代码里，而是写在网关的策略引擎里，与应用解耦，改策略不碰业务系统。

角色画像先行。先把理赔系统里的角色枚举清楚，给每个角色定义"对每类字段的可见级别"：完整、掩码、状态位、不可见。例如：

角色	证件号	银行卡号	病历原文	病历摘要
报案客服坐席	掩码（前后四位）	掩码（后四位）	不可见	不可见
理赔初审员	掩码	掩码	不可见	可见
现场查勘员	掩码	不可见	不可见	可见（出险相关）
外部公估机构	状态位	不可见	不可见	可见（定损相关片段）
核赔员	完整	掩码（财务段才完整）	完整	完整
财务付款岗	不可见（付款时由系统校验）	完整	不可见	不可见
合作医院/数据方	不可见	不可见	不可见	仅回传结构化字段

这张表是策略的"真相来源"，也是后面合规检查的核心证据之一。

策略如何与登录身份绑定。网关需要知道"当前是谁、什么角色"，才能路由到对应视图。工程上不推荐让网关自己管身份，而是复用企业已有的统一身份认证（如 SSO 下发的角色声明、或应用下传的会话角色）。网关在收到 SQL 时，从连接会话里取出角色标识，匹配策略引擎，决定字段返回形态。这里有个关键约束：角色标识必须从可信通道获得，不能由应用随便传一个字符串就信——否则攻击者伪造角色就能拿完整字段。因此角色映射建议由网关侧的配置仲裁，应用只传会话标识，角色与字段权限的对应在网关侧闭环。

最小可见的"反向校验"。策略写完后要反过来问一句：有没有角色拿到的字段超过了它的业务必需？比如客服坐席如果某天突然能查到完整病历，一定是策略配错了；核赔员如果连证件号都看不到，一定是权限漏了。把"角色—字段"矩阵当成一张强约束的授权表，任何偏离都要告警，这是最小可见能长期成立的前提。

技术拆解四：理赔外包与公估，如何用"脱敏结果"而不是"明文"

保险理赔高度依赖外包与公估：查勘定损常外包给公估机构，大案要案要外部专家参与，甚至部分初审岗是外包坐席。这些外部主体必须能"用数据"，但又绝不能"拿到明文"。字段级加密网关的脱敏三视图，正好把外部角色卡在"脱敏结果"这一层。

公估机构的数据使用形态。公估机构评估一辆车的损失，需要的是出险时间、车型、定损项目、历史理赔概要——它不需要被保人完整证件号，不需要银行卡，也不需要原始病历全文。因此它拿到的应当是：证件号状态位（已核验）、银行卡状态位（已核验）、病历的脱敏摘要（与定损相关的伤情描述，已去除姓名与可识别信息）。这种"脱敏结果"足以支撑它的业务，又从源头切断了敏感字段流向外部的可能。

外包坐席的视图隔离。外包客服坐席与自有坐席用同一套前端、查同一张表，差异只在角色。网关按角色返回不同视图，外包坐席屏幕天然只显示掩码与状态位。这里要特别注意一个盲区：外包坐席如果可以通过"导出 Excel""打印工单"把屏幕内容落盘，脱敏就白做了。所以脱敏策略必须与终端侧的外发管控联动——导出与打印的也是脱敏后的结果，而不是屏幕背后解密出来的明文。

对外接口的脱敏输出。与合作医院、再保公司、数据服务方的数据交换，往往走接口批量推送。这类接口最容易"顺手"把完整字段推过去。正确做法是接口在网关侧统一收口，推送出去的字段全部走脱敏策略，合作方拿到的永远是脱敏结果；若某业务确实需明文（极个别情形），必须走单独的明文外发审批，且审批单、用途、有效期、接收方全部留痕。

脱敏结果的可还原性边界。必须明确：脱敏结果在外部不可还原。也就是说，公估拿到的状态位与摘要，无法通过任何手段反推证件号与银行卡。这就要求脱敏函数走单向或密钥隔离设计，脱敏视图用的密钥与存储加密的密钥严格分离，外部系统即便拿到脱敏数据也还原不出明文。这一条常被忽略，却是外部合规审查的硬指标。

技术拆解五：留 Evidence 给合规检查——哪些证据必须可查

保险行业受多重监管：个人信息保护、病历数据使用、金融数据安全、等保与密评。字段级加密网关要在这些检查里"说清楚"，靠的不是一句"我们加密了"，而是一组可被抽取、可被核验的证据材料。

证据一，字段加密的存证。证明证件号、银行卡、病历字段在库里是密文：导出的表结构或抽样数据要能展示这些列的内容为密文形态，且加密算法为合规的国密 SM4。同时要能说明密钥由密钥管理系统集中管理、根密钥受硬件保护、密钥生命周期可控——这对应密评对"密钥管理"的要求。

证据二，角色—字段授权矩阵。即上一节的角色可见表，它是"最小可见"的可审计依据。检查时要能回答：每个角色为什么能看到它看到的字段、看不到的字段是被谁拦的。矩阵要带版本与生效时间，变更有审批。

证据三，动态脱敏的命中日志。每一次查询返回的是完整、掩码还是状态位，都要记下来：谁、什么角色、查了哪张表的哪一行、哪些字段走了脱敏、脱敏形态是什么、结果放行还是拦截。这套日志是"按角色最小可见"真正落地的证明，也是事后追溯"谁看过某客户的证件号"的依据。

证据四，运维 SQL 拦截与全量审计。理赔系统的 DBA、数据工程师常直连库做排查，这类通道最易泄露。网关的运维管控能力要在 SQL 级做拦截（比如禁止 SELECT 证件号/银行卡的明文、禁止整表导出），并把所有运维操作全量审计。合规检查时会重点看：有没有人绕过脱敏直接拉明文、拦截规则是否被触发过、告警有没有人处理。

证据五，对外数据交换的留痕。与合作医院、公估、再保的每次数据推送，记下发往哪、发了什么字段形态（脱敏/明文）、有没有走审批。这是病历数据合规使用与外部数据共享审查的主线证据。

把五类证据串起来，合规检查要回答的核心问题就闭环了：字段有没有加密（静态）、谁能看到什么（动态）、外部拿到的是什么（脱敏）、运维有没有越界（拦截）、全链路能不能追溯（审计）。

技术拆解六：与 TDE 的双层配合，以及密钥怎么归口

字段级加密网关解决的是"列"的问题，但它不是银弹。理赔系统的病历 PDF、影像报告这类大对象、以及库文件本身，更适合在文件系统层用透明加密兜底。两者配合构成"双层防护"。

内层，DBG 字段级加密。针对证件号、银行卡、病历结构化字段做列级加密与脱敏，控制"字段可见"。

外层，TDE 透明加密。对数据库落盘文件、病历 PDF 存储目录、备份集做文件系统层透明加密，控制"文件落地即密文"，即使库文件、备份被拷走也打不开。两层叠加，字段级防内部窥探、文件级防介质丢失，覆盖面互补。

密钥归口到 KSP。无论是 DBG 的字段密钥还是 TDE 的文件密钥，根密钥都应统一收口到密钥管理系统（KSP），由硬件密码机保护根密钥、做密钥生成到销毁的全生命周期管理。这样做有两个好处：一是满足密评对密钥集中管理的要求；二是当某个角色权限要回收、某把字段密钥要轮换时，有统一的管控面，不至于散落在各系统各自为政。

改造路径：六步落地

理赔系统上字段级加密网关，最忌"一口气全库加密"。建议按六步推进，每步有产出物。

第一步，字段盘点与分级。拉出理赔相关全部库表，标出敏感字段：证件号、银行卡、病历结构化字段、病历原文对象。给每类字段定密级与默认策略（加密 + 默认脱敏形态）。产出《敏感字段清单》与《字段分级表》。这步不做，后面策略全是拍脑袋。

第二步，角色—字段矩阵评审。联合业务、合规、安全三方，把上一节的角色可见表逐字段确认，合规签字生效。产出带版本号的《角色字段授权矩阵》。这是后续所有策略与证据的源头。

第三步，先在影子模式跑。网关先以"审计不拦截"模式上线，观察真实查询里各角色实际访问了哪些字段、有没有越权访问、脱敏策略会不会误伤业务。影子期跑至少一个完整业务周期（建议覆盖月初报案高峰与月末付款高峰），确认无误再切真实加密。

第四步，核心字段先加密。优先把证件号、银行卡两类核对型字段加密落库，用 FPE 保等值比对，验证客服核对、财务付款、反欺诈查重都不受影响。病历类大对象放到与 TDE 配合的外层处理，降低单点改造风险。

第五步，脱敏策略按角色灰度。先放开自有坐席与核赔员视图，再放开外包坐席与公估接口。每放开一类角色，观察脱敏日志与业务反馈，确认"该看的看到、不该看的看不到"。

第六步，证据归档与合规预检。按下一节清单导出五类证据，做一次内部预检，补掉缺口后再迎接外部检查。

配置示例

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

字段加密与脱敏策略（网关策略侧，类 YAML 描述）：

# 理赔系统字段级加密与动态脱敏策略claimFieldPolicy:cipher:algorithm:SM4# 国密 SM4，合规算法mode:FPE# 保留格式加密，支持等值/LIKE 比对keySource:ksp# 字段密钥由密钥管理系统统一下发与轮换columns:-table:policy_claimcolumn:id_cardencrypt:true-table:policy_claimcolumn:bank_cardencrypt:true-table:claim_medicalcolumn:diagnosis_codeencrypt:truedesensitize:# 动态脱敏三视图，按角色路由defaultView:mask# 默认掩码，白名单思维roleViews:-role:cs_agent# 报案客服坐席id_card:"310***********1234"# 保留前后四位bank_card:"****1234"medical:none-role:claim_assessor# 核赔员id_card:plainbank_card:mask_finance# 财务段才完整medical:plain-role:outsourced_cs# 外包客服坐席id_card:maskbank_card:maskmedical:none-role:public_adjuster# 外部公估机构id_card:status_only# 只给状态位bank_card:nonemedical:summary_only# 只给定损相关摘要-role:finance_pay# 财务付款岗id_card:nonebank_card:plainmedical:noneroleBinding:source:sso_session# 角色取自可信 SSO 会话，应用不自行声明enforceGatewayArbiter:true# 角色—字段映射在网关侧闭环仲裁

运维 SQL 拦截与审计（运维管控侧）：

opsGuard:sqlIntercept:-pattern:"SELECT .*id_card.* FROM policy_claim"roleNotIn:[claim_assessor,finance_pay]action:mask_result# 非授权角色查证件号，返回脱敏结果-pattern:"SELECT .* FROM policy_claim"action:full_audit# 整表查询全部审计-pattern:"SELECT .*bank_card.*"roleNotIn:[finance_pay]action:mask_resultaudit:fields:[account,role,table,row_key,columns,view_type,result,ts]exportTo:central_log# 全量审计上报独立日志服务outbound:partnerPush:defaultView:desensitized# 对外推送默认脱敏plainRequires:approval# 明文外发必须走审批approvalBind:[file_sm3,partner,valid_until]

审计记录样例（服务端集中留存）：

{"event_id":"DBG-20260912-003314","timestamp":"2026-09-12T10:05:22+08:00","subject":{"account":"cs_wang","role":"cs_agent","session":"SSO-9f2a"},"object":{"table":"policy_claim","row_key":"CLM-2026-88123","columns":["id_card","bank_card"]},"action":{"sql":"SELECT id_card,bank_card FROM policy_claim WHERE ...","view_type":"mask","result":"allowed"},"policy":{"rule":"desensitize.roleViews[cs_agent]","approval_id":null}}

验证：确认字段加密与脱敏真的生效：

-- 1. 库内抽样：直连数据库看到的应是密文，而非明文证件号SELECTid_cardFROMpolicy_claimWHEREclaim_no='CLM-2026-88123';-- 预期：返回 SM4/FPE 密文，形如 'a7f3***'，不是 310***********1234 也不是明文-- 2. 坐席视图：以 cs_agent 角色查询，返回掩码/* 通过网关以 cs_agent 会话执行 */SELECTid_card,bank_cardFROMpolicy_claimWHEREclaim_no='CLM-2026-88123';-- 预期：id_card 显示前后四位掩码，bank_card 显示后四位掩码-- 3. 公估视图：以 public_adjuster 角色查询，证件号只给状态位/* 通过网关以 public_adjuster 会话执行 */SELECTid_card,medicalFROMpolicy_claimWHEREclaim_no='CLM-2026-88123';-- 预期：id_card 返回 '已核验'，medical 返回定损相关摘要，无原始病历

验证方法：六条实测

库内密文验证。直连生产库抽样证件号、银行卡列，应为密文形态，非明文、非掩码。这一条证明"静态保护"成立。
角色视图验证。用每类角色会话查同一行，返回形态应严格符合授权矩阵：客服掩码、核赔完整、公估状态位。这一条证明"动态最小可见"成立。
越权拦截验证。用无权限角色（如外包坐席）尝试查病历原文、财务查完整证件号，应被拦截或返回脱敏。这一条证明策略没配漏。
FPE 查询验证。用加密后的证件号做等值查询与 LIKE 前缀查询，应能正常命中、性能在预期损耗内（网关整体 5%-10%、可承载 3 万+ QPS）。这一条证明加密没打断业务。
对外推送验证。触发一次与合作医院/公估的数据推送，抓取出站内容，应为脱敏结果；明文外发必须命中审批且有绑定。这一条证明外部合规边界。
审计与反查验证。给定某客户证件号，能反查谁在什么时间、什么角色、以什么视图查过它；给定某角色，能列出其全部查询。这一条证明证据可追溯。