eyondCorp 是 Google 零信任網絡的實現。本篇論文是系列論文中的第三篇，文中總結了多平臺身份驗證的挑戰、在實際環境中可能遇到的異常情況，并分享了在實施過程中的經驗教訓。論文強調的訪問代理可擴展性，也正是作為訪問代理實現的 Pipy 重要設計特色之一。

下面是論文的翻譯。

本文詳細介紹了 BeyondCorp 前端基礎架構的實現。重點介紹了訪問代理（Access Proxy），我們在其實施過程中遇到的挑戰以及在設計和推出過程中所學到的經驗教訓。我們還涉及了一些當前正在進行的項目，以提升員工訪問內部應用程序的整體用戶體驗。

在遷移到 BeyondCorp 模型時（前文已討論過的“BeyondCorp：企業安全的新方法”[^1] 和“BeyondCorp：Google 的設計與部署”[^2]），Google 需要解決許多問題。如何在所有僅限內部的服務中執行公司策略成為一個顯著的挑戰。傳統的方法可能會將每個后端與設備信任推斷器集成，以評估適用的策略；然而，這種方法會顯著減慢我們能夠推出和更改產品的速度。

為了應對這個挑戰，Google 實施了一個集中的策略執行前端訪問代理（Access Proxy，AP）來處理粗粒度的公司策略。我們實現的 AP 足夠通用，可以使用相同的 AP 代碼庫來實現邏輯上不同的網關。目前，訪問代理同時實現了 [^2] 中討論的 Web 代理和 SSH 網關組件。由于 AP 是唯一允許員工訪問內部 HTTP 服務的機制，我們要求所有內部服務都遷移到 AP 后面。

不出所料，僅處理 HTTP 請求的初步嘗試證明是不夠的，因此我們不得不針對其他協議提供解決方案，其中許多協議需要端到端加密（例如 SSH）。這些額外的協議需要進行一些客戶端的更改，以確保設備能夠正確地識別給 AP。

AP 和訪問控制引擎（共享的 ACL 評估器）的組合提供了兩個主要的優勢。通過為所有請求提供一個共同的日志記錄點，它使我們能夠更有效地進行取證分析。我們還能夠比以前更快、更一致地更改執行策略。

BeyondCorp 的前端基礎架構

任何大規模部署的現代 Web 應用都會使用前端基礎架構，通常是負載均衡器和/或反向 HTTP 代理的組合。企業級 Web 應用也不例外，前端基礎架構提供了部署策略執行點的理想位置。因此，Google 的前端基礎架構在 BeyondCorp 的訪問策略執行中占據了關鍵位置。

Google 前端基礎架構的主要組件是一組稱為 Google 前端（GFE）的 HTTP/HTTPS 反向代理。GFE 提供了許多好處，例如負載均衡和 TLS 處理作為一種服務。因此，Web 應用的后端可以專注于處理請求，而無需過多關注請求的路由細節。

BeyondCorp 利用 GFE 作為邏輯上的集中式訪問策略執行點。通過以這種方式引導請求，我們自然地擴展了 GFE 以提供其他功能，包括自助配置、身份驗證、授權和集中日志記錄。所得到的擴展 GFE 稱為訪問代理（AP）。下一部分詳細介紹了訪問代理提供的服務的特定內容。

擴展 GFE 的功能：產品需求

GFE 提供了一些內置的好處，這些好處并非專門為 BeyondCorp 設計：它既為后端提供了負載均衡，又通過將 TLS 管理委托給 GFE 來處理 TLS。AP 通過引入身份驗證和授權策略來擴展 GFE。

身份驗證

為了正確授權請求，訪問代理（AP）需要識別發出請求的用戶和設備。在多平臺環境中對設備進行身份驗證會面臨一些挑戰，我們將在后面的部分“多平臺身份驗證的挑戰”中討論這些問題。本節重點介紹用戶身份驗證。

