数据安全怎么做

一、熟悉业务

其实这么多年信息安全、数据安全做下来，跟很多同行有过不同程度的交流，业内的分享也很多了，我觉得现在已经不能说“不知道怎么做数据安全”了，但是确实依然有很多同行在问“应该怎么做数据安全”。我对这个现象的研究和判断是：因为数据安全和业务结合太紧密，技术人员很难把握实施数据安全措施的尺度，无法在安全和业务中取得良好的平衡。本质上是因为对业务不了解、不熟悉，或者是公司管理层、业务管理层人员没有参与到数据安全决策中。所以做数据安全的同事，一定要对公司的业务有充足的了解，要了解公司各类业务的流程，以及在流程中的物流、人流、数据流、资金流。

这里就有必要提一下Gartner提倡的DSG方法，理念肯定是正确的。如果完全不懂业务或者对业务只是一知半解，就着手做数据安全，大概率没有办法真正、有效解决数据安全风险。从网上拷贝了一张图，见下图。

运用DSG方法的时候，要特别注意：涉及数据安全风险的业务有很多，短期内机制、流程卡点不完善的情况下，很难全面熟悉业务、评估风险，因此熟悉业务也要有针对性，这时候往往根据法律法规强制要求、公司当期经营重点、过往或同行多发的场景、近期主要执法案例等因素选择重点业务先入手、做起来，也就是DSG的框架第一层描述所包含的那些维度。一定要保证当下选择的业务及数据真的重要，也要让关键干系人觉得重要。为什么？因为只有选择了这些重点业务，短期内数据安全才能出成绩，才能得到后续长期的支持。

运用DSG方法的过程中，要注意这不是一个静态的方法论，而是一个类似PDCA循环的动态方法论。这个方法论告诉我们的是：一要意识到数据资产的动态性，数据资产的流动、使用随着业务的变化而变化，很难能找到一个完全的卡口，因此要持续了解、感知、熟悉业务；二是单位里面往往都是业务在先、数据安全在后，业务都上线运行了，数据安全再去推广落地、就会面临压力，所以需要很好的业务切面和技术切面的能力（业务切面我在7.2会讲，技术切面我在11.1会讲）；第三，因为数据和业务紧密绑定，业务在动态变化过程中，数据面临的安全风险也会动态变化，因此要在业务动态变化的过程中实现数据安全的动态平衡，就要有机制、有技术手段感知、介入和控制风险。

二、定义数据安全

了解完业务之后，是不是马上就要开始数据安全的工作了？根据我的经验，不是。为什么？因每家公司对“数据安全”这个词的定义是不一样的，虽然《数据安全法》对“数据安全”的定义是：数据安全是指通过采取必要措施，确保数据处于有效保护和合法利用的状态，以及具备保障持续安全状态的能力，但这个定义仍然有待进一步拆分和解读，什么叫“必要措施”、“有效保护”、“合法利用”、“持续安全”？因此必须要通过回答如下问题来明确数据安全工作的边界，明确数据安全工作对什么结果负责。

1、“数据”是指哪些内容的数据。个人信息、商业秘密、国家秘密？商业秘密中的哪些？这里其实本质上说的不是该被保护的“内容”，而是基于不同组织利益而要求保护的信息。比如自身组织利益，就是商业秘密；客户利益，就是和客户协议定义的客户信息；个人利益，是个人信息；国家利益、公众利益，就有数安法定义的核心数据、重要数据；保密法定义的国家秘密；还有美国14117行政令定义的美国“政府相关数据”。这其中不同类别的数据也会有交集，有些国家关基单位的商业秘密可能同时就是国家的重要数据；有些互联网或者物流企业，其掌握的个人信息本身也是该组织的商业秘密。

2、“数据”指哪些形态的数据，电子化数据、纸质数据？指服务器、应用系统中的电子数据，还是也包括终端、合作方系统中存储流动的电子数据？是包括结构化数据，也包括非结构化数据（通常指各种文档、研发设计图纸）？是仅在公司业务系统、公司终端中存储流动的数据，还是也包括提供给客户、合作方的客户端、App中存储流动的数据？如果包括纸质数据，往往会超出IT部门的能力范畴，需要慎重考虑。

3、数据安全的管控边界在哪里、是什么？这里的管控边界通常是指安全策略、措施能够管理的范围，包括网络范围、物理边界、存储介质形态。比如电子数据、纸质数据管到哪些，在线数据、离线数据管哪些？比如研发设计图纸要交给合作伙伴，对合作伙伴管到什么地步？比如服务器外出维修或报废、移动存储介质外出维修，这些边界要不要管到？有没有一些数据只流经公司、但没有落地存储，那这些数据要不要管，管到什么地步？比如有跟第三方公司开展隐私计算业务，那数据安全在隐私计算过程中要管到哪个环节？

