BeyondProd:新型雲端原生安全防護機制

Google 撰寫了多份白皮書,專門介紹有助於提高安全性的內部開發專案。BeyondProd 特別回顧了 BeyondCorp 的概念:邊界式安全性模型不再適用於使用者;同樣的道理,這套模型也不再適用於微服務。因此我們修改了原始的 BeyondCorp 報告,「這個模型的重要假設不再成立:邊界範圍不再侷限於企業 [資料中心] 的實體位置,而邊界內的區域也不再是託管個人運算裝置和企業應用程式 [微服務] 的安全位置」。

本白皮書會詳細說明 Google 基礎架構的數個部分,如何共同運作以保護工作負載。這個架構現在稱為「雲端原生」架構。如需 Google 安全防護機制的總覽,請參閱安全性基礎架構設計白皮書

本文撰寫於 2019 年 12 月,所有資訊皆以當時情況為依據。另外,我們會持續改善使用者資料的保護機制,因此 Google Cloud 的安全性政策和系統未來可能會有所有變動。

詞彙

本文件使用的定義如下:

  • 微服務會將應用程式必須執行的個別工作分為不同的服務,每個服務都可以獨立進行開發和管理,並且有自己的 API、推出、資源調度和配額管理方式。較現代化的架構能以一組微服務 (而非單一單體式服務) 的形式,執行網站等應用程式。微服務具有獨立、模組化、動態和暫時等特性,可以跨主機、叢集甚至是雲端環境分布。

  • 工作負載是應用程式完成的不重複工作。在微服務架構中,工作負載可以是一或多個微服務。

  • 工作是微服務的單一執行個體,負責執行應用程式的某些部分。

  • 微服務會使用服務身分來向在基礎架構中執行的其他服務驗證自己的身分。

  • 服務網格是服務與服務間通訊的基礎架構層,可用來控制流量、套用政策,並為服務呼叫提供集中式監控功能。使用微服務架構時,服務網格可以免除個別服務實作這些控管機制的負擔,並讓您統一對多項微服務進行較為簡單的集中式管理。

資訊長層級摘要

  • Google 的基礎架構會將工作負載以個別微服務的形式部署在容器中,並使用我們的容器自動化調度管理系統 Borg 來管理這些工作負載。現在廣為人知的「雲端原生」架構,就是以前述的機制為靈感和範本。

  • Google 的基礎架構在設計時便已考量到安全性,而不是事後想到才加入安全功能。我們的基礎架構假設服務之間不存在信任關係。

  • Google 透過一項名為 BeyondProd 的計畫來保護微服務。這項保護機制涵蓋如何變更程式碼,以及如何存取微服務中的使用者資料。BeyondProd 應用的概念如下:雙向驗證的服務端點、傳輸安全性、包含全球負載平衡和阻斷服務保護的邊緣終止、端對端程式碼來源,以及執行階段沙箱機制。

  • 要從傳統的安全性模型轉換至雲端原生安全防護機制模型,須針對兩個主要領域進行變更,也就是我們的基礎架構和開發程序。將共用元件建構到涵蓋和連接所有微服務的共用網狀架構 (也稱為服務網格) 中,就能以較簡便的方式推出變更,以及實現跨服務的一致化安全措施。

動機

Google 改採容器和容器自動化調度管理技術是為了提高資源使用率、建構可用性高的應用程式,以及簡化 Google 開發人員的工作。而改採容器化基礎架構的另一個動機,則是為了讓安全性控管機制能夠配合現有架構的運作方式。我們已清楚地瞭解到,邊界式安全性模型並不夠安全。如果攻擊者突破了這道邊界,他們就可以在網路中自由移動。雖然我們瞭解整個基礎架構需要更嚴格的安全性控管機制,但也希望能讓 Google 開發人員輕鬆編寫和部署安全的應用程式,而無須自行實作安全防護功能。

捨棄單體式應用程式,改用自動化調度管理系統從容器部署的分散式微服務,可帶來實質的操作優勢,讓管理和擴充作業變得簡單。這個雲端原生架構須具備內含不同工具的不同安全性模型,才能保護具有微服務管理和擴充性優勢的部署作業。

