【譯】現代環境下的網絡分割

NIC JACKSON

網絡分割是限制網絡入侵影響的一種高效策略。可是, 在諸如羣集調度程序這樣的現代環境中, 應用程序一般會在沒有操做員干預的狀況下啓動和從新啓動。這種動態資源調配會致使不斷變化的 IP 地址和應用程序入口端口。使用傳統的防火牆和路由方法對這些動態環境進行細分能夠在技術上具備挑戰性。

在這篇文章中, 咱們將研究這種複雜性以及服務網格是如何成爲現代動態環境中安全網絡通訊的潛在解決方案的。

動態環境

咱們先來定義一下動態環境的含義。最簡單的狀況是, 動態環境是應用程序和基礎結構常常發生更改的環境, 要麼是經過手動個更改常規部署和基礎結構，要麼就是在沒有操做員干預的狀況下觸發大小自動調整或實例自動替換。像 HashiCorp Consul或 Kubernetes 這樣的調度程序展現了這種行爲, 就像許多雲提供商提供平衡自動縮放組的自動冗餘功能。可是, 這種效果不只限於雲環境, 任何平臺 (如 vSphere 配置在高可用模式下) 也能夠歸類爲動態環境。

網絡分割

咱們還須要澄清爲何網絡分割對網絡安全有很高的價值。傳統的網絡分割主要是使用外圍防火牆實現的。此方法的問題在於受信任區域是平坦的。它只須要一次入侵就能得到對網絡的普遍訪問, 而網絡越大, 入侵檢測的機會就越有限。

隨着細粒度網絡分割, 網絡被分紅許多較小的網絡, 爲的是在發生入侵的時候能減小爆炸半徑,。此方法涉及開發並執行某規則集, 以控制特定主機和服務之間的通訊。

每一個主機和網絡應該被分割和隔離在最低的水平, 這個是能夠實際實現的。路由器或3層交換機使用諸如虛擬 LAN (VLAN) 或訪問控制列表 (acl) 等措施將網絡劃分爲不一樣的較小網絡。網絡防火牆則是爲了過濾各小塊網絡之間的網絡通訊, 而基於主機的防火牆則主要負責過濾來自本地網絡的通訊來添加額外的安全性。

若是您在基於雲的環境中運行, 則經過使用虛擬私有云 (VPC) 和安全組來實現網絡細分。雖然交換機是虛擬化的, 但將入口規則和 acl 配置爲分段網絡的方法主要與物理基礎結構相同。

服務細分

在網絡細分涉及保護區域間的通訊時, 服務分割確保同一區域中服務之間的通訊安全。服務細分是一種更細化的方法, 尤爲與多multi-tenanted環境 (例如, 在單個節點上運行多個應用程序的調度程序) 相關。

實現服務細分取決於您的操做環境和應用程序基礎結構。服務細分一般經過軟件防火牆的配置、軟件定義的網絡 (如應用調度程序使用的覆蓋網絡) 以及最近出現的經過利用服務網格來實現。

與網絡分割同樣, 應用最小特權原則, 只容許在有明確意圖容許此通訊的時候容許服務通訊。

網絡分割與動態環境問題

當咱們試圖在動態環境中實現此方法時, 存在許多問題:

應用程序部署與網絡配置斷開鏈接

當使用自動縮放組部署應用程序並建立新實例時, 一般會動態地從預先配置的塊中分配 IP 地址。這個特定的應用程序不多會被孤立地運行, 須要訪問在同一網絡段中運行的服務, 以及潛在的另外一個網絡段。若是咱們對網絡安全採起了強硬的方法, 那麼這兩段之間就會有嚴格的路由規則, 這兩個部分只容許預約義列表上的通訊。除此以外, 咱們還將在上游服務上配置主機級防火牆, 這將只容許特定的通訊。

在靜態的世界中, 當應用程序部署到已知位置時, 這是更簡單的解決辦法。能夠在部署時更新路由和防火牆規則, 以啓用所需的訪問權限。

在動態的世界中, 存在斷開鏈接的問題, 應用程序獨立部署以配置網絡安全和分配的 IP 地址, 甚至潛在的端口都是動態的。一般有一個手動更新網絡安全規則的過程, 這會減慢部署速度。

在現代調度程序中調度應用程序

網絡分割的目標是在邏輯上劃分網絡, 以減小爆炸半徑。極限來講, 每一個網絡段只包含一對須要通訊的服務。這就造成了服務細分的概念, 在這裏咱們管理對服務層的訪問。隨着服務級別的細分, 咱們關注服務之間的交互, 而無論它們在網絡上的位置。若是您在像 Kubernetes 或Consul這樣的調度程序上運行應用程序, 利用覆蓋網絡是配置服務細分的經常使用方法。配置疊加比管理多個網絡路由和防火牆規則要簡單得多, 由於在應用程序位置發生變化時, 疊加一般會自動從新配置。咱們須要考慮調度程序一般是更重要的基礎結構部署的一部分。

