一种海量数据安全分类分级架构的实现！
发布时间：2023-01-05 10:52:29 所属栏目：大数据 来源：
导读： 本文主要总结个人在数据安全分类落地过程遇到问题的经验，希望本文能对此方面感兴趣的开发者们提供一些经验和帮助。
背景
随着《数据安全法》、《个人信息保护法》等相继出台，数据安全上升到国
背景
随着《数据安全法》、《个人信息保护法》等相继出台，数据安全上升到国
|
本文主要总结个人在数据安全分类落地过程遇到问题的经验，希望本文能对此方面感兴趣的开发者们提供一些经验和帮助。 背景 随着《数据安全法》、《个人信息保护法》等相继出台，数据安全上升到国家安全层面和国家战略层面，数据分类分级已经成为了企业数据安全治理的必选题。然而数据分类分级的实现在行业内有很多痛点，主要体现在如下几点： 然而查阅公司内外很多资料，往往只着重讲解数据分类分级概念与标准。目前并未有可借鉴，可落地的分类分级技术实现参考。因此本文重点不在于讨论数据分类分级的标准制定，而是从技术层面来讲述一种通用能力抽象封装，海量数据识别，跨部门和平台数据接入的分类分级架构实现。将数据分类分级技术进行赋能，避免重复造轮子。并以此为基础来从实际角度满足数据安全合规工作的落地和推展。 注：数据分类分级介绍参考数据安全治理：数据分类分级指南。 数据安全业务流程 （一）业务层面 从业务层面看，以数据分类分级作为数据安全的基石，来对数据进行安全管控，比如数据加密，数据脱敏，数据水印，权限管理，安全审计等。可见数据分类分级对数据安全的重要性。 （二）技术层面 从技术层面看，将数据扫描上报，通过数据识别引擎进行识别。然而在实际落地过程中，却发现很多问题。比如存储组件种类多，上报数据流量大，以及时效性，准确率，覆盖率等等问题。 整体架构 通过不断对数据分类分级业务分析，设计如上数据分类分级架构。架构核心由五大块组成： 其中重点要处理前三点。 海量数据实时识别 企业规模不断庞大，海量用户，必然产生海量数据。如何满足高性能，时效性同时，又能达到高正确率和覆盖率要求，对于系统架构是一个巨大考验。 （一）数据存储 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密集型无法简单使用常见的缓存，异步等方式去减轻服务端压力。因此需要考虑点如下： 多核并行 多核并行借鉴MapReduce编程模型，本质是一种“分而治之”的思想。 优化效果 规则管理 数据的分类分级，需更精细化的规则管理，才能对后续数据安全做到更合理的管控。规则包括不限于正则，nlp，机器学习，算法，全文匹配，模糊匹配，黑名单等。对应每种具体分类分级定义，又包括多个规则的组合使用。通过实际的运营和梳理以后，目前有近四百种分类分级定义和八百种识别规则。 因此需考虑合理的方式，将规则管理和识别逻辑解耦，以便后续的维护和升级。同时需考虑规则热更新和关闭，做到对线上服务无感知。 权重计算 数据分类分级，在不同行业和业务有不同的维度和定义。且源数据由于开发和运维人员定义不清晰，导致最终识别结果存在模糊的边界。在实际运营过程中，常会因为识别结果不准确，被业务方反馈。 假设有字段叫xid，有可能是qqid，也可能是wechatid，而qdid和wechatid对应不同的分类分级，这会影响后续的合规流程。在实际场景，xid有可能同时被qqid和wechatid识别规则命中，那么该取哪个呢？ 因此引入权重的概念，权重不在于将识别结果做简单的0和1取舍，而是通过多个组合规则识别后，计算出一个权重值，并对多个识别结果的权重值进行排序，取权重最大的识别结果作为当前字段的分类分级。 数据校验 数据安全合规管控，最重要一项是数据加密。为了方便运营后续进行合规追溯，需要在服务端对当前上报数据是否加密进行校验，并将校验结果保存下来。 数据是否加密需综合判断库表状态等信息，其中包括数据是否加密，表是否删除，库是否删除，实例是否下线等。状态的转换大数据存储架构，通过以下决策树表示： 跨部门和平台接入 在重点解决数据上报和数据识别等难点以后，数据分类分级框架已可以满足大部分业务场景。因此也希望框架能服务更多的部门需求，减少大量繁琐重复的工作量。 由于数据分类分级结果属于敏感数据，对于跨部门和平台接入，需考虑将数据根据不同部门和平台进行物理隔离存储。 总结 数据分类分级很复杂，这种复杂性有业务层面，也有架构层面。本文重点在于述说架构层面的问题。这些问题有些可以提前规划设计，比如存储选型、通用扫描能力等。也有些需要在落地过程中持续优化，比如海量数据识别，除了对服务本身性能优化，也要对资源成本综合考虑。 架构没有好坏之分，只有合适一说。本文所讲述是基于个人在落地过程遇到问题的经验总结。因此反复斟酌，认真梳理写下本文，也是对本人工作的一个阶段总结。同时也希望框架能得到更多人认可，并达到数据分类分级能力复用，为公司数据安全合规工作尽到一点小小贡献。 （编辑：草根网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐
浙公网安备 33038102330470号