讀零信任網路：在不可信網路中構建安全系統15協議和過濾

1. 協議

1.1. IKE/IPSec

• 1.1.1. 因特網金鑰交換協議（Internet Key Exchange,IKE）用於執行IPSec認證和金鑰交換

• 1.1.1.1. 通常以後臺守護程序的方式實現，使用預共享金鑰或X.509證書來認證對端並建立一個安全會話

• 1.1.2. IKEv1與IKEv2

• 1.1.2.1. IKEv1過於複雜，效能也不太好

• 1.1.2.2. 相比於IKEv1, IKEv2更為靈活和可靠

• 1.1.2.3. 強烈建議使用IKEv2

• 1.1.3. IPSec不是單一的協議，而是一系列協議的集合

• 1.1.4. IKE可以被認為是IPSec的控制平面，它處理會話協商和認證，使用協商的結果為端點配置會話金鑰和加密演算法

• 1.1.5. 由於核心的IPSec協議內嵌在IP協議棧中，因此IPSec通常在核心中實現

• 1.1.5.1. 金鑰交換是一種相對複雜的機制，IKE以使用者態的守護程序形式實現

• 1.1.5.2. 核心維護的狀態定義了IPSec安全關聯，流量選擇器則定義了對哪些流量應用IPSec策略

1.2. 身份認證憑證

• 1.2.1. IKEv2支援預共享金鑰和X.509證書

• 1.2.2. 還支援可擴充套件身份驗證協議（EAP）​

• 1.2.3. 支援EAP意味著IKEv2透過代理可以支援大量其他的身份驗證方法（包括多因素認證）

• 1.2.4. X.509證書是IKE的首選認證方法

• 1.2.4.1. X.509證書不是為人工使用準備的，它們用於裝置。證書不但攜帶信任證明，而且提供了帶有簽名的後設資料，以及一種利用其身份對資料進行強加密的方法

• 1.2.5. IKEv2支援預共享金鑰，但我們強烈反對使用它們，其帶來了大量的金鑰生成和分發問題，但最重要的是，需要人為記憶這些預共享金鑰

1.3. IKE SA_INIT和AUTH

• 1.3.1. 所有的IKEv2金鑰交換都從一對名為IKE_SA_INIT的資料包交換開始，這個初始交換決定密碼套件的選擇（和Diffie-Hellman交換一樣）​

1.4. 密碼套件選擇

• 1.4.1. IPSec的密碼選擇比TLS稍微複雜一些

• 1.4.1.1. IPSec是在核心中實現的，相較於以軟體包的形式實現，其對密碼支援的要求更嚴苛

• 1.4.2. RFC 6379提出了被稱為套件B的密碼套件，該標準是由美國國家安全域性撰寫的，它是一個被廣泛接受的IPSec密碼套件標準

• 1.4.3. 不是所有的IPSec實現都支援橢圓曲線演算法，而套件B強制要求橢圓曲線加密

• 1.4.4. 對於主流橢圓曲線演算法的安全性的擔憂，許多人認為國家政府相關人員的干預可能會影響其安全性

1.5. IPSec安全關聯

• 1.5.1. 4個不同狀態：幼年（larval）、成熟（mature）、垂死（dying）和死亡（dead）​

1.6. IPSec隧道模式

• 1.6.1. 隧道模式是目前廣泛部署的模式，當IPSec在隧道模式下執行時，SA包含了遠端端點的資訊，用於封裝IP資料包並且在路由到端點的過程中保護它

• 1.6.2. 經常用於VPN，在需要與遠端網路建立安全連線的情況下，管理員能夠採用隧道方式將流向該網路的流量透過安全通道進行傳輸

• 1.6.3. 既然是隧道模式，那就意味著流量在某個時間點會變得不受保護

• 1.6.4. 傳送者與中間網路之間傳輸的安全是可以確保的，但在此之後，將無法保證安全性

• 1.6.4.1. 認為隧道模式其實與零信任體系結構相矛盾

1.7. IPSec傳輸模式

• 1.7.1. 傳輸模式提供了幾乎相同的安全保證，只是減去了隧道的部分

• 1.7.2. 它沒有封裝整個IP資料包，而是封裝了IP有效負載，這對於主機到主機的直接IP通訊非常有用

• 1.7.3. 傳輸模式並不是與網路中間裝置建立一個安全聯盟，而是與流量的目的端點直接建立安全聯盟，確保端到端應用安全，這個屬性使得傳輸模式能夠很好地適用於零信任網路