在這種狀況下, 咱們還須要考慮調度程序內部的應用程序如何與其餘網絡服務通訊。例如, 您有一個100節點羣集, 一個應用程序實例須要與另外一個網絡段中的服務進行對話。在調度程序中運行的應用程序能夠在100個節點中的任何一個上運行。這使得肯定哪些 IP 應該列入白名單是有挑戰性的。調度程序一般會動態地在節點之間移動應用程序, 這會致使一直產生更新路由和防火牆規則的需求。

現代環境由VMs、容器、無服務器功能、雲數據存儲等組成。這種複雜的基礎結構對管理網絡安全構成了重大挑戰。

爲了防火牆和路由規則配置網絡級安全性, 以及爲了覆蓋網絡配置調度程序級別安全性有助於提升整個系統的安全性。可是, 咱們必須在兩個獨立的區域中管理安全配置。在操做上, 咱們還有兩種大相徑庭的方法來實現所需的配置。這兩個要求大大提升了管理應用程序安全性的系統複雜性和操做開銷。

這種複雜性的一個不幸的反作用多是安全被放鬆了, 網絡分割被簡化爲路由規則的塊, 而不是絕對地址。整個羣集被容許路由, 而不只僅是運行特定應用程序的節點。從服務的角度來看, 對本地網絡段應用太多的信任。從安全的角度來看, 這並非最好的選擇, 由於增長了應用程序的攻擊面, 因此須要一種一致且集中的方法來管理和理解網絡和服務細分。

基於意向安全的服務細分

解決複雜性和提升網絡安全性的方法是, 刪除配置基於位置的安全規則的須要, 並移動到基於意向的模型。基於意向的安全性構建了有關標識而不是位置的規則。例如, 咱們能夠定義一個意向, 說明前端服務須要與付款服務通訊。

經過意圖定義網絡分割能夠緩解傳統網絡分割的複雜性, 並容許更嚴格地控制網絡安全規則。出於意向, 您在應用程序級別描述安全性, 而不是網絡位置級別。

例如, 若是咱們有如下基礎結構:

爲了啓用 "服務 A" 到 "服務 B" 通訊, 咱們須要在兩個段之間建立路由規則。必須建立防火牆規則, 以容許從 "服務 A" 實例進行訪問。

此配置總共有9條規則:

• 9x 服務 A 和服務 B 之間的防火牆規則

考慮當 "服務 A" 實例被替換時的影響, 並記住這不只是因爲失敗, 並且是持續集成。須要再次更新這些規則, 刪除的實例詳細信息將須要被刪除, 並添加新的實例詳細信息。

如今考慮經過基於意向的安全性來控制路由的方法。

此配置將致使單個意圖:

• "服務 A" ➡️ "服務 B",

更改運行實例的比例或位置不會更改該簡單規則。

使用服務網格能夠實現基於意向的安全性。服務網格由一箇中央控制平面組成, 它容許您經過使用意向而不是網絡位置來集中配置網絡和服務細分, 而且數據平面提供路由和服務發現。這兩個組件一塊兒幾乎能夠徹底替換複雜路由和防火牆規則的要求。

使用基於身份的受權, 數據平面只容許由這些意圖定義的服務之間的通訊, 並且因爲意圖是由控制平面集中管理的, 所以單個更新會從新配置整個網絡。

意圖對傳統網絡分割的好處

服務意圖大大簡化了爲服務通訊提供安全服務的方法。不管咱們的應用程序是在虛擬機中運行, 仍是在調度程序上, 或者是雲管理的數據存儲區, 咱們均可以採起集中的方法。

因爲服務網格中的全部通訊都是代理的, 因此網絡路由規則被大大簡化。能夠將通訊流限制爲單個端口的端口, 或很是窄的範圍和主機級防火牆, 只須要將其配置爲容許在已知的代理端口上進行侵入。

在服務網格中, 鏈接經過相互 TLS 進行身份驗證, 所以即便無管理應用程序得到對網絡的訪問權, 若是沒有有效的標識和身份驗證, 它將沒法與在主機上運行的開放代理端口通訊。

最後, 使用單一的集中規則定義服務安全性的概念更簡單, 更易於實現。

咱們認爲, 服務細分是確保數據中心安全的重要步驟, 特別是在現代雲環境中。咱們最近引入了 "Consul Connect", 它增長了對Consul的分割能力, 使其成爲一個完整的服務網格。你能夠在這裏閱讀關於這一聲明的更多信息www.hashicorp.com/blog/consul…, 瞭解更多關於Consul的信息在這裏www.consul.io/.