本文件將說明 Google 實作雲端原生安全防護機制 (在此稱為 BeyondProd) 的方式:改採雲端原生架構對安全性有何意義、雲端原生安全防護機制的安全性原則、為滿足這些需求所建構的系統,以及如何自行進行類似變更的一些指引。

Google 的雲端原生安全防護機制

容器化微服務

從成立之初,Google 就做出一個深思熟慮的決定:利用低成本的通用伺服器建構資料中心能力,而不是投資較昂貴的高可用性硬體。一直以來,我們對於可靠性所秉持的理念,都是「系統的任何獨立部件就算發生故障,也不會對使用者可看到的服務造成影響」。為了實現這種可用性,就必須執行服務的備援執行個體,讓系統即使在發生個別的故障事件時,也不會造成服務中斷。有鑑於這樣的理念,我們開發了容器、微服務和容器自動化調度管理技術,藉此透過可擴充的方式,管理這些分散式高度備援系統的部署作業。

使用容器化基礎架構,就代表每個工作負載都是以一組專屬容器的形式進行部署。這組容器不可變更,但可移動與排程。為了在內部管理這些容器,我們開發了一個名為 Borg1 的容器自動化調度管理系統。我們目前仍使用這個系統每週部署數十億個容器。

容器使得在機器之間分裝和重新排程工作負載變得更簡單。微服務則簡化了應用程式不同部分的開發和偵錯作業。將微服務和容器搭配使用時,可以將工作負載分割為更小且更易於管理的單元,以進行維護和探索。改用包含微服務架構的容器化基礎架構,稱為採用「雲端原生」架構。服務會在 Borg 部署的容器中執行。這個架構會視需要針對工作負載進行資源調度,如果對特定工作負載有高度需求,則可能會有多部機器執行同一項服務的副本來處理所需的工作負載規模。

Google 的與眾不同之處在於,我們在每次改進架構時都會將安全性納入考量。近年的雲端原生安全防護機制概念,與 Google 多年來保護基礎架構的手法不謀而合。我們採用這種微服務架構和開發程序的目標,是要在開發和部署生命週期中,以標準化且一致的方式盡早解決安全性問題,因為這時解決問題的成本較低。最終的結果是,開發人員減少了耗費在安全性事務上的時間,但仍獲得更完善的安全防護成果。

遷移至雲端原生架構

時下的安全性架構已超越了傳統的邊界式安全性模型。在傳統模型下,我們仰賴單一道防火牆來保護整個邊界範圍,而且內部的所有使用者或服務都受到完全的信任。BeyondCorp 的出現,是為了因應現代企業使用者工作方式上的改變。現今的使用者具機動性,經常會在機構傳統的安全防護範圍之外作業,例如在咖啡廳、飛機上或其他地方。在 BeyondCorp 中,我們摒棄了特殊權限企業網路的想法,僅根據裝置和使用者憑證及屬性來授予存取權,而不管使用者的網路位置為何。

雲端原生安全防護機制為服務和使用者解決了相同的問題。在雲端原生環境中,不能只依靠防火牆來保護實際工作環境網路,一如我們不能只靠防火牆來保護企業網路。就像使用者並非都使用相同的實體位置或裝置一樣,開發人員也不全都會將程式碼部署至相同的環境中。採用 BeyondProd 時,微服務不僅可以在已架設防火牆的資料中心內執行,也可以在公用雲端、私人雲端或第三方託管的服務中執行,而且不論在何處都必須安全無虞。

就像使用者會移動、使用不同的裝置,以及從不同的位置連線一樣,微服務也可以移動,並跨異質主機部署在不同的環境中。BeyondCorp 指出「對使用者的信任應取決於裝置的情境感知狀態等特性,而非連線至企業網路的能力」,BeyondProd 則指出「對服務的信任應取決於程式碼來源和服務身分等特性,而非服務在實際工作環境網路中的位置,例如 IP 或主機名稱身分」。

雲端原生架構和應用程式開發

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

但是,在雲端原生模型中,容器會將應用程式所需的二進位檔與基礎主機作業系統分離,並讓應用程式具有較高的可攜性。容器只適合以不可變更的方式使用,所以一旦部署後就無法變更,因此必須經常重新建構和重新部署。系統會針對工作調度資源以處理負載,並在負載增加時部署新的工作,以及在負載減少時取消現有的工作。由於容器的重新啟動、終止和重新排程作業頻繁,硬體和網路的重複使用與共用情況也會增加。利用通用的標準化建構作業和分配程序,即使團隊獨立管理其微服務開發作業,團隊之間的開發程序也會較為一致和統一。因此,安全性考量 (例如安全性審查、程式碼掃描和安全漏洞管理) 可以在開發週期的早期進行。

