Inceptor动态数据脱敏指南：实现架构解析

友情链接：

• 【汇总】Inceptor相关使用教程及介绍
• Inceptor动态数据脱敏指南：策略管理介绍

介绍

在成功构建了数据脱敏策略后（见Inceptor动态数据脱敏指南：策略管理介绍 ），如何高效、可靠、稳定地将这些策略执行于具体的业务访问过程，就成为保护数据安全的关键技术挑战。动态数据脱敏要求在不影响业务响应效率的前提下，实现敏感信息的实时拦截与转化，这对底层架构的设计提出了苛刻要求：高性能、低延迟、高兼容性、强扩展性。

为此，Inceptor 提供两种动态脱敏架构：Gateway 模式 和 Server 模式。Gateway 模式通过独立部署的 SQL 网关接收查询请求，在返回结果时执行脱敏操作，具备良好兼容性和流量隔离能力，适合第三方关系型数据库。Server 模式则将脱敏逻辑集成于 Inceptor 服务内部，减少网络开销，适用于针对 Inceptor 存储的数据进行脱敏以及跨数据源联邦计算后的数据脱敏场景。

两种模式均可灵活配置参数与策略，确保在复杂业务环境中实现安全与效率的平衡，为企业提供稳定可靠的数据保护方案。

动态脱敏实现架构

一般地，动态脱敏功能包括2个功能组件，Defensor和SQL网关。根据SQL网关是独立服务还是复用数据源服务，分为Gateway模式和Server模式两种架构：

Gateway模式

在Gateway模式下，需独立部署并安装SQL网关服务。该架构中，Defensor负责旁路管理业务数据源的访问控制策略，并将其下发至SQL网关；SQL网关则负责接收客户端发送的查询SQL语句，将其下推至底层数据源执行，并根据预设的访问策略对返回结果进行脱敏处理，最终将处理后的结果返回给客户端。

该模式具备良好的兼容性，对业务数据源的类型无特殊要求（由SQL网关实现适配支持），且不会对业务数据源本身造成额外的性能开销和资源负担。同时，需要安全防护的业务查询流量可通过SQL网关进行管控，而无需防护的开发类流量则可直接访问数据源，从而实现两类流量的高效隔离与解耦，提升系统整体的安全性与灵活性。

示例：假设某金融机构在处理跨数据库联邦查询和复杂数据流转场景时，通过 Inceptor 对接了多种数据源（例如 Oracle），希望实施统一的数据脱敏策略，从而在数据分析、报告生成等业务活动中保护客户的敏感信息。

接下来，我们以 Oracle 数据源为例，演示如何将其作为 DBLink 连接至 Inceptor，并完成动态脱敏的规则设置。

1、登录 Transwarp Manager 平台，完成全局参数预设。

• a.在集群页面，单击 Quark 服务卡片。
• b.在配置页签，单击添加自定义参数，设置 argodb.sql.desensitize.enabled 的值为 true，配置文件为 hive-site.xml，单击确定以开启动态脱敏功能。

• c.参考上一步，选择设置下述参数：

2、连接 Inceptor 数据库，创建一个指向远程 Oracle 数据库的链接（DBLink），然后为要脱敏的表建立 DBLink 外表并与其关联，示例如下：

• a、-- 为远程的 Oracle 创建名为 dblink_oracle 的数据库链接

CREATE DATABASE LINK dblink_oracle CONNECT TO demoschema IDENTIFIED BY 'Pass123456'
USING 'jdbc:oracle:thin:@172.16.190.242:1521:xe';

• b、-- 创建并进入数据库

CREATE DATABASE demodata;
USE demodata;

• c、-- 建立 DBLink 外表，使其关联 Oracle 数据库中的 customer_transactions 表，该表随意设置一个列即可，Inceptor 会自动完成 Schema 信息同步