• 1.7.4. 成熟的零信任資料中心架構應該選擇IPSec的傳輸模式

1.8. 將IKE/IPSec用於裝置認證

• 1.8.1. 由於IPSec直接在IP上實現，因此它可以處理大多數應用程式流量，而不僅僅是TCP和UDP

2. 雙向認證TLS

2.1. 傳輸層安全（TLS，通常會沿用其前身SSL的稱謂）是用來保護Web流量的常見協議

• 2.1.1. 它是一種成熟的、易於理解的協議，被廣泛地部署和支援，並且已經獲得一些敏感業務的信任

• 2.1.2. HTTPS中的S指代的就是TLS（SSL）

• 2.1.3. 面向一般公眾的服務可以接受客戶端身份認證的缺失，但其他任何用例都不可接受這種妥協

• 2.1.4. 雙向身份認證是遵循零信任模型安全協議的必要條件，TLS也不例外

2.2. 在TLS密碼套件中有4個主要的元件

• 2.2.1. 金鑰交換

• 2.2.2. 身份驗證

• 2.2.3. 塊加密

• 2.2.4. 訊息完整性

2.3. 系統的整體安全性取決於較弱的客戶端能提供的最強密碼套件

• 2.3.1. 在TLS握手中，客戶端按優先順序顯示其支援的密碼套件列表，如果客戶端和服務端支援的密碼套件有重合，那麼伺服器會從這個列表中選擇一個密碼套件，否則會話建立就可能失敗

• 2.3.2. 建議伺服器只支援最合理的密碼套件

2.4. 協商是一個弱點

• 2.4.1. 碼套件協商被認為是現代加密協議中的反模式

• 2.4.2. 較新的協議和框架，如Noise，旨在消除協議協商

2.5. 金鑰交換

• 2.5.1. TLS的金鑰交換描述了在不安全的通道上安全地生成加密金鑰的過程

• 2.5.2. 它們使用數學函式來協商金鑰，而不用明文進行傳輸（在大多數情況下是這樣）​

• 2.5.3. TLS支援3個主流的金鑰交換/協商協議，按照優先順序排列，它們是ECDHE、DHE和RSA

• 2.5.4. ECDHE基於Diffie-Hellman交換，使用橢圓曲線來協商一個金鑰

• 2.5.4.1. 橢圓曲線密碼具備高強度、高效率的特點，它建立在一個難以解決的數學問題的基礎之上

• 2.5.4.2. 從安全性和效能上考慮，它是理想的選擇

• 2.5.5. DHE同樣基於Diffie-Hellman交換，但它使用模運算而不是橢圓曲線來協商一個金鑰

• 2.5.6. RSA金鑰交換基於非對稱運算來驗證數字簽名的身份（如X.509證書）​，它使用伺服器的公鑰來加密傳輸需要的共享金鑰

• 2.5.7. 當今主流的公鑰密碼學都基於這樣一種假設，即分解較大數字的計算開銷非常大

• 2.5.7.1. 經典的計算必須依賴於一種被稱為普通數域篩選法的技術來推匯出大數因子，這是一種相對低效的演算法

• 2.5.7.2. Shor演算法是一種比一般數域篩選更有效的量子演算法，只要有足夠強大的量子計算機，它就可以被用來快速破解大多數非對稱金鑰交換協議

2.6. 完美的前向保密性

• 2.6.1. PFS（完美的前向安全性）是一種加密屬性，基於PFS，私鑰的披露不會導致之前協商的會話的洩露

• 2.6.2. 可以確保竊聽者不能記錄會話資料以供之後解密

• 2.6.3. RSA金鑰交換不支援PFS

• 2.6.3.1. 因為我們是直接使用私鑰加密和傳輸會話金鑰的

• 2.6.4. 必須使用DHE或ECDHE以獲得完美的前向安全性

• 2.6.5. 精心設計伺服器端密碼套件，在可用的情況下先選擇DHE協商，必要時返回到ECDHE協商

2.7. 認證

• 2.7.1. 有3種常見的認證方法：RSA、DSA和ECDSA

• 2.7.2. RSA認證是較常見的，它在超過99%的基於Web的TLS資源中使用

• 2.7.3. DSA認證已不再推薦使用

• 2.7.4. EDCSA是DSA的新表兄，它使用橢圓曲線來提供公/私鑰對

