鑽石舞台

當前企業運營環節採用外包形式已經越來越普遍了，外包形式能為企業降本增效，但在安全環節，外包往往會成為薄弱的一環。外包團隊究竟會為企業帶來哪些安全風險？我們又該如何應對外包所帶來的問題？本期話題討論我們以外包開發中的安全風險與應對解決方案為主，就相關問題展開了討論。

Q：大家認為，對於需要外包開發的項目，整套流程中可能會存在哪些安全風險？比如存在高危漏洞，或者是一些敏感信息泄露？具體應該如何避免？

A1：

我覺得主要是源碼，有人會把源碼傳到自己的代碼倉庫。

A2：

其實就是代碼泄露吧（人為帶走或上傳敏感代碼至Github等平台），機器淪陷成為跳板。如何避免的話，開發工作在虛擬桌面種進行，內部建設Git平台，Github巡檢監測，通過准入系統與網絡設備設置訪問控制策略，上審計，全流量威脅感知。

A3：

外包開發主要的風險在於安全漏洞和信息泄露風險。對於安全級別較高的企業（例如銀行），會要求：

1.外包商進駐甲方場地，使用甲方的開發環境和基礎設施，內部統一管理源代碼；

2.對需求和架構進行安全評審；

3.使用自動化工具進行代碼質量檢查和代碼審計，定期進行Code Review；

4.和外包商簽訂保密協議，在合同中明確SLA指標；

5.做好互聯網源代碼、敏感信息泄露等監測。

A4：

銀行這一塊，可以參考年初發的《中國銀保監會辦公廳關於印發銀行保險機構信息科技外包風險監管辦法的通知》。

A6：

外包開發的項目，到處都是風險，因為項目質量、人員管控、信息擴散範圍均不可控，處處皆風險。

外包風險不可控，如果不是成本考量，可能更願意選擇自研，相對而言人員外包比項目外包更可控。

A7：

我現在遇到的主要是外包開發水平太差，寫的程序性能和穩定性不行，所以涉及到敏感信息的項目不會採用外包。安全風險的話，項目整體會單獨一個區域放置，避免跟非外包項目有任何網絡和權限上的交互，避免問題擴散。開發流程上很難控制外包，只能在部署層面上做一些要求和控制。相比較而言，能讓外包如實的將代碼（包括提交記錄歷史）提交到我方提供的代碼庫就很不容易了。

A8：

個人認為最需要關注的安全風險有是人員風險和數據(泄露)風險。人員風險來自於人員安全意識的稂莠不齊，沒有良好的保密意識和工作習慣，以及隨外包公司的多項目交叉開展帶來數據泄露風險；數據泄露風險來自於人員風險延伸的人員異動(入、轉、調、離)、代碼不規範、功能邏輯理解偏差等。

避免上述風險的方法：與外包公司和外包人員簽訂嚴格的合約，約束項目人員的異動，加強需求溝通和代碼評審，做好安全測試和上線檢測流程。

Q：那具體而言，在選擇外包服務商時可以從哪些方面進行審計來確保其安全基線？比如攻防演練期間如何控制外包風險？

A1：

駐場類：外包安全培訓、簽安全保密協議、權限管控、源代碼檢查、敏感信息泄露、終端口令安全、終端病毒防護等；

非駐場類：參考物理安全、網絡安全、數據安全、應用安全、權限安全、終端安全和運維安全等。

A2：

除了合同約束，也要依照企業自身安全管理需求，對人員、操作、數據流轉、組件(服務)資產、工作流程、文檔、代碼存儲及備份、BYOD等進行審計。攻防演練期間無需特意控制外包風險，做好（上述）日常管理就好。

Q：外包是否已成為很多甲方企業做安全的慣性思維？如果外包過程中出了安全事件，權責該怎麼劃分？落實到合同中應該注意些什麼？

A1：

安全外包用於一線監控的多，落實到合同中就是保密協議跟服務質量約束。

A2：

我們公司安全不讓外包人員參與，供應商如果碰了我們的策略，老大給我們就要上課了。不過每年有攻防演練服務，供應商外部打一下，系統上線安全檢查也是自己人測。

A3：

這個不好評判，不同的企業對外包的需求不同，談不上慣性思維。更多的應該關注成本、專業程度以及業務適配性。

如果外包過程中除了安全事件，權責的劃分應依照合同條款和具體情況進行判定：例如，觸碰審計紅線、溝通偏差導致的誤操作等。

落實到合同條款中，應儘可能將權責進行明確和細化，避免出現模稜兩可的描述。可參考雲服務中的《責任共擔模型》。

Q：在直接購買安全服務與搞安全外包中，影響企業選擇的因素有哪些？

A1：

選擇的因素很多，如：服務商的資質、口碑、企業擅長的產品及技術能力、售後、響應速度。

A2：

其實主要就是看時間、成本、效能、風險。

A3：

安全外包更多看跟現有業務的契合度吧，再就是性價比。

話題二：對於服務器密碼管理。一般海量服務器是怎麼做？密碼記錄在哪裡？用戶一般是普通權限。進系統自己切Root?怎麼做定期更改密碼？

A1：

服務器上收到堡壘機管理，掃描器、HIDS做登陸掃描挖掘弱密碼。

A2：

堡壘機外還會存一份密碼嗎？

A3：

保險柜。堡壘機的密碼加密後可以備份，需要特權賬號恢復，極度重要特權賬號可以使用保密打印機，打印後交由檔案部門保險柜。

A4：

90天打印一次？密碼要求90天改一次，不90天打印一次怎搞。

A5：

從來沒有規定這麼要求過，現在這種說法過時了。我以前做等保，也這樣跟客戶說，自從做了甲方才感覺這麼要求真傻。

A6：

等保要求對口令定期更新，之後制度落實不就是XX天改一次麼。

A7：

密碼並不一定要定期更換，如果夠保密、夠複雜、不泄露，可以不修改。

A8：

堡壘機上有普通用戶和Root的賬號給用戶自己選嗎?關鍵是不允許Root登陸，用戶要通過普通賬號登陸。然後切換Root. 把Root密碼給用戶還是Sudo配置隨便切？

A9：

堡壘機就是控制賬號權限的，有什麼需求一定要Root嗎？實在需要就設置高危操作審核。

A10：

密碼要全部符合要求也蠻煩的。90天改密碼，不能歷史密碼，默認Root要禁用，賬號要按角色分配，密碼複雜度要用戶無法記憶。

A11：

以前安全保護措施少，為了防止密碼泄漏，最有成本的方式就是要求用戶定期更改。

本期精彩觀點到此結束啦~此外，FreeBuf會定期開展不同的精彩話題討論，想了解更多話題和觀點，快來掃碼免費申請加入FreeBuf甲方群吧！

加入即可獲得FreeBuf月刊專輯，還有更多精彩內容盡在FreeBuf甲方會員專屬社群，小助手周周送福利，社群周周有驚喜，還不趕快行動？

申請流程：掃碼申請-後台審核（2-5個工作日）-郵件通知-加入會員俱樂部

如有疑問，也可掃碼添加小助手微信哦！

精彩推薦