AP 通過與 Google 的身份提供者（IdP）集成來驗證用戶身份。考慮到要求后端服務更改其身份驗證機制以使用 AP 機制缺乏可擴展性，因此 AP 需要支持一系列身份驗證選項：OpenID Connect、OAuth 和一些自定義協議。

AP 還需要處理沒有用戶憑據的請求，例如軟件管理系統嘗試下載最新的安全更新。在這些情況下，AP 可以禁用用戶身份驗證。

當 AP 對用戶進行身份驗證后，它在將請求發送到后端之前會去除憑據。這樣做的原因有兩個關鍵點：

• ? 后端無法通過訪問代理重播請求（或憑據）。

• ? 代理對后端是透明的。因此，后端可以在訪問代理的流程之上實施自己的身份驗證流程，并且不會觀察到任何意外的 cookie 或憑據。

授權

在 BeyondCorp 世界中，我們的授權機制實施受到兩個設計選擇的推動：

• ? 通過可遠程過程調用（RPC）查詢的集中訪問控制列表（ACL）引擎

• ? 一種既可讀又可擴展的領域特定語言來表達 ACL

將 ACL 評估作為一種服務提供可以確保多個前端網關（如 RADIUS 網絡訪問控制基礎設施、AP 和 SSH 代理）之間的一致性。

提供集中授權既有好處又存在一些缺點。一方面，授權前端使得后端開發人員無需處理授權的詳細細節，通過提倡一致性和集中的策略執行點，解放了后端開發人員。另一方面，代理可能無法強制執行細粒度的策略，這些策略在后端處理更好（例如，“用戶 A 被授權修改資源 B”）。

根據我們的經驗，將 AP 中的粗粒度集中授權與后端中的細粒度授權相結合，可以兼顧兩者的優點。這種方法不會導致太多的工作重復，因為應用程序特定的細粒度策略往往與由前端基礎架構強制執行的企業范圍策略基本上是正交的。

代理與后端之間的雙向認證

由于后端將訪問控制委托給前端，因此后端必須能夠相信其接收到的流量已經經過前端的身份驗證和授權。這一點尤為重要，因為 AP 終止了 TLS 握手，后端通過加密通道接收到 HTTP 請求。

滿足這個條件需要一種能夠建立加密通道的雙向認證方案，例如可以實施雙向 TLS 認證和企業公鑰基礎架構。我們的解決方案是一個內部開發的認證和加密框架，名為 LOAS（Low Overhead Authentication System），可以實現代理到后端之間的雙向身份驗證和加密所有通信。

雙向認證和加密前端與后端之間的通信的一個好處是后端可以信任 AP 插入的任何附加元數據（通常以額外的 HTTP 標頭的形式）。雖然在反向代理和后端之間添加元數據并使用自定義協議不是一種新穎的方法（例如，參見 Apache JServe Protocol [^4]），但 AP 之間的雙向認證方案確保元數據無法偽造。

作為額外的優勢，我們還可以逐步在 AP 上部署新功能，這意味著允許后端服務可以通過解析相應的標頭來選擇加入。我們利用這個功能將設備的信任級別傳遞給后端服務，后者可以相應地調整響應中提供的詳細程度。

ACL 語言

為 ACL 實現一個領域特定語言是解決集中授權挑戰的關鍵。這種語言不僅允許我們靜態編譯 ACL（有助于性能和可測試性），還有助于減少策略和實現之間的邏輯差距。這種策略促進了以下各方責任的分離：

• ? 擁有安全策略的團隊： 負責訪問決策的抽象和靜態編譯規范

• ? 擁有庫存流水線的團隊： 負責根據特定設備和請求訪問的用戶來具體實現對資源的訪問決策（有關庫存流水線的更多細節，請參閱 [2]）

• ? 擁有訪問控制引擎的團隊： 負責評估和執行安全策略

ACL 語言使用首次匹配語義，類似于傳統防火墻規則。雖然這種模型會產生一些經過深入研究的邊界情況（例如，相互覆蓋的規則），但我們發現安全團隊相對容易理解這種模型。我們目前強制執行的 ACL 結構由兩個宏部分組成：

