隨著"云原生"成為新一代云計(jì)算技術(shù)的內(nèi)核，業(yè)界對(duì)其關(guān)注點(diǎn)正在迅速?gòu)?概念"轉(zhuǎn)向"落地實(shí)踐"。在諸多云安全技術(shù)中，微隔離被視為云原生安全的一項(xiàng)必備"基礎(chǔ)能力"。那么，在云原生環(huán)境中微隔離技術(shù)又該如何落地呢？

下面我們將以國(guó)內(nèi)某大型股份制銀行（下簡(jiǎn)稱"S行"）的真實(shí)案例，獨(dú)家揭秘云原生環(huán)境下實(shí)施微隔離的技術(shù)實(shí)踐。

容器平臺(tái)投產(chǎn)，微隔離需求凸顯

2018年，隨著銀行業(yè)務(wù)進(jìn)入場(chǎng)景金融的新階段，金融服務(wù)應(yīng)用亟需被更為敏捷的承載和交付。作為金融科技創(chuàng)新的先行者，S行率先開始了對(duì)云原生技術(shù)的探索嘗試，并于2020年上線了服務(wù)全行業(yè)務(wù)的云原生體系平臺(tái)。當(dāng)前，S行正通過老業(yè)務(wù)"應(yīng)轉(zhuǎn)盡轉(zhuǎn)"、新應(yīng)用100%原生化的技術(shù)戰(zhàn)略，加速云原生技術(shù)應(yīng)用。

云安全是S行進(jìn)行云原生能力建設(shè)的重要組成部分，其針對(duì)云原生設(shè)計(jì)了覆蓋基礎(chǔ)設(shè)施、計(jì)算環(huán)境、應(yīng)用API、開發(fā)過程和業(yè)務(wù)數(shù)據(jù)等全環(huán)節(jié)、全要素的安全架構(gòu)，并力求實(shí)現(xiàn)安全能力組件化、服務(wù)化，使其能夠隨業(yè)務(wù)而生，充分融入設(shè)計(jì)開發(fā)和業(yè)務(wù)操作的過程當(dāng)中。

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

數(shù)據(jù)中心隔離與控制方案演進(jìn)

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

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

在技術(shù)調(diào)研初期，S行對(duì)于微隔離的考量指標(biāo)有兩點(diǎn)。首先，自然是安全策略要與IP地址解耦，否則策略無法依靠人工運(yùn)維。第二，期望云平臺(tái)的安全能力能夠通過"云原生化運(yùn)行"，從而便于將安全能力作為組件或服務(wù)的形式提供。

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

經(jīng)過初步的實(shí)測(cè)驗(yàn)證，盡管Network Policy在操作體驗(yàn)上差強(qiáng)人意，但方案至少滿足了兩點(diǎn)核心訴求，因此很快進(jìn)入到規(guī)?；脑囘\(yùn)行階段。而后面的經(jīng)歷，卻讓S行的網(wǎng)絡(luò)管理人員大跌眼鏡，以下引用他們的幾句原話。

"初期測(cè)試的時(shí)候是在幾個(gè)小規(guī)模的模擬環(huán)境里，作策略也就無需考慮太多。而到了真實(shí)環(huán)境中，容器規(guī)模瞬間放大了幾十倍，連業(yè)務(wù)開發(fā)人員也說不清究竟誰該訪問誰，這時(shí)微隔離策略要怎么做真就沒人能說清了……"，網(wǎng)絡(luò)人員抱怨的是開源Network Policy未提供諸如連接可視化等任何的策略輔助設(shè)計(jì)能力。

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

編寫yaml文件下發(fā)安全策略

從此刻起，S行的網(wǎng)絡(luò)管理人員才開始意識(shí)到，當(dāng)微隔離的管理規(guī)模達(dá)到一定程度，原本"體驗(yàn)"層面的問題就會(huì)變成關(guān)乎"落地成敗"的關(guān)鍵因素。

可行性評(píng)估，除了"有用"還要"可用"

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

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

不得不說，市場(chǎng)上有過大規(guī)模微隔離交付案例的廠商并不多，所以S行很快就選定了我們進(jìn)行測(cè)試。

測(cè)試初期，對(duì)微隔離產(chǎn)品的環(huán)境適應(yīng)性考察是必不可少的，比如對(duì)容器平臺(tái)的支持、跨平臺(tái)的統(tǒng)一納管、虛擬機(jī)和容器的同臺(tái)管理等，當(dāng)然這些基礎(chǔ)能力測(cè)試均順利通過。然而，作為一個(gè)將來要部署進(jìn)銀行核心網(wǎng)的產(chǎn)品，還必須要經(jīng)過幾輪嚴(yán)酷的"大考"，S行內(nèi)部稱之為"非功能驗(yàn)證"。

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

