微隔離不僅是防火牆
前言：
作為國內微隔離市場的主要開拓者，我們經常被問一個問題，那就是我們的系統上都裝了防火牆，為什麼還需要微隔離呢？我們通過自動化指令碼配置主機防火牆策略不是也可以做到點到點白名單控制麼？
首先，我們必須承認這個看法本身還是有一定的道理的，在比較小比較靜態的網路中（小於20臺伺服器）也基本是可以工作的。但是如果我們討論的是一個定義為“雲”或者“軟體定義的資料中心”的中等規模以上的計算系統，那麼我們就有一些東西要和您分享一下了。
一、 軟體定義的隔離
“微隔離”這個詞是一個比較商業化的市場用語，而這個技術事實上還有一個更加學術一點的名字——軟體定義的隔離（Software Defined Segementation）。事實上這個名字才更加本質的說出了這個技術的內涵。就像軟體定義的網路（SDN）一樣，軟體定義的隔離的特點就是隔離點（enforcement point）與策略控制（policy）相分離，從而讓隔離更加靈活，更加智慧，進而有可能對由海量工作負載構成的複雜而多變的虛擬化網路進行隔離管理。
在過去，我們主要通過防火牆來做隔離這個事情，在那個時候，策略的管理和隔離的動作都是發生在防火牆裝置上的。就算是主機防火牆也是如此，它的策略也是配置在主機上的。這些策略一般是在防火牆上線部署的時候配置上去的，然後在整個防火牆的生命週期內基本不做調整。然而，進入到雲端計算時代之後，如此多分散的獨立工作的控制點變得非常難以維護和過於的僵化。進而導致了雲的使用者只能在安全與業務之間做一個二選一的選擇。要安全，業務就無法快速交付，要業務就無法進行有效的安全管理。這種局面呼喚了軟體定義隔離這種技術形態的出現。軟體定義隔離與傳統防火牆最本質的區別在於它把策略從每一個分散的控制點上給拿出來了，放在一個統一集中的地方進行設計，管理和維護，原則上，安全管理者不必要了解下面的控制點在哪裡，也不必再對每一個控制點進行策略配置和維護，這些工作都將由策略管理中心來自動完成。
而這種策略管理工作，不是基於預定義指令碼的簡單的自動化過程，而是一個基於實時網路環境監聽的，基於高層次安全策略的一種實時策略計算與策略更新過程。對每一個接入系統的控制點，根據實時發生的特殊事件，同時參考其他控制點的變化情況，做出獨特的，恰當的策略計算，這個過程就是軟體定義隔離的核心管理過程。
二、 主機防火牆與微隔離的關係
講清楚了微隔離技術的定義，再來回答使用者關於“主機防火牆”與微隔離的關係的問題就比較簡單了。簡單地說，主機防火牆相當於SDN網路中的白牌交換機，而策略計算中心相當於SDN控制器。
在微隔離的安全體系中，具體的訪問控制是通過主機防火牆來做的，但是策略不在主機防火牆上，而是配置在策略計算中心。這個計算中心從全域性收集資訊，然後根據預先定義好的高階安全策略去做具體的策略計算，然後生成主機防火牆能夠看得懂的五元組策略，並配置回去。
所以，主機防火牆自身無法完成微隔離功能，一個強大的策略計算中心才是微隔離體系的靈魂。事實上主機防火牆有著悠久的發展歷史，無論是iptable還是wfp都是久經考驗的好產品，他們在穩定性，相容性，效能上都非常出色。微隔離以這些老戰士為資料面的控制點事實上也是一種非常穩妥的選擇，而微隔離的核心技術應該放在策略計算能力上。
三、 微隔離技術的硬核究竟在哪裡
如果說主機防火牆不是微隔離技術的核心的話，那麼微隔離技術的硬核究竟在哪裡呢？我們說圍繞著安全策略的生命週期，微隔離技術主要就是三個地方展現技術含量。
首先是業務分析
要做隔離就需要具體的安全策略，所謂“安全策略”就是允許或者拒絕哪些流量的具體規則。微隔離要解決的是內網的點到點的訪問控制問題，一般來說都是採用的白名單策略。那麼問題就來了，這個策略應該怎樣設計呢？在內網充斥著大量複雜且私有的應用協議，除了業務開發者沒有人瞭解他們使用了什麼埠和協議，於是無論是運維團隊還是安全團隊都缺少設計安全策略所必須的業務知識。
所以要做策略管理，首先要分析業務，要把東西向的具體的通訊關係給找出來，最好是以視覺化的方式呈現出來，這樣安全團隊才能夠在此基礎上設計出正確的東西向安全策略。如果沒有這個能力，你有再多的防火牆也註定只能是擺設。
然後是策略建設
瞭解了業務的構成，下一步就是設計策略了。不過那又該怎麼做呢，是不是點開每一條線，看看源和目的的地址和埠，然後到主機上去寫防火牆規則呢？如果這麼搞，那就又掉進了一個深不見底的大坑了。你能想象在一個幾千臺虛擬機器，虛擬機器之間有十幾種通訊關係的私有云內用這種方法設計策略麼？
在這個階段，一個合格的微隔離管理平臺，應該做到兩件事情，一個是自學習互動式建立，一個是去ip化的策略表達。
一般來說，微隔離平臺通過業務學習，已經瞭解到全部必要的資訊，這個時候可以通過互動式的方式來建立策略，比如你選定一組虛擬機器，告訴平臺說，現在看到的所有虛擬機器間的通訊都是可信的，請為我建立策略，那麼微隔離平臺應該可以自動的來建立策略。
而創建出來的策略最好是去ip化的，因為ip在雲系統中是一個非常不穩定的引數，經常發生變化，最好可以由更高階更穩定的引數來描述，比如我們的comb平臺用的是虛擬機器的角色標籤來描述安全策略。
另外，我們的策略還能做到策略與策略作用物件脫耦，通過調整策略作用範圍，來動態的改變虛機上的安全策略部署。當然，這個不是必須的，不過這可以進一步下降策略總數，提策略運維的效率，我們覺得這樣很酷。
最後是策略自適應運維
雲是個快速變化的系統，安全策略也必須能跟上雲變化的腳步，我們看到現在各種雲安全規範中，都會有一條自適應要求（比如等級保護2.0的雲安全擴充套件部分）——“訪問控制策略能夠隨著虛擬機器的遷移而遷移”。其實我們一直很想跟有關部門提個建議，這個要求中缺少“自動”二字。導致很多產品通過手工遷移的方式，也能滿足要求。但是我們知道，這個要求的本意就是自動遷移。因為虛擬機器遷移是雲的常規操作，如果這個過程中需要安全部門的手工參與，勢必大大下降雲的彈性，增加業務遷移時間，並且帶來手工操作所不可避免的錯誤從而出現不必要的風險。
事實上，除了遷移以外，克隆，擴充套件，資源升級等操作也都會導致網路地址的變化從而需要安全策略做相應的調整，這些時候最好也都能實現安全策略的自適應調整。一個好的微隔離管理平臺，應該能夠做到這一點，否則就是一種管殺不管埋的產品設計，你幫助安全部門設計了幾萬條策略，然後你做不到自適應運維（注意是自適應，不是自動化），那麼以後安全部門的夥計們就可以不用下班了。我們的微隔離管理平臺叫做QCC——英文單詞Queen Computing Center的縮寫，它最核心的工作就是持續不斷的做策略計算和策略更新。
終上所述，大家可以看到，微隔離的核心在於一個高度智慧化的全生命週期黑科技的策略管理中心，主機防火牆不過是執行策略的控制點而已。如果大家要評估一款微隔離產品，請圍繞策略管理中心來下功夫，而不是防火牆，你要看他是否能真的把你帶上安全的新高峰而不是推入安全的新火坑。畢竟這才是你能否擁有一個愉快的微隔離使用體驗的決定性要素。
作者：薔薇靈動