讀零信任網(wǎng)絡(luò)：在不可信網(wǎng)絡(luò)中構(gòu)建安全系統(tǒng)18零信任代理.png

1. 零信任代理

1.1. 零信任代理是應(yīng)用級(jí)代理服務(wù)器，用來保護(hù)零信任網(wǎng)絡(luò)，它是處理認(rèn)證、授權(quán)以及加密的基礎(chǔ)設(shè)施

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

• 1.2.1. 運(yùn)行時(shí)可以同時(shí)采用這兩種工作模式，也可以只采用其中的一種

• 1.2.2. 在反向代理工作模式下，代理接收來自零信任客戶端的連接請求，并接收初始連接，校驗(yàn)此連接是否應(yīng)該被授權(quán)，授權(quán)通過后，把客戶端請求傳遞給后端的應(yīng)用系統(tǒng)處理

• 1.2.3. 在前向代理工作模式下，非零信任感知的組件需要向另一個(gè)零信任系統(tǒng)發(fā)出網(wǎng)絡(luò)請求

  • 1.2.3.1. 因?yàn)榉橇阈湃胃兄慕M件不能和零信任控制平面交互，所以不能正確地初始化該請求，只能通過認(rèn)證代理完成請求的初始化

1.3. 利用代理構(gòu)建零信任網(wǎng)絡(luò)時(shí)，代理應(yīng)該以嵌入式的方式部署在運(yùn)行工作負(fù)載的設(shè)備上

• 1.3.1. 以這種方式構(gòu)建零信任網(wǎng)絡(luò)，所有工作負(fù)載的網(wǎng)絡(luò)通信流量在進(jìn)入網(wǎng)絡(luò)之前都會(huì)被強(qiáng)制引流到代理上

1.4. 最好不要把零信任代理部署在一臺(tái)單獨(dú)的外部設(shè)備上

• 1.4.1. 把零信任職責(zé)交由外部設(shè)備代理的做法違背了零信任模型聲稱的保證所有流量安全的目標(biāo)

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

1.5. 如果系統(tǒng)管理員對于網(wǎng)絡(luò)中的設(shè)備和服務(wù)沒有完全的控制權(quán)，那么構(gòu)建零信任網(wǎng)絡(luò)就會(huì)變得非常困難

1.6. 在不可修改的組件和零信任網(wǎng)絡(luò)之間部署零信任代理，就可以讓該組件參與到零信任網(wǎng)絡(luò)中來，盡管不能保證足夠高的安全性

1.7. 將非零信任感知的組件完全隔離非常重要，而且這種隔離必須保證流入和流出該組件的網(wǎng)絡(luò)流量都只能經(jīng)過認(rèn)證代理

• 1.7.1. 如果可能，代理最好采用串聯(lián)部署而非旁路部署模式

2. 客戶端與服務(wù)端遷移

2.1. 通常首先是從客戶端—服務(wù)器之間的交互著手實(shí)現(xiàn)零信任模型

• 2.1.1. 客戶端一般是指移動(dòng)設(shè)備或者源自非受控網(wǎng)絡(luò)的訪問服務(wù)

• 2.1.2. 零信任架構(gòu)的自動(dòng)化系統(tǒng)需要兼容多種客戶端操作系統(tǒng)

• 2.1.3. 不是每個(gè)客戶端設(shè)備都能安裝現(xiàn)有的自動(dòng)化系統(tǒng)

• 2.1.4. 在客戶端—服務(wù)器層面構(gòu)建零信任將會(huì)面臨很多挑戰(zhàn)

2.2. 從服務(wù)器—服務(wù)器之間的交互著手構(gòu)建零信任網(wǎng)絡(luò)相對來說更容易一些

• 2.2.1. 服務(wù)器通常都已經(jīng)安裝了自動(dòng)化工具

• 2.2.2. 服務(wù)器供應(yīng)商的數(shù)量相對較少，對系統(tǒng)自動(dòng)化工具的兼容性要求也更低

• 2.2.3. 從安全角度考慮也應(yīng)當(dāng)盡快著手實(shí)現(xiàn)服務(wù)器之間的零信任

  • 2.2.3.1. 服務(wù)器通常是那些保存敏感數(shù)據(jù)的系統(tǒng)，所以它們也是攻擊者的攻擊目標(biāo)

2.3. 網(wǎng)絡(luò)安全較薄弱的環(huán)節(jié)恰恰是構(gòu)建零信任網(wǎng)絡(luò)的著手點(diǎn)

