在前面文章中介绍过“9.6.1 数据加解密接口”，本篇我们介绍第9章 安全管理源码解析中“9.6.2 数据动态脱敏”的相关精彩内容介绍。
数据脱敏，顾名思义就是将敏感数据通过变形、屏蔽等方式处理，其目的是保护隐私数据信息，防止数据泄露和恶意窥探。当企业或者机构收集用户个人身份数据、手机、银行卡号等敏感信息，然后将数据通过导出（非生产环境）或直接查询（结合生产环境）的方式投入使用时，按照隐私保护相关法律法规需将数据进行“脱敏”处理。
openGauss实现了数据动态脱敏机制，它根据一系列用户配置的“脱敏策略”来对查询命令进行分析匹配，最终将敏感数据屏蔽并返回。使用数据动态脱敏特性总的来说分为两个步骤：配置脱敏策略、触发脱敏策略。本小节将对这两个步骤进行具体分析。
显然只有在配置脱敏策略后系统才能有根据地进行敏感数据脱敏。openGauss提供了脱敏策略配置（创建、修改、删除）语法，这些语法所涉及的语法解析节点内容大致相同，因此这里仅对创建策略相关数据结构进行分析，其余不再赘述。下面将结合一个具体示例对数据动态脱敏特性进行详细介绍。
表9-6给出了一张包含敏感信息（薪资、银行卡号）的个人信息表，策略管理员要对该表中的敏感信息创建脱敏策略：当用户user1或user2在IP地址10.123.123.123上使用JDBC或gsql连接数据库并查询个人信息表时，系统将自动屏蔽敏感信息。

表9-6 个人信息表person

首先策略管理员需要对敏感列打标签，随后使用标签创建脱敏策略，策略配置DDL语句如下。
例9-1脱敏策略配置示例。
配置资源标签：
（1） CREATE RESOURCE LABEL salary_label ADD COLUMN(person.salary);
（2） CREATE RESOURCE LABEL creditcard_label ADD COLUMN(person.creditcards);
配置脱敏策略：
（3） CREATE MASKING POLICY mask_person_policy MASKALL ON LABEL(salary_label), CREDITCARDMASKING ON label(creditcard_label) FILTER ON ROLES(user1,user2), IP(‘10.123.123.123’), APP(jdbc, gsql);
user1在10.123.123.123地址使用gsql查询敏感数据：
（4） SELECT id, salary, creditcards FROM public.person;
下面将对“CREATE MASKING POLICY”语句所涉及的语法结构定义进行逐一介绍。
数据结构CreateMaskingPolicyStmt代码如下：

typedef struct CreateMaskingPolicyStmt
{
NodeTag     type;
char        *policy_name;    /*  脱敏策略名称  */
List        *policy_data;    /*  脱敏策略行为  */
List        *policy_filters; /*  用户过滤条件  */
bool        policy_enabled;  /*  策略开关  */
} CreateMaskingPolicyStmt;

脱敏策略创建语法是对CreateMaskingPolicyStmt函数进行填充，其中policy_data是由若干DefElem节点组成的List，每个DefElem指出了以何种方式脱敏数据库资源，DefElem->name标识脱敏方法，DefElem->arg代表脱敏对象。
“9.6.2 数据动态脱敏”小节中例9-1脱敏策略配置示例的步骤0对应的policy_data组织结构如图9-31所示。

图9-31 脱敏策略配置示例对应的policy_data组织结构

policy_filters属性通过二叉逻辑树的形式描述了哪些用户场景（用户名、客户端、登录IP）可以使脱敏策略生效，policy_filters指向了逻辑树的根节点，只有当用户信息与逻辑树匹配时（匹配方式详见图9-35），脱敏策略才会被触发。逻辑树节点结构如下所示：

typedef struct PolicyFilterNode
{
NodeTag     type;
char        *node_type;  /*  逻辑操作类型，取值为“op”或“filter”  */
char        *op_value;   /*  逻辑操作符，仅当node_type为op时取值为“and”或“or”，否则为NULL  */
char        *filter_type;/*  过滤数据类型，仅当node_type为filter时取值为“APP”、“ROLES”、“IP”  */
List        *values;     /*  过滤数据值List，指出具体的过滤条件值，若node_type为op时置NULL  */
Node        *left;       /*  左子树  */
Node        *right;      /*  右子树  */
} PolicyFilterNode;

逻辑树节点分为操作符(op)节点和过滤数据(filter)节点。当op节点分为“与”或“或”关系，其op_value将置为“and”或“or”，其左右子树代表操作符左右子表达式。filter节点一般作为op的叶子节点出现，它标识具体的过滤信息并将其值存放在values链表中。需要注意的是，一个节点不可能既是op节点又是filter节点。“9.6.2 数据动态脱敏”小节中例9-1脱敏策略配置示例的步骤0对应的policy_filters组织结构如图9-32所示。

图9-32 配置脱敏策略对应的policy_filters 组织结构

脱敏策略配置的总体流程如图9-33所示。

图9-33 脱敏策略配置流程图

