讀零信任網路：在不可信網路中構建安全系統18零信任代理

躺柒發表於2024-08-14

1. 零信任代理

1.1. 零信任代理是應用級代理伺服器，用來保護零信任網路，它是處理認證、授權以及加密的基礎設施

1.2. 零信任代理分為反向代理和前向代理兩種工作模式

  • 1.2.1. 執行時可以同時採用這兩種工作模式，也可以只採用其中的一種

  • 1.2.2. 在反向代理工作模式下，代理接收來自零信任客戶端的連線請求，並接收初始連線，校驗此連線是否應該被授權，授權透過後，把客戶端請求傳遞給後端的應用系統處理

  • 1.2.3. 在前向代理工作模式下，非零信任感知的元件需要向另一個零信任系統發出網路請求

  • 1.2.3.1. 因為非零信任感知的元件不能和零信任控制平面互動，所以不能正確地初始化該請求，只能透過認證代理完成請求的初始化

1.3. 利用代理構建零信任網路時，代理應該以嵌入式的方式部署在執行工作負載的裝置上

  • 1.3.1. 以這種方式構建零信任網路，所有工作負載的網路通訊流量在進入網路之前都會被強制引流到代理上

1.4. 最好不要把零信任代理部署在一臺單獨的外部裝置上

  • 1.4.1. 把零信任職責交由外部裝置代理的做法違背了零信任模型聲稱的保證所有流量安全的目標

  • 1.4.2. 這種做法不能保證代理/負載均衡器和後端服務之間的流量安全

1.5. 如果系統管理員對於網路中的裝置和服務沒有完全的控制權，那麼構建零信任網路就會變得非常困難

1.6. 在不可修改的元件和零信任網路之間部署零信任代理，就可以讓該元件參與到零信任網路中來，儘管不能保證足夠高的安全性

1.7. 將非零信任感知的元件完全隔離非常重要，而且這種隔離必須保證流入和流出該元件的網路流量都只能經過認證代理

  • 1.7.1. 如果可能，代理最好採用串聯部署而非旁路部署模式

2. 客戶端與服務端遷移

2.1. 通常首先是從客戶端—伺服器之間的互動著手實現零信任模型

  • 2.1.1. 客戶端一般是指移動裝置或者源自非受控網路的訪問服務

  • 2.1.2. 零信任架構的自動化系統需要相容多種客戶端作業系統

  • 2.1.3. 不是每個客戶端裝置都能安裝現有的自動化系統

  • 2.1.4. 在客戶端—伺服器層面構建零信任將會面臨很多挑戰

2.2. 從伺服器—伺服器之間的互動著手構建零信任網路相對來說更容易一些

  • 2.2.1. 伺服器通常都已經安裝了自動化工具

  • 2.2.2. 伺服器供應商的數量相對較少，對系統自動化工具的相容性要求也更低

  • 2.2.3. 從安全形度考慮也應當儘快著手實現伺服器之間的零信任

  • 2.2.3.1. 伺服器通常是那些儲存敏感資料的系統，所以它們也是攻擊者的攻擊目標

2.3. 網路安全較薄弱的環節恰恰是構建零信任網路的著手點

2.4. 使用威脅建模方法可以預測攻擊者會在組織的哪些脆弱點進行攻擊、如何攻擊，然後依此決定在哪裡投入資源和時間研究以實現零信任

3. PagerDuty的雲無關網路

3.1. PagerDuty系統的日常運營重度依賴廣域網（WAN）通訊

  • 3.1.1. 網際網路的網路環境相對比較惡劣，可能會出現意外的高延遲和資料包丟失等狀況

  • 3.1.2. 廣域網的通訊需要採用認證和加密機制以保證資料的隱私和完整性

3.2. 部署無邊界的零信任網路成為理想的解決方案，零信任網路叢集中的每個節點都僅僅負責它自己的通訊，可以實現故障的隔離

3.3. 配置管理系統作為自動化平臺

  • 3.3.1. Chef系統

  • 3.3.1.1. Chef已經被用來配置系統中的虛擬機器，因此它是一個理想的、隨時可用的自動化系統，可以利用它來構建零信任網路

  • 3.3.2. 好處

  • 3.3.2.1. 網路計算資源能夠隨著例項數量的增減而自動伸縮，隨著網路的擴充套件，這種伸縮效能夠降低購買更大的共享硬體伺服器的需求

  • 3.3.2.2. 更好地隔離故障

>  3.3.2.2.1. 該方案事實上是採用大量“微型防火牆”代替了傳統的完整防火牆

