2万字揭秘阿里巴巴数据治理平台DataWorks建设实践

五、数据安全管控治理

当有越来越多的人来使用数据，那安全管控就会成为一个比较头疼的问题，绝大部分的管控行为就是“反便捷”的，用的人越多，影响越大。不论是阿里巴巴自身还是其他企业组织的大数据体系，在安全管控方面有以下几个痛点：

• 存储量大、用户种类多：由于数据仓库/数据中台是集成的、反映历史变化的，因此注定了企业的数据仓库集中存储了各部门、各业务系统的数据，阿里巴巴内部的一张宽表动辄达到TB级别的存储量、每日新增上百张表与数百GB是不可避免的事，这些数据不仅包含结构化数据，也包含非结构化、半结构化数据。如果我们希望将这些数据进行精细化的管理加密，会导致数据分级分类成本过高、耗时较长及遗漏的问题。
• 用户基数大、用户种类多：数据中台是用于服务企业决策、日常分析的基础设施，在数据采集阶段，通常由开发人员配置任务将数据导入至数仓，加工阶段由数据工程师进行代码开发与侧，使用阶段则由各类运营、分析师通过各类Client来进行即席查询，也包括某些业务系统的直接调用。之前我们提到了，阿里巴巴，每天有数万名员工（包括：开发、运营、分析师、销售、HR等岗位）以各类方式接入使用数据仓库。如此多的人员授权就成为了难题，特别是在人员入职、离职、转岗场景，管理员需要花费大力气维护人员权限，非常容易出现过度授权、权限蠕变等问题。
• 客户端操作界面多样性：在使用数据仓库的人员中，部分开发人员会通过命令行直连，大多数人员则是通过可视化界面与自己的认证信息连接使用。由于不同数据应用所提供的服务、所服务的群体不一样，因此某些业务团队会自行开发适合自己的客户端界面以达到业务所需效果。而实际上授权过后的操作行为就是不可控的，各界面上的人员操作是否合理、是否符合工作所必需的原则是难以管控的。
• 数据流转链路复杂：数据在采集&传输、生产&开发、分发&使用阶段都涉及不同的流转链路。在采集&传输阶段，工程师可能通过离线、实时链路在内网、公网进行数据传输；在生产&开发阶段，少量数据会被从开发环境加载到生产环境用于测试，大量数据则会设计跨项目、跨DB读取与写入；在分发&使用阶段，由于不同业务系统处于不同网络环境，因此存在大量数据回流（出数仓）行为，这些行为可能通过数据服务API、离线同步链路来实现，同样可能涉及公网、内网。如此复杂的流转链路对加大了管控某些不合规数据流转行为的难度。
• 结果数据交付：数仓中最终可用于支撑分析决策的数据绝不是通过简单逻辑就能加工得出的，通常会涉及多团队、跨系统、多处理逻辑的交付，常见的数据产出逻辑可能涉及通过多个业务团队的数据，需构建十多个层级、总共上百个加工任务的工作流程（DAG）来使用。对不同团队的数据可用性、完整性管理，成为了企业安全管理员一项艰巨的挑战。

之前，阿里巴巴就联合中国电子技术标准化研究院、国家信息安全工程技术研究中心、中国信息安全测评中心等20家业内权威机构联合编写国家标准DSMM（数据安全能力成熟度模型），可让企业更清楚自身数据安全水位，并采取有效措施提升数据安全防护能力，从而有效保护消费者的数据安全。目前，以DSMM为抓手，在阿里生态内进行数据安全治理实践，对生态企业根据其数据安全能力进行分层管理，实现业务与安全挂钩，促进生态企业主动提升数据安全能力，接下来我们将会介绍一下在DataWorks平台层面一些安全管控经验。

• 梳理敏感数据资产清单并分级分类

数据安全治理的第一要务是梳理资产并对其进行分级分类，这已经成了数据安全行业的共识。面对PB级别庞大、每日新增的数据，人肉梳理是不现实的，因此我们会在“数据保护伞“上基于名称匹配、正则匹配、行业AI分级分类模板来配置数据识别规则，通过这种智能化的方式，可以快速发现敏感数据并进行打标。另外，除了一些表数据，数据安全还包含了一些类似数据源、任务、规则等非数据类的敏感数据，也是需要在梳理的范围之类，很多数据安全事件往往来源于这些非数据类资产的违规操作。

