构建数据安全纵深防御体系，多层边界守护数据流转｜总第276周

0x1本周话题

话题一：有个关于数据安全的不成熟想法跟大家请教一下，因为数据流动较多，将数据的流转完全监控起来很困难，考虑建立类似网络安全那样的数据安全纵深防御体系。也是分为多层，构成多个边界： 

数据集中地边界：针对大数据平台、数据湖等数据集中地，建立边界，推动业务尽量在数据集中地进行用数和计算，出边界脱敏； 

数据生产网边界：通过旁路镜像等方式监控数据异常访问、大批量数据外流等行为，已审批行为加白，未审批行为进行分析研判，生产网与互联网的边界再结合威胁情报进行告警；

 数据内网边界：涵盖生产网、办公网、测试网等全部内网环境，结合终端DLP，邮件DLP等形成内网边界，生产网边界到内网边界仅进行审计，内网边界到外部环境需要审批。

A1:理论可行，但落地工程庞大臃肿，也不是审批可以搞定的，最终都是业务发展需要，无法阻挡流动。建议进一步明确这个做法希望达到的数据安全管控目标。不同的目标，决定不同的做法。

A2:数据集中地边界和数据生产网边界主要的管控目标是防外部攻击，防止数据扩散，防止数据大量外泄.数据内网边界这个做起来比较难，主要防的是内部，也是准备最后获得高层授权后开始做。

A3:考虑推进的顺序是：生产网边界--集中地边界--内网边界。因业务部分分析需要，数据集中已经有了，基本上是各业务系统有一份，数据集中地有一份。因为数据集中地外也有敏感数据，另外也无法完全避免数据出集中地，所以才在外面再划分边界，多级管控。

A4:数据没有集中前，遍地撒网成本太高了，现在又一堆云化的基础设施，overlay 网络搞旁路镜像技术上也挑战。按场景精细化管控。权限、访问行为、出行监控审批。

Q:嗯嗯，安全肯定是没办法推动数据集中的，只能依赖现有环境。其实从我的角度还不是很希望数据集中，集中也意味着容易被一网打尽。请问出行监控审批是什么？

A5:收敛数据出行口子，比如只保留邮件外发、少量USB、API系统对接等。针对性进行识别过滤拦截审批。

A6:根子上大部分企业数据分类分级都搞不定，最基本的数据流动规则都定不出来，从安全视角执法监督的依据都建立不起来，结果是一管就是一堆审批卡点，业务天天投诉影响效率。

A7:从实践上来说可行的还是关键场景的管控，如账户权限、数据出行、数据库访问、展示脱敏、API敏感数据外发识别等。

A8:这个考虑通过终端DLP来实现。生产网系统对接取数先进行梳理，然后对于新增的建立审批流程，生产网边界到内网边界仅进行审计留痕，不审批，出互联网再审批。像DLP这些，刚开始推进的时候，肯定是后台告警，然后人工跟进，等告警稳定了再走审批。

A9:终端DLP我上了，运营工作量大。然后我就全域推了虚桌，收口了数据出行。在分级分类做成熟以前，考虑先做规则比较确定的个人敏感信息的管控，像身份证号这些都比较好识别。

A10:我遇到的场景有很多 2P2B 互联网业务，各种非结构化数据，不审容易泄密，审就是靠人工，最后就是发送方业务主管负责兜底，苦不堪言。

A11:终端DLP这个确实难做，所以准备最后再做，要管理层下了决心才行。要想数据安全又想使用方便，我的理念是构建一个安全的使用环境，在安全环境里可以随便用。但是权限是清晰的、行为也要得到监控和审计。

A12:非结构化的很难，现在了解了一下部分DLP有文件追踪的功能，下载了代码即使各种变换，修改，还是能追踪到，不知道实用起来效果如何。

A13:先把网络隔离做了，然后是集中网关，最后再考虑合法接口内的流动。肖总列的确实是高优先级的。感觉外部环境上跟华为差不多，以前华为电脑都是上锁的。

A14:那是锁 usb 外设，后面都可以软件控了，还能审计。安全机箱开锁挥不去的噩梦。

A15:终端还是需要配的。桌面云的钱其实主要是网络的钱，服务器都是一次性和维保投入，价格可以谈。配了电脑终端后，那员工回家可以连自己的桌面云吗？

A16:如果可以，那人家回家截屏，不就泄露了吗？