4、“安全”指的到底是什么特性，机密性、完整性、可用性、抗抵赖性、可追溯性、合规性、可见性中的哪些？不同的行业，不同的安全分工，不同的团队职能对这个问题的回答可能都是不一样的，所以要回答清楚。这里要特别搞清楚“公司领导想要的数据安全里的安全到底是什么”？举个例子，安全团队可能只对机密性、可见性负责，研发团队对完整性、抗抵赖性、可追溯性负责，运维团队对可用性负责，领导的意图是“都想要”，那数据安全工作交给安全团队总体负责，安全团队在实际工作中，不但要承担机密性、可见性的工作，还要对研发和运维团队的工作进行监督、督促。

在实践中，我们发现“安全”有时候还包含“自证清白”的内涵，也就是当接到投诉、举报或外部监管检查的时候，数据安全团队必须要能够举证自己的管控措施是有效的、合规的、充分的，从而帮助公司尽可能免责、保护公司利益，这点内涵也要充分识别与考虑，尤其是金融、互联网平台等类似的单位。

5、“数据安全保护的效果”是什么，得描述清楚，至少要用明确的、尽可能量化的描述方式跟老板对齐目标和效果。“不发生被监管通报处罚的数据安全事件”，“数据被窃取、勒索造成的损失每年小于公司营收的0.3‰”，“晚于监管机构发现的互联网、暗网数据泄露事件每年为0”，“敏感数据的访问和操作可对应到人、数据可追溯1年”，“对敏感数据的常见异常访问、操作可在发生后48小时内发现”等类似的描述方式都是可以借用的。这里给出这些例子，核心目的是像定义KPI一样跟老板对齐数据安全工作的目标和效果，否则只是一个含糊的“不出事”“别丢数据”，是没有办法干活，出了事也是没有办法界定责任的。这个指标最好还是能不断提升的，这样才能持续驱动改进。

6、在完成上面这个步骤之后，还要再考虑一个问题。在现阶段，“数据合规”这个词的含义基本等同于“个人信息保护、隐私保护、跨境数据合规、个人信息合法合规采集使用”，数据安全团队必须要明确“数据安全”和“数据合规”工作之间的关系，是包含还是交叉，对于交叉部分、由哪些团队分别对什么负责。如果数据合规和数据安全是两个团队的话，一般建议的操作方式是：数据合规团队（可能是法务团队，也可能是其他技术团队）负责解读、提出合规和业务需求，数据安全团队（一般在IT部门内）对技术实现负责，非技术部分的实现由数据合规团队负责。同时也要敏锐地注意到，“数据合规”现阶段仍主要围绕“个人信息”、“隐私信息”的保护，而“数据安全”往往不只是保护个人信息，因此两者按照上述分工是一种比较合理的协作方式。

关于不同团队分工的话题，本文的几位作者提出了一些不同意见，也是很有趣：其实也可以考虑用一个团队来统筹管数据治理、数据合规和数据安全，就是成立一个独立的数据管理团队。因为数据安全本身就是数据管理的一个属性，很多数据的梳理，数据流转的梳理，可以和数据团队的业务一并来做，或者用较为相同的流程方法来做。

有几位作者也认为：在不同的公司里面，也要切实考量下数据合规团队和数据安全团队划分边界之后的可操作性。把非技术的交给合规，技术的交给数据安全团队，恐怕这样的边界比较难以厘清。因为技术是实现业务目标的一个手段，有时候非常难以切割。就以数据分类分级这个业务目标来说，因为最末端流程一定是要涉及到业务一线的，只有业务一线能知道自己的业务流程是否会接收或产生商业秘密、重要数据、个人信息、国家秘密等，那这个工作发起者，推动者到底是合规团队，还是数据安全团队？是否数据安全团队只负责提供工具，其实是由合规团队向下推进呢？但实际情况，可能早在合规之前，数据安全团队已经存在了，帮助业务单位识别了商业秘密等，来了合规团队，又是另一个方法去识别合规相关的数据？

看起来，关于分工问题没有定论，每个组织选择一个自己合适的方式就好，但是一定要讲清楚。很多单位数据安全做不好，一个很重要的原因就是天天在扯皮。

7、在某些央国企、事业单位，大概率还有保密办这么一个组织，主要落实对国家秘密、商业秘密的保护要求。单位里面类似的组织多了，就很容易扯皮，那么数据安全和保密办之间是个什么关系？我一直以来的建议就是：尽可能简单点来，只要老板给我资源和支持，我不怕多扛职责。有更多机会锻炼提升自己，是好事哇！因此一般来说，我建议把保密办当做一个业务部门看待，也就是上面说的：保密办提需求，技术部分由数据安全团队负责实现，非技术部分由保密办负责实现。

上面提出了很多需要思考和注意的问题维度。最后总结一下，定义“数据安全”是为了划边界，划一个做什么、不做什么的边界（其实任何工作职责都得有这么个边界，我以前讲过“怎么做规划”的课程，也有这么个环节，其实都是一个意图）：

1、明确定义数据安全工作中需要保护的对象是什么；

2、针对这些保护对象，数据安全工作中到底要解决哪些风险？

3、针对这些风险的控制活动由谁定规则、由谁执行、谁对最终结果负责，本质上这是一个组织分工问题。

三、开展数据安全规划

业务也了解清楚了，“数据安全”的定义也定义好了，该开始下手买工具、建系统了吧？不、不、不，还早着呢。下一步工作是做规划。

