引言理赔系统里最该保护、也最容易被看光的字段保险业务的核心是理赔而理赔系统的核心数据是三类高度敏感、又必须被反复查询的字段被保人证件号、理赔收款银行卡号、以及出险病历与诊断结论。这三类字段有两个共同特点恰好让它们成为数据安全的重灾区。第一它们查询频率极高。客服坐席每接一通电话要核对证件号财务每笔付款要核对银行卡核赔员每审一单要看病历。字段就在 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:****1234medical: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_claimroleNotIn:[claim_assessor,finance_pay]action:mask_result# 非授权角色查证件号返回脱敏结果-pattern:SELECT .* FROM policy_claimaction: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:2208: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_noCLM-2026-88123;-- 预期返回 SM4/FPE 密文形如 a7f3***不是 310***********1234 也不是明文-- 2. 坐席视图以 cs_agent 角色查询返回掩码/* 通过网关以 cs_agent 会话执行 */SELECTid_card,bank_cardFROMpolicy_claimWHEREclaim_noCLM-2026-88123;-- 预期id_card 显示前后四位掩码bank_card 显示后四位掩码-- 3. 公估视图以 public_adjuster 角色查询证件号只给状态位/* 通过网关以 public_adjuster 会话执行 */SELECTid_card,medicalFROMpolicy_claimWHEREclaim_noCLM-2026-88123;-- 预期id_card 返回 已核验medical 返回定损相关摘要无原始病历验证方法六条实测库内密文验证。直连生产库抽样证件号、银行卡列应为密文形态非明文、非掩码。这一条证明静态保护成立。角色视图验证。用每类角色会话查同一行返回形态应严格符合授权矩阵客服掩码、核赔完整、公估状态位。这一条证明动态最小可见成立。越权拦截验证。用无权限角色如外包坐席尝试查病历原文、财务查完整证件号应被拦截或返回脱敏。这一条证明策略没配漏。FPE 查询验证。用加密后的证件号做等值查询与 LIKE 前缀查询应能正常命中、性能在预期损耗内网关整体 5%-10%、可承载 3 万 QPS。这一条证明加密没打断业务。对外推送验证。触发一次与合作医院/公估的数据推送抓取出站内容应为脱敏结果明文外发必须命中审批且有绑定。这一条证明外部合规边界。审计与反查验证。给定某客户证件号能反查谁在什么时间、什么角色、以什么视图查过它给定某角色能列出其全部查询。这一条证明证据可追溯。风险与误区误区一把加密和脱敏当成一件事。只加密不脱敏坐席屏幕还是明文只脱敏不加密DBA 直连库照样拿全部。两者必须串联。误区二角色权限配成都能看。最小可见失效最常见的原因是上线时为省事把外包与公估也配成完整视图。必须以授权矩阵为准任何偏离告警。误区三脱敏密钥与存储密钥不分。外部拿到的脱敏结果若能用存储密钥还原等于没脱敏。两套密钥必须隔离脱敏结果外部不可还原。误区四忽略导出与打印旁路。屏幕脱敏了但坐席能导出 Excel、打印工单明文就落盘了。脱敏必须联动终端外发管控。误区五密钥散落各系统。字段密钥、文件密钥各管各的轮换与回收没有统一面密评一定卡。应归口密钥管理系统。误区六只在应用层做脱敏。应用层脱敏绕不过运维直连与文件拷贝。字段级加密网关在数据库侧兜底才覆盖全通道。证据材料清单合规检查取证用敏感字段清单字段名、所属表、密级、默认加密与脱敏策略、生效时间。角色—字段授权矩阵角色、每类字段的可见级别、制定依据、合规签字、版本与变更审批。字段加密存证抽样密文数据、加密算法说明国密 SM4/FPE、密钥由密钥管理系统集中管理与根密钥硬件保护的说明。动态脱敏命中日志含主体、角色、表、行、字段、视图形态、结果的完整记录样本可脱敏。运维 SQL 拦截记录拦截规则、触发样本、告警处理记录。对外数据交换留痕合作方、推送字段形态、审批单与绑定、有效期。双层防护说明字段级加密与透明加密的配合关系、密钥归口到密钥管理系统的架构图。六条验证的实测记录每项操作步骤、命令、结果、结论。合规映射说明与个人信息保护、病历数据使用、等保2.0、密评国密 GM/T 0051/0028条款的对应表。方案参考落地保险理赔系统的字段级加密与动态脱敏建议按下面顺序推进先盘两张表敏感字段清单字段—密级—策略与角色字段授权矩阵角色—字段—可见级别由业务、合规、安全三方签字生效这是所有策略与证据的源头。字段加密用国密 SM4 的保留格式加密FPE保住证件号、银行卡的等值与 LIKE 比对能力不让反洗钱查重、反欺诈关联这类业务中断。动态脱敏走三视图客服与外包坐席给掩码、核赔给完整、公估与外部给状态位与摘要默认掩码、白名单思维绝不默认完整。角色标识必须从可信 SSO 会话获得角色—字段映射在网关侧闭环仲裁不让应用自行声明角色防止伪造身份拿明文。外包与公估一律拿脱敏结果不准拿明文脱敏密钥与存储密钥严格隔离确保外部不可还原确需明文外发必须走审批且单绑定。脱敏必须联动终端外发管控导出、打印、接口推送都只出脱敏结果堵住屏幕脱敏后的落盘旁路。运维直连库做 SQL 级拦截与全量审计禁止非授权角色拉明文、整表导出告警要有人处理并留痕。与透明加密构成双层字段级管可见、文件级管落地即密文密钥统一归口密钥管理系统满足密评对密钥集中管理的要求。上线先影子模式跑一个完整业务周期确认无误再切真实加密核心字段先上、病历大对象交给外层透明加密。合规证据按五类归档字段加密存证、授权矩阵、脱敏命中日志、运维拦截、对外留痕并提前做内部预检再迎检。以安当DBG为例其以应用与数据库之间的透明代理实现字段级加密与动态脱敏三视图应用零改造即可让理赔系统的证件号、银行卡与病历在存储侧加密、在查询侧按角色最小可见并可与密钥管理系统对接实现密钥全生命周期治理为保险行业的个人信息保护与密评合规提供可追溯的证据链。