BeyondProd

本文上次更新於 2026 年 9 月，內容反映截至撰文時的情況。我們一向持續提升客戶保護措施，因此安全性政策和系統日後可能會有所變動。

本文說明 Google 如何使用名為 BeyondProd 的雲端原生架構，在基礎架構中導入安全防護機制。BeyondProd 是指基礎架構中的服務和控管機制，這些機制會相互搭配，共同保護工作負載。工作負載是應用程式完成的獨特工作。BeyondProd 可協助保護我們環境中執行的微服務，包括程式碼的變更方式，以及使用者資料的存取方式。

本文是系列技術文件之一，說明我們開發的技術 (例如 Chrome Enterprise 進階版、 )，有助於防範複雜威脅，保護 Google 平台。Chrome Enterprise 進階版採用零信任架構，可確保 Google 平台和其上執行的服務存取安全。與 Chrome Enterprise 進階版一樣，BeyondProd 不依賴傳統的網路周邊防護機制，例如防火牆。而是透過程式碼來源、服務身分和信任的硬體等特徵，在微服務之間建立信任關係。這份信任也延伸到在 Google Cloud 和軟體中執行的軟體，以及由 Google Cloud 客戶部署及存取的軟體。

這份文件說明 BeyondProd 的優點、服務和程序，以及我們如何遷移至這個架構。如要瞭解基礎架構安全防護總覽，請參閱 Google 基礎架構安全設計總覽。

與 Chrome Enterprise 進階版連線

現代安全架構已不再採用傳統的邊界式安全模型，也就是透過防火牆保護邊界，並將邊界內的任何使用者或服務視為可信任。

如今使用者經常在傳統安全邊界以外的地方工作，例如在家中、咖啡廳或飛機上。我們使用 Chrome Enterprise 進階版，根據多項因素授予公司資源的存取權，包括使用者身分、用於存取資源的裝置身分、裝置健康狀態、信任訊號 (例如使用者行為) 和存取控制清單。

BeyondProd 解決了生產服務的相同問題，就像 Chrome Enterprise 進階版為使用者解決問題一樣。在雲端原生架構中，我們不能只依賴防火牆來保護生產網路。微服務會遷移並部署在不同環境中、跨異質主機，且在各種信任和敏感度層級運作。在 Chrome Enterprise 進階版中，使用者信任取決於裝置的情境感知狀態等特徵，而非連線至公司網路的能力。在 BeyondProd 中，服務信任取決於程式碼來源、信任的硬體、服務身分等特徵，而不是 IP 位址或主機名稱等正式環境網路中的位置。

容器化基礎架構

我們的基礎架構會將工作負載部署為容器中的個別微服務。 微服務會將應用程式需要執行的個別工作，分離成不同的服務。每項服務都可以獨立開發及管理，並有專屬的 API、推出、調度及配額管理。微服務是獨立、模組化、動態且暫時性的服務。這些工作負載可分散在多個主機、叢集，甚至是雲端。在微服務架構中，工作負載可以是一項或多項微服務。

容器化基礎架構是指每項微服務都會部署為一組可移動及排程的容器。為了在內部管理這些容器，我們開發了名為 Borg 的容器自動化調度管理系統，每週會部署數十億個容器。Borg 是 Google 的統一容器管理系統，也是 Kubernetes 的靈感來源。

容器可讓您更輕鬆有效率地在多部機器上排定工作負載。 將微服務封裝在容器中，可將工作負載分割成更小、更易於管理維護和探索的單元。這種架構可視需要擴充工作負載：如果特定工作負載的需求量很高，可以有多部機器執行相同容器的副本，以處理必要範圍內的工作負載。

在 Google，安全防護在架構的每次演進中都扮演關鍵角色。我們的目標是透過這個微服務架構和開發程序，盡可能在開發和部署生命週期初期解決安全性問題 (此時解決問題的成本較低)，並以標準化且一致的方式解決問題。最終的結果是，開發人員減少了耗費在安全性事務上的時間，但仍獲得更完善的安全防護成果。

BeyondProd 福利