很多人不理解为什么要做规划，我拉着团队内部讨论一下、统一一下意见，不就搞定了？一定要做个数据安全规划出来吗？答案是“一定要做”。因为规划的目的和意义在于“统一思想”，数据安全规划的目的和意义在于“统一和管理层、协作团队、业务部门的思想”，统一对于“数据安全”定义的认知，统一对于数据安全工作开展过程中的各方职责、定位和协作关系的认知，统一先解决哪些数据安全问题、后解决哪些数据安全问题的认知，统一重大数据安全策略、尺度的认知。

传统意义上，网络安全、基础安全更多属于技术层面的工作，可能1、2个技术团队拉在一起就讨论、确定了。数据安全本身和公司业务关系紧密，必须要通过“制订规划、汇报规划、确定规划”的套路把以上这些问题解决掉才能往后推进，否则一定会在执行过程中遇到多方阻力，因为你上安全手段就会对业务便捷、数据流动、系统稳定造成负面影响。所以，一定要通过数据安全规划这个动作要解决这些推进过程中出现的风险。至于怎么做规划，我以前的文章都写过，就不细说了，特别提醒的一点是：规划中要基本明确针对各类数据安全风险的控制措施，尽可能细化、明确，如果确实精力、能力不够，可以先把确定要干的明确了，剩下的写个大概，然后在不断的技术交流、评估测试、技术选型、同行交流过程中磨合、确定。

有人会问，做个3年规划耗时耗力，有没有简便的办法？也可以，那就是每年滚动规划。每年底做预算之前，花一定的时间，完成下一年度的数据安全规划，在年度规划中把以上这些问题逐步解决掉。但具体如何切分，就看自己把握了。

数据安全规划中要特别注意的一点是，数据资产的流动和使用与业务紧密相关，业务过程灵活调整、数据资产弹性变化、访问使用多元多面都可能导致数据安全规划会失效，所以数据安全团队一定要有机制流程和技术手段感知、适应以及应对这些变化，怎么做？再就是企业内部一般都是业务系统已经建好了，业务流程已经基本建好了、运行了一段时间了，这时想再推广、落地数据安全控制措施，就会面临很大的阻力，那么应该怎么办？这些问题在6章数据流动，7.2 业务运营 和 11章 切面技术思想 中有描述。

四、分类分级

做完规划，就进入执行阶段。执行阶段的第一步是什么，一定是分类分级。

分类分级怎么做，其实很多人都说过了，概括来说无非就是人工分，或者结合系统和流程用机器分。这个环节很多人都写过文章，我就不细说了。但是我发现很多人其实对分类分级的本质并没有正确的认识。到底什么是分类分级？为什么要做分类分级？

分类分级其实不是一个新概念，但凡资源有限的领域，想更好地开展工作，一定是要把手头的任务区分重点和次要，并做优先级排序。数据安全的分类分级本质上也是识别需要重点保护的数据和优先级。

分类其实很简单，公司有哪些业务活动、经营管理活动，就有哪些类别的数据；分级就是区分在这些业务活动、经营管理活动中有哪些数据在流动，这些数据从安全保护的重要性来说属于1、2、3、4什么级别。传统的分类分级会根据这个结果输出一张巨宽、巨长的Excel，到这里就结束了，也可能把这个Excel存到数据库里面，以便后续共调用。

但实际上，我认为这样的分类分级是有严重缺陷的。正确的分类分级应该是

（1）识别公司有哪些业务活动、经营管理活动对公司是最重要的、当前和未来一个阶段最有价值的；

（2）对这些重要的业务活动、经营管理活动进行理解和拆分，将这些活动拆解为人流、物流、资金流和数据流，最后形成一个数据流图，并附加说明数据在流动中有哪些人、岗位角色可以访问、操作这些数据；

（3）对数据流图中的数据进行分级、定级；

（4）将分类分级的结果，以某种结构化、容易被自动化识别的方式保存下来，便于后续在自动化的识别过程中调用；

这样的分类分级方法，其实应该是在第一章“熟悉业务”中完成的，这才是真正有灵魂的分类分级，是站在业务视角、保护业务利益的分类分级。不讲业务过程的分类分级，不止效率最低，对后续的数据安全保护动作也很难形成有价值的输入。

以上的分类分级完成后，基本还只是一个静态的数据分类分级成果，也就是“知道”了哪些数据是需要被保护的，但在实际应用中，还有一个动态识别的过程。比如从系统A通过API读取了系统B的数据，那么这些API里面包含了哪些类别的数据，这些数据分别定级是多少，有没有未定级的数据？也都需要被识别出来。识别出来之后，就可以按照后续的数据安全策略予以保护；如果发现有未分类分级的数据，也要按照既定的策略对数据访问操作予以控制。那么具体怎么做，在第六章里面阐述。

分类分级的流程和方法也可能跟以上的做法不一样，不过我们认为最本质的一点是相通的，要基于业务活动来识别、分类、分级。

五、确定数据保护措施

5.1 基本认识

