打造零信任全網防火牆　四步驟部署NSX微分段

2021-04-21

饒康立

本文將討論這幾年在規劃NSX微分段方案部署時的方法論，以及相關的使用工具，VMware的經銷商及專業服務部門面對眾多客戶時，都是透過這個四個步驟成功地推動微分段方案上線，以下將進行詳細地說明。

有聽過或用過VMware NSX的各位同好，肯定會知道NSX Data Center的核心功能之一：微分段。微分段的功能在台灣推廣數年，受到VMware客戶的廣大喜愛，也已經運作在許多中大型企業的生產環境內。在這幾年的部署經驗裡，通常實務使用上問題都不在技術面，因為微分段是非常高可用性且穩定的功能。但真正常碰到的問題，尤其是在企業要實際部署微分段到現有生產環境（Brownfield）時，必須要考慮的是：怎麼知道現在環境內的重要業務網路流有哪些？如何能在設定微分段安全規則時，不會去阻擋到正確的網路流，而導致影響業務正常運作呢？

這當然是VMware的專案服務團隊，或是合作經銷商顧問，必須要能夠協助客戶解決的實際問題。

本文想與大家討論這幾年在規劃NSX微分段方案部署時的方法論，以及相關的使用工具，VMware的經銷商及專業服務部門在眾多客戶都是採用這個方法成功地推動微分段方案上線，接下來進行細部的分享。

如圖1所示，當NSX微分段方案要在企業生產環境進行部署前，服務團隊會依據下列的步驟逐步規劃，以下將一個個步驟進行說明：

步驟一：確認業務範圍與構件分類

此步驟內通常需要進行1～2週的Workshop，由VMware專業服務團隊或是合作的經銷商顧問，與客戶的業務團隊進行數次訪談。訪談要達成的內容包含：

‧定義生產環境內有哪些業務應用要納入保護範圍。

‧在各業務應用內，確認含括的虛機∕容器，以及裡面的各個構件分類，比如說哪些虛機是Web-Server、哪些機器是資料庫等等。

‧請此業務應用的負責人提供此應用與其他應用間，以及此應用內部各構件間的防護規則。

圖2是一個網路上常見、簡易的購物網站方案構件範例，這些構件可能是在同一個或不同的虛機、容器上。在Workshop內，應該要至少可以知道這個應用內包含哪些主要構件（對應到安全群組），每個構件是位於哪些虛機或容器，以及各個虛機∕容器間的連線機制。

在理想狀況下，在這個階段應該就可以定義出應用裡面有哪些構件（群組），以及構件間的服務（要開放的防火牆規則）。但實務與不同的專案經驗上，由於各種原因，很多客戶無法在訪談時就提供相關的資訊。通常可能會是下列幾種原因：

‧應用老舊，當時的文件不齊全。

‧應用老舊，開發團隊已經解散，現有的應用負責人員也不清楚構件間的連接關係。

‧客戶本身政治問題：客戶內部團隊不對盤，專案Workshop不易請到應用負責人員提供資訊。

此時，一些能夠進行實際網路流查詢與稽核的工具配合就很重要，而且在過程中，應該極力避免現有業務發生中斷造成影響。因此，接下來就進入步驟二，利用工具來確認防火牆群組與實際規則。

步驟二：透過訪談或工具確認防火牆群組及規則

在步驟一，與客戶進行訪談，而步驟二，則需要以實際的工具安裝在客戶的實際生產環境內，進行建議1～2週，甚至更長時間的資料收集。大致上的流程包括：

‧工具的安裝，這邊的可用方案包含vRealize Network Insight（vRNI），或是NSX Enterprise Plus版本內所包含的NSX Intelligence方案。如果目前因為各種限制仍在使用NSX for vSphere，Application Rule Manager也是同樣可使用的工具。

‧在實際生產環境內進行業務網路流收集，持續至少1～2週。

‧依據工具觀察結果，並與應用Team回覆討論，進行應用群組間的規則定義與確認，並據以產出修正後的防火牆規則。

