讀零信任網路：在不可信網路中構建安全系統08裝置清單管理
躺柒發表於2024-08-04
1. 裝置清單管理
1.1. 裝置的認證和完整性檢查是零信任安全至關重要的第一大步，但是僅僅驗證裝置是否屬於企業是不夠的
1.2. 裝置清單管理涉及對裝置及其屬性進行編目管理
1.2.1. 將配置管理作為裝置清單資料庫
1.2.2. 維護/管理這些記錄對客戶端和伺服器裝置同樣重要
1.2.3. 建議將這些裝置當作網路實體而不是物理裝置，雖然大多數情況下它們是物理裝置，但是在零信任網路中，它們也可能是網路上的邏輯實體
1.2.4. 事實上，同時部署多個清單管理系統也是很常見的
1.3. 零信任網路模型主張跟蹤工作負載流量以便進行細粒度的網路策略
1.3.1. 工作負載排程服務是可以作為裝置清單管理的一個元件進行工作的
1.4. 梳理系統預期
1.4.1. 零信任網路的強大之處在於系統預期的明確，什麼應該發生和什麼不應該發生是很清晰的
1.4.2. 預設情況下禁止任何等級的訪問，只允許預期的操作和請求
1.4.3. 裝置清單資料庫是實現這種可預期的訪問控制能力的關鍵元件
1.4.3.1. 透過各類裝置屬性可以推匯出大量的有用資訊
1.4.3.2. 基於這些資訊推匯出系統的預期行為
1.4.3.3. 預期行為可能包括哪些使用者或應用應該在哪些裝置執行、裝置應該被部署的位置，甚至裝置上應該執行什麼作業系統等
1.4.3.4. 屬性資訊越豐富、越準確，這種細粒度的行為預期和訪問控制規則就越完善
1.4.3.4.1. 可以預設只放行期望的流量
1.4.4. 在資料中心內的伺服器行為相對靜態和可預期，它們往往採用長連線的方式與特定的預設主機/服務通訊
1.4.5. 客戶端系統則常常使用短連線與各種不同的服務進行通訊，通訊的時間、頻率和模式都會持續有機變化
1.4.6. 一種可行的方案是允許各類全域性訪問
1.4.6.1. 確保所有的通訊都使用雙向認證的TLS連線進行保護
1.4.6.2. 強制客戶端提供裝置證書，否則雙向認證的TLS連線將無法建立
1.4.6.3. 透過裝置證書，可以在裝置清單資料庫中進行裝置檢索，從而判斷是否授權此連線請求
1.4.7. 這種方案的優勢在於，很多系統現在都支援雙向TLS連線，並且不會過度限定必須使用某種客戶端軟體，因此，可以在獲得較高安全性的同時保持不錯的可用性和易用性
1.4.8. 不足也非常明顯，服務是全域性可訪問的
1.4.8.1. 透過雙向TLS驗證客戶端證書可以緩解這種安全性的不足
1.4.8.2. 由於心臟滴血（HeartBleed）之類漏洞的存在，TLS伺服器仍然暴露了相當大的攻擊面
1.5. 安全介紹
1.5.1. Secure Introduction, SI
1.5.2. 新裝置發出的第一個連線或資料包具有極高的不確定性（甚至威脅性）
1.5.2.1. 因為系統為了提供服務，必須允許和接受這個請求，如果沒有很好的機制對這個初始包進行認證，則風險就始終存在
1.5.3. 透過安全介紹，一個新實體在將自己介紹給一個現有系統的同時可以傳遞足夠的信任資訊
1.5.4. 安全介紹機制的核心在於必須設定一個預期
1.5.4.1. 安全介紹在實踐中必須依賴一個可信的第三方
1.5.4.2. 這個可信第三方是一個已經被信任的系統，並且它具備介紹其他更多新系統加入的能力
1.5.5. 優秀的安全介紹系統的構成要素
1.5.5.1. 單次使用
1.5.5.1.1. 安全介紹所使用的憑證或許可權資訊只能單次使用，防止攻擊者透過重用金鑰進行攻擊或重放攻擊
1.5.5.2. 瞬時性安全介紹所使用的憑證或許可權資訊應該具備時效性，防止有效但尚未使用的金鑰形成堆積
1.5.5.3. 第三方參與
1.5.5.3.1. 透過第三方系統進行安全介紹有利於職責分離，這可以避免引入一些不良的安全舉措，並且有效地緩解一些運維麻煩
1.5.6. Chef系統提供唯一的秘密資訊（視作“驗證證書”），只要擁有這個證書，主機就可以作為一個新節點加入系統
1.5.7. 新版的Chef採用了新方案，它不再提供靜態的驗證證書，而是供應系統（透過Chef客戶端工具“Knife”）與Chef伺服器通訊，建立一個客戶端和相關聯的客戶端證書，然後進一步建立一個新主機並傳遞客戶端證書，透過這種方法，新客戶端就建立了足夠的預期
2. 裝置信任續租
2.1. 沒有完美的安全，也沒有永遠的安全。這是一個必須面對和遵循的事實，沒有例外
2.1.1. 只有意識到這一“殘酷”現實，才能妥善地尋求緩解措施來應對各種可能的安全問題和潛在影響
2.1.1.1. 所有解決方案都依賴於具體的場景
2.1.2. 隨著時間的推移，信任度會流失，因此，需要考慮信任的續租
2.1.2.1. 裝置從可信狀態開始，逐步退化到不可信狀態
2.2. 裝置執行的時間越長，其被攻破的可能性就越高，因此，裝置“年齡”應該作為一個信任訊號進行度量
2.2.1. 一臺全新映象的裝置的可信度顯然高於一臺執行了多年的裝置
2.3. 裝置輪換（Rotation）
2.3.1. 雲主機例項，在這種場景下實現“輪換”就相對簡單：只需要銷燬現有例項，重新構建一個新例項就完成了（使用配置管理系統，這個過程很簡單）
2.3.2. 物理硬體的場景，裝置輪換就不那麼簡單了
2.3.3. 大家都認可客戶端裝置也需要週期性的輪換或重映象，但是這個頻率需要根據情況具體分析
2.3.4. 裝置輪換或重映象的週期越長，終端系統的安全越是難以控制
2.4. 本地度量
2.4.1. 基於硬體的度量
2.4.1.1. 更加安全可靠，但是受限於硬體的能力
2.4.1.2. 利用TPM實現遠端證明
2.4.1.2.1. 這個響應資訊非常可靠並且難以複製
2.4.1.2.2. TPM的遠端證明只能覆蓋比較低階的系統資訊和特定的軟體資訊，如果攻擊者透過提權在系統的使用者空間執行了一些未授權應用，那麼TPM的遠端認證機制就無能為力了，因此其能力是受限的
2.4.2. 基於軟體的度量
2.4.2.1. 安全性和可靠性稍弱，但是在實踐中，其度量能力會更加強大
2.4.2.2. 代理程式可以持續報告系統的健康度和狀態評估
2.4.2.2.1. 缺乏硬體層面的保護，所以只要攻擊者具備足夠的許可權就很容易對其進行攻擊（甚至篡改），整個度量機制也會隨之失效
2.5. 遠端度量
2.5.1. 其受益於職責分離
2.5.2. 一個被攻破的系統可能上報任意經過篡改的內容，這些內容和資訊能輕而易舉地掩蓋攻擊者的行為
2.5.2.1. 這種情況在遠端度量或被動度量的場景下不會發生
2.5.2.2. 因為這些度量是完全獨立的外部系統，它從外部對目標裝置進行健康度分析和度量
2.5.3. 在傳統方案中，遠端度量透過簡單的漏洞掃描實現，週期性地對目標系統進行掃描、探測，並觀察和分析其響應結果
2.5.3.1. 這種探測和掃描可以獲取不少的有用資訊，包括裝置上執行的是什麼作業系統、裝置開啟了哪些服務，甚至於可以探測這些服務的版本是多少
2.5.3.2. 非常成熟的漏洞掃描軟體
2.5.3.2.1. OpenVAS
2.5.3.2.2. Nessus
2.5.3.3. 本地度量是詢問某人是否搶劫了銀行，而漏洞掃描系統則稍微高明一點，它透過觀察判斷某人是否搶劫了銀行
3. 軟體配置管理
3.1. 配置管理是嚴格控制和記錄所有軟體變更的過程
3.1.1. 所需的配置被定義為程式碼或資料
3.1.2. 這些資訊通常被提交到版本控制系統進行管理，以便進行變更審計、回滾之類的操作
3.2. 配置管理軟體在資料中心和客戶端部署場景中同樣適用，特別是當系統規模超出一定範圍後尤其必需
3.2.1. 資料中心託管系統雖然具備一定的動態性，但某種程度上卻明顯比客戶端系統更加靜態和可預測
3.3. 基於配置管理的裝置清單庫
3.3.1. 一種免費饋贈
3.3.2. 配置管理系統本身還有很多其他好處可大量使用，將其作為裝置清單資料庫往往是出於方便
3.3.3. 配置管理系統不是為裝置清單管理系統而設計的，它們是作為配置管理系統使用的，其功能存在明確的邊界，當然，最終可以逐步將其完善
3.4. 可搜尋的裝置清單庫
3.4.1. 一些配置管理系統集中儲存透過其代理收集的資料，並且支援對這些資料進行搜尋，基於這樣的系統構建零信任網路，具備了更多的可能性和想象空間
3.4.2. 裝置清單庫的可搜尋特性在審計和報表生成方面也大有可為
3.4.2.1. 這種特性不僅僅適用於資料中心，還適用於客戶端系統
3.4.3. 只需要簡單地搜尋目標系統，並變更配置管理的程式碼，有漏洞的軟體包就全部精準更新了
3.5. 軟體
3.5.1. Chef
3.5.2. Puppet
3.5.3. Ansible
3.5.4. CFEngine
4. 確保資料的真實性
4.1. 信任的基礎是裝置部署者，或者是人工操作員，又或者是某個自治系統
4.2. 評估裝置的關鍵屬性或行為等各個方面
4.2.1. 裝置型別
4.2.2. 角色
4.2.3. IP地址（針對資料中心而言）
4.2.4. 公鑰
4.3. 限制對這些屬性的變更至關重要
4.3.1. 這些自彙報的裝置屬性仍然可以用於授權判定
4.3.2. 在任何情況下都不能把這些屬性當作既成事實，而應僅僅將其作為一個提示性的屬性
5. 使用者授權
5.1. 零信任網路模型強制對裝置、使用者甚至應用程式進行認證和授權
5.2. 裝置認證一般在使用者認證之前完成，因此裝置認證不應該依賴使用者認證階段獲取的任何資訊，使用者認證則與之相反
5.2.1. 當進行使用者認證時，裝置認證也已完成，網路已經知悉了裝置的身份並生成了大量有用的場景資訊
5.2.2. 可以據此資訊構建比以往更強大的使用者認證手段
5.2.3. 可以根據這些資訊判斷使用者是否應該在某個型別的裝置或者某個位置登入
5.3. 另外一種不錯的威脅訊號是使用者認證頻率
5.3.1. 事無絕對，這種情況也有可能是合法的，因此，對這種情況的處理可以灰度化，降低使用者的信任評分以表明當前會話值得懷疑
5.4. 對零信任網路架構而言，能進行場景感知的動態授權判定是非常關鍵的，這也說明了強大的裝置清單資料庫的重要性
5.4.1. 裝置清單管理雖然是為了進行嚴格的裝置認證而引入的，但其在使用者認證方面的貢獻更是極具價值
6. 信任訊號
6.1. 上次映象時間
6.1.1. 隨著時間的推移，裝置被攻破的機率將大幅上升
6.2. 歷史訪問
6.2.1. 裝置認證模式和使用者認證模式比較類似，能較好地體現裝置的風險，並且可以對裝置的行為進行建模和過濾
6.2.2. 訪問頻率也可以用於分析某個資源是否被可疑地濫用
6.3. 位置
6.3.1. 雖然在零信任網路模型中，網路位置不再是授權判定的依賴因素，但是仍然可以將其作為一種信任訊號進行分析
6.3.2. 零信任的目標就是不以網路位置作為信任的基礎，因此，基於網路位置來判定訪問許可權確實看起來有少許矛盾
6.4. 網路通訊模式
6.4.1. 如果裝置訪問的網路是可控的，那就有機會度量網路通訊模式，並形成一種流量正規化，正規化的突然變化是可疑的，這將直接影響系統對裝置的信任度
6.4.2. 網路監測和流量採集裝置透過流量分析可以快速檢測出可能的入侵，將這種檢測結果作為授權判定的輸入因子，可以產生強大的聯動效果