• ? 全局規則： 通常是粗粒度的，影響所有服務和資源。例如，“低層級的設備不允許提交源代碼”。

• ? 特定服務的規則： 針對每個服務或主機名的具體規則；通常涉及對用戶的斷言。例如，“組 G 中的供應商被允許訪問 Web 應用程序 A”。

上述假設是服務所有者能夠識別出需要制定策略的 URL 空間的部分。除了一些在請求體中進行區分的情況（盡管可以修改 AP 來處理這種情況），服務所有者幾乎總是能夠識別出這些部分。與特定服務的規則相關的 ACL 部分隨著 Access Proxy 為越來越多需要專門 ACL 的業務服務提供支持而逐漸增大。

全局規則集在安全升級（例如員工離職）和事件響應（例如瀏覽器漏洞或設備丟失）時非常有用。例如，這些規則幫助我們成功緩解了與我們 Chrome 瀏覽器一起發貨的第三方插件的零日漏洞。我們創建了一個新的高優先級規則，將過時版本的 Chrome 重定向到一個帶有更新說明的頁面，該規則在 30 分鐘內在整個公司范圍內部署和強制執行。結果，受漏洞影響的瀏覽器的使用人數迅速下降。

集中式日志記錄

為了進行適當的事件響應和取證分析，將所有請求記錄到持久存儲中至關重要。訪問代理（AP）提供了一個理想的日志記錄點。我們記錄請求頭的子集、HTTP 響應代碼以及與調試或重建訪問決策和 ACL 評估過程相關的元數據。這些元數據包括與請求關聯的設備標識符和用戶身份。

訪問代理的特點：操作可擴展性

自助配置

一旦訪問代理基礎架構就位，企業應用程序的開發人員和所有者就有動力配置其服務以通過代理訪問。

當 Google 逐漸限制用戶對企業資源的網絡級訪問時，大多數內部應用程序所有者將訪問代理視為在遷移進行時保持其服務可用的最快解決方案。很明顯，一個團隊無法擴展以處理對 AP 配置的所有更改，因此我們設計了 AP 的配置，以便促進自助添加。用戶保留其配置片段的所有權，而擁有 AP 的團隊則擁有編譯、測試、金絲雀部署和配置發布的構建系統。

這種設置有幾個主要的好處：

• ? 使 AP 所有者無需根據用戶請求不斷修改配置

• ? 鼓勵服務所有者擁有自己的配置片段（并為其編寫測試）

• ? 在開發速度和系統穩定性之間找到合理的折中方案

在 AP 后面設置服務所需的時間已經有效縮短到幾分鐘，而用戶也能夠在不需要 AP 團隊的支持的情況下迭代其配置片段。

多平臺身份驗證的挑戰

現在我們已經描述了 BeyondCorp 前端的服務器端 - 實現及其帶來的挑戰和復雜性 - 現在我們將對這個模型的客戶端部分進行類似的觀察。

至少，要進行正確的設備識別，需要兩個組成部分：

• ? 設備標識符的某種形式

• ? 跟蹤任何給定設備的最新已知狀態的庫存數據庫

BeyondCorp 的一個目標是用適當的設備信任替代對網絡的信任。每個設備必須具有一致的、不可克隆的標識符，而設備的軟件、用戶和位置信息必須集成在庫存數據庫中。正如在前面的 BeyondCorp 論文中討論的那樣，構建和維護設備庫存可能非常具有挑戰性。下面的小節詳細描述了與設備識別相關的挑戰和解決方案。

臺式機和筆記本電腦

臺式機和筆記本電腦使用 X.509 機器證書和相應的私鑰存儲在系統證書存儲中。密鑰存儲是現代操作系統的標準功能，它確保通過 AP 與服務器通信的命令行工具（和守護程序）能夠與正確的設備標識符進行一致匹配。由于 TLS 要求客戶端提供私鑰擁有權的加密證明，這種實現使得標識符無法偽造和克隆，前提是它存儲在安全硬件（如可信平臺模塊 TPM）中。

