BeyondProd

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

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

本文是系列技術文件之一，說明我們開發的技術 (例如 Chrome Enterprise Premium、 )，有助於防範 Google 平台遭受進階威脅。Chrome Enterprise 進階版採用零信任架構，可安全存取 Google 平台和在該平台上執行的服務。與 Chrome Enterprise Premium 相同，BeyondProd 不依賴防火牆等傳統網路周邊防護措施。BeyondProd 則會根據程式碼來源、服務身分和信任的硬體等特徵，在微服務之間建立信任關係。這項信任也延伸至在 Google Cloud 執行的軟體，以及由 Google Cloud客戶部署及存取的軟體。

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

簡介

時下的安全性架構已超越了傳統的邊界式安全性模型。在傳統模型下，我們仰賴防火牆來保護整個邊界範圍，而且邊界內的所有使用者或服務都受到信任。

現今的使用者具機動性，經常會在機構傳統的安全防護範圍之外作業，例如在家中、咖啡廳或飛機上。我們使用 Chrome Enterprise Premium，根據多種因素授予公司資源的存取權，包括使用者身分、用於存取資源的裝置身分、裝置健康狀態、信任信號 (例如使用者行為) 和存取權控制清單。

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

容器化基礎架構

我們的基礎架構會將工作負載以個別微服務的形式部署在容器中。微服務會將應用程式必須執行的個別工作分為不同的服務。每個服務都可以獨立進行開發和管理，並且有自己的 API、發布、資源調度和配額管理方式。微服務具有獨立、模組化、動態和暫時等特性，可以跨主機、叢集甚至是雲端環境分布。在微服務架構中，工作負載可以是一或多個微服務。

使用容器化基礎架構，就代表每個微服務都是以一組專屬容器的形式進行部署。這組容器可移動且可排程。為了在內部管理這些容器，我們開發了一個名為 Borg 的容器自動化調度管理系統，這個系統每週會部署數十億個容器。Borg 是 Google 的統一容器管理系統，也是 Kubernetes 的靈感來源。

容器可讓您更輕鬆且有效率地在機器之間排程工作負載。將微服務封裝在容器中，可將工作負載分割為更小且更易於管理的單元，以進行維護和探索。這個架構會視需要針對工作負載進行資源調度，如果對特定工作負載有高度需求，則可能會有多部機器執行同一項服務的副本來處理所需的工作負載規模。

在 Google，安全性是我們每次改進架構時的關鍵考量。我們採用這種微服務架構和開發程序的目標，是要在開發和部署生命週期中，以標準化且一致的方式盡早解決安全性問題，因為這時解決問題的成本較低。最終的結果是，開發人員減少了耗費在安全性事務上的時間，但仍獲得更完善的安全防護成果。

BeyondProd 優點

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

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

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

BeyondProd 安全性服務

我們設計及開發了多項 BeyondProd 安全性服務，以實現「BeyondProd 優點」一文中所述的優勢。以下各節將說明這些安全防護服務。

Google Front End 網路邊緣防護

Google Front End (GFE) 提供網路邊緣防護。GFE 會終止與使用者的連線，並充當強制執行 TLS 最佳做法的中央位置。

即使邊界式安全防護機制已不再是我們的重心，GFE 在我們保護內部服務免受阻斷服務攻擊的策略中，仍是重要的一環。GFE 是使用者連線至 Google 基礎架構的第一個進入點。使用者連線至我們的基礎架構後，GFE 還將負責進行負載平衡，並視需要在區域之間重新轉送流量。GFE 是可將流量轉送至正確微服務的邊緣 Proxy。

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

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

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

每部機器都有一個使用主機完整性系統佈建的 ALTS 憑證，而且只有在主機完整性系統驗證安全啟動成功後才能解密。大多數 Google 服務都會以微服務的形式在 Borg 之上執行，而這些微服務都有自己的 ALTS 身分。Borg Prime(go/borg-control) 是 Borg 的集中式控制器，會根據微服務的身分將這些 ALTS 微服務憑證授予工作負載。機器層級 ALTS 憑證形成了佈建微服務憑證的安全通道，因此只有成功通過主機完整性驗證開機程序的機器，才能託管微服務工作負載。如要進一步瞭解 ALTS 憑證，請參閱「工作負載憑證」。

Borg 適用的二進位授權，用於程式碼來源

Borg 適用的二進位授權 (BAB) 可驗證程式碼來源。BAB 是一種部署期間強制檢查，可確保程式碼在部署前符合內部安全性需求。舉例來說，BAB 強制檢查包括確保變更內容經過第二位工程師審查，然後才將程式碼提交至 Google 的原始碼存放區，以及在專屬基礎架構上以可驗證的方式建構二進位檔。在我們的基礎架構中，BAB 會針對未經授權的微服務限制部署作業。

主機完整性，用於機器信任

