全文約6666字 20圖表 閱讀約18分鐘
上一篇提到了Illumio實施零信任微分段的“三步走”方法論：1）獲得應用程式實時地圖；2）為工作負載打标簽；3）實施安全政策。
作為本系列第3篇，本文延續上一篇，重點介紹第3步（安全政策設定）。如果說應用程式實時地圖是技術根基，則可以認為自然語言安全政策是上層建築，容易展現“三步走”方法論的價值。
設定安全政策通常是相當困難的。由于應用程式是高度互聯的，即使隻有幾百個應用程式（可能由幾千個工作負載組成），也可能有數百萬個需要分析的連接配接。是以，設定安全政策的最佳方法是自動化生成允許這些連接配接的政策。
本文将結合一個示範（Demo），來更清楚地解釋自動化的自然語言政策方法。通過手把手的配置過程，令人不禁感歎：原來零信任的實施也可以如此簡單！當然，其背後隐藏了很多複雜性。
是以，Illumio其實是在盡其所能提升客戶體驗，把簡單留給客戶，把複雜留給自己。
目 錄
1.總體架構：安全大腦+神經元
1）神經元：虛拟執行節點（VEN）
2）安全大腦：政策計算引擎（PCE）
2.工作負載微分段之“三步走”方法論
3.四維标簽模型及其資料治理
1）Illumio的四維标簽模型
2）标簽資料的來源
3）标簽資料的品質
4）标簽資料的治理
5）從網絡語言轉向自然語言
4.應用程式的五級可見性
1）第1級可見性：全局視圖
2）第2級可見性：單個資料中心
3）第3級可見性：單個應用程式
4）第4級可見性：單個主機（工作負載）
5）第5級可見性：跨多個資料中心的單個應用程式
5.自然語言安全政策設定
1）通過政策生成器編寫安全政策
2）第1級安全政策：應用程式組級别
3）第2級安全政策：應用程式角色級别
4）第3級安全政策：應用程式服務級别
6.安全政策的測試驗證
1）建構（build）模式
2）測試（test）模式
3）強制（enforce）模式
01
總體架構：安全大腦+神經元
Illumio總體架構是安全大腦+神經元的結構。安全大腦是政策計算引擎（PCE），神經元是虛拟執行節點（VEN）。如下圖所示。使用零信任架構的語言講，政策計算引擎（PCE）是政策決策點（PDP），虛拟執行節點（VEN）是政策執行點（PEP）。
圖1-總體架構：安全大腦+神經元
1）神經元：虛拟執行節點（VEN）
如圖，您可能會在資料中心或雲中，運作裸機、虛拟機、容器。我們可以先在這些機器上安裝一個VEN代理。它很像天線（或神經元/傳感器/探針），其作用就是發送和接收資訊。它會收集IP位址、機器主機名等資訊，甚至收集打開的程序、端口和與之通信的東西，并将其發送到安全大腦即政策計算引擎（PCE）中。
2）安全大腦：政策計算引擎（PCE）
政策計算引擎（PCE）是整個解決方案的大腦。PCE可以部署在客戶資料中心的實體或虛拟伺服器上運作，也可以直接在Illumio雲服務中使用。不論哪種方式，都可以擴充到支援數十萬個工作負載。
PCE這個大腦會做兩件神奇的事情：
一是制作應用程式通信的地圖。而這些都是神經元VEN報告的。值得提醒的是，這是一個應用程式拓撲圖，而非一個網絡拓撲圖。
圖2-應用程式實時地圖
二是根據應用程式實時地圖，編寫安全政策。這裡的特别之處在于，你可以使用非常母語化的語言（即自然語言而非網絡語言），編寫安全政策。安全政策的樣子就像“我想讓web層與資料庫對話”，或者“我想分段我的生産環境”這種自然語言，而非難以了解的IP位址等網絡語言。
一旦你讓這種語言或者政策就位，政策計算引擎（PCE）将把它翻譯成本機第三層/第四層狀态防火牆的規則，并将其發送回VEN。
虛拟執行節點（VEN）所做的并不隻是強制執行任何操作，相反，它還會對Linux的iptable進行程式設計，也對Windows的Windows過濾平台（Windows Filtering Platform）進行程式設計。而且，還可以跨Solaris或AIX這樣的遺留系統，來實作這一點。
故事并沒有結束，因為您的應用程式總是在變化。當您從一個資料中心故障切換到另一個資料中心時，會發生什麼呢？或者說當你遷移到雲端時？VEN都會向PCE更新這些變化資訊。而PCE則會不斷地重新計算政策，以確定VEN上的政策是最新的。
02
工作負載微分段之“三步走”方法論
何謂工作負載？在Illumio的話語體系中，工作負載指的是網絡上的端點，可以是實體或虛拟伺服器、公有雲執行個體、容器、儲存設備、負載平衡器或代理裝置上的VIP，或者任何具有IP位址的東西。
如上篇所述，Illumio高度概括了實施零信任微分段的“三步走”方法：
圖3-工作負載微分段的“三步走”方法
第一步是擷取地圖：Illumio使用“應用程式依賴關系圖”（Application Dependency Map），來實作應用程式實時地圖（Application Real-time Map）。進而獲得了應用程式級（而非網絡級）的上下文，包括應用程式元件以及這些元件之間關系的可見性。這是上一篇介紹的重點。
第二步是給工作負載打标簽：采用四個次元的通用中繼資料，對工作負載打标簽，并且根據标簽進行分組。進而獲得了帶标簽的應用程式實時地圖。上一篇也做了簡單介紹。
第三步是制定和實施安全政策：這是本篇的重點。首先，要輕松的編寫安全政策，本就是一件難事。另一個難題是：在真正強制執行安全政策之前，您需要一種方法來測試和模組化這些政策。因為我們經常看到客戶長期陷入這種狀态：他們在送出新的安全政策後，隻能祈禱這些政策不會破壞他們的應用程式。這正是因為他們缺少一種方法，在進入強制執行之前測試他們的安全政策。
03
四維标簽模型及其資料治理
1）Illumio的四維标簽模型
安全政策的前提是标簽模型。Illumio的安全政策是根據四個标簽次元編寫的。如下圖所示。
圖4-四維标簽模型
标簽模型的關鍵之處包括：
- 務必謹記：标簽不是組。每個标簽次元都是獨立的，标簽可以組合起來，為每個工作負載形成一組唯一的安全屬性。
- Illumio的四維标簽模型是建構可擴充和可管理的安全政策的關鍵。基于上述四個次元交叉點的政策，不僅易于實施，而且易于審查和維護。而常見的标簽模型，如扁平組（flat groups）或任意級别“标記（tagging）”，則通常很不靈活。
- 每一個标簽次元都應該被用來引用同一個邏輯概念。比如說，如果角色（Role）标簽用于表示應用程式的分層，就不應該再用于表示資訊敏感度的分級。
2）标簽資料的來源
大多數組織都有一些資源，可以利用它們來擷取至少一個标簽次元。大型企業通常有CMDB或其他功能齊全的目錄，較小的組織可能有一個電子表格，甚至是一個主機名約定。雖然可能不完整或不準确，但都沒關系。
在應用Illumio解決方案的早期，客戶需要識别哪些資源可以為其工作負載提供部分或全部标簽資料。當需要将這些資料提供給PCE（政策計算引擎）時，既可以手工輸入，也可以使用Illumio的API一次性或持續地自動同步。
3）标簽資料的品質
如果客戶擔心沒有一個完整的目錄或可靠的标簽資料來源，那就别費心了。通常來說，客戶通常能夠以50-80%的信心提供環境（Environment）标簽（即這是生産工作負載，還是非生産工作負載？），而對其他标簽次元的信心則低得多。
Illumio是基于現有目錄不完整或不正确的預期而建構的。采用Illumio控制過程，可幫助客戶提純和改進中繼資料。在客戶剛開始的時候，客戶并不需要有一個高品質的目錄，但是在完成的時候卻可能擁有一個高品質的目錄。
4）标簽資料的治理
為實作自适應安全，需要了解環境中可能影響安全性的變更。包括供應新的工作負載和停用舊的工作負載，以及标簽變化，例如将非生産伺服器更新為生産伺服器。
如果客戶的标簽資料是手工維護的，那麼客戶需要包含一個過程，以便在發生變更時更新PCE。
如果客戶使用Illumio的API将标簽資料加載到PCE，則更新通常每天進行，也可以根據需要随時進行，包括在變更發生時實時進行。
許多組織選擇實施資料治理過程或指定一名資料監護人來管理目錄中資料的品質。客戶通常會發現，在中繼資料品質方面的投資，會帶來廣泛的安全性和運作性好處。
5）從網絡語言轉向自然語言
标簽的概念可能看起來很小，卻值得強調。使用标簽（即自然語言）來定義安全政策，與數十年來使用網絡語言（IP、VLAN、端口等）定義安全政策相比，是一個重大變化。至少表現在兩個方面：一是自然語言更加容易了解，便于跨越安全、網絡、應用團隊之間的交流；二是自然語言更加穩定，與網絡基礎設施無關，即使工作負載跨越網絡結構發生遷移，安全政策也無需改變。
04
應用程式的五級可見性
1）第1級可見性：全局視圖
首先，登入到政策計算引擎（PCE）web控制台。在這裡，有一個Illumination應用程式，它可以生成實時高保真的應用程式依賴關系圖。它可以顯示，我的應用系統如何分布在不同的位置。如下圖所示：
圖5-應用程式分組（全局視圖）
圖中可見，我有一個CA（美國加州，California）資料中心（圖中左上角最大的圓圈），其中包含9個分組和48個工作負載。另外，我在雲上還有不同的執行個體，比如AWS和Azure（圖中另外兩個圓圈）。這是一個高層級的視圖。
2）第2級可見性：單個資料中心
當我點選加州（CA）資料中心後，就好像掀開了它的屋頂，看到資料中心裡面的各個應用程式。如下圖所示：
圖6-加州（CA）資料中心的内部（含應用程式分組）
可見，加州資料中心有9個不同的應用程式分組在運作。但注意，大圓圈中9個分組中的數字，并不是分組編号，而是該分組中的工作負載數量。如果把所有數字加在一起，正好是48個工作負載（與圖5中的工作負載數量是一緻的）。需要注意的是，訂單應用程式（Ordering）被分成了兩個，即在開發環境中的訂單應用程式和在生産環境中的訂單應用程式（筆者用兩個紅圈做了标記）。這正是四維标簽發揮的作用。
另外，上圖中那條帶箭頭的直線，表示有流量從生産環境中的訂單應用程式，流向PCI環境中的銷售點（point of sale）應用程式。
3）第3級可見性：單個應用程式
但我可以更進一步，看看加州資料中心生産環境中的訂單應用程式，即Ordering|Production|CA（即上圖的中間數字為9的應用程式分組）。點選這個分組後，會看到該分組的内部情況，如下圖所示：
圖7-一個應用程式的内部（含工作負載）
可見，它由9個不同系統組成，它們可能是裸金屬、VM、容器。而它們具體是什麼形态，卻無關緊要。這就是Illumio一直在強調的網絡無關性（即可以不考慮網絡基礎設施的具體形态）。
我們還可以看到主機和主機之間存在依賴關系：紅線表示我們檢測到了流量，但缺少一個允許這種流量發生的政策；綠線表示我們檢測到了流量，并且已經制定了政策來規範這些流量。當我們分别點選紅線和綠線時，如下圖所示：
圖8-點選紅線時顯示的資訊
上圖浮現的資訊表明：這條紅線流量是從ipList到ordering-lb1（訂單程式-負載平衡1号主機），使用了TCP協定443端口。
圖9-點選綠線時顯示的資訊
上圖浮現的資訊表明：這條綠線流量是從ordering-web3（訂單程式-web層3号主機）到ordering-processing1（訂單程式-處理層1号主機），使用了TCP協定8070端口。
4）第4級可見性：單個主機（工作負載）
更進一步，我們還可以提供主機級的洞察，例如在每台機器上運作或打開的各個端口和程序。
圖10-檢視單個主機
當點選編号①處的主機時，會浮現出資訊：工作負載（OS Workload）的名稱是訂單程式web層1号（ordering-web1）；角色（Role）是Web；政策狀态（Policy State）為建構（Build）狀态（後面會講到這個）。
而且，左上角還同步顯示了該主機的相關資訊。比如在編号②處，顯示了該主機上運作的3個服務程序以及相關的協定和端口号。
進一步，我們還可以點選編号③處的ordering-web1，進入到主機内部，檢視更多資訊。如下圖所示：
圖11-檢視主機内部的更多資訊
在紅圈處可見，包括摘要（Summary）、程序（Processes）、規則（Rules）、阻塞流量（Blocked Traffic）、漏洞（Vulnerabilities）等菜單資訊。其中，摘要菜單中顯示了主機運作的作業系統等資訊。規則菜單中可以看到政策計算引擎（PCE）翻譯并發送到VEN以程式設計到該主機iptable中的各個規則，如入站和出站的3層/4層狀态防火牆的規則。這些提供了很好的洞察能力。
5）第5級可見性：跨多個資料中心的單個應用程式
前面的應用程式它隻位于一個（地理）位置，即加州資料中心。現在，我們回頭看看混合部署的Settlements（結算）應用程式，它不僅位于加州資料中心，而且還運作了Amazon中的一個執行個體。如下圖所示：
圖12-跨資料中心混合部署的應用程式
圖中還可以看到，在兩個資料中心的資料庫層之間存在活躍通信（即圖中兩個藍色大圓圈之間的4條紅線）。
雖然這看起來不錯，但還不夠好。我們希望不考慮地理位置，将上圖中相同應用程式的14個工作負載，合并到同一個分組中，這就是應用程式分組地圖（application group map）視圖，可以通過菜單App Group Map打開。如下圖所示：
圖13-應用程式分組地圖
事實上，很多應用程式所有者都是這樣看待他們的應用程式的，他們不一定在乎它的具體位置。
05
自然語言安全政策設定
通常，編寫安全政策是相當複雜的，或者需要很長時間才能正确處理政策。但是政策計算引擎（PCE）中内置了很多工作流（workflow），使得安全政策的編寫工作變得輕松。特别是政策生成器，大大簡化了微分段政策的編寫過程。
1）通過政策生成器編寫安全政策
繼續從上面的應用程式開始，如下圖所示：
圖14-準備設定安全政策
由于圖中所有線條都是紅色，說明還沒有為這個應用程式編寫任何政策。我們将使用政策生成器來編寫安全政策。政策生成器會觀察在應用程式内部或穿越應用程式的所有流量。然後，我就可以獲得基于這些流量而自動化生成的政策。我們單擊上圖中的政策生成器，将出現如下界面：
圖15-政策生成器的界面
其中，編号①處表明，目前規則覆寫率為0%；編号②處表明，規則編寫分為三個步驟：1）選擇應用程式分組；2）配置規則；3）預覽規則。
2）第1級安全政策：應用程式組級别
政策生成器支援不同粒度的政策層級：1）應用程式組級别（App Group Level）；2）應用程式角色級别（Role Level - All Services ）；3）應用程式服務級别（Role Level - Specified Services ）；4）自動級别（Auto Level）。如下圖所示：
圖16-安全政策的不同級别
一般而言，大多數客戶會将應用程式組級别（App Group Level）作為起點。也就是在上圖中勾選App Group Level選項。這意味着将在Settlements應用程式周圍設定一個微邊界。勾選好配置後，進入下一頁"預覽規則"，如下圖所示：
圖17-安全政策的規則預覽
可見，勾選App Group Level選項後，會自動化生成一條新的規則/政策，即：在該應用程式内部，允許所有工作負載與所有工作負載進行對話。
我們可以儲存這條政策，然後傳回到應用程式地圖，就可以在地圖上得到政策更新的實時确認。如下圖所示：
圖18-安全政策的實時更新
将該圖與圖14（準備設定安全政策）對比可知，該圖中的内部連線已經全都由紅色變成綠色。安全政策的覆寫由0%變成了100%。
3）第2級安全政策：應用程式角色級别
當然，為了設定更加安全的政策，我們可以在圖16（安全政策的不同級别）中勾選應用程式角色級别（Role Level - All Services）的自動化安全政策。這會自動設定一個層到層的政策（角色級别也就是層級别），即：Web層可以與處理層對話，而處理層可以與資料庫層對話，但是不允許Web層直接與資料庫層對話。當這樣設定後，我們進一步減少了攻擊面。
4）第3級安全政策：應用程式服務級别
我們還能更進一步，在圖16（安全政策的不同級别）中選擇應用程式服務級别（Role Level - Specified Services ）的安全政策。比如将政策設定為：Web層可以與處理層對話，但隻能在OpenERP端口上，而我的資料庫之間隻能通過postgres互相通信。
點評：不論你選擇哪種級别的安全政策，基本上隻需要在政策生成器上做選擇題就可以了。政策生成器将在幾分鐘内自動生成一緻的微分段政策。而且，微分段政策是自然語言，任何應用程式團隊都可以閱讀和了解。
06
安全政策的測試驗證
1）建構（build）模式
經過上面的步驟，我們已經做好了安全政策的配置。為了避免安全政策的變更對應用程式帶來未預料的影響，我們需要對安全政策進行測試和驗證。這涉及到政策狀态（Policy State）的調整，如下圖所示：
圖19-政策狀态的調整
圖中可見，有三種政策狀态：1）建構（build）模式；2）測試（test）模式；3）強制（enforce）模式。下面将分别介紹。
首先，要從建構（build）模式開始。這意味着，雖然我們将配置好的政策覆寫在地圖上，但是我們仍然允許所有的流量通信發生，而不管你的政策是否真地允許。也就是說，在建構（build）模式下，政策并不會真正阻塞流量。
2）測試（test）模式
一旦你覺得你已經有了正确的政策，你就可以更進一步，進入測試（test）模式。測試模式的作用，是将政策向下配置設定到每個單獨的主機，但它會插入一條額外的政策行“允許any到any登入警報（permit any-any log-in alert）”。是以，在測試模式下，還是不會阻塞流量。
但是，如果流量應該被政策阻塞的話，則會記錄這個資訊并實時發送到政策計算引擎（PCE）。當然也可以把這個資訊發送給你的SIEM工具，比如Splunk、QRadar。
比如，我可以點選圖中的處理型（processing）工作負載，以檢視本應該被阻塞的流量。如下圖所示：
圖20-檢視本應該被阻塞的流量
實踐表明，許多客戶都會在這種測試模式下呆上一個月或者一兩個季度，這樣他們就可以充分地測試和驗證安全政策變更的正确性。
3）強制（enforce）模式
一旦客戶對上述測試模式感到滿意後，他們将進入強制（enforce）模式，這會删除所有any到any規則，并強制執行嚴格的白名單政策模型。
上面就是進行微分段時你應該遵循的旅程，這樣您就可以在不破壞業務運作的情況下安全地保護應用程式。