数据要素流通下的“可用不可见“：安当DBG 如何支撑隐私计算与数据交易的字段级加密与可控脱敏

一、数据要素流通为什么需要"可用不可见"

数据作为生产要素，其价值只有在流通、汇聚、联合计算时才真正释放。银行要联合运营商做风控，医疗机构要联合药企做流行病学统计，政务数据要对社会力量开放用于惠民应用——这些场景的共性需求是：多方都要用这份数据，但任何一方都不应完整持有另一方的原始敏感数据。

这就是"可用不可见"的核心命题。它包含两个层次：

• 可见但不可识：数据进入计算环节时以密文或脱敏形态存在，参与方拿到的不是原始明文，但计算结果依然可用。
• 可用但不可取：数据被授权在某个受控环境内参与计算或查询，但无法被整体导出、拷贝、带走。

在隐私计算技术栈里，多方安全计算（MPC）、联邦学习（FL）、可信执行环境（TEE）解决的是"计算过程中不暴露原始数据"的问题。但有一个环节常被忽视：数据从业务库进入计算环境之前，以及在库内被日常运维、查询、交换时，如何保证字段级的安全与可控？这正是数据库加密网关（DBG）的发力点。

换句话说，隐私计算解决"算的时候不泄露"，而字段级加密与可控脱敏解决"存和查的时候不泄露"。两者是前后衔接的关系，缺了后者，隐私计算的上游数据入口仍然是敞开的。

二、数据库加密网关在"数据流通"链路中的位置

数据库加密网关（DBG）本质是部署在应用与数据库之间的透明代理。它拦在 SQL 通路上，对进出库的语句与结果集做字段级处理，而对应用完全透明——应用无需改动一行代码，无需引入新的 SDK，仍然用既有的 JDBC/ODBC 连接，只是把连接地址从直连数据库改为连接网关。这种"应用零改造加密"的特性，使得它可以在不扰动既有数据交易链路的前提下，把安全能力叠加进去。

在数据要素流通的架构里，DBG 通常出现在这样几个位置：

1. 业务库前置：生产库前面，对敏感字段做加密存储与查询脱敏，保证落盘无明文。
2. 数据交换出口：当数据要被导出给交易对手方、联合建模方时，在出口处做可控脱敏，确保送达的是"最小必要"的变形数据。
3. 运维与审计通道：所有运维人员的查库、导出动作都走网关，受 SQL 级拦截与全量审计约束，而非直连数据库，从根上压缩内部数据泄露面。

以安当DBG为例，它支持双模式运行，恰好对应数据流通里的两类现实诉求：一类是"数据必须进密文库"（透明加密网关），另一类是"库里已是明文、但出库必须受控"（运维管控网关）。下面分别展开。

2.1 透明加密网关：字段级加密存储

在透明加密网关模式下，网关对指定的敏感列做字段级加密存储。数据写入数据库时已是密文，DBA、运维、甚至拿到备份文件的人，看到的都是加密后的乱码。应用读取时由网关透明解密，业务无感知。

对数据要素流通而言，这种模式的意义在于：原始敏感数据在存储侧就实现了"不可取"。即便数据持有方要把数据库整体迁移、备份、甚至灾备到第三方环境，落地的也只是一堆密文，原始价值无法被单方窃取。

2.2 运维管控网关：明文存储 + 输出脱敏

现实里大量 legacy 系统、报表库、分析平台不便推动存储改造，数据仍以明文存在于库中。此时运维管控网关在"出库"环节发力：所有 SQL 结果返回给不同角色时做动态脱敏，高危语句（如全表导出）被直接拦截。

它解决的是"库里暂时改不动，但人不能乱看、不能乱导"的问题。在数据交易场景中，这对应"数据提供方内部仍有明文，但对外的查询与取样必须受控"。

三、字段级加密与可控脱敏：隐私计算协同中的两道防线

很多团队把"加密"和"脱敏"混为一谈，但在数据要素流通场景里，二者目标不同，必须分清：

在数据交易中，一个典型流程是：数据提供方用字段级加密保证原始数据不出密文库（不可取），再用可控脱敏在对外查询/取样时只暴露脱敏后的值（可用但受控）。两道防线叠加，才构成"可用不可见"的完整闭环。

需要强调的是，"可控"二字是脱敏方案的灵魂。普通静态脱敏往往一次性把全库变形，后续无法还原、也无法按场景差异化；而可控脱敏强调授权驱动——同一份数据，经审批的不同调用方、不同用途，得到不同粒度的可见结果。这正是数据交易里"差异化授权"的工程基础。

