互聯網公司自研安全產品個人感悟

09-10

互聯網公司自研安全產品個人感悟

來自專欄一個安全工程師的點點滴滴8 人贊了文章

首先要說明的是，這是一篇方法論文章，技術乾貨會在後續的文章中做詳細說明。

本篇文章主要著重以下幾個問題，一、安全產品買還是自研，二、自研的長期收益在於哪裡，安全產品的架構設計踩過的一些坑。三個方面來陳述。

一、買還是自研？

這是所有甲方安全從業者一個基本的問題，我們的安全產品是購買第三方的好還是自研好？

我的經驗是參考三個前提維度、兩個重要參考指標。

三個前提維度：信息化程度，人才儲備，企業執行效率與領導態度，這三個問題決定是企業是否自研的是與否。

1、信息化程度：首先傳統企業和互聯網企業的信息化程度是非常不一樣的，舉個很簡單的例子，十年前的套路如下，取自豬豬俠阿里雲峰會的PPT：

這套方法論在面對傳統的政府、傳統企業依舊比較有效，但想黑進大中型互聯網公司的核心業務基本非常困難。為什麼會造成這麼大的差距，我覺得核心問題是企業的信息化程度不太一樣，很多安全問題在企業解決信息化和業務需求的時候，安全問題已經被消滅了百分之80-90%。舉個簡單的例子，一個大中型互聯網的運維高並發架構，基本上一定會用到四層+七層負載作為保證。具體的架構圖如下：

在這種架構下，我們發現上線流程可控了，在Nginx上做反向代理可以保證公網只暴露80和443。同時公網開發的業務系統，整個公司的運維OP也能做很好的把控，在防火牆上做好相關策略，埠安全問題基本被幹掉了百分之90。

好，大家覺得可能說遠了，我想表達的是什麼？企業的信息化程度決定著企業的風險點範圍，越先進的技術架構雖然也存在安全問題，但攻擊者的門檻更高，而且越熱門的技術威脅情報研究情報也會越活躍，及時出現問題企業也可以第一時間做好應急響應，這樣企業可以騰出很多救火的時間去自研安全產品。自研最大的缺點就是見效慢，需要時間，當一個很簡單的安全問題能搞穿一個企業的內網時候，我們投入巨資自研並不能解決企業短期的安全，反而會帶來領導與兄弟部門的不信任。同時，在信息化不夠先進的時候，企業對單一安全產品的依賴會更多，更廣。這裡看一下我之前公司的創宇盾產品，我認為做的還是比較好的：

如上紅框中產品功能，其實大多數互聯網公司都有成型的系統能更好的替代工作。比如內容防禦，作為一個電商平台，一定會有個更完整的生態風控部門承擔這項工作，而資源鎖，整站鎖對於互聯網企業是不太需要的。拋開這些功能的研發量剩下的功能的開發技術門檻是非常低的，最大的難點是需要積累規則經驗和穩定性經驗，已經由技術問題轉變成了時間問題，這已經不屬於技術的範疇內了。

WAF demo可參見業內兜哥的公開課：

FreeBuf直播間 FreeBuf.COM | 關注黑客與極客?

open.freebuf.com

Github上成型的WAF demo：

jx-sec/jxwaf

2、人才儲備：

這個問題非常簡單，說句玩笑話，我覺得互聯網企業最不缺的就是研發。至少在我們企業基本大多數技術人人都有一門編碼能力，不論是SQL、SHELL、C、Python、Java。所以提出需求解決需求的人才儲備非常充足，比如我一個從沒寫過代碼的同學，在短期內能夠快速的研發出系統（雖然做的比較爛），沒有兄弟部門，周圍同事的支持和幫助是很難實現的，很多事情自己研究可能需要5天，同事一句話可能就是3分鐘的事兒。所以企業內的人才是否廣泛具備編碼能力也是安全是否適合研發的先決條件。

3、企業執行效率與領導態度：

這個是不可避免的問題，在我看來安全系統很多解決核心問題的功能風險性都偏大。比如在機器上安裝agent、WAF需要搶佔入口流量、掃描器可能會給業務數據帶來潛在的威脅。這些都會成為企業在安全自研工作的阻力。然而購買安全產品卻好得多，因為成熟的安全產品有其他用戶的積累，穩定性短期內會比自研的好（這是一定的）。如果企業文化不是一個類似互聯網企業那樣高速發展，領導願意不停的去嘗試新鮮技術，願意在不斷試錯不斷調整中快速發展的企業是不適合自研的。

