一种海量数据安全分类分级架构的实现

背景

随着《数据安全法》、《个人信息保护法》等相继出台，数据安全上升到国家安全层面和国家战略层面，数据分类分级已经成为了企业数据安全治理的必选题。然而数据分类分级的实现在行业内有很多痛点，主要体现在如下几点：

1. 规则制定复杂：数据进行分类有多种维度，不同维度各有价值。在不同行业及领域，甚至具体到每个企业和部门，针对不同级别数据也各有定义。维度、级别的不清晰会导致后续基于分类分级的很多合规管控存在问题。
2. 协调沟通成本高：企业规模不断庞大，组织架构也随之变得复杂臃肿。数据的扫描上报关联到多个部门和事业群，甚至子公司。这涉及到多人之间的协调沟通，还需考虑网络隔离，访问权限和审批等诸多问题。
3. 数据容量大：互联网时代到来，企业信息化建设一直高速发展中，业务系统也越来越复杂。随之产生的海量数据，给企业带来巨大的价值。相应一旦海量数据泄漏，也会给企业造成严重的后果。如何实时，高效，全面覆盖海量数据分类分级，这对技术架构是一种考验。
4. 存储组件多：互联网尤其是云计算时代，企业为了应对大流量高并发业务场景，诞生关系型，非关系型，对象存储等多种存储组件。这既有开源实现，也有企业内部自研。不同的实现，有着不同的传输协议和数据结构。要覆盖多种存储组件数据分类分级，需要大量的工作量。

然而查阅公司内外很多资料，往往只着重讲解数据分类分级概念与标准。目前并未有可借鉴，可落地的分类分级技术实现参考。因此本文重点不在于讨论数据分类分级的标准制定，而是从技术层面来讲述一种通用能力抽象封装，海量数据识别，跨部门和平台数据接入的分类分级架构实现。将数据分类分级技术进行赋能，避免重复造轮子。并以此为基础来从实际角度满足数据安全合规工作的落地和推展。

注：数据分类分级介绍参考 数据安全治理：数据分类分级指南

数据安全业务流程

业务层面

从业务层面看，以数据分类分级作为数据安全的基石，来对数据进行安全管控，比如数据加密，数据脱敏，数据水印，权限管理，安全审计等。可见数据分类分级对数据安全的重要性。

技术层面

从技术层面看，将数据扫描上报，通过数据识别引擎进行识别。然而在实际落地过程中，却发现很多问题。比如存储组件种类多，上报数据流量大，以及时效性，准确率，覆盖率等等问题。

整体架构

通过不断对数据分类分级业务分析，设计如上数据分类分级架构。架构核心由五大块组成：

1. 多种存储组件数据扫描上报工具。
2. 数据识别服务集群，统一接收上报数据，并进行数据识别。
3. 识别规则引擎，统一维护识别规则的管理，在线热更新等功能。
4. 数据中台，依托分类分级结果，进行数据安全管控。
5. 依托公司的基础框架能力，保障引擎服务的高可用，比如监控，告警，日志，弹性扩缩容等。

其中重点要处理前三点。

腾讯存储组件现状

随着云计算时代到来，腾讯内部存储组件整体趋势是上云，然而依然还有大量存量业务是使用自建平台的存储组件，以PCG为例，目前涉及到平台包括不限于如下：

从上可见，要覆盖如此众多存储组件数据分类分级扫描，存在很多问题：

凡此总总，使得提高对存储组件分类分级覆盖率上，增加很多困难以及工作量。因此需要对公司存储组件整体状况进行梳理，对同样的功能模块抽象封装，以达到同种能力的复用。

具体步骤如下：

1. 将常用的存储组件上报能力封装，比如MySQL，Redis，天穹HIVE。只需要传账号等信息，就能进行数据的扫描上报。
2. 将腾讯云账号注册能力封装，只需要简单配置，就能将云上资产实例和账号信息保存到本地。

天穹大数据扫描上报

PCG目前授权对天穹 大数据扫描覆盖3000个库，200多万张表。要达到七天扫描覆盖率99%，那么日均需扫描30万张表。

大数据计算引擎对