A17:禁止截屏，拍照记录是个问题。远程生产VPN按需开，办公VPN默认开。

A18:水印、禁止截屏、禁止录屏，这都是标配。即使不让截屏和拍照，谁也不能阻止手抄。手抄不泄露也行，所以对互联网环境做敏感数据检测。比如手抄了代码，上传到自己的git上，私有化不公开，也没啥大问题。你也检测不到。我觉得做到员工只能靠手抄才能泄露的程度，已经是无敌了，手抄泄露了，我感觉也怪不到安全头上。

A19:拍照后ai读取文字也无解，破水印。

A20:拍可以，别拍敏感的就行。敏感的能脱敏还是得脱敏，如果不能脱敏就想办法知道谁能访问这些数据。

A21:源头还在于绝密、机密数据的管控，做到访问范围有限、数据水印标识追溯、禁止下载、禁止外发策略即可。这种背调可以做出来吗？

A22:没做出来，理论是这个理论，但实际很难做到，就在于第一点分类分级。

A23:好在现在都开始强调“谁管业务、谁管业务数据、谁管数据安全”，那数据安全的人在安全下还是业务下了。在安全下可以是提供技术支持，不负责，但其实多多少少都会背责。感觉现在数据都要靠技术手段。

A24:大家公司里面现在数据安全归口管理部门是安排哪个部门承担呀？

A25:出了问题先查的是技术上有没问题。你只搞搞技术建设，就不会给你太多资源，就别抱怨。我们这种民营企业，老板就会觉得，你们在干嘛呢，要你们啥用。

A26:重点是大家还没有广泛认可这句话，如果业务都当自己事，自然会聚起来想办法让科技规划实现。

A27:应该是谁使用谁负责，更合理。数据的管理职责，就这个就扯不清楚。科技已经被罚怕了，当银监去直接罚到业务的数据安全问题，他们才知道他们也有责任。

A28:一步步来，也不能一步到位，这口号是监管发文的，说明监管层面也意识到了这不是科技能解决的问题。使用很难界定的（存储数据也是使用），广泛使用就表示大家都有责任，也就都没责任，最后科技兜底。

A29:我感觉数据安全做的好的典范，还真都是高压管理那种，华为啊pdd啊保密办啊之类，互联网类型的企业都不大好。

Q:pdd是怎么做的？

A30:一是没数据，二是可以直接查员工手机。

A31:主要是认定泄露的原因是否是环境不安全，还是人为因素。比如业务人员自己主动外发出去了，泄露了，就是业务的全责。如果是在终端存储，因为钓鱼失陷被泄露，这种科技有一定责任。

其实换个视角分两类：

• 一类是外部攻击导致的数据泄露，这是科技的领域，需要从系统层面进行安全加强，这个措施就太多了，和防御体系相关，直接相关的是应用程序接口安全问题；

• 二是内部人员导致泄露，如果能做统一身份认证，对员工所有的敏感数据访问行为进行监控审计，重点对数据外发行为进行监测，抓典型通报典型，压实责任。大面上应该就控住了。或者说安全团队的责任也尽到了。

  ‍

A32:工作责任制的问题，讲的是一个主管能动性。所谓的大家各自认领各自想办法，在组织中是理想化的。业务平时说要发展业务需要怎么怎么配合，说他们主力，怎么到这个环节就退了呢。

A33:所以谁管业务谁管数据安全是更合理的，我们科技该想办法技术保护的就做好，也不推责任呗。好奇pdd为啥没数据。

A34:Pdd对数据权限管的很严。

A35:查员工手机，这个没有得到授权有法律风险吧。进来就签署授权协议？其实这也算是一种威慑吧，企业愿意承担这个法律风险来威慑员工。

A36:我觉得应该说是企业认为压根不会有什么法律风险，然后事实上，也是如此。

A37:企业查看员工手机通常构成侵权，但在特定情况下可能是合法的。

侵权情况：

1、侵犯隐私权：未经同意查看员工手机中的个人通讯、照片、金融信息等，违反了法律保护的隐私权。

2、违反合同与信任**：随意查看手机破坏了劳资间的信任，除非合同中明确规定并符合隐私保护法规，否则不可查看所有聊天记录等私人内容。

合法情况：

1、工作手机：企业提供的专用工作手机，若事先告知检查规则，为了信息安全和防止泄密，可以进行检查。