BeyondProd 為 Google 基礎架構帶來許多自動化和安全防護優勢。福利包括：

  • 網路邊緣保護：工作負載會與網路攻擊和來自網際網路的未授權流量隔離。雖然邊界方法並非新概念，但仍是雲端架構的最佳安全做法。服務範圍方法有助於盡可能保護基礎架構，防範未經授權的流量和來自網際網路的潛在攻擊，例如以流量為基礎的 DoS 攻擊。
  • 服務之間沒有固有的相互信任關係：只有經過驗證、可信任且獲得明確授權的呼叫端或服務，才能存取其他服務。這樣一來，攻擊者就無法使用不受信任的程式碼存取服務。 如果服務遭到入侵，這項福利有助於防止攻擊者採取行動，擴大影響範圍。這種互不信任的機制搭配精細的存取控管，有助於限制遭入侵的範圍和影響。
  • 執行已知出處程式碼的受信任機器：服務身分只能使用授權的程式碼和設定，且只能在授權的已驗證環境中執行。
  • 在各項服務中一致執行政策：一致執行政策有助於確保各項服務的存取權決策可靠無虞。舉例來說，您可以建立政策強制執行機制，驗證使用者資料的存取要求。如要存取服務，授權使用者必須提出通過驗證的要求，管理員則須提供業務上的正當理由。
  • 簡化、自動化及標準化的變更推出程序：輕鬆審查基礎架構變更對安全性的影響，並推出安全性修補程式，對正式環境的影響極小。
  • 共用作業系統的工作負載之間相互隔離：如果某項服務遭到入侵，不會影響在同一主機上執行的其他工作負載安全。這種隔離方式有助於限制遭入侵工作負載的影響範圍。
  • 信任的硬體和驗證：硬體信任根可確保主機只執行已知且授權的程式碼 (從韌體到使用者模式)，然後才排定任何工作負載在主機上執行。

這些優點代表容器和在雲端架構中執行的微服務可以部署、相互通訊，以及彼此相鄰執行，而不會削弱基礎架構的安全性。此外，個別微服務開發人員不必負擔基礎架構的安全性和實作細節。

BeyondProd 安全服務

我們設計及開發了多項 BeyondProd 安全防護服務，以創造「BeyondProd 優點」一節中討論的效益。以下各節將說明這些安全防護服務。

Google 前端網路邊緣防護

Google Front End (GFE) 提供網路邊緣防護。GFE 會終止來自使用者的連線，並提供集中式端點，強制執行 TLS 最佳做法。

雖然我們不再著重於以周邊為基礎的安全性，但 GFE 仍是我們防範 DoS 攻擊，保護內部服務的重要策略。使用者連線至 Google 基礎架構時，GFE 是第一個進入點。使用者連線至我們的基礎架構後，GFE 也會負責負載平衡，並視需要重新導向區域之間的流量。GFE 是邊緣 Proxy，可將流量轉送至正確的微服務。

Google Cloud 上的客戶 VM 不會向 GFE 註冊。而是向 Cloud Front End 註冊，這是 GFE 的特殊設定，使用 Compute Engine 網路堆疊。客戶 VM 可以透過公開或私人 IP 位址，直接存取 Google 服務。(只有啟用Private Google Access時，才能使用私人 IP 位址)。

應用程式層傳輸安全性，確保服務之間的信任關係

應用程式層傳輸安全性 (ALTS) 可確保服務之間沒有固有的相互信任關係。ALTS 用於遠端程序呼叫 (RPC) 驗證、 完整性、流量加密和服務身分。ALTS 是 Google 基礎架構中服務的雙向驗證和傳輸加密系統。一般而言，身分會繫結至服務，而非特定伺服器名稱或主機。這項繫結有助於在各個主機之間順利複製微服務、平衡負載以及重新排程。

每部機器都有透過主機完整性系統佈建的 ALTS 憑證，只有在主機完整性系統驗證安全啟動成功後，才能解密。大多數 Google 服務都是以 Borg 為基礎的微服務形式運作，而這些微服務各自都有自己的 ALTS 身分。Borg Prime( ) 是 Borg 的集中式控制器，會根據微服務的身分，將這些 ALTS 微服務憑證授予工作負載。機器層級的 ALTS 憑證會形成安全管道，用於佈建微服務憑證，因此只有成功通過主機完整性驗證啟動的機器，才能託管微服務工作負載。如要進一步瞭解 ALTS 憑證，請參閱「工作負載憑證」。

Borg 適用的二進位授權，可追溯程式碼來源

Borg 適用的二進位授權 (BAB) 可提供程式碼來源驗證。BAB 是部署時的強制執行檢查，可確保程式碼符合內部安全規定，再進行部署。舉例來說，BAB 強制執行檢查包括確保程式碼提交至來源程式碼存放區前，變更內容已由第二位工程師審查，且二進位檔是在專用基礎架構上建構，並可驗證。在我們的基礎架構中，BAB 會限制未經授權的微服務部署作業。

主機完整性，確保機器信任

