Google 如何保護生產服務

本文上次更新於 2026 年 6 月，內容反映截至撰文時的情況。我們會持續改善保護客戶的方式，因此 Google 的安全性政策和系統未來可能會改變。

Google 經營全球規模的多元租戶分散式運算基礎架構，為全球數十億人提供產品和服務。這項基礎架構必須兼顧安全性、可靠性、韌性、效率、開發速度、可偵錯性等相互競爭的優先事項。

本文說明我們用來維護服務的機制，確保服務在 Google 生產環境中運作時，能維持業界領先的安全狀態。這些服務涵蓋各種安全敏感度，從無法存取任何機密資料的開發實驗，到重要的身分識別基礎架構都有。這些服務可完成處理使用者資料、管理軟體推出作業，以及為個別實體機器佈建和管理生命週期等工作。

本文說明有助於保護基礎架構以下三個主要層級的安全控管措施：

  • 生產服務，包括安全性最關鍵的服務 (也稱為基礎服務)
  • 生產機器
  • 正式環境工作負載

我們採用這些控管措施，確保 Google 員工只能基於正當的業務目的 (例如維護存取權) 存取服務、機器和工作負載，並防範內部風險和員工帳戶遭盜用。這些控制項可提供更深入的防禦保護，做為現有基礎架構安全控制項的補充，有助於防止帳戶遭到入侵。

持續改善

本文所述的控制項會用於 Google 的整個正式環境。許多服務 (包括基礎服務) 都使用我們提供的最新控管機制。不過，由於 Google 基礎架構的範圍和複雜度，個別生產服務通常有獨特的需求，可能需要額外時間才能實作最新建議。Google 的網站可靠性工程 (SRE) 和安全團隊秉持持續改善的文化，不斷調整安全控管措施，因應不斷變化的威脅情勢。

保護正式版服務

Google 會保護正式作業服務的完整性，確保 Google 人員只能基於正當業務目的 (例如維護) 存取服務。如要存取在正式環境中執行的服務，主要有兩種方式：透過管理存取權和透過軟體供應鏈。

