2018年9月18日 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的分割能力, 使其成為一個完整的服務網格。你可以在這裡閱讀關於這一宣告的更多資訊https://www.hashicorp.com/blog/consul-1-2-service-mesh, 瞭解更多關於Consul的資訊在這裡https://www.consul.io/.