讀零信任網路：在不可信網路中構建安全系統14流量信任

躺柒發表於2024-08-10

1. 流量信任

1.1. 網路流的驗證和授權是零信任網路至關重要的機制

1.2. 零信任並非完全偏離已知的安全機制，傳統的網路過濾機制在零信任網路中仍然扮演著重要的角色

2. 加密和認證

2.1. 加密和認證通常是緊密相關的，儘管其目的截然不同

  • 2.1.1. 加密提供機密性，用於確保只有接收者才能讀取傳送的資料

  • 2.1.2. 認證則用於確保接收者可以驗證訊息確實是由所聲稱的物件傳送的

2.2. 認證還有另外一個有趣的特性，為了確保訊息是可信的，必須能夠驗證傳送者以及傳送的訊息未被篡改，這是訊息認證的基本屬性，它被稱為完整性

2.3. 加密也可以不與認證同時使用，但一般認為這是一種非常糟糕的安全實踐

  • 2.3.1. 由於身份認證的缺失引發了更多的攻擊向量，因此業界對此的看法高度一致，強烈建議同時使用加密和認證

2.4. 訊息的真實性是零信任網路的一個必選需求，沒有它就無法構建零信任網路

2.5. 加密能夠保證機密性，但偶爾也會帶來麻煩

  • 2.5.1. 只有經過複雜的解密過程才可以讀取捕獲的資料包內容，這會導致故障排除變得更加困難

  • 2.5.2. 如果不能檢查網路流量，那麼入侵檢測就很難甚至不可能實現

  • 2.5.3. 如果想放棄加密機制，那麼一定要確保資料機密性對系統而言並不重要

  • 2.5.4. 透過各種理由來拒絕對業務流量進行加密是完全站不住腳的

  • 2.5.5. 在真實場景中，真正不需要機密性的系統是非常少見的

2.6. 認證仍然是必需的

  • 2.6.1. 很少有網路協議提供強認證機制但不提供加密

3. 首包認證

3.1. 網路流中的首個資料包職責重大，根據連線的型別或者裝置生命週期的時間點，首個資料包所蘊含的信任度極其有限

3.2. 在資料中心內部對各類資料流的預期是比較清楚的

3.3. 在面向客戶的系統中，誰都無法預測，因為這類系統一般是廣泛可達的，這大大增加了風險

3.4. 所謂的首包信任問題，通常採用預認證的方式來解決

  • 3.4.1. 預認證操作模式也稱為單包授權（Single Packet Authorization, SPA）

  • 3.4.2. 透過為認證請求設定預期，預認證可以被認為是對認證請求的授權，它往往透過為一小段資料加密和/或簽名，並使用UDP協議將資料包傳送至資源方來完成

  • 3.4.3. 使用UDP進行預認證非常重要，因為UDP傳輸是無連線的，預設無須響應，這個特性允許資訊接收方“隱藏”自己，只有其接收到採用正確金鑰加密的資料包時才會做出響應暴露自己

  • 3.4.4. 被動接收一個經過正確加密的預認證資料包後，就可以讓資訊傳送方啟動身份認證流程了，可以對防火牆過濾規則進行細粒度控制，僅僅為此傳送方打一個“洞”​，讓此傳送方與系統的TLS伺服器通訊

3.5. 將SPA作為裝置認證協議並不完全合適，它僅僅有助於解決首包信任問

3.6. 雖然SPA機制對於預認證來說極其重要，但不能用SPA代替更為穩定的雙向認證協議，比如TLS或者IK

4. fwknop

4.1. 一個流行的SPA開源實現，它支援多種作業系統，並且與主機防火牆整合以便建立具有嚴格範圍的短時例外

4.2. 短時例外

  • 4.2.1. fwknop建立的防火牆規則是嚴格限定範圍的，它只允許傳送方的IP地址和傳送方請求的目的埠號透過，並且可以透過策略限制不同使用者的可請求目標埠範圍

  • 4.2.2. 傳送方還可以指定一個源埠號，進一步限制防火牆規則的範圍

4.3. 單包授權載荷

  • 4.3.1. fwknop SPA實現的有效載荷中包含7個必選欄位和3個可選欄位，其中包括使用者名稱、訪問請求自身的一些資訊（埠號等）、時間戳和一個校驗和

  • 4.3.2. 一旦客戶端生成了有效載荷，就可以對其進行加密，新增一個可選的HMAC, SPA資料包就成功生成並可以傳輸了

4.4. 載荷加密

  • 4.4.1. AES

  • 4.4.1.1. 個人應用程式或小型部署場景更傾向於AES

  • 4.4.1.2. 不要求任何GnuPG工具，並且AES在資料量和計算開銷方面效能更優

  • 4.4.1.3. 對稱加密的金鑰分配問題很難解決，而且在一定程度上，其帶來的挑戰變得難以應對

  • 4.4.2. GnuPG

  • 4.4.2.1. GnuPG加密模式解決了大部分對稱加密的問題，它是推薦的操作模式

  • 4.4.2.2. 在效能方面，GnuPG肯定不如AES