對安全性的影響

對於內部範圍不受信任的模型 (使用者在 BeyondCorp 內) 如何同樣適用於 BeyondProd 中的微服務,我們已進行了許多相關討論,但實際變更會是什麼情況?表 1 比較了傳統基礎架構安全防護機制的各個層面,以及對應的雲端原生架構要素。表格也列出了從傳統架構遷移至雲端架構時,必須符合的要求條件。本節的其餘部分將詳細介紹表中的每一列。

傳統基礎架構安全防護機制 雲端原生安全防護機制 對雲端原生安全防護機制的隱含要求
邊界式安全防護機制 (如防火牆),一律信任所有的內部通訊活動。 會驗證服務與服務間通訊的零信任安全機制,對環境中的服務沒有隱含的信任。 網路保護機制在邊緣位置仍適用,服務之間沒有固有的相互信任。
某些應用程式使用固定的 IP 和硬體。 更高的資源使用率、重複使用率和共用率,包括 IP 和硬體。 由受信任的機器執行來源已知的程式碼。
以 IP 位址為基礎的身分。 以服務為基礎的身分。
服務在已知的預期位置執行。 服務可以在環境中的任何位置執行,包括在公用雲端和私人資料中心的混合式部署項目中執行。
安全性專屬需求已內建至每個應用程式並分別強制執行。共用安全性需求已按照集中式強制執行政策整合至服務堆疊中。 透過堵塞點一致地在各服務上強制執行政策。
對如何建構和審查服務的限制有限。 安全性需求一致地套用至所有服務。
對安全性元件的監督有限。 集中顯示安全性政策和對政策的遵守情況。
推出作業不頻繁且具備專門用途。 標準化的建構和推出程序,對個別微服務的變更較為頻繁。 簡單、自動化且標準化的變更推出作業。
工作負載通常會部署為 VM 或部署至實體主機,並使用實體機器或管理程序來提供隔離措施。 分裝的工作負載和其程序會在共用的作業系統中執行,因此需要工作負載隔離機制。 共用作業系統的工作負載之間有所隔離。

表 1:遷移至雲端原生架構時的安全性隱含要求

從邊界式安全防護機制到零信任安全機制

在傳統的安全性模型中,機構的應用程式可以依賴其私人資料中心周圍的外部防火牆來針對連入流量提供防護。在雲端原生環境中,雖然仍然需要像 BeyondCorp 模型那樣保護網路邊界,但邊界式安全性模型已不再足夠。這雖然沒有造成新的安全性問題,但協助我們認清以下事實:如果防火牆無法完全保護企業網路,那它也無法完全保護實際工作環境網路。採用零信任安全性模型時,您就不能再給予服務隱含式的信任,而是必須採行其他安全性控管機制,例如驗證和加密。同時,改用微服務也會讓您有機會重新審視傳統的安全性模型。當您擺脫對單一網路邊界 (例如防火牆) 的依賴時,就可以依服務將網路進一步分段。如要進一步實踐這樣的概念,您可以在微服務層級進行分段,這樣一來,服務之間就不會存在固有信任。有了微服務,流量就能獲派不同層級的信任,而各層級又對應不同的控管機制,不再只是分辨內部與外部流量。

從固定的 IP 和硬體到更龐大的共用資源

在傳統的安全性模型中,組織的應用程式會部署到特定的機器,而這些機器的 IP 位址並沒有經常更新。換言之,安全性工具可依賴相對靜態的架構。在這種架構中,應用程式是以可預測的方式相互連結,因此防火牆等工具中的安全性政策可以使用 IP 位址做為 ID。

但是,在雲端原生環境中,由於共用主機且工作經常變更,因此使用防火牆來控管微服務之間的存取權並不可行。您不能依靠特定 IP 位址會連結至特定服務這個特性。因此,您應以服務做為身分的依據,而非 IP 位址或主機名稱。

從應用程式專屬的安全防護實作項目,到整合至服務堆疊的共用安全性要求

