随着我国信息化建设的持续推进，政府、企业乃至个人对数据安全的认知与重视程度不断提升。作为数据安全防护工作的重要一环，数据脱敏技术和产品已作为常规手段，在开发测试环境构建以及数据外发共享等典型场景中被广泛普及应用。
如果单纯从“使用效果”来看，数据脱敏所要实现的不过是将用户真实数据迁移至新环境中，并对敏感数据进行变形、遮蔽等处理，达到数据“敏感性降低、标识化消除”的目的。然而，上述貌似简单明确的需求，如果没有数据安全厂商专业、复杂的技术支撑，非但无法将安全和便捷带给客户，还会在项目交付实施等环节造成一系列问题和麻烦！围绕以上问题，安华金和带您透过一系列典型数据脱敏需求，看清其背后的产品功能与技术能力差异：
差异一：敏感数据发现与“精确”敏感数据发现
针对目标环境中的敏感数据进行发现，是进行数据脱敏公认的前提。然而，对这项技术的应用除必须考察数据脱敏产品的“发现性能和准确度”外，在实际使用过程中还隐藏着对产品更多“深度能力”的要求，这些能力将决定一款数据脱敏产品能否真正适用于真实复杂的场景：
1.多种内容混合的字段脱敏
对于“由多种内容混合在一起“的字段，数据脱敏产品能否准确辨别其中每种数据的类型，同时给出类型占比以供使用者参考抉择？
以个人信息收集场景为例，其中一个典型内容就是需要有人填写“联系方式”字段。但是由于填写人员对采集需求的理解不同，导致所填写的信息可能会由手机号、座机号、地址等五花八门的“个人信息”构成。而这些信息会存储在同一列中，如果单从数据特征入手，处理不善的话很容易将此字段当做非敏感字段被忽略掉。因此，一款成熟的数据脱敏产品的发现机制，不仅要能将上述字段准确识别为敏感数据字段，还要能根据采样数据给出各类数据在此字段中的发现占比；此外，在之后的数据脱敏运算环节中，还应能够根据每行数据的真正类型，对应地产生高度仿真的数据。
2.无法判别敏感属性的字段脱敏
对于“从数据特征上无法判别敏感属性”的字段，在传统数据脱敏产品的发现逻辑中往往容易被忽略，从而导致敏感数据的泄露；其实处理得当的话，此类数据是能够进行识别的，可通过以下两种方式进行：
其一，对属于某种集合范围内、能够被枚举概括的数据，可将这些集合全部列出作为数据字典保存；当遇到这类“落到字典中”的数据时，即可以此辨别其是否为敏感数据。例如：中国的省市区划、企业和机构的行政部门、股票证券行业的上市公司代码等，均可通过此类逻辑进行敏感数据发现。
其二，对字段命名具有特征的数据，可根据字段名称特征尝试进行敏感数据发现；通过这种发现方式得出的结果虽是基于猜测，但却能缩减客户大海捞针般的工作量。例如：保存有密码的字段，单从数据内容特征上是很难辨别其敏感性的，但若根据字段的名称，却可利用一条“包含了PWD或PASSWORD等字符串的列名”作为此类数据的疑似判别依据。
差异二：数据脱敏与“高度仿真”数据脱敏
数据脱敏，看似是描述相关产品“最基础能力”的词语，但在差异化使用场景下却对其有着不同能力的要求；比如客户对脱敏后数据”仿真”质量的要求，就会随着脱敏后数据的实际使用得到验证，从而对数据脱敏产品的“高度仿真”能力提出更多、更高的要求，往往由以下几个难度层级构成：
1.内容仿真
基础的内容仿真，要求脱敏后数据从“数据类型、长度、格式、内在逻辑和语义”等特性上均与原始数据保持一致，不会对脱敏后数据的使用场景造成无法识别或产生歧义等问题。通常来说，市面上多数脱敏产品通过内置规则，可针对身份证、姓名、银行卡、手机号、地址等常见字段实现上述最基础的仿真要求。但当客户面对五花八门的使用场景时，想要实现脱敏后数据的“高度仿真”，就需要更加灵活的产品技术能力提供支撑。
例如：在某制造行业中，对于制成品的批次号需要进行脱敏，但批次号是由生产日期、车间号、流水线号和操作者相关信息共同组成的，这种行业级的数据显然已超出一般数据脱敏产品内置规则的默认范围，这时就需要安全厂商的数据脱敏产品能够对数据按位数进行切分，并基于切分的结果对各段配置脱敏规则。比如：对于日期段，可采用标准的日期脱敏规则；对于车间号、流水线号这种有范围的数据，要能基于数据字典进行脱敏；最终还要将各段组合成完整的脱敏后数据。
2.区间、比例仿真
进阶一步的数据仿真，除对内容进行仿真外，还要求脱敏后的整列数据能够满足某些特征，以避免这些脱敏后数据被分发到分析统计场景后，因为失真降低其实用性。
例如：金融行业客户需要对储户的储蓄金额进行分析，但若拿到的脱敏后数据与原始数据相差过大，将会导致统计分析结果大大失真，因而需要脱敏产品的算法能够将金额数据划分区间步长，并能以“就近随机”的方式完成脱敏；而高校客户在统计生源分布比例时，即便拿到的已是将“北京市脱敏成上海市，天津市脱敏成江西省”这样的非真实数据，也还是希望“同一省市生源数据的比例”是不变的等等。
3.关联仿真
关联仿真则是更进一步的数据仿真，要求脱敏后数据与其所在行的其他数据能够保留一定的关联关系或运算关系，例如：
当身份证号、出生日期、年龄三个字段出现在同一个表中，则天然存在“身份证中间8位数据与出生日期一致，且当前年份减去出生日期即为年龄”这一逻辑关系。在这种情况下，就要求脱敏后数据也要保持这种关联关系，否则在分发到开发测试场景后极易造成业务系统出现逻辑异常；
而在制造行业，一张表中常存在“产品单价、折扣率、实际价格”三个字段，且存在“产品单价x折扣率 = 实际价格”这一逻辑关系。在这种情况下，如果对价格数据进行脱敏，那么要求脱敏后数据仍能保留上述运算关系，这就需要脱敏产品能够通过表达式精确处理此类行业内特定的数据逻辑关系；
再以证券行业为例，同一张表内常存在“证券号码、上市地区、企业名称”等存在对应关系的数据，并且要求在对证券号码或企业名称进行脱敏后，三者的逻辑关系依然能够对应。为此，脱敏产品需要能够针对多列数据字典，实现精确且保障效率的关联仿真脱敏运算。
综上所述，想要真正做到以仿真数据满足不同行业、不同场景下的客户使用需求，并不是简单一句“数据脱敏”所能概括的，其背后对厂商产品、技术有着更多、更高的要求与考验。
差异三：脱敏运算与“高性能”脱敏运算
脱敏性能，是客户极为关注的产品指标！在一些场景下，客户需要执行“一次全量脱敏后每天增量脱敏”的数据处理逻辑，这就要求脱敏产品必须在规定时间内处理完前一天的增量数据，不然就会直接影响到脱敏目标环境中的数据一致性；而在另一些场景中，对数据脱敏的需求则处于“随用随做”的节奏，且从数据脱敏需求被发出到完成数据脱敏环境的构建，留给相关人员的时间很可能十分紧张。无论面临以上哪种场景，都对大批量数据的脱敏性能提出着新的要求与挑战。除常规提升调度合理性与算法运算效率外，还有两个关键因素也影响着数据脱敏效率的提升：
其一，是利用数据库特性完成数据抽取与入库逻辑。例如：以“数据库并行加载机制或load机制”替换“通过JDBC读写数据”，这种方式会令数据脱敏产品的开发复杂程度大幅提升，但与此同时也会带来大规模数据脱敏性能的提升。
其二，是数据脱敏产品能够提供平行扩展的集群化部署运算能力，从而通过扩展运算节点的数量，成倍扩展数据脱敏产品的运算能力。
本文中，安华金和数据安全专家通过“三大差异”对数据脱敏产品能力的“不同之处”进行了详细介绍，希望这些来自真实使用侧的实践经验与问题思考，能够为更多客户在未来进行产品选型与技术比对时提供参考和指引，让数据使用自由而安全！
