本文做爲 BeyondCorp 架構元件的小結，我們來看整體架構，包含元件之間的連線。

圖 1. BeyondCorp components and access flow 01 (source: https://www.beyondcorp.com/)

本篇內容大多爲論文翻譯，詳見出處：An overview: "A New Approach to Enterprise Security"

端到端的舉例 (An End-to-End Example)

應用程式 (The Application)

讓我們假設有一個應用程式——codereview.corp.google.com——要運行在 BeyondCorp 架構下。這個應用程式是讓工程師用來審查、評論、更新、提交源碼的工具，僅開放來自於使用受管設備的全職和兼職工程師訪問。

配置面向網路的 Access Proxy

codereview 的管理員負責爲應用程序配置 Access Proxy。配置指定了後端的位置和每個後端能夠接受的最大流量。codereview.corp.google.com 的域名會在公共 DNS 中被註冊，並透過設定 CNAME 將該域名指向 Access Proxy。

例如，透過 dig 指令查看 codereview.corp.google.com 的 DNS 配置，會發現 answer section 中 CNAME 將該域名指向 access proxy:

圖 2. dig command

配置 Access Control Engine

Access Control Engine 提供了一個 default rule，限制只有使用受管設備的全職工程師才能訪問。該應用程式的管理者可以進一步設定更具體的訪問規則: 只有最高信任級別的受管設備和最高信任級別的員工可以訪問該應用。

當工程師連上網路...

情境一：網路位於企業運營的實體建築之外

只要工程師使用 Google 提供的辦公電腦（受管設備），他就可以連上任何 WiFi 網路，無論是機場 WiFi 或 咖啡廳 WiFi，不需要設置到公司的 VPN。

情境二：網路位於企業運營的實體建築之內

如果工程師使用的是 Google 提供的辦公電腦（受管設備），那麼當工程師連上企業內的非特權網路時，該設備會在與 RADIUS server 的 802.1x 協議握手過程中提供其設備證書。如果工程師使用的不是受管設備，或者其憑證到期，那麼該設備會被在修復網路 (remediation network) 中分配到一個地址，而該網路的訪問權限就非常有限了。

無論網路如何，都可以訪問應用

圖 3. BeyondCorp components and access flow 02 (source: An overview: "A New Approach to Enterprise Security")

從公司提供的辦公電腦上訪問 codereview 應用的流程如下，可以參考上圖：

1. 訪問被導到 Access Proxy。受管設備提供其設備證書。
2. Access Proxy 不認識請求的用戶，並將訪問重定向至 SSO 服務。
3. 工程師輸入身份驗證憑據（可能包含雙因素認證），通過 SSO 系統領取到 token，並被重定向至 Access Proxy。
4. 現在，Access Proxy 擁有了設備證書和 SSO token，分別代表了設備和用戶。
5. Access Control Engine 會根據 Access Control list 執行針對 codereview 應用的驗證檢查。這個授權檢查在每次請求都會進行，檢查項目例如：
   • 確認該用戶來自於 engineer group
   • 確認該用戶擁有足夠的信任等級
   • 確認請求的設備是受管設備，且狀態良好
   • 確認請求的設備有足夠的信任等級
   • 如果上述所有驗證都通過，請求便可以順利通過並轉發給相應後端
   • 如果有一項驗證沒通過，那麼請求遭拒

就是透過這種方法，我們可以針對每次用戶請求執行堅實的、 service-level 的驗證和授權檢查。

好的這就是今天的內容~明天我們將進入下一個討論階段—— Google 是如何將內部轉型到 BeyondCorp 架構的？

明天見！