在傳統的安全性模型中,個別應用程式必須獨立負責滿足自己的安全性需求,且各自的需求與其他服務無關。這類需求包括身分管理、安全資料傳輸層 (SSL)/傳輸層安全標準 (TLS) 終止和資料存取權管理。此機制常會導致實作不一致,或安全性問題無法獲得解決,因為這類問題必須從多處修正,所以修正內容也較難套用。

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

從專用且不頻繁的推出程序,到推出作業較為頻繁的標準化程序

在傳統的安全性模型中,共用服務的情形有限。由於程式碼較為分散,加上開發作業於本機執行,在變更會牽動應用程式許多部分的情況下,就很難確定變更造成的實際影響,進而使得推出作業頻率低且難以協調。如要進行變更,開發人員可能必須直接更新每個元件 (例如,透過 SSH 連線至虛擬機器以更新設定)。整體而言,這使得應用程式的使用壽命變得極長。從安全性的角度來看,由於程式碼較為分散,因此較難審查,而修正一個安全漏洞後,要確保有這個漏洞的所有位置也都獲得修正,甚至更具挑戰。遷移至推出作業頻繁且標準化的雲端原生架構,便可以在軟體開發生命週期中提前進行2 安全性相關作業。這樣可以更簡單一致地強制執行安全性措施,包括定期套用安全性修補程式。

從透過實體機器或管理程序隔離的工作負載,到於同一部機器執行且需要更強隔離措施的分裝式工作負載

在傳統的安全性模型中,工作負載是在自己的執行個體上排程的,而且沒有共用資源。應用程式會由其機器和網路邊界有效地分隔,而工作負載隔離則僅依賴實體主機分離、管理程序和傳統的防火牆來強制執行。

在雲端原生環境中,工作負載均經過容器化並分裝到共用主機和共用資源中。因此,您的工作負載之間必須有更強的隔離措施。工作負載可以分離為多個微服務,而網路控制機制和沙箱技術則可對微服務進行部分隔離。

安全性原則

在開發雲端原生架構時,我們希望同時加強安全性,因此開發出以下安全性原則,並針對這些原則進行最佳化調整:

  • 在邊緣保護網路,使工作負載與網路攻擊及來自網際網路的未經授權流量可以有所隔離。以防火牆為基礎的方法並不是雲端原生架構中的新概念,但仍是提供安全防護的最佳做法。在雲端原生環境中,邊界式防護機制可以盡可能地保護基礎架構,以防止來自網際網路的未經授權流量和潛在攻擊,例如以「量」為手段的阻斷服務攻擊。

  • 服務之間沒有固有的相互信任,因此只有已知、受信任且已獲明確授權的呼叫者才能使用服務。這樣可以防止攻擊者使用不受信任的程式碼來存取服務。如果服務已經遭駭,則可以阻止攻擊者執行可以擴大危害範圍的操作。這種互不信任的做法有助於限制遭駭的範圍。

  • 由受信任的機器執行來源已知的程式碼,以便將服務身分限制為只能使用已獲授權的程式碼和設定,而且只能在經過驗證的授權環境中執行。

  • 透過堵塞點一致地在各服務上強制執行政策。例如,堵塞點可用於驗證對使用者資料的存取要求,如此一來,使用者就必須在自身已獲授權,且要求已通過驗證的情況下,才能存取服務,至於系統管理員若要取得存取權,則須提出業務上的正當理由。

  • 簡單、自動化且標準化的變更推出作業,讓您輕鬆審查基礎架構變更對安全性的影響,且推出安全性修補程式時對生產作業的影響很小。

  • 共用作業系統的工作負載之間具有隔離措施,因此即使有服務遭駭,也不會影響到同一部主機上執行之其他工作負載的安全。這種措施可以限制潛在入侵行為的影響範圍。

我們希望在整個基礎架構中,實現不仰賴人類操作的自動化安全防護機制。安全性的擴充方式應該與服務的擴充方式相同。服務在預設情況下應屬安全,在例外情況下才會發生安全性問題,而人類操作即應視做例外狀況,而非經常性事件,且發生時應該要能稽核。然後,我們便可以根據為服務所部署的程式碼和設定 (而非部署服務的人員) 來驗證服務。

