浅谈有赞大数据安全体系
点击关注“有赞coder”
获取更多技术干货哦～
部门：数据中台
一、背景
据统计表明，全球的数据量每过两年翻一番，不知道什么时候开始，“大数据”已经成了我们经常挂在嘴边的词。随着大数据时代的来临，数据无疑是企业和用户最为重要和宝贵的数字资产，那么安全体系的建设尤为重要和关键，而其中数据安全和隐私保护则是安全体系的重中之重。
2018年7月，中国信通院发布了大数据安全白皮书，标志着数据安全正式作为国家大数据战略。本文将从数据安全的定义和目标入手，逐步介绍有赞的大数据安全体系的发展和建设过程。
二、什么是大数据安全
2.1 大数据安全定义和目标
说到安全，我们都熟悉计算机系统安全性的 CIA 原则(保密性、完整性、可用性)，而数据安全亦离不开这个原则。所谓数据安全，其实就是保障数据全生命周期的安全和处理合规。其中数据的全生命周期，包括数据生产、使用、存储、传输、披露、销毁等等；处理合规其实就是在数据处理的过程中符合各项法律法规的要求。
数据安全体系的建设围绕着以上的原则，重点关注数据的应用场景和隐私保护，主要有如下目标：
满足基本数据安全需求，敏感数据、数据合规和基本数据保护
不能只局限于单一平台或产品，需要覆盖数据的所有环节和应用场景
数据支持分类分级，重视数据角色权限管理和数据全生命周期管理
时刻关注合规性处理，需要体系化的合规处理机制
2.2 大数据安全总体架构
明确了数据安全的定义和目标后，我们构建了一套数据安全体系，如下图所示：
三、大数据平台安全
3.1 边界安全
3.1.1 身份认证
3.1.2 网络隔离
3.1.3 接口鉴权
3.2 访问控制和权限控制
3.2.1 数据访问权限控制
3.2.2 权限审计
3.3 审计和备份
3.3.1 数据审计
3.3.2 备份和恢复
四、隐私保护与个人数据安全
4.1 数据安全能力保障
4.1.1 数据分类分级标准
公司数据：属于公司自身所有的财务、技术、人事、行政等信息 业务数据：公司在业务开展过程中所使用和产生的数据 客户数据：客户的基本信息，以及客户在使用公司产品及服务的生命周期中产生的信息
4.1.2 数据安全策略控制
4.1.3 数据打标
4.2 敏感数据识别
4.2.1 敏感数据定义
地址 qq号 微信号 邮箱 手机号 姓名 身份证 银行卡号
4.2.2 敏感数据识别优化
单机部署，程序宕机容易造成安全漏洞 一次全量识别时间过长，一次全量采样分析脱敏流程时间在两天左右。 运行透明度低，流程失败了无法感知，恢复成本代价高。
优化全量采样流程，缩短全量识别时间至1～2个小时 支持增量数据的采样和分析，分钟级响应敏感数据脱敏 同时打通和数据资产平台的交互渠道，支持相关责任人自定义数据敏感等级 优化原有采样规则，增加对敏感数据类别识别的准确性
采样是对每个表进行抽样数据，供后续特征识别和脱敏用。在表的数据量过大时，其实可以采取更快的大数据查询引擎来执行采样sql以提高效率，比如spark、presto等对于大数据量的查询都是比较快速的。在实际的生产环境中，我们会首先根据数据资产平台采集到的表数据量和行数，设定一定阈值，超过阈值会使用presto引擎，未超过阈值的则选择基本的hive引擎。之所以不全部统一采取presto引擎执行是为了不跟生产环境正常任务抢占计算资源，尽可能小的对调度任务产生影响。
在实际的采样过程中，我们发现大部分表属于长期不更新或者更新周期较长，比如周表、月表之类的，这些其实没必要每天都重复采样分析，从而浪费过多的时间和计算资源。所以我们定义了需要采样表的标准：
从未采集过的，即新表 采集过且在一天之内更新过的
在实际采样过程中，我们还会判断表的分区属性，根据是否为分区表采取不同的采样策略：
在采样过程中，我们没必要对一张表所有字段进行采样工作，所以我们通过对字段类型和字段名称进行过滤，最后得到具体需要采集的字段。这样做的好处是能够避免对不可能包含敏感信息的大字段或者复杂结构的字段进行查询采样，大大提高单表的查询速度。具体的，我们的过滤有：
string/数值类型的字段 非time字段 名称非id、par等明确含义的字段
如何保证敏感信息识别的准确性，首先要保证的是采样数据的足够性和随机性。为了达到以上的需求，我们做了一下几点优化：限定采样数量的阈值，对于第一次采样语句只限定数量要求，同时采用一定的随机采样方法。对于第一次采样结果进行非空过滤，如果不够数量要求，则会第二次采样，执行附加更多限制条件的采样语句，确保采样数据的数量达到要求。对于 string 类型的字段限制长度，过长的 string 类型字段某种意义上不可能是敏感字段，所以我们需要采集的是合理范围长度的信息。对于非 string 类型字段的限制不为 null 值，null 值的数据采了也是没有意义的，我们核心遵守的理念是保证采样的数据是合理的，有意义的，最后分析的结果才有意义。
为了增加数据安全的及时性，天级的全量敏感数据识别任务其实已经比较滞后了。所以除了天级的全量调度措施作为兜底方案外，我们还增加了增量的敏感数据识别的措施。由于现在数据开发的入口都已经收敛到 DP ，所以我们和 DP 打通渠道，监听数据开发的更新数据的动作，在用户新建或者更新数据后，触发敏感数据识别的流程，及时收敛敏感数据泄漏的风险。
同时我们会利用数据资产平台的血缘关系，进行一定程度的敏感等级继承。在实际的开发过程中，数据与数据之间其实是存在链路或者血缘关系的，举个例子：A 表的字段 c1是从上游 B 表的 c2 表字段 select 过来的，这个时候敏感信息一样会跟着血缘关系从 c1 到 c2 字段中。所以血缘关系也作为了敏感数据识别的参考依据之一。
4.3 数据脱敏
4.3.1 敏感数据识别
对于手机号、邮箱之类规则比较明确的，采取正则表达式进行匹配 对于姓名、地址之类的，我们采取开源的自然语言特征识别工具HanLP进行这类信息的识别判断 微信号、qq号的，由于随机性较大，我们会额外对字段的名称进行特定的过滤以增加匹配的准确性
对于识别的敏感数据类型，我们根据类型的敏感程度分为三级(和上文的数据分类分级标准匹配)，从而进行不同程度的脱敏效果，目前我们的等级定义为如下(仅供参考)：
4.3.2 数据脱敏
五、合规处理
5.1 数据导出控制
5.1.1 内部调用控制
5.1.2 数据对外导出控制
5.2 其他
六、总结和展望
最后，有赞数据中台，长期招聘基础组件、平台研发、数据仓库、数据产品、算法等方面的人才。欢迎加入我们，一起enjoy～ 简历投递邮箱：sunweiwei@youzan.com。
拓展阅读：
Flink 滑动窗口优化 有赞埋点实践 有赞埋点质量保障 基于时间加权的用户购买类目意愿计算 有赞推荐系统关键技术 有赞数据中台建设实践 数据资产，赞之治理 SparkSQL在有赞大数据的实践（二） HBase Bulkload 实践探讨