圖 1. Access Proxy (source: https://www.beyondcorp.com/)

上篇瞭解到所有用戶訪問都要經過 Access Proxy，而 Access Proxy 是建立在 Google 的 Global network 基礎上，其底層技術是 Google 的前端基礎設施稱爲 Google Front End (GFE)。

上篇也留了幾個疑問：

1. GFE 是什麼？
2. Access Proxy 中的身份驗證和授權具體是怎麽實現的？
3. 這種集中式授權有沒有短板？
4. 後端又是怎麽去確保所接收的用戶訪問確實是經過驗證和授權的呢？

這篇我們繼續讀下去~

本篇大部分爲論文翻譯，有些大標題是筆者自下，詳見出處：Google's frontend infrastructure: "The Access Proxy"

GFE 是什麼？

Google 的前端基礎設施稱爲 Google Front End (GFE)，主要的組成部分其實就是一堆 HTTP/HTTPS reverse proxies。GFE 提供的功能包含 TLS handling as a service、防禦 DDoS 攻擊，以及 load balancing。這使得 GFE 後面的 Web 應用程序可以專注於回應服務請求，而在很大程度上不用去管請求的路由。

圖 2. GFE (source: https://cloud.google.com/docs/security/infrastructure/design?hl=zh-cn#google-frontend-service)

GFE 和 Access Proxy 的關係

BeyondCorp 利用 GFE 作爲邏輯上的集中訪問政策執行點。以這種方式來進行請求導向使 Google 能夠自然地擴展 GFE 的功能，以 GFE 爲基礎新增身份驗證、授權和集中式記錄等功能。擴展功能後的 GFE 稱爲 Access Proxy (AP)。

Access Proxy 透過引入身份驗證和授權來擴增 GFE 的功能。

Features of the Extended GFE: Product requirements

• 驗證 (Authentication)
• 授權 (Authorization)
• 集中日誌記錄 (Centralized Logging)

1. 驗證 (Authentication)

在多平臺環境下，驗證設備會面臨一些挑戰，這個在 Google's frontend infrastructure: "The Access Proxy" 的 “多平臺認證的挑戰” 章節有詳細討論，但我們這篇先不會提到這一章節，也不會談到設備驗證。本節主要討論用戶身份驗證。

Access Proxy 透過和 Google 的身份提供者 (IdP) 集成來驗證用戶身份。

由於要求後端服務改變其身份驗證機制不具備可擴展性，因此，Access Proxy 本身需要支援多種驗證方法，包含 OIDC、OAuth、和一些自定義協議。除此之外，Access Proxy 也需要處理沒有帶用戶憑證 (user credentials) 的請求，例如，軟件管理系統需要下載最新的安全更新以進行系統升級。在這樣的用例中，Access Proxy 可以禁用身份驗證。

當 Access Proxy 對用戶進行驗證後，它會將憑證剝離，再將訪問導到後端應用程序。將憑證剝離是很重要的，因爲：

1. 後端應用程序無法透過訪問 Access Proxy 而回訪用戶請求。
2. Access Proxy 對後端而言是透明的。因此，後端可以在 Access Proxy 通過的基礎上實現自己的驗證流程，而不會觀察到任何超出意料範圍的 cookie 或憑證。

2. 授權 (Authorization)

在 BeyondCorp 架構中，授權機制的實現受到了兩個設計選擇的驅動：

1. 一個可通過 RPC 查詢的集中式 Access Control List (ACL) 引擎
2. 一種用來表達 ACL 的領域特定語言 (Domain-Specific Language, DSL)，這個語言需要具備可讀性和可擴展性

透過將 ACL 評估作爲一項服務 (ACL evaluation as a service)，Google 能夠確保在多個 front-end gateways（例如，RADIUS network access control infrastructure, Access Proxy, SSH proxy） 間保持一致性。

2.1. 集中式授權有沒有短板？

然而，透過 Access Proxy 提供集中授權 (Authorization) 有優點也有缺點。一方面，集中授權帶來了強一致性，同時也降低了後端的工作量，讓後端開發人員免於處理授權細節。但是另一方面，proxy 可能無法執行細粒度的 policy (fine-grained policy)（例如用戶有權修改資源 B），這些細粒度的 policy 通常在後端設定效果更好。

以 Google 的經驗看來，在 Access Proxy 上進行集中式且粗粒度的授權機制，輔以後端細粒度的授權機制，保留了兩者的優點，是推薦做法。這種方法不會導致工作重複的現象，因爲應用程序特定的細粒度授權 policy 往往與 front-end infrastructure 的企業範圍 policy 在很大程度上是正交關係。

2.2. 如何確保後端流量確實經過認證和授權？

由於後端將訪問控制委託給 GFE，因此後端有必要確保所接收到的流量是經過前端認證和授權的。這一點尤爲重要，因爲 Access Proxy 終止了 TLS 握手，後端是通過一個加密通道接收到 HTTP 請求。

爲了確保後端所接收到的流量是經過前端認證和授權的，需要一個能夠建立加密通道的雙向認證方案。Google 的解決方案是一個內部開發的認證和加密框架，稱爲 LOAS (Low Overhead Authentication System)，它會對 Access Proxy 到後端的所有請求進行雙向認證和加密。

在 Access Proxy 和後端之間進行雙向認證和加密的一個好處是後端可以信任由 Access Proxy 插入的任何附加元數據（通常以額外的 HTTP header 形式存在）。盡管在 Access Proxy 和後端之間添加元數據並使用自定義協議並不是一種新穎的方法，但雙向認證方案確保了元數據不可偽造。

除此之外，我們還可以在 Access Proxy 上逐步部署新功能。這樣的話後端只要解析相應標頭即可。我們利用這個功能將設備的信任級別傳播到後端，然後後端可以根據這個信任級別調整響應中提供的詳細程度。

2.3. ACL 語言

在解決集中授權的挑戰中，制定一種用來表達 Access Control List (ACL) 的領域特定語言 (Domain-Specific Language, DSL) 是關鍵。該語言既允許我們靜態編譯 ACL（有助於提高性能和可測試性），又有助於減少 access policy 與實現 policy 之間的邏輯差距 (reduce the logical gap between the policy and its implementation)。

制定 ACL 語言促進了以下各團隊的職責分工，實現了低耦合的組織架構：

• 負責 Security Policy 的團隊：負責制定 Policy
• 負責 Inventory Pipeline 的團隊：負責根據設備或用戶身份 grant 相應的權限
• 負責 Access Control Engine 的團隊：負責評估和執行 Policy

目前我們實施的 ACL 結構包括兩個 macro-sections：

1. Global rules: 通常是粗粒度的，並影響到所有服務和資源。例如，“低層設備 (devices at a low tier) 不允許提交源代碼。”
2. Service-specific rules: 針對特定 service 或 hostname 所設定，通常涉及到指定用戶。例如，“用戶 A 有權使用資源 B”。

其中，Global rules 在面對特權提升 (privilege escalation) 或突發事件響應 (incident response) （例如瀏覽器漏洞或設備不見）時非常有用。

特權提升 (privilege escalation)：特權提升攻擊是一種網絡攻擊，攻擊者透過應用程序的設計缺陷或操作系統的疏忽，取得比應用程式開發者或系統管理員預期的更高的特權，從而可以執行授權的動作。瞭解更多請看 維基百科

例如，Google 透過設定 Global rules 成功地降低了 Chrome 瀏覽器附帶的第三方插件相關的零日漏洞 (zero-day vulnerabilities)。我們創建了一個新的高優先級規則，將過時的 Chrome 版本重定向到一個包含更新說明的頁面，並在 30 分鐘內部署和強制執行到整個公司。結果，易受攻擊的瀏覽器的數量迅速下降。

零時差漏洞 (zero-day vulnerability): 指軟體、韌體或硬體設計當中已被公開揭露但廠商卻仍未修補的缺失、弱點或錯誤。或許，研究人員已經揭露這項漏洞，廠商及開發人員也已經知道這項缺失，但卻尚未正式釋出更新來修補這項漏洞。這樣的缺失就是所謂的「零時差」漏洞，因為廠商及開發人員 (以及受此漏洞影響的企業和使用者) 才剛知道這個漏洞的存在。隨後，當廠商及開發人員針對這個漏洞提供了修補更新，那這漏洞就會變成「已知」漏洞 (有時亦稱為 N-day 漏洞)。 參考來源：https://blog.trendmicro.com.tw/?p=62238

3. 集中日誌記錄 (Centralized Logging)
   為了進行適當的事件響應和取證分析，將所有用戶請求記錄到持久存儲是至關重要的。Access Proxy 提供了一個理想的集中日誌記錄點。其中 Log 的資料包含 request headers、HTTP response code、還有一些相關元數據如 device identifier 和 user identity。

================= 我是夜晚終於結束的分割線 =======================
至此，我們讀完了 BeyondCorp 前端基礎設施 Access Proxy 的 server side 功能，包含 Authentication、Authorization，和 Centralized Logging。（撒花！！不過昨天這個點閱率哈哈哈哈太無聊了嗎。。。QQ我覺得好有趣的說。anyway不管~~）

下回，我們來讀 Google 在設計 Access Proxy 時的 lessons learned，作爲這個架構元件的小節。（我們先跳過“多平臺認證的挑戰”這一章節，等講完 Access control engine、pipeline、Trust inference 等其他組件後再回來提這個。

再見！