兩個重要參考依據：我們的企業是不是超熱點行業？投入產出比是否值得？

1、超熱點行業，比如區塊鏈，可能全世界的黑客都在盯著。甚至為了他不惜動投入大量人力物力進行代碼審計，投入各種0day。這種情況下，自研就沒有必要，先快速購買提高進攻門檻，才是首先要解決的問題。否則可能會出現，系統還自研到一半，已經丟了200個幣，領導會想，這安全部門在幹嘛，吃乾飯的么？

2、投入產出比是否值得。例如DDOS這種除了3BAT和運營商很少有廠商能夠做到大流量清洗，當然這只是技術層面，很多雲清洗的廠商，仔細調研你會發現背後都有這四家+運營商的影子在協助。當然說這番話不是說要去買3BAT的運營商產品服務，因為服務嘛就像下館子，每個企業口味不一樣，服務這種產品的客戶主觀感受更強，在技術解決的情況下，選擇合適自己的才是最好的。比如一個中型電商平台，難道我們要為防DDOS自建一個機房進行流量清洗並招聘專門的團隊開發么？這是一個很現實的問題，所以以DDOS為例投入產出比是重要的參考因素。

二、自研的長期收益在於哪裡？

1、靈活，定製化場景：

自研的安全產品一定是最適合企業目前生態和安全現狀的，並且可以像互聯網企業其他產品一樣進行安全迭代開發。在企業安全的救火壓力沒那麼大的時候，很容易在3個月到半年內開發出一套最適用企業生態的產品。我們可以做一個真正意義上的SOC所有安全產品的報警都在上面處理，而不是一方傳統的SIEMS和SOC那樣很多無法落地。

2、多系統勾連，組成乙方產品無法完成的縱深生態。

其實有一些乙方產品已經實現了相關的功能，比如我們看HIDS阿里雲的雲盾安騎士：

這項功能如果沒有阿里內部自建的威脅情報平台是非常難以實現的，所以我們看到很多一線互聯網的雲安全產品已經開始逐漸往這個方向走以適應更多的互聯網企業。比如WAF，既然我們可以攔截傳統安全，為何不能再JS裡面種個Cookie字元串做設備指紋對接風控系統，比如資料庫審計系統發現異常了，可不可以自動對接WAF和防火牆快速實現攔截策略。這種聯動乙方產品很多時候出於商業考慮只給自己的產品預留了介面，而並沒有預設第三方介面。造成聯動的困難。

三、安全自研踩過的坑

架構設計，解耦，寫注釋和文檔，多向研發部門的程序員請教開發經驗。

不要寫前後端粘在一起的代碼，太難維護了。我作為研發巨菜做的第一個系統是公司的許可權伺服器管理系統，使用Django實現的，全程用了Django的模板系統，開發效率高CURD很順利，人瞬間膨脹了很多，開發一時爽，維護火葬場。粘在一起的代碼主要功能介面分散很難做到統一，導致有些bug可能不能修改單一介面就修復給自己留了無數的坑（正在準備重構ing）。架構能解耦就解耦，寫好代碼和注釋，要不有時候改bug看到自己寫的代碼真的有點懵。學會正確使用git，符合開發的基本流程規範。

2、做好監控、監控！！

又是自我膨脹帶來的教訓，就大多數安全系統來說，實現功能跟容易。但維持穩定性是重中之重，畢竟安全是跟運維一樣的基礎保障部門，平時看不見工作，出了事兒容易背鍋。不可控，所以在自研系統的時候要做好監控。舉個例子，我自研的HIDS系統，覺得一切自我感覺良好，直到有一天我覺得這麼完美的系統我應該接進open-falcon做監控，結果接進去我傻眼了。

我的生產者消息隊列的積壓程度已經不正常了，只能說我們公司的機器好，運算效率高，並沒有影響到實際系統的運營。如果我們換一種思路想，假設這是WAF呢？造成核心業務的Reponse延遲這怎麼辦，所以要做好監控。具體經驗後文再說。

以上是我的一些拙見，希望對大家能起到幫助。