本文上次更新於 2024 年 5 月，內容反映截至撰文時的情況。我們會持續改善保護客戶的方式，因此 Google 的安全性政策和系統未來可能會改變。
本文說明 Google 驗證資料中心機器的做法。本文所述架構旨在與開放式標準整合，例如信任平台模組 (TPM)、安全通訊協定和資料模型 (SPDM) 和Redfish。如要查看 Google 提議的資料中心機器認證相關新標準或參考實作方式，請參閱 GitHub 上的 Platform Integrity (PINT) 專案。本文適用於安全主管、安全架構師和稽核人員。
總覽
Google 越來越常設計及部署分離式資料中心機器。許多機器都包含個別的信任根，包括測量 (RTM)、儲存、更新和復原的信任根，而非單一信任根。每個 RTM 負責處理整個機器的其中一個子區塊。舉例來說，某部機器可能有一個 RTM，用於測量及驗證在主要 CPU 上啟動的項目，另一個 RTM 則用於測量及驗證在插入 PCIe 插槽的 SmartNIC 上啟動的項目。下圖顯示範例機器。
機器中的多個 RTM 複雜度，會增加資料中心機器的龐大規模和期望，以及因人為、硬體或軟體故障而可能發生的許多併發症。總而言之，確保機群的韌體完整性是一項不簡單的任務。
本文所述的系統旨在讓分散式機器的遠端認證問題更容易管理。這項認證基礎架構可擴充，因此能適應資料中心中越來越複雜的機器。
我們希望透過分享這項工作，提供大規模執行非聚合式機器認證的觀點。我們與業界合作夥伴攜手，並為 Distributed Management Task Force (DMTF)、Trusted Computing Group (TCG) 和 Open Compute Project (OCP) 等標準機構貢獻心力，持續支援這個領域的安全創新。
建議使用的 RTM 屬性
本節將介紹建議用於 RTM 的一些屬性。
RTM 硬體整合
處理器與 RTM 配對時，RTM 應擷取在該處理器上執行的第一個可變動程式碼的測量結果。後續可變動的程式碼應先擷取測量結果並回報給信任根，再執行程式碼。這種安排方式會產生測量啟動鏈，可對處理器的安全關鍵狀態進行穩健的認證。
RTM 硬體和韌體身分認證
每個 RTM 都應有一組簽署金鑰，用於發出認證以供外部驗證。這個金鑰組的憑證鏈結應包含 RTM 專屬硬體 ID 的密碼編譯證據，以及 RTM 內執行的任何可變動程式碼的韌體 ID。憑證鏈結應以 RTM 製造商為根。這種做法可讓電腦從嚴重的 RTM 韌體安全漏洞中復原。
裝置 ID 組合引擎 (DICE) 規格是我們認證解決方案所用模式的正式化版本。RTM 製造商會認證一組專屬裝置金鑰，這組金鑰會認證一組別名金鑰，該金鑰專屬於 RTM 的硬體 ID 和韌體映像檔。別名金鑰憑證鏈結包含 RTM 韌體的測量結果和 RTM 的序號。驗證者可以確信，由特定別名金鑰簽署的任何資料，都是由加密硬體和韌體身分識別測量值所描述的 RTM 發出，而這些測量值會嵌入該別名金鑰的憑證鏈結中。
遠端認證作業
認證機制旨在確保使用者資料和工作只發給執行預期啟動堆疊的機器，同時允許大規模進行機群維護自動化作業，以解決問題。這項作業排程服務託管於內部雲端，可對機器內的 RTM 集合提出質詢，並將產生的認證測量結果與該機器的專屬政策進行比較。只有在經過認證的測量結果符合機器的政策時，排程器才會將工作和使用者資料發送至機器。
遠端認證包含下列兩項作業：
產生認證政策，這會在電腦的預期硬體或軟體變更時發生。
認證驗證：在機器管理流程中，系統會在特定時間點進行驗證。其中一個時間點是機器排定工作前不久。通過認證驗證後，機器才能存取工作和使用者資料。
認證政策
Google 會使用簽署的機器可讀文件 (稱為「政策」)，說明電腦中預期執行的硬體和軟體。這項政策可由電腦收集 RTM 進行認證。政策會顯示每項 RTM 的下列詳細資料：
- 可驗證 RTM 發出的認證的信任身分根憑證。
- 全域不重複的硬體 ID，可明確識別 RTM。
- 描述 RTM 應執行的預期版本的韌體身分。
- RTM 回報的每個啟動階段的評估期望。
- RTM 的 ID，類似於 Redfish 資源名稱。
- 將 RTM 連結至機器內實體位置的 ID。這個 ID 類似於 Redfish 資源名稱，用於自動化機器維修系統。
此外，這項政策也包含全球唯一的撤銷序號，有助於防止未經授權的政策復原作業。下圖顯示政策。
下圖顯示政策中的下列項目：
- 簽章可提供政策驗證。
- 撤銷序號可確保政策為最新版本，避免回溯。
- RTM 期望值會列舉機器中每個 RTM 的詳細資料。
下列各節將詳細說明這些項目。
政策組合
組裝或維修機器硬體時，系統會建立硬體模型，定義該機器上預期的 RTM。控制平面可確保這項資訊在維修 (包括零件更換或硬體升級) 等事件中保持最新狀態。
此外，控制平面會維護一組預期安裝在機器上的軟體，以及預期哪些 RTM 應測量哪些軟體。控制平面會使用這些期望值和硬體模型，產生已簽署且可撤銷的認證政策，說明機器的預期狀態。
簽署的政策隨後會寫入其描述的機器上的永久儲存空間。這個方法有助於減少遠端驗證器在驗證機器時所需的網路和服務依附元件數量。驗證者可以從機器本身擷取政策，而不必查詢資料庫。這項做法是重要的設計功能，因為作業排程器有嚴格的服務等級目標規定，且必須維持高可用性。減少這些機器對其他服務的網路依附元件，有助於降低服務中斷的風險。下圖顯示事件流程。
下圖說明控制平面在政策組裝程序中完成的下列步驟：
- 根據軟體套件指派作業和電腦硬體型號衍生認證政策。
- 簽署政策。
- 將政策儲存在資料中心電腦上。
政策撤銷
特定機器的硬體和軟體意圖會隨時間改變。意圖變更時，必須撤銷舊政策。每項簽署的認證政策都包含專屬的撤銷序號。驗證者會取得適當的公開金鑰來驗證已簽署的政策，並取得適當的憑證撤銷清單，確保政策仍然有效。
以互動方式查詢金鑰伺服器或撤銷資料庫，會影響工作排程器的可用性。Google 採用非同步模型，用於驗證已簽署認證政策的公開金鑰集，會推送為每部機器的基本作業系統映像檔。CRL 會透過非同步方式推送，使用的集中式撤銷部署系統與 Google 用於其他憑證類型的系統相同。這個系統在正常情況下運作可靠，而且能在事件應變期間快速推送緊急更新。
驗證者可使用儲存在本機電腦上的驗證公開金鑰和 CRL 檔案，驗證遠端電腦的認證陳述式，而不需要在重要路徑中使用任何外部服務。
擷取認證政策並驗證測量結果
遠端認證機器的程序包含下列階段：
- 擷取及驗證認證政策。
- 從機器的 RTM 取得經過認證的評估結果。
- 根據政策評估認證的測量結果。
下圖和各節將進一步說明這些階段。
擷取及驗證認證政策
遠端驗證者會擷取機器的簽署認證政策。如政策組裝一文所述，基於可用性考量，政策會以簽署文件的形式儲存在目標電腦上。
為驗證傳回的政策是否為真，遠端驗證器會參考驗證器相關 CRL 的本機副本。這項動作可確保擷取的政策是由受信任的實體以密碼編譯方式簽署，且政策未遭撤銷。
取得經過認證的測量結果
遠端驗證器會對機器提出質疑，要求從每個 RTM 取得測量結果。驗證者會在這些要求中加入加密隨機數，確保要求是最新狀態。機器上的實體 (例如基板管理控制器 (BMC)) 會將每個要求傳送至各自的 RTM，收集簽署的回應，然後傳回給遠端驗證者。從認證角度來看，這個裝置上的實體沒有權限，因為它只做為 RTM 簽署的評估結果傳輸管道。
Google 會使用內部 API 來驗證評估結果。我們也為 Redfish 貢獻了強化功能，讓機器外的驗證者能使用 SPDM，向 BMC 質疑 RTM 的測量結果。內部機器路由作業是透過實作專屬的通訊協定和管道完成，包括：
- 透過子網路使用 Redfish
- 智慧型平台管理介面 (IPMI)
- 透過 i2c/i3c 的管理元件傳輸通訊協定 (MCTP)
- PCIe
- 序列周邊介面 (SPI)
- USB
評估經過認證的測量結果
Google 的遠端驗證器會驗證每個 RTM 發出的簽章，確保這些簽章可追溯至機器認證政策中包含的 RTM 身分。系統會根據政策驗證 RTM 憑證鏈中的硬體和韌體身分，確保每個 RTM 都是正確的執行個體，並執行正確的韌體。為確保新鮮度，系統會檢查簽署的加密隨機數。最後，我們會評估認證的測量結果，確保符合該裝置的政策預期。
回應遠端認證結果
完成認證後，必須使用結果判斷受認證機器的命運。如圖所示，結果有兩種可能：驗證成功，機器會發出工作憑證和使用者資料；或是驗證失敗，並將警報傳送至維修基礎架構。
下列各節將進一步說明這些程序。
認證失敗
如果機器認證失敗，Google 就不會使用該機器提供客戶工作。系統不會傳送警報給使用者，而是傳送給維修基礎架構，嘗試自動重新映像處理電腦。雖然認證失敗可能是惡意行為所致，但大多數認證失敗都是因為軟體推出時發生錯誤。因此，如果推出作業的認證失敗率不斷上升，系統會自動停止作業，避免更多電腦無法通過認證。發生這類事件時，系統會傳送快訊給 SRE。如果自動重設映像檔無法修復電腦，系統會復原推出作業，或推出修復後的軟體。在機器再次成功完成遠端認證前，不會用於處理客戶工作。
認證成功
如果機器的遠端認證成功，Google 就會使用該機器提供生產作業服務，例如為 Google Cloud 客戶提供 VM，或是為 Google 相簿處理圖片。Google 規定，涉及網路服務的有意義工作動作，必須透過短期 LOAS 工作憑證才能執行。成功通過認證挑戰後，系統會透過安全連線授予這些憑證，並提供工作所需的權限。如要進一步瞭解這些憑證，請參閱「應用程式層傳輸安全標準」。
軟體認證的品質取決於建構該軟體的基礎架構。為確保產生的構件能準確反映我們的意圖，我們投入了大量資源，確保建構管道的完整性。如要進一步瞭解 Google 提議的標準，以解決軟體供應鏈完整性和真實性問題，請參閱「軟體供應鏈完整性」。
後續步驟
瞭解 BeyondProd 如何協助 Google 資料中心機器建立安全連線。