做完分类分级、识别了需要保护的数据之后，紧接着就是要确定数据保护措施了。赶紧的，上工具、上手段！这是不是很多人的第一反应？

慢点，慢点，你是不是快了点，这里面是不是缺了点啥？

从逻辑上分析，应该先做数据安全威胁建模，然后才是确定数据保护措施。威胁建模这个步骤一定不能省！不一定要写下来，即便你在脑子里面过了一下，这个建模的动作也必须要有，否则怎么可能知道在上一个步骤中输出的数据流图中的数据有哪些安全风险？安全风险不清晰、准确的话，怎么保证数据保护措施是恰当、合理的？当然，如果数据安全工作涉及人员较多或者跨团队的话，这个威胁建模的结果最好写下来、有评审，避免遗漏。注意个细节，这个威胁建模不只是分析了威胁，其实还同步评估了风险。

完成数据安全威胁建模之后，就要确定数据保护措施。大多数人对数据保护措施的反应就是“上安全工具”！这也是一个要不得的误区。我们之所以说数据安全难做，就是因为数据是在业务过程中流动的，数据的流动、使用就代表着业务活动，上工具就很容易对业务活动造成阻碍；而实际过程中很多数据安全风险就来自于业务活动中对数据的不当使用、流动和授权。所以考虑数据保护措施的时候，首先应该考虑对业务活动的流程、工具、方法是否可以做改造、优化，降低数据风险暴露面、减少不必要的授权，这往往是最有效的数据安全保护措施。只有无法、不愿改变业务活动的情况下，才需要动用外挂式的安全工具来达到保护数据安全的目的。

当然，确定数据安全保护措施的过程中，有一个风险容忍度的平衡。不同的人对于风险接受度是不一样的，因此在这个过程，是需要和管理层做充分沟通的，这个一定是需要管理层参与和决策的。数据安全保护措施和其他安全措施的类型是一样的，要综合采用规避风险（包括业务最小化满足、技术方案的设计安全等前置工作），降低风险（例如采取功能优化，使得影响程度小、影响面小、影响对象重要性低），接受风险等组合型措施。

如果翻阅一下市面上各类数据安全管理技术规范、标准，都会提到“数据全生命周期保护”。这个提法的初衷是没错的，因为确实存在数据采集、传输、存储、使用、分享、销毁这么一个链条，如果忽略了其中任何一个环节，就容易造成数据安全保护措施的缺失。因此，在对数据安全威胁建模的过程中，不但要考虑业务活动中的数据安全风险（这里大多涉及的是采集、使用、分享），还要考虑IT基础设施管理与服务中的数据安全风险（这里大多涉及的是传输、存储、销毁）；要根据企业数据安全工作的目标，不但保护机密性，也根据数据安全规划定义的目标，适当地保护可用性、完整性、可追溯性、抗抵赖性、可见性。

上一章讲分类分级的时候，特别提到“将分类分级的结果，以某种结构化、容易被自动化识别的方式保存下来，便于后续在自动化的识别过程中调用”，在确定、实施数据保护措施的时候就能用到。比如在数据流动的监测中，对某个API访问的数据进行监测并和库中的分类分级样本进行比对，发现有敏感数据则根据保护策略自动启动相应的告警、加密等保护措施，过程完全自动化实现，效率和质量都有很大的提升。
5.2 场景抽象

传输、存储、销毁的环节以及保护措施相对明确，本文就不做赘述了。基于过往对数据安全的认知和经验，我把企业内部数据采集、使用、分享的场景做了一个抽象，将各类业务活动、经营管理活动中的数据采集、使用、分享环节抽象成如下图所示的一个田字格。

网络架构简述：企业内部网络分成办公网、生产网两张大网，中间有效、逻辑隔离，每张大网的安全管控要求有差别，可以理解为生产网是高密区、办公网是低密区；每个大网细分终端侧、应用侧，中间有效、逻辑隔离；红色圆角方框代表企业网络边界、办公场地边界；蓝色带箭头粗线代表数据流向；办公网、生产网的终端统称“员工办公终端”。

场景A1：员工办公终端访问互联网；

场景A2：员工办公终端的数据离线存储（拷贝到U盘，打印复印扫描纸件）；

场景B：员工办公终端带离公司管控边界以外；员工通过个人手机、个人电脑以远程方式访问公司内网资源；第三方人员以远程方式访问公司内网资源；

场景C：员工办公终端访问公司应用系统、公司数据；IT特权运维人员访问操作数据；

场景D1：在同一个大网内应用系统之间的数据流动；

场景D2：跨大网的应用系统之间的数据流动；数据从不同应用系统进入数据仓库（数据湖）；运用公司数据训练AI模型；

场景E：应用系统被互联网用户访问；

场景F：应用系统被第三方合作机构访问，或访问第三方合作机构；

以上对数据安全场景抽象、解耦的逻辑、思路、方法，可能每个单位不太一样，本质上还是基于不同类型数据、不同威胁和业务场景来做管控。
5.3推荐策略和顺序

将这些场景抽象以后，我推荐的策略实施重点和优先顺序是