主機完整性 透過安全啟動程序驗證主機系統軟體的完整性，並由硬體信任根安全晶片 (稱為「Titan」) 提供支援 (如適用)。主機完整性檢查包括驗證 BIOS、基板管理控制器 (BMC) 上的數位簽章、

系統啟動載入程式和 OS 核心。在支援的情況下，主機完整性檢查可以包括使用者模式程式碼和周邊韌體 (例如 NIC)。除了驗證數位簽章，主機完整性還能確保每部主機都執行這些軟體元件的預期版本。

服務存取管理和使用者情境票證，用於強制執行政策

服務存取權管理 和使用者環境票證 有助於在各項服務中一致地強制執行政策。

服務存取管理功能可限制服務間的資料存取方式。當 RPC 從某項服務傳送至另一項服務時，服務存取管理會定義服務存取接收服務資料時所需的授權和稽核政策。這項功能可限制資料存取方式、授予所需的最低存取權，並指定稽核存取權的方式。在 Google 基礎架構中，服務存取權管理會限制一個微服務存取另一個微服務的資料，並允許對存取權控管進行全域分析。

使用者情境票證是由使用者驗證服務核發，可為服務提供與服務身分不同的使用者身分。這些票證是受完整性保護、集中核發、可轉送的憑證，可證明向服務提出要求的使用者身分。這些票證可減少服務間的信任需求，因為使用 ALTS 的對等互連身分可能不足以授予存取權，而這類存取決策通常也以使用者的身分為依據。

Borg 工具，可自動推出變更並調整規模

藍綠部署的 Borg 工具可提供簡單、自動化和標準化的變更推出作業。 藍綠部署 是一種在不影響連入流量的情況下，對工作負載發布變更的方法，能讓使用者在存取應用程式時，不會遇到任何停機時間。

Borg 工作 是微服務的單一執行個體，負責執行應用程式的某個部分。系統會視負載情況調整工作規模，負載增加時部署新工作，負載減少時終止現有工作。

執行維護工作時，Borg 工具會負責遷移執行中的工作負載。部署新的 Borg 工作時，負載平衡器會逐步將流量從現有工作移至新工作。這個程序可讓微服務在不中斷服務的情況下更新，使用者不會察覺。

我們也會使用這項工具在新增功能時套用服務升級，並在套用重要安全性更新時避免服務中斷。如果變更會影響基礎架構，我們會使用即時遷移客戶 VM，確保工作負載不受影響。

詳情請參閱「Borg 的二進位授權」。

用於隔離工作負載的 gVisor 核心

gVisor 核心 可隔離共用作業系統的工作負載。gVisor 會使用使用者空間核心攔截及處理系統呼叫，減少與主機的互動，並縮小潛在的攻擊面。這個核心提供執行應用程式所需的大部分功能，並限制應用程式可存取的主機核心介面。

Borg 通常用於 Google 內部由 Google 工程師編寫的受信任工作負載，因此這些工作負載不需要安全沙箱。gVisor 則用於執行第三方程式碼或處理不受信任資料的 Borg 工作負載。例如 Gmail 病毒掃描、YouTube 影片處理和自訂使用者資料查詢。

gVisor 是我們用來隔離內部工作負載和 Google Cloud 客戶工作負載的工具之一，這些工作負載會在同一部主機上執行。如要進一步瞭解其他沙箱工具，請參閱「程式碼沙箱」。

使用 BeyondProd 保護使用者資料

本節說明 BeyondProd 服務如何相互搭配，協助保護基礎架構中的使用者資料。以下章節說明兩個範例：

  • 從建立到傳送至目的地，存取使用者資料要求。
  • 將程式碼從開發環境移至正式環境。

並非所有列出的技術都會用於基礎架構的所有部分，具體情況取決於服務和工作負載。

存取使用者資料

下圖顯示基礎架構用來驗證使用者是否獲准存取使用者資料的程序。

Google 的雲端原生安全控管機制存取使用者資料。 存取使用者帳戶的步驟如下：

  1. 使用者向 GFE 傳送要求。
  2. GFE 會終止 TLS 連線，並使用 ALTS 將要求轉送至適當服務的前端。
  3. 應用程式前端會使用中央使用者驗證 (EUA) 服務驗證使用者要求，如果驗證成功，就會收到短期的加密使用者情境票證。
  4. 應用程式前端會透過 ALTS 向儲存後端服務發出 RPC，並在後端要求中轉送票證。
  5. 後端服務會使用服務存取管理機制，確保符合下列條件：
    • 前端會使用有效且未遭撤銷的憑證進行驗證。這項檢查表示該應用程式是在受信任的主機上執行，且 BAB 檢查已成功。
    • 前端服務的 ALTS 身分已獲授權，可向後端服務提出要求並出示 EUC 票證。
    • 使用者情境票證有效。
    • EUC 票證中的使用者有權存取所要求的資料。