2、法律授权或紧急情况：配合执法机关调查或在有合理怀疑且经过合法程序（如获得搜查令）的情况下，企业可依法查看员工手机。

A38:参考某大佬的思想：边界内的流动：基本不管控，优先审计追溯。跨边界的流动，分两种，一种是生产边界或内网边界流出到互联网（非可控区），要可管控可追溯；另外一种是从高级别流向低级别，即核心到生产、生产到内网，应减少发生，可审计溯源，保留可管控的能力。

A39:还不太一样，区域间应该有个数据交换平台，员工终端分内网和外网。

A40:哪里不一样呢？

A41:开发测试也应该有员工。这些都属于是内网区域内的，不影响整体。从人的终端角度，开发，测试，内网，办公从数据交换角度，需要数据交换平台建设，堡垒机，外联软件，数据流转通道管控。

A42:大致思路可以这样做没问题，但数据安全的难度是在工程落地和运营机制的成熟度，而不是方法论上。明白到做到，中间还有一大段路要走。

A43:提几个落地时可能碰到的case，可以评估一下是否存在这些场景： 如果公司考虑压降成本，比如大数据平台和应用做在离线混部或资源共享，充分利用服务器的潮汐性能，有可能会打破现有红线隔离边界；如果开发测试区服务器足够多，跨区混部也有可能。 如果大数据平台能力不完备，无法高效满足数据分析人员需求，有可能会在办公网通过本地分析工具直连大数据存储系统或是从平台导出数据分析。

A44:收到，边界不清确实就比较难做，我先摸排一下。

话题二：请教下，11位手机号用SHA256哈希运算后，算匿名化个人信息吗？

A1:算吧。加盐吗？

A2:加盐或不加盐的，如果对方知道加盐的方法呢？我主要不太确认官方能不能认可这种匿名化的技术手段，因为有生日攻击，手机号有点规律化。

A3:在一些数据安全和隐私保护要求相对较低的场景下，如果只是为了简单的标识区分，且哈希后的手机号码不会被用于重新识别个人身份，可能可以满足部分监管要求。

例如，在一个内部统计系统中，统计不同号码对应的用户行为次数，只要不涉及对外泄露和重新识别用户，哈希后的手机号码可能是可以接受的。 然而，在金融、医疗等对个人信息保护要求极高的领域，仅仅哈希手机号码通常是不能满足监管要求的。

这些领域的监管机构通常要求采取更严格的匿名化措施，如使用令牌化（用随机生成的令牌代替真实的手机号码）或者完全删除可识别个人身份的信息。

A4:但是感觉还原的成本应该很高，所以不太确认。看场景，金融医疗不认可。你们应该不是金融医疗强监管场景，已经足够了。

A5:有监管的最好用国密的算法。这里明确讲了散列技术，SHA256已经是足够安全的散列技术了。而且文档没有明确要求必须使用国密。

等保 3 级要求信息系统能够确保通信网络的安全性，必须采用校验技术或密码技术来保证数据在传输过程中的完整性和保密性，强调数据保护，但并未明确规定必须使用国密算法。

散列技术 国密 SM3 的特点及适用范围：国密 SM3 哈希算法可用于生成消息的摘要，确保数据的完整性和一致性，在国内的信息安全领域中得到了广泛的应用，能够满足等保 3 级对于数据完整性校验的要求。

其他散列算法的合规性：常见的如 SHA-256 等散列算法，同样具有良好的安全性和广泛的应用基础，在等保 3 级系统中，如果能够证明其使用方式和强度能够达到等保 3 级对于数据完整性保护的要求，也是可以被采用的。国家是认可SHA256的。

A6:这个其实是要求了，只是要求的有点隐晦。得把等保和密码局的规定对照着看，《网络安全等级保护基本要求》里多次提到了“应确保密码产品与服务的采购和使用符合国家密码管理主管部门的要求”，然后从三级要求开始出现“应采用密码技术….”，《商用密码管理条例》里提到了“网络运营者应当按照国家网络安全等级保护制度要求，使用商用密码保护网络安全。”对照来看的话，感觉是要求用商用密码了。

A7:从目前上海侧直接测评看，等保测评机构不会以是否使用商密来做风险判断，但有额外的评估项，来征询商密现状。当然，这是非金融标准的等保测评，金融标准的等保测评可能有其他要求。

A8:我们要求国密的，只要满足安全要求就可以了，我们在满足的情况下，尽量会采用国密的算法。

0x2