1、先控制A、B、E、F的风险，因为数据出了管控边界；AB的保护措施实施起来相对容易，可以先做；E、F会复杂一些，可以放在第二步。在完成这些保护措施的同时，调研熟悉C、D的场景，做威胁建模、评估保护措施。实施ABEF的保护措施，可以为CD保护措施赢得时间和空间。当然，第一步并不只是针对这个场景，还是要看业务需求、公司领导的需求综合判定，但选择第一步的原则就是“先救命、再养生”。

2、再控制C、D的风险。这2类场景最复杂，技术实施难度也很大。

3、A、B类主要管员工、服务商，可控性强，策略可以选择脱敏、加密、隔离、阻断、严格审批为主，强势一些；E、F类主要管用户、合作机构，可控性弱，策略以监测、阻断、审计可追溯、简单审批为主，略微弱势一些；C、D场景复杂、数据类型复杂，策略以监测检测、数据流动可视化、收敛暴露面、备案告知为主，配合奖惩、绩效考核等管理措施驱动治理和改进，减少对业务、系统的打扰，又能达成数据安全目标。

以上保护措施举例的更多是技术类的保护措施，很容易造成大家的误解，因此需要特别强调一下，保护措施也包括流程类、管理类的保护措施，比如数据访问的权限控制既要有工具控制、也要有授权审批，比如对数据接口类的API要在变更流程后配套一个渗透测试的检查环节，比如要在立项环节对系统架构和方案进行评审、控制数据安全风险，比如在员工申请从生产环境提取数据后要自动追加一个“30天确认删除”的动作。这些流程类、管理类的保护措施，有的是通用类的（比如立项评审、授权审批），有的是业务专用类的（比如API变更后的渗透测试），但都是建立在数据安全威胁建模的基础上确定的保护措施。数据安全保护措施也应该参照安全左移的思想，尽可能在在项目初期完成数据的识别与威胁建模、隐私保护设计（Privacy by Design），并配套相应的数据安全工具；参照安全右移的思想，确保技术保护、流程改进、业务提升类措施是闭环的、持续改进的。
5.4多云数据安全

云上数据安全和传统最大的差异在于基建的变化，在治理思路上打破了传统安全的人为分类，尤其是在基础设施安全和数据安全之间的分类，更考验的是技术的管理执行。多云的数据安全其实是互通的，前提是需要先了解和熟悉单云的数据安全风险及差异。

深入理解云上的数据安全风险，一个关键的认知很重要，云上的产品从诞生之初就肩负着“独立生存的使命”，要在这种使命下看他们的风险，云上产品既可能单独存在风险，也可能因为组合使用后构成新的风险。

在云环境下，传统的终端数据安全场景风险即5.2中的ABC依然是存在的。不过，在终端数据安全场景下时，需要将云平台视为一个应用来进行管理，C模式下的风险更甚。因为，从云厂商的视角看，云管控台可以通过任何地方、任何终端访问，所以通过终端上的泄露场景是首先需要解决的风险，要保证可控数据落在可控端。

在云环境下，还会面临传统IDC场景下永远不会面临的问题，正如下图所揭示的“企业云化数据安全管控”中总结的5大挑战，云上传统的网络边界会被打破，有很多种的方式：

●AK是打破大门的第一环，未经任何限制的AK可以在任何地方、任何设备自由的出入云上环境，当然更会有各种隐藏模式，防不胜防；

●除了AK之外，还有存储桶Bucket，云上数据泄露80%来自于此。

这些都是需要单独拿出来去关注和管理的云上数据安全场景。管控方案也很简单，正如“新视角下企业云化安全管控框架OCBC”中提及的，要做好这块的工作，首先需要关注“3控”（控边+控权+控桶），同时处理好“双非”风险。

在云环境下，最后一个需要关注的就是云产品，所有云产品拿来即用的思路也是不可取的，很有可能因为一个新的云产品的引入打破原有的已经固防的安全边界，造成新的攻击面和数据泄漏点。所有，尤其需要关注云产品的“选、用、留”，做好云产品的数据安全基线就非常关键了。

每家云平台都可能存在安全漏洞，只是存在多与少、发现早与晚的问题。但是，更多的时候，其实是作为甲方企业没有安全、合规的使用云而造成的安全漏洞或数据泄露，云平台间接成了”背锅侠“。所以，坚持做好用云数据安全第一责任人的角色定位是重要的。

六、关于数据安全可观测

讲一个近年来经同行启发后的思考成果：数据安全可观测其实也是一种有效的数据安全保护策略。

比如上面这张图，是N年前我们经过访谈梳理出来的用户信息流转图。只是这么一张粗略的流转图，完全足以指导我们后续的数据安全规划和保护策略的实施，重要性不言而喻。当时画这张图，是为了便于数据安全同事理解、便于向老板汇报，但是用下来效果特别好。对这个现象，我们也进行了持续的思考。

传统的数据分类分级方法主要聚焦于对数据本身的理解，依据数据的敏感程度、重要性等属性进行简单分类，其核心目的是便于企业初步识别和管理数据。然而，这种方式存在明显的局限性，它未能充分考虑数据的载体以及数据在企业内部和外部的流转情况。在复杂的业务环境中，数据的载体多种多样，数据的流转路径错综复杂，缺乏对这些关键信息的了解，企业难以构建全面有效的数据安全防护体系。因此，有必要建立“数据安全可观测能力”。