>  3.3.2.2.2. 即使微型防火牆失效，也只是影響很小範圍的網路流量

  • 3.3.3. 貫穿整個網路設計的分散式策略的缺點

  • 3.3.3.1. 需要持續校驗預期策略的狀態，以確保所有節點正確地執行預期策略

  • 3.3.3.2. 策略變更會逐步作用到整個叢集

  • 3.3.4. 選擇合適的配置管理工具作為著手點，能夠快速實現零信任網路的理念落地，但是配置管理工具並不是理想的長期解決方案

  • 3.3.5. 隨著零信任網路的成熟度不斷提高，管理員應該儘快擺脫對Chef系統的依賴，實現自己的自動化平臺，以獲得最佳效能，為目標進行部署並持續迭代調優

  • 3.3.5.1. 隨著網路規模的擴大，系統的配置不再依賴Chef，而是由一個專用服務負責

3.4. 動態配置本地防火牆

  • 3.4.1. Chef系統需要基於現有的系統知識生成IPtable配置

  • 3.4.2. 每個主機都需要構建IPtable連結串列，列舉特定角色的伺服器的IP地址，然後就可以使用這些連結串列來定義基於角色的訪問控制規則

3.5. 分散式流量加密

  • 3.5.1. PagerDuty實現了一個基於IPSec主機—主機模式的網狀網路

  • 3.5.1.1. 所有資料包都經過系統中每個節點的加密和認證

  • 3.5.1.2. 因為認證和加密是在系統中分散式部署的，所以這些關鍵功能會隨著主機數量的增加而增長

  • 3.5.2. 3個問題

  • 3.5.2.1. 不是每個應用都能正確實施加密規範

  • 3.5.2.2. 缺乏響應安全漏洞的配置控制手段

  • 3.5.2.3. 導致系統效能降低

  • 3.5.3. 為了保證安全能力的一致性，系統管理員應當把TLS基礎設施從應用系統中剝離出來

  • 3.5.4. 隨著系統中應用程式的數量不斷增加，越來越多的系統傾向於利用過程外（Out-Of-Process）加密機制來保證網路通訊安全

  • 3.5.5. IPSec通訊通常採用ESP資料包傳輸，但是有些雲服務提供商不能路由ESP資料包，所以需要使用UDP資料包封裝所有IPSec流量

  • 3.5.5.1. 優點是可以有效處理隨著主機數量增加而不斷增長的業務吞吐量

  • 3.5.5.2. 缺點：初次上線執行時，IPSec通訊雙方的狀態不一致經常會導致通訊的失敗，而這類問題對於網路的生產運營至關重要

  • 3.5.6. 分散式流量加密也採取了漸進式部署模式

  • 3.5.6.1. 以空操作（No-Op）的方式在系統叢集中部署IPSec策略，這些策略用於控制網路流量是否應該使用IPSec通訊

  • 3.5.6.2. 不使用（None）​：不使用IPSec通訊

  • 3.5.6.3. 使用（Use）​：如果通訊雙方可以透過協商調整關係引數，那麼最好使用IPSec

  • 3.5.6.4. 必須（Required）​：必須使用IPSec通訊

  • 3.5.6.5. 在實際應用中，不能直接把整個網路同時配置成“使用”狀態，而是先將一小部分網路遷移到“使用”狀態，然後再將它們重新配置成“必須使用”狀態

3.6. 使用者管理的去中心化

  • 3.6.1. PagerDuty的使用者訪問控制也是集中式部署的，但是其使用者管理沒有依賴中心化的LDAP系統，而是由網路中的每個主機構建本地使用者和群組

  • 3.6.2. 系統根據LDAP伺服器和其他相關資料庫中的資訊，集中完成使用者和群組的定義

3.7. 部署上線

  • 3.7.1. 步驟

  • 3.7.1.1. 定義新策略

  • 3.7.1.2. 在不影響生產系統的情況下部署策略，同時收集有用的測量指標和日誌

  • 3.7.1.3. 長期收集監測測量指標或日誌，確保整個系統執行在期望狀態下

  • 3.7.1.4. 策略逐漸覆蓋整個系統叢集，從只覆蓋系統的一部分直到百分之百完全覆蓋

3.8. 供應商無關係統的價值

  • 3.8.1. 構建與供應商無關的系統需要巨大的工程投入

  • 3.8.2. 供應商無關網路將顯著減少供應商移除過程所花費的時間，並且降低了風險

  • 3.8.3. 調研新供應商

  • 3.8.4. 試新供應商的系統

  • 3.8.5. 使用Chef自動化系統重新配置

  • 3.8.6. 真正對生產系統部署變更的時間只需要1周，並且不會對客戶造成任何影響

相關文章