如何構建高效的安全運維服務平臺

大家好，我是烏雲的章華鵬，今天和大家分享的話題是“高效安全運維服務平臺的構建”，包括：企業的資料安全問題，運維安全中面臨的網路、系統服務、應用相關配置等問題。

企業安全的核心是資料安全

當我們在討論如何構建安全運維服務平臺之前，我們需要考慮的問題是構建這樣一個平臺的核心需求是什麼？核心需求是幫助企業解決安全風險，避免因為安全風險帶來的業務損失。
我們都知道對於一個依賴網際網路的企業來說，資料是企業的核心資產，那麼歸根結底，其實企業安全的核心是資料安全，所以我們首先要明白企業的資料到底在哪裡？
業務是資料的載體，IT資產是業務的載體，那麼運維的核心物件即是企業的IT資產，由此可見，企業安全運維應該是運維的一項基礎要求。
運維安全面臨哪些問題？
高效安全運維平臺構建的前提—瞭解企業面臨的風險。企業的運維安全主要分為：網路、系統服務、應用相關配置三個方面。

網路安全

主要是網路邊界被突破帶來的安全風險。對於大多數存在網際網路業務的公司來說，服務都會分為內網和外網兩塊區域，通常這兩部分業務是相互隔離的。
一般來說，企業內網主要部署著一些公司內部的敏感系統，這些系統只需要對內部員工開放，與網際網路是隔離的。既然存在邊界隔離，那麼就會存在一些網路邊界被穿透的安全隱患。
企業網路邊界安全的典型風險主要表現在以下幾個方面：包括某臺伺服器同時部署內網&外網業務、SSRF漏洞、IDC與辦公網網路互通、未授權代理配置、IDC伺服器被入侵等等。
這裡對其中一些比較專業的概念做一個解釋，某臺伺服器同時部署內網&外網業務這個其實就很容易理解了，比如有兩個研發公用一臺伺服器，其中這臺服務的內網IP對映到一個內部的業務系統，比如ERP；但同時這臺伺服器又部署了一個外部的業務，比如企業的官方部落格，而這個部落格繫結的是外網IP/域名。
SSRF漏洞，說白了就是相當於一個應用層的代理，可以利用這個應用層的代理來對內網任意地址發起請求。
未授權代理配置主要一些類似Squid這樣的代理未新增授權控制，導致任何人都可以直接通過這個代理帶請求內網資源的問題。
在烏雲平臺，經常可以看到這樣一些案例，一些攻擊者可以通過突破邊界來漫遊企業的內網，從而拿到公司內部的核心資訊。

系統服務安全

系統服務相關的安全問題主要體現在系統基礎依賴元件及基礎服務漏洞兩個方面。
典型的系統服務相關安全問題主要包括OpenSSL 心臟滴血、Shellshock BASH遠端命令執行、Redis 未授權訪問、各種基礎服務的弱口令等配置問題。
近些年爆發的一些全球性安全事件包括：心臟滴血、BASH遠端命令執行等漏洞，影響範圍非常廣，這些都是由於系統的基礎依賴元件存在安全問題導致的。

應用配置安全

應用配置安全主要體現在應用上線流程和各種配置不當方面。

在應用上線流程中常見的安全問題，例如上線程式碼的SVN及Git配置檔案目錄未刪除導致程式碼資訊洩露，資料庫及程式碼的備份檔案放在 WEB目錄下導致被黑客下載等問題。
通常Webserver的配置也是配置風險的大頭問題，這裡面不乏由於Webserver配置不當導致任意系統檔案遍歷，列目錄風險等問題。
問題這麼多，這麼辦？

如何構建安全運維服務平臺

基礎資產管理

企業安全的核心是資料安全，而基礎資產是這些核心資料的載體，所以在構建這樣一個安全運維服務平臺之初，我們首先應該做好基礎資產的發現和管理。
基礎資產發現，甲方可以從兩個角度來考慮，一個是依賴於內部的資產運維管理流程，另外一個是站在外部攻擊者的角度來進行資產探測，這樣做的話可以有效的進行互補，因為如果僅從內部資產運維管理流程中來對接企業的IP、域名等資產的話對於內部資產管理的要求會很高，而往往企業內部規範落地很難，導致一些資產會遺漏，而外部探測的方式就能夠很好的彌補。
外部資產發現的方式主要包括：子域名的暴力列舉，通過一個子域名命名常用字典來挨個遍歷子域名；第三方的DNS資料分析獲取企業相關的子域名和IP；除此之外還可以通過第三方查詢介面、網站爬蟲、域傳送漏洞的方式獲取相關子域名IP的資訊。
基礎的域名IP資產梳理完畢後，我們需要思考如何把資產管理這件事情做的更加高效。
域名IP是一個比較粗粒度的資產，為了方便應對全球不斷變化的安全風險，我們需要做到更加精細化的資產識別，比如每個域名IP上所部署的應用及服務相關資訊，一旦這些應用及服務在網際網路上暴露出來安全風險，運維服務平臺就能第一時間進行響應，這些都依賴於指紋識別技術。
指紋識別方面包括服務指紋識別和應用的指紋識別。
服務指紋識別方面Nmap完全可以滿足大家的需求，而且可以方便的進行指紋規則的定製；
應用指紋識別方面我們可以考慮從HTTP協議層面，包括特殊WEB應用的HTTP Headers欄位的特徵，比如某應用會使用特殊的Cookie值。另外包括特殊應用獨有的靜態JS/CSS/HTML檔案特徵。
通過這些特徵基本可以識別市面上所有的第三方應用特徵。