這種實現有一個主要的缺點：證書提示通常會讓用戶感到沮喪。值得慶幸的是，大多數瀏覽器支持通過策略或擴展自動提交證書。如果服務器拒絕了 TLS 握手時客戶端提供的無效證書，用戶也可能感到沮喪。失敗的 TLS 握手會導致特定于瀏覽器的錯誤消息，無法自定義。為了緩解這個用戶體驗問題，AP 接受沒有有效客戶端證書的 TLS 會話，并在需要時呈現一個 HTML 拒絕頁面。

移動設備

上述討論的減少證書提示的策略在主要移動平臺上并不存在。與其依賴證書，我們使用移動操作系統本身提供的強大設備標識符。對于 iOS 設備，我們使用 ForVendor 標識符，而 Android 設備使用企業移動管理應用程序報告的設備 ID。

特殊情況和異常情況

盡管在過去幾年中，我們已經成功將絕大多數 Web 應用程序遷移到了訪問代理，但一些特殊用例要么不適應該模型，要么需要某種特殊處理。

非 HTTP 協議

Google 的許多企業應用程序采用需要端到端加密的非 HTTP 協議。為了通過 AP 提供這些協議，我們將它們包裝在 HTTP 請求中。

將 SSH 流量包裝在 HTTP over TLS 中很容易，得益于現有的 ProxyCommand 功能。我們開發了一個本地代理，它看起來很像 Corkscrew，只是將字節包裝成了 WebSockets。雖然 WebSockets 和 HTTP CONNECT 請求都允許 AP 應用 ACL，但我們選擇使用 WebSockets 而不是 CONNECT，因為 WebSockets 在本質上繼承了瀏覽器的用戶和設備憑證。

對于 gRPC 和 TLS 流量，我們將字節包裝在一個 HTTP CONNECT 請求中。包裝的明顯缺點是對傳輸協議施加了（可忽略的）性能損耗。然而，它有一個重要的優點，

即在協議堆棧的不同層次上將設備識別和用戶識別分開。基于庫存的訪問控制是一個相對較新的概念，因此我們經常發現現有的協議在用戶身份驗證方面具有本地支持（例如，LOAS 和 SSH 都提供此功能），但將其與設備憑證擴展在一起是不簡單的。

因為我們在包裝 CONNECT 請求的 TLS 層上執行設備識別，所以我們不需要修改應用程序使其了解設備證書。考慮 SSH 用例：客戶端和服務器可以使用 SSH 證書進行用戶身份驗證，但 SSH 并不本地支持設備身份驗證。此外，修改 SSH 證書以傳遞設備識別將是不可能的，因為 SSH 客戶端證書是可移植的設計：它們預計將在多個設備上使用。類似于我們處理 HTTP 的方式，CONNECT 的包裝確保我們正確地區分了用戶和設備身份驗證。雖然我們使用 TLS 客戶端證書對設備進行身份驗證，但我們可能使用用戶名和密碼對用戶進行身份驗證。

遠程桌面

Chrome Remote Desktop 是 Google Chrome 代碼庫中公開提供的主要遠程桌面解決方案 [^5]。雖然在許多情況下在 HTTP 中包裝協議是可行的，但是一些協議（例如遠程桌面）對由通過 AP 路由導致的附加延遲特別敏感。

為了確保請求得到正確的授權，Chrome Remote Desktop 在連接建立流程中引入了一個基于 HTTP 的授權服務器。該服務器充當了 Chromoting 客戶端和 Chromoting 主機之間的授權第三方，同時還幫助這兩個實體共享一個密鑰，類似于 Kerberos 的操作方式。

我們將授權服務器實現為 AP 的簡單后端，并帶有自定義的 ACL。這個解決方案已經證明非常有效：每個遠程桌面會話只需承擔一次 AP 帶來的額外延遲，而訪問代理可以在每個會話創建請求上應用 ACL。