2.8. 職責分離

• 2.8.1. 需要保護的資源是裝置，因此將加密功能獨立於工作負載本身非常有意義

• 2.8.2. 要確保所有這些應用程式都確實透過正確的方式使用TLS，在已知漏洞上保持最新狀態是非常困難的

• 2.8.3. 將TLS的配置職責轉移到控制平面是非常有用的

• 2.8.3.1. 到服務的連線被TLS守護程序代理，然後本地轉發給應用程式

• 2.8.3.2. TLS守護程序配置了系統證書、信任許可權和節點資訊

• 2.8.3.3. 透過這種方式，可以確保所有的軟體都接受裝置認證和TLS的安全保護，而不管軟體是否支援TLS庫

• 2.8.4. 零信任網路對業務流採用了“白名單”機制，所以可透過限制到已知TLS端點的業務流白名單，確保應用程式業務流量受到保護

2.9. 塊加密

• 2.9.1. TLS握手主要有兩個目的：認證和會話金鑰的建立

• 2.9.2. 當無須考慮身份或認證問題時，使用對稱加密就可以滿足所需的安全強度

• 2.9.3. 對稱加密使用一個單獨的金鑰而不是公/私鑰對，並且與非對稱加密相比其計算成本要低得多

• 2.9.4. 業界一致建議採用AES

• 2.9.4.1. 它設計完美，並且沒有專利保護，可以在硬體中廣泛實現，並且已在軟體中普遍採用

• 2.9.4.2. 它非常高效，經過嚴格的審查/檢查，並且保持一致性

2.10. ⑩訊息完整性

• 2.10.1. 訊息的完整性即使不是必需的也是一個重要屬性

• 2.10.2. 完整性演算法的選擇僅限於MD5和SHA系列的雜湊演算法

• 2.10.2.1. 前者已經被破解

• 2.10.2.2. 這使得SHA系列成為TLS確保訊息完整性的唯一合理選擇

• 2.10.2.3. 不斷增長的計算能力導致SHA-1脆弱並易受攻擊

• 2.10.2.4. 建議選擇可以合理部署的最強SHA雜湊演算法

2.11. ⑾基於雙向TLS進行裝置認證

• 2.11.1. TLS是依賴於協議的

• 2.11.1.1. 它通常基於TCP協議實現，雖然基於UDP的協議變種DTLS也是可用的

• 2.11.2. 只要代理和保護的上游節點被一個計算機網路分離開，這種執行模式就不適用於零信任網路

• 2.11.3. 在零信任網路中，基於TLS協議實現的通訊代理必須和應用程式部署在一個邏輯主機上

• 2.11.4. 在用TLS保護資料中心零信任網路時，應用需要自動化配置以便使用外部的TLS通訊，它不像IPSec協議那樣是“免費”加密

• 2.11.5. TLS仍然是目前保護面向客戶的零信任網路的較好選擇，它在軟體和傳輸網路中都得到了廣泛的支援，並且其運作模式直接而可信賴

• 2.11.6. 大部分Web瀏覽器本身就支援雙向TLS認證，這意味著資源可以直接基於零信任原則進行保護而不需要專門的客戶端軟體

3. 過濾

3.1. 過濾是資料包被網路上的系統接受或拒絕的過程

3.2. 防火牆確實提供了過濾作用，但它們也可以提供其他服務

• 3.2.1. 網路地址轉換（NAT）

• 3.2.2. 流量控制

• 3.2.3. VPN隧道服務

3.3. 傳統意義上過濾功能可以由很多系統提供，比如路由器或交換機

3.4. 過濾是一種簡單的服務，在網路系統的很多地方都可以應用它

3.5. 許多零信任概念都集中在高階加密和認證系統上，這是因為網路安全的這些方面沒有得到應有的設計和考慮

• 3.5.1. 不應該低估網路過濾的重要性，它仍然是零信任架構的關鍵組成部分

4. 主機過濾

4.1. 過濾主機上的流量

• 4.1.1. 主機過濾讓網路端點成為其自身安全的積極參與者，其目標是確保每臺主機都被配置為過濾自己的網路流量

4.2. 防火牆利用專用積體電路（Application-Specific Integrated Circuit, ASIC）來有效地處理流經裝置的資料包

4.3. 軟體防火牆比硬體防火牆要靈活很多，它們提供了一組豐富的服務

• 4.3.1. 比如根據日期和任意的資料偏移（欄位）來定義策略