与之形成鲜明对比的是，现代数据安全观测能力涵盖了“我有什么数据（数据标签分类分级）”“在哪里（数据资产清单）”“如何流动（数据流转地图）” 这几个核心能力，实现了对数据全生命周期的可视化管理。

（1）数据标签分类分级是数据安全观测的基础。通过更细致、精准的分类分级体系，企业不仅能像传统方式那样识别数据的敏感程度，还能基于业务场景和风险特征为数据添加丰富的标签。例如，对于金融企业，除了将客户的身份证号、银行卡号标记为高敏感数据外，还可以根据数据的使用场景，如线上交易、线下业务办理等，进一步细分数据标签。这样，企业能够更全面地理解数据的价值和风险，为后续的安全防护提供更精准的依据。

（2）数据资产清单则明确了数据的具体存储位置和所属系统。它就像是一份详细的数据“地图”，记录了企业内各个数据资产的详细信息，包括数据的存储介质、所在服务器、关联的业务系统等。有了数据资产清单，企业可以快速定位重要数据，了解数据的存储环境和访问路径，及时发现潜在的安全隐患。比如，当发现某个服务器存在安全漏洞时，通过数据资产清单可以迅速确定受影响的数据范围，采取相应的防护措施，避免数据泄露的风险扩大。

（3）数据流转地图是数据安全观测的关键能力之一。它通过实时监测和分析数据在不同系统、部门、地域之间的流动轨迹，帮助企业掌握数据的去向和使用情况。以电商企业为例，数据流转地图可以清晰地展示用户从注册、浏览商品、下单、支付到售后整个过程中数据的流转路径，包括数据在各个业务系统之间的传递、存储和处理。通过对数据流转地图的观测，企业可以及时发现异常的数据流动，如数据流向未经授权的第三方，从而及时采取措施阻断数据传输，防止数据泄露。

总结来看，数据安全观测能力不仅仅是对数据的了解，更是实现数据安全防护和运营的基础。在理解业务的前提下，通过数据安全观测，企业可以制定更有针对性的防护策略。例如，对于频繁流转且涉及敏感信息的数据，可以加强加密和访问控制措施；对于存储在高风险环境中的数据，增加备份频率和安全防护级别。同时，数据安全观测也为数据安全运营提供了有力支持。通过对数据标签分类分级、数据资产清单和数据流转地图的持续监测和分析，企业可以及时调整安全策略，优化安全流程，提升数据安全的整体运营水平。因此，企业建立数据安全可观测能力，将数据的分布、流转以直观、量化的形式展现出来，本身就是一项重要的基础工作。有了数据安全观测能力，依靠对业务的理解就能发现数据安全风险、建立业务切面和技术切面的感知能力，并指导安全人员采取下一步的保护措施；同时数据安全可观测的成果（比如数据资产清单、数据流转地图）可以做到很直观的效果，很容易打动业务部门、公司领导，很容易驱动数据安全决策。因此我们认为数据安全可观测也是一种有效的数据安全保护策略。过往我们很容易忽视这一点，现在该加强重视这个能力的建设了。

因此，数据安全观测是企业数据安全管理的核心环节。它弥补了传统数据分类分级的不足，通过实现对数据的全面了解和可视化管理，为企业构建了一道坚实的数据安全防线。随着数据安全威胁的日益复杂，企业应不断强化数据安全观测能力，将其融入到数据安全防护与运营的全过程，以保障数据资产的安全，推动企业的数字化转型和可持续发展。

七、数据安全运营

7.1 技术运营

攻防对抗场景下部署了这些安全工具都要运营，数据安全也同理，更需要运营。无论是DLP、数据库审计、数据脱敏还是审计可追溯，这些数据安全工具的有效性咋样？漏报误报咋样？告警处置了没？复盘分析改进了没？都得按照安全运营的逻辑展开运营。同理，不但要有运营闭环，也要有数据化的度量。度量指标哪里来？请参见第二章“定义数据安全的目标和效果”一节的描述。

这里特别要强调的一点是，安全运营不能只管安全工具，凡是可能造成数据安全工具效果变化的工具、系统也应该纳入数据安全运营的范畴。比如要控制U盘拷贝，你是在桌管软件上实施策略的，但这个系统在桌面团队运行管理，那他们执行的怎样，要运营、要监督；比如在应用系统中部署了水印插件，对敏感信息展示的页面要附加水印，那这个插件作为系统的一部分、属于系统运维范畴啊，那这个插件是否正常运行要有检查和运营；比如你部署了一个基于DNS引流的数据安全网关，那DNS服务及其配置的变更就可能影响数据安全网关的运行有效性，则DNS服务及其配置变更后就要有有效性验证。