通过表格对比，由于SuperSQL代码维护成本低，且数据扫描场景比较简单，更看重维护性，因此选择SuperSQL。.

通过性能测试，SuperSQL单表访问平均延迟10秒左右，对于单表需要获取元数据信息和200条数据。通过100个线程访问SuperSQL，那么一天的扫描量为：

（(24 * 3600s) / (10s + 10s) ）* 100 = 432000

然后实际运行，一天扫描量在20万至30万之间。这种差距主要是：

1. 网络抖动大和计算资源负载高，造成访问延迟增大。
2. 元数据同步不及时，导致访问到已经删除的库表，造成网络超时。

其中第二点对整体扫描效率的影响比较大，因此需要优化：

1. 申请独立的计算集群，避免资源相互干扰。
2. 通过元数据中心，对库表删除状态做二次校验。
3. 增加异步定时器，监控超时的线程，进行中断处理。

注：天穹SuperSQL介绍参考 【天穹】SuperSQL跨引擎计算揭秘

腾讯云实例账号注册

实例账号注册流程

实例账号筛查流程

账号筛查需要综合处理实例的信息，其中包括：

1. UIN号码
2. 实例是否存在
3. 实例的归属部门
4. 实例是否初始化

经过账号筛查后，一个实例必定对应4种状态中的一个，4种状态的命中条件通过以下决策树表示：（初始状态下，可以将所有实例状态设定为“未注册”，通过一轮筛选和验证即可确定实例状态）

海量数据实时识别

企业规模不断庞大，海量用户，必然产生海量数据。如何满足高性能，时效性同时，又能达到高正确率和覆盖率要求，对于系统架构是一个巨大考验。

数据存储

PCG目前覆盖近二十种存储组件类型和平台，三千万张表，以mdb，cdb，tredis，天穹为例：

存储选型

从表格可见，仅mdb已超过五百万张MySQL表，而cdb甚至超过一千万张MySQL表。而一张MySQL表即对应要保存一条分类分级识别结果。MySQL单表数据建议在五百万左右，超过这个数据量建议通过分库或分表处理，这在电商项目一些场景是可行，比如交易订单数据。但这也会带来经典的分布式事务等问题。

因此需要选择一种满足大容量，高并发，高可用和事务acid的数据库。

大数据hadoop

hadoop作为经典大数据存储架构，可存储pb级别以上数据，但时效性不高，通常用作T+1离线任务olap场景。且hadoop对事务acid支持有限，无法满oltp场景。

tidb

tidb是一款分布式海量容量云原生newsql。tidb底层使用raft算法，实现数据分布式存储和保证数据一致性。同时兼容MySQL协议，支持事务。因此tidb满足要求，然而公司目前没有专门团队维护tidb。

云原生tdsql-c

tdsql-c是TEG自研的一款的数据库。tdsql-c对MySQL架构做了改进，将计算和存储分离，从而实现存储和计算资源的快速扩容。因此tdsql-c支持MySQL协议和事务，同时具备高性能等特性。且公司目前有专门团队维护tdsql-c。

存储对比

从表格可见tidb和tdsql-c满足需求，但tdsql-c有公司内部专人维护。因此选择tdsql-c来存储数据分类分级识别结果。

数据接入

服务端需要对接多种存储组件平台的数据上报，不用平台对资源，性能，时效性有不同要求。因此实现http，trpc，kafka多种接入方式，以满足不同场景。

kafka传输大数据

kafka可以实现消费端失败重试，且可以对流量进行削峰，推荐使用kafka进行数据上报。

为了保证识别结果正确，对关系型数据库单表取200条数据上传。大数据存在一些宽表或者大字段，导致上传的数据超过1M，这超过了kafka默认配置。除了限制上传数据包大小以外，也需要对kafka配置进行优化。

kafka producer

max.request.size = 1048576 （1M）

batch.size = 262144 （0.25M）

linger.ms = 0

request.timeout.ms = 30000

由于消息数据包比较大，因此不希望消息常驻producer内存，造成producer内存压力，因此让消息尽可能快速发送到broker端。

kafka consumer

fetch.max.bytes = 1048576（1M）

fetch.max.wait.ms = 1000