如果這些檢查中有任何一項不符，系統就會拒絕要求。

如果通過這些檢查，系統就會將資料傳回授權應用程式前端，並提供給授權使用者。

在許多情況下，會有一連串的後端呼叫，每個中介服務都會對傳入的 RPC 執行服務存取檢查，並將票證轉送至傳出的 RPC。

如要進一步瞭解基礎架構內的流量路徑，請參閱「Google 網路內的傳輸中資料加密」。

進行程式碼變更

下圖顯示程式碼變更的部署方式。

程式碼變更方式。

如要變更程式碼，請按照下列步驟操作：

  1. 開發人員變更受 BAB 保護的微服務。變更會提交至中央程式碼存放區， 該存放區會強制執行程式碼審查。 獲得核准後，變更會提交至中央信任的建構系統 ，該系統會產生套件，並附上已簽署的可驗證建構資訊清單憑證。

  2. 在部署時，BAB 會驗證建構管道的簽署憑證，確認是否遵循這個程序。

  3. 無論是例行推出還是緊急安全性修補程式，Borg 都會使用可靠性模型處理所有工作負載更新，確保服務中斷時間降到最低。

  4. GFE 會使用負載平衡將流量轉移至新部署作業，確保作業持續進行。

如要進一步瞭解這個程序，請參閱「我們的開發和製作程序」。

所有工作負載都需要隔離。如果工作負載的來源程式碼來自 Google 外部，因此信任度較低，系統會部署具有更強大隔離層的工作負載，例如部署到受 gVisor 保護的環境。這種隔離機制有助於遏制成功入侵應用程式的攻擊者。

雲端原生安全影響

以下各節會比較傳統基礎架構安全防護的各個層面，以及雲端原生架構中的對應項目。

應用程式架構

以邊界為基礎的傳統安全模型無法單獨保護雲端原生架構。傳統上，單體式應用程式採用三層式架構，並部署至私有企業資料中心，這些資料中心有足夠的容量來處理重要事件的尖峰負載。具有特定硬體或網路需求的應用程式會刻意部署到特定電腦，這些電腦通常會維持固定 IP 位址。由於變更會同時影響應用程式的許多部分，因此推出次數不多、規模龐大，且難以協調。這導致應用程式的生命週期非常長，更新頻率較低，且通常較少套用安全性修補程式。

不過，在雲端原生模型中，應用程式必須可在不同環境之間移植，因為應用程式可以在公有雲、私有資料中心或第三方託管服務中執行。因此，容器化應用程式會拆分為多項微服務，非常適合雲端環境，而非單體式應用程式。容器會將應用程式所需的二進位檔與基礎主機作業系統分離，讓應用程式更具可攜性。容器是不可變的，部署後不會變更。而是經常重建及重新部署。

容器經常重新啟動、停止或重新排程，因此硬體和網路的重複使用和共用頻率更高。有了通用的標準化建構和發布程序，即使團隊各自管理微服務的開發作業，開發程序也能在團隊之間保持一致。因此，您可以在開發週期初期解決安全考量 (例如安全審查、程式碼掃描和安全漏洞管理)。

服務網格

我們建構共用且安全設計的基礎架構，供所有開發人員使用，盡量減輕開發人員瞭解及實作常見安全需求的負擔。安全功能應盡量減少或完全不需要整合到各個應用程式中，而是以包覆及連結所有微服務的架構形式提供。這通常稱為「服務網格」。這也表示安全性可以與一般開發或部署活動分開管理及實作。

服務網格是基礎架構層的共用架構，可包覆並連結所有微服務。服務網格可讓服務之間相互通訊，藉此控管流量、套用政策，並集中監控服務呼叫。

零信任安全防護

在採用私有資料中心的傳統安全模式中，機構的應用程式會依賴防火牆，防範外部網路威脅，保護工作負載。

採用零信任安全模型後，授權決策就不會再依賴防火牆。而是透過工作負載身分、驗證和授權等其他控制項，確保內部或外部連線在交易前經過驗證，藉此保護微服務。擺脫對防火牆或網路控管機制的依賴後，您就能實作微服務層級的區隔，服務之間不會有任何信任關係。透過微服務層級的分段，流量可透過不同控制項擁有不同信任等級，您不再只能比較內部和外部流量。

整合至服務堆疊的共用安全防護需求