2.4. 使用威脅建模方法可以預(yù)測攻擊者會(huì)在組織的哪些脆弱點(diǎn)進(jìn)行攻擊、如何攻擊，然后依此決定在哪里投入資源和時(shí)間研究以實(shí)現(xiàn)零信任

3. PagerDuty的云無關(guān)網(wǎng)絡(luò)

3.1. PagerDuty系統(tǒng)的日常運(yùn)營重度依賴廣域網(wǎng)（WAN）通信

• 3.1.1. 互聯(lián)網(wǎng)的網(wǎng)絡(luò)環(huán)境相對比較惡劣，可能會(huì)出現(xiàn)意外的高延遲和數(shù)據(jù)包丟失等狀況

• 3.1.2. 廣域網(wǎng)的通信需要采用認(rèn)證和加密機(jī)制以保證數(shù)據(jù)的隱私和完整性

3.2. 部署無邊界的零信任網(wǎng)絡(luò)成為理想的解決方案，零信任網(wǎng)絡(luò)集群中的每個(gè)節(jié)點(diǎn)都僅僅負(fù)責(zé)它自己的通信，可以實(shí)現(xiàn)故障的隔離

3.3. 配置管理系統(tǒng)作為自動(dòng)化平臺(tái)

• 3.3.1. Chef系統(tǒng)

  • 3.3.1.1. Chef已經(jīng)被用來配置系統(tǒng)中的虛擬機(jī)，因此它是一個(gè)理想的、隨時(shí)可用的自動(dòng)化系統(tǒng)，可以利用它來構(gòu)建零信任網(wǎng)絡(luò)

• 3.3.2. 好處

  • 3.3.2.1. 網(wǎng)絡(luò)計(jì)算資源能夠隨著實(shí)例數(shù)量的增減而自動(dòng)伸縮，隨著網(wǎng)絡(luò)的擴(kuò)展，這種伸縮性能夠降低購買更大的共享硬件服務(wù)器的需求

  • 3.3.2.2. 更好地隔離故障

    3.3.2.2.1. 該方案事實(shí)上是采用大量“微型防火墻”代替了傳統(tǒng)的完整防火墻

    3.3.2.2.2. 即使微型防火墻失效，也只是影響很小范圍的網(wǎng)絡(luò)流量

• 3.3.3. 貫穿整個(gè)網(wǎng)絡(luò)設(shè)計(jì)的分布式策略的缺點(diǎn)

  • 3.3.3.1. 需要持續(xù)校驗(yàn)預(yù)期策略的狀態(tài)，以確保所有節(jié)點(diǎn)正確地執(zhí)行預(yù)期策略

  • 3.3.3.2. 策略變更會(huì)逐步作用到整個(gè)集群

• 3.3.4. 選擇合適的配置管理工具作為著手點(diǎn)，能夠快速實(shí)現(xiàn)零信任網(wǎng)絡(luò)的理念落地，但是配置管理工具并不是理想的長期解決方案

• 3.3.5. 隨著零信任網(wǎng)絡(luò)的成熟度不斷提高，管理員應(yīng)該盡快擺脫對Chef系統(tǒng)的依賴，實(shí)現(xiàn)自己的自動(dòng)化平臺(tái)，以獲得最佳性能，為目標(biāo)進(jìn)行部署并持續(xù)迭代調(diào)優(yōu)

  • 3.3.5.1. 隨著網(wǎng)絡(luò)規(guī)模的擴(kuò)大，系統(tǒng)的配置不再依賴Chef，而是由一個(gè)專用服務(wù)負(fù)責(zé)

3.4. 動(dòng)態(tài)配置本地防火墻

• 3.4.1. Chef系統(tǒng)需要基于現(xiàn)有的系統(tǒng)知識(shí)生成IPtable配置

• 3.4.2. 每個(gè)主機(jī)都需要構(gòu)建IPtable鏈表，枚舉特定角色的服務(wù)器的IP地址，然后就可以使用這些鏈表來定義基于角色的訪問控制規(guī)則

3.5. 分布式流量加密

• 3.5.1. PagerDuty實(shí)現(xiàn)了一個(gè)基于IPSec主機(jī)—主機(jī)模式的網(wǎng)狀網(wǎng)絡(luò)

  • 3.5.1.1. 所有數(shù)據(jù)包都經(jīng)過系統(tǒng)中每個(gè)節(jié)點(diǎn)的加密和認(rèn)證

  • 3.5.1.2. 因?yàn)檎J(rèn)證和加密是在系統(tǒng)中分布式部署的，所以這些關(guān)鍵功能會(huì)隨著主機(jī)數(shù)量的增加而增長