主機完整性 經由安全的啟動程序，驗證主機系統軟體的完整性。此服務是透過支援此作業的硬體信任根安全晶片 (稱為 Titan) 執行。主機完整性檢查包括驗證 BIOS、基板管理控制器 (BMC)、系統啟動載入程式和 OS 核心上的數位簽章。在支援的情況下，主機完整性檢查可以包含使用者模式程式碼和周邊韌體 (例如 NIC)。除了驗證數位簽章，主機完整性還能確保每部主機都執行這些軟體元件的預期版本。

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

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

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

使用者情境票證由使用者驗證服務發出，並可為服務提供與其服務身分不同的使用者身分。這些票證是完整性受保護、集中發出且可轉送的憑證，可以認證發出服務要求的使用者所具備的身分。這些票證減少了服務之間的信任需求，因為 ALTS 提供的對等身分通常並不足以授予存取權，而此類存取權決定通常也是以使用者的身分為基礎。

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

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

Borg 工作是微服務的單一執行個體，負責執行應用程式的某些部分。系統會針對工作調度資源以處理負載，並在負載增加時部署新的工作，以及在負載減少時終止現有的工作。

執行維護工作時，Borg 工具會負責遷移正在執行的工作負載。部署新的 Borg 工作時，負載平衡器會逐漸將流量從現有工作轉移到新的工作。如此一來，便可在無須停機，且使用者也不會注意到的情況下更新微服務。

我們也會使用這個工具，在新增功能時套用服務升級，以及在不停機的情況下套用重要的安全性更新。對於會影響基礎架構的變更，我們會使用客戶 VM 的即時遷移功能，確保工作負載不受影響。

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

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

gVisor 核心 可隔離共用作業系統的工作負載。gVisor 會透過使用者空間核心來攔截和處理系統呼叫，從而減少與主機的互動，並縮減潛在受攻擊面。這個核心可提供執行應用程式所需的大部分功能，並且會限制應用程式可存取的主機核心部分。我們使用多種工具來隔離內部工作負載和 Google Cloud 客戶工作負載，而 gVisor 就是其中一種。如要進一步瞭解其他沙箱工具，請參閱「程式碼沙箱」。

透過 BeyondProd 保護使用者資料

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

  • 從建立到傳送至目的地，存取使用者資料要求。
  • 將程式碼從開發環境變更為實際工作環境。

此處列出的技術並不是全都應用於 Google 基礎架構的所有部分，各項服務和工作負載使用的技術並不相同。

存取使用者資料

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

Google 的雲端原生安全控管機制存取使用者資料。

存取使用者帳戶的步驟如下：

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

如果這些檢查中有任何一個失敗，系統就會拒絕該要求。

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

許多情況下都會有一連串的後端呼叫，而每個媒介服務都會對傳入的 RPC 執行服務存取檢查，而票證則經由傳出的 RPC 轉送。

如要進一步瞭解流量如何在我們的基礎架構中轉送，請參閱「流量轉送方式」。

進行程式碼變更

下圖顯示如何部署程式碼變更。

程式碼變更方式。

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

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

  2. 在部署期間，BAB 會驗證來自建構管道的已簽署憑證，以驗證前述程序。

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

  4. GFE 會使用負載平衡將流量轉送至新的部署作業，以確保作業的連續性。

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

所有工作負載都需要隔離。如果工作負載的受信任等級較低 (例如原始碼來自 Google 外部)，則會部署至隔離層級較高的環境，例如受 gVisor 保護的環境。這種隔離措施有助於遏制設法入侵應用程式的攻擊者。

雲端原生安全防護機制影響

以下各節比較了傳統基礎架構安全防護機制的各個層面，以及對應的雲端原生架構要素。

應用程式架構

較傳統的安全性模型著重於邊界式安全防護機制，而無法單獨保護雲端原生架構。傳統上，單體式應用程式使用三層架構，並部署至私人企業資料中心，而該資料中心具有足夠的容量來處理重要事件的尖峰負載。至於具有特定硬體或網路需求的應用程式，則都刻意部署至通常會維持固定 IP 位址的特定機器。由於所產生的變更會同時影響應用程式的許多部分，所以推出作業較不頻繁、規模較大且難以協調。這種情形會使得應用程式的使用壽命偏長、不常更新，而且通常不會經常套用安全性修補程式。

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

由於容器的重新啟動、停止和重新排程作業頻繁，硬體和網路的重複使用與共用情況也會增加。利用通用的標準化建構作業和分配程序，即使團隊獨立管理其微服務開發作業，團隊之間的開發程序也會較為一致和統一。因此，安全性考量 (例如安全性審查、程式碼掃描和安全漏洞管理) 可以在開發週期的早期解決。

服務網格

建構共用且安全設計的基礎架構供所有開發人員使用，可盡量減輕開發人員瞭解及實作常見安全需求的負擔。安全防護功能應幾乎不須整合至個別應用程式，而是以涵蓋並連接所有微服務的結構形式提供。這通常稱為「服務網格」。換句話說，安全性機制的管理與實作，可以獨立於一般的開發和部署活動。