綜合以上所述,只要實作這些安全性原則,容器與運行於容器當中的微服務就能順利部署、彼此通訊,且可以並行執行,而不會削弱雲端原生架構的特性,即工作負載管理作業簡便、免人工管理即可進行資源調度,以及能有效進行分裝作業。這一切都可以實現,而個別微服務開發人員也無須煩惱基礎架構的安全性和實作細節。

Google 的內部安全性服務

為了保護 Google 的雲端原生基礎架構,我們設計且開發了一些內部工具和服務。以下列出的安全性服務可以共同滿足安全性原則一節中所定義的安全性原則:

  • Google Front End (GFE):可終止與使用者的連線,並充當強制執行 TLS 最佳做法的中央位置。即使邊界式安全防護機制已不再是我們的重心,GFE 在我們內部服務的阻斷服務攻擊防護策略中,仍是重要的一環。GFE 是使用者連線至 Google 的第一個進入點;進入我們的基礎架構後,GFE 還將負責進行負載平衡,並視需要在區域之間重新轉送流量。在我們的基礎架構中,GFE 是可將流量轉送至正確微服務的邊緣 Proxy。

  • 應用程式層傳輸安全性 (ALTS):用於遠端程序呼叫 (RPC) 驗證、完整性和加密。ALTS 是雙向驗證和傳輸加密系統,適用於 Google 基礎架構中的服務。身分通常是繫結至服務,而不是特定伺服器名稱或主機。這有利於在各個主機之間順利複製微服務、平衡負載以及重新排程。

  • Borg 適用的二進位授權主機完整性分別用於微服務及機器完整性驗證:

    • Borg 適用的二進位授權 (BAB):一種部署期間強制檢查,可在部署程式碼前確保該程式碼滿足內部安全性需求。BAB 檢查包括由第二位工程師審核變更、將程式碼提交至 Google 的原始碼存放區,以及在專屬的基礎架構上以可驗證的方式建構二進位檔。在我們的基礎架構中,BAB 禁止使用者部署未經授權的微服務。
    • 主機完整性 (HINT):經由安全的啟動程序,驗證主機系統軟體的完整性。此服務是透過支援此作業的安全微控制器硬體執行。HINT 檢查包括驗證 BIOS、BMC、系統啟動載入程式和 OS 核心上的數位簽名。
  • 服務存取政策使用者情境票證會用於限制對資料的存取權:

    • 服務存取政策:限制服務存取彼此資料的方式。RPC 從一項服務傳送至另一項時,服務存取政策會針對接收 RPC 的服務,定義存取服務資料的驗證、授權和稽核政策。這樣可以限制資料的存取方式、授予所需的最低存取權層級,以及指定該存取權的稽核方式。在 Google 的基礎架構中,服務存取政策會限制一個微服務對另一個微服務的資料存取權,並提供對存取權控管機制進行全域分析的功能。
    • 使用者情境 (EUC) 票證:這些票證由使用者驗證服務發出,並可為服務提供與其服務身分不同的使用者身分。這些票證是完整性受保護、集中發出且可轉送的憑證,可以認證發出服務要求的使用者所具備的身分。這種憑證減少了服務之間要取得信任的需要,因為 ALTS 提供的對等身分通常並不足以授予存取權,而此類授權決定通常也是以使用者的身分為基礎。
  • 可進行藍/綠部署的 Borg 工具3:這項工具負責在執行維護工作時遷移正在執行的工作負載。除了現有的 Borg 工作之外,系統也會部署新的 Borg 工作,而負載平衡器則會逐漸將流量從舊有工作轉移到新的工作。如此一來,便可在無須停機,且使用者也不會注意到的情況下更新微服務。當我們加入新功能時,這個工具可用於套用服務升級,以及在不停機的情況下套用重要的安全性更新 (例如,Heartbleed 和 Spectre/Meltdown 的安全性更新)。對於會影響 Google Cloud 基礎架構的變更,我們使用即時遷移來確保 VM 工作負載不會受到影響。

  • gVisor,用於隔離工作負載。gVisor 會透過使用者空間核心來攔截和處理系統呼叫,從而減少與主機的互動,並縮減潛在受攻擊面。這個核心可提供執行應用程式所需的大部分功能,並且會限制應用程式可存取的主機核心部分。在 Google 基礎架構中,我們使用了幾個重要工具,藉此隔離於同一部主機執行的內部工作負載和 Google Cloud 客戶工作負載,而 gVisor 就是其中的一項工具。