• 3.5.2. 3個(gè)問題

  • 3.5.2.1. 不是每個(gè)應(yīng)用都能正確實(shí)施加密規(guī)范

  • 3.5.2.2. 缺乏響應(yīng)安全漏洞的配置控制手段

  • 3.5.2.3. 導(dǎo)致系統(tǒng)性能降低

• 3.5.3. 為了保證安全能力的一致性，系統(tǒng)管理員應(yīng)當(dāng)把TLS基礎(chǔ)設(shè)施從應(yīng)用系統(tǒng)中剝離出來

• 3.5.4. 隨著系統(tǒng)中應(yīng)用程序的數(shù)量不斷增加，越來越多的系統(tǒng)傾向于利用過程外（Out-Of-Process）加密機(jī)制來保證網(wǎng)絡(luò)通信安全

• 3.5.5. IPSec通信通常采用ESP數(shù)據(jù)包傳輸，但是有些云服務(wù)提供商不能路由ESP數(shù)據(jù)包，所以需要使用UDP數(shù)據(jù)包封裝所有IPSec流量

  • 3.5.5.1. 優(yōu)點(diǎn)是可以有效處理隨著主機(jī)數(shù)量增加而不斷增長的業(yè)務(wù)吞吐量

  • 3.5.5.2. 缺點(diǎn)：初次上線運(yùn)行時(shí)，IPSec通信雙方的狀態(tài)不一致經(jīng)常會(huì)導(dǎo)致通信的失敗，而這類問題對于網(wǎng)絡(luò)的生產(chǎn)運(yùn)營至關(guān)重要

• 3.5.6. 分布式流量加密也采取了漸進(jìn)式部署模式

  • 3.5.6.1. 以空操作（No-Op）的方式在系統(tǒng)集群中部署IPSec策略，這些策略用于控制網(wǎng)絡(luò)流量是否應(yīng)該使用IPSec通信

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

  • 3.5.6.3. 使用（Use）：如果通信雙方可以通過協(xié)商調(diào)整關(guān)系參數(shù)，那么最好使用IPSec

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

  • 3.5.6.5. 在實(shí)際應(yīng)用中，不能直接把整個(gè)網(wǎng)絡(luò)同時(shí)配置成“使用”狀態(tài)，而是先將一小部分網(wǎng)絡(luò)遷移到“使用”狀態(tài)，然后再將它們重新配置成“必須使用”狀態(tài)

3.6. 用戶管理的去中心化

• 3.6.1. PagerDuty的用戶訪問控制也是集中式部署的，但是其用戶管理沒有依賴中心化的LDAP系統(tǒng)，而是由網(wǎng)絡(luò)中的每個(gè)主機(jī)構(gòu)建本地用戶和群組

• 3.6.2. 系統(tǒng)根據(jù)LDAP服務(wù)器和其他相關(guān)數(shù)據(jù)庫中的信息，集中完成用戶和群組的定義

3.7. 部署上線

• 3.7.1. 步驟

  • 3.7.1.1. 定義新策略

  • 3.7.1.2. 在不影響生產(chǎn)系統(tǒng)的情況下部署策略，同時(shí)收集有用的測量指標(biāo)和日志

  • 3.7.1.3. 長期收集監(jiān)測測量指標(biāo)或日志，確保整個(gè)系統(tǒng)運(yùn)行在期望狀態(tài)下

  • 3.7.1.4. 策略逐漸覆蓋整個(gè)系統(tǒng)集群，從只覆蓋系統(tǒng)的一部分直到百分之百完全覆蓋

3.8. 供應(yīng)商無關(guān)系統(tǒng)的價(jià)值

• 3.8.1. 構(gòu)建與供應(yīng)商無關(guān)的系統(tǒng)需要巨大的工程投入

• 3.8.2. 供應(yīng)商無關(guān)網(wǎng)絡(luò)將顯著減少供應(yīng)商移除過程所花費(fèi)的時(shí)間，并且降低了風(fēng)險(xiǎn)

• 3.8.3. 調(diào)研新供應(yīng)商

• 3.8.4. 試新供應(yīng)商的系統(tǒng)

• 3.8.5. 使用Chef自動(dòng)化系統(tǒng)重新配置

• 3.8.6. 真正對生產(chǎn)系統(tǒng)部署變更的時(shí)間只需要1周，并且不會(huì)對客戶造成任何影響