烏雲章華鵬：如何構建高效的安全運維服務平臺

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

你們好，我是烏雲的章華鵬，今天和你們分享的話題是「高效安全運維服務平臺的構建」，包括：企業的數據安全問題，運維安全中面臨的網絡、系統服務、應用相關配置等問題。

企業安全的核心是數據安全

當咱們在討論如何構建安全運維服務平臺以前，咱們須要研究的問題是構建這樣一個平臺的核心需求是什麼？核心需求是幫助企業解決安全風險，避免由於安全風險帶來的業務損失。 咱們都知道對於一個依賴互聯網的企業來講，數據是企業的核心資產，那麼歸根結底，其實企業安全的核心是數據安全，因此咱們首先要明白企業的數據到底在哪裏？ 業務是數據的載體，IT資產是業務的載體，那麼運維的核心對象便是企業的IT資產，因而可知，企業安全運維應該是運維的一項基礎要求。 運維安全面臨哪些問題？ 高效安全運維平臺構建的前提—瞭解企業面臨的風險。企業的運維安全主要分爲：網絡、系統服務、應用相關配置三個方面。

網絡安全

主要是網絡邊界被突破帶來的安全風險。對於大多數存在互聯網業務的公司來講，服務都會分爲內網和外網兩塊區域，一般這兩部分業務是相互隔離的。 通常來講，企業內網主要部署着一些公司內部的敏感系統，這些系統只須要對內部員工開放，與互聯網是隔離的。既然存在邊界隔離，那麼就會存在一些網絡邊界被穿透的安全隱患。 企業網絡邊界安全的典型風險主要表如今如下幾個方面：包括某臺服務器同時部署內網&外網業務、SSRF漏洞、IDC與辦公網網絡互通、未受權代理配置、IDC服務器被入侵等等。 這裏對其中一些比較專業的概念作一個解釋，某臺服務器同時部署內網&外網業務這個其實就很容易理解了，好比有兩個研發公用一臺服務器，其中這臺服務的內網IP映射到一個內部的業務系統，好比ERP；但同時這臺服務器又部署了一個外部的業務，好比企業的官方博客，而這個博客綁定的是外網IP/域名。 SSRF漏洞，說白了就是至關於一個應用層的代理，能夠利用這個應用層的代理來對內網任意地址發起請求。 未受權代理配置主要一些相似Squid這樣的代理未添加受權控制，致使任何人均可以直接經過這個代理帶請求內網資源的問題。 在烏雲平臺，常常能夠看到這樣一些案例，一些攻擊者能夠經過突破邊界來漫遊企業的內網，從而拿到公司內部的核心信息。 上圖是一個關於某互聯網公司SSRF的案例，詳見烏雲http://www.wooyun.org/bugs/wooyun-2016-026212，相似內網漫遊的案例在烏雲漏洞報告平臺上搜索一下有超過400條的記錄。

系統服務安全

系統服務相關的安全問題主要體如今系統基礎依賴組件及基礎服務漏洞兩個方面。 典型的系統服務相關安全問題主要包括OpenSSL 心臟滴血、Shellshock BASH遠程命令執行、Redis 未受權訪問、各類基礎服務的弱口令等配置問題。 最近爆發的一些全球性安全事件包括：心臟滴血、BASH遠程命令執行等漏洞，影響範圍很是廣，這些都是因爲系統的基礎依賴組件存在安全問題致使的。 上圖是一個國內某電商網站的心臟滴血漏洞，烏雲主站搜索redis 相關的風險也有將近400 條。

應用配置安全

應用配置安全主要體如今應用上線流程和各類配置不當方面。 在應用上線流程中常見的安全問題，例如上線代碼的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同樣獲得及時的排期修復。 同時這個過程當中必定要有一個專業的安全人員進行跟蹤服務，確保問題不會修復不當，致使問題反覆出現。在全球風險預警方面最好對接社區的力量，由於小團隊沒法跟蹤全球最新的安全風險動態。

持續風險管理

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