下表說明有助於保護各存取路徑的控制項。

  • 管理存取權控管：實際執行環境中的服務需要定期維護 (例如二進位檔或設定發布)。在 Google，我們的目標是透過自動化、安全 Proxy 或經過稽核的緊急存取作業，遵循「零接觸式生產」哲學完成這類作業。這套控制項可移除人員對正式作業環境資產的存取權，稱為「無人員」(No Persons，簡稱 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 的多方授權

MPA 必須由其他授權的 Google 人員核准存取要求。

如果要求存取高度敏感的服務，MPA 也會要求人員在每次提出要求時，提供業務理由並說明目前發生生產緊急狀況。

這兩項條件都能防止濫用存取權。

NoPe 的安全 Proxy

安全 Proxy 是一組工具，可公開預先定義的指令集，安全 Proxy 可代表呼叫端執行這些指令。安全 Proxy 會實作精細的授權政策，並以規則為基礎，對生產服務的存取權設下限制。舉例來說，這些政策可要求其他授權人員核准，才能執行可能對安全性或可靠性造成負面影響的指令 (例如刪除檔案的指令)。政策也可以允許執行特定安全指令 (例如列出資源用量的指令)，不必經過核准。這項彈性對於減少營運負擔至關重要。

如果發生濫用存取權的情況，帳戶仍會受到安全 Proxy 允許的作業限制。該帳戶只能單方面執行安全指令，但如要執行具備特殊權限的作業，則須獲得其他授權人員核准。所有作業都會留下清楚的稽核記錄。

如要進一步瞭解安全 Proxy，請參閱 SREcon 簡報，瞭解零接觸式生產和案例研究：安全 Proxy。零接觸式生產是一套原則和工具，可確保生產環境中的所有變更都由自動化程序執行 (不涉及人為作業)、由軟體預先驗證，或使用經過稽核的緊急應變機制進行。

隨選存取

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，以難以稽核的方式執行任意程式碼。

如果帳戶有權存取實際工作環境服務的 Shell，就能變更執行中工作的行為、外洩憑證，或使用憑證在環境中取得持續立足點。

為降低這項風險，我們採用下列控管措施，以安全替代方法取代生產機器的 SSH 存取權：

  • 窄版 API：對於工作流程明確定義的團隊，我們以可稽核的窄版 API 取代先前需要的 SSH。
  • SSH 安全 Proxy：對於需要更彈性存取權的團隊，安全 Proxy 可個別授權及稽核指令。
  • MPA：當 SRE 需要緊急 SSH 存取機器時，Google 會要求提供業務正當理由，並由授權人員核准存取權。系統會記錄完整的殼層工作階段轉錄稿。
  • 鎖定情境：單向 SSH 存取權是唯一允許的例外狀況。系統會記錄完整的殼層工作階段轉錄稿。

這些控制項可平衡正當 Shell 存取需求，以及過於廣泛的 Shell 存取權相關風險。

背景：Google 的 SSH

過去，Google 使用 SSH 管理機器。Borg 的開發讓大多數 Google 員工不再需要直接存取執行二進位檔的 Linux 電腦，但基於下列原因，殼層存取權仍保留下來：

  • 有時，人員需要直接存取電腦，才能進行偵錯。
  • SSH 存取權是瞭解各種抽象層的寶貴教學工具。
  • 在非預期的災難復原情境中，可能無法使用較高層級的工具。

為了在這些原因和所造成的安全風險之間取得平衡，Google 逐步達成一系列里程碑，以消除 SSH 風險，然後停止使用 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 群組和時間表。

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 節點可以對應至實體或虛擬機器。本文著重於實體機器。此外，Compute Engine 等產品 Google Cloud 提供單一用戶群，可隔離實體機器。

工作負載排程限制

Google 會將機器佈建到三種隔離集區：基礎機器、正式環境機器和開發機器。Google 營運多個獨立集區，用於代管基礎和機密工作負載，但為求簡化，本文會將每個集區視為一個集區。

為提供最有效的保護，我們對 WSR 部署了下列排程限制：

  • 基礎工作負載只能在基礎機器上執行。
  • 敏感工作負載只能在正式版機器上執行。
  • 未強化的工作負載只能在開發機器上執行。
  • 強化型工作負載可在正式環境或開發機器上執行，但建議在正式環境機器上執行。

下圖顯示排程限制。

WSR 的排程限制。

在這張圖中，隔離界線會區隔機器集區之間和集區內的不同類別工作負載。基礎工作負載是專屬基礎機器的唯一租戶。針對在正式版電腦上執行的工作負載，進行二進位授權或沙箱化，有助於防止本機權限提升攻擊。在開發機器上，未強化的工作負載可能會危害其他工作負載，但由於強化的工作負載無法建立新工作，因此危害僅限於開發機器。

系統會根據可用性，在正式版或開發機器上排程強化工作負載。在多個集區中排程可能違反直覺，但這是減輕排程限制導致使用率下降的必要措施。強化型工作負載可填補因隔離敏感和未強化的工作而產生的缺口。此外，硬體資源足跡越大，其他兩類資源的使用量波動就越能獲得容納，不必在環之間進行昂貴的機器移動。

下圖顯示不同類別工作負載的排程限制。強化型工作負載可位於正式環境或開發機器上。

工作負載類別的排程限制。

Google 會將基礎工作負載隔離到多個基礎集區，以資源效率換取更高的安全性。幸好，基礎工作負載的資源用量通常相對較小，而專用機器的隔離式小型集區對整體使用率的影響微乎其微。

WSR 強力保證非基礎工作負載絕不會在基礎機器上執行。基礎機器受到保護，可防範橫向移動，因為只有基礎工作負載才能在這些機器上執行。

控制項摘要

Google 會在基礎架構中採用多項控管機制，協助保護正式版服務、正式版機器和工作負載。這些控制項包括：

  • 實際工作環境服務的管理存取控制項和 BAB
  • 實際工作環境機器的 Shell 存取權控管、實體存取權控管，以及韌體和系統軟體控管
  • 不同類別工作負載的 WSR

這些控制項會共同強制執行限制，協助保護 Google 使用者和客戶，以及他們的資料。下圖說明這些控制項如何搭配運作，以支援 Google 的安全防護。

保護正式版服務的解決方案。

後續步驟