隨著“云原生”成為新一代云計算技術的內核，業界對其關注點正在迅速從“概念”轉向“落地實踐”。在諸多云安全技術中，微隔離被視為云原生安全的一項必備“基礎能力”。那么，在云原生環境中微隔離技術又該如何落地呢？

下面我們將以國內某大型股份制銀行（下簡稱“S行”）的真實案例，獨家揭秘云原生環境下實施微隔離的技術實踐。

容器平臺投產，微隔離需求凸顯

2018年，隨著銀行業務進入場景金融的新階段，金融服務應用亟需被更為敏捷的承載和交付。作為金融科技創新的先行者，S行率先開始了對云原生技術的探索嘗試，并于2020年上線了服務全行業務的云原生體系平臺。當前，S行正通過老業務“應轉盡轉”、新應用100%原生化的技術戰略，加速云原生技術應用。

云安全是S行進行云原生能力建設的重要組成部分，其針對云原生設計了覆蓋基礎設施、計算環境、應用API、開發過程和業務數據等全環節、全要素的安全架構，并力求實現安全能力組件化、服務化，使其能夠隨業務而生，充分融入設計開發和業務操作的過程當中。

在規模龐大的數據中心內部進行安全域分隔和網絡控制，是銀行業的長期通行做法。隨著數據中心架構幾代演變，S行在歷史上嘗試過多種網絡隔離控制方案，例如從最初的域間防火墻方案、到上云初期的虛擬防火墻方案、再到后來利用SDN技術的服務鏈編排方案等。

數據中心隔離與控制方案演進

當然，隨著容器平臺的投產，上述方案幾乎徹底失效。究其原因，首當其沖的便是容器網絡中的IP地址已失去其本身的秩序，而基于IP的靜態策略自然不再有效。由此開始，S行正式踏上了微隔離技術的探索之路。

首選原生方案，可行性低落地難

在技術調研初期，S行對于微隔離的考量指標有兩點。首先，自然是安全策略要與IP地址解耦，否則策略無法依靠人工運維。第二，期望云平臺的安全能力能夠通過“云原生化運行”，從而便于將安全能力作為組件或服務的形式提供。

于是，原生于K8S的Network Policy方案自然的成為了第一選擇。

經過初步的實測驗證，盡管Network Policy在操作體驗上差強人意，但方案至少滿足了兩點核心訴求，因此很快進入到規?；脑囘\行階段。而后面的經歷，卻讓S行的網絡管理人員大跌眼鏡，以下引用他們的幾句原話。

“初期測試的時候是在幾個小規模的模擬環境里，作策略也就無需考慮太多。而到了真實環境中，容器規模瞬間放大了幾十倍，連業務開發人員也說不清究竟誰該訪問誰，這時微隔離策略要怎么做真就沒人能說清了……”，網絡人員抱怨的是開源Network Policy未提供諸如連接可視化等任何的策略輔助設計能力。

“在沒有輔助的情況下，很難保證策略一次配置正確，但Network Policy的策略恰恰是即時生效的，這意味著搞不好就是一次業務中斷，而回退或修改策略時又要重新編寫yaml文件，業務部門是不可能給我們機會一次次試錯的……”。

編寫yaml文件下發安全策略

從此刻起，S行的網絡管理人員才開始意識到，當微隔離的管理規模達到一定程度，原本“體驗”層面的問題就會變成關乎“落地成敗”的關鍵因素。

可行性評估，除了“有用”還要“可用”

初探微隔離所“踩的坑”，使S行開始理解東西向訪問控制與過去管理防火墻的不同，與其說微隔離是一種訪問控制技術，還不如說它是一套策略管理體系，覆蓋策略從設計、到定義、再到運維的全流程。

因此，S行的網絡管理人員很快便將目光投向了專業的微隔離產品。相較開源方案，專業微隔離產品的設計更加貼合客戶運維管理的實際，提供了諸如連接可視化分析、策略仿真模式、策略批量生成、策略審閱發布等完整的策略管理框架。

不得不說，市場上有過大規模微隔離交付案例的廠商并不多，所以S行很快就選定了我們進行測試。

測試初期，對微隔離產品的環境適應性考察是必不可少的，比如對容器平臺的支持、跨平臺的統一納管、虛擬機和容器的同臺管理等，當然這些基礎能力測試均順利通過。然而，作為一個將來要部署進銀行核心網的產品，還必須要經過幾輪嚴酷的“大考”，S行內部稱之為“非功能驗證”。