在查询编译脱敏策略配置SQL之后将进入策略增删改主函数中，首先会根据语法解析节点校验相关参数的合法性，做如下检查：
（1） 检查脱敏策略指定的数据库资源是否存在。
（2） 检查脱敏函数是否存在。
（3） 检查脱敏策略是否已存在。
（4） 检查脱敏相关约束：脱敏对象必须为基本表的数据列、脱敏列类型必须满足规格限制、脱敏列只允许加载一个脱敏函数。
（5） 检查Masking Filter是否冲突，不允许同一数据库资源在相同用户场景下触发多个策略。
其中Masking Filter冲突校验的目的是防止用户场景同时满足多个脱敏策略限制，导致策略匹配时系统无法判断应该触发哪种脱敏策略。因此在创建策略时要保证其过滤条件与现存的策略互斥，主要是判断是否存在一种用户场景能够同时满足多个MASKING FILTER。在“9.6.2 数据动态脱敏”小节所示的表9-6数据基础上，如下表中策略A和策略B是相互冲突的，而策略A和策略C是互斥的。
脱敏策略冲突或互斥场景如下所示：

策略A：CREATE MASKING POLICY mask_A MASKALL ON LABEL(creditcard_label) FILTER ON IP(’10.123.123.123’), APP(jdbc), ROLES(user1);
策略B：CREATE MASKING POLICY mask_B CREDITCARDMASKING ON LABEL(creditcard_label) FILTER ON IP(’10.123.123.123’,’10.90.132.132’), APP(jdbc, gsql), ROLES(user1);
策略C：CREATE MASKING POLICY mask_C CREDITCARDMASKING ON LABEL(creditcard_label) FILTER ON IP(’10.123.123.123’ ,’10.90.132.132’), APP(jdbc), ROLES(user2);

随后将依据策略配置信息更新系统表：
（1） 更新gs_masking_policy系统表，存储policy基本信息。
（2） 更新gs_masking_policy_actions系统表，存储策略对应的脱敏方式及脱敏对象。
（3） 更新gs_masking_policy_filter系统表，存储脱敏用户场景过滤信息。此时会将逻辑树转换为逻辑表达式字符串进行存储，在之后的敏感数据访问时该字符串将会重新转换为逻辑树进行场景校验。
为了降低策略读取I/O损耗，openGauss维护了一组线程级别的策略缓存，用于保存已配置的脱敏策略，并在策略配置后进行实时刷新。
在用户进行数据查询时，数据动态脱敏特性使用openGauss的HOOK机制，将查询编译生成的查询树钩取出来与脱敏策略进行匹配，最后将查询树按照脱敏策略内容改写成不包含敏感数据的“脱敏”查询树返还给解析层继续执行，最终实现屏蔽敏感数据的能力。其执行流程如图9-34所示。

图9-34 脱敏策略执行流程图

在对一个访问数据库资源的查询树进行脱敏之前，需要准备一份待匹配的脱敏策略集合，其依据就是用户登录信息，check_masking_policy_filter函数的任务就是将用户信息与所有的脱敏策略进行匹配，筛选出可能被查询触发的脱敏策略。最终筛选如下脱敏策略。
（1） 若脱敏策略没有配置过滤条件信息，说明对所有用户生效。
（2） 若当前用户信息与脱敏策略的过滤条件匹配，则说明对当前用户生效。
在每个脱敏策略从系统表读入缓存时，需要将对应的过滤条件逻辑表达式转换为逻辑树并将逻辑树根节点存入缓存中，将其作为脱敏策略筛选条件。逻辑树结构代码如下：

class PolicyLogicalTree {
public:
    …
    bool parse_logical_expression(const gs_stl::gs_string logical_expr_str);   /*  逻辑表达式构造逻辑树入口函数  */
    bool match(const FilterData *filter_item);
    bool has_intersect(PolicyLogicalTree *arg);
private:
    gs_stl::gs_vector<PolicyLogicalNode> m_nodes;  /*  逻辑节点集合，包含了逻辑树中所有的节点  */
    gs_stl::gs_vector<int> m_flat_tree;   /*  利用数组将逻辑节点索引构造逻辑二叉树  */
    /*  逻辑表达式转换为逻辑树的递归函数  */
bool parse_logical_expression_impl(const gs_stl::gs_string logical_expr_str, int *offset, int *idx, Edirection direction); 
    inline void create_node(int *idx, EnodeType type, bool has_operator_not); /*  创建单个逻辑树节点  */
    void flatten_tree();  /*  将逻辑树刷新到m_nodes集合与m_flat_tree索引中  */
    bool check_apps_intersect(string_sort_vector*, string_sort_vector*);
    bool check_roles_intersect(oid_sort_vector*, oid_sort_vector*);
    bool m_has_ip;    /*  标识整个逻辑树是否涉及ip校验  */
    bool m_has_role;  /*  标识整个逻辑树是否涉及用户名校验  */
    bool m_has_app;   /*  标识整个逻辑树是否涉及客户端校验  */
};

逻辑树节点的结构与语法解析中的FILTER节点类似，具体可以参照PolicyFilterNode结构。相关代码如下：