持續風險監測

在前面的資產管理模組中我們提到資產指紋識別主要分為服務及應用指紋識別兩方面，同樣在進行風險檢測時也是關注服務及應用的風險檢測。
服務風險檢測主要包括系統基礎服務相關的通用漏洞和服務配置不當的風險檢測；
應用風險檢測主要包括一些第三方應用的通用漏洞和自研的應用風險。第三方應用的通用漏洞通常根據具體漏洞的利用方法來編寫具體的檢測策略即可，而自研的應用風險如典型的SQL注入，則只能通過嘗試不同的攻擊測試Payload來判斷是否存在漏洞，這通常和具體的漏洞場景有關。
那麼如何讓風險檢測這件事情變得更加高效呢？
我們知道關於風險的檢測最重要的就是檢測策略，而且網際網路相關的技術是在不斷變化的，也帶來不一樣的漏洞風險。這就給企業在覆蓋不同風險的檢測策略上帶來了極大的困難，那麼如果我們能夠聯合安全社群的力量來完善策略就能夠完美且高效的解決這個問題，而作為平臺方只需要做的一件事情就是提供足夠好的引擎框架來方便社群的安全專家為平臺提供策略。
同時還需要有良好的機制來運營社群，比如說將風險發現的結果和白帽子編寫檢測策略的獎勵對應起來，這樣可以很好的激勵白帽子寫更多更好的檢測策略。

安全事件處理

當企業發現了風險以後接下來需要做的事情就是去進行事件的處理，企業需要建立一個及時有效的處理流程：首先從發現問題開始，接下來是進行風險通告，通告到存在風險的具體業務部門，同時指導業務部門進行風險整改。
這個環節有一個很重要的細節就是，業務部門的研發人員其實是不瞭解安全的，所以在重視安全問題及修復過程中可能會存在修復不當的情況，所以在通報修復的過程中最好有安全人員進行跟進。
最後修復處理完畢後還要進行及時的迴歸測試。
當然，除了需要去及時處理一些已知存在的安全風險，還需要有預警全球正在爆發的通用安全事件的能力，比如當年爆發的Struts2漏洞的時候，漏洞爆發的第一時間需要預警到各個可能受影響的業務部門，要求業務部門及時配合自查整改。這樣能夠更大程度上贏得修復的時間。
關於安全事件處理流程如何更加高效？
核心是需要把安全運維服務平臺和業務部門的產品生命週期管理流程打通，最好有API直接對接到產品開發上線的流程中去，安全問題作為產品的嚴重BUG一樣得到及時的排期修復。
同時這個過程中一定要有一個專業的安全人員進行跟蹤服務，確保問題不會修復不當，導致問題反覆出現。在全球風險預警方面最好對接社群的力量，因為小團隊無法跟蹤全球最新的安全風險動態。

持續風險管理

由於業務是在持續不斷的迭代更新，所以為了保證業務在迭代更新過程中不斷的規避風險，需要對業務系統進行週期性的持續監測。
這樣能夠避免由於迭代更新帶來新的安全風險和避免曾經修復的安全問題回滾再次出現。另外一方面可以對持續風險監測的結果進行趨勢分析，這樣能夠幫助我們發現企業當前一段時間主要面臨的安全問題，在下一階段的安全建設上就能夠提供有效的指導建議。
關於如何高效的進行持續風險管理，一方面需要能夠自主的配置週期性的檢測，這樣可以適應企業的迭代更新頻率；另一方面還需要支援不定時的手動啟動檢測風險來滿足突發的應用上線。
在風險管理方面可以支援定期的報表匯出和自定義的匯出策略，如此能夠更加高效的滿足風險運營管理的需求。
以上就是本次分享的所有內容。