從“軟件定義”到“智能協同”
大數據分析以及人工智能的發展，使得安全智能化成為可能。本文從軟件定義著手，結合云安全技術路線的三個階段，詳細闡述了為什么云安全一定要實現智能協同化，這種智能協同是否可行以及如何來實現。
云安全，從“軟件定義”到“智能協同”，是趨勢、是必然，當然也是挑戰。
一、概述
“軟件定義”的概念，伴隨著軟件定義網絡的興起，曾一度被追捧。相繼出現了軟件定義存儲、軟件定義體系結構、軟件定義數據中心、軟件定義云計算等等，甚至出現了軟件定義一切。當然這其中也包括了軟件定義安全。
那么軟件定義為何如此備受青睞呢?筆者認為，軟件定義提出了一種對于解決問題近乎完美的想法，它把所有美好的愿景都寄托在了邏輯上集中的控制中心，尤其是隨著虛擬化和云計算的不斷發展和應用，這種集中控制的需求顯得越來越迫切。
圖1 軟件定義的三個層次
軟件定義是一種態度、是一種思想、是一種架構。這種架構思想包含三個層面上的內容：首先就是最下面的資源層，也可以稱作基礎設施層，或者叫執行層，是需要被控制和操作的對象;其次就是控制層，這是軟件定義架構里面的集中控制中心，是下面執行層所執行操作指令的發出者;最后就是上面的應用層，基于具體的業務需求，實現不同的應用，進而通過控制層將相應的控制邏輯下發到執行層，轉化為對應的執行操作指令。
軟件定義也僅僅是一種架構思想。從整個系統來看，實現了軟件定義，也就相當于實現了系統的骨架，真正的思維和靈魂，是上層的應用。這和互聯網時代所謂的“應用為王”是相通的。
那么回到云安全，云計算的特性決定了傳統的安全解決方案對云安全來講，是不能完全復制、復用的。在這里，筆者將云安全的技術路線總結為三個階段：
圖2 云安全技術路線
1. 安全設備虛擬化
在云安全發展的早期，由于云計算的資源虛擬化、多租戶、彈性伸縮等特性，傳統的“安全盒子”方案沒有辦法解決云中的安全問題了。那么簡單而有效的辦法，就是將“安全盒子”也進行虛擬化，具體體現形式就是由硬件設備變成虛擬機。
這樣不同的租戶，根據各自不同的安全需求，在其租戶網絡內進行安全虛擬機的申請、部署、使用。比如某租戶需要對其業務系統進行入侵檢測、web防護，那么他就可以申請購買一臺虛擬化IDS和WAF進行部署。
這種單純的虛擬化方式，其實和傳統數據中心的安全方案并沒有太大的差別，只不過是把硬件設備變成了虛擬機。安全設備的管理、配置、運維還是需要用戶人工登錄到各個設備進行操作。
這樣，簡單粗暴的虛擬化方式，就形成了第一階段的云安全解決方案。基本實現了對云環境進行專業安全防護的從0到1過程。
2. 安全資源池化(軟件定義)
隨著人們對云安全認知的不斷深入，大家不再滿足于這種簡單粗暴的方式。
從云服務提供者角度來看，他會考慮所有租戶獨占一套安全設備虛擬機時，對于云中的資源利用率來說，性價比是否合適;
從用戶的角度來看，1)租戶獨占方式購買、部署安全設備虛擬機，其安全成本是否合適，據筆者了解，單獨的安全設備虛擬機在云里面的價格，也是不低的;2)安全運營成本是否合適，一方面需要像傳統安全設備一樣，逐個的對每個安全虛擬機進行安全策略的配置，繁瑣麻煩;另一方面，安全設備又包括透明模式、代理模式、旁路模式等多種的部署方式。這都需要具有一定安全背景的專業人員才能夠完成的。
那么在這個階段，基于軟件定義安全的云安全方案就應運而生了。安全資源不再是租戶獨占的安全設備虛擬機，而是通過安全資源池化的方式，為租戶提供無感知的安全服務。
這樣一方面對于云服務提供商來說，池化的方式可以更好的提高其資源利用率;另一方面，對于用戶來說，服務化的方式既不需要自己進行復雜的部署，也可以通過安全應用盡可能的降低其安全運營成本。
圖3 基于安全資源池的云安全方案
3. 安全防護智能化(智能協同)
正如前文對軟件定義的描述那樣，第二階段的基于軟件定義安全的云安全方案，算是將這種池化的安全系統骨架搭起來了。那么怎樣在這個骨架的基礎之上，將其變的有血有肉有靈魂，就是安全防護智能化需要考慮的了。
這里的智能化可以包括如何動態靈活的僅將必要的流量進行專業的安全檢測;如何通過多個設備的自動化聯動，實現復雜的攻擊檢測;如何針對檢測到的異常準確的進行防護處置;以及如何不斷提高自身的檢測與防護精準度等等。
接下來，本文就將詳細的介紹，進入智能協同時代，如何利用大數據以及人工智能的方式，設計實現更加完善的云安全解決方案。
二、智能協同
2017年“智能”這個詞簡直是太火了，以至于誰家的產品和方案不貼個“智能”的標簽，根本不好意思拿出來講。但是筆者認為智能化是有前提的，是需要積累的，就像我們想要造一艘能拉貨過河的船，萬噸油輪肯定是好的，但是如果連普通貨船都造不好呢，誰又敢相信他的大油輪呢?
道理一樣，今天我們談智能協同的云安全，也一定是順勢而為，水到渠成的。
1. 什么是智能協同
所謂智能，根據維基百科的解釋，可以將其總結為“讓機器能夠像人一樣，可以觀察周圍的環境，進行感知、學習、分析，并且做出相應的行動以實現某種目標”。那么智能協同的安全防護，筆者將其定義為“安全防護系統能夠進行威脅感知，并且調動所有可用的安全資源，主動的進行威脅檢測防御，同時不斷提升自己的威脅感知能力”。
Gartner在2016年提出了“自適應安全”(Adaptive Security)的防護模型，模型中包括了預測(Predictive)、防御(Preventive)、檢測(Detective)和響應(Retrospective)這一持續處理的安全防護過程。自適應安全架構，是實現智能協同安全防護的一種典型架構設計方式。通過對四個階段的劃分，形成一個持續的閉環防御體系。
圖4 自適應安全模型
在整個模型中，持續的監控和分析成為了其核心所在：
- 預測能力強調安全系統需要具備持續對業務系統進行監控分析的能力，據此形成相應的安全基線，主動對業務系統進行風險評估以及威脅預測。
- 防御能力指一系列安全防御產品和服務，提升威脅攻擊門檻，防止事件發生。
- 檢測能力用于發現那些進入防御網絡的攻擊，對事件進行確認和處理，降低威脅造成的損失。
- 響應能力需要能夠對系統脆弱性提出修復意見，對威脅事件進行調查取證，同時更新預測手段，避免再次遭受類似的安全威脅。
2. 為什么一定要智能協同
那么為什么說云安全技術路線的第三個階段一定是智能協同呢，我們從以下兩個方面來看：
首先從云計算系統的角度來看，假如一個擁有50臺計算節點的小型私有云，平均每臺主機間的東西向流量為3G左右，雙向的話大約就是5G—6G，那么如果要對所有的流量進行專業安全檢測，就需要足夠安全資源能夠處理300G的流量。同時在這種情況下，云數據中心會額外增加一倍的東西向流量用于安全檢測。這無論是對于計算資源，還是網絡帶寬資源，都是一筆不小的投入。
而這double出來進行檢測的流量，其中異常的部分可能不及5%。因此，我們一定要讓安全防護系統用一種“聰明”的方式來進行應對，而不是粗獷的“眉毛胡子一把抓”。這就是說，云安全一定要是智能的。
另外，從攻防的角度來看，攻擊者的攻擊手段千變萬化。尤其是像APT這種高級持續性的威脅，攻擊者在發動攻擊之前會對攻擊對象的業務流程和目標系統進行精確的信息收集，這種行為往往經過長期的經營與策劃，并具備高度的隱蔽性。一旦發現可乘之機，便會對攻擊對象發起大規模的攻擊。
面對這種威脅，單一設備基于規則的安全防護和檢測，在處理起來可能會有些力不從心。需要漏洞檢測、入侵檢測、未知威脅檢測等多種手段，共同來應對。這就是說，云安全一定要是協同作戰的。
3. 可行性分析
理想很豐滿，現實情況是什么樣的呢?下面我們對智能協同進行可行性分析。
圖5 可行性分析
(1) 全局網絡視圖
作為云管理平臺，網絡監控以及流量可視化是基礎也是必要的功能。這里的流量既包括南北向機房入口的流量、也包括整個Spine-Leaf層跨宿主機流量、同時還包括宿主機內虛擬化層的網絡流量。這些流量信息都是可以進行采集、監控和分析的，只不過從上到下難度會逐漸的增加。
通過云管理平臺的網絡監控，一方面可以獲取到flow層的信息，這層的流信息相對來講還比較輕量，獲取難度也比較小，比如通過SDN或者netflow等方式;另一方面可以獲取到packet層的信息，通過端口鏡像、專用采集器等方式，拿到完整的數據包，這個層面的監控相對來說難度會稍大一些，因為可能會涉及到一些租戶的隱私。
這樣把收集到的flow和packet連同租戶以及租戶網絡信息放在一起，就形成了全局的網絡視圖。有了這個全局網絡視圖，就很容易對其中各個租戶的相關流量信息進行分析和監控。
圖6 全局網絡監控
(2) 流量畫像
據筆者了解，無論是公有云還是私有云，用戶在虛擬云主機上，主要包含兩種類型的業務：一種是自身的業務系統，比如門戶網站、辦公系統、信息系統之類的;另外一種就是集群計算系統，主要用于后端的數據運算。而無論是哪種業務，它們都有一個共同的特點，就是云主機之間的東西向流量一定存在某種固定的特征，比如某個主機開放哪些端口、這些主機和端口的訪問客戶端是哪些主機、他們通常會在什么時間段進行什么樣的流量交互、流量大小又有什么樣的特征等等。
我們可以將這種特征稱之為流量畫像，或者行為基線。那么如果某一時刻，實時流量和畫像描述的特征不符，那么這種“另類”的流量就很有可能是存在安全威脅的。
(3) 攻擊鏈
下面再從攻擊鏈的角度看一下。攻擊鏈是根據攻擊者對目標系統入侵的不同進展程度進行階段劃分，將各個階段串聯形成完整的攻擊過程的模型。對于攻擊鏈中的每一階段，都可以通過流量監控/檢測提取出來的特征屬性，間接判斷出威脅攻擊的進展。比如在偵查探測階段，可以通過發現異常的端口訪問，或者在工具分發階段發現異常大小數據包等，更早的發現并預防威脅的發生。
由于攻擊者攻擊手段的隱蔽性，以及攻擊鏈模型中各階段的界定有一定的模糊性，單個階段難以評估目標遭受入侵的嚴重程度，因此可以對各階段之間進行關聯分析。同時與流量畫像進行對比分析，發現可疑流量。
圖7 攻擊鏈模型
(4) 安全資源池化
池化的安全資源是安全防護基礎性保障，能夠根據檢測防護需求，快速動態的進行資源的生成、配置、使用，同時還可以靈活的實現多種安全手段的有效聯動。這部分作為先決條件，前文已經進行了詳細的介紹，這里就不再贅述了。
云計算系統有著全局的網絡視圖，能夠對其中的網絡信息進行監控和分析，結合其應用特點，進而可以生成相應的流量畫像。一旦發現網絡流量特征與畫像不符，便可以通過池化的安全資源進行深度精準的檢測。
三、實踐方案
下面的架構圖展示了一種智能協同的云安全設計方案。
右半邊是云計算管理平臺，通過流量采集，將所有的流量信息進行“可視化”，這里的流量既可以flow級的，也可以是packet級的，流量采集的手段當然也可能是netflow、SDN或者其它方式，不同的云服務提供商，可能會有不同的實現方式。
圖8 方案架構圖
左半邊為安全資源池，通過安全控制平臺對其中的各種安全能力進行統一管理。最上層實現為智能協同的安全應用，AI應用根據云平臺中的流量監控信息智能的生成防護方案和策略，編排模塊據此調用對應的安全資源進行防護響應。方案流程可參考下圖。
圖9 方案流程圖
在服務上線前(確保無威脅存在)，AI應用從云計算管理平臺獲取租戶所有的監控流量信息，形成相應的流量畫像，作為其流量行為基線。系統上線后，實時獲取流量監控信息，對于符合流量行為基線的流，則認為是正常的。
對于與畫像不符合的流，則通過編排應用，生成相應的安全審計流程，針對這部分流進行更深入的安全審計，審計結果可轉化到實時的防護規則。
安全資源池的防護結果，可以反饋到AI應用，AI應用根據這個結果不斷的調整其判斷的準確性。當然，考慮到誤報，這個過程必然會需要一定的人工參與。AI應用應盡可能地從流程、視圖和算法層面降低人力投入成本。
上述方案僅僅是對于云安全智能協同化的一個簡單設計，算是拋磚引玉。真正實現這種智能協同化，還是有很長一段路要走的。
四、總結
本文從軟件定義著手，結合云安全技術路線的三個階段，詳細闡述了為什么云安全一定要實現智能協同化，這種智能協同是否可行以及如何來實現。
云安全，從“軟件定義”到“智能協同”，是趨勢、是必然，當然也是挑戰。
【本文是51CTO專欄作者“綠盟科技博客”的原創稿件，轉載請通過51CTO聯系原作者獲取授權】
