DataSecOps：一种新的数据安全落地框架-安全KER

[TOC]

导语

相对于DevSecOps的火热，DataSecOps似乎冷清不少。实际上从两者发端的DevOps和DataOps的传播热度，也能看出端倪。本文主要从上述术语的对比、分析出发，再到分析DataSecOps与数据安全网关、CASB等传播更广的安全产品或解决方案的对比分析，试图去说明DataSecOps研究与落地的价值所在。而随着对DataSecOps的深入了解，发现其当前两种架构模式，相比传统的数据安全网关或一站式运营平台，除了有不少进步之处，但也存在一些问题。为此，最后还提供了如何覆盖数据全生命周期、区分不同场景与构建工具链的落地思路。

DataSecOps概述

本节主要通过术语对比、概念解析的方式引入DataSecOps的介绍。

反差：冷清的DataOps/DataSecOps，与不冷清的赛道

经过对安全业界人士的简单调研，发现知道DataSecOps的几乎没有，这点在接下来的【Google Trend】调查中得到验证，而介绍DataSecOps，就像介绍DevSecOps之前，怎能不介绍作为基础的DevOps？因此本文也将同步介绍DataOps。相对于大热的DevOps、DevSecOps，DataOps、DataSecOps受到的关注很少。如图1所示，DevOps今年以来热度依旧很高，DevSecOps热度其次，但是DataOps、DataSecOps则几乎没有什么热度。

【图1】
但是，通过对近年来的安全赛道调查，发现DataSecOps其实还被一些安全咨询机构列为新赛道，并且国内外还有不少厂商，如图2所示，既然如此，说明DataSecOps还是有不小的市场价值，否则支持不起一个赛道的定位。

【图2】

这样的反差，让人不禁疑问：为什么DataSecOps这个领域这个冷清，而它为何又进入我们的研究领域？带着这样的疑问，让我们继续往下了解。

快速了解DataOps与DataSecOps

了解DataSecOps，就必须了解DataOps，就像要了解DevSecOps，就要了解DevOps一样。如图3所示，DataOps于2014年首次提出，2018年Gartner将DataOps纳入数据管理技术成熟度曲线。根据IBM的定义，DataOps是一组协作数据管理实践，通过流程和技术，将对数据的集成和面向流程的观点与来自DevOps的自动化和方法相结合，将数据开发、管理、分析、运营融为一体的方法论，通过更好的协作和自动化来改善组织对于数据的使用。如图4所示，DataOps包含四大能力：在Agile，DevOps和Lean的加持下，包括数据工程、数据集成、数据安全和隐私，数据质量等。如图5，根据TrueDataOps社区定义，DataOps包含如下七根支柱：包括ELT与ELT精神、持续集成/持续部署（CI/CD）、代码设计和可维护性、环境管理、治理和变更控制、自动化测试和监控以及协作和自助服务。

