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

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

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

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

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

2.避免文件丢失

3.可以防止勒索病毒

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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