• 4.3.2. Linux:IPtable

• 4.3.3. BSD系統：Berkley包過濾（BPF）

• 4.3.4. macOS：應用程式防火牆和基於命令列的主機防火牆

• 4.3.5. Windows:Windows防火牆服務

4.4. 零信任網路假設網路中始終充滿威脅，需要在每個可能的位置過濾網路流量，通常使用主機防火牆實現

4.5. 透過主機防火牆可以過濾不良網路流量來減小主機的攻擊面

4.6. 主機過濾非常容易著手實施，配置管理系統很好地支援了主機防火牆的管理

4.7. 在安全設計中隔離的好處，主機過濾可以從中受益

4.8. 關於主機過濾的問題是，其部署點在網路中的位置太“深”了，會造成大量的額外成本

• 4.8.1. 增加了拒絕服務（DoS）攻擊的可能性，使內部網路充斥大量的無用流量，壓垮了相對脆弱的軟體防火牆

5. 雙向過濾

5.1. 同時過濾主機的出入流量

• 5.1.1. 一種在接收和傳送資料包時同時應用的過濾策略

5.2. 出站（入站的反面）這個術語用來描述離開主機的網路流，這種型別的過濾通常用於管理從私有網路到公共網路的通訊，它很少在私有網路內部使用

• 5.2.1. 入站過濾更容易理解，因為在構建防火牆規則時可以列舉出所有的監聽服務，出站過濾則需要更多的記錄來得知主機如何進行通訊

• 5.2.2. 通常認為，入站過濾能夠阻止網路中的不良通訊

• 5.2.3. 出站過濾需要了解每一個預期的流量，這在傳統網路中不常見

5.3. 即使在系統中出現了關鍵的錯誤配置，一個部署了全面的雙向過濾機制的網路也會受到保護

5.4. 雙向過濾不是預防疾病，而是保護被錯誤配置的系統能夠免受錯誤配置帶來的潛在影響

5.5. 在系統中構建雙向過濾並沒有那麼困難，可以透過程式化實現對通訊業務流的捕獲，捕捉這些流的較好方法是定義細粒度的入站規則

5.6. 出站過濾機制最好與執行在系統上的應用程式隔離，建議在虛擬化或容器化環境的外層實現過濾以便擁有健壯的過濾機制

5.7. 當網路流資料庫與執行系統隔離時，雙向過濾是較有效的

5.8. Calico專案是動態排程工作負載的虛擬網路系統

6. 中間過濾

6.1. 透過兩個主機間的裝置過濾流量

• 6.1.1. 指除了傳送方或接收方之外的裝置在零信任網路中可以並且應該參與到流量過濾中

6.2. 邊界過濾在零信任網路中可以發揮作用，並且在網路結構中的中間裝置也可以發揮作用

6.3. 高吞吐量的過濾流量通常是來自網際網路入口的流量，在理想情況下，我們希望儘快過濾流量，以減少延遲過濾的影響和成本

6.4. UPnP被認為是有害的

• 6.4.1. 從主機策略衍生出的邊界策略不應該與UPnP混合使用

• 6.4.2. UPnP是一種用於重新配置使用者防火牆的技術

• 6.4.3. UPnP受到詬病是因為網路上的任何應用程式都可以重新配置邊界，在零信任模型中，主機策略和邊界建立的例外規則之間應該存在信任鏈

6.5. 零信任網路不會拋棄所有的邊界概念，相反，它們鼓勵管理員從主機開始向外擴充套件，邊界裝置最終會以某種方式發揮作用，而值得關注的是其在緩解拒絕服務攻擊上的應用

6.6. 使用主機策略資料庫來動態地規劃網路結構本身

6.7. 軟體定義網路（Software-Defined Network,SDN）

• 6.7.1. 它不會盲目地將資料包路由到目的地址，而是根據預期和允許的流量，積極管理交換和路由策略

• 6.7.2. 將潛在的惡意流量擋在主機之外，減少了攻擊面

• 6.7.3. 主機上基於軟體的防火牆在網路中增加了額外的防禦層

• 6.7.4. 想象一個SDN控制器，它只根據強身份認證和授權過程的結果實現流量傳輸，希望訪問網路資源的客戶端可以向控制平面發出訊號，提供網路訪問請求以及相應的憑證，請求成功授權之後，網路過濾或轉發規則就會被下發並且執行，但這些規則僅針對特定的已授權業務流