现在企业的很多业务需要与各部门、外部合作伙伴、供应商等进行文件交换传输，在这过程中可能会用到U盘、网盘等方式，也有通过内网私域进行传递，这些方式在保证方便、快速地共享信息的同时，如何保证安全性是本期话题讨论的主要内容。

为了保证安全，大家一般是怎么设置文件的交换或外发流程的？比如企业局域网内的文件交换，以及需要突破内外网壁垒的文件交换场景？

A1：

外发文件分为两类，一是普通类型文件，可通过企业微信和邮件附件外发，二是重要文件，只允许通过文档系统外链发送，且需审批。内部区分重要部门，重要岗位，对重要文件做加密。重点研发部门做了网络隔离，如果需要外发文件到办公网，只能使用指定的文件摆渡工具。

A2:

我司这边，如果是恶意泄露那没办法，主要防的是过失泄露。之前我基本上秉持一个原则，鼓励大家用Office365的OneDrive：

1.避免出现把交接文件放某些网盘上泄露的风险

2.避免文件丢失

3.可以防止勒索病毒

用了飞书之后，很多文件也是直接飞书云文档了。所以我控制好OneDrive，不得外部分享，飞书有一套不太完善的权限管理方案，也勉强能用。

A3：

交换外发，首先明确文件类型定义，敏感类型一律走外发审批流程；同时利用数据防泄露监控所有外发行为进行审计，包括IM途径。

A4：

差不多和上面的回答类似，流程的规定当然是先定密级，交换按照文件密级来走申请，不同密级的文件对应不同审批人。局域网内的话还是邮件和共享文件夹用的多。

A5：

我这目前暂未针对文件交换制定相应的要求，也未对常用文件进行密级区分（企业管理类文件除外）。对于内部文件交换，以某企业级即时通讯工具为主，以协同办公系统为辅；

涉及与供应商、服务商或外部合作方的文件交换也以某企业级即时通讯工具为主。涉及某些特定场景的客户需求，以专用服务器+点对点专线+VPN+PGP+重要数据分离传输（例如，文件密钥与文件通过不同渠道进行传输）的方式进行交换。此外，移动存储形式的文件交换需要进行审批和权限开通。

A6：

可以参考一下某司对电子邮件的安全规范，其实是相似的。

A7：

我听说我们现在可能在考虑的一个解决方案，是针对DLP来实现的。计划是若有数据邮件外发或者是USB拷贝诉求，先让文件走线上签报进行审批，审批通过后，外发或者拷贝与签报中的文件MD5值进行检验。

A8：

我们大概是这样：互联网-->商密网-->SM网，单向导入，反方向审批导出。实际上，除了SM网，我觉得互联网和商密网管理的不太好，还是完全隔离省心，就是成本过高了。

Q：像现在不少企业员工在用一些即时通讯软件（IM）传递文件，你们对此有没有相关规定，比如哪些文件禁止通过这些软件传递？

A1：

通讯软件传递文件必不可少呀，感觉只能提高个人意识。

A2：

有相关规定，例如财务等文件不会让其通过即时通讯软件传输，如机密文件则是通过专线进行传输。

A3：

IM系统使用第三方商业版和自研的均可（我们这使用自研IM产品）。基础IT建设是否大力投入需要老板层面的决策，能干就干。我这使用自研产品，已完美融合加解密能力，实现内部IM安全互传。账号安全使用商业人脸+设备+短信认证模式，安全性相对可靠。

A4：

自研IM香啊，可以控制的太多了。我见过一个公司的朋友给我展示，他们自研IM安卓的客户端，有个授权是要收微信聊天记录。我们也是自研的，所以我用iOS，我领导微信和内部聊天软件在两个手机上。

Q：对于上述提到的类似于自建IM，如果要形成一套企业数据交换方案，应该如何建设？重点是在哪一块，是防泄露还是可溯源？

A1：

数据交换方案就是上云，上权限管理，上DLP，我觉得理论上的重点当然是防泄露，但落地还是重可溯源，可溯源本身是种威慑且防泄露太严影响业务。

A2：

以物流行业为背景，企业数据交换方案建议是以可溯源为主，以防泄露为辅，理由如下：

1.数据泄露的途径、方法多如牛毛，在企业层面即使对各种场景进行头脑风暴和穷举，也无法覆盖所有场景和可能性；

2.技术层面对防泄露的手段，一是有限；二是对业务操作影响比较大；三是实现起来，对小企业来说，有些得不偿失（即投入产出比不高）；

3.因此，尽可能的收敛泄露途径，在确实发生数据泄露的情况下，又要最大可能的发现数据是从哪个环境，以那种方式泄露的。