第三方軟件

第三方軟件經常會帶來麻煩，有時它們無法提供 TLS 證書，有時又假設直接連接。為了支持這些工具，我們開發了一種自動建立加密點對點隧道（使用 TUN 設備）的解決方案。軟件對隧道一無所知，并且表現得好像直接連接到服務器一樣。隧道建立機制在概念上與遠程桌面的解決方案類似：

• ? 客戶端運行一個助手來設置隧道。

• ? 服務器也運行一個充當 AP 的后端的助手。

• ? AP 執行訪問控制策略，促進客戶端和服務器助手之間的會話信息和加密密鑰的交換。

經驗教訓

ACL 是復雜的

我們推薦以下最佳實踐來減輕與 ACL 相關的困難：

• ? 確保語言是通用的。 AP 的 ACL 已經多次改變，我們不得不添加新的數據源（例如，用戶和組源）。預計您將需要定期更改可用功能，并確保語言本身不會妨礙這些更改。

• ? 盡早啟動 ACL。 這樣做的原因有兩個：

• ? 確保用戶盡早熟悉 ACL 以及可能導致拒絕訪問的原因。

• ? 確保開發人員開始調整他們的代碼以滿足 AP 的要求。例如，我們不得不實現一個 cURL 替代品來處理用戶和設備身份驗證。

• ? 使修改成為自助服務。 如前所述，負責管理特定服務配置的單個團隊無法支持多個團隊。

• ? 創建一種從 AP 傳遞數據到后端的機制。 如上所述，AP 可以安全地將附加數據傳遞給后端，以允許其執行精細的訪問控制。要早早規劃這個所需的功能。

緊急情況會發生

為處理不可避免的緊急情況制定經過充分測試的計劃。確保考慮以下兩個主要類別的緊急情況：

• ? 生產緊急情況： 由請求處理路徑中關鍵組件的故障或故障引起。

• ? 安全緊急情況： 由緊急需要向特定用戶和/或資源授予/撤銷訪問權限引起。

生產緊急情況

為了確保 AP 能夠在大多數故障中保持正常運行，根據 SRE 的最佳實踐 [^3] 進行設計和操作。為了在潛在的數據源故障中保持正常運行，我們的所有數據都定期進行快照，并且可以在本地訪問。我們還設計了不依賴 AP 的 AP 修復路徑。

安全緊急情況

安全緊急情況比生產緊急情況更加微妙，因為在設計訪問基礎設施時很容易忽視它們。一定要考慮 ACL 推送頻率和 TLS 問題對用戶/設備/會話撤銷的影響。

撤銷用戶相對比較簡單：撤銷用戶時，會自動將其添加到一個特殊組中，并且在 ACL 中的一個早期全局規則（請參見上文的“ACL 語言”部分）確保這些用戶被拒絕訪問任何資源。類似地，會話令牌（例如 OAuth 和 OpenID Connect 令牌）和證書有時會泄漏或丟失，因此需要撤銷。

如第一篇 BeyondCorp 文章所討論的，設備標識符在設備庫存管道報告之前是不可信的。這意味著即使丟失證書頒發機構（CA）密鑰（這意味著無法撤銷證書），也不意味著失去控制，因為只有在正確地編目在庫存管道中的新證書之后才會信任它們。

鑒于這種能力，我們決定完全忽略證書吊銷：我們不發布證書吊銷列表（CRL），而是將證書視為不可變的，并簡單地降低庫存信任級別，如果我們懷疑相應的私鑰丟失或泄漏。實質上，庫存充當接受的設備標識符的白名單，對 CRL 沒有實時依賴。這種方法的主要缺點是可能引入額外的延遲。但是，通過在庫存和訪問代理之間工程快速傳播，這種延遲相對容易解決。