max.partition.fetch.bytes = 262144（0.25M）

max.poll.records = 5

topic partion >= 20

retention.ms = 2

由于消息数据包比较大，且consumer消费消息需要几百秒延迟，减少批量拉取消息数量同时提高拉取消息等待时间，避免consumer频繁去broker端拉取消息，导致consumer cpu被打爆。

优化效果

数据识别

在解决数据上报，数据存储，数据接入以后，便是数据识别。这是整个数据分类分级架构最核心也是最复杂部分。对数据识别过程主要分为数据映射，规则管理，权重计算，数据校验四大块。

数据映射

服务端对单表取200条数据进行识别，按每张表20个字段，每个字段需进行20种正则识别。每天假设跑1千万张表，一共大概要跑8千亿次正则计算。如此巨大的计算量，在流量冲击下，立马将服务端的cpu飙升到100%，从而导致服务不可用！！！

相对于io密集型，cpu密集型无法简单使用常见的缓存，异步等方式去减轻服务端压力。因此需要考虑点如下：

1. 通过云上k8s弹性扩缩容，将流量分散到多个容器节点，降低单节点负载压力。
2. 单节点利用多核并行，将计算压力分担到多个cpu核处理器上。并且使用信号量限流，避免cpu一直处于100%。
3. 正则表达式优化。 藏在正则表达式里的陷阱，竟让CPU飙升到100%！

多核并行

多核并行借鉴MapReduce编程模型，本质是一种“分而治之”的思想。

优化效果

规则管理

数据的分类分级，需更精细化的规则管理，才能对后续数据安全做到更合理的管控。规则包括不限于正则，nlp，机器学习，算法，全文匹配，模糊匹配，黑名单等。对应每种具体分类分级定义，又包括多个规则的组合使用。通过实际的运营和梳理以后，目前有近四百种分类分级定义和八百种识别规则。

因此需考虑合理的方式，将规则管理和识别逻辑解耦，以便后续的维护和升级。同时需考虑规则热更新和关闭，做到对线上服务无感知。

权重计算

数据分类分级，在不同行业和业务有不同的维度和定义。且源数据由于开发和运维人员定义不清晰，导致最终识别结果存在模糊的边界。在实际运营过程中，常会因为识别结果不准确，被业务方反馈。

假设有字段叫xid，有可能是qqid，也可能是wechatid，而qdid和wechatid对应不同的分类分级，这会影响后续的合规流程。在实际场景，xid有可能同时被qqid和wechatid识别规则命中，那么该取哪个呢？

因此引入权重的概念，权重不在于将识别结果做简单的0和1取舍，而是通过多个组合规则识别后，计算出一个权重值，并对多个识别结果的权重值进行排序，取权重最大的识别结果作为当前字段的分类分级。

数据校验

数据安全合规管控，最重要一项是数据加密。为了方便运营后续进行合规追溯，需要在服务端对当前上报数据是否加密进行校验，并将校验结果保存下来。

数据是否加密需综合判断库表状态等信息，其中包括数据是否加密，表是否删除，库是否删除，实例是否下线等。状态的转换，通过以下决策树表示：

跨部门和平台接入

在重点解决数据上报和数据识别等难点以后，数据分类分级框架已可以满足大部分业务场景。因此也希望框架能服务更多的部门需求，减少大量繁琐重复的工作量。

由于数据分类分级结果属于敏感数据，对于跨部门和平台接入，需考虑将数据根据不同部门和平台进行物理隔离存储。

总结

数据分类分级很复杂，这种复杂性有业务层面，也有架构层面。本文重点在于述说架构层面的问题。这些问题有些可以提前规划设计，比如存储选型、通用扫描能力等。也有些需要在落地过程中持续优化，比如海量数据识别，除了对服务本身性能优化，也要对资源成本综合考虑。

架构没有好坏之分，只有合适一说。本文所讲述是基于个人在落地过程遇到问题的经验总结。因此反复斟酌，认真梳理写下本文，也是对本人工作的一个阶段总结。同时也希望框架能得到更多人认可，并达到数据分类分级能力复用，为公司数据安全合规工作尽到一点小小贡献。