四、关键技术点一：FPE 保留格式加密与查询兼容

字段级加密面临一个现实矛盾：如果手机号"13800138000"被普通加密成无规律密文，业务侧基于该列做LIKE '%13800%'前缀匹配、范围查询、排序时就会失效——密文空间与明文空间完全失配，索引和查询计划都作废。

FPE（Format-Preserving Encryption，保留格式加密）解决了这个矛盾：加密结果仍保持原数据的格式与长度（手机号加密后还是 11 位数字，身份证加密后还是 18 位）。因此数据库里的索引、前缀匹配、范围查询、排序都能继续生效。这对"既要加密存储、又不能完全牺牲查询能力"的数据流通场景非常关键。

示意一段 FPE 在查询侧的行为（伪代码，说明思路）：

-- 明文库查询（无网关时）SELECTnameFROMt_userWHEREphoneLIKE'13800%';-- 命中索引，正常-- 字段级加密 + FPE 后（经网关）-- 网关把 '13800%' 用同一密钥做 FPE 前缀变换，下推到密文库-- 密文库上仍走索引范围扫描，结果回传网关再解密SELECTnameFROMt_userWHEREphone_fpeBETWEEN'FPE(13800000000)'AND'FPE(13800999999)';

需要注意，FPE 保留格式意味着密文空间与明文空间同构，低基数字段（如性别、省份、状态码）的密文可能被枚举反推。工程上对这些字段应改用哈希或令牌化，而非 FPE；只有中高基数、且需保留查询能力的标识类字段（手机号、证件号、账号）才适合 FPE。

五、关键技术点二：权限三视图与可控脱敏的分级授权

“动态脱敏"的灵魂在于权限分层。光有脱敏规则不够，必须回答"对谁脱敏、脱到什么程度、基于什么授权”。这就引出权限三视图（或称角色视图）的设计。

数据交易场景里常见的三层角色模型：

• 数据提供方管理员视图：可见明文或完整解密值，用于必要的核验与合规核对，但所有操作被审计，高危动作受审批或拦截。
• 交易对手方 / 联合计算方视图：只可见脱敏或令牌化后的值，能在"不识原值"的前提下完成核验尾号、做统计分析等任务。
• 审计 / 监管视图：给监管或审计系统的是不可逆哈希或令牌，用于留存证据链与事后核对，而不暴露原始敏感信息。

实现权限三视图依赖两点：一是网关能准确识别访问者身份与授权范围（通过连接账号、应用标识、会话上下文，或外部授权服务下发的临时令牌来判定）；二是脱敏规则能按角色与授权分支。示意性策略（伪代码）：

column_policy:-table:t_citizencolumn:id_cardstorage:fpe_sm4# 字段级加密存储，国密 SM4 保留格式roles:provider_admin:output:plaintext# 提供方管理员可看明文（受审计）counterparty:output:mask# 交易对手方看掩码 110***********1234mask_rule:"prefix3_suffix4"auth_required:true# 需持有有效授权令牌才可查询regulator:output:hash# 监管看不可逆哈希-table:t_txncolumn:amountstorage:plaintextoutput_gateway:dynamic_maskroles:counterparty:output:bucket# 仅返回区间分桶值，如 "1万-5万"

这段配置表达的是：同一张公民表，id_card走"静态加密存储 + 分角色动态输出"，且对交易对手方的可见性绑定了auth_required授权；amount走"明文存储 + 输出脱敏"，对对手方只给区间分桶。这就是数据交易中"可控脱敏"的实例化。

以安当DBG为例，上述列级策略与角色视图可以在网关控制台以"列级策略 + 角色视图 + 授权绑定"的形式落地，而应用侧因为走的是透明代理，无需改造代码即可获得字段级加密与可控脱敏能力，契合"应用零改造加密"在真实工程里的含义。

六、关键技术点三：查询审计与 SQL 级拦截

数据要素流通里，内部数据泄露的高发动作往往是一句"看起来正常"的 SQL：SELECT * FROM t_citizen、mysqldump整库导出、把结果集导出到本地文件再带走。DBG 的运维管控能力要在 SQL 层面做两件事：拦截与审计。

6.1 SQL 级拦截

网关可基于规则识别并阻断高危语句，例如：

• 无 WHERE 条件的敏感表全表查询。
• 涉及敏感列的批量导出、超阈值返回（如单次返回超过设定行数）。
• 非白名单来源、非授权时段的运维连接。
• 未携带有效授权令牌却尝试查询受控列的请求。

示意性拦截逻辑（伪代码）：