4.5. HMAC

  • 4.5.1. fwknop可以在其有效載荷的最後新增HMAC，雜湊訊息驗證碼（Hashed Message Authentication Code, HMAC）可以保證訊息的真實可靠性，以防止篡改

  • 4.5.2. 包括一個訊息摘要欄位，它是與明文一起計算並儲存的

  • 4.5.2.1. 這個訊息摘要有助於減少密文被篡改的威脅，但不夠理想，因為這種方法（被稱為“驗證並加密”或AtE）容易受到一些特定類別的攻擊

  • 4.5.2.2. 在加密的有效載荷後追加HMAC可以防止這些攻擊生效

  • 4.5.3. 解密程式通常比HMAC程式要複雜得多，這意味著它們更易遭受攻擊

  • 4.5.4. 透過為密文新增HMAC，使得接收者能夠進行輕量級的完整性檢查，這樣接受者只需傳送驗證透過的可信資料到解密程式即可

  • 4.5.5. 強烈建議在fwknop中啟用HMAC

5. 網路模型

5.1. 每一層都負責網路傳輸資料的一部分工作

  • 5.1.1. 分層定義的機制還有利於描述新技術在網路棧中執行的位置

  • 5.1.2. 4層負載均衡器不用考慮7層的資料，因此它僅僅能夠基於簡單的網路連線資訊（如源IP和埠號）來轉發和路由流量

5.2. OSI網路模型

  • 5.2.1. 1984年釋出

  • 5.2.1.1. 國際標準化組織ISO釋出了ISO 749

  • 5.2.1.2. 國際電信聯盟電信標準化局（ITU-T）釋出了X.200

  • 5.2.2. 第1層——物理層

  • 5.2.2.1. 被定義為網路裝置和承載網路傳輸的物理介質之間的介面，其中包括引腳佈局、線路阻抗、電壓和頻率

  • 5.2.3. 第2層——資料鏈路層

  • 5.2.3.1. 負責在物理層上傳輸資料。資料鏈路層僅考慮直連節點間的資料傳輸，並不考慮在互聯的網路之間如何進行資料傳輸

  • 5.2.4. 第3層——網路層

  • 5.2.4.1. 負責在兩個相互連線的節點之間傳輸資料包

  • 5.2.5. 第4層——傳輸層

  • 5.2.5.1. 建立在第3層的簡單資料包傳輸能力之上，它通常作為控制協議來為第3層擴充套件一些必要的服務

>  5.2.5.1.1. 有狀態連線

>  5.2.5.1.2. 多路複用

>  5.2.5.1.3. 有序傳送

>  5.2.5.1.4. 流量控制

>  5.2.5.1.5. 重傳

  • 5.2.5.2. TCP就是第4層協議，不過和網路層的IP協議類似

  • 5.2.6. 第5層——會話層

  • 5.2.6.1. 為連線提供了額外的狀態層，並允許恢復通訊

  • 5.2.6.2. 多個VPN（PPTP、L2TP）和代理協議（SOCKS）都工作在這一層

  • 5.2.7. 第6層——表示層

  • 5.2.7.1. 與應用程式開發人員頻繁發生互動的一層，這一層負責處理應用程式資料（通常是結構資料）和可傳輸的資料流之間的轉換

  • 5.2.7.2. 通常還負責加密和壓縮之類的工作

  • 5.2.7.3. TLS是工作在表示層的協議，儘管只在會話建立後它才開始在第6層上執行

  • 5.2.8. 第7層——應用層

  • 5.2.8.1. OSI模型的最高層，它提供了應用程式在網路上通訊的高階通訊協議

  • 5.2.8.2. 常見協議有DNS、HTTP和SSH協議

5.3. TCP/IP網路模型

  • 5.3.1. TCP/IP模型沒有試圖透過明確的邊界來定義嚴格的層

  • 5.3.2. RFC 3439記錄了針對網際網路架構師的“哲學指導方針”​，其中有一節名為“深思熟慮，認為分層是有害的”​

  • 5.3.3. 鏈路層

  • 5.3.4. 網際網路層

  • 5.3.4.1. 一般與第3層相關聯

  • 5.3.5. 傳輸層

  • 5.3.5.1. 大致可以對映到第4層

  • 5.3.5.2. 透過引入埠的概念它具備了一些第5層的特性

  • 5.3.6. 應用層

  • 5.3.6.1. 大致覆蓋了OSI模型中的第5～7層

6. 零信任在網路模型中的位置

6.1. TLS

  • 6.1.1. TLS（傳輸層安全，其前身是SSL）相對較為常見，許多應用層協議支援透過TLS來保護流量

  • 6.1.2. TLS並不工作在TCP/IP模型的傳輸層，而是工作在應用層（在OSI模型的第5層和第6層之間）​

  • 6.1.3. 基於邊界的網路經常將TLS從應用程式中抽象出來，將其職責從應用程式轉移到基礎設施

