百家 | 胡恺健：企业云原生数据防泄漏（DLP）架构与运营实践指南
“百家”，既是“诸子百家”，亦为“百花齐放”。他们是各行各业网络安全专家：有CSO、业界大咖、权威代表，更有奋战在网安一线的实践者、思想者和分享者。安在“百家”，最佳实践，真知灼见，思想火花，期待有你！
数据安全与隐私保护专家，现任广州诸子云常务理事、广东省等级保护专家、CSA云安全联盟零信任工作组、CSA隐私与个人信息法律组成员、DPOHUB成员。专注于全球金融科技的数据安全与隐私保护工作，在数字政府、金融科技、互联网电商的网络安全规划设计、信息安全治理与管理、数据安全、隐私保护、安全运营等领域具有丰富的实践经验。持有CISSP \ CISA \ CIPM \ CDPO \ CISP-DSG \ EXIN-DPO \ CDPSE \ C-CCSK \ ISO 27001 LA \ CCNA \ 网络规划设计师等安全与数据隐私认证
数据防泄漏（Data Loss Prevention，以下简称DLP）这个话题在国内一直处于不温不火的状态。大家都知道DLP非常重要，但实际部署过DLP或者听过经历的安全从业人员都对这个技术的有效性和易用性充满了怀疑。因其漫长又艰难的POC测试过程和部署运营的人力投入都与这个技术带来的收益不成正比，使DLP的安全效用大大降低，也逐渐拖慢了DLP的发展过程。
但随着国内外数据合规监管要求趋严，企业IT架构逐渐云化，SaaS应用的逐渐成熟，以及2020年以来全球COVID-19疫情给企业带来的远程办公数据泄露问题，都给DLP架构升级带来了新的机遇，企业选择DLP技术方案时，不再仅仅局限于终端、网络和邮件的DLP，而是逐渐趋向于选择在零信任、云原生、CASB和SASE等新技术领域驱动之下的全新DLP解决方案。
笔者一直坚信数据防泄漏是一个企业系统化、体系化的工程，绝对不是仅仅一两个安全产品就可以解决的。国外数据防泄漏市场注重的是生态和连接，一方面是IT巨头和行业应用如Microsoft、Google、Salesforce和Slack等在建设自己应用产品的同时，本身就会将应用原生DLP能力集成在内，通过开放的API为其他安全产品提供深度定制的安全能力。另一方面，安全厂商不求大而全的“王国”，而是在某一细分领域中做大做强，与IT巨头和行业应用做到足够强度和深度的集成。这些国外的经验非常值得借鉴和学习，期望国内各类安全产品和SaaS应用平台，都能通过加强自身原生安全能力设计，提供足够开放的连接能力，则可以为整个安全生态构建默认的数据保护基础，降低企业在选择安全解决方案时的困扰，这样才能真正解决企业数据防泄漏的问题。
02什么是云原生数据防泄漏（DLP）？
国内目前没有对云原生数据防泄漏（DLP）作出明确的定义，但从笔者对目前较为领先的云原生DLP科技企业进行调研分析来看，云原生主要的聚焦点在于云上SaaS应用数据的泄露保护上。因此我给云原生数据防泄漏（DLP）的两个关键定义是：
1.SaaS应用自身具备原生的DLP能力，在不同形态的产品类型上，能做到基本的身份认证、角色权限、授权控制，并且在数据的共享、外发、链接、发布、交换、授权、上传与下载方面提供基本的安全可配置性；
2.SaaS应用自身具备充足的开放APIs，能为第三方的DLP产品提供充分的数据防泄漏控制灵活性。可以通过基于API的方式，对SaaS数据进行分类分级和标签化，提供共享、外发、链接、发布、交换、授权、上传与下载等功能的配置与整改，进而通过结合零信任和UEBA手段做到更灵活的数据控制。
本文主要从云原生DLP这个新技术架构进行展开讲述，但也同时将传统的终端DLP、云桌面VDI等技术作为解决方案的实用补充手段进行讲解，希望能为读者带来更广阔的企业数据防泄漏解决方案的视野，更好地在企业打出数据防泄漏组合拳。
一、背景与驱动因素
1.企业IT应用部署架构演进的大环境
企业IT架构已经逐渐从传统的内网数据中心部署模式迁移至云平台部署，也有不少多云与数据中心混合部署的模式，甚至有不少的企业应用已经将企业IT系统转向SaaS平台，例如常见的企业IM即时通讯、CRM系统、客服系统、在线文档协作平台、云盘、云笔记、项目管理平台、代码托管平台等。这对于安全团队来讲，意味着更多的数据将流转到传统企业安全边界之外的地方进行存储和处理，非受控设备访问、不可控的SaaS数据分享和转发，在这种架构下为数据防泄漏工作带来了新的风险和挑战。
2.外部攻击与内部泄密问题愈发突出
APT组织的入侵与渗透，其目标主要是具有高度商业价值和国家秘密的高敏感数据，技术手段趋于通过办公终端泄密。员工受利益引诱售卖数据，或者不经意扩大数据的分发和共享范围，将文件和代码上传至不可控的互联网Shadow IT，这些都是当今企业安全需要面对的外忧内患。
3.数据隐私合规要求驱动
国家陆续针对数据和个人信息领域发布了《中华人民共和国数据安全法》和《中华人民共和国个人信息保护法》，配套的法规标准也密集出台，跨国企业也需要满足SOC 2和NIST CSF和PRF的一些要求，从而向投资人与客户提供更强的安全信心。这意味着数据隐私合规工作从有能力才做，转变成必须要做。数据防泄漏（DLP）是数据安全与隐私合规的重要组成部分，是数据安全中的基础配套能力，也是衡量数据使用流动是否满足企业业务需求和安全要求的天秤。
4.COVID-19疫情下激增的远程办公需求
自从2020年全球COVID-19疫情爆发以来，世界各地的远程办公需求激增，甚至目前已经迎来了元宇宙办公时代了，员工居家使用BYOD设备访问SaaS化在线文档编辑、业务处理和远程会议已经成为工作常态，但也意味着数据可能被传输到很多企业不可控的Shadow IT网站，造成企业敏感信息泄露。
图片来源：元宇宙办公场景（摘自36氪公众号）
为什么是云原生DLP，它是否足够强大
上图是一个企业已经迁移上云并且业务已经SaaS化的简要网络架构，从图中可以看出我们的访问终端可能包含了全球的总部、各地分支结构、办公设备、移动设备以及部分非受控设备，需要访问的资源分别有SaaS应用（指公有云SaaS）、企业本地化部署（云部署的私有应用）以及企业不受控的Shadow IT。
1.办公全球化，影子IT与BYOD难以管控
跨国公司业务全球化，办公地点全球分布，BYOD、远程办公、外包设备，未知的网络接入场所导致数据泄露点增加。员工随意使用SaaS应用，成为Shadow IT。从上图分析，会发现企业里面非受控设备与Shadow IT可能会与企业内部数据资源进行交叉访问，意味着数据泄露风险发生的可能性非常大。
2.敏感数据位置未能有效识别
企业敏感数据遍布各类不同的IT设施，有结构化、非结构化、半结构化等不同数据形态存储在终端、云盘、NAS、数据库、存储、SaaS应用中。这种跨平台、跨数据结构的数据分布为企业的敏感数据识别、分类分级、数据标记以及数据泄露策略配置带来重重困难。安全有句老话：“你不能保护你不知道的任何事情。”数据分类分级毫无疑问是数据安全工作的基础，资产底数不清晰，就不要谈后续的数据保护策略了。
3.传统DLP解决方案已无法有效支撑云原生架构
在数据必定要上云的情况下，传统的终端DLP和网络DLP框定的边界已逐渐失效。SaaS应用自身的数据分享、转发、公开，或者恶意分享、意外分享、数据泄密等行为已经越来越常见。在探索企业DLP效用时，应把数据、使用行为、数据场景作为一个系统进行分析。从下表的简单分析来看，传统DLP和云原生DLP能解决的数据场景是不同的，但基于云环境的数据防泄漏，显然云原生DLP具有天然的优势。
4. 结论：多云与数据中心混合架构，DLP应使出组合拳
随着SaaS应用广泛使用，企业数据上传至SaaS应用是正常业务需求。但在混合部署的架构下，从上表的分析来看，单纯的云原生DLP也无法解决所有的数据泄露问题，必须使用体系化的DLP架构建设思维，使出DLP组合拳。
笔者曾在《百家| 探索隐私保护数字化解决方案》中为读者介绍过企业搭建数据安全与隐私保护框架的方法，也提供了以NIST Privacy Framework为基础，融合了各类安全合规要求的数据保护框架。本文所介绍的企业云原生DLP架构思想承袭于该框架，并在该框架下覆盖了特定的安全领域，以具体地解决数据安全中属于办公网数据安全方面的数据防泄漏问题。
当企业的数据安全与隐私保护框架设计完善时，所有的安全控制措施都会在整个框架的各个部分得以体现，形成安全技术、安全管理、安全运营和安全合规的小循环。因此，笔者依然极为推荐读者在建设安全体系时，以体系化思维来构筑各项安全活动。
在企业数据防泄漏（DLP）的安全域下，各个安全模块都有各自的功效，具体如下：
1.识别模块
在企业数据防泄漏（DLP）的领域，我们需要做识别的分别有业务场景和数据资产，并通过数据泄露风险分析的方法，将数据防泄漏的需求进行完整识别，以更好地推动DLP体系建设。本文会在数据发现、分类分级数据标签化能力建设和运营方面进行具体介绍。
2.保护模块
保护模块是数据防泄漏的技术体系建设重点，本次云原生DLP的介绍会更倾向于在办公网数据安全方面进行具体介绍，结合云原生DLP+传统DLP+云桌面VDI+零信任+CASB等方面的内容进行整体介绍。
3.治理模块
数据安全运营管理是治理模块的其中一个重要环境，也是本文数据防泄漏运营体系的重点介绍内容。数据防泄漏运营体系将通过介绍如何将数据防泄漏运营通过NIST CSF框架的IPDRR模式进行深度整合，彻底融合到一个企业安全运营框架中。
4.交互模块
数据防泄漏要在企业中实施彻底的培训宣贯，与各相关部门形成良好的沟通机制，才能将DLP策略更轻松地部署到企业的每一个角落。得到各部门和关键相关方的支持，这是DLP策略成功的重要环节。就像信息安全管理体系各过程管理一样，数据防泄漏的目标绩效最终需要通过安全事件、纠正措施、过程更改、变更控制、文件更新，最后落实到培训宣贯中，整个体系才能运转正常，并得到持续改进的机会。
5.内控模块
内控模块在数据防泄漏领域，主要就是对已设定的技术、管理、运营和合规措施做定期的内部安全评估，以发现不足。持续识别法律法规在数据安全与隐私层面的最新要求，为数据分类分级和数据标记的策略提供依据。最后需要对DLP的不足和不合规进行持续的整改和纠正。
根据企业的总体安全目标，数据防泄漏也应该确立明确的目标，才能将内、外部相关方要求与业务目标、数据治理目标保持一致。每个企业的数据防泄漏目标可能不尽相同，企业的不同性质（国企、外企）、不同规模、不同行业、不同风险偏好、不同资源投入的情况下，对于目标的设定都会有所差异。因此，本文暂且以“满足全球办公需求，数据防护策略一致；敏感数据多维感知，实现数据分级保护”为目标，开展整体数据防泄漏框架的设计。
通过上图的数据防泄漏框架可以看出，企业数据防泄漏涉及的IT设施包括网络、终端、移动设备和云，不同的IT设施所需要部署实现的安全技术措施都不尽相同，配合DLP策略运营手段，共同形成DLP组合拳框架，以满足企业数据防泄漏的总体目标。
要理清具体的数据防泄漏需求，首先要在企业中开展重点数据使用场景的梳理，一般在企业数据中心+SaaS混合部署的IT架构下，会有以下几种重点的数据使用场景：
▶企业内部云盘敏感信息（如Office 365/Google Drive）
员工使用云盘等在线编辑的文件作为载体记录敏感数据，例如客户基本信息、员工薪酬信息、财务信息、研发计划等，文件下载到本地终端后可随意外发。
▶对外沟通联系
IM聊天工具与邮件既用作内部沟通，也可与客户或第三方机构联系。商业秘密易通过邮件/消息/文件传输等方式外泄。
▶内外部应用上云，SaaS应用持续增加
内外部应用逐渐上云，SaaS应用逐渐增加，传统的数据中心边界被打破。
▶“云端”文件存储共享、外部链接
云端临时存储的敏感文件（如Slack、Confluence上传文件），或以链接的方式分享敏感文档或数据给第三方文件。共享链接的权限配置错误，或链接设置时间过长导致数据持续泄露。
▶自带设备（BYOD）
员工或供应商使用自己携带的设备访问企业的数据资源，导致企业数据资源被发送到不受控的环境。
▶非管控的Shadow IT外部网站访问
技术人员通过各式IT技术论坛寻求问题解决方案，员工使用未经批准的第三方应用（Shadow IT）上传内部敏感资料，如未知的云盘、云笔记、流程图系统、云代码平台（GitHub、码云）。
通过数据使用场景梳理后，就可以对数据泄露渠道进行枚举了，这是一个必须通过头脑风暴结合实际情况的穷举过程，而且也应该纳入后续运营的持续识别过程中。总的来看可以通过从设备外设、典型传输通道、拍照截屏、邮箱、IM、网盘、云笔记、代码平台、共享盘、NAS存储、SaaS Drive等方面进行完整识别，并且明确列出其传输通道、数据传输/操作场景、信息泄露的具体情况，信息泄露的细节列得越清楚，后续DLP策略将会更清晰。例如USB禁用的情况下，通过审批（仅允许单个文件外传）临时开通USB端口后，短时间内的大量异常数据外泄，是否能够被监控告警或审计？
可参考的数据泄露渠道梳理例子如下：
在对企业的数据防泄漏使用场景和数据泄露渠道梳理完成后，根据数据防泄漏框架，就可以搭建出整个企业的云原生DLP总体架构来对数据安全的各个泄露风险进行处置。整个云原生的DLP总体架构分为七部分，下面逐一介绍：
1.职场办公网络
职场办公网络指企业的办公室环境，包括总部和分支机构的所有办公PC、公司配发的笔记本电脑、企业云桌面VDI资源。该环境是一个相对可控的办公环境，各类传统的安全管控设施最为完整。在该环境中，我们可以在终端中部署包括终端DLP、安全桌管、CASB连接器、EDR、杀毒软件等一系列的Agent来进行终端的安全防护。在该环境中，我们可以配合云桌面（VDI）、远程浏览器隔离（RBI）和桌面沙箱（Sandbox）来做不同数据密级的流动限制，禁止高密级数据向低密级环境流动。云原生DLP的实现重点是CASB连接器，它可以将终端侧的流量通过PAC文件的方式引流到CASB的就近POP云节点中，提供在线（Inline）的数据防护能力。当然，如果有安全厂商能将所有能力集成在一个Agent中，企业肯定是欢迎的，但是各个厂商会有自己的细分领域优势，做到又全又好的产品是极为少见的。笔者建议多点通过POC测试来检验产品能力。
2.BYOD & 远程访问
在应对员工、供应商、实习生、疫情隔离人员使用BYOD设备和智能手机时，我们采用几种方法使这类设备重新受控，使用哪一种方法，取决于公司的具体数据使用场景，以及对不同部门采用不同的策略而定。
■云桌面VDI：通过纯虚拟云桌面给办公人员，使办公人员的BYOD设备纳入到可控的VDI管控范围，本身VDI也会安装EDR、桌面管理、终端DLP，也通过PAC文件引流到CASB的就近POP云节点；
■云桌面VDA（Virtual Delivery Agent）插件：通过VDA插件替代传统的RDP协议，为BYOD设备提供远程连接到公司办公PC的方式，可以远程遥控办公室的PC电脑；
■远程浏览器隔离（RBI）：当BYOD设备只需要通过浏览器完成工作时，可以使用远程浏览器隔离（RBI）的方式，提供像素流或者CDR技术（内容解除和重建）的远程浏览器遥控，防止数据泄露，也可以防止病毒在终端运行；
■移动设备MDM与MAM：如有需要使用移动设备（智能手机、平板）访问公司资源，则移动设备必须安装公司指定的MDM和MAM，或者EMM等相应的移动设备管理系统，以及安装CASB连接器App。其最主要的功能是在移动设备中开辟一个虚拟的工作办公空间，里面安装企业允许的App程序，只有在沙箱里面的App才能访问公SaaS应用的租户资源以及公司内部的相关数据资源，即使下载了公司的数据文件，也无法通过移动设备工作办公空间外的应用程序进行调用、存储。在员工离职或移动设备丢失时，可以远程清空移动设备该工作空间的数据内容。该方案最大限度保护了工作数据以及员工的个人隐私。
3.CASB云安全访问代理/SASE安全服务边缘（云原生DLP的Inline模式）
图中中间的部分就是本文重点介绍的云原生DLP的在线（Inline）模式。目前市面上通常是CASB云安全访问代理或SASE安全服务边缘能够提供该类的能力。这两种形态的产品，其根本功能都是由安全厂商在公有云上提供的一整套具备SD-WAN网络基础，提供全球就近POP接入的云安全接入点，通过该接入点提供包括数据防泄漏（DLP）、远程浏览器隔离（RBI）、云入侵防护（IPS）、云沙箱、云防火墙、URL过滤、防病毒（AV）、SSL流量检测、Shadow IT监控、DNS安全、带宽控制以及可视化的多项安全功能。
所有职场办公网络、BYOD和移动设备等受控设备，都可以通过CASB连接器、PAC文件或者办公场所IP SEC / GRE通道等不同方式，将流量全部引流至CASB云安全访问代理或SASE安全服务边缘，使各类数据流量得到防护和监控。
本文将重点将其DLP、RBI、URL过滤、Shadow IT等方面进行重点介绍。
4.应用程序资源（SaaS应用原生DLP）
应用程序资源分为SaaS应用（指公有云SaaS）、企业本地化部署（云部署的私有应用，下面简称私有应用）以及企业不受控的Shadow IT。其中SaaS应用和私有应用都会与企业IAM进行集成，并将SSO单点登录入口源设置为CASB，并且阻断其他网络来源的登录请求。这种方法可以杜绝非受控设备访问SaaS应用和私有应用的风险，做到入口收敛和攻击面收敛。
还记得云原生DLP的定义吗？其中一个关键的定义就是SaaS应用自身就需要具备云原生的DLP能力。目前笔者观察到不少做到好的科技巨头在其产品中已经集成了非常强的云原生DLP能力，就像Microsoft的整套云安全能力，就包含了信息保护与治理（IPG）、内部风险管理（Insider Risk Management）、发现与响应（Discovery & Respond）和合规管理（Compliance Management），其中微软信息保护（MIP）更是目前为止与将非结构化标签集成得最好的一个科技巨头，其数据标签可以用到不同的数据保护场景，包括DLP、Teams、Azure Storage、SharePoint和Exchange等场景的发现、分类、保护和监控。Google的G-Suite套件在BeyondCorp零信任架构的加持下，在数据保护能力方面也非常优秀，包括Chrome浏览器的基于情境感知的零信任准入机制以及G-Drive和Gmail的数据发现、标签、DLP能力都与微软有得一拼，而且更多的新功能也在持续迭代过程当中，不少好用的功能已经在测试发布。类似Salesforce等全球最多人用CRM系统，其身份与访问控制和数据控制的能力都已经打磨得非常到位。
总体来讲，一个SaaS应用在数据保护能力上是否充分，在企业的系统选购过程，都应该由安全团队作为关键的技术评审环节人员作出评价，确保SaaS应用具备充分有效的数据防泄漏能力。
5.云原生DLP的API模式
这是组成云原生DLP的另一个必不可少的部分，这个部分的部署有两种方法。
方法一：是单独购买云原生DLP细分领域做得比较好的产品，目前观察到的包括Nightfall AI和Altitude Networks等比较细分的产品。他们在逐步扩展能支持的SaaS产品范围，做到更深入的API集成。他们普遍能提供的DLP功能有以下几点：
lSaaS应用数据发现和识别：包括数据标签、文件名、创建者（IAM关联）、创建时间、安全设置、有访问权限和执行权限的所有操作（例如编辑、创建、查看、下载、重命名、共享等）的发现和识别。这个功能完全依赖于SaaS应用本身的API开放性，开放能力越强，云原生DLP的功能就越强，他们是一个生态内的持续迭代过程，是一个很有盼头的正向循环。
lSaaS应用共享风险的纠正（整改）：当云原生DLP发现SaaS应用基于敏感、机密标签时，就可以设定不得全员共享或不得外发共享的设定，当在SaaS应用扫描中发现该类违规，则会通过API进行文档权限的纠正。企业可以随时根据公司实际情况来修改DLP的规则，来满足内部的安全政策。
●关系图谱分析：建立数据使用关系图谱，哪个用户（主体）访问哪些文件（客体），以及之间的访问控制规则，可以可视化地观察和了解员工的数据使用和共享情况，也能映射企业与第三方的数据共享情况，包括合作伙伴、供应商等。
●行为分析：提供基于机器学习技术对行为进行建模，发现用户异常行为。例如一个员工在离职前大量从Office 365 或 Google Drive下载文件，共享给第三方等与正常行为发生严重偏离的情况，都会进行告警，并调用API进行纠正。
方法二：采用本身CASB自带的API模式来完成云原生DLP的API模式集成，该方法的考虑因素是成本节约，而且与本身CASB的云原生DLP共享一套策略，但可能在云原生DLP的控制力度上不如单独的云原生DLP产品。
6.非受控设备
非受控设备指没有安装任何公司安全管控软件的设备，根据CASB的策略，可以完全禁止这些设备访问SaaS应用和私有应用，也可以对其限制为只能通过RBI来限制查看部分非敏感资源。
7.安全智能管理
安全智能管理，主要是整套云原生DLP的智能大脑，为整套体系提供数据发现、身份管理、日志采集汇聚与异常行为分析等相关功能。
以上就是云原生DLP总体技术架构的总体介绍，下面针对每一项重点的技术，再进行展开描述。
云原生DLP在线（Inline）模式的关键组件就是CASB。在国内CASB一直不温不火，主要是由于SaaS应用未大规模推广，以及国内企业喜欢私有化部署SaaS应用，导致CASB无法做到规模化和有效的部署。但最近火热的SASE，因为具备SD-WAN网络基础和零信任SDP理念，可以使不同类型的网络轻松地连接在一起，无论公有云SaaS版、本地部署SaaS、私有应用都可以轻松通过SASE进行接入和控制。SASE是一种更广泛的云安全接入能力，同时能提供CASB、SWG、ZTNA、RBI和UEBA等众多网络安全能力和DLP能力。据笔者观察，这应该是国内采用CASB功能的合理过度技术。
无论CASB或者SASE技术都无关紧要，笔者介绍的主要是他们这个技术特点下的五点主要能力：
1. 云上应用身份认证和访问控制
受控的办公终端安装CASB连接器Agent，利用PAC文件将流量重定向到CASB，通过API和IAM的对接，实现云上应用身份认证及登录访问控制，阻断非法访问，禁止非认证终端用户访问云应用。
2. 云上应用DLP防护
云上应用的上传下载流量需经过CASB，实现敏感数据监控阻断。可以将传统上网行为管理的URL过滤能力进行云化，以满足全球各办公地点一致的上网行为管理。
3. 互联网访问控制
终端Agent流量重定向CASB（*流量转发粒度可灵活配置，例如按应用类别进行转发，将部分延迟敏感性较高的网站进行例外处理），终端的所有互联网流量将通过CASB，可有效发现、监控访问互联网上的Shadow IT的Web应用。
4. 安全威胁防护
互联网访问的流量通过CASB时，CASB的威胁防护提供云入侵防护（IPS）、云沙箱、云防火墙、URL过滤、防病毒（AV）、SSL流量检测、DNS安全、带宽控制以及可视化的多项安全功能，可对暴力破解、钓鱼、0-Day漏洞、病毒、DNS中毒等安全威胁进行拦截保护。
5. 网络级DLP防护
终端Agent可实现SSL流量劫持，解密流量，识别流量内容，有效地对终端DLP防护的未拦截遗漏数据进行拦截，实现网络防护补充。如果企业本身已经部署了网络DLP，那么CASB也可以将云上的ICAP文件传输给本地的网络DLP，做进一步的DLP流量检测。
如上图所示，CASB的部署方式有两种，分别是在线（Inline）模式和API模式。
1.在线（Inline）模式主要应对数据动态传输（Data-in-Motion）的情况，可以提供以下功能：
●SSL加密流量检测；
●多终端、多网络访问的统一数据防护策略；
●精确数据匹配（EDM、IDM & OCR）；
●文件类型、上传/下载、URLs控制；
●SaaS应用访问控制；
●远程浏览器隔离（RBI）；
●数据防泄漏DLP能力集成。
2.API模式主要应对的是数据静态存储（Data-at-Rest）的相关风险，如要通过与SaaS应用的API集成进行实现，主要功能有：
●通过APIs 扫描SaaS应用存储的数据；
●通过APIs 对外部分享链接、IM外部群组、数据互联网开放进行扫描；
●通过APIs 对SaaS应用的错误配置进行检查，并自动修复；
●强制执行数据文件共享策略（阻断、只读、隔离）；
●自动采取行动进行风险整改（关闭链接、删除分享文件、事件报告）。
CASB连接器Agent集成了零信任准入检测的能力，秉承“永不信任，始终验证”的思想，使用CASB连接器验证用户的设备状态，判断终端入网的风险级别，从而提供不同级别的网络资源访问能力。该CASB连接器还可以通过第三方与所有主要的EPP/EDR/XDR提供商（例如，CrowdStrike、微Defender和SentinelOne）的集成来获取设备状态，包括系统版本、软件安装情况、注册表情况、浏览器情况、安装安全软件情况、病毒情况等设备信息，形成设备指纹。
当CASB的零信任检测认为设备的健康状态不符合安全政策要求，则禁止或受限访问对应的网络资源，目前的管控颗粒度一般是应用系统域名级别。
零信任的动态授权究竟能管到多细，这取决于组织在零信任动态授权上投入的人力资源和开发资源。从笔者观察来看，客体资源大概可以分为网络级别（禁止/允许）、应用级别（域名禁止/允许）、应用功能/URL级别（功能页面和URL的禁止/允许）以及数据级别（一个页面的数据访问的禁止/允许，或脱敏显示）。可以看出，越往细的粒度来进行管控，技术难度和运营难度都会成指数级别增长，在投入产出比（ROI）不高的情况下，无谓抠技术细节。从实践角度来看，能做到应用级别（域名禁止和允许）已经非常不错，组织可以分为敏感应用、普通应用和全网禁止访问等三个级别，基于CASB连接器Agent对终端的风险状态判断，来动态授予三个不同级别的客体资源，可以做到简单的动态授权。
评审：安全团队与采购部门应建立一个SaaS应用采购的技术评审流程，也可以成为立项流程。评审过程中，需要对即将采购的SaaS应用必要性、可行性、重复采购以及安全架构进行严格审查，确保采购回来的SaaS应用具备SSO单点登录接入能力，能与CASB进行集成，将CASB作为唯一的登录通道。如果SaaS应用没有SSO功能，则次好的方法是通过企业网络出口白名单进行访问，禁止互联网直接连接。
监控与识别：首先建立SaaS应用清单，对网络中所有访问非受控SaaS应用清单中的域名，并且存在数据文件上传行为、敏感关键字输入行为的网站都进行记录。
禁止：通过CASB的URL过滤，先将能够识别到的云盘、云笔记、同步盘、代码平台等具备上传数据文件的网站进行上传封禁，并按需开通。CASB中其他可选的安全策略包括允许、阻断、禁止上传、带宽控制、时间控制等，可以结合企业实际情况进行设定。
纳管：对监控识别结果进行定期汇总，如果发现企业内多人使用同一个Shadow IT，则判断是否需要为它“转正”成为公司批准的SaaS应用。如果公司已经有类似应用可以满足需求，则应引导员工使用经批准的应用。俗话说，关了一扇门，总要开一扇窗，否则总会有员工绕开我们的安全政策。
对于非受控设备访问正常的网络资源，一定要进行严格控制，与组织毫无关系的访问必须采用阻断手段，从而收敛SaaS应用的暴露面。如果是BYOD或者供应商临时访问的情况，则可以考虑远程浏览器隔离（RBI）或者云桌面VDI的访问方式。这两种访问方式可以基于不同的数据使用场景进行，下面分别介绍。
1.远程浏览器隔离（RBI）
远程浏览器隔离（RBI）是简单来说，就是用户不使用本地的浏览器直接上网，而是连接到一个远程服务器上，用服务器上的“远程浏览器”上网。全程数据只落在远程服务器上，不落在本地，达到数据不落地的效果。RBI与VDI相比，具有更轻量化的使用逻辑，无需安装Agent就可以使用，特别适合手机、笔记本、平板等访问场景，以及工作中属于轻度使用浏览器就能完成业务的部门，用户体验比VDI更好，但RBI无法应对C/S架构软件的工作内容。RBI的好处在于一方面提供数据防泄漏能力，另一方面提供了阻断恶意代码运行的功能。RBI一般有两个流派，一个是像素推送，一个是DOM重建来达到安全保护目的，两种方法各有优缺点。目前主流厂商包括Cloudflare, Zscaler, McAfee等，在RSAC2022创新沙盒大赛中，Talon这家专注于浏览器安全解决方案的企业也成功夺冠。
像素推送：CASB云节点上通过容器化实例的方法创建一个远程浏览器，该远程浏览器负责访问目标网站。用户在本地浏览器上通过点击、滚轮、鼠标移动的命令都会通过加密通道传送到远程浏览器并进行遥控，远程浏览器会将对应命令执行，并通过像素流视频的方式将网页的显示结果返回给本地浏览器，达到远程遥控的效果。特点是网络流量较大，网速不好的情况下，高分辨率的视频返回的图像会模糊和失焦，用户体验可能会打折扣。
DOM重建：DOM 重建尝试在将内容转发到本地端点浏览器之前对 HTML 和 CSS 等进行清理。通过重建 HTML 和 CSS 等来消除活跃代码、已知漏洞，以及其他潜在的恶意内容。但HTML和CSS的重构，没有办法完全杜绝黑客利用重构漏洞形成的攻击，也可能因为网站更新改版导致重建失败而无法显示，需要不断维护DOM重建的能力。
2.云桌面VDI
如果用户除了使用浏览器外，还有其他本地文档需要进行处理，例如Office编辑、开发，或使用非Web系统，则应该使用云桌面VDI，以获得最完整的工作空间。员工和第三方人员可以在BYOD电脑安装VDI客户端，访问云上桌面，获得与本地电脑无异的完整工作空间，也可以做到“数据不落地”的效果。
云原生DLP还有一个重要的功能，就是非受控SaaS租户控制。现在SaaS应用一般都会有租户机制，有些SaaS应用可以使用个人账号，也可以使用企业账号进行登录。如果员工可以同时在企业网络中登录个人账号和企业账号，则可能存在将企业数据传输到个人租户空间中的风险，供应商租户也是同一个道理。所以CASB应该能做到SaaS应用租户级访问控制，能禁止或受限地访问个人账号和供应商租户，可选的受限策略包括完全禁止、只读访问、禁止上传等。这项功能基本只会出现在少数的CASB厂商能力中，传统的网络DLP基本没有这项功能，这也是云原生DLP的优势之一，在CASB选型时需要特别关注。
云原生DLP对于数据精确匹配的规则上出了传统的关键字和正则表达式外，也具备EDM（精确数据匹配）、IDM（索引数据匹配）和OCR（光学字符识别）技术，进一步增强云原生DLP的数据识别、规则命中的精度。
lEDM技术：精确数据匹配（EDM）是可以降低数据泄露告警误报率的技术。EDM通过将业务生产数据库中的个人数据（客户数据、员工数据）记录进行Hash摘要，并将摘要上传到CASB中，只有当上传的数据中匹配了对应的摘要信息，才进行告警，可以大大提高告警准确度。
lIDM技术：索引数据匹配（IDM），是一种数据内容进行模糊匹配的算法技术。该技术主要用于检测各种非结构化储存的文档与样本文档的相似度，检测内容包括文件头、文件内容（段落、句子）、文件格式。但可能存在文档段落轻微改变后就无法识别的问题，例如对Excel识别后，将Excel转换为PDF导致分页后的数据，是无法被准确匹配的。
lOCR技术：光学字符识别（OCR），对图片中文字的形状进行识别辨认，将其转换成文字信息后，再通过DLP规则进行匹配，但准确率会存在一定的误差。
这三种手段可以作为补充识别手段，但不能百分百依赖，而且其功效需要在企业内部进行大量测试后，才能对误报和漏报做到心中有数。
Google基于BeyondCorp零信任的机制为整个G-Suite应用提供了丰富的数据保护功能，其中Google Drive是一款在线文档编辑与文件存储的系统，Google提供了云原生的DLP能力，支持探查发现留存在云端网盘中的敏感信息，从而确保云端网盘中的数据符合公司合规政策（信息隔离墙/客户资料保管/商业秘密保护）。
●文件标签功能：作为遵循合规政策的一部分，用户可为文档添加数据分级标签(公开/内部/秘密等)，并将分级结果与Gmail外发策略联动，如带内部标签的文档外发需审批。Google的数据标签分为敏感级别标签与其他标准标签，可以根据企业需要进行设定，在DLP运营章节会详细介绍。
●数据合规探查：对个人及共享云端网盘进行敏感数据扫描，确保客户资料保管及其他数据存储符合公司数据安全政策，并强制执行保护策略，如敏感数据禁止下载，转发等；
●数据保护报告：基于Google预定义敏感字段，分析用户存储及分享数据类型，生成云端数据保护报告，如最常共享的数据类型，包含敏感内容的云端网盘文件数量等。
Gmail的云原生DLP策略也非常丰富，对于Google Drive中设定好的相关数据标签，可以被Gmail进行识别和调用。同时Gmail也支持负责的规则设置，OCR检测，全球语言识别，多文件类型识别等能力。通过搭配不同的属性，能对邮件的收件人、发件人、敏感字段、统计信息进行复杂的规则匹配，从而实现邮件DLP阻断。
另外，Gmail也支持将邮件的下一跳路由设置为其他第三方邮件DLP产品，由第三方邮件DLP产品提供敏感词检测，并提供基于组织结构（AD域）的邮件例外放行的能力，例如可以由部门经理或安全管理员进行审批放行。
全球目前专注于云原生DLP的厂商不多，如前面介绍过，他们都是利用SaaS应用程序提供的API接口来完成对应的DLP和风险纠正。从Nightfall AI和Altitude Networks的云原生DLP在SaaS集成的进程来看，基本上对Slack、Google Drive、Github、Confluence、Jira、Salesforce、Box、Office 365等主流SaaS都有一定的支持。
以Slack的云原生为例，云原生的DLP支持以下主要功能，这些功能基本涵盖了一个IM软件所具备的数据泄露功能：
▶实时扫描整个 Slack 组织的所有文件和消息；
▶实时扫描公共频道中的所有文件和消息；
▶机器学习训练的检测器；
▶支持的各种文件类型；
▶支持光学字符识别 (OCR) 文件扫描；
▶可自定义检测器和检测规则；
▶用于创建规则和调整准确性的检测引擎；
▶自定义警报消息；
▶自动和手动删除和最终用户通知；
▶细粒度的访问控制；
▶自动化工作流程；
▶实时执行策略；
▶扫描所有预先存在的数据；
▶自动和手动隔离敏感数据；
▶自动和手动编辑消息中的敏感数据；
图片来源：Nightfall AI官网
图片来源：Altitude Networks官网
国内企业的IM聊天软件，例如企业微信、飞书、钉钉能够开放这些API功能，相信能为IM的云原生数据防泄漏提供一个高成熟度的DLP能力，非常期待。
相信读者都应该十分清楚，数据安全治理的基础就是数据分类分级，但目前提的比较少的是数据发现和数据标签化能力。整个逻辑是先数据发现，再分类分级，打上标签，标签再提供给数据安全系统使用。
目前国内市场在结构化数据的分类分级逐渐成熟，有不少的安全厂商已经具备数据库扫描发现的能力了，但非结构化数据分类分级的专用工具则不多见，通常由终端DLP厂家代劳。终端DLP自带的数据分类分级和标签，比较难被其他数据安全产品使用，缺乏独立性，也可能导致企业中存在多套不同的数据标签，引起不必要的维护量。
我们要寻找的是一种能够跨越数据结构和不同平台的数据发现、分类分级和数据标记平台，无论结构化数据、非结构化数据、半结构化数据都能识别，无论在终端、存储、数据库、数据仓库、文件服务器还是SaaS应用中的敏感数据都能发现，最终在企业中对同一种数据提供统一的数据标签。同时，这个标签可以传输给DLP、CASB、OA审批流程、加密脱敏设备、匿名化系统、DSAR（数据主体权利请求）、数据映射（Data Mapping）、SOC/SIEM所使用。在笔者对该类型系统的调研过程中，发现国外的Spirion、Titus、Boldon James和Netwrix等几个专注于数据发现、分类分级和数据标记的厂家，具备一定的数据标签整合潜力，希望国内安全厂商在后面也能跟上步伐。
至此，云原生的DLP能力已经介绍完毕，但笔者前面提过，企业的整体数据防泄漏，不可能单靠云原生的DLP能力就能完全覆盖，传统的终端DLP和安全桌管依然能为数据防泄漏提供不可代替的能力。特别是企业有大量的C/S架构的应用程序的时候，云原生DLP是无能为力的。
终端DLP和桌管一般能提供以下能力作为整个体系的补充：
■禁止外设及移动设备连接：通过桌管实现非授权外设及移动设备禁止连接公司终端，防止数据文件外泄；
■拍照、截屏及打印的水印：通过桌管实现屏幕、截图及打印水印，使数据通过拍照和打印对外泄密时可追溯。水印有明水印、暗水印、文档修改痕迹等不同类型，企业可以根据成本和实际目的来选择；
■敏感字段内容识别拦截：通过文件内容识别、应用输入、剪切板及图像OCR，对敏感字段信息识别，实现对相关信息告警拦截并禁止对外输出发送；
■数据发现及分类分级：通过应用程序识别及内容扫描任务，实现非结构化数据分类分级，识别敏感数据文件并进行分类分级标签化，有利数据文件管控。虽然DLP也有数据发现能力，但笔者建议采用更独立的第三方数据发现能力，以获得更好的可集成性。第三方独立工具的集成方式包括API对接和标签数据库读取等；
■文件上传外发管控：管控IM、网盘、邮箱等网上应用，结合数据分类分级，实现文件上传外发的管控；
■流程化自动审批：对文件特权发送审批实现流程化和智能化，实现审批可追溯和可视化。
VDI是非受控设备控制的一个重要功能，但VDI具体应该如何设置才能实现良好的数据泄露管控呢？要用好VDI，首先我们应该对VDI的使用场景进行识别，并结合企业不同部门对工作的使用习惯来决定VDI使用方式。其次是做好VDI不同镜像模板的分类，使其放在不同的VPC里，通过设置不同网络访问策略达到不同级别的网络环境区分。
如上图，我们对VDI使用分为两大类，第一类是因网络隔离需要而使用，第二类是因非受控设备访问内部网络资源而使用。
1. 网络隔离使用VDI
网络隔离使用VDI，从访问互联网的角度可以分为正向使用、反向使用和完全隔离三种子类别。
▶正向使用，指本地PC终端不能上互联网，而使用VDI上互联网。这种模式下，PC终端是高密级环境，VDI是低密级环境，文件不能从PC终端发送到VDI，但可以从VDI将文件发送到PC终端。该模式通常用在研发部门、UIUX部门等对终端PC有较高性能要求的部门；
▶反向使用，指本地PC终端可以上互联网，但VDI不能上互联网，可以受限访问部分内部网络和固定的外网域名。这种模式下，PC终端是低密级环境，VDI是高密级环境，文件不能从VDI发送到PC终端，但可以从PC终端发送到VDI；该模式常见于需要受限处理个人数据的部门，例如客服部门；
▶完全隔离（数据安全屋），这是在反向使用的基础上，对VDI可访问的网络资源进行进一步收缩，完全不能访问任何互联网和任何内部网络资源，是一个完全封闭的独立虚拟终端，用于需要将生产敏感数据进行本地化统计分析的情况。
2. BYOD使用VDI
VDI另一种使用方法就是为使用BYOD的员工和供应商使用，使其能在不可控的环境里面访问到企业内部资源，员工和供应商的无法从VDI中将数据直接拖到本地PC，但其他互联网访问渠道我们也可以通过云原生DLP、终端DLP等手段进行兜底。
企业的移动设备也必须通过技术控制措施将其纳入受控设备进行管理，其中常用的工具就是企业EMM或者是MDM + MAM的组合，来达到移动设备和移动App的管理。
1.MDM通常具备以下主要功能：
■越狱或ROOT权限检测
■设备密码管理
■设备远程擦除
■强制数据加密
■远程锁定/解锁
2.MAM通常具备以下主要功能：
■分隔工作及个人应用数据
■部署软件商城
■部署企业应用
■强制应用更新
■预设应用配置
在数据防泄漏方面，显然是移动设备上的应用沙箱能够提供最强大的数据隔离效果，所有企业的App可以安装在应用沙箱中，并且通过CASB连接器App打通访问内部资源的加密通道。从企业App上下载的数据，不能被移动设备的其他非应用沙箱内应用进行读取和使用，做到强制的工作空间隔离。
企业除了实施单点的DLP外，为了获得更强的综合管控，做到数据防泄漏的可视、可控和可管，必不可少的方法是完成数据安全SOC的建设。通过对CASB、终端DLP、桌管、VDI、移动设备管控系统以及SaaS应用埋点日志数据的采集，进行日志汇聚后放入Splunk中提供大数据分析能力，结合多源威胁情报（暗网的企业数据售卖情报）进行综合分析，为数据安全团队提供告警降噪、异常行为分析、安全事件追踪溯源和SOAR等必要能力。
云原生DLP架构所采用的技术细节又多又广。要把DLP产品用好，关键不是部署实施，而是对DLP策略和规则的运营。为了使整个DLP运营体系与网络安全运营进行整合，笔者用NIST CyberSecurity Framework的IPDRR模型为基础，将DLP日常运营措施嵌入体系之中，使企业的网络安全和数据安全运营相适应，做到更好的资源调配，形成安全合力。具体的云原生DLP运营体系如下图所示。
数据防泄漏是数据安全治理的重要环节，而数据安全治理的基础就是分类分级。笔者观察到很多企业做完数据分类分级后，其分类分级的标签未能被分级保护策略有效地利用，其结果可能是分类分级做完，只得到了一张分类分级Excel表。终究其原因，笔者认为是分类分级没有以价值和目的为导向，导致分类分级结果缺乏实用价值。
笔者提倡的一种数据分类分级思路，要以数据标签价值和目的为导向的，实用主义的数据分类分级方法，其分类分级结果一定要以能被充分利用为目标。在数据安全和隐私保护领域，有大量需要基于数据标签来工作的控制活动，举几个简单例子：
◆国家数据安全法和网络安全法都有要求对数据实施分类分级；
◆国家重要数据分级与企业数据分级存在不同，需要进行级别映射和维护；
◆不同数据类别和级别与DLP策略应该相适应；
◆不同类别和级别的数据应该实施不同的访问控制、数据加密、脱敏和匿名化策略；
◆不同类别和级别的数据使用应该得到不同层级的Data Owner和相关方的审批；
◆不同类别和级别的数据应该与隐私保护中的数据库存和数据处理活动相关联；
◆不同类别和级别的数据在响应DSAR（数据主体访问权利）时应采取不同流程；
◆不同类别和级别的数据在数据保留时间策略上有所不同；
读者是否有想过上面的多个安全活动，其实都可以通过不同的数据标签进行识别和利用？下面逐一讲述。
1. 数据分类分级--法律合规要求
从《数据安全法》和《个人信息保护法》到《重要数据识别规则》，以及各行各业出的数据分类分级指南，对数据的具体分类分级方法都存在或多或少的区别。企业在实施具体的数据分类分级的时候会遇到十分困难的定级问题，不清楚数据应该怎样定级才能符合法律法规、标准、行业规范的各类要求。
其实笔者发现是有办法做到数据类别和级别的调和的，那就是分层数据标签模式（Schema），借助统一的、跨数据结构、跨平台的数据发现、分类分级和数据标记平台，实现对统一数据的多标签标记，是协调各类不同法律法规要求的主要办法。
2. 数据分类分级--统一数据标签平台
在前面的云原生DLP架构中已经介绍过这个统一数据标签平台了。在我们具体实施数据分类分级和标记的时候，我们可以利用这个平台做定期的数据扫描和数据标记，使组织内所有不同数据结构和存储于不同数据平台的数据都被充分发现，配合数据分类分级人工服务，在平台上做到企业数据资产的可视化管理。
3. 数据分类分级--数据隐私组织
数据分类分级人工服务是必不可少的，再好的工具都只能辅助你更快地完成分类分级工作而已，但具体数据类别和级别的沟通，依然需要繁重的人工沟通、协调和反复确认。这个时候，一个良好的数据安全与隐私治理组织就能助你事半功倍完成任务。现在企业内一般都会在各个部门设置安全专员/安全接口人等角色，而数据治理侧也会设置Data Owner和数据技术负责人，在企业来看，这些接口人很可能都是同一人。因此企业可以考虑将Data Owner、数据技术负责人与安全接口人等角色进行整合，使这些跨部门协调和上传下达的职能人员能够更好地起到沟通桥梁作用，企业可以设计合理的奖励机制对接口人进行激励，使接口人能够成长，并成为部门内部信息安全和数据隐私的倡导者（Advocate）和领跑冠军（Champion），使业务部门和安全部门实现双赢。一个良好的数据安全治理组织架构，一般分成决策层、管理层、执行层和监督层，这与大多数的管理体系设计保持一致，这样的组织架构层次分明，也具备持续改进的基础。
对于非结构化的数据分类分级，企业可以充分利用好安全接口人机制，并且将非结构化标记的工作赋能给接口人和业务部门，让他们一起从业务数据文件使用的角度协助安全完成数据文件的标记，我们称之为“用户驱动型数据分类（User-Driven data classification）”。
4. 数据分类分级--分层数据标签模式
分层数据标签模式，简单来说就是可以通过为一份数据进行多种标签的标记，使同一份数据可以通过不同维度进行统计分析，以及被使用。通过这种方法，只要我在企业内维护好一份主数据，数据标签就可以通过其元数据（属性）进行结构化设计了。
如上图所示，一般企业内部的数据定级都是外部公开、内部使用、敏感数据和机密数据，但可能部分数据会同时属于国家的重要数据，又属于个人数据类别。这种情况下，仅靠单一的数据分类分级标签，没有办法对各类不同维度进行标记和定义，也就造成企业数据分类分级时的痛苦。
但只要我们对数据的元数据通过标签模式进行设计，我们就可以轻松应对不同维度的数据标记要求了。如上图所示，一个数据库的表，或者一个Office文档，一个Google在线文档，他都可以通过数据标签模式定义其不同维度的数据标签，例如数据级别标签、数据责任人标签、数据共享情况标签、监管标记（重要数据、GDPR）、数据保留期限标签、加密技术标签数据类别标签、隐私类别标签（PII\PCI\PHI）、管辖国家标签等等。通过这些标签，我们可以轻松地对标签进行多维度统计分析，也可以将标签通过API或者数据库读取的方式被其他数据安全系统、审批流程系统所读取，从而实现基于分类分级标签的数据保护策略。
当然，根据企业对于数据标签的紧急程度，可以分阶段来实施数据标签。一些解决方案只支持每个文档两个标签，尽管理论上大多数可标记文档可以接受更大的数量。如果你的场景和工具只支持两个标签，可以优先对“数据级别（安全标签）”和“数据所有者（业务标签）”进行标记。这些标签可以使数据安全团队专注于正确的业务流程，访问以及 DLP 控制，并让数据所有者定义一个应该有权访问文档的范围。对于安全团队来讲，这两个标签可以作为第一优先级进行实施。
不同数据结构的标签具体实现方法如下：
●数据库或数据仓库：有两种方法。一是在建数据表时预留数据列作为数据标签的载体。二是在统一数据标签平台向其他数据安全系统提供该数据的标签读取API；
●离线Office文档：可以通过统一数据标签平台为Office文档的元数据属性加上标签；
lGoogle/Office 365在线文档：可以通过统一数据标签平台的API为在线文档提供数据标签。
读者要注意的是不是每一种文件类型都支持元数据修改的，如果不支持的情况下，只能通过在文件内容里面进行对应的标记，可能会对文件内容进行修改。下面罗列出常见的文件支持标签/标记的类型：
在云原生DLP架构建设时，已经对数据使用场景和数据泄露渠道进行了识别，但随着企业的收购合并、组织架构调整、IT基础设施改变、数字化转型、业务变化和引入新应用系统的关系，数据使用场景会发生变化，我们需要及时对这些变化进行识别。
●收购合并：一个企业在收购合并时，必然会导致数据范围、数据类型、数据规模发生变化。安全团队应利用好接口人，做好公司收购合并的变化识别，及时启动场景识别；
●组织架构调整：互联网公司和快速发展的企业通常都会频繁调整组织架构，组织架构调整会带来此前安全和数据接口人更换，数据审批链变更，数据权限蔓延等一系列的问题；
●IT基础设施变更：指服务器、数据库、数据仓库、数仓、文件服务器、终端、VDI等等基础设施的变更，会导致此前的数据识别和场景识别发生变；
●数字化转型：很多企业在数字化转型的时候，都会存在纸质文档录入电子档，本地数据迁移至云等不同的转变，因此在企业数字化转型时，应该做到及时的识别；
●业务变化：业务变化必然带来数据使用场景的变化；
●引入新应用系统：新的SaaS应用和私有应用，都会带来数据适用场景的变化；
当数据使用场景更新后，紧接着需要实施的就是数据泄露风险评估。该评估可以参考国标GB/T 20984 信息安全风险评估规范 以及ISO/IEC 27005等相关标准进行实施，主要方法离不开可能性和影响评估、风险定级、管控措施有效性评估、残余风险评估等相关的方法论。风险评估从来不缺乏方法论和过程，重点是对威胁和脆弱性的枚举，这个过程需要安全团队与业务部门进行适当的头脑风暴，并且注意收集业务案例来逐步丰富。当然，合适的数据泄露风险评估工具能帮助企业快速完成评估，例如类似OneTrust等隐私管理平台的数据安全评估模块可以助你事半功倍完成对应的评估工作，并且可以基于正规的风险评估过程对风险进行识别、定级，也可以创建风险处置任务、风控控制措施，做持续的计划跟踪管理。
DLP运营，少不了对敏感数据规则的不断优化。这是一个繁重的任务，也是数据安全团队需要投入大量人力资源的领域。在敏感数据规则运营商，一般遵从以下三个步骤：
●依据：不同的司法管辖区对敏感数据的定义可以参考各地区的相关法律、标准指南和行业规范，从而作为敏感数据识别的重要依据。同时，数据泄露风险评估的结果，也应该作为依据输入来源；
●设置：DLP产品一般都会有开箱即用策略，也能提供敏感关键字、正则表达式以及EDM、IDM和OCR等数据规则识别能力。所有的规则都要考虑告警阈值、语言、准确率等关键要素。其中阈值的判断往往是一个反反复复的过程，要综合考虑数据安全团队的人力资源和告警数据来判断阈值大小设置的合理性，同时也要不断在SOC中做告警降噪；
●验证：有不少的DLP策略验证网站可以给策略实施的正确性提供验证能力。所有设置正式发布前，应该得到充分验证和变更管理。
终端的账号权限收敛和桌面管控是做好企业数据防泄漏的基础性工作，没有这几个步骤，其他DLP策略就像失去了根基，无法发展壮大。该工作通常是企业IT团队负责，安全团队为企业IT团队提供必要的安全策略指导，合作推动该项基础性工作。企业可以考虑从以下几个方面做好这项基础性工作：
●办公终端统一加入AD域，建立企业全局唯一身份：全球办公终端需要统一加入AD域，建立全集团统一的唯一身份，该身份用于访问SaaS应用、私有应用，为后续访问控制和数据泄露溯源提供唯一标识。可通过本地数据中心AD+Azure AD，加快全球AD加入速度和管理有效性；
●回收管理员权限+桌面管控：回收终端的管理员权限，限制终端用户自行安装软件以及更改系统配置的能力。Windows系统仅分配User权限，MacOs使用JAMF系统完成系统的超级管理员权限回收。配合桌管系统，完成外设管控，并提供桌面水印。
●软件安装白名单管理：我们可以在企业内建立终端的软件白名单，原则上公司不允许使用私人IM、云同步盘、云笔记等涉及员工个人数据的软件。建立软件白名单要注意两点：一是对公司所有软件安装进行第一层审批，分为企业通用软件和限制级软件（存在数据泄漏风险和员工个人数据处理的软件）；二是每个员工需要安装限制级软件时需要额外再得到相应审批并签署个人数据同意书，同意公司对私人IM通讯、云同步盘、云笔记等软件的DLP监控。新软件增加进入白名单前，需经过IT的安全评审，确保软件符合公司的安全政策，数据泄漏风险较小。软件白名单机制可以通过企业软件商城的方式来建立和维护，在软件商城下载安装软件，系统可以自动以管理员身份安装，无需IT人员手动完成。新实施该项政策时，要注意存量软件的识别和卸载，否则企业内依然会存在不少绕过白名单的情况，这与ISO 27001和SOC2等认证要求都有一定违背。企业在安装CASB的DLP时，默认就会对公司非授权的软件进行阻断，部署推广过程可以顺便把软件随意安装的暴露面进行收敛。
●受控设备与非受控设备区分：在全集团区分受控设备与非受控设备，常见受控设备包括公司配发的台式机、笔记本和VDI，不受控设备包括BYOD、外包人员自带设备和访客设备。受控设备的标记可以在具有零信任准入功能的管理平台上维护，以实现受控设备的风险管理，例如Google Workspace或CASB管理后台。
●禁用邮件客户端：通常邮件客户端程序都会主动将邮箱中的邮件拉到本地保存，从而导致邮件的外泄。因此禁用邮件客户端，仅允许使用Web邮件是收敛风险的较好方法，即使公司推动有阻力，也应尽量通过沟通进行克服。
SaaS应用暴露面收敛是有效实施云原生DLP的必要要求，否则SaaS应用将与Shadow IT无异，在企业内非常难以管理。实施SaaS应用暴露面收敛，主要可以从以下三方面进行：
■SaaS应用采购技术评审：在企业内建立项目技术评审（立项），将技术评审输出结果嵌入采购流程中，确保SaaS应用使用得到正式的IT批准，能有效接入SSO，避免非受控设备访问。所有SaaS应用，在采购完成后均应接入CASB的SSO，建立访问授权SaaS应用的唯一通道。
■Shadow IT 持续发现与监控：对Shadow IT进行持续发现和监控，对有异常文件上传，敏感数据输入的Shadow IT应用进行定期统计分析，了解业务需求，完成封禁和限制措施，同步整合需求给企业IT进行统一建设，或引导到公司统一的应用中进行工作。
■禁用个人账号与SaaS租户：一般SaaS应用都支持不同的版本，例如个人版、高级版、企业版。企业IT应该禁止员工在受控设备直接访问个人账号与其他企业的SaaS租户空间，规避公司资料上传到非受控SaaS空间，造成信息泄露。通常可以通过网络DLP或CASB做到登录租户的域名识别。
根据笔者的调研，目前很多的SaaS应用都有很多自身安全设置可供选择，安全团队应该与业务部门一起对SaaS应用进行安全初始化设置，并将SaaS企业租户超级管理员账号进行回收，避免业务部门自行改变安全设置。SaaS应用的安全设置可以通过以下几个方面进行：
◆身份认证：启用SaaS应用的身份认证和2FA，接入集团统一的IAM系统；
◆角色权限：完成SaaS应用的角色权限梳理，形成RBAC角色权限矩阵，并通过ABAC实现细粒度控制，对各类权限对应可访问数据范围进行明细记录。
◆访问控制：通过SSO提供唯一网络访问通道，结合用户终端风险态势，对URL级别的功能进行动态授权。
◆关键功能设置：针对不同的SaaS应用，识别关键数据功能，例如数据上传、下载、共享、外发、数据扫描与标记、公共链接、公共频道等进行安全设置。
◆零信任设置：不少互联网大厂的SaaS应用具有一定程度的零信任设置，例如浏览器检测、限制访问，应该持续了解能力，并进行设置。举个例子，基于Google BeyondCorp的零信任，可以实现非受控终端无法访问G-Suite系统的能力，一定程度上降低了数据泄露风险。
云原生DLP的关键是SaaS应用自身DLP和SaaS开放API能力的组合，因此及时了解企业才采购的SaaS应用以及DLP平台的在DLP特性上的更新信息显得十分重要。
一方面可以通过订阅SaaS与DLP平台信息来了解DLP新特性新闻和通知，以及API清单更新。另一方面也可以与销售代表建立良好的沟通关系。
了解到新的SaaS和DLP平台特性后，应该将APIs集成与配置纳入运营日程中，及时对DLP能力进行升级。
URLs过滤是企业限制网站访问的必要能力，必须进行严格的上网行为规则过滤，杜绝大部分不可控的Shadow IT访问。国内通常使用的上网行为管理，是基于数据中心出口进行防护的，如果企业开始使用CASB，可以将上网行为管理的策略迁移到CASB上进行云化。
一般URLs过滤都应将恐怖主义、反社会、暴力、色情等违规内容就进行禁止。同时禁用高风险的云盘、云笔记、同步盘的上传功能。
CASB的URL过滤规则与传统防火墙的ACL规则无异，所有需要白名单放行的规则（Rule）必须放在列表前面，最后是Deny ALL的规则（Rule），所以对于部分网站存在较多子域名时，需要通过抓包工具来检查浏览器跳转顺序，做到网站部分功能封禁的效果，这种方法也可以用来在部署CASB时进行逐步排错。
根据企业安全政策，可以考虑部分打开文件下载功能，方便获取互联网资料。URLs策略的维护是一个长期迭代的过程，配合Shadow IT的监控，可以做到事半功倍的效果。
数据防泄漏管理制度规范的制定和培训宣贯，属于预防性控制措施，因此同样归为防护领域。以上DLP运营的所有活动，都应该在DLP制度规范中明确。所有的DLP策略，应该在安全团队内通过知识库（Wiki）进行维护，确保团队中每一个成员都了解DLP策略的最新情况，提高排错效率。
同时，公司内所建立的制度规范、指南都应该与业务部门和职能部门进行有效的宣贯。一是宣贯我们为什么要这么做，二是我们应该怎么做，三是如何提升有效性。有一个理念是必须要时刻宣贯的，就是安全与业务共赢理念，我们一定要让业务知道安全是在帮助业务保护敏感数据，我们为业务赋能数据防泄漏能力，业务可以向安全反馈哪里不好用，以及改进建议。当组织形成双赢的正向循环后，DLP运营就可以正式进入常态化运营，也会降低不少应急处理时的压力。
随着不断在组织内进行培训宣贯，笔者发现不少的业务部门和职能部门都会主动向安全团队寻求数据保护的方法。毕竟，数据丢失时受影响和冲击的往往都是公司业务。
检测模块是DLP运营的常态化工作，数据安全团队每日都需要进入DLP平台或者SOC平台进行告警的处置，确保每个告警都需要处理，如果告警太多就证明DLP规则存在过多误报，则应该对误报内容进行调整，另一方面需要对告警进行降噪，同一个事件触发多个告警规则时，应该合并告警，降低告警量，提高告警质量。
一般笔者建议从下面几个方面来做日常的DLP检测：
●告警监控：在终端DLP、邮件DLP、CASB与云原生DLP中打捞告警信息，采集到SOC/SIEM，对告警进行处置，可依赖ITSM的工单系统进行团队内的协同处理。
●零信任终端检测：终端的零信任检测，会产生终端准入失败的情况，需要及时监控告警信息，并协助正常用户进入网络。异常用户需要发起调查，确定异常来源。
●UEBA检测：当SOC具备UEBA检测能力后，应基于位置、时间、角色、频率等关键要素进行异常行为检测。各种异常维度结合后，可以维护一个UEBA的场景库，根据场景库在SOC里面设置告警规则，以达到更准确的事件发现能力。UEBA是一个大话题，本文就不再赘述了。
●SaaS违规检测：检测SaaS应用中的外发连接、公共频道创建、全员共享文件情况，及时进行相应处置。
●优化：对误拦截、误报等情况进行归纳整理，调整告警规则，形成DLP运营组内知识库。
在响应模块，主要做的是根据不同的情况进行响应。一般在企业内的响应场景有以下几类：
●离职检查：企业的离职检查流程中，应该加入数据泄露检查，对离职意向或已经提取离职的员工进行数据泄露的检查，并及时降低其网络访问能力。
●应急响应：当发生数据泄露事件时，数据安全团队除了满足数据隐私合规的响应流程外，也应该能够肩负起数据泄露追踪溯源的重任。
●变更管理：DLP策略变更可能会引起终端崩溃、网络中断、业务异常、数据阻断等不良影响，应该建立规范的DLP策略变更管理规范，做好策略验证和回退计划。DLP的变更规范在下图给了一个示例，读者可以根据企业实际情况和变更管理制度来调整。
●定期汇报：通过SOC以及各类DLP平台，形成定期汇报材料，选取重要指标，例如高危人员、高危部门、外发文件等，对数据泄露情况进行汇报，体现数据防泄漏效能。
在DLP运营的恢复模块，主要是快速对业务恢复正常，通常引起业务异常的情况就是DLP规则异常阻断，另一种就是DLP在线模式故障。
●例外放行：监听邮件、IM聊天工具的业务人员DLP误拦截或误报申诉，判断安全风险与实际业务情况，完成例外放行动作，确保业务快速恢复正常。
●DLP平台工具故障处理：对DLP平台工具的故障、崩溃、网络中断情况进行及时处理，确保故障时能够及时恢复。
本文向读者介绍了企业云原生DLP架构、技术细节和运营实践，希望能为一些全球化跨国企业提供部署实施先进的云原生DLP技术作参考。随着各类数据安全与隐私法律法规相继出台，国内数据防泄漏（DLP）市场感觉会迎来第二个爆发期。在疫情和远程办公（元宇宙办公）需求激增的背景下，云原生DLP的总体架构将会是未来部署DLP技术的首选。
同时，作者希望本文能为安全厂商和SaaS产品在云数据防泄漏技术尝试上带来一些新的启发，通过 “开放连接、拥抱生态”的理念，实现SaaS产品与云原生安全的强强联合，以更开放的姿态与安全细分领域玩家实现共赢，使DLP市场走向螺旋上升的正向循环。
推荐阅读
百家 | 探索隐私保护数字化解决方案
齐心抗疫 与你同在