現在企業的很多業務需要與各部門、外部合作夥伴、供應商等進行文件交換傳輸，在這過程中可能會用到U盤、網盤等方式，也有通過內網私域進行傳遞，這些方式在保證方便、快速地共享信息的同時，如何保證安全性是本期話題討論的主要內容。
為了保證安全，大家一般是怎麼設置文件的交換或外發流程的？比如企業局域網內的文件交換，以及需要突破內外網壁壘的文件交換場景？
外發文件分為兩類，一是普通類型文件，可通過企業微信和郵件附件外發，二是重要文件，只允許通過文檔系統外鏈發送，且需審批。內部區分重要部門，重要崗位，對重要文件做加密。重點研發部門做了網絡隔離，如果需要外發文件到辦公網，只能使用指定的文件擺渡工具。
我司這邊，如果是惡意泄露那沒辦法，主要防的是過失泄露。之前我基本上秉持一個原則，鼓勵大家用Office365的OneDrive：
用了飛書之後，很多文件也是直接飛書雲文檔了。所以我控制好OneDrive，不得外部分享，飛書有一套不太完善的權限管理方案，也勉強能用。
交換外發，首先明確文件類型定義，敏感類型一律走外發審批流程；同時利用數據防泄露監控所有外發行為進行審計，包括IM途徑。
差不多和上面的回答類似，流程的規定當然是先定密級，交換按照文件密級來走申請，不同密級的文件對應不同審批人。局域網內的話還是郵件和共享文件夾用的多。
我這目前暫未針對文件交換制定相應的要求，也未對常用文件進行密級區分（企業管理類文件除外）。對於內部文件交換，以某企業級即時通訊工具為主，以協同辦公系統為輔；
涉及與供應商、服務商或外部合作方的文件交換也以某企業級即時通訊工具為主。涉及某些特定場景的客戶需求，以專用服務器+點對點專線+VPN+PGP+重要數據分離傳輸（例如，文件密鑰與文件通過不同渠道進行傳輸）的方式進行交換。此外，移動存儲形式的文件交換需要進行審批和權限開通。
可以參考一下某司對電子郵件的安全規範，其實是相似的。
我聽說我們現在可能在考慮的一個解決方案，是針對DLP來實現的。計劃是若有數據郵件外發或者是USB拷貝訴求，先讓文件走線上籤報進行審批，審批通過後，外發或者拷貝與簽報中的文件MD5值進行檢驗。
我們大概是這樣：互聯網-->商密網-->SM網，單向導入，反方向審批導出。實際上，除了SM網，我覺得互聯網和商密網管理的不太好，還是完全隔離省心，就是成本過高了。
Q：像現在不少企業員工在用一些即時通訊軟件（IM）傳遞文件，你們對此有沒有相關規定，比如哪些文件禁止通過這些軟件傳遞？
通訊軟件傳遞文件必不可少呀，感覺只能提高個人意識。
有相關規定，例如財務等文件不會讓其通過即時通訊軟件傳輸，如機密文件則是通過專線進行傳輸。
IM系統使用第三方商業版和自研的均可（我們這使用自研IM產品）。基礎IT建設是否大力投入需要老闆層面的決策，能幹就干。我這使用自研產品，已完美融合加解密能力，實現內部IM安全互傳。賬號安全使用商業人臉+設備+短信認證模式，安全性相對可靠。
自研IM香啊，可以控制的太多了。我見過一個公司的朋友給我展示，他們自研IM安卓的客戶端，有個授權是要收微信聊天記錄。我們也是自研的，所以我用iOS，我領導微信和內部聊天軟件在兩個手機上。
Q：對於上述提到的類似於自建IM，如果要形成一套企業數據交換方案，應該如何建設？重點是在哪一塊，是防泄露還是可溯源？
數據交換方案就是上雲，上權限管理，上DLP，我覺得理論上的重點當然是防泄露，但落地還是重可溯源，可溯源本身是種威懾且防泄露太嚴影響業務。
以物流行業為背景，企業數據交換方案建議是以可溯源為主，以防泄露為輔，理由如下：
1.數據泄露的途徑、方法多如牛毛，在企業層面即使對各種場景進行頭腦風暴和窮舉，也無法覆蓋所有場景和可能性；
2.技術層面對防泄露的手段，一是有限；二是對業務操作影響比較大；三是實現起來，對小企業來說，有些得不償失（即投入產出比不高）；
3.因此，儘可能的收斂泄露途徑，在確實發生數據泄露的情況下，又要最大可能的發現數據是從哪個環境，以那種方式泄露的。
防泄露可溯源兩手抓兩手都要硬。通過內容審計，AI識別等方式逐步建設異常流出阻斷能力，通過明暗水印的方式逐步建設辦公安全溯源能力。
話題二：大家有什麼漏洞生命周期管理的方式或者實踐可以分享？不管是從單純的手測然後文檔記錄，再到引入黑白盒和IAST掃描，產生漏洞記錄之後都得運營起來，否則效果也是大打折扣。
我感覺在Devops平台上面二開和補充是最好的，一個是直接需求分發，另一個就是流水線上，安全不批就發不了。
作為一個運維工程師，我的思路很受局限，我最開始是準備在CMDB上二開的，後來不行，業務部門堅持說，我們不能只提出問題不解決問題，給他們出一鍵修復，否則不允許上報他們有問題。
產品的話，現在在炒漏洞聚合平台，站在研發角度，只接受CI/CD上面按照Bug缺陷去對待；現在安全角度，要的是漏洞閉環。
話題三：關於IAST（測試環境使用，不是RASP那種在生產環境的）的一些問題
IAST產生的髒數據如何處置？怎樣降低髒數據產生的影響？（影響：導致接口報錯甚至崩掉、插入數據庫的髒數據影響開發排錯）？
IAST產生的日誌正常日誌有些產品可以單獨生成，但是如果是IAST本身報錯日誌會插入業務本身的日誌。（個人想法，二開改源碼單獨生成日誌，但是存在無人二開的窘境）
安全問題如何閉環？放到功能測試層面是有大批量測試團隊去發現問題及復現提交給開發團隊，但是IAST是平台自動發現問題，難免有誤報，如此大批量的問題怎麼解決？設置專崗？可是非大廠很少有這個的專崗，該如何處理？
回歸測試如何處理？雖然IAST有這個功能？但是該如何整合到研發流程里，跟Bug提測回歸測試一樣呢？（流程問題說到底還是非大廠沒有專崗，不像功能測試有測試工程師能去處理問題，IAST僅僅是一個自動化的平台，終歸還是需要人去進行運營）
我覺得 IAST 可以和功能一起測, 然後給到代碼審計排除誤報。
IAST可以，本來就是和功能測試同步進行的，IAST跑起來的前提是業務在運行，也就是在做功能測試。
我意思是測試完，同步到代碼審計那邊，結合IAST和代碼審計。
能買個代碼審計軟件都已經上天了，所以我一直很羨慕預算充足的公司，誤報率可以結合人工來降低，但是一般企業連邊界防護都還沒完善，別說代碼審計了。
技術層面第一個問題是不是可以考慮設置IAST測試規則，白天功能測試時只記錄流量，夜間再測試。
流程層面第一個第二個問題，能否考慮針對IAST掃描結果分類處理，一類問題出一個通用的解決方案，建立代碼檢測規則，減少IAST誤報。
關於第一點，因為IAST的測試原理是需要業務本身在跑，也就是功能測試在進行，同時對業務中間的數據流、控制流同時進行安全測試（這也是IAST的優勢所在，可以減少安全測試時間），所以這塊是需要測試同事進行的，夜間測試IAST這塊的話就隱匿了本身的優勢點，站在功能測試同事角度也是不太可能接受的。
關於第二點，分類處理可以，針對中高危處理，可以降低誤報（或者說平台策略和開發的安全策略不一樣），但是同樣存在問題，就好比功能測試同事發現了問題，開發覺得不對，這中間就需要溝通交流，因為測試同事多，可以一對一解決問題，但是針對IAST平台，它是個機器，無法去進行溝通，所以這塊還是需要專人去運營。
第一點我記得IAST是可以設置規則的，功能測試還是在白天進行，功能測試的同時流量通過Agent傳到IAST服務器存儲，然後晚上再自動化測試，並不是要求晚上再讓功能測試人員進行測試。
