浅谈有赞大数据安全体系
一、背景
据统计表明，全球的数据量每过两年翻一番，不知道什么时候开始，“大数据”已经成了我们经常挂在嘴边的词。随着大数据时代的来临，数据无疑是企业和用户最为重要和宝贵的数字资产，那么安全体系的建设尤为重要和关键，而其中数据安全和隐私保护则是安全体系的重中之重。
2018年7月，中国信通院发布了大数据安全白皮书，标志着数据安全正式作为国家大数据战略。本文将从数据安全的定义和目标入手，逐步介绍有赞的大数据安全体系的发展和建设过程。
二、什么是大数据安全
2.1 大数据安全定义和目标
说到安全，我们都熟悉计算机系统安全性的 CIA 原则(保密性、完整性、可用性)，而数据安全亦离不开这个原则。所谓数据安全，其实就是保障数据全生命周期的安全和处理合规。其中数据的全生命周期，包括数据生产、使用、存储、传输、披露、销毁等等；处理合规其实就是在数据处理的过程中符合各项法律法规的要求。
数据安全体系的建设围绕着以上的原则，重点关注数据的应用场景和隐私保护，主要有如下目标：
- 满足基本数据安全需求，敏感数据、数据合规和基本数据保护
- 不能只局限于单一平台或产品，需要覆盖数据的所有环节和应用场景
- 数据支持分类分级，重视数据角色权限管理和数据全生命周期管理
- 时刻关注合规性处理，需要体系化的合规处理机制
2.2 大数据安全总体架构
明确了数据安全的定义和目标后，我们构建了一套数据安全体系，如下图所示：
总体从下至上分为三个层次，数据平台安全、数据管理安全、隐私保护安全，其中合规处理会贯穿整个过程，保障每个环节的合规性。数据平台安全作为最底层、最基础的组件为其上运行的数据和应用提供安全机制的保障；数据管理安全则会在数据的流转或者全生命周期中提供功能和手段防护数据的安全；最上层的隐私保护安全是在数据安全管理的基础上对个人敏感数据和企业数据资产的保护。
三、大数据平台安全
3.1 边界安全
边界安全是指只有合法的用户才能访问大数据集群，确保大数据平台运行的边界数据进出的安全，主要从网络、接口、存储等角度保障数据平台运行的安全。
3.1.1 身份认证
目前我们已经收敛禁止所有数据开发涉及到的大数据基础组件的 client 使用方式和入口，统一使用 DP（数据研发平台）或者实时计算平台等平台型工具作为数据开发的入口和平台，登陆这些平台则需要进行一定的身份验证才能使用大数据基础组件相关能力。
3.1.2 网络隔离
大数据集群目前通过网络层面的隔离做到不同环境，不同机房的网络安全和数据隔离，从而保证网络的安全。
3.1.3 接口鉴权
接口鉴权主要分为两部分，一个是内部平台之间的接口鉴权，一个是内部平台与外部系统之间的接口鉴权。接口鉴权主要是在大数据平台能力输出的时候确保被合法性使用，防止一些接口和能力被非法使用、窃听或旁路嗅探，造成安全事故。
3.2 访问控制和权限控制
3.2.1 数据访问权限控制
在3.1.1节中介绍到目前我们将数据开发处理入口收敛到相关上层平台(比如 DP 等)，用户通过平台访问数据时，会经过数据解析服务分析出用户和需要访问的数据等信息，用户和数据之间的权限判断目前我们是托管到开源的大数据权限管理组件ranger来处理（关于ranger的介绍可以移步有赞大数据平台安全建设实践）
3.2.2 权限审计
ranger只能控制具体权限的规则，而权限的申请和审批我们是通过平台提供能力让用户自行操作。同时我们也会记录用户的申请和审批者的审批信息，作为重要的审计内容。
在用户申请数据访问权限的时候，我们也会要求用户提供数据的使用期限。平台会用定期的权限清理任务定期清理过期的权限，不会存在数据无限期的被用户使用的情况。
3.3 审计和备份
3.3.1 数据审计
除了权限的审计和控制之外，我们同样也对数据的使用进行了审计和监控。目前我们是通过T+1的离线调度任务，采集平台和组件本身的相关审计日志。平台同时提供审计日志查询功能供管理员进行定期审计复查和排查问题时的重要依据。
3.3.2 备份和恢复
备份作为大数据平台安全中存储安全不可缺少的一环，我们花了不少的精力在数据备份的整个事上。首先将数据的备份和数据的生命周期结合在一起，在数据创建的时候需要指明数据的生命周期，并且推进存量数据的生命周期设置。
在数据有了生命周期的设定后，会有备份程序会定期根据数据的生命周期，将数据自动备份到只做存储的冷备集群中，这里的技术栈主要涉及到一些对 hive server 的配置改造。这样操作的意义是，减少机器成本，不浪费计算资源，根据需要只备份明确需要的数据。
四、隐私保护与个人数据安全
4.1 数据安全能力保障
数据安全能力保障主要是指通过平台提供安全功能，支撑数据在生命周期内流转的安全，主要包括敏感信息脱敏、分类分级、元数据管理、存储加密、数据溯源等功能。
4.1.1 数据分类分级标准
为了支撑隐私保护和个人数据安全，首先要做的是对数据进行分类分级。只有做好分类分级后，才能对不同层级的数据采取不同的措施，从而实现数据的“可用不可见”。
目前有赞将数据分为三类，每类分为四级，安全等级随数字增大而增大。三类数据为：
- 公司数据：属于公司自身所有的财务、技术、人事、行政等信息
- 业务数据：公司在业务开展过程中所使用和产生的数据
- 客户数据：客户的基本信息，以及客户在使用公司产品及服务的生命周期中产生的信息
然后根据数据类型、数据保密性要求、数据访问授权的对象不同，详细的数据级别分类如下：
4.1.2 数据安全策略控制
做好数据分类分级后，还需要对不同类别不同等级的数据进行相应的数据安全策略控制，如访问权限、文件传输、测试使用等场景下不同等级的数据应该如何操作，这里不做详细介绍。
4.1.3 数据打标
明确数据分类分级标准后，需要做的是将类别等级应用到具体的数据。我们主要采用的自动采集+手动打标的方式。首先我们在源头创建MySQL表时需要额外选择字段的类别等级，rds（管理 Mysql 的工具平台）提供这样的标记功能。
数据资产平台采集数据的元数据时同时采集字段的这部分信息，获取到源头数据的分类分级信息。根据数据资产平台的字段血缘功能，将类别等级根据血缘关系继承下去，这样能够在数据地图中将分类分级信息蔓延开来。同时数据资产平台提供额外的标记入口，作为补充分类分级信息的入口，在用户有额外类别等级要求的时候能够快速更改和标识数据的类别等级信息。
4.2 敏感数据识别
根据上一节的数据分类，敏感数据也分为个人敏感数据和企业敏感数据，本篇着重介绍个人敏感数据的识别流程以及优化细节。
4.2.1 敏感数据定义
顾名思义敏感数据属于个人息息相关的不能轻易透露的信息，这些都属于用户重要的数据资产，我们暂时采集的个人敏感数据主要分为八种：
4.2.2 敏感数据识别优化
敏感数据识别程序作为个人隐私保护的重要技术保障，如何快速以及准确的定位到敏感数据是急需解决的问题。以前，有赞也部署过一套简易的敏感字段识别程序，但是缺陷很多：
- 单机部署，程序宕机容易造成安全漏洞
- 一次全量识别时间过长，一次全量采样分析脱敏流程时间在两天左右。
- 运行透明度低，流程失败了无法感知，恢复成本代价高。
基于以上缺陷，我们对原有的敏感数据识别流程进行优化和升级，达到以下效果：
- 优化全量采样流程，缩短全量识别时间至1～2个小时
- 支持增量数据的采样和分析，分钟级响应敏感数据脱敏
- 同时打通和数据资产平台的交互渠道，支持相关责任人自定义数据敏感等级
- 优化原有采样规则，增加对敏感数据类别识别的准确性
完整的敏感数据识别流程主要包含采样-识别-等级判定-权限写入，下面详细介绍部分步骤的内容和优化点。
（1）引擎自动选择
采样是对每个表进行抽样数据，供后续特征识别和脱敏用。在表的数据量过大时，其实可以采取更快的大数据查询引擎来执行采样sql以提高效率，比如spark、presto等对于大数据量的查询都是比较快速的。在实际的生产环境中，我们会首先根据数据资产平台采集到的表数据量和行数，设定一定阈值，超过阈值会使用presto引擎，未超过阈值的则选择基本的hive引擎。之所以不全部统一采取presto引擎执行是为了不跟生产环境正常任务抢占计算资源，尽可能小的对调度任务产生影响。
（2）采样表优化
在实际的采样过程中，我们发现大部分表属于长期不更新或者更新周期较长，比如周表、月表之类的，这些其实没必要每天都重复采样分析，从而浪费过多的时间和计算资源。所以我们定义了需要采样表的标准：
- 从未采集过的，即新表
- 采集过且在一天之内更新过的
在采样之后我们会记录采样结果，以便下一次采样时作对比，确定是否已采集过。在判断更新时间时，主要依赖对hdfs文件系统的更新时间读取，判断表是否一天内更新。
（3）分区表/非分区表
在实际采样过程中，我们还会判断表的分区属性，根据是否为分区表采取不同的采样策略：
（4）过滤字段
在采样过程中，我们没必要对一张表所有字段进行采样工作，所以我们通过对字段类型和字段名称进行过滤，最后得到具体需要采集的字段。这样做的好处是能够避免对不可能包含敏感信息的大字段或者复杂结构的字段进行查询采样，大大提高单表的查询速度。具体的，我们的过滤有：
- string/数值类型的字段
- 非time字段
- 名称非id、par等明确含义的字段
（5）采样数据丰富性
如何保证敏感信息识别的准确性，首先要保证的是采样数据的足够性和随机性。为了达到以上的需求，我们做了一下几点优化：限定采样数量的阈值，对于第一次采样语句只限定数量要求，同时采用一定的随机采样方法。对于第一次采样结果进行非空过滤，如果不够数量要求，则会第二次采样，执行附加更多限制条件的采样语句，确保采样数据的数量达到要求。对于 string 类型的字段限制长度，过长的 string 类型字段某种意义上不可能是敏感字段，所以我们需要采集的是合理范围长度的信息。对于非 string 类型字段的限制不为 null 值，null 值的数据采了也是没有意义的，我们核心遵守的理念是保证采样的数据是合理的，有意义的，最后分析的结果才有意义。
（6）增量采样识别脱敏
为了增加数据安全的及时性，天级的全量敏感数据识别任务其实已经比较滞后了。所以除了天级的全量调度措施作为兜底方案外，我们还增加了增量的敏感数据识别的措施。由于现在数据开发的入口都已经收敛到 DP ，所以我们和 DP 打通渠道，监听数据开发的更新数据的动作，在用户新建或者更新数据后，触发敏感数据识别的流程，及时收敛敏感数据泄漏的风险。
（7）血缘继承敏感等级
同时我们会利用数据资产平台的血缘关系，进行一定程度的敏感等级继承。在实际的开发过程中，数据与数据之间其实是存在链路或者血缘关系的，举个例子：A 表的字段 c1是从上游 B 表的 c2 表字段 select 过来的，这个时候敏感信息一样会跟着血缘关系从 c1 到 c2 字段中。所以血缘关系也作为了敏感数据识别的参考依据之一。
4.3 数据脱敏
4.3.1 敏感数据识别
经过上述的步骤我们已经采集到每个表的抽样数据，接下来要做的是对采样数据进行特征识别，匹配是否为八种敏感数据类型。对于敏感数据类型的识别主要分为两种：
- 对于手机号、邮箱之类规则比较明确的，采取正则表达式进行匹配
- 对于姓名、地址之类的，我们采取开源的自然语言特征识别工具HanLP进行这类信息的识别判断
- 微信号、qq号的，由于随机性较大，我们会额外对字段的名称进行特定的过滤以增加匹配的准确性
敏感数据等级
对于识别的敏感数据类型，我们根据类型的敏感程度分为三级(和上文的数据分类分级标准匹配)，从而进行不同程度的脱敏效果，目前我们的等级定义为如下(仅供参考)：
4.3.2 数据脱敏
对于敏感数据的识别结果，我们采用的是依赖ranger的mask功能进行不同等级的脱敏。在敏感数据等级确定后，我们会通过 HTTP 的方式，将敏感数据的控制规则作为 policy 写入 ranger mask，实际的效果如下：
经过上述的数据脱敏流程后，用户在实际的数据开发过程时，涉及到敏感字段的信息都会自动进行一定程度的脱敏，如果需要具体敏感字段的权限，用户可自行在 DP 上申请敏感字段的访问权限。
五、合规处理
在 2.1 节中我们介绍了大数据安全的定义和目标，而数据的合规处理是每个时刻都需要关注的内容。成立合规处理小组，介入数据的流转过程，这样用户使用有赞的数据才能放心和安心。有赞在2020年下半年也进行了合规相关内容的改造，拿到了隐私合规资质非常高的 ISO 27701 认证证书。下面对合规处理的一些方面的做一下简单介绍：
5.1 数据导出控制
为了提供更好的数据对外服务，保护有赞商家的数据资产和用户的个人信息，同时保证有赞小伙伴的工作效率，我们定义了许多数据导出的流程规范。主要分为两个场景，一个是内部调用数据，一个是有赞数据对外提供导出服务。
5.1.1 内部调用控制
内部的数据调用出口我们同样控制到 DP 的服务范围内，用户可以自行下载导出相关的数据内容。我们会调用数据解析服务根据条数和敏感信息的程度进行一定的审批操作，可以内部调用使用。
5.1.2 数据对外导出控制
当数据的流转超出有赞范围时，比如提供给商家时，我们会启用数据对外导出流程控制，商家需要提供《商家授权函》等等。
5.2 其他
除了数据导出控制外，在合规处理方面我们还做了很多，比如数据泄漏的应急预案、采购外部服务数据的安全规范定义等等，其实都是为了从数据的各个方面提前定义安全的规范和标准，并且按照规范和标准去执行每个数据流转的动作，让我们和商家在数据安全方面吃下一颗定心丸。
六、总结和展望
在上述的大数据安全体系架构中，我们从数据的生命周期和处理合规的角度建设了大数据安全体系。然而我们其实还有很多做的不好或者说可以做的更好的地方，比如审计只有计没有审、缺少对数据的监控和危险动作的提前预测等等，这些也都在未来的规划日程中。
一个系统结构的设计和开发中，开发人员为了高效，安全往往是容易忽视的一点，大数据安全亦是如此。在这里，也希望大家重视数据，提高数据安全意识，牢记“行车不规范，亲人两行泪”。
