数据中台之数据安全系列风险篇
数据中台被誉为大数据的下一站，由互联网巨头提出，核心思想是数据共享。
数据中台是聚合和治理跨域数据，将数据抽象封装成服务，提供给前台以业务价值的逻辑概念。数据中台距离业务更近，可以为业务提供速度更快的服务。数据中台可以建立在数据仓库和数据平台之上，将数据生产为一个个数据API 服务，以更高效的方式提供给业务，是加速企业从数据到业务价值的过程的中间层。从强调效率的需求出发，数据中台天然具有开放性和高效性的特点，而开放性和高效性同样带来了不容忽视的数据安全隐患。
数据中台数据安全风险现状
在数据中台中，数据全生命周期涉及到的安全风险涵盖了数据采集、数据传输、数据存储、数据处理、交换共享使用五个环节。此外，数据中台还存在着通用安全风险的痛点。从以上五个环节一个痛点出发，我们来详细分析一下数据中台的数据安全风险现状。
一、数据采集侧
1）数据保护措施与敏感级别不匹配
数据分类分级既是数据治理的基础，也是开展数据安全工作的前提。我国相关法律法规也要求对不同安全级别的数据需采取不同的安全保护措施与手段。
举例来说，若政务大数据平台中的数据未进行分类分级，则会按照政务网数据默认敏感等级进行安全保护，从而造成以下问题：首先，进行安全防护工作需要投入更大量的人力物力财力；其次，未分类数据中敏感级别低于默认敏感级别的数据会被过度保护，存在安全资源过度投入，防护过度也会导致系统运作效率的降低；另外，被默认级别保护的数据中还将含有大量敏感级别高于默认级别的数据，从而出现高敏感数据保护不足的风险。对于企业来说也存在同样的问题。
2）统一访问控制机制存在短板
大数据资源池包括关系型数据库、大规模并行数据仓库、分布式大数据，其中每类数据库均有自己的账号和权限体系。如果要应用全局安全策略，则需要对每一类数据库分别进行设置，必然会导致工作量成倍增加的问题。
每类数据库对访问控制的粒度以及标准存在不一致的支持度。假设当前需要进行字段级粒度的访问控制，而某些组件只能对表级粒度进行访问控制。因此，访问控制能力的差异必然会导致制定全局安全策略变得困难。
“工作量增加”与“全局策略制定困难”成为了“统一访问控制机制”的短板。
3）运营/运维人员拖库撞库风险
运维人员使用数据库账号进行运维管理，该账号的权限有可能超出实际运维管理所需要的标准。如果对其缺少访问行为控制管理，运维人员技术层面上就可以进行与运维任务无关的操作。在好奇心或某些利益驱动下，运维人员完全可以执行拖库撞库操作，以获取其感兴趣的数据，导致数据大量泄漏。
二 )、数据存储侧
1）权限失控风险
大数据资源池中每种数据库都有超级管理员账号，超级用户是数据库创建过程中的缺省用户，可以认为是数据库中的“造物主”，他们就像Unix系统的root用户或Windows的Adminstrator用户，有着至高无上的权力。当然，为了安全一般这种超级用户的口令都被掌握在极少数人手里，但是过度集中的权力同样也会带来问题，当超级用户拥有最高权力的情况下，意味着他可以做任何想做的事，并且不留下任何痕迹。因此，大数据资源池中还存在权限失控风险。
此外，在数据存储环节，同样存在着统一访问控制机制的短板和运营/运维人员拖库撞库的风险，这里不再进行赘述。
三、数据处理侧
1）处理过程中的恶意操作
数据治理行为通过执行治理脚本实现，治理脚本含有各种数据源操作命令。如果未对操作命令进行有效管控，就可能会出现恶意命令。恶意命令一旦被执行，数据源就有被破坏的风险，以及导致其他不可预知的安全问题。
2）缺少命令自动审批机制
虽然采用审批方式可以治理脚本自身风险，但审批环节除了要判断治理脚本本身风险外，还要判断治理脚本影响的库表是否与申请信息一致，从而确保治理脚本业务的正确性。因此针对不同的目标对象，治理脚本需进行差异化的审批策略。
若采用人工审批方式，在审批完成之前，若不能阻止未审批通过的脚本执行，则存在未授权执行风险。另外，人工审批高度依赖个人经验，对含有大量操作命令的脚本可能存在误判。因此，还存在高危脚本被审批通过的风险。另一方面，人工审批机制无法保证足够的时效性，对于数据中台的整体效率是一块短板。
3）治理流程脱管
数据治理通过执行治理脚本完成。治理脚本通过治理平台执行时，执行过程、执行结果都会被治理平台管控。另外，治理脚本也可以通过手动执行，手动执行的过程、结果不能同步给治理平台，治理平台无法管控，从而导致数据治理流程脱离管控。
执行治理脚本，会直接操作原始库，若脱离管控的治理脚本被执行操作，还将可能导致数据被破坏。
4）隐私泄密风险
异常的数据治理行为（例如非法执行数据查询脚本）会导致隐私泄漏。如果没有分析审计手段，当异常行为发生时不能及时告警，异常行为发生后也无法追查取证。
四、 数据交换共享使用侧
1）数据泄漏风险
数据需求方会向数据中台请求批量数据进行分析，中台提供批量数据时，由于对业务分析指标不了解，会存在过度提供数据的情况。
例如，某应用需要分析本年度每月结婚数量，该应用会申请本年度所有结婚人口信息，包括姓名、住址、联系方式等。其实统计每月数量仅需要时间信息准确即可，姓名、住址、联系方式等敏感信息都没有提供的必要性。数据中台在不了解分析内容时，会提供本年度结婚的完整人口信息，过度提供数据从而导致敏感信息泄漏。
2）非法应用服务器接入风险
数据资源管理平台通过接口方式对应用提供数据服务，如果接口缺少应用服务器的可信认证机制就不能分辨应用服务器的合法性，存在非法应用服务器接入的风险。
非法应用服务器接入后，可以直接访问数据资源平台提供的所有接口，存在极大的安全风险。
3）数据泄露不可追溯
数据服务平台有时要提供批量数据给数需方，同一份数据也可能会同时提供给多个数需方。
假设发生了数据泄漏事件，并且泄漏的数据是数据服务平台曾经提供给了多个数需方的情况下，泄漏渠道可能是其中一个或多个数需方，也可能是数据中台自身泄漏，很难准确判断泄漏途径，存在数据泄漏不可追溯风险，难以归责。
4）违规使用数据风险
数据在正常流程之外的对外发布操作都属于异常行为。例如数需方请求超出其实际需要的数据属于异常行为，未经授权的人员使用发布的数据也属于异常行为。以上对发布数据异常使用的行为，均会导致数据违规使用的风险。
若没有异常行为监控手段，当异常行为发生时不能及时告警，异常行为发生后也无法追查取证。
五、通用安全风险方面
1）缺少数据访问分析手段
安全策略的优化依赖于对当前数据安全状态的掌握程度。对当前数据安全状态了解越充分，对后续的安全策略优化提供的支撑则越充足。
数据一般会经历采集、处理、存储、交换共享、使用、销毁等过程，若缺少过程的联动分析，就无法形成数据流动的整体态势，难以对当前数据安全状态进行整体掌握，也就无法为后续的数据安全决策提供有效支撑。
2）缺少安全事件异常告警机制
当发生安全事件时，需要及时的告警反馈，才能进入应急响应流程。如果缺少安全事件异常告警机制，发生安全事件时就无法及时采取措施。安全事件越晚被发现，造成的损失也将越大。
3）敏感信息泄漏风险
采集平台与治理平台的脚本开发完成后，需要测试脚本的有效性、稳定性等。开发测试人员须有数据库操作权限才能进行脚本测试，该权限会涉及敏感信息，因此该环节存在敏感信息泄漏的风险。
其他业务平台后续也会进行定制开发，其过程跟采集平台、治理平台类似，开发和测试环节都可能会导致敏感信息泄漏。
综上所述，从数据的生命周期考量，数据中台存在着以上多种形式的安全风险，后面我们将以此场景针对性介绍对应防护方案。