為了確保及時執行策略，您需要一套標準的快速推送 ACL 的過程。在一定規模以上，您必須將至少部分 ACL 定義過程委托給服務所有者，這必然會導致錯誤。盡管單元測試和煙霧測試通常可以捕捉到明顯的錯誤，但邏輯錯誤會穿過保護措施并進入生產環境。工程師能夠快速回滾 ACL 更改以恢復丟失的訪問權限或鎖定意外的廣泛訪問權限是很重要的。舉個例子，早期的零日漏洞插件，我們之所以能夠

迅速推送 ACL 對我們的事件響應團隊至關重要，因為我們可以快速創建一個自定義 ACL 來強制用戶進行更新。

工程師需要支持

過渡到 BeyondCorp 模式不會一蹴而就，需要多個團隊之間的協調和互動。在大型企業規模下，不可能將整個過渡委托給一個團隊。遷移可能涉及一些不兼容的更改，需要充分的管理支持。

過渡的成功在很大程度上取決于團隊成功將其服務設置在 Access Proxy 后面的難易程度。讓開發人員的工作更容易應該是主要目標，因此應盡量減少意外情況的發生。提供合理的默認設置，為最常見的用例創建步驟指南，并投資于文檔。為更高級和復雜的更改提供沙盒環境，例如可以設置 Access Proxy 的單獨實例，負載均衡器故意忽略它，但開發人員可以訪問（例如，暫時覆蓋其 DNS 配置）。沙盒在許多情況下都證明非常有用，例如當我們需要確保在對 X.509 證書或底層 TLS 庫進行重大更改后，客戶端能夠處理 TLS 連接。

展望未來

雖然我們在 BeyondCorp 的前端實現在很大程度上取得了成功，但仍然存在一些痛點。最明顯的是，桌面和筆記本電腦使用證書進行身份驗證，而移動設備使用不同的設備標識符。證書更替仍然是一個痛點，因為呈現新證書需要重新啟動瀏覽器，以確保現有的套接字被關閉。

為了解決這兩個問題，我們計劃將桌面和筆記本電腦遷移到移動設備模型，這將消除證書的需求。為了進行遷移，我們計劃構建一個桌面設備管理器，它將與移動設備管理器非常相似。它將提供一個共同的標識符，即設備 - 用戶 - 會話 -ID（DUSI），該標識符將在所有瀏覽器和使用共同 OAuth 令牌授權守護程序的工具中共享。一旦遷移完成，我們將不再需要通過證書對桌面和筆記本電腦進行身份驗證，并且所有的控制都可以使用 DUSI 在所有操作系統上保持一致。

結論

作為 BeyondCorp 核心組件的 Access Proxy 的實施是針對我們的基礎架構和用例的。我們最終實現的設計與常見的 SRE 最佳實踐高度一致，已經證明非常穩定和可擴展 - 在部署過程中，AP 的規模增長了數個數量級。

任何尋求實施類似安全模型的組織都可以應用創建和部署類似 AP 的解決方案的基本原則。我們希望通過分享我們在多平臺身份驗證、特殊情況和異常處理方面的解決方案以及在該項目中學到的經驗，能夠幫助其他組織以最小的痛苦采取類似的解決方案。

參考文獻

[^1]: R. Ward and B. Beyer, “BeyondCorp: A New Approach to Enterprise Security,”*;login:,* vol. 39, no. 6 (December 2014): https://www.usenix.org/system/files/login/articles/login_dec14_02_ward.pdf.

[^2]: B. Osborn, J. McWilliams, B. Beyer, and M. Saltonstall, “BeyondCorp: Design to Deployment at Google,”*;login:,* vol. 41, no. 1 (Spring 2016): https://www.usenix.org/system/files/login/articles/login_spring16_06_osborn.pdf.

[^4]: Apache JServer Protocol: https://tomcat.apache.org/connectors-doc/ajp/ajpv13ext.html.

[^5]: https://src.chromium.org/viewvc/chrome/trunk/src/remoting/.

[^3]: B. Beyer, C. Jones, J. Petoff, and N. Murphy, eds., Site Reliability Engineering (O’Reilly Media, 2016).