Network Insight或是NSX Intelligence將會在後續文章進一步說明。但無論使用哪個工具，此步驟內業務應用實際發生的網路流會被記錄，管理者可透過工具實際檢視真實的業務構件連接關係。此步驟建議要持續一段時間，包含主要業務運作的不同歷程。例如，1～2週時間看起來很長，但或許並沒有包含到備份作業的時間點，那這邊就需要與客戶團隊進行實際的討論。

當工具資料收集結束後，專案團隊應該拿相關的結果與應用Team進行第二次討論，確認各個觀察到的網路流是否與應用團隊的認知與文件相同。此時，就可產出第一版經雙方同意的防火牆規則，這個規則包含了：

‧此業務內的構件分類，並定義出不同的群組（Group）。

‧由工具觀察結果，確認群組間的防火牆規則定義。

圖3是採用vRealize Network Insight工具的圖示範例，可以針對選定的業務系統，看到構件間的網路流關係，並將各個網路流展開以確認細部相關資訊。

步驟三：配置規則，不進行阻擋，以防火牆Log檢視規則完整性

在步驟二中，已可基於工具和Workshop討論，產出第一版防火牆規則。但此時仍會擔心，是否會有漏網之魚，造成某些合法的應用行為被阻擋。因此，接下來的步驟是要實際將防火牆規則部署上去，但「暫時不進行阻擋（Deny/Reject）的行為」，透過防火牆日誌持續觀察一段時間，確認規則的完整性。本步驟內包含：

‧實際進行NSX微分段方案部署及防火牆規則配置。

‧與各業務應用相關的最後一條規則設定為Permit Any，但不進行阻擋，但此規則需要記錄日誌（Log），若有符合則送往後端的日誌稽核系統紀錄（如Log Insight）。

‧由日誌稽核系統，觀察數天各應用的「最後一條Permit Any規則」，若有出現在日誌內，代表此應用前面相關的防火牆規則有遺漏。

‧各業務找到的遺漏防火牆規則，再次與應用Team進行規則討論與確認，並據以修正。

雖然前面步驟二透過工具收集應用的網路流，但仍有可能遺漏。可能的原因包含觀察的時間不夠長，或是工具本身準確度、Sampling遺漏小流量等狀況。透過第三個步驟，可以在不影響應用運作的狀況下，對於防火牆規則進行覆核。圖4所示是透過Log Insight進行防火牆日誌檢視的演示畫面，可以觀察到有被記錄的網路流資訊，並據以進行需求的規則修正。

步驟四：啟用防火牆阻擋規則，持續觀察與修正

經過前面的三步驟，包含一開始的資料檢視、不同工具的使用、日誌檢查，以及數次與業務應用團隊的訪談與檢討，此時部署的防火牆政策應該已經正確度大增了，雙方應該都有信心此時可以正式啟用阻擋規則。

在此步驟中，將各應用最後的預設規則由允許改為拒絕。但當然這裡應該要持續進行應用以及防火牆日誌的觀察與修正，以確認雖然透過微分段、白名單的機制對業務系統進行完善的防護，但同時不會對正常的業務運作造成影響。

但不要忘記，當後續業務有異動，例如換版等作業時，也應該再就前面的步驟在測試環境內重新進行防火牆規則的確認，並據以更新。此外，上面的流程是針對一個業務系統。客戶的環境當然同時有多個業務系統在運作，因此以上的配置當然可以多個業務平行進行。

這裡抓幾張實際的NSX-T/vRealize Log Insight圖給大家看。圖5是針對展示的應用系統之對應防火牆規則，其中包含：

‧允許任何來源到CRM此應用系統的ping流量（規則ID 6123）

‧允許任何來源到CRM系統Web群組的HTTP流量（規則ID 6120）

‧允許CRM系統Web群組到AP群組的TCP-8443 Port流量（規則ID 6122）

‧允許CRM系統AP群組到DB群組的MySQL流量（規則ID 6121）

‧對應此業務系統的預設規則設為Reject（規則6124）

圖5內的Default Rule 6124號，就是在前篇步驟三內說明應先開啟成為Permit進行一段時間觀察，修正防火牆規則後，於步驟四內正式改為Reject or Deny進行白名單防護的應用預設規則。在這條規則中，應配置將Log機制打開，同時也可以加上一個Log Label（圖6內的CRM-DEFAULT-REJECT），以易於進行後續的搜尋。