CREATE EXTERNAL TABLE ex_customer_transactions (
  id   string
) STORED AS DBLINK WITH DBLINK dblink_oracle tblproperties("dblink.table.name"="DEMOSCHEMA.CUSTOMER_TRANSACTIONS");

3、为列创建脱敏策略。详见 Inceptor动态数据脱敏指南：策略管理介绍。

示例一：本例对ex_customer_transactions表设置特定脱敏规则，示例如下：

拒绝所有用户访问 transaction_amount 列的数据

CREATE MASKING POLICY demo_policy3
    ON COLUMN demodata.ex_customer_transactions.transaction_amount
    USING DENY;

示例二：在上述规则的基础上，将 account_number 列的值进行部分遮掩（仅保留后四位），且该脱敏规则仅针对 dev_user 用户生效。

CREATE MASKING POLICY demo_policy4
    ON COLUMN demodata.ex_customer_transactions.account_number
    USING DESENSITIZATION WITH mask('*',0,4)
    by user dev_user;

Server模式

动态脱敏 Server 模式可用于对 Inceptor 存储的数据或跨数据源联邦计算后的数据执行脱敏，该模式下，数据的查询计算和脱敏操作均由 Inceptor 服务内部完成，无需通过外部代理或中间件，保障数据处理过程的高效性和安全性。动态脱敏Server模式，可以看作是Argodb数据库的一个功能模块。与动态脱敏Gateway模式相比，Server模式下所有的计算都是在Agrodb服务中执行的。

在Server模式下，业务数据源本身也是SQL网关，不需要另外安装部署。defensor旁路管理业务数据源的访问策略并下发到SQL网关；SQL网关接受客户端的查询SQL，按访问策略配置改写查询SQL后执行并返回脱敏后的结果给客户端。Server模式适合在对性能有要求的场景下使用，可以减少多次网络传输带来的损耗。

1、开启Server模式

• 动态脱敏开启

设置argodb.sql.desensitize.enabled为True，表示开启动态脱敏

• 设置脱敏模式

设置argodb.sql.desensitize.mode为Server，表示当前脱敏模式为Server脱敏

2、根据业务需求选择是否设置：

• a、开启udf白名单（可选）

有些需要的敏感字段（需要脱敏的COLUMN）经过一些UDF函数转换后，敏感字段的数据不再具备敏感性，比如count(敏感column)等。动态脱敏提供session级别设置UDF白名单。一但udf函数加入到白名单，被白名单里的udf处理后的敏感COLUMN，不会脱敏输出。

# session级别，默认为空
set argodb.sql.desensitize.udf.whitelist=udf1,udf2,udf3

• b、开启等值传递功能（可选）

某些等值关联查询中，比如类似select t2.a from t1 join t2 on t1.a = t2.a .... 这种sql，t1.a是敏感列，需要脱敏，那么此场景下t2.a 也可以认为具有敏感性。当需要设置join等值关联传递column的敏感性，可以设置argodb.sql.desensitize.equivalent.transfer.enabled为true，如下：

# seesion级别，默认为false
set argodb.sql.desensitize.equivalent.transfer.enabled = true

• c、写入文件的数据脱敏（可选）

如果开启该功能，类似insert overwrite local directory xxx select ....操作，写入文件的数据为脱敏后的数据

开启功能：设置argodb.file.desensitize.export.enabled为true，表示开启该功能。

3、为列创建脱敏策略。详见脱敏策略管理。

示例一：拒绝demodata数据库中customer表的所有用户访问 funds 列的数据。

CREATE MASKING POLICY demo_policy1
    ON COLUMN demodata.customer.funds
USING DENY;

示例二：如不再需要某个脱敏规则，可执行下述格式的命令将其删除。

-- 删除指定列的脱敏规则

DROP MASKING POLICY ON COLUMN demodata.customer.username; 

-- 删除指定表的所有列脱敏规则

DROP MASKING POLICY ON COLUMN demodata.customer;