导语：本文将站在工程的视角，结合一些的思考和经验，从整体的大框架上介绍数据分类分级产品敏感数据识别技术方案和能力，希望对大家有所帮助。
背景
虽然整体上大家做分类分级的背景以及目标基本一致：满足监管要求；为数据合规和安全体系建设打好基础。但是实施落地的过程不尽相同，每个客户所处的行业不同，所要遵循的分类分级标准不同，同时每个客户的数据也是截然不同，定制化需求是普遍存在。
当前一些业务模式相对简单的公司，使用excel的方式人工进行数据分类分级；规模更大业务更复杂的公司自研或采购第三方数据分类分级产品或服务。市场上大部分供应商采取产品+服务的方式服务客户，其中产品敏感识别能力较弱更多以运营功能为主，敏感数据识别更多的以人力服务的方式帮助客户进行梳理，虽然能满足监管要求，但是存在以下公认的问题：
· 无法做到持续运营，交付的产物是基于当时的数据情况，后续新增数据要么需要人介入重新进行梳理，要么无法保证能够持续准确识别
· 准确率低或不稳定，特别是在数据元信息质量较低的情况
· 人力投入成本高
仅满足监管要求不是我们的终极目标，我们希望用九智汇分类分级产品在满足监管的前提下，为数据合规和数据安全打下坚实的基础，所以我们：
· 采集样本数据，走样本数据为主、元数据为辅的技术路线，一方面可以保证已建设的识别能力可持续识别，另一方面准确率稳定性不受元数据质量影响
·提供智能化、 无侵人、开箱即用的同时，打造易用、灵活、强大的自定义功能，满足客户的定制化需求，一方面降低交付成本，另一方面降低门槛让客户可以自助使用产品进行敏感数据识别。
实践方案
如果没有系统或产品，纯人工来做数据分类分级，基本上大家完成这件事情的步骤都是：找数据在哪里->梳理数据有哪些->找敏感数据->归类->分级。同理，我们的产品也遵循这个思路，设计了一套标准的敏感数据识别流程，如下图：
在这个流程中，每个节点我们代码层面的设计和实现都遵循可配置的原则，可以根据客户环境、现状和需求等情况调整配置进行适配。另外，尽可能的支持客户自定义，比如在“敏感数据识别”、“自动分类”、“自动审核”等节点我们都添加了易用的自定义功能，方便满足客户的定制化需求。
数据源扫描
负责数据分类分级落地，碰到的首要问题肯定是：我们有哪些数据，这些数据在哪里，是否有遗漏的数据未找到？为此我们研发了数据源扫描器来帮助发现数据源，尽可能的帮助客户自动发现数据源，尽可能的不遗漏数据源，该扫描器目前具备以下两种能力：
· 部署到指定网络环境内，扫描和探测网络环境内可能是数据存储的目标，比如可以通过扫描一些常用端口来发现关系数据库
· 按照要求给云账号的AK配置权限后，可以通过该AK拉取云账号的所有数据存储资源列表
数据源集成
当然除了上面提到的自动扫描，也可以通过输入endpoint手动添加数据源。自动扫描发现或手动添加的数据源，一般情况下是需要鉴权才能访问，这就需要我们找到对应负责人提供账号密码连接到数据源。产品特别提供了一个密钥对管理功能来来解决安全问题：
· 加密存储鉴权信息（如账号密码），提升安全性；
· 连接数据源无需直接输入鉴权信息，选择已经维护好的密钥对即可，有效减少接触到明文鉴权信息的人员，降低泄漏风险。
另外产品交付过程中，实际上每个客户的数据源类型不一样，同种类型的数据源也会有不同版本，为此我们在数据源集成这里采用插件的设计，插件之间、插件和应用之间隔离运行，以帮助我们解决以下问题：
· 同种类型的数据源，支持不同版本，避免不同版本连接驱动之间依赖冲突问题
· 应用无需直接依赖数据源驱动，避免大量数据源驱动依赖带来的各种冲突问题
· 满足客户数据源集成的定制化需求，不侵入应用代码
目前我们已经支持以下类型数据源：
· 关系数据库：MySQL、ORACLE、SQLServer、达梦数据库、IBM DB2、MariaDB、PostgreSQL等
· 大数据平台：Hive、Maxcompute、ClickHouse、Hbase
· 文件存储：阿里云OSS、腾讯云COS、华为云OBS、AWS S3、Ceph、Minio
· 文档平台：语雀
元数据同步
在数据源连接成功之后，如果要搞清楚到底哪些数据，我们就需要读取数据源内部的结构比如表、字段、文件夹、文件的元信息，这些元信息主要有以下作用：
· 为抽样提供参考依据，比如可以根据表的数据量采取不同的抽样方法，保证样本的随机性，以及降低对数据源的性能和稳定性影响
· 为敏感数据识别提供上下文，帮助进一步确定敏感数据类型，比如根据抽样数据我能确定该字段是姓名，但是如果有字段备注、字段名称、表名、表备注信息以及同表其他字段信息，就有可能进一步确定该字段是否是法人姓名
另外，稍微量级大一点的业务就会涉及分库分表，这也是在元数据同步要解决的问题，需要将分库分表的库、表进行合并，抽样的时候也需要考虑去不同的库、不同的的表进行抽样。
数据抽样
数据抽样是一个体力活，也是一个技术活。说是体力活是因为每一种数据源类型甚至每一个类型的数据源版本可能抽样方法都不一样，需要单独做技术实现。说是技术活是因为无论是哪一种数据源类型，不仅要考虑能否抽到数据，还要保证：
· 抽样数据的随机性和数量，只有这样才能保证识别准确率
· 抽样对数据源的性能和稳定性影响必须要做到最小，即使连接的备库，每个客户都非常在意这一点，如果在这一点无法取得客户信任，项目就非常难往前推进
即使解决了上面两个最重要的问题，还有保证抽样性能和稳定性，你可能会遇到以下问题：
· 大数据平台（如Hive）抽样如果在保证样本随机性的情况下，不触发MR任务
· 上百亿的大表，如何进行抽样才能保证样本随机性、性能
· 大字段，单次抽太多肯定会引发IO问题，如何进行分批抽样
· 同步抽样肯定会存在超时问题，异步化或回调，哪种方式更好
识别敏感数据
敏感数据识别是整个流程中最核心的一个环节，也是算法同学发挥的舞台，首先是要把算法能力集成好，算法需要使用的能力涉及到：
· 正则，由于会有大量的正则匹配，Java自带的正则能力是无法满足性能要求的，需要使用RE2或HyperScan
· PMML，机器学习模型
· ONNX，深度学习模型
· NVIDIA Triton Server，推理服务，主要用于非结构化数据识别
由于每个客户所处的行业不一样，业务数据更是截然不同，为根据客户的数据现状实现更好识别效果以及满足客户的定制化需求，我们支持了可自助配置、训练的敏感数据识别能力：
· 基与YAML格式标准化的识别逻辑配置能力，可自助研发识别能力并录入到产品中
· 自助配置规则树，基于规则树进行敏感数据识别
· 自助模型训练，目前已支持ID类型的结构化数据，图片、文档
自动分类
一般情况下，识别出某种类型敏感数据之后，就能根据映射关系映射到唯一的分类下，并映射到对应的分级，但是某些行业要求更高，比如证券行业，根据证券行业分类分级标准，同种类型的敏感数据可能需要再分类放到不同分类下，如要区分“姓名”是“个人投资者信息”还是“机构投资者法人信息”，这就需要我们在识别出某个字段是“姓名”之后进一步分类，这个时候我们可以根据以下信息进行分类：
· 元信息，如字段名称、字段备注、表名称、表备注等
· 同表其他字段命中的敏感数据类型，比如如果同表其他字段有公司名称，那该字段属于“法人”的概率就更高
同时，分类的识别逻辑也基于YAML格式进行了标准化，可自助研发识别能力并录入到产品中。
自动审核
机器自动识别，大家非常关注的就是准确率，很难做到100%准确，所以我们设置了一个置信度的概念，用来表示识别准确率。除了准确率，每个客户的肯定有一些自己的特殊情况，比如说某个客户每张表都有5个无任何业务含义的“id”、“gmt_create”、“gmt_modified”、“creator”、“modifier”、“is_deleted”字段，其中“creator”、“modifier”虽然是填的姓名，但是并不是敏感数据。为解决这类跟客户数据现状相关的特殊情况，我们特别提供了自定义规则能力，规则可以根据以下特征自动决策是否通过审核：
· 命中的敏感数据类型，以及对应置信度
· 字段/文件的元信息，如文件名称、字段名称、字段备注等
· 字段/文件历史人工审核结果
如若转载，请注明原文地址