表 2 將「安全性原則」一節說明的各項原則,對應至 Google 用於實作這些原則的相應工具。

安全性原則 Google 的內部安全性工具/服務
在邊緣位置保護網路 Google Front End (GFE),用於管理 TLS 終止作業和連入流量的政策
服務之間沒有固有的相互信任 應用程式層傳輸安全性 (ALTS),用於 RPC 驗證、完整性、加密和服務身分
由受信任的機器執行來源已知的程式碼 Borg 適用的二進位授權 (BAB),用於程式碼來源驗證

主機完整性 (HINT),用於機器完整性驗證

透過堵塞點一致地在各服務上強制執行政策 服務存取政策,用於限制服務存取彼此資料的方式

使用者情境 (EUC) 票證,用於認證原始要求者的身分

簡單、自動化且標準化的變更推出作業 Borg 工具,用於進行藍/綠部署
共用作業系統的工作負載之間的隔離措施 gVisor,用於隔離工作負載

表 2:Google 實作雲端原生安全防護機制的原則和安全性工具

全面整合使用

在本節中,我們將說明要上面討論的各項元件,如何合力在雲端原生環境中完成使用者要求。我們會使用兩個示例來說明:第一個是追蹤一般使用者資料要求從建立到目的地交付的流程,第二個則是追蹤從開發到實際工作環境的程式碼變更。此處列出的技術並不是全都應用於 Google 基礎架構的所有部分,各項服務和工作負載使用的技術並不相同。

存取使用者資料

如圖 1 所示,GFE 收到使用者的要求時 (步驟 1),會終止 TLS 連線,並透過 ALTS4將要求轉送至適當服務的前端 (步驟 2)。應用程式前端會使用中央使用者驗證 (EUA) 服務驗證使用者的要求,如果成功,就會收到短期的密碼編譯使用者情境票證 (EUC) (步驟 3)。

圖表

圖 1:Google 的雲端原生架構安全性控管機制:存取使用者資料

然後,應用程式前端會透過 ALTS 向儲存後端服務發出 RPC,並在後端要求中轉送 EUC 票證 (步驟 4)。後端服務會使用服務存取政策來確保:

  1. 前端服務的 ALTS 身分已取得授權,可向後端服務發出要求並出示 EUC 票證;
  2. 前端的身分受 Borg 適用的二進位授權 (BAB) 保護;而且
  3. EUC 票證有效。

接下來,後端服務會檢查 EUC 票證中的使用者是否取得授權,能夠存取所要求的資料。如果這些檢查中有任何一個失敗,系統就會拒絕該要求。在許多情況下,系統會有一連串的後端呼叫,每個媒介服務都會對傳入的 RPC 執行服務存取政策檢查,而 EUC 票證則經由傳出的 RPC 轉送。如果通過這些檢查,系統便會將資料傳回獲授權的應用程式前端,並提供給獲得授權的使用者。

每部機器都有一個透過 HINT 系統佈建的 ALTS 憑證,而且只有在 HINT 驗證該機器啟動成功後才能解密。大多數 Google 服務都會以微服務的形式在 Borg 之上執行,而這些微服務都有自己的 ALTS 身分。Borgmaster 5 會根據微服務的身分將這些 ALTS 微服務憑證授予工作負載,如圖 1 所示。機器層級 ALTS 憑證形成了佈建微服務憑證的安全通道,因此只有成功通過 HINT 驗證開機程序的機器,才能實際託管微服務工作負載。

進行程式碼變更

如圖 2 所示,Google 員工對強度適當的 BAB 所保護的微服務進行變更時,必須將變更內容提交至 Google 的中央程式碼存放區,接受強制執行的程式碼審查。經核准後,變更內容會提交至受信任的中央建構系統,而該系統則會產生一個套件,當中具有已簽署且可驗證的建構資訊清單憑證 (步驟 1)。在部署期間,BAB 會驗證來自建構管道的已簽署憑證,以驗證相關事務均按照前述程序進行 (步驟 2)。

圖表

圖 2:Google 的雲端原生架構安全性控管機制:進行程式碼變更