• 建设安全能力并选定安全控制

基于各类法律法规的合规要求，我们建设了“识别->防护->检测->响应”各阶段的数据安全技术工具能力，这些能力也会同时覆盖数据安全防护全生命周期，接下来我们会介绍几种典型的数据安全治理场景。

1. 角色划分与权限控制

为了方便使用，DataWorks提供了多种方式，例如平台内置了分析师、数据开发、运维等角色，基于角色的常见职责，分配角色后会直接赋予一些该角色的常见权限，不需要再逐个勾选。那基于一些特殊的定制化权限，我们也提供了OpenAPI的形式进行自动化地授权，实现人员自动添加/自动授权/按需申请权限，让团队内分权管理、各司其职，规范化开展数据生产开发流程。同时，针对一些敏感数据，还可以自定义审批流，进行访问控制，例如L1数据仅审批到表Owner、L2数据审批到部门安全负责人，L3数据审批到CIO等管理层。

2. 数据脱敏

虽然有些人已经申请了表的权限，但是针对一些敏感数据，我们还需要开启更高级别的保护。例如数据脱敏功能可以针对已经识别的敏感数据，进行格式加密、掩盖、HASH加密、字符替换区间变换、取整、置空等多种方式，这样我们就可以实现敏感数据的去标识化（脱敏），达到保护的目的。

3. AI风险识别模型

风险行为肯定不止查数据这种行为，DataWorks内置了AI数据风险行为治理，基于智能UEBA引擎配置各类风险规则，采集分析用户行为并智能判断各类诸如恶意数据访问、恶意数据导出、高危变更行为是否需以告警、阻断、审批等操作进行响应。在此阶段，我们会配置诸如数据大规模查询展示/复制/下载、数据DROP/DELETE/UPDATE、单位时间数据操作偏离、导出大量敏感数据、高敏感查询条件、事件发生时间异常、数据服务API发布、数据跨域同步等阻断或审批规则，以此来防范人员因蓄意或安全意识缺乏、误判而导致的不合理行为、风险、损失。

4. 数据安全治理成效

在上述相关治理动作落地后，我们在合规、攻防、降本提效方面都取得了明显成效。

• 满足国内包括但不限于等保2.0的所有安全测评。
• 每日自动化发现敏感记录值、核心表访问流转风险。
• 100%释放用于数据梳理、分级分类、风险发现的巨大人力。

▌小结

数据安全治理的需求多数来源于由于法律法规的要求，以及大数据平台用户增加带来的安全风险，而管控和效率绝大部分时候又是相背的。所以在安全治理的时候，我们不仅仅在平台基础能力上要满足各类安全合规的要求，同时需要提供类似敏感数据智能识别与分类分级、智能风险行为识别、自定义安全审批等一系列平台能力，尽量减少用户的使用成本，提高管控效率。

六、数据成本治理

最后终于讲到了成本治理，其实如果有仔细看前面几个场景的实践的话，会发现多多少少也有很多成本治理的事情或者效果在里面。就像我们在前面梳理企业大数据发展阶段的时候说过，降本的需求往往在成熟阶段产生，并且同时包含了前面几个阶段需要做的事情，企业在有降本需求的时候，不妨可以先回顾下前面几个阶段，我们是否做的足够充分，例如当前的成本高企，或许是因为第一阶段堆叠了过多的人肉，又或许是因为第二阶段各种人员无序使用资源。

从我们的观点来看，成本治理的方案核心主要包含了以下三个部分。

• 治技合一