-- 运维管控网关拦截示例（伪逻辑）IFstatement.tableIN(受控表清单)ANDstatement.auth_tokenISNULLANDstatement.request_role='counterparty'THENaction='BLOCK'audit_note='交易对手方未持授权令牌查询受控列，已拦截'

6.2 全量审计

所有经过网关的 SQL、访问者身份、命中的加密/脱敏策略、返回行数、是否拦截，都要落审计日志。审计日志本身应防篡改（写入独立存储或带签名），并保留足够时长以满足合规举证。审计的价值不止事后追责，更是合规检查时证明"你确实对敏感访问做了管控"的证据链。

七、与隐私计算的协同：网关守入口，MPC/FL 守过程

回到"可用不可见"的全链路。一个完整的隐私计算 + 数据交易方案，通常是这样的分层：

1. 入库层：DBG 透明加密网关对原始敏感字段做字段级加密存储，保证库里无明文（数据不可取）。
2. 出口层：DBG 运维管控网关对对外查询/取样做可控脱敏，按授权返回脱敏或令牌化结果（数据可用但受控）。
3. 计算层：需要跨域联合计算时，原始数据在密文或脱敏态下进入多方安全计算 / 联邦学习 / 可信执行环境，计算过程不还原明文（计算过程不暴露）。
4. 监管层：全程查询审计 + 密钥托管记录，形成可举证的证据链。

可以看到，DBG 并不替代隐私计算，而是补齐了它"数据落地与日常查询"这一段的安全。没有 DBG，隐私计算拿到的上游数据仍然可能是明文裸库导出的，整个"可用不可见"链条在源头就断了。

八、密钥管理：由 KSP 托管，与数据分离

字段级加密的密钥绝不应散落在应用或网关本地文件里，而应由独立的密钥管理服务（KSP）统一托管：密钥的生成、分发、轮换、销毁都在 KSP 完成，网关只持有"使用密钥的权限"而非密钥本身。这样既符合"密钥与数据分离"的安全原则，也便于做密钥轮换的合规举证。

在数据交易场景里，密钥托管还带来一个额外好处：授权可随密钥策略而动。例如某笔数据交易到期，可以通过 KSP 撤销对应网关实例的使用权限或轮换密钥，使历史密文在新授权下不可解密，实现"授权到期即失效"的闭环控制。

九、与 TDE 的双层配合：管"盘"与管"字段"

不少团队已给数据库开了TDE（透明数据加密），用来加密数据文件和备份。那 DBG 的字段级加密是否多余？并非如此，二者解决不同层面的问题，可以双层配合：

• TDE加密"静态文件层"：数据库文件、日志、备份在磁盘上是密文，防止存储介质丢失泄露。但它对有权限连库的人是透明的——DBA、运维、应用账号看到的仍是明文，防不住内部越权访问与运维导出。
• DBG 字段级加密加密"字段内容层"：即使连上库、即使绕过文件层，敏感字段本身也是密文；同时 DBG 还能做动态脱敏与 SQL 拦截。

合理组合是：TDE 管"盘"，DBG 管"字段 + 输出 + 权限"。TDE 解决存储文件泄露，DBG 解决内部数据泄露与细粒度权限。两者叠加，防护更完整，且互不冲突。

十、性能：3 万 QPS 与 5%–10% 损耗的工程现实

任何在 SQL 通路上做加解密和脱敏的方案，都必须回答性能问题。DBG 类网关的损耗主要来自：加解密计算、协议解析与结果集改写、策略匹配、审计写入。在合理部署（网关就近部署、连接池复用、策略预编译）前提下，工程上常见的损耗区间在5%–10%左右，单网关可支撑3 万以上 QPS的吞吐。

数据交易场景下的几个性能要点：

• 损耗与"被处理的字段比例"强相关。只把真正敏感的少数几列纳入加解密，比"全库全列加密"损耗小得多——这也是列级策略的意义：只对敏感列付费。
• FPE 因保留格式，索引和查询计划基本不受影响，避免了"一加密就全表扫描"的灾难，对需要按标识检索的交易查询尤其重要。
• 网关须做横向扩展与高可用，避免成为单点。通常建议网关集群 + 健康检查，应用连接网关的虚拟入口而非单实例。

简化的损耗测算表，供容量规划参考：

十一、数据库矩阵与远程接入运维

DBG 要真正落地，必须兼容组织实际在用的各种数据库。常见的数据库矩阵包括 MySQL、PostgreSQL、SQL Server、Oracle，以及信创体系下的达梦、人大金仓等。网关需要针对每种数据库的协议、类型系统、函数做适配，确保字段级加密与脱敏在不同引擎上行为一致。