ELT与ELT精神：从ETL转变为ELT以保证数据加载的时效性，减少不必要的细节丢失，从而最大限度地提高了未来数据处理和分析的潜力
持续集成/持续部署 (CI/CD）：与DevOps开发过程类似，代码发生新增或变更后提交到代码仓库并触发持续集成、构建和测试并支持按需部署
代码设计和可维护性：参考软件设计原则，提升代码复用和可维护性
环境管理：基于容器化技术，可支持自动构建、更改和销毁数据运行环境，方便用户同步的数据开发和管理用途，比如沙箱环境、开发环境、测试环境、验证环境等
治理和变更控制：提供数据自理和安全隐私的工具和平台支持，保障数据安全和可追溯可审计
自动化测试和监控：针对用户提交的代码基于测试规则进行自动化测试，包括输入测试、业务逻辑测试和输出测试
协作和自助服务：包括开发和运营层面的协作和自助服务以及客户和利益相关者层面的协作和自助服务

【图3】

【图4】

【图5】

但是，国内更多的时候是讲数据治理，数据中台，他们之间有什么关系？通过以下分析，可以发现其实DataOps并非某种技术或者平台，而是可以作为建设数据中台或者开展数据治理的能力或者策略。

DataOps与数据中台：DataOps可以作为数据中台的核心能力，实现快速、稳定和自助式数据准备和数据服务。
DataOps与数据治理：基于DataOps，可以更好的实现元数据、数据质量等数据治理自动化。

接下来，我们来了解DataSecOps，如图6所示，2020年首次提出，DataSecOps是一种敏捷、全面、内置安全的方法，用于协调不断变化的数据及其用户，旨在快速提供数据价值，同时确保数据的私密性、安全性和良好的管理。强调数据全生命周期流转运营过程中的内嵌安全属性，将敏感数据在基于业务的流动各环节和状态下的安全风险动态统一把控。

【图6】

为了更好理DataSecOps，接下来不妨将其与DataOps、DevOps、DevSecOps进行对比，如表1，可以看到DevOps处理对象是代码，DevSecOps是挖掘代码或组件安全漏洞并支持加固，DataOps处理对象是数据，DataSecOps是挖掘承载数据的载体存在的安全风险并支持加固。


DataOps	DevOps	DataSecOps	DevSecOps
Data Operations	Development Operations	Data Security Operations	Dev Security Operations
Employs agile approach	–	–	–
Involves data management and IT operations teams	Involves product development and IT operations teams	Involves data management, IT operations, and security teams	Involves development, IT operations, and security teams
Uses Build, Test, Release with several steps in between	Uses Build, Test, Release	Uses Build, Test, Release with security in every stage	Uses Build, Test, Release with security in every stage
Faster delivery of data analytics solutions	Faster development and release of software products	Faster delivery of data products	Faster development and release of software products
Ensures structured and accurate data	Ensures faster deployment with the least amount of bugs and issues	Ensures data security, safety, and governance	Ensures software development and release security, safety
Continuous integration and delivery	–	–	–
Offers companies automated data pipeline	Offers companies the chance to release their product faster	Offers maximum security for every step of the data project	Offers maximum security for every step of software products

【表1】

到了这里，我们可以大致理解，为什么会DataSecOps目前如此冷清？借助大模型来进行总结，大致有以下5个原因：

定义不明确：未形成共识，推广难度大
行业认可度不足：相比于DevOps的火热，DataOps并没有那么流行，国内更喜欢叫数据中台
安全天然内置理念越来越深入人心：安全性作为内置特性，未必需要以新的概念或实践去推广
已有专业术语：DevSecOps的流行很大程度上减弱了再造一个类似的DataSecOps的必要性
安全需求的多样性：不同行业和组织需求差异大，使得构建一种通用的实践或方法论更为困难。这个问题在数据安全领域更甚，这也是很大程度上数据安全难做或者做了这么多年，没有出现DevSecOps这种大热的理念或者框架的根本所在。

既然如此，那为什么我们还要研究它？从对一个新生事物的了解过程来看，一般是：选择的过程：粗看->发现问题，但有价值->再看，问题更多，但价值也更多->选择，并探索、优化。现在我们进入了第2个阶段，研究它，知道它有问题，但是它是有价值的，因此反推我们去进一步研究它。这里以DevSecOps刚出来的时候也遇到过的争议为例，当时有一种说法：“就像有了SDL，为什么还要有DevSecOps？”

下面不妨对SDL和DevSecOps来对比一下，如表2所示，会发现：DevSecOps的优势在于，其实是将SDL的落地更进一步：流程融入、自动化、更多前置、让安全文化更深入人心。同样的理由，用于DataSecOps，何尝不也成立？

客观来说，也有下面3个因素导致DataSecOps还未流行起来：

发展需要时间：2012年Gartner就提出了DevSecOps，但2020年才开始爆发，何况DataSecOps在2020年才提出，到目前为止也不过短短4年。
工具链不够成熟：数据分类分级与敏感数据识别、加密、脱敏等工具非常成熟，但异常检测、行为审计等工具链并不成熟，而且太多单点问题，比如存储组件的安全性当前很难靠工具解决
海量资产覆盖资源消耗巨大：海量数据，对工具性能要求极高，需要消耗资源之大导致无法全场景覆盖，尤其是离线场景。我觉得这个是最大的问题，数据安全，不像软件安全，从资产绝对值来说，数据资产和整个上下游远比软件多得多，相对应的，需要投入成本无疑会更大，为了实现成本与安全的平衡，就要找到一个有效的、可平的抓手。

小结一下，讨论到此，算是说明白了DataSecOps研究研究的价值。但是，开展的落地的价值所在，却不是一个理念上问题，更多需要从技术，或者架构上来看。因此，下面进入下一部分。

DataSecOps整体架构

纵观目前国内外DataSecOps的理论框架，其实并没一套成熟的方法论，它也还随着DevOps的不断落地去沉淀，更遑什么成熟的技术架构。不过通过研究国内外代表厂商的解决方案，会发现其实有两套模式。

模式1：数据安全网关/CASB

我们对数据安全网关并不陌生，类似API网关，如图7，数据安全网关部署于数据访问的客户端和数据存储之间，通过识别访问者身份、位置、行为，同时依靠对被访问对象的全面认知，提供统一的、细粒度的访问控制、身份验证能力，近年来，如图8，开始提供动态脱敏、动态加密、行为审计等安全能力，有的甚至还支持敏感数据识别与分类分级等资产识别与管理能力。不同厂商提供的产品在能力上实际上存在一定差异，但总体上不会超过以上范围。类似的，进入云时代，开始出现CASB（Cloud Access Security Broker），从能力上看并没有突破传统的数据安全网关能力范畴。客观来说，主要的进步在于：加入加密、脱敏、敏感数据识别、数据分类分级等新的安全能力以及合规评估机制的嵌入，但所能覆盖的数据生命周期阶段以及场景仍不完整，根本原因在于无法将所有数据链路收敛到统一的网关之上，试想，在海量数据面前，去建设这样的一个网关的代价有多大？对于业务规模优先的组织来说，是有可能的，但对于大中型企业来说，可行性不大，这也决这样的模式只能应用于部分场景，特别是数据使用场景。

【图7】

【图8】

模式2：一站式运营平台

采用这种模式的厂商，国内有数安行等公司，国外的目前暂未观察到。如图9，这种模式下，将IT系统分为三个平面，最下层的业务基础设施包含存储、主机、各类业务系统以及终端，可以看到数据存储流转的业务流和数据流。往上一层通过建立与数据业务形成映射的数据流转存储空间，关注在基础设施上各种来源的数据，包括个人隐私数据和敏感商业数据，通过不同技术进行识别，并跟踪其处理流转和状态变化过程。最顶层作为数据安全平面，即一个自动化的数据合规与安全防护平台，将持续进行数据安全风险检测评估，根据识别到的敏感数据及其风险和具体的影响程度，采取自适应的细粒度防护措施。客观来说，主要的进步在于：从面向数据访问场景，扩展到数据平面与数据安全平面的抽象，这不仅仅是理念升级，更让覆盖场景更加全面。但退一步讲，即便没有这个一站式运营平台，当前采用DSMM+IPDRR的动静结合模型的安全建设思路，其实本质上也是这个思路，只不过缺乏一个统一的运营平台，是否一站式，并不是关键。

【图9】

通过以上技术架构的分析，我们对DataSecOps的理解又更进一步，可以总结出落地上的更深层次的问题，也是如果它要火起来，必须要解决的关键问题。

1、没有真的覆盖数据全生命周期，主要聚焦数据使用场景，但也并不是所有的现有产品都是这样。毕竟一些公司还是宣称自己的数据安全网关或者一站式运营平台支持数据全生命周期的。
2、未考虑复杂的业务场景，多面向在线，无视规模更大的离线近线场景，但也并不是所有的现有产品都是这样。毕竟一些公司还是宣称自己的数据安全网关或者一站式运营平台支持数据全场景的。
3、单点功能产品堆砌为主，缺乏CI/CD管道打通产品形成闭环，做到在DataOps双环中用户无感接入。这块可以说几乎空白，无论是解决方案，还是工具链，至今未看到有结合CI/CD管道来考虑落地的，无论是数据安全网关模式，还是一站式运营平台，对数据的pipeline或者用户体验，包括架构改动，都并非无侵入式，或者免改造的。但不可否认，完全无侵入，或者免改造，目前来看并不现实。

既然已经找到症结所在，那么如果要落地，具体的思路是怎样的呢？

DataSecOps落地思路

其实对应上述症结，落地思路上主要考虑如何解决存在的关键问题。而DataSecOps并不倡导发明新轮子，在漫长的企业安全建设路上，可以站在巨人的肩膀上，在覆盖数据全生命周期的基础上，区分不同数据场景因地制宜的选择更细节的方案，复用已有工具加以编排形成面向CI/CD的工具链。

覆盖数据全生命周期

过去业界已经提出面向静态的数据全生命周期保护的DSMM框架，还有的是结合IPDRR框架来做动态的数据风险监测闭环。具体来讲，如图10所示，以DSMM为横坐标，以IPDRR为纵坐标，一般来说，数据全生命周期分为：采集->传输->存储->使用->加工->交换->销毁等几个阶段，IPDRR框架分为：识别Identify、保护Protect、检测Detect、响应Respond、恢复Recovery等5个环节，通过将这两种动静态维度的方案组合在一起实现数据全生命周期的风险监测与安全防护，这套机制已经在业界取得广泛的认同。而DataSecOps落地，完全可以复用这套机制。

【图10】
比如数据采集场景，可以在APP打包过程嵌入采集合规扫描能力，或者在数据上报协议创建或修改时嵌入敏感字段检测能力，比如数据存储场景，可以将分类分级扫描能力与数据平台打通，实现数据资产的全面分类分级，并在此之上实现相应的安全保护与管控措施。其他的业界也有很多介绍，这里不再赘述。但这里有个难点，在很多公司无法落地，或者落地效果很差的，就是将数据整流转链路刻画出来，比如在api接口检测出敏感数据字段，即便在存储组件也做了分类分级，但如何将这两份结果，以及数据流经的节点识别出来，难度很大。对于RASP落地了的公司来说，可能实现起来相对简单。实际上，还有一种模式，如果从api层，到存储层，中间的调用关系可以通过服务端框架或者可观测性框架实现，那同样来说实现起也会相对简单。

区分不同数据场景

正如上文所述，DataSecOps落地方案不能一刀切，需要根据不同数据场采用更细节的方案，比如对于在线与离线，在数据流转过程上就存在很大不同，导致DataSecOps落地需要加以区分。

1、数据流转pipeline

如图11所示，首先数据采集环节，对应数据来源，一般有客户端、web、服务端、工具等几类，客户端、web一般是直接采集用户侧数据，服务端、工具一般是采集加工数据。之后在数据传输环节，对应上报通道，一般有http api或rpc两种，在此可以嵌入上报协议审核、分类分级扫描、加密、脱敏等安全合规能力。之后到了数据存储环节，对应的不仅仅是数据存储，其实还有数据转发，这里存储组件分为在线存储、离线存储，还有类似kafka、mq、pulsar等转发服务，在这里同样可以嵌入分类分级扫描、加密、脱敏、漏洞扫描、异常检测等安全能力。之后进入数据加工环节，比如数据计算，这里部署一套数据网关，不仅可用于收敛、代理对存储组件的实时分析、离线分析，以及数据共享，还可支持访问控制、鉴权、审计、异常检测等安全能力，同样道理，如果需要提供在线访问，也可以部署类似的API网关，提供相应的安全能力，并嵌入合规评估流程，之后在加工后数据输出到BI报表、运营系统、工具，此时进入数据运营阶段，可继续沿用前面环节安全能力。

【图11】

接下来，针对在线、离线场景再稍作展开。

2、在线

如图12所示，在线场景涉及通过提供api的方式提供对底层数据存储的直接访问，可在统一网关内置安全能力，并在api开发、上线流程中嵌入合规评估、异常检测能力。具体功能如图13所示，可以支持包括数据分类分级、敏感数据识别的数据标签功能，提供基于调用监控的数据血缘视图，支持服务、接口字级级别鉴权的权限管理，还有基于服务、接口字段关联关系的接口管理功能，并内置限频限速、异常检测等其他安全能力。

【图12】

【图13】

3、离线

如图14所示，离线场景下的处理流程和应用架构与在线场景差异较大，从上报通道开始，就开始内置数据分类分级能力，并基于分级将数据分流到不同安全管控要求存储组件或运行环境中，除了会经过与同样支持访问控制、鉴权、异常检测的统一网关外，还可支持通过合规评估后授权方可使用或导出，使用过程纳入自动对账与异常审计。在数据计算的运行环境这里，如图15所示，当前至少有数据沙盒、安全屋、隐私计算三种模式。其中，数据沙盒的特点是：数据只进不出，或严格限制出库，安全屋的特点是：不移动或复制数据，支持字段级别权限控制，隐私计算则指联邦学习、安全多方计算、机密计算等技术方案。

【图14】

【图15】

选择切入场景与构建工具链

个人认为，真正的DataSecOps工具链，应该是立足于DataOps的生命周期的，但是很可惜，目前国内外都没有看到相应的产品。因此下面将介绍参考DevSecOps工具链，并结合DataOps生命周期设计出来的一套工具链及其切入场景。如图16所示，在数据源与数据输出之间构建DataOps处理流。在Plan阶段，可复用DevSecOps或SDL的现有能力，比如威胁建模、安全培训以及合规评估。在Develop阶段，可嵌入敏感信息硬编码检测能力，比如提供IDE安全插件。在Build阶段，嵌入认证授权预检查，数据分类分级与敏感数据识别，合规检测等安全合规能力，比如在app构建过程中嵌入灵犀或Rightly合规检测工具。之后是部署测试环境之前，先要完成环境管理，对应Manage Enviroments阶段，可以提供数据沙箱、安全屋等方案，在Test阶段，可嵌入数据分类分级与敏感数据识别、加密、脱敏、漏洞扫描等安全能力，在之后Release、Deploy阶段，同样可以嵌入认证授权检查，数据分类分级与敏感数据识别等安全能力，至于后续的Operator、Monitor阶段，可以分别接入认证授权检查、异常检测、安全审计、SOAR等安全能力，从而实现安全能力对整个DataOps生命周期的全覆盖。

【图16】

结语

DataSecOps之于DataOps，就像DevSecOps之于DevOps，其实相比于SDL，基本上不需要发展出新的工具链，而是从流程集成、自动化嵌入、更多左移以及安全文化的深入人心上去努力，期待随着DataOps的理念传播、一站式数据开发治理平台落地，会有越来越多的数据安全能力可以找到抓手嵌入到数据研发运营流程中。