这里的“技”包含了技术平台与技术人员，成本治理的目标绝不仅仅是下线几台机器，通用技术平台的构建至关重要。例如DataWorks这种工具型产品，主要是服务技术人员，提升工作效率。这里的“降本”，可以把它等同于“提效”，让1个人能做更多的工作，也是降本的一种方式。关于成本治理的理念、方法、流程，我们都通过产品技术平台的方式内置，将用户关注的各项维度的治理方法流程化提供，在研发同学完成数据开发的过程时，就完成了数据治理，并且能提升各个环节参与治理的研发同学的治理技能与治理效率。所以，我们的治理一定要沉淀成企业通用的技术资产，从而提升技术人员的治理能力与效率，达到治技合一。

• 全链路数据治理

基于平台之上，我们构建全链路的数据治理能力，从数据生产到数据消费的每个环节，我们都会针对每个环节的具体问题进行相应维度、相应问题项的定义，完成针对性的成本治理优化。每个链路上微小的优化，才能实现整体成本的不断降低。

• 组织设计与常态运营

最后我们需要各类组织架构、规章制度、运营活动来不断推动数据治理工作在内部落地。在阿里巴巴内部，我们常用存储健康分、计算健康分等指标，发起集团各团队数据治理战役，围绕健康分为核心指标，推动人做数据治理和管理。大家在各类培训、比武中，不断展示、学习各类不同的数据治理场景，让我们的数据治理工作可量化，持续化进行。

成本治理策略分析

成本治理大的目的都是推动以“更低成本”换取“更高”的最终业务价值。这里的成本同时包含了人与机器，这也是我们一直在强调的成本治理不要仅仅关注机器的成本，例如我们用3个人，能完成原本5个人的工作，这种提效也是一种降本的形态。回到技术人员关心的具体要做的事情上，成本治理的策略主要可以关注三个层面，

• 基础设施

主要指传统的机房形式，涉及硬件的采购、选型、优化等等，这里大部分工作一般由阿里云负责，不需要我们投入太多精力。

• 引擎能力

主要涉及存储与计算能力的优化，例如提高存储的效率，压缩比，提高单位计算的能力，提高分布式调度的能力等等。

• 平台能力

主要涉及工具平台，例如高效地进行数据开发，将各类治理策略平台化，快速发现、解决、量化各类数据治理的问题。

这些动作最终是为了实现我们成本治理的业务价值，例如整体集团节省了多少成本，某个事业部达成了多少的降本目标，某个业务板块的ROI等等，接下来，我们将重点针对引擎能力和平台能力做详细的介绍。

引擎降本-MaxCompute&Hologres

首先我们提到对于引擎侧的降本，是要向核心技术要红利。DataWorks在阿里巴巴集团结合阿里云ODPS一体化大数据智能计算平台能力，不断突破性价比世界记录，满足多元化数据计算需求。阿里云ODPS（OpenData Platform and Service）自2009年开始建设至今，提供规模化批量计算、实时交互式计算、流式计算等可扩展的智能计算引擎，是目前中国最早自研，应用范围最大，能同时支持超过10万台服务器并行计算的大数据智能计算平台。其中大规模计算批量引擎MaxCompute在TPCx-BigBench-100TB测试中，连续6年稳定全球冠军，2022年，MaxCompute评测结果性能较2021年提升40%，同时成本下降近30%。实时交互式计算引擎Hologres在2022年TPC-H 30000GB性能评测中，获得世界第一，超过原世界记录23%。

这些记录背后是ODPS持续13年深耕自研技术的成果，ODPS-MaxCompute基于盘古存储，提供高性能的存储引擎，存储成本比Apache ORC和Parquet节约20%和33%存储空间，计算效率对比Apache ORC和Parquet分别有30%和40%的性能提升。伏羲大规模分布式调度系统在全区域数据排布、去中心化调度、在线离线混合部署、动态计算等方面全方位满足新业务场景下的调度需求，在单日任务量千万级、单日计算量EB级的压力下，保障了基线全部按时产出。强大的高性能SQL计算引擎完整支持标准SQL(TPC-DS 100%兼容)且支持Hive/Spark兼容，一套SQL引擎支持离线、近实时分析、交互式分析场景，TPC-H指标上领先Spark 3X以上。ODPS-MaxCompute连续六次突破性能/成本世界记录，也是释放云上技术红利的最佳诠释之一。