容易被忽略的是，数据安全运营活动本身蕴含数据安全风险，常见的场景是数据安全运营人员由于风险告警的响应、调查需要接触敏感数据。谁来授权、监督数据安全运营人员接触数据安全工具中记录的敏感数据，以免引起公司其他领导和同事过度的隐私担忧与争议，这本身也是一种数据安全风险，也需要通过合适的规范、机制、工具来予以控制，例如人力资源部门担心薪酬数据被数据安全工具监控；数据安全运营人员应该在何种受管控的流程、环境下接触敏感数据，是否仅能在必要的情况下，取得授权并在安全的环境中最小化的访问使用敏感数据。
7.2 业务运营

除了安全工具、系统的持续运营外，还有一个要特别提醒的运营活动，就是要建立机制、主动感知公司有哪些业务活动、经营管理活动、技术活动存在数据安全风险。怎么建立？一般几个渠道（1）参与立项评审，设立数据安全风险评估卡点；（2）安排个意识敏感的人，参与公司的研发、运维、AI、外部合作等领域的例会，听听其他团队、部门都在做什么，既熟悉了业务，也及时察觉这些领域存在的数据安全风险，避免被动。（3）在上一章的“数据安全可观测”部分提到的，建立数据安全可观测能力，能看到数据分布流动，基本也就七七八八知道哪里可能有风险了。对于这种能力，我称之为“业务切面”，本意是想说在公司的业务活动中，我们要建立对各类业务活动中数据安全风险的观测能力，进而帮助提升数据安全保护措施的覆盖面和有效性。

数据安全运营活动与公司风险、合规等后台执法部门建立良好的协作机制至关重要，一方面需要从这些部门获取支持以表明实施监控的合规、合理性，另一方面也需要借助这些部门的执法权力与流程威慑、处罚违法违规人员。

八、数据安全制度和组织运作

数据安全的工作要想做得好，制度和组织运作也是必不可少的。这也是为什么“数据安全工作”经常也会被称为“数据安全治理工作”的原因。

1、数据安全在绝大部分场景上，基本上等同于业务安全。那么在业务活动、经营管理活动中，谁对数据安全的最终结果负责，需要在组织中通过制度、组织运作确定下来。比如：业务部门说我就要通过这种方式把数据给到合作单位，就要追求快、敏捷灵活，安全团队说你这样不行，我们现有的安全手段保护不了你，你得改业务流程、改系统接口。在这种情况下，是安全团队有一票否决的权利，还是业务部门签字画押、承担风险，还是升级到最高领导决策拍板，组织内部必须明确这样的责任，明确仲裁和决策的流程。

2、数据安全团队与数据治理团队、数据合规团队的协作关系，也要参照上一条，通过制度或组织运作的形式界定清楚。毕竟，数据治理、为单位内部提供数据服务的过程，本身也是一项经营管理活动，那么在这项活动中的数据安全谁负责、对什么负责，是需要界定清楚的。

3、按照“责权利对等”的原则，明确了数据安全责任之后，谁承担最终责任，就要给责任部门提供相应的工具、手段，让他们管好业务活动、经营管理活动中的数据安全风险，技术团队至少要让他能看到数据安全风险。因此这时第6章提到的“数据安全可观测能力”就很重要了，当然，还可以整合数据安全工具的数据，将“数据风险可视化”。

4、数据安全团队要通过月报、例会、安全委员会等不同层级的渠道，展现数据安全工作的进展、运营状态和风险问题。所有的汇报都是为了展现业绩、暴露问题、驱动问题的解决，数据安全也不例外。

5、持续的、为员工喜闻乐见形式的安全意识教育是必不可少的。

九、技术措施的逐步演进

在这几年开展数据安全工作的过程中，从安全运营的方法论中也吸取了一点想法，最终有这么一个认识：从整体视野看，数据安全防护能力的建设一定是先解决痛点场景、痛点问题，采购部署工具，就形成了多个场景的单点能力；然后随着场景的深入解构和实施，我们发现有必要将这些单点能力串联、编排，形成多场景下的平台化能力，所以如果要看数据安全的技术架构的话，最终很可能是“基础工具”-“能力”-“场景”这么一个层次架构。

想列出这个层次架构的目的是想说

1、数据安全技术体系的建设，不太可能一下子想清楚、看明白，大多数人都是一步一步走过来之后，才看到一个完整的数据安全技术体系是咋样的。

2、如果这篇文章看到这里的话，希望上面这个层次架构能对你有一点帮助，至少在技术选型的时候，可以多考虑一些工具和能力的互联互通、可整合性，比如API的开放，比如多节点部署，比如策略设置的格式、字段一致性。

3、数据安全保护措施基本都是针对一个个场景，这些场景本质上就是一类业务活动、业务流程，因此数据安全保护措施要做的要么是规范、调整业务活动、业务流程，要么就是适应场景、部署针对性的保护措施。

十、集团型企业数据安全应该怎么做

关于集团型企业数据安全应该怎么做，有以下几点想法：

1、集团层的数据治理制度、数据安全制度要区分集团和一级子公司、二级子公司之间的关系，主要强调数据安全组织、职责和决策机制、通用的保护&教育&应急要求、运作汇报机制等，不要对具体的数据保护要求做出过多约束，尽可能把这部分职责交给子公司自己决策、落实。因为子公司的业务特性、风险接受程度是不同的，集团层要避免把这些要求做出太硬性的要求。

