《网络安全法》《数据安全法》等法规都要求对数据进行分级分类，在数据安全运营时大家都使用哪些技术或方法来实现？

本质还是数据全生命周期管理每个环节来控制，采集、存储、整合、呈现与使用、分析与应用、归档和销毁几个阶段使用以下DLP、数据脱密、数据屏蔽、传输加密、权限等技术。

现在已有一些公司开发了分类分级的工具或平台，与资产管理系统或平台可以对接，动态的更新数据资产列表，可以得的实时的数据地图。

数据分类分级这块主要还是靠人工去评估吧，由数据所有者评估数据分类等级。

高管层的数据治理小组，其他职能部门执行，以数据中台为核心对数据进行分类分级，以数据态势感知平台为安全做保障，设置数据间物理隔绝，终端和网络dlp，企业间数据共享就遵从监管要求设置门槛和措施。

1、数据资产梳理（敏感发现、数据地图）
2、开展数据分类分级（制度、管理、指南、分类分级清单目录）
3、加强分类分级保护（策略、管理、合规、分级保护控制）
4、编制重要数据目录（管理机制、编目、备案）

我们的分类分级，都是找厂商做的。数据分类分级这个事情展开来讲就很大，借助之前大佬总结过的：有多少数据仓库、多少数据库实例、都存了哪些数据、数据分布地图、数据流转逻辑，这些前置条件的完成，缩小范围到数据库而不是包含办公文档等，再回归到安全问题上来，通过将数据字段的敏感等级定义，之后进行敏感数据发现、敏感数据管理、敏感数据脱敏等工作，结合敏感数据状况及数据使用需求，针对每种敏感数据定制脱敏方式，外保证敏感数据安全性的前提下，满足数据用户的需求。

我们是通过建立一个动态的数据主体主从索引机制，把大多数数据主体的个人身份识别信息单独处理。这样不仅解决6000多万人的身份信息保护，还可以为数据主体打标签，支持多种应用对数据主体的检索，实现索引跑数据不跑。关于数据分级分类，其实在解决个人身份识别后，再进一步明确大的应用场景，还是比较简单的。理论上可以比较复杂，但是操作上可以轻便。

Q：企业因业务需要产生了大量不同管理系统、存储方式的数据，为了更加安全且高效的管理数据，该如何对这些多源异构系统数据进行整合？

开发或引进数据资源目录系统，整合多源数据编录。

数据整合可能最大的难点是数据类型不一致，数据一流动又可能导致数据价值的变化，所有这个还得一步一步摸索着来。

“多源异构系统数据进行整合”，我感觉统一存储，做成数据接口给各个业务系统调用。这样只需要管控一个数据池就可以。

缩小到数据库范围的话，可以通过工具对目标数据库进行扫描，发现库中的敏感数据并形成敏感数据分布的管理报告，通过技术为管理决策提供服务。

Q：业务需要安全，数据安全运营的过程中也必然会和业务部门产生交集，运营人员该如何和业务部门进行沟通，才能取得业务部门的支持，并就数据安全相关措施和风险达成一致，推动数据安全运营更好地落地？

向上管理，让领导施压。

将业务部门的人拉进数据治理小组，让他参与或当小组长，和其他部门一起搞。

从业务部门利益出发，防泄密是一方面，发现和降低经济损失是另一方面。

1、为保持安全运营团队与业务部门的信息互通，建议办公环境相邻或相近；
2、可通过数据安全运营平台等系统，将运营环节或工单展现，体现出数据安全运营指标，取得领导对数据安全的重视及支持；
3、可参与制定公司数据运营报告（含治理共享等）对业务部门数据使用情况进行考核评分，阶段性的提供安全指标；
4、落实数据安全运营，更需要关注前沿数据安全技术手段和供应商的能力，运用专业型人才和团队配合数据安全运营落地。

理想状态上层数据合规领导小组，下面数据治理执行小组，业务部门、营运部门、安全风控部门共同参与，定期审查数据安全执行情况，对新数据识别打标，对所有参与部门有KPI指标。

数据安全这个东西，肯定还是要自上而下的，理想的状态当然是业务部门、安全部门等相关部门协调，但是实际推动的话还是有领导来协调和推进，并利用KPI或者制度来做强制要求；同时牵头部门也必须有明确的方向，我有什么，我应该做什么，我要做到什么程度，有什么验证的手段。

为什么做安全的总想着以自己为中心呢，业务才是公司的中心，这个是前提，都是服务业务的。

所以要让领导高层给业务方压力，安全自己去推动，基本没啥人搭理。

是的，业务部门永远是核心，一个花钱的部门能做的不多，如果公司所处的行业有强力的监管部门，公司又有钱那安全才有可能发挥自身的能力和价值（如金融行业）。

之前参与梳理过一次，全程人工....先圈定项目范围涉及的公司，然后挨个跟业务老大沟通，把他们能接触到的数据按部门全列一遍，再做数据分类分级评定，线下数据的执行还是交回业务部门内部进行管理（只做制度要求、数据管理培训、有的还要帮忙梳理业务内部的SOP流程）。反正肯定有个大佬先挑头说要搞，顶住压力，才能逐个业务部门做好沟通、没打招呼搞不了。