所以，可溯源的覆盖范围（场景）要比防泄露要大。

A3：

防泄露可溯源两手抓两手都要硬。通过内容审计，AI识别等方式逐步建设异常流出阻断能力，通过明暗水印的方式逐步建设办公安全溯源能力。

话题二：大家有什么漏洞生命周期管理的方式或者实践可以分享？不管是从单纯的手测然后文档记录，再到引入黑白盒和IAST扫描，产生漏洞记录之后都得运营起来，否则效果也是大打折扣。

A1：

现在一些厂商有类似漏洞管理的运营系统。

A2：

还是得引入产品来解决嘛。

A3：

你们能拿开源的二开也行啊。

A4：

我感觉在Devops平台上面二开和补充是最好的，一个是直接需求分发，另一个就是流水线上，安全不批就发不了。

A5：

作为一个运维工程师，我的思路很受局限，我最开始是准备在CMDB上二开的，后来不行，业务部门坚持说，我们不能只提出问题不解决问题，给他们出一键修复，否则不允许上报他们有问题。

A6：

产品的话，现在在炒漏洞聚合平台，站在研发角度，只接受CI/CD上面按照Bug缺陷去对待；现在安全角度，要的是漏洞闭环。

话题三：关于IAST（测试环境使用，不是RASP那种在生产环境的）的一些问题

技术层面

IAST产生的脏数据如何处置？怎样降低脏数据产生的影响？（影响：导致接口报错甚至崩掉、插入数据库的脏数据影响开发排错）IAST产生的日志正常日志有些产品可以单独生成，但是如果是IAST本身报错日志会插入业务本身的日志。（个人想法，二开改源码单独生成日志，但是存在无人二开的窘境）

流程层面

安全问题如何闭环？放到功能测试层面是有大批量测试团队去发现问题及复现提交给开发团队，但是IAST是平台自动发现问题，难免有误报，如此大批量的问题怎么解决？设置专岗？可是非大厂很少有这个的专岗，该如何处理？

此外回归测试如何处理？虽然IAST有这个功能，但是该如何整合到研发流程里，跟Bug提测回归测试一样呢？（流程问题说到底还是非大厂没有专岗，不像功能测试有测试工程师能去处理问题，IAST仅仅是一个自动化的平台，终归还是需要人去进行运营）

A1：

我觉得 IAST 可以和功能一起测, 然后给到代码审计排除误报。

A2：

IAST可以，本来就是和功能测试同步进行的，IAST跑起来的前提是业务在运行，也就是在做功能测试。

A3：

我意思是测试完，同步到代码审计那边，结合IAST和代码审计。

A4：

问题又来了，非大厂一般没有安全代码审计吧。

A5：

能买个代码审计软件都已经上天了，所以我一直很羡慕预算充足的公司，误报率可以结合人工来降低，但是一般企业连边界防护都还没完善，别说代码审计了。

A6：

技术层面第一个问题是不是可以考虑设置IAST测试规则，白天功能测试时只记录流量，夜间再测试。

流程层面第一个第二个问题，能否考虑针对IAST扫描结果分类处理，一类问题出一个通用的解决方案，建立代码检测规则，减少IAST误报。

A7：

关于第一点，因为IAST的测试原理是需要业务本身在跑，也就是功能测试在进行，同时对业务中间的数据流、控制流同时进行安全测试（这也是IAST的优势所在，可以减少安全测试时间），所以这块是需要测试同事进行的，夜间测试IAST这块的话就隐匿了本身的优势点，站在功能测试同事角度也是不太可能接受的。

关于第二点，分类处理可以，针对中高危处理，可以降低误报（或者说平台策略和开发的安全策略不一样），但是同样存在问题，就好比功能测试同事发现了问题，开发觉得不对，这中间就需要沟通交流，因为测试同事多，可以一对一解决问题，但是针对IAST平台，它是个机器，无法去进行沟通，所以这块还是需要专人去运营。

A8：

第一点我记得IAST是可以设置规则的，功能测试还是在白天进行，功能测试的同时流量通过Agent传到IAST服务器存储，然后晚上再自动化测试，并不是要求晚上再让功能测试人员进行测试。

第二点人工部分肯定是需要的。

——————————————————

本期精彩观点到此结束啦~此外，FreeBuf会定期开展不同的精彩话题讨论，想了解更多话题和观点，快来扫码免费申请加入FreeBuf甲方群吧！

加入即可获得FreeBuf月刊专辑，还有更多精彩内容尽在FreeBuf甲方会员专属社群，小助手周周送福利，社群周周有惊喜，还不赶快行动？

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

如有疑问，也可扫码添加小助手微信哦！