2、加强与管理层/业务部门沟通，明确需要保护的数据和目标。如果管理层和业务部门不清楚哪些数据需要保护，可以考虑推动数据湖或者数据中台的建设，再从数据湖或数据中台梳理出现有的数据，提供给管理层/业务部门参考；

3、明确需要保护的数据后，进行风险评估，开始查漏补缺。这些数据的当前保护措施是否依然有效，或者是否符合管理层/业务部门的期望，列出当前无效的措施或者没受到保护的数据；

4、根据风险评估结果以及数据的重要性，制定管理和技术控制措施，管理措施一般都是制度与流程，技术措施例如以下：

(1)网络层：根据数据的重要性，将业务系统进行分类，在网络层面进行分区分域，做好网络层访问控制以及相关的审计措施，攻击防护和流量分析等；

(2)服务器主机层：防勒索，主机安全，特权管理等；

(3)应用层：应用系统访问控制，权限管理，攻击防护，代码/组件安全（SDL/DevSecOps)

(4)数据层：高敏感数据加解密、脱敏，二次认证，数据防泄漏等；

(5)客户端侧：终端安全管理，高敏感文件加密，防钓鱼/勒索；

(6)数据安全运营：数据地图、流转监测、数据溯源、事件管理等

十一、对数据安全工具的期待和思考

11.1 切面技术思想

蚂蚁集团这几年力推的“切面技术思想”，是我现阶段看到的数据安全领域最好的技术思想，强烈推荐。当然，其他数据安全技术工具还是有不错的，但在技术思想上没有新的突破；切面技术思想之前在国外也有应用和普及，但是我觉得蚂蚁的同事们在理论和实践上都有很好的突破。同时也期待蚂蚁的平行切面技术联盟能够联合国内厂家，推动基于切面技术思想的数据安全工具整合、优化。

之所以很喜欢这个技术思想，从第9章的内容描述来看，就能看到。数据安全工具的精细化场景应对，决定了数据安全工具、能力未来会朝着“多个基础能力控制点+一个控制平台”的方向演进，切面技术思想正好应运而生。这样可以做到既不打扰业务、不改造系统，数据安全保护措施也可以动态演进、有效实施。蚂蚁把切面技术思想比喻成平行的高速公路，我觉得比喻成“输液埋管”更合适：通过这根管子既可以监测血液流动和监测指标，还可以输液、施加控制措施。
11.2 融合框架性技术

在文章的编写过程中，有作者贡献了一个非常有价值的观点：数据安全技术、工具应该融合IT技术领域的框架性技术。

前面多次提到，数据安全工作面临的主要挑战之一就是“业务在先、安全在后”，因此对于数据安全控制措施而言，是具有较大的滞后性、有时候可能跟不上业务和应用系统的变化。那为了让数据安全技术、工具能够适应变化，就必须要和主流的技术框架做融合，就必须要融合、迎合技术生态，这样才能具有普适性。国内有的数据安全厂家在JDBC、ODBC层面提供数据安全的能力，这就是一种融合技术框架、具有普适性的数据安全技术；切面技术思想本身也是符合这个技术理念的，在操作系统、Java解释层做切点切入。

大家看WAF为什么能卖得好？因为HTTP和HTTPS协议是标准化的，可以基于此做解析和风险控制。那为啥数据库防火墙买不好？因为每个厂家有自己的私有协议，你得一个一个适配，他不是通用性的框架和技术。

当然，在融合的过程中如果又能够运用切面技术思想，善莫大焉。
11.3数据安全系统的开放性

从上面多个章节的阐述中，我们已经看到非常明显的趋势：（1）数据安全工具之间存在数据打通、访问调用的需求，比如敏感数据识别检查策略的一致性，比如多个工具脱敏策略设置的一致性，比如告警数据的统一身份关联、告警数据格式化和标准化；（2）为了被集成、嵌入业务活动中，数据安全工具也需要被其他业务系统、IT工具所调用，一些通用的数据安全能力很可能需要作为服务对内开放，比如加密、动态脱敏、水印展示、数据敏感度检查等。

从甲方角度来看，显然是有如上的诉求，也期待各个数据安全厂商能够意识到这一点，在产品设计、架构上做出改进。从厂商角度而言，做大而全的数据安全产品也不太可能，更多的可能是针对某个、某几个场景推出有效果的数据安全产品，因此短期内来看，甲方环境下部署多个数据安全产品的局面不会改变，那如果数据安全产品的开放性、可集成性比较强的话，会更容易受到甲方的青睐。

以上就是我们对“数据安全怎么做”的理解和分享。这里面我们基本没有描述具体的技术和工具，因为数据安全技术、工具太多，我们无法一一穷尽，而且不同的单位有不同的选型风格，无法给出通用的指导。但我们会在另一篇“如何做POC测试和技术选型”中讨论通用的测试和技术选型方法。

作者：李维春、刘亚军、李良、刘新凯、李磊、俞婷、李吉祥、王军军