我们这个人信息保护做的很烂，上次某个兄弟单位有全集团所有人的家庭地址+单位岗位+姓名+手机号，然而没啥用。这玩意，我知道有的就十几家单位，有的单位甚至拿去做商业合作，所以到底有没有谁家的数据安全真真落地了？

数据安全运营只能靠甲方结合自身业务形态高度个性化的解决方案，能依靠乙方的有且仅有数据地图、分类分级这种“相对通用”的“工具”。

乙方提供的什么工具的，现在来说，个人感觉都只能解决20%的问题，剩下80%都还要靠人，甚至20%都达不到，数据安全运营，感觉还很遥远。

如果有数据治理团队，可以跟他们配合着做，定好数据Owner，专项启动，配合数据资产平台，还是可以逐渐落地的。

现实情况下数据治理团队跟数据安全团队真的隔行隔山，数据治理团队能把主数据、元数据做好，配合做数据管理，会跨越很大的困难。真实情况是，数据治理根本不懂安全，不知道在哪个流程里需要找数据安全进来。

其实这里面几个角色要分工好，业务、IT、数据治理、安全，一般是业务从业务中去梳理出业务资产对象，IT将资产对象转为实际的物理表，字段，转化为实际的物理表、字段、数据治理负责牵头，技术上支持资产打标录入、安全负责定级标准、指引。

话题二：现在不少企业已经在运用所谓的微服务架构，那在微服务化的过程中，如何进行服务的划分？怎么确定服务的粒度？有没有一些可以参考的业界通用规则？

每个企业的架构设计不一样 粒度也不一样，比如按照业务功能模块的公共基础能力进行服务划分。

个人认为微服务化应该算分布式部署的延伸，将整体系统的功能进行解耦和聚合，可以很方便的对负载压力大的服务进行计算资源倾斜，保障业务流程的高效运转。

对现有系统进行拆分的话，建议通过负载、功能和业务场景需求进行拆分。划分服务的粒度需要结合实际情况来进行判断，将具备类似或关联性的功能组合成一部分，最好结合功能之间的关联性进行设计，避免拆分的过细，造成不必要的资源浪费。

Q：微服务和容器往往会被同时提及，二者是一种什么关系？是微服务一定要用上容器吗？

基于微服务的思想开发应用程序是完全可以不用容器技术的，例如现在很流行的Spring Cloud和Dubbo都是可以不使用容器技术来做开发实现的。很多人喜欢同时提到微服务和容器化，这主要是基于以下几个原因：

（1）按照微服务的理念，如果使用容器作为基础设施，能够实现快速部署，快速迭代；
（2）在云计算浪潮中，容器作为替代VM的基础设施受到大家的关注度更高；
（3）K8s作为几乎实际默认的容器化平台标准，其集成了配置中心和注册中心，相当于天然的帮微服务架构解决了自己开发配置中心和注册中心的问题。

容器是一种新的软件交付方式，它把应用和其运行环境以一个标准镜像格式打包， 能保证应用及其运行环境的统一，并能在装有Docker环境上以容器方式运行，不管宿主机是什么环境
微服务是应用软件架构设计模式，推崇单一职责、服务自治、轻量通信和接口明确等原则， 基于此，容器可以比较好的配合使微服务易于开发和维护、按需伸缩等。

两者并不相干 但是凑一起好使（对运维来说）。

微服务是松耦合、高内聚和易扩展的，容器是无状态的，因此，容器的设计理念完美契合微服务的需求，将一个微服务构建成一个容器镜像，在必要的时候，可以快速生成所需数量的微服务，满足业务需求和负载压力，提升系统运行的稳定性。

因此，容器的无状态特性能够最大化的辅助支撑微服务的设计需求，所以，两者经常会被同时提及。微服务不一定要上容器，取决于系统架构的体量和资源需求。

微服务是业务，而容器是提供运行环境，不一定非要上容器，但是上容器应该是当前最优解。

Q：相比单应用架构，在安全性上，微服务架构存在哪些弊端？比如多个API增加了网络攻击面，对此有没有什么解决办法？

微服务里面的微隔离比较难搞，我们现在就在弄，重要的系统基本上都不上，因为容器都是混合在一起的，而且容器还是在集群上随意漂移，IP啥的也是随意变化。

搞微服务要把系统切片，分成一块一块的，然后再组合和联动，没有牛逼的架构师，难搞。

微服务因为是将整体系统功能做了拆分，所以无形中会扩大系统的受攻击面。微服务复杂的调用关系和数据流转，会增加安全问题排查的复杂性。对于网络攻击面，一定要严控API的暴露面，一定要严控API的暴露面，一定要严控API的暴露面。其次是，加强API之间的鉴权机制，加强注册中心的权限管理，加强数据链路的加密，严控内部调用数据的出入。

弊端的话， 部署成本高（无论是修改1行代码，还是10行代码，都要全量部署替换），改动影响大，风险高，测试成本高（不论代码改动多小，成本都相同）。因为成本高，风险高，所以导致部署频率低（无法满足快速交付客户需求）。

利与弊是相对的，就看怎么能好的支持业务。前提一定梳理清楚资产，有针对的上对应的防护就可以了。

申请流程：扫码申请-后台审核（2-5个工作日）-邮件通知-加入会员俱乐部