讀零信任網路：在不可信網路中構建安全系統07裝置信任
躺柒發表於2024-08-03
1. 裝置信任
1.1. 在零信任網路中建立裝置信任至關重要，這也是非常困難的一個環節
1.2. 建立裝置信任是基石，直接影響零信任網路架構的成敗
1.3. 大多數網路安全事件都和攻擊者獲得信任裝置的控制權相關，這種情況一旦發生，信任就將被徹底瓦解，無法透過裝置來確保安全信任鏈的建立
2. 初始信任
2.1. 對於新採購的裝置，其信任程度取決於採購者對生產廠商和供應商的信任程度
2.1.1. 一般認為其信任度較高
2.1.2. 這種繼承自供應商的信任度是一種社會化信任
2.1.3. 需要將這種現實社會的真實信任度“注入”裝置本身，形成初始的數字信任度
2.2. 黃金映象
2.2.1. 無論以何種方式收到裝置，都需要載入一個明確的“好”映象，這個映象就是“黃金映象”
2.2.2. 一次性地透過徹底的稽核確定軟體映象的可信，並將其作為“黃金映象”進行分發
2.2.3. 將一個乾淨的“黃金映象”載入到裝置能極大地確保裝置的信任度
2.2.3.1. 透過這種方式，有足夠的理由確信裝置執行的軟體經過了稽核並且是安全的
2.2.3.2. 記錄裝置上次重新載入映象的時間可以在一定程度上決定裝置的可信程度
2.3. 安全啟動
2.3.1. 透過一些非常底層的技術將非法程式碼植入到裝置中是完全有可能的
2.3.1.1. 即便重新為裝置載入映象也無法擦除
2.3.2. 安全啟動是防護此類攻擊的方法之一，透過在裝置韌體內嵌入的公鑰對驅動程式和作業系統載入程式進行簽名驗證，可以確保這類非法植入物無所遁形
2.3.3. 安全啟動比較有效，但是其受限於作業系統和裝置的內在機制的支援
2.3.4. 有效驗證裝置上執行的軟體只是第一步，還需要提供一種技術手段，讓裝置可以向待訪問的資源標識自己的身份
2.3.4.1. 典型做法是透過私有CA為每臺裝置簽發單獨的裝置證書，進行網路通訊時，裝置必須提交此證書
2.4. 裝置證書
2.4.1. 裝置證書不僅僅能證明裝置是已知在冊的，還能證明裝置的唯一身份
2.4.2. 裝置證書的私鑰一旦被竊取，攻擊者就可以假冒信任裝置，這種情況會直接影響裝置認證方案的有效性
2.4.2.1. 必須考慮裝置證書私鑰的安全儲存問題
2.4.3. 方案1：配置對私鑰的訪問許可權，只允許具有超級許可權的使用者（如root或administrator）訪問
2.4.3.1. 攻擊者一旦提權就可以輕易獲取私鑰
2.4.4. 方案2：對私鑰進行加密
2.4.4.1. 比簡單的許可權控制方案好一些
2.4.4.2. 可能存在一些易用性問題
2.4.4.2.1. 必須提供口令或其他憑證才能解密和使用私鑰
2.4.4.2.2. 對於伺服器認證的場景它就很不適用了
2.4.4.2.2.1. 無法做到每次軟體重啟時都要求人工互動
2.4.5. 方案3：迄今為止儲存裝置金鑰的一種極好的方法是使用安全的加密處理器
2.4.5.1. 這些裝置[通常被稱為硬體安全模組（HSM）或可信平臺模組（TPM）]提供可以執行加密操作的安全區域
2.4.5.2. 加密處理器暴露為數不多的應用程式程式設計介面（API）用於生成非對稱加密金鑰，確保私鑰永遠不會離開安全模組
2.4.5.3. 作業系統也不能直接訪問安全模組儲存的私鑰，因此它很難被竊取
2.4.6. 裝置證書代表了裝置的身份和初始信任度，其私鑰用於對其他系統證明本裝置是被認證的、可信的
2.4.6.1. 既然對身份標識的本地安全儲存都需要謹慎防護以免被竊取，證書的生成和簽發就更不應掉以輕心
2.4.6.2. 如果從企業的安全需求來看，裝置的初始證書籤發和安裝極其敏感，那就必須在證書籤署流程中引入人工干預環節，杜絕流程上的隱患
2.5. 身份標識安全
2.5.1. 在相對靜態的系統中配置新主機時，通常由安全操作員進行人工的裝置身份標識部署
2.5.1.1. 一般認為安全操作員是可信任的
2.5.1.2. 這一人工操作確保初始身份標識可信
2.5.2. 在動態系統中，配置和簽名過程都是自動化的，是否需要人工干預？
2.5.2.1. 完全取決於系統的安全等級
2.5.3. 所有應用和系統元件都應該身份化，這一原則是不變的，這同時適用於主機中心化和容器中心化的環境
2.6. 審批和安全授權
2.6.1. 為避免人為犯錯，建議每個人只負責對他們自己發起的請求進行審批確認
2.6.2. 透過使用一次性動態口令（TOTP）可以在單個步驟中完成部署和簽名授權
2.6.2.1. 一個TOTP口令只能使用一次，所以TOTP驗證失敗是一個重要的安全事件，可以杜絕安全隱患
2.6.3. 信任只能來源/派生於某個已有的信任源
2.6.3.1. 人工干預
2.6.3.1.1. 在相對靜態的基礎設施或終端使用者裝置的場景中，人工干預是一種簡單安全的方案
2.6.3.1.2. 對於自動化的基礎設施場景而言，人工干預不是一個好的選擇
2.6.3.2. 資源管理器
2.6.3.2.1. 在某種程度上屬於特權系統，其具備對基礎設施的系統進行擴大或縮減的能力，並且整個基礎設施的可用性也極大地依賴這類資源管理系統
2.6.3.2.2. 透過資源管理器可以直接或間接地對新證書的簽發進行授權
2.6.3.2.3. 在容器化環境中，這類職責可能由資源排程器承擔
2.6.3.3. 映象或裝置
2.6.3.3.1. 可考慮將身份憑證直接“燒製”到裝置映象中
2.6.3.3.2. 不建議將這種方案作為首選，因為這種方案過度依賴映象庫，並且保護和週期性地重新整理映象將變得複雜且具有風險
2.6.3.3.3. 可以利用HSM或TPM來提供與硬體關聯的裝置證書，這種方案比直接將憑證“燒製”到裝置映象中稍好
2.6.3.3.4. 但過度依賴TPM來實現裝置證書的簽發仍然不是最理想的方案
2.6.3.3.5. 特別是需要兼顧雲端系統的部署時，其侷限性就很明顯了
2.6.4. 授權因子
2.6.4.1. 映象中的金鑰（或TPM中註冊的金鑰）
2.6.4.2. 正確的IP地址
2.6.4.3. 合法的TOTP（透過資源管理器生成）
2.6.4.4. 匹配的證書屬性（如匹配的證書CN）
2.6.5. 一種較好的方式是綜合利用資源管理器和可信安全映象，將通用的認證憑證“燒製”到裝置映象中（或註冊TPM金鑰），並將其用於終端和簽名服務之間的安全通訊傳輸
2.6.5.1. 攻擊者無法訪問待部署的主機，頂多對可用性進行一些攻擊
2.6.5.2. 即便裝置映象被盜用也無法完成證書請求，因為資源管理器會進一步驗證映象部署的主機以及簽名請求的其他屬性
3. X.509
3.1. X.509是當之無愧的裝置身份和認證方面的重要標準
3.1.1. 它定義了公鑰證書、吊銷列表的證書格式和驗證證書鏈的方法
3.1.2. X.509證書的首要作用是證明身份
3.2. X.509的強大之處在於，其使用的公私鑰對除了用於裝置身份認證，還提供了一種用於裝置初始安全通訊的可靠機制
3.2.1. 這也是X.509對網際網路安全非常有價值的眾多原因之一
3.3. 證書鏈及證書認證機構
3.3.1. 要使證書具備足夠的意義，對其建立信任是至關重要的
3.3.2. 任何人都可以簽發證書，只是擁有一個匹配的CN名稱證書並不意味著什麼，證書必須經由可信機構進行數字簽名才能具備有效性，才是可信的
3.3.3. 沒有“真實”簽名的證書被稱為自簽名證書，通常用於測試
3.3.4. 證書序號產生器構（一般可由證書籤發機構充當或委派）負責對證書的詳細資訊進行確認，只有確認過的證書資訊才能被簽名
3.3.5. 如果簽發的證書具備一定的屬性，還可以用於簽發下一級證書，從而形成信任鏈，顯而易見，這個信任鏈的根就是證書認證機構
3.3.6. 透過信任CA，我們間接信任了其簽發的所有證書的有效性
3.3.7. 透過實現分發少量公鑰（CA公鑰），所有從這個CA簽發的證書都包含了到上級簽發證書的連結，從而可驗證其有效性和合法性
3.4. 公鑰加密或非對稱加密
3.4.1. 非對稱加密運算代價極大，不適合用於大塊資料加密
3.4.2. 透過使用公鑰和私鑰兩個金鑰可以完成身份證明/認證
3.4.3. 公鑰是可公開分發的，而私鑰由證書的所有者安全持有
3.4.4. 使用私鑰加密一小段資料，則這段資料只能透過對應的公鑰進行解密，從而證明證書所有者確實持有證書私鑰
3.4.5. 在大多數場景下，這個金鑰對採用RSA金鑰對
3.5. 裝置身份
3.5.1. 主體（Subject），這個欄位用於描述證書的所有者，在裝置認證的場景下，這個所有者就是裝置（或主機）
3.5.2. 通常情況下，組織（Organization, O）和組織機構（Organizational Unit, OU）欄位的含義與字面意思一致
3.5.2.1. O欄位用於表示環境
3.5.2.2. OU欄位用於表示主機的角色
3.5.3. 證書是經過簽名的，可被信任，所以這些資訊可以安全地用於授權判定
3.5.4. 作為授權客體的伺服器明確地知道其應該被授權給哪些主體
3.6. 私鑰儲存
3.6.1. 如果私鑰被攻破，那麼裝置的身份和隱私也會受到威脅
3.6.1.1. 私鑰被攻破的情況是一種糟糕的場景，應該不惜一切代價進行規避
3.6.2. 可以在儲存私鑰時對其進行加密，使用私鑰的時候需要提供加密口令進行解密
3.6.2.1. 使用口令對私鑰進行加密僅適用於面向使用者的裝置
3.6.2.2. 在資料中心場景，這種方案並不奏效，因為解密私鑰需要口令並考慮其安全儲存，或透過某種安全機制傳輸金鑰口令到伺服器，這樣一來，保證口令的安全變得和保護私鑰一樣重要
3.6.3. 硬體安全模組（HSM）
3.6.3.1. 可以透過硬體生成金鑰對並且將私鑰儲存在安全儲存區內，安全儲存區的私鑰是禁止直接讀取的，只能透過HSM提供的介面請求其使用私鑰來進行指定的運算
3.6.3.2. 這種基於硬體安全儲存的私鑰保護機制非常安全，不易被盜
3.7. 裝置認證
3.7.1. 在零信任網路中，將X.509證書用於裝置認證至關重要，它是證明裝置身份的基石，其在建立端到端加密的過程中也不可或缺
3.7.2. 零信任網路的每個裝置都應該擁有X.509證書
3.7.2.1. 這個方案的核心是私鑰，私鑰是基於軟體的，如果被盜，那麼整個裝置認證體系將成為無本之木
3.7.3. 裝置證書通常用於真正的裝置認證的代理
3.7.3.1. 金鑰如此之長，不可能將其寫下來或記住
3.7.3.2. 金鑰可以被下載和安裝，因此，一般不由使用者隨身攜帶，在裝置認證的場景中，金鑰應該始終和裝置在一起
3.7.4. 透過使用TPM可以將私鑰和硬體進行繫結並安全儲存，從而有望徹底地解決私鑰的安全問題
4. TPM
4.1. 可信平臺模組（TPM）是一種嵌入到計算裝置中的特殊晶片
4.1.1. 這種晶片一般稱為加密處理器，用於以可信和安全的方式進行密碼運算
4.1.2. 一般包含自己的韌體，可以將其視作一種特殊的微控制器
4.1.3. 有助於實現一種小巧而精簡的硬體API，並且可輕鬆稽核和分析潛在的系統漏洞
4.1.3.1. 可以避免暴露過多介面以及直接對私鑰的讀取
4.1.3.2. 即便是作業系統，也無從獲取安全金鑰
4.1.4. 安全金鑰和硬體緊密繫結
4.1.4.1. 在零信任安全中，透過TPM實現裝置認證是一個極佳的實踐
4.2. 使用TPM加密資料
4.2.1. TPM生成並儲存所謂的儲存根金鑰（Storage Root Key, SRK），這個金鑰對代表了TPM裝置的信任根
4.2.2. 為了有效利用TPM進行批次資料加密，必須設法減少SRK直接保護的資料量
4.2.3. 方案是生成一個隨機加密金鑰，將其用作對稱加密演算法（如AES）的加密金鑰，並採用這類高效能演算法對塊資料進行加密，這個隨機加密金鑰可以使用SRK進行加密保護
4.3. 中間金鑰和密碼短語
4.3.1. 很多TPM庫（如TrouSerS）在加密資料時會使用中間金鑰
4.3.1.1. 要求TPM建立一個全新的非對稱金鑰對，使用公鑰對AES金鑰進行加密，然後使用SRK對私鑰進行加密
4.3.1.2. 解密資料時，首先透過TPM解密中間金鑰的私鑰，並用它解密AES金鑰，然後再使用AES金鑰解密原始資料
4.3.2. 增加一級額外的中間金鑰有利於加密資料的靈活分發
4.3.2.1. 如果僅僅為了滿足“金鑰只能透過相應的裝置進行解密”這一目標，則並不需要採用中間金鑰方案
4.3.3. SRK和中間金鑰都支援加密短語，因此中間金鑰可以允許使用額外的加密短語
4.4. 基於TPM的安全儲存機制的一個作用在於保護裝置X.509證書的私鑰
4.4.1. 安全金鑰是裝置身份證明的權威信任根，如果其被盜用，那麼裝置身份事實上也被盜用了
4.4.2. 使用TPM對私鑰進行加密，意味著雖然仍有可能從磁碟獲取私鑰，但是一旦離開當前裝置，這個私鑰就不能解密和恢復使用
4.4.3. 金鑰盜用仍然存在可能性
4.4.3.1. 方案只能防止攻擊者直接從磁碟讀取金鑰
4.4.3.2. 無法避免攻擊者提權後直接從記憶體讀取解密後的金鑰
4.4.3.3. 攻擊者甚至可能呼叫TPM的介面直接進行加解密操作
4.5. 平臺配置暫存器
4.5.2. 是TPM的重要特性之一
4.5.3. 提供多個儲存插槽，可以用於存放執行軟體的雜湊值
4.5.4. PCR最開始存放的是BIOS的雜湊值，緊隨其後的是引導記錄，然後是對應的配置資訊，諸如此類
4.5.4.1. 這些雜湊值序列可以用於證明系統的配置或狀態是合法的
4.5.5. 資料“封印”
4.5.5.1. 可以確保只允許經過授權的軟體配置解密資料，這可以透過在使用TPM加密資料時，傳遞一組已知的PCR資料值作為引數來實現
4.5.5.2. 被“封印”的資料只能透過封印它的TPM進行解密，並且解密時PCR的取值必須匹配
4.5.5.3. 由於PCR的取值無法修改或回滾，因此可以使用TPM“封印”技術確保加密資料不僅僅繫結到當前裝置，還能繫結到特定的軟體配置和版本
4.5.5.4. 可以有效地防止攻擊者透過裝置訪問許可權來獲取私鑰，因為只有未被修改的軟體才能解鎖這些資料
4.6. 遠端認證
4.6.1. 資料一旦離開物理TPM的安全儲存區域，其安全性將無法保證，仍然可能被盜用
4.6.2. 一旦透過TPM對加密資料進行解鎖/解密，原本在TPM中安全存放的私鑰就被暴露了
4.6.3. TPM還提供了另外一種唯一標識其身份的方法，就是被稱為背書金鑰（Endorsement Key,EK）的金鑰對
4.6.3.1. 每個TPM都有唯一的金鑰對
4.6.3.2. EK的私鑰僅存在於TPM內，因此即便是作業系統也無法對其進行訪問
4.6.4. 遠端認證時，TPM生成一個稱為“引用”，然後將其安全地傳輸至遠端系統
4.6.4.1. 這個“引用”包含了當前的PCR取值列表，並且使用EK進行簽名
4.6.4.2. 遠端系統可以透過這些資訊對主機身份（因為EK對於每個TPM都是唯一的）和對應的軟體狀態/配置（因為PCR的取值不能被修改）進行確證
4.7. 用於認證的金鑰僅能夠簽署源自於TPM的資料，這種侷限顯然無法支援類似TLS之類的傳輸加密協議
4.7.1. 流行的IKE守護程序strongSwan使得TPM不僅僅可以用於認證IPSec連線，還能透過對PCR資料的使用實現授權，確保發起連線的主機所執行的軟體是準確且未被篡改過的
4.8. 對於一個成熟的零信任網路，使用TPM進行強裝置認證是理想選擇，它完美地實現了軟體身份和物理硬體之間的聯結
4.8.1. 目前TPM虛擬化技術已有可用的實現（如用於Xen系統的vTPM），但信任仍然必須植根於硬體TPM
4.8.2. 設計一套可熱遷移的基於TPM的安全系統具有極大的挑戰性
4.8.3. 雖然在成熟的零信任網路中建議採用TPM作為裝置認證的手段，但不應該將其視為強制需求， TPM的大幅採用並不容易，在零信任架構的採用和遷移方面可以考慮一些其他的折中方案
5. 基於硬體的零信任附件
5.1. 在零信任網路中，支援傳統裝置的常用方案是採用認證代理
5.2. 認證代理終止與零信任相關的邏輯和操作，並將連線轉發至傳統主機
5.3. 可以透過一些專用硬體來實現類似功能，這些專用硬體裝置作為零信任附件裝置，攜帶一枚TPM晶片，可以直接插入傳統裝置的乙太網埠