struct PolicyLogicalNode {
    ...
EnodeType m_type;
int m_left;                /*  左子节点索引  */
int m_right;               /*  右子节点索引  */
void make_eval(const FilterData *filter_item); /* 判断用户信息是否满足本节点子树表示的逻辑。  */
bool m_eval_res;
oid_sort_vector m_roles;   /*  本节点包含的用户名集合  */
string_sort_vector m_apps; /*  本节点包含的客户端名称集合  */
IPRange m_ip_range;        /* 本节点包含的IP  */
};

当需要将逻辑表达式转变为逻辑树时，parse_logical_expression_impl函数将对逻辑表达式字符串进行递归解析，识别出表达式包含的操作符（and或or）以及过滤条件信息（ip、roles、app）,构造出PolicyLogicalNode并使用左右子节点索引（m_left、m_right）链接起来形成逻辑树并将每个节点存入m_nodes中，最终利用m_nodes构造m_flat_tree数组来模拟二叉树。
m_flat_tree数组的作用是标记逻辑树节点间关系以及标识哪些节点是逻辑树的叶子节点。当用户信息与逻辑树某节点进行匹配时，首先需要与其左右子树进行匹配，然后根据该节点的逻辑运算符来判断是否满足过滤条件要求，而左右子树的判断结果又依赖于它们的子树的结果，因此这种递归判断方法首先将会是取叶子节点进行用户信息匹配。
openGauss使用“自底向上”的方式来进行用于信息与逻辑树的匹配。从m_flat_tree末尾（叶子节点）进行匹配，将匹配结果记录下来，当匹配到非叶子节点时（op节点）只需使用其左右子节点结果进行判断即可，最终实现整个逻辑树的匹配。在例9-1脱敏策略配置示例中创建脱敏策略后，当用户使用非受限的客户端访问敏感数据时，逻辑树匹配结果如图9-35所示。

图9-35 逻辑树匹配示例

在筛选出脱敏策略后，就需要对查询树所有TargetEntry进行识别和策略匹配。从openGauss源码可以看到，脱敏策略支持对SubLink、Aggref、OpExpr、RelabelType、FuncExpr、CoerceViaIO、Var类型的节点进行解析识别。数据脱敏的核心思路是：Var类型节点代表了访问的数据库资源，而非Var类型节点可能包含Var节点；因此需要根据其参数递归的寻找Var节点，最后将识别到的所有Var节点进行策略匹配并根据策略内容进行节点替换。
识别脱敏节点源码如下：

static bool mask_expr_node(ParseState *pstate, Expr*& expr,
    const policy_set *policy_ids, masking_result *result, List* rtable, bool can_mask)
{
    if (expr == NULL) {
        return false;
    }
    switch (nodeTag(expr)) {
        case T_SubLink:
            ... /*  解析SubLink节点  */
        case T_FuncExpr:
            ... /*  解析FuncExpr节点  */
        case T_Var:
            return handle_masking_node(pstate, expr, policy_ids, result, rtable, can_mask); /*  进入最后脱敏处理过程  */
        break;
        case T_RelabelType:
            ... /*  解析RelabelType节点  */
        case T_CoerceViaIO:
            ... /*  解析CoerceViaIO节点  */
        case T_Aggref:
            ... /*  解析Aggref节点  */
        case T_OpExpr:
            ... /*  解析OpExpr节点  */
        default:
            break;
    }
    return false;
}

在匹配脱敏策略时，首先需要将识别出的Var节点进行解析，将其转为PolicyLabelItem，该数据结构存储了数据列的全部路径信息，然后将其与已过滤出的脱敏策略集合进行匹配；若某个脱敏策略对应的数据库资源对象与PolicyLabelItem一致，将已匹配到的脱敏策略指定的方式替换该Var节点。相关数据结构PolicyLabelItem的代码如下：

struct PolicyLabelItem {
    ...
    void get_fqdn_value(gs_stl::gs_string *value) const;

    bool operator < (const PolicyLabelItem& arg) const;
    bool operator == (const PolicyLabelItem& arg) const;
    bool empty() const {return strlen(m_column) == 0;}
    void set_object(const char *obj, int obj_type = 0);
    void set_object(Oid objid, int obj_type = 0);
    Oid            m_schema;     /*  数据库资源所属的namespace OID  */
    Oid            m_object;     /*  数据库资源所属的table OID  */
    char           m_column[256];/*  列名
    int            m_obj_type;   /*  资源类型，数据动态脱敏仅支持对column生效  */
};

脱敏策略匹配成功后，将会根据策略内容替换包含敏感信息的Var节点，使之外嵌脱敏函数。最后将修改后的查询树返还给解析器继续执行，最终敏感数据将会在脱敏函数的作用下以脱敏的形式返回给客户端。“9.6.2 数据动态脱敏”小节中例9-1脱敏策略配置示例步骤(4)中，当SELECT语句触发脱敏策略时，查询树被替换前后的数据结构如图9-36所示。

图9-36 查询树脱敏前后的数据结构示例

至此整个查询树已经完成了脱敏策略的匹配与重写，随后将重新回归查询解析模块并继续执行后续处理，最终系统将返回脱敏后的数据结果。