对于分布式或多租户环境，网关通常通过"逻辑库/实例"维度做策略隔离，再下钻到表、列。运维人员通过远程接入方式登录运维管控网关进行日常查询时，所有操作都受脱敏与审计约束，而不是直接连库。这样即使运维在远端操作，数据暴露面也被压缩在网关的策略边界内。

十二、合规举证：把"做了防护"变成"能证明做了防护"

数据交易与隐私计算相关的合规评估，不只看是否部署了工具，更看能否举证。DBG 场景下，举证材料通常包含：

1. 策略清单：哪些表、哪些列、走了哪种存储与脱敏策略，对应哪类角色与授权。这是"可控脱敏"的书面证据。
2. 角色与授权映射：三视图各自的可见范围与授权前提，证明"最小权限"与"差异化授权"被落实。
3. 审计日志样本：包含被拦截的高危语句、被脱敏的查询记录、授权校验失败的请求，证明管控真实生效而非摆设。
4. 密钥管理记录：密钥由 KSP 托管、轮换周期、访问审批、授权到期处置，证明密钥生命周期可控。
5. 损耗与可用性报告：证明安全方案没有把业务拖垮，5%–10% 的损耗在可接受区间，3 万 QPS 满足流通需求。

把上述内容整理成定期报告，配合日志导出，就能在合规审查时形成完整证据链。这里的关键词"数据库防泄露""脱敏方案"对应的，正是这类从技术到管理的闭环。

十三、数据交易场景的落地参考模型

把前面所有点串起来，一个可落地的"数据流通可用不可见"参考模型如下：

1. 盘点与分级：先做数据分类分级，确定哪些列是 PII、哪些是机密、哪些可对外交易，落到列级清单。
2. 定模式：高敏感且需检索的列（手机号、证件号）走 FPE 字段级加密存储；历史明文列走输出脱敏；两者在同库并存。
3. 定授权：定义提供方管理员、交易对手方、监管三类视图及各自可见形态，并把可见性绑定到授权令牌。
4. 定拦截规则：把全表查询、超阈值导出、无授权查询受控列等列进 SQL 拦截。
5. 接审计与密钥：全量审计落独立存储，密钥托管到 KSP，授权到期可撤销。
6. 测损耗：灰度验证 5%–10% 损耗与 3 万 QPS 目标，确认业务无感。
7. 出举证：定期生成策略清单、审计样本、密钥与授权记录，形成合规材料。
8. 接隐私计算：上游数据以密文/脱敏态进入联合计算，网关守入口、MPC/FL 守过程，闭环"可用不可见"。

方案参考

以下为数据要素流通场景下的通用落地建议，供不同技术栈团队参考，不局限于特定产品：

• 先分级再流通：没有明确字段清单的脱敏与加密是盲目的。建议先完成数据资产盘点与分类分级，明确 PII 与可交易列，再定义列级策略与授权边界。
• 静态与动态互补而非互斥：能用字段级加密存储的优先加密（库里无明文、不可取），不能改存储的老系统用动态脱敏兜底（输出层受控、可用但受控）。同库双层组合比单一手段更稳。
• 低基数字段慎用保留格式加密：性别、省份等枚举值少的字段，FPE 密文空间小，应配合令牌化或哈希，避免被反推。
• 可控脱敏要绑定授权：脱敏规则必须按角色与授权分支，"谁、凭什么授权、能看到什么"要可核查，否则脱敏只对外部有效、对交易对手方仍可能过度暴露。
• 拦截与审计并重：只审计不拦截，泄露已经发生；只拦截不审计，事后无法举证。两者结合才能既防住又说得清。
• 隐私计算与上游客门协同：MPC/FL/TEE 解决计算过程不暴露，但数据落地与日常查询的安全要靠字段级加密与可控脱敏补齐。二者前后衔接，缺一则"可用不可见"在源头断裂。
• 密钥独立托管：加密密钥应交由独立密钥管理服务托管，与网关、数据库分离，并定期轮换、支持授权到期撤销，便于合规举证。
• 性能要实测而非估算：上线前用真实业务 SQL 做灰度压测，确认损耗落在 5%–10%、吞吐满足流通需求，避免安全把业务拖垮。
• TDE 与字段级加密叠加：若已启用 TDE，保留它管存储文件层，再叠加字段级加密管内容层与权限层，形成双层防护。
• 举证材料常态化：把策略清单、角色与授权映射、审计样本、密钥与授权记录做成定期自动产出的报告，合规审查时直接可用。