服務網格是基礎架構層的共用網狀架構，可封裝及連結所有微服務。服務網格可讓服務與服務間通訊，可用來控制流量、套用政策，並為服務呼叫提供集中式監控功能。

零信任安全防護機制

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

採用零信任安全模式後，授權決策就不會再依賴防火牆。而是透過其他控制項 (例如工作負載身分、驗證和授權)，確保內部或外部連線在交易前經過驗證，藉此保護微服務。擺脫對防火牆或網路控管的依賴後，您就能實作微服務層級的區隔，這樣一來，服務之間就不會存在固有信任。有了微服務層級的區隔，流量就能獲派不同層級的信任，而各層級又對應不同的控管機制，讓您不再只能比較內部與外部流量。

整合至服務堆疊的共用安全性要求

在傳統的安全性模型中，個別應用程式必須各自負責滿足獨立於其他服務之外的安全性需求。這類需求包括身分管理、TLS 終止和資料存取權管理。這可能會導致實作不一致，或安全性問題無法獲得解決，因為這類問題必須從多處修正，所以修正內容也較難套用。

在雲端原生架構中，各服務重複使用元件的頻率較高。堵塞點可讓政策以一致的方式跨服務強制執行。不同的政策可以使用不同的安全性服務來強制執行。您可以將各種政策拆分為不同的微服務，而不是要求每個應用程式分別實作重要的安全性服務。舉例來說，您可以建立一個政策，確保使用者資料存取作業已經過授權，並建立另一個政策，確保系統是使用最新的 TLS 加密套件。

推出作業較為頻繁的標準化程序

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

從安全性的角度來看，由於程式碼經常重複，因此較難審查，而修正一個安全漏洞後，要確保存在這個漏洞的所有位置也都獲得修正，甚至更具挑戰。

在雲端原生架構中，推出作業頻繁且標準化。這個程序可讓安全性在軟體開發生命週期中提前進行。「提前進行相關作業」是指在軟體開發生命週期中，提早執行某些步驟，其中可能包括編寫程式碼、建構、測試、驗證和部署等等。左移可更簡單一致地強制執行安全性措施，包括定期套用安全性修補程式。

改用 BeyondProd

Google 轉換至 BeyondProd 時，需要在兩個大方面做出改變：基礎架構和開發程序。我們同時進行了兩方面的變更，但您也可以分別獨立處理，在自己的環境中設定類似項目。

改變我們的基礎架構

我們的目標是在整個基礎架構中實現安全防護自動化，因為我們認為安全防護的擴充方式應與服務的擴充方式相同。服務在預設情況下應屬安全，只有在明確決定接受風險後，才會發生安全性問題。對基礎架構的直接人為介入應視為例外狀況，而非例行作業，且介入時應可稽核。然後，我們便可以根據為服務所部署的程式碼和設定 (而非部署服務的人員) 來驗證服務。

我們首先建構了一個強大的服務身分、驗證和授權基礎。微服務會使用服務身分，向在基礎架構中執行的其他服務驗證自己的身分。有了受信任的服務身分做為基礎，我們就能實作須驗證這些服務身分才能執行的較高層級安全功能，例如服務存取管理和使用者情境票證。為了簡化新服務和現有服務的轉換過程，ALTS 一開始提供時所採取的形式，是包含單一輔助 Daemon 的程式庫。這個 Daemon 在每個服務呼叫的主機上執行，並隨著時間發展為使用服務憑證的程式庫。ALTS 程式庫已緊密整合至核心 RPC 程式庫中。這項整合措施讓 ALTS 更容易獲得廣泛採用，且不會給個別開發團隊帶來沉重負擔。推出 ALTS 是推出服務存取管理和使用者情境票證的先決條件。

改變我們的開發程序

對於 Google 來說，建立一個完善可靠的建構作業和程式碼審查程序至關重要，可確保服務完整運作。我們建立了一個集中的建構程序，在這個程序中，我們可以開始強制執行要求，例如在建構和部署期間進行雙人程式碼審查和自動化測試。(如需有關部署的詳細資料，請參閱 Borg 適用的二進位授權。)

完成基本工作後，由於某些不受信任的外部程式碼需要在內部環境執行，因此我們便開始處理這些需求。為達成這個目標，我們開始採用沙箱機制，首先使用 ptrace，然後使用 gVisor。同樣地，藍/綠部署在安全性 (例如修補) 和可靠性方面都提供了顯著的效益。

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

  • 這個方法讓服務擁有者有機會測試改變的結果，以及評估遷移至雲端原生環境將對其服務產生的影響 (如果有的話)。
  • 這樣的做法也讓我們能夠修正所有錯誤，以及確定可能需要提供給服務團隊的其他功能。

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

後續步驟