微隔離為等保2.0而生
作為云安全的重要基礎構件,微隔離技術最早由VMware提出,這是眾所周知的事實。然而作為國內微隔離領域的領導廠商,薔薇靈動的誕生卻與等保2.0有著密不可分的關系。等保2.0的技術標準研究工作從2015年已經開始,薔薇靈動的兩位創始人作為安全領域的技術專家,很早就了解到了相關的技術內容。根據對等保2.0的安全理念和具體技術要求的研究,他們深刻地認識到,現有的防火墻技術在等保2.0時代將面臨巨大挑戰,尤其是在云環境下將變得完全不可用。從那時起他們就在思考如何解決這個問題,并把握這樣一個市場機遇。
經過長期的思考與技術預研,他們認為微隔離技術必將作為一項顛覆性技術,成為未來數據中心尤其是云化數據中心東西向網絡安全的基石,幫助用戶滿足等級保護2.0關于內部安全的一系列要求。在薔薇靈動的第一版商業計劃書中就明確將等保2.0列為其首要市場驅動因素,并于2017年年初正式成立公司,開始了產品研發工作。從這個角度來說,中國的微隔離技術就是由等保2.0催生而出的科技創新。
雖然等保2.0的正式發布比他們預計的要晚了一些,但是這也給了薔薇靈動以足夠的時間來磨煉產品,打造標桿。迄今為止,薔薇靈動已經為海淀區電子政務云,通州區電子政務云,中國移動,中國電信,中國人壽等多家政企客戶提供了微隔離產品和服務,部署的環境覆蓋了VMware,OpenStack,阿里云,騰訊云,華為云,華三云,天翼云,青云,K8s等各種云計算和虛擬化系統,操作系統覆蓋了包括windows的全線服務器版本,所有的主流linux版本以及部分國產化操作系統。
2019年5月13日,等級保護2.0技術標準正式發布,這將成為中國網絡安全行業發展歷史中的重要里程碑事件,也將成為薔薇靈動發展歷史中的關鍵節點。
微隔離從高配到標配的轉變
以等級保護2.0技術標準正式發布為分水嶺,可以把微隔離產品的發展化為兩個時期。
在等保2.0以前,微隔離技術屬于高配技術,他的核心驅動是兩個,一個是零信任的安全管理邏輯,一個是大規模云計算系統的安全運維需求。這時候主要部署微隔離技術的用戶包括:
1)大型行業用戶:
例如央企制造業,金融行業等,這些用戶一直以來都極為重視安全,他們的業務系統從來都是按照白名單方式來進行網絡策略管理的,但是在云計算時代,過去的技術手段遇到了問題,使得他們開始考慮采納微隔離技術作為替換性技術來在云計算環境下繼續提供白名單的管理能力。
2)大型云計算用戶:
即使不做白名單,而只是在業務系統間進行隔離,在大規模云計算環境下也變得非常困難,云基礎架構提供的安全組,VPC等能力隨著體量的增長和變化頻度的加快變得極為不可用,此時他們也考慮采用更專業的微隔離技術來在云計算環境,尤其是多云,混合云條件下完成其業務隔離,區域隔離需求。
3)高安全需求用戶:
隨著APT越來越引起重視,以及勒索病毒的泛濫,網絡安全管理者越來越重視內部威脅的防御工作。現有的安全技術主要是南北向技術,防御對象是外部攻擊,這些技術應用于內部的時候往往有各種不適應,此時,用戶會考慮部署微隔離技術來發現內部的威脅,并對網絡攻擊在內部的橫向行走進行防御。
而隨著等級保護2.0技術標準正式發布,微隔離技術將從過去的高配變成標配。
關于等級保護2.0對內部安全的要求及其帶來的挑戰,在我們去年的一篇文章中做了深刻的技術分析,大家可以參考這篇文章:
《東西向加白名單,等保2.0挖了個天坑》
值得再強調一下的地方是,對于內部安全的重視不僅僅是在云環境,而是在全部計算環境,因為這些要求是出現在等級保護的通用安全要求部分。也就是說不管你是不是已經進行了云化或者虛擬化,你都必須要對你的數據中心進行白名單化管理。當然,在非云環境下,除了微隔離,還是有其他手段的,比如說,過去的銀行系統就通過部署大量的隔離防火墻來解決這個問題,不過這個開銷真不是普通用戶能承擔的了的。相較而言,更加輕量級的微隔離技術即使在傳統環境下也有著更好的可行性。
在等保2.0時代,以下用戶和場景應該盡快考慮部署微隔離技術以實現對內網流量的可視化管理與全面可控的策略設計。
1) 各級電子政務云
2) 企業私有云和數據中心
3) 政府部委部署的數據中心,私有云和行業云
4) 各種大數據計算平臺
5) 政企用戶沒有部署過內部安全措施的數據中心
2) 企業私有云和數據中心
3) 政府部委部署的數據中心,私有云和行業云
4) 各種大數據計算平臺
5) 政企用戶沒有部署過內部安全措施的數據中心
微隔離部署方式
微隔離技術要管理的是由數千甚至數萬臺機器構成的大型計算環境,在部署這一技術時必然有一定的復雜性,通過長期的實踐,薔薇靈動總結出了一套自己的方法論:
第一步,對東西向業務進行學習,繪制云內業務拓撲。
第二步,業務梳理(確認)
這一步,在不同的用戶處不太一樣,有的用戶過去沒有完善的資產、業務與配置管理體系,這就需要首先建立起一套業務模型出來。無論如何,在你根本不理解業務的情況下,是不可能進行有效的東西向安全策略設計的。這種情況下,這一步的工作量就變得比較大了,而且往往需要調度多個部門進行協作。不過,既然等保2.0已經來了,這是早晚都要做的一步,用我們的技術已經把工作量縮減了好幾個數量級了。
而如果是用戶過去就有很好的類似于CMDB的資產與業務管理系統,那么我們就只需要做業務確認即可,因為實際的業務情況可能會與系統中的不一樣,或者系統中缺少一些信息。
第三步,策略設計
好的微隔離產品,一定能夠根據業務情況自動生成安全策略(當然,好的安全產品一定能看得見業務),否則,如果讓用戶自己去逐臺機器進行配置,那根本就是一場災難。比如我們的一個客戶,有兩萬臺虛擬機,隨便一個業務系統就有超復雜的內部業務關系,給張圖你們自己體會下(這還不是虛機間關系,只是業務間關系)。
而且策略最好是IP無關的,比如薔薇靈動可以直接根據虛擬機的業務標簽來配置策略。因為IP地址在云內是個非常不穩定的參數,一旦策略是用IP配置的,那么后面的運維就非常痛苦了。
第四步,自適應運維
好的微隔離產品,一定能夠進行自適應的策略運維,也就是當云計算環境發生,遷移,擴容,升級等變化時,系統可以對安全策略進行自適應調整。沒有這個能力,策略運維將變得非常困難,甚至是難以完成的。比如我們的另一個客戶,每天都有新業務上線,隨時都有可能進行業務架構調整,此時如果策略運維不是自動完成的,那么他們的業務交付必將被安全所拖累。
第五步,自動化編排
云計算環境下,一切都是軟件定義的,這當然也包括安全。不同的安全產品,需要被進行統一的管理和調度。我們的產品從設計之初就采用了微服務架構,每一個點擊,每一個查詢背后都有對應的API可以使用,這使得我們可以被整合到云管理系統中,或者被SOC/SIEM等安全管理平臺所調用。
東西向安全是新的安全建設熱點,難度非常大。幸運的是,薔薇靈動已經打磨出了一款非常好用的東西向安全產品,并積累了豐富的部署經驗。等保2.0來了,我們準備好了!