其次，產(chǎn)品還需適應(yīng)并滿足銀行內(nèi)部的種種運(yùn)維規(guī)范。這大概同樣是金融用戶的習(xí)慣做法。例如，針對(duì)產(chǎn)品部署安裝、所需的依賴庫(kù)、所需分配的系統(tǒng)權(quán)限、可能存儲(chǔ)于本地的數(shù)據(jù)文件等，均會(huì)被提出具體的要求，不滿足的則必須進(jìn)行優(yōu)化整改。

正如行業(yè)內(nèi)的一句俗話"能服務(wù)銀行客戶，就能服務(wù)所有客戶"。

五步法落地，策略管理緊密契合業(yè)務(wù)

經(jīng)過長(zhǎng)達(dá)數(shù)月的反復(fù)驗(yàn)證和試運(yùn)行，S行最終選定了我們的方案，并以"五步法"為指引正式開始了微隔離系統(tǒng)的實(shí)施。

所謂"五步法"，是指定義、分析、設(shè)計(jì)、防護(hù)和運(yùn)維5個(gè)關(guān)鍵步驟，它既是行業(yè)公認(rèn)的零信任理念落地方法，也是我們總結(jié)出的一套切實(shí)可行的微隔離實(shí)施方案。

微隔離實(shí)施"五步法"

定義階段，要完成系統(tǒng)的部署和工作負(fù)載納管。首先，為了滿足S行超3萬點(diǎn)規(guī)模的統(tǒng)一管理需求，我們?cè)谟?jì)算中心的部署上進(jìn)行了充分的性能和可用性保障設(shè)計(jì)，將一個(gè)8機(jī)計(jì)算中心集群拆分部署于同城的兩個(gè)雙活數(shù)據(jù)中心中，并實(shí)現(xiàn)了工作負(fù)載就近接入、雙集群A/A備份的效果。其次，為了充分發(fā)揮云原生的特性，我們并未選擇基于Agent的"輕代理"方式，而是采用了基于DaemonSet的"無代理"模式部署，通過自動(dòng)化的守護(hù)容器部署，省去了在各節(jié)點(diǎn)安裝Agent的繁冗，也實(shí)現(xiàn)了S行力求的"原生化部署運(yùn)行"。

S行云原生環(huán)境微隔離解決方案示意圖

分析階段，要對(duì)工作負(fù)載進(jìn)行分組和標(biāo)簽化管理，為安全策略與IP解耦打下基礎(chǔ)。很多用戶認(rèn)為"分組打標(biāo)簽"就會(huì)引發(fā)新的工作量，而在云原生環(huán)境中，容器自身的標(biāo)簽體系是可以被復(fù)用的。在S行的實(shí)施中，我們便是通過容器Namespace的名稱作為分組，并利用app label的鍵值作為各容器角色標(biāo)識(shí)的。

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

防護(hù)階段，安全策略需要下發(fā)并執(zhí)行。微隔離策略的下發(fā)并非"一蹴而就"，而是要經(jīng)過一定時(shí)間的效果仿真和試運(yùn)行，因此專業(yè)微隔離系統(tǒng)通常具有多種策略生效模式，例如"僅定義不下發(fā)"的建設(shè)模式、"僅下發(fā)不阻斷"的測(cè)試模式或"完全執(zhí)行"的防護(hù)模式。S行的業(yè)務(wù)容器投產(chǎn)前會(huì)先后運(yùn)行于開發(fā)、測(cè)試、投產(chǎn)驗(yàn)證和生產(chǎn)環(huán)境，而微隔離能力是在最初的開發(fā)環(huán)境便開始生效的，在開發(fā)和測(cè)試環(huán)境策略僅工作于建設(shè)模式，在投產(chǎn)驗(yàn)證環(huán)境策略工作于測(cè)試模式，而在真正進(jìn)入生產(chǎn)環(huán)境時(shí)，策略已完成了充分的仿真驗(yàn)證并正式切換為防護(hù)模式。

至此，微隔離實(shí)施的主要工作已基本完成，系統(tǒng)將進(jìn)入運(yùn)維階段。目前，S行正在積極嘗試將微隔離系統(tǒng)與ITSM、SOC等外部系統(tǒng)打通，實(shí)現(xiàn)智能化的策略變更和優(yōu)化。

基于以上技術(shù)實(shí)踐，我們給正在進(jìn)行微隔離規(guī)劃的用戶一些建議：

1.微隔離技術(shù)的內(nèi)涵并非單純的訪問控制，而是通過一整套策略管理體系框架，實(shí)現(xiàn)東西向流量的精細(xì)管理，因此微隔離系統(tǒng)的策略管理能力應(yīng)被重點(diǎn)考量；

2.云原生環(huán)境的工作負(fù)載規(guī)模指數(shù)級(jí)放大，給微隔離系統(tǒng)帶來多重挑戰(zhàn)，用戶在實(shí)施微隔離初期便應(yīng)充分預(yù)見未來的擴(kuò)容需求、可用性要求和運(yùn)維規(guī)范的遵從；

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