6.2. IPSec

  • 6.2.1. IPSec是一種替代協議，通常用於VPN場景

  • 6.2.2. IPSec通常被認為是TCP/IP模型中網際網路層的一部分（OSI模型中的第3層或者第4層，這取決於不同的理解）

  • 6.2.3. IPSec本身是為IPv6規範開發的，它最初是IPv6的一個需求，但最終被降級為推薦項

  • 6.2.3.1. 因為IPv6標準包含IPSec，所以希望隨著IPV6的逐步採用，IPSec能夠成為網路環境下的可行解決方案

  • 6.2.4. 使用IPSec可以明確保護主機之間的通訊

  • 6.2.4.1. 由於IPSec被深度整合到網路棧中，因此可以將其配置為僅允許在建立了安全通道之後再進行資料包傳輸

  • 6.2.4.2. 接收方可以配置為只處理透過安全通道發來的資料包

  • 6.2.4.3. 只有安全的流量才能透過

  • 6.2.4.4. 它可以一次性為一個應用程式增加安全通訊

6.3. 零信任的目標是保證所有流量的安全通訊，實現這一目標的較好方式是構建預設安全通訊的系統，作為一種底層服務，IPSec能夠很好地提供這種預設服務

6.4. 僅保護兩個裝置之間的通訊是不夠的，還需要確保每個單獨的網路流都是經過授權的

  • 6.4.1. IPSec可以為每個應用程式配置使用唯一的安全關聯（SA）

  • 6.4.1.1. 只有經過授權的流量才允許構造這些安全策略

  • 6.4.2. 過濾系統（軟體防火牆）可以疊加在IPSec之上

  • 6.4.3. 應透過應用程式級授權來確保通訊得到授權，可以使用標準的授權技術（如訪問令牌或X.509證書）​，同時將強大的加密和認證職責委派給IPSec棧

  • 6.4.4. 對於一個真正具備雙重保障的系統，雙向TLS認證可以被疊加在現有的IPSec層之上

  • 6.4.4.1. 這種縱深防禦的方法提供了兩層加密（MTLS和IPSec）​，確保即使其中一層被攻破，通訊仍能得到保護

  • 6.4.4.2. 這是以複雜性和額外的開銷為代價的

6.5. 網路支援問題

  • 6.5.1. 網路支援問題會阻礙IPSec的大規模應用，IPSec引入多個新協議，其中有兩個（ESP和AH）IP協議

  • 6.5.2. 大型公有云提供商Amazon的Web服務不允許在其網路上傳輸ESP或AH流量

  • 6.5.3. IPSec支援在UDP報文中封裝流量

  • 6.5.3.1. 這種封裝允許不友好的網路進行流量傳輸，但它在一定程度上增加了系統的複雜性

6.6. 裝置支援問題

  • 6.6.1. IPSec標準是複雜的，它包括許多配置選項和密碼套件

  • 6.6.2. 在IPSec系統中還沒有一個非常強大的密碼套件

  • 6.6.3. IPSec同樣需要主動配置相關的裝置，在裝置能力不同的客戶端/伺服器系統中，配置客戶端裝置可能相當具有挑戰性

  • 6.6.4. 桌面作業系統通常可以支援不那麼主流的協議，然而，移動作業系統的侷限性更大，它難以透過符合零信任模式的方式完全支援IPSec

6.7. 應用支援問題

  • 6.7.1. 和基於TLS的方案相比，IPSec對系統配置的要求更高

  • 6.7.2. 使用IPSec的系統需要配置IPSec策略，為所需的密碼套件啟用核心支援，並執行IKE守護程序來實現IPSec安全關聯的協商

  • 6.7.3. Web瀏覽器通常是訪問一個組織各類系統的公共接入點，它支援現代TLS（假設組織保證使用瀏覽器的最新版本）​

  • 6.7.4. 在伺服器端，許多組織正在向一種新模式轉變，這種模式透過本地的守護程序集中保護網路通訊，它將配置集中在單個應用程式中，並且允許系統管理員提供基本的網路安全層，在某種程度上，它看起來類似於IPSec模型，但是其實現基於TLS

6.8. 實用解決方案

  • 6.8.1. 對於客戶端/伺服器的互動，使用雙向認證的TLS協議似乎是一種合理的網路安全方案

  • 6.8.1.1. 這會限制零信任僅支援基於瀏覽器的Web應用

  • 6.8.2. 對於伺服器/伺服器的互動，IPSec似乎更實用，伺服器機群（Fleet）的配置通常更可控，並且網路環境更明確

  • 6.8.3. 對於不支援IPSec的網路，UDP封裝可以用來解決網路傳輸問題

6.9. 微軟伺服器隔離

  • 6.9.1. 對於完全使用帶有AD域的Microsoft Windows環境來說，一種被稱為伺服器隔離的特性尤其具有吸引力

  • 6.9.2. 伺服器隔離可以與AD域的安全組繫結，提供細粒度的訪問控制，強大的IPSec認證為這種模式提供支援

  • 6.9.3. 伺服器隔離可能是在基於Windows的環境中實現零信任的較實用方法

相關文章