在傳統安全模式中，個別應用程式須負責滿足自身的安全需求，不受其他服務影響。這類需求包括身分管理、TLS 終止和資料存取權管理。因為這些問題必須在許多地方修正，導致修正作業難以套用，進而造成實作不一致或未解決的安全問題。

在雲端原生架構中，服務會更頻繁地重複使用元件。透過節流點，系統就能在各項服務中一致地強制執行政策。您可以使用不同的安全防護服務，強制執行不同的政策。您不必為每個應用程式分別實作重要安全服務，而是將各種政策拆分成不同的微服務。舉例來說，您可以建立一項政策，確保使用者資料的存取權經過授權；也可以建立另一項政策，確保使用最新的 TLS 密碼組合。

標準化程序，推出頻率更高

在傳統安全模式中，共用服務有限，程式碼通常會重複，並與本機開發作業耦合。共用範圍有限會導致難以判斷變更的影響，以及變更可能對應用程式許多部分造成的影響。因此，推出作業不常進行，且難以協調。如要進行變更，開發人員可能必須直接更新每個元件 (例如開啟與每部虛擬機器的 SSH 連線，以更新設定)。整體而言，這可能會導致應用程式的生命週期極長。

從安全性的角度來看，由於程式碼經常重複，因此審查難度較高，確保修正漏洞時能一併修正所有相關程式碼，更是難上加難。

在雲端原生架構中，推出作業頻繁且標準化。這個程序可讓安全防護機制在軟體開發生命週期中提前介入。「提早」是指在軟體開發生命週期中，提早執行程式碼、建構、測試、驗證和部署等步驟。提早進行安全性測試可簡化安全性強制執行作業，並確保一致性，包括定期套用安全性修補程式。

變更為 BeyondProd

Google 轉移至 BeyondProd 時，必須在兩大領域進行變更：基礎架構和開發程序。我們同時處理了這些變更，但您也可以獨立處理，以便在環境中設定類似項目。

改變我們的基礎架構

我們的目標是在整個基礎架構中自動執行安全防護措施，因為我們認為安全防護措施的規模應與服務規模相同。服務必須預設為安全，只有在明確決定接受風險後，才能使用不安全的方式。對基礎架構進行直接人為介入應為例外情況，而非例行作業，且介入作業發生時應可稽核。這樣一來，我們就能根據為服務部署的程式碼和設定，而非部署服務的人員，驗證服務。

我們首先建構了一個強大的服務身分、驗證和授權基礎。微服務會使用服務 ID ，向基礎架構中執行的其他服務驗證自身。有了可信賴的服務身分基礎，我們就能實作更高層級的安全功能，例如服務存取權管理和使用者環境票證，這些功能都必須先驗證服務身分才能運作。為簡化新舊服務的這項轉換作業，ALTS 最初是以程式庫的形式提供，並搭配單一輔助精靈。這個常駐程式會在每個服務呼叫的主機上執行，並隨著時間演進為使用服務憑證的程式庫。ALTS 程式庫已無縫整合至核心 RPC 程式庫。這項整合功能可輕鬆獲得廣泛採用，不會對個別開發團隊造成重大負擔。ALTS 推出後，才能推出服務存取管理和使用者環境票證。

改變我們的開發程序

Google 必須建立完善的建構和程式碼審查程序，確保服務運作的完整性。我們建立了中央建構程序，以便在建構和部署時開始強制執行雙人程式碼審查和自動化測試等規定。(如要進一步瞭解部署作業，請參閱「 Borg 適用的二進位授權」一文)。

基本功能就位後，我們開始著手解決在環境中執行外部不受信任程式碼的需求。為達成這個目標，我們開始進行沙箱化作業，首先是 ptrace，然後是 gVisor。同樣地，藍綠部署在安全性 (例如修補) 和可靠性方面也帶來顯著優勢。

我們很快就發現，一開始先讓服務對違反政策的情形進行記錄，而不要直接封鎖，會比較容易實現目標。這種做法有兩大優點：

  • 服務擁有者可藉此測試變更，並評估遷移至雲端原生環境對服務的影響 (如有)。
  • 這讓我們得以修正任何錯誤，並找出可能需要提供給服務團隊的任何其他功能。

舉例來說，當服務加入 BAB 時，服務擁有者會啟用僅限稽核模式。這將有助於他們識別不符合需求的程式碼或工作流程。服務擁有者解決僅限稽核模式標示的問題後，即可切換為強制執行模式。在 gVisor 中，我們首先透過對工作負載採用沙箱機制 (即使沙箱功能中存在相容性差異)，然後以系統化的方式解決這些差異以改進沙箱，最後達成相同的結果。

後續步驟