首先，產品要在極為嚴苛、甚至極端的環境中驗證可靠性。例如，在大規模策略執行和高連接速率的情況下，驗證工作負載的性能衰減是否在可接受范圍。又如，在規模上萬點的K8S集群中，模擬超過一半的容器同時重啟，驗證安全策略是否能及時更新并下發。再如，計算中心集群大范圍宕機時，工作負載是否可被備份集群接管，安全策略是否能依然有效。

其次，產品還需適應并滿足銀行內部的種種運維規范。這大概同樣是金融用戶的習慣做法。例如，針對產品部署安裝、所需的依賴庫、所需分配的系統權限、可能存儲于本地的數據文件等，均會被提出具體的要求，不滿足的則必須進行優化整改。

正如行業內的一句俗話“能服務銀行客戶，就能服務所有客戶”。

五步法落地，策略管理緊密契合業務

經過長達數月的反復驗證和試運行，S行最終選定了我們的方案，并以“五步法”為指引正式開始了微隔離系統的實施。

所謂“五步法”，是指定義、分析、設計、防護和運維5個關鍵步驟，它既是行業公認的零信任理念落地方法，也是我們總結出的一套切實可行的微隔離實施方案。

微隔離實施“五步法”

定義階段，要完成系統的部署和工作負載納管。首先，為了滿足S行超3萬點規模的統一管理需求，我們在計算中心的部署上進行了充分的性能和可用性保障設計，將一個8機計算中心集群拆分部署于同城的兩個雙活數據中心中，并實現了工作負載就近接入、雙集群A/A備份的效果。其次，為了充分發揮云原生的特性，我們并未選擇基于Agent的“輕代理”方式，而是采用了基于DaemonSet的“無代理”模式部署，通過自動化的守護容器部署，省去了在各節點安裝Agent的繁冗，也實現了S行力求的“原生化部署運行”。

S行云原生環境微隔離解決方案示意圖

分析階段，要對工作負載進行分組和標簽化管理，為安全策略與IP解耦打下基礎。很多用戶認為“分組打標簽”就會引發新的工作量，而在云原生環境中，容器自身的標簽體系是可以被復用的。在S行的實施中，我們便是通過容器Namespace的名稱作為分組，并利用app label的鍵值作為各容器角色標識的。

設計階段，本質上是要回答安全策略怎么做的問題，所以需要梳理出東西向訪問的基線。對于像S行這種管理水平較高的用戶，業務容器上線時業務開發部門就需要提交應用的訪問需求，這些信息可以從CMDB系統中直接獲得。除此之外，在過去云平臺中的防火墻、安全組中，可能運行著一些訪問控制策略，這些策略經過分析選擇，也可以通過工具自動化的導入微隔離系統。當然，對于仍未覆蓋的少部分策略，我們可以利用連接可視化分析能力，與業務部門逐條確認。

防護階段，安全策略需要下發并執行。微隔離策略的下發并非“一蹴而就”，而是要經過一定時間的效果仿真和試運行，因此專業微隔離系統通常具有多種策略生效模式，例如“僅定義不下發”的建設模式、“僅下發不阻斷”的測試模式或“完全執行”的防護模式。S行的業務容器投產前會先后運行于開發、測試、投產驗證和生產環境，而微隔離能力是在最初的開發環境便開始生效的，在開發和測試環境策略僅工作于建設模式，在投產驗證環境策略工作于測試模式，而在真正進入生產環境時，策略已完成了充分的仿真驗證并正式切換為防護模式。

至此，微隔離實施的主要工作已基本完成，系統將進入運維階段。目前，S行正在積極嘗試將微隔離系統與ITSM、SOC等外部系統打通，實現智能化的策略變更和優化。

基于以上技術實踐，我們給正在進行微隔離規劃的用戶一些建議：

1. 微隔離技術的內涵并非單純的訪問控制，而是通過一整套策略管理體系框架，實現東西向流量的精細管理，因此微隔離系統的策略管理能力應被重點考量；

2. 云原生環境的工作負載規模指數級放大，給微隔離系統帶來多重挑戰，用戶在實施微隔離初期便應充分預見未來的擴容需求、可用性要求和運維規范的遵從；

3. 微隔離通過標簽實現策略與IP解耦，其使用了更為有效和高效的控制邏輯。通過制定合理的安全目標，探究與既有運維流程的結合方式，即可使微隔離加速落地。

業界首發，薔薇靈動發布《云原生環境微隔離解決方案白皮書》感興趣：云原生環境微隔離解決方案_微隔離-薔薇靈動就是自適應微隔離.微隔離技術標準定義者-薔薇靈動 (dynarose.com)