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