本文上次更新於 2024 年 6 月，內容反映截至撰文時的情況。我們會持續改善保護客戶的方式，因此 Google 的安全性政策和系統未來可能會改變。
Google 經營全球規模的多元租戶分散式運算基礎架構，為全球數十億人提供產品和服務。這項基礎架構必須兼顧安全性、可靠性、復原能力、效率、開發速度、可偵錯性等相互競爭的優先事項。
本文說明我們用來維護業界領先安全狀態的部分機制，確保在 Google 生產環境中執行的服務安全無虞。這些服務涵蓋各種安全敏感度，從無法存取任何敏感資料的開發實驗，到重要的身分識別基礎架構都有。這些服務可完成處理使用者資料、管理軟體推出作業，以及為個別實體機器佈建和管理生命週期等工作。
本文說明有助於保護基礎架構下列三個重要層級的安全控管措施：
- 生產服務，包括最攸關安全性的服務 (也稱為基礎服務)
- 生產機器
- 正式版工作負載
我們採用這些控管措施，確保 Google 員工只能基於正當的業務目的 (例如維護存取權) 存取服務、機器和工作負載，並防範內部風險和員工帳戶遭盜用。這些控制項可提供更深入的防禦機制，做為現有基礎架構安全控制項的補充，協助防止帳戶遭到入侵。
持續改善
本文所述的控制項會用於 Google 的整個正式環境。許多服務 (包括基礎服務) 都採用我們提供的最新控管機制。不過，由於 Google 基礎架構的範圍和複雜度，個別生產服務通常有獨特需求，可能需要額外時間才能實作最新建議。Google 的網站可靠性工程 (SRE) 和安全團隊秉持持續改善的文化，不斷調整安全控管措施，因應不斷變化的威脅情勢。
保護實際工作環境服務
Google 會協助保護正式作業服務的完整性，確保 Google 人員只能基於正當業務目的 (例如維護) 存取服務。如要存取實際工作環境中執行的服務，主要有兩種方式：透過管理存取權和透過軟體供應鏈。
下表說明有助於保護各存取路徑的控制項。
管理存取權控管：生產服務需要定期維護 (例如二進位檔或設定發布)。在 Google，我們的目標是透過自動化、安全 Proxy 或經過稽核的緊急存取作業，遵循「零接觸式生產」哲學完成這類作業。這套控制項可移除人員對正式作業環境資產的存取權，稱為「無人員 (NoPe)」。NoPe 可讓 Google 彈性部署存取權控管機制，這些機制會根據正式版服務的敏感程度，以及服務是否已準備好透過持續改善來達到更強大的狀態而定。
舉例來說，Google 不允許單方面存取基礎服務，即使是緊急存取權，也必須獲得其他 Google 員工核准。如果使用者不需獲得其他授權人員的核准，即可執行存取作業，則該存取作業為單方面。
軟體供應鏈控管措施：Google 的大多數實際工作環境工作負載 (包括基礎服務)，都會執行可驗證的二進位檔和工作設定，這些項目是從位於可信來源的同儕審查程式碼建構而來。我們使用 Borg 適用的二進位授權 (BAB) 強制執行這項程序。
下圖顯示有助於保護正式版服務的控制項。
我們採用最高等級的 NoPe 和 BAB，確保即使在緊急情況下，任何人員都無法單方面存取基礎服務，且獲得的任何特殊存取權都有明確的範圍和期限。高權限存取權是授予人員的進階存取權，可在自動化無法解決的特殊情況下，管理重要生產服務。我們對這項規則做出例外處理，確保 Google 有辦法擺脫鎖定狀態。
許多其他生產服務 (包括 Filestore 或 Cloud SQL 等產品，以及 Borg 和 Spanner 等內部基礎架構產品) 都已設定為使用最高層級的 NoPe 和 BAB，我們也不斷努力，讓生產服務擁有者能隨著時間推移，更輕鬆地採用 NoPe 和 BAB。
管理員存取權控管
在 Borg 中，具備生產角色的成員可以讀取、寫入或刪除生產角色擁有的資料，並使用該角色的授權執行程式碼。生產角色是一種身分，可在 Google 的生產環境中執行工作負載。
永久擔任製作角色成員可能會對製作造成意料之外的後果，且這些權限可能遭到濫用。不過，SRE 的任務要求團隊有權維護自己負責的服務，因此完全移除存取權可能不是可行的策略。
NoPe 套件提供設定存取權的方法，可平衡團隊授權和確保生產系統安全這兩項相互競爭的需求。啟用 NoPe 後，Google 員工嘗試存取正式版服務時，帳戶權限會受到限制。NoPe 允許下列限制：
- 存取要求必須獲得核准者同意，並附上理由：這項稱為多方授權 (MPA) 的控制項可確保 Google 員工必須附上業務理由，並獲得有權驗證存取要求的其他人員核准，才能存取生產服務。
- 無法直接存取正式作業服務角色：人員只能透過 NoPe 的安全 Proxy 存取正式作業服務。安全 Proxy 的設計宗旨是只允許執行一組明確定義的指令。如果 Google 安全性和 SRE 機構認為指令有風險 (例如關閉服務，或是存取或刪除資料)，也需要 MPA。
- 沒有永久的製作角色成員資格：這項稱為「隨選存取權 (AoD)」的控制項，要求人員申請臨時成員資格，而不是允許人員帳戶一律擁有存取權。這項控制項可確保只有在特定情況下，才會暫時授予提升的權限。
- 監控人員對正式版服務的存取要求：Google 會定期稽核正式版服務執行角色存取模式，稽核的目標是持續改善管理 API，日後不必再提出這類要求。只有在緊急應變情況下，才應存取正式環境服務。對於基礎服務，授予存取權的情況非常少，因此安全團隊會稽核每項授予的存取權，確認其有效性。
以下各節將詳細說明各項控制項。
NoPe 的多方授權
多方核准程序需要其他授權的 Google 人員核准存取要求。
如果要求存取高度敏感的服務，MPA 也會要求人員在每次提出要求時，提供業務理由並說明目前發生生產緊急狀況。
這兩項條件都能防止濫用存取權。
NoPe 的安全 Proxy
安全 Proxy 是一組工具，可公開預先定義的指令集，讓安全 Proxy 代表呼叫端執行。安全 Proxy 會實作精細的規則式授權政策，對生產服務的存取權設下限制。舉例來說，這些政策可能會規定，執行可能對安全性或穩定性造成負面影響的指令 (例如刪除檔案的指令) 時，必須先獲得其他授權人員核准。政策也可以允許執行特定安全指令 (例如列出資源用量的指令)，不必經過核准。這種彈性對於減少作業手動作業至關重要。
如果發生濫用存取權的情況，帳戶仍會受到安全 Proxy 允許的作業限制。帳戶只能單方面執行安全指令，但執行具備權限的作業時，必須獲得其他授權人員核准。所有作業都會留下清楚的稽核記錄。
如要進一步瞭解安全 Proxy，請參閱SREcon 簡報，瞭解零接觸式生產。零接觸式生產是一套原則和工具，可確保生產環境中的所有變更都透過自動化方式執行 (不涉及人員)、由軟體預先驗證，或使用經過稽核的緊急應變機制進行。
隨選觀看
Google 可透過隨選存取 (AoD) 功能，以符合資格的成員資格取代永久成員資格，藉此減少人員權限。
符合資格的角色成員無法存取權限。如果符合資格的角色成員需要存取權，可以要求臨時成員資格，也就是 AoD 授權。如果獲得其他授權人員核准，AoD 授權會讓要求者在一段時間內成為該角色的成員，通常不到一天。
符合資格的成員模式可讓人員在需要時，僅要求存取所需的子集。從概念上來說，您可以將 AoD 視為受時間限制的製作 sudo，類似於 Unix 中的 sudo -u 指令，可讓您執行與指定使用者相關聯的提升權限指令。不過，與 Unix sudo 不同的是，接收 AoD 授權需要業務正當理由和 MPA，並會留下稽核記錄。AoD 補助金也有時間限制。
為符合資格的會員方案提供機密權限，可確保即使發生存取權濫用等罕見情況，帳戶也只能在有效授權期間存取這些權限。採用安全 Proxy 後，這類授權需求將大幅減少。
存取要求監控
雖然 Google 生產環境的許多領域都使用 NoPe 做為減少存取權的做法，但對於最敏感的生產環境角色，AoD 授權極為罕見，僅保留用於緊急應變。此外，每個事件都會觸發事後手動稽核。稽核的目標是減少日後授予 AoD 的頻率 (例如，使用這些事件來促使改善管理 API)。
Google 會持續監控全公司 AoD 授權的授予情形，以及持有這些授權時執行的動作。我們會使用即時監控資料偵測潛在的安全性缺口，並找出可進一步減少存取權的區域。如果發生事件，稽核記錄可協助您快速應變。
Borg 適用的二進位授權
正如 NoPe 有助於保護具備特殊權限的存取路徑，Borg 適用的二進位授權 (BAB) 有助於保護 Google 軟體供應鏈。BAB 可確保生產軟體和工作設定在部署前經過審查和核准，特別是可存取私密資料時。BAB 最初是為 Google 的生產基礎架構所設計，現在已納入開放規格，稱為軟體構件供應鏈級別 (SLSA)。
BAB 可確保人員無法在未經同儕審查的情況下修改原始碼、執行二進位檔或設定工作，且任何二進位構件或軟體設定都是以經過同儕審查的簽入原始碼建構而成，可供驗證。
詳情請參閱「Borg 適用的二進位授權」。
保護生產機器
除了強化具備特殊權限的存取路徑，以及維護軟體供應鏈的完整性之外，Google 也會保護執行生產服務的機器。具體來說，我們實作了下列項目：
Shell 存取控制項：大多數 Google 員工無法透過 Shell 存取 (例如透過 SSH) 實際工作環境機器，或在 Google 的叢集管理系統 Borg 上執行的工作負載。而是必須使用安全 Proxy，由另一位授權人員審查並核准每項指令，指令才會執行。
只有少數負責低階基礎架構的團隊，會保留非單向 Shell 存取權，以便在無法使用安全 Proxy 的情況下，偵錯最複雜的問題。如果存取權需要一或多名額外授權人員的授權，則為非單方面存取權。Google 例外情況：為確保 Google 有辦法擺脫鎖定狀態，允許單方面存取 Shell。
實體存取控制項：機器需要定期進行實體維護，才能維持良好運作。為確保資料中心技術人員僅在有正當業務理由的情況下存取實體機器，Google 採用實體到邏輯的控管機制。
韌體和系統軟體控制項：Google 會根據硬體信任根，實作測量開機安全流程。硬體信任根可協助確保每部機器的啟動韌體和系統軟體完整性。
下圖顯示有助於保護資料中心內機器的控制項。
Shell 存取權控管
SSH 是一種開放原始碼管理工具，可讓使用者廣泛存取 Linux 伺服器，因此廣受歡迎。如果沒有 SSH 存取權控管機制，擁有適當憑證的帳戶就能取得 Shell，以難以稽核的方式執行任意程式碼。
如果帳戶有權存取實際工作環境服務的殼層，就能變更執行中工作的行為、竊取憑證，或使用憑證在環境中取得持續立足點。
為降低這項風險，我們採用下列控制措施，以安全替代方法取代生產機器的 SSH 存取權：
- 窄版 API：對於工作流程明確定義，且先前需要 SSH 的團隊，我們以定義明確、可稽核的 API 取代 SSH。
- SSH 安全 Proxy：對於需要更彈性存取權的團隊，安全 Proxy 可個別授權及稽核指令。
- MPA：當 SRE 需要緊急 SSH 存取機器時，Google 會要求提供業務正當理由，並由授權人員核准存取權。系統會記錄完整的殼層工作階段轉錄稿。
- 鎖定情境：這是唯一允許單向 SSH 存取權的例外狀況。系統會記錄完整的殼層工作階段轉錄稿。
這些控制項可平衡正當 Shell 存取需求與過於廣泛的 Shell 存取權相關風險。
背景：Google 的 SSH
Google 過去使用 SSH 管理機器，Borg 的開發讓大多數 Google 員工不再需要直接存取執行二進位檔的 Linux 電腦，但基於下列原因，殼層存取權仍保留下來：
- 有時，人員需要直接存取電腦，以進行偵錯。
- SSH 存取權是瞭解各種抽象層的寶貴教學工具。
- 在非預期的災難復原情境中，可能無法使用較高層級的工具。
為了兼顧這些原因和所造成的安全風險，Google 逐步達成一系列里程碑，以消除 SSH 風險，然後停止使用。
集中監控和存取權控管里程碑
Google 投入資源開發中央 SSH 監控和授權系統，也就是以主機身分為依據的監控授權 (HIBA)。HIBA 可讓您掌握所有 SSH 使用情形，並強制執行嚴格的授權政策。系統會記錄 SSH 嘗試，不僅是目標電腦，連集中式 BeyondCorp Proxy 也會記錄。系統會記錄殼層執行的指令，並將這些指令提供給惡意行為偵測管道。不過，偵測本質上是被動的，容易遭到規避和混淆。
淘汰單向存取里程碑
對於大多數人員，Google 已移除殼層存取權 (例如透過 SSH) 至實際工作環境機器，或在 Borg 上執行的工作負載。不過，開發團隊仍可在測試機器上存取 (例如用於驗證新硬體或新低階軟體，但未執行實際工作環境服務的機器)。
Narrow API
部分 Google 團隊過去會使用 SSH 執行數量有限的精確定義指令 (例如在劇本中)，或取得結構可預測的資料，現在則使用定義明確的 API，這些 API 可滿足特定用途並提供結構化資料。
Narrow API 的方法數量不多，但與常見的使用者歷程一致，且會隱藏低層級的存取詳細資料。因此，這類解決方案是 Google 的首選，因為可提供最佳安全性和可稽核性。這些 API 是以 Google 的遠端程序呼叫 (RPC) 基礎架構為基礎建構而成，因此可享有數十年來在安全性和稽核方面投入的資源。
安全殼層 (SSH) 的安全 Proxy
部分 Google 團隊無法事先判斷可能需要的指令。在這種情況下，Google 會使用指令執行精靈，只接受由安全團隊執行的受信任 Proxy 傳送的任意指令執行要求。這項技術與 NoPe 安全 Proxy 使用的技術類似。
SSH 安全 Proxy 負責對指令執行作業進行精細授權和稽核。授權依據為指令的引數和環境、速率限制參數、業務理由和 MPA。這個授權程序可根據團隊手冊和最佳做法，對可執行的指令設定任意精確的限制。如果發生現有劇本未涵蓋的意外故障狀況，人員仍可在其他授權人員核准後，執行必要的偵錯指令。
SSH 適用的 MPA
其餘負責低階基礎架構的少數團隊，則保留非單方面的殼層存取權，以偵錯最複雜的問題。
在鎖定情境中使用 SSH
Google 允許單方面 Shell 存取權的例外情況：確保 Google 可以解決鎖定情況。用於此目的的 SSH 金鑰是透過可稽核的獨立程序產生，並離線儲存在防竄改硬體中。使用這些金鑰時，系統會記錄完整的殼層工作階段轉錄稿。
實體存取權控管
Google 資料中心是伺服器、網路裝置和控制系統的複雜環境，需要各種角色和技能才能管理、維護及運作。
Google 會在機器上實作六層實體控管措施和許多邏輯控管措施，協助保護資料中心的工作負載。我們也會保護機器之間的空間，也就是所謂的「實體到邏輯」空間。
實體到邏輯控制項提供額外的防禦層，包括機器強化、以工作為基礎的存取權控管和系統自我防禦。實體到邏輯控制措施可防範意圖利用機器實體存取權，並將攻擊升級為機器工作負載邏輯攻擊的攻擊者。
詳情請參閱「Google 如何保護資料中心的實體空間和邏輯空間」。
韌體和系統軟體控制
資料中心機器的安全防護機制是在啟動時建立。機器的開機程序會設定機器硬體並初始化作業系統，同時確保機器安全無虞，可在 Google 的生產環境中執行。
在開機程序的每個步驟中，Google 都會導入業界領先的控制措施，協助強制執行預期的開機狀態，並確保客戶資料安全無虞。這些控管措施可確保機器啟動時使用預期軟體，讓我們移除可能危害機器初始安全狀態的漏洞。
詳情請參閱「Google 如何在正式環境機器上強制執行啟動完整性」。
保護工作負載
為配合零信任哲學，Google 也推出了控管機制，可協助防範不同安全需求的工作負載之間出現橫向移動威脅。Google 基礎架構使用稱為「工作負載安全環 (WSR)」的工作負載階層。WSR 可確保重要工作負載不會排定在與安全性較低工作負載相同的機器上，同時避免對資源用量造成負面影響。WSR 會將工作負載分組為四個機密程度類別 (基礎、機密、強化和未強化)，並嘗試在不同的機器集區中排定這些工作負載。
下圖顯示 WSR 如何在基礎、生產和開發機器上，將工作負載分組及排程。
WSR 可提供額外防護層，防範使用核心安全漏洞攻擊或 CPU 側通道攻擊，進行本機權限提升攻擊。WSR 可確保只有安全防護需求相似的工作負載，才會在同一部機器上共同排程。如要實作 WSR，請執行下列操作：
- 根據安全防護需求分類工作負載。每個類別都稱為「工作負載環」。
- 將實體機器分配到多個彼此隔離的機器集區。換句話說，我們消除了集區之間的橫向移動路徑。
- 套用排程限制，防止安全需求不同的工作負載在同一部機器上執行。這些排程限制可降低透過本機權限提升手法遭到入侵的風險。
舉例來說，WSR 要求基礎工作負載在專用機器上執行，且絕不會與非基礎工作負載共同排程。這項限制可有效隔離安全性較低的工作負載。
隔離工作負載的方法
現代系統軟體十分複雜，安全研究人員會定期發現本機權限提升漏洞，例如核心零時差攻擊或新型 CPU 側通道攻擊。WSR 最早於 USENIX ;login: 推出，可讓 Google 降低工作負載共置相關風險，同時維持高資源用量。
根據預設，Borg 會使用作業系統層級的程序界線來隔離容器。相較於使用硬體式虛擬化的虛擬機器，這些程序提供的隔離界線較弱。對於執行受信任工作負載的多租戶環境而言，這種較弱的隔離通常是效率與安全性之間良好的取捨。受信任的工作負載是指二進位檔和設定可驗證地建構自經過同儕審查的程式碼，且來源經過認證。受信任的工作負載不會處理任意不受信任的資料。 處理不受信任的資料包括代管第三方程式碼或編碼影片。
Google 使用 BAB 確保二進位檔值得信賴。不過，BAB 不足以確保處理不受信任資料的工作負載完整性。除了 BAB，這類工作負載也必須在沙箱中執行。沙箱是受限的環境，例如 gVisor，可讓二進位檔安全執行。BAB 和沙箱都有其限制。
BAB 是成熟產品的強大控制項，但在新系統開發初期，以及執行不含私密資料的實驗時 (例如，最佳化已公開資料的編碼)，可能會降低速度。這項限制表示部分工作負載必須一律在沒有 BAB 的情況下執行。這類工作負載本質上具有較高的本機權限提升風險 (例如，利用核心安全漏洞在機器上取得本機根存取權)。
將不受信任的工作負載放入沙箱，也能降低安全性風險，但會增加運算和記憶體用量。視工作負載和沙箱類型而定，效率可能會下降雙位數百分比。如要瞭解沙箱工作負載的效能影響，請參閱 gVisor 效能指南中的詳細基準測試。WSR 可讓我們解決因隔離工作負載而造成的效率限制。
工作負載環
Google 會根據工作負載的安全性需求，將其分為四個類別：基礎、機密、強化和未強化。下表會詳細說明這些屬性。
| 工作負載環 | 說明 |
|---|---|
| 基礎 | 對 Google 安全性至關重要的工作負載，例如身分與存取權管理服務。基礎工作負載的安全防護要求最高，通常會犧牲效率，以換取更高的安全性和可靠性。 |
| 機密 | 可能導致大範圍中斷的作業，或可存取產品專屬機密資料 (例如使用者或客戶資料) 的作業。 |
| 服務強化 | 支援非安全關鍵工作負載，但已採用 BAB 或經過沙箱化，因此對鄰近工作負載造成的風險很小。 |
| 未強化 | 所有其他工作負載，包括執行不受信任程式碼的工作負載。 |
在 Google，我們將支援特定產品的重要工作負載歸類為敏感工作負載，而基礎工作負載則可能影響所有產品。
與基礎和機密工作負載不同，我們可以完全根據工作負載採用的控制項和處理的輸入類型，將任何工作負載分類為強化型。對於強化的工作負載，我們主要擔心的是對其他工作負載的影響，因此強化解決方案可能包含沙箱。
機器集區
為避免將機密服務與較不受信任的工作負載 (例如處理不受信任的資料，但沒有沙箱) 共同排程，我們必須在獨立的機器集區中執行這些服務。機器隔離可讓您更輕鬆地瞭解安全不變量，但每個額外的機器集區都會在資源用量和可維護性方面造成取捨。
機器隔離會導致實體資源使用率降低，因為隨著我們新增更多集區，確保機器集區充分利用資源會變得更加困難。如果有多個大型獨立機器集區，效率成本可能會相當高。
由於每個集區中工作負載的資源用量會有所變動，因此嚴格隔離會增加管理負擔，需要定期重新平衡及重新指派集區之間的機器。重新平衡作業需要從機器排空所有工作負載、重新啟動機器，並執行最耗費資源的機器清除程序，確保韌體真實性和完整性。
這些考量因素表示，Google 實作的機器隔離機制必須提供方法，盡量提高實體資源的使用率，同時防範對手攻擊基礎和敏感工作負載。
在 Kubernetes 中，這種做法稱為「節點隔離」。Kubernetes 節點可對應至實體或虛擬機器。本文著重於實體機器。此外， Google Cloud Compute Engine 等產品提供單一用戶群，可隔離實體機器。
工作負載排程限制
Google 會將機器佈建到三種隔離集區：基礎機器、生產機器和開發機器。Google 營運多個獨立集區，用於代管基礎和機密工作負載，但為求簡潔，本文會將每個集區視為一個集區。
為提供最有效的保護，我們對 WSR 部署了下列排程限制：
- 基礎工作負載只能在基礎機器上執行。
- 敏感工作負載只能在正式環境機器上執行。
- 未強化的工作負載只能在開發機器上執行。
- 強化型工作負載可在正式版或開發機器上執行，但建議使用正式版機器。
下圖顯示排程限制。
在這張圖中，隔離界線會區隔機器集區之間和集區內的不同類別工作負載。基礎工作負載是專屬基礎機器的唯一租戶。針對在正式版電腦上執行的工作負載，進行二進位授權或沙箱化，有助於防止本機權限提升攻擊。在開發機器上，未強化的工作負載可能會危害其他工作負載，但由於強化的工作負載無法建立新工作，因此危害僅限於開發機器。
系統會根據可用性，在正式環境或開發機器上排程強化工作負載。允許在多個集區中排程可能違反直覺，但這是減輕排程限制導致使用率下降的必要措施。強化型工作負載可填補因隔離敏感和未強化的工作而產生的缺口。此外，硬體資源足跡越大，其他兩類資源的使用量波動就越能容納，不需要在環之間進行昂貴的機器移動。
下圖顯示不同類別工作負載的排程限制。強化型工作負載可位於生產或開發機器上。
Google 會將基礎工作負載隔離到多個基礎集區，以資源效率換取更高的安全性。所幸基礎工作負載的資源用量相對較小，因此一小群專屬機器對整體用量的影響微乎其微。不過，即使有大量的自動化機制，維護多個機器集區仍需要成本，因此我們不斷演進機器設計，以改善隔離效果。
WSR 強力保證非基礎工作負載絕不會在基礎機器上執行。基礎機器受到保護，可防範側向移動，因為只有基礎工作負載才能在這些機器上執行。
控制項摘要
Google 會在基礎架構中採用多項控管機制，協助保護正式環境服務、正式環境機器和工作負載。這些控制項包括：
- 實際工作環境服務的管理存取權控制項和 BAB
- 實際工作環境機器的 Shell 存取權控管、實體存取權控管，以及韌體和系統軟體控管
- 不同類別工作負載的 WSR
這些控制項會共同強制執行限制，協助保護 Google 使用者和客戶，以及他們的資料。下圖說明這些控制項如何共同運作，以支援 Google 的安全防護。
後續步驟
- 如要進一步瞭解 Google 基礎架構的安全控管措施，請參閱Google 基礎架構安全防護設計總覽。
- 如要瞭解 Google 安全文化，請參閱《打造安全可靠的系統 (O'Reilly 書籍)》。
- 如要進一步瞭解零接觸生產，請參閱 SREcon 簡報。