所有工作負載更新都會透過藍/綠部署進行處理,無論是經常性的推出作業還是緊急安全性修補程式都一樣 (步驟 3)。為了達成負載平衡,GFE 會將流量轉送至新的部署作業,以確保作業能持續執行。

所有工作負載都需要隔離。如果工作負載的受信任等級較低,例如工作負載是多用戶群,或者原始碼是來自 Google 外部,則可部署至受 gVisor 保護的環境中,或者使用其他隔離層來處理。這種隔離措施可確保當應用程式的一個執行個體遭駭時,其他執行個體都不會受到影響。

應用 BeyondProd

全力以赴

Google 採用雲端原生架構並適當保護此基礎架構後,得以為內部和外部 (Google Cloud) 工作負載提供極高的安全性。

建構共用元件後,就可以盡量減輕個別開發人員為了滿足常見安全性需求,因此而承受的負擔。在理想情況下,安全防護功能應幾乎不須整合至個別應用程式,而是以涵蓋並連接所有微服務的結構形式提供。這通常稱為服務網格。換句話說,安全性機制的管理與實作,可以獨立於一般的開發和部署活動。

改用雲端原生架構

Google 轉換至雲端原生架構時,需要在兩個大方面做出改變:基礎架構和開發程序。我們同時進行了兩方面的變更,但是這些變更也可加以分離,再獨立進行處理。

改變我們的基礎架構

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

改變我們的開發程序

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

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

我們很快就發現,一開始先讓服務對違反政策的情形進行記錄,而不要直接封鎖,會比較容易實現目標。這種方法有雙重好處。首先,這個方法讓服務擁有者有機會測試改變的結果,以及評估遷移至雲端原生環境將對其服務產生的影響 (如果有的話)。其次,這樣的做法也讓我們能夠修正所有錯誤,以及確定可能需要提供給服務團隊的其他功能。例如,將服務加入 BAB 後,服務擁有者可啟用「僅限稽核」模式。這將有助於他們識別不符合需求的程式碼或工作流程。服務擁有者解決了「僅限稽核」模式檢查出的問題後,便可以切換至強制執行模式。在 gVisor 中,我們首先透過對工作負載採用沙箱機制 (即使沙箱功能中存在相容性差異),然後以系統化的方式解決這些差異以改進沙箱,最後達成相同的結果。

改用雲端原生架構的好處

就如同 BeyondCorp 協助我們跨越了邊界式安全性模型的防護方式,BeyondProd 同樣也代表了實際工作環境安全機制的一大進步。BeyondProd 方法說明了一種雲端原生安全防護機制架構,該架構假設服務之間不存在信任關係、在工作負載之間提供隔離措施、驗證系統僅部署集中建構的應用程式、自動進行安全漏洞管理,以及對重要資料強制執行嚴格的存取權控管機制。BeyondProd 架構引導 Google 建立了幾個新系統以滿足這些需求。

安全性機制經常是在已決定遷移至新架構以後,才納入考量。盡早讓您的安全性團隊參與,並專注於新安全性模型的優點,例如簡化的修補程式管理和更嚴格的存取權控管機制,雲端原生架構就可以為應用程式開發和安全性團隊帶來極大的益處。將本文概述的安全性原則套用至您的雲端原生基礎架構後,您就可以強化工作負載的部署作業、工作負載通訊的防護機制,以及工作負載間的交互影響。

附註

1 Borg 是 Google 的叢集管理系統,用於大規模排程和執行工作負載。Borg 是 Google 的第一個統一容器管理系統,也是 Kubernetes 的靈感來源。

2「提前進行相關作業 (shifting left)」是指在軟體開發生命週期中,提早執行某些步驟,其中可能包括編寫程式碼、建構、測試、驗證和部署等等。生命週期圖表經常是從左到右繪製,因此左邊代表較早採取的步驟。

3 藍/綠部署是一種在不影響連入流量的情況下,對工作負載推出變更的方法,能讓使用者在存取應用程式時,不會遇到任何停機時間。

4 如要進一步瞭解流量如何在 Google 的基礎架構中從 GFE 轉送至某個服務,請參閱我們流動資料加密機制白皮書中的流量轉送方式一節。

5 Borgmaster 是 Borg 的集中式控制器,用於管理工作的排程,並與正在執行的工作通訊以瞭解其狀態。