圖 1. 遷移到 BeyondCorp 概覽 (source: An overview: "A New Approach to Enterprise Security")

圖 2. 將設備遷移到受管非特權網路的流程 (source: Migrating to BeyondCorp: "Maintaining Productivity while Improving Security")

本篇內容來自於論文：Migrating to BeyondCorp: "Maintaining Productivity while Improving Security"

成功導向的遷移（續）

將簡單用例透過 Access Proxy 訪問

Google 的基本安全策略要求所有從工作站流向服務器的流量都必須符合以下條件：

• Authenticated 經過驗證（以識別發出請求的設備和用戶）
• Authorized 經過授權（驗證用戶和設備是否允許訪問後台資源）
• Encrypted 經過加密（防止竊聽）
• Independently logged 獨立記錄（有助於取證分析）

對於 HTTP/S 流量和我們的 HTTP 封裝 SSH 流量，Access Proxy 可以滿足所有這些要求。

令人高興的是，我們的大多數高用量應用程序都是基於瀏覽器的應用程序 (browser-based Web application)。這種情況既令人高興，也是有意設計的：Google 的核心理念是盡可能使用基於瀏覽器的應用程序，這在業界是獨一無二的。我們向每個應用程序團隊提供了需要的工具和文檔，以便他們可以配置應用程序，使其運行在 Access Proxy 後面。

當一個應用程序在 Access Proxy 背後時，企業和公共 DNS 包含一個 CNAME，解析到 Access Proxy，因此這些應用程序的 URL 可以被方便和安全地使用，不管是從企業非特權網路或公共網路。從公共網絡訪問企業應用程序的能力意味著經過身份驗證的遠程用戶可以在無需啟動 VPN 連接的情況下訪問企業 Web 應用程序。因此，使用和支持遠程工作的 VPN 連接的開銷立即大幅減少。根據我們粗略的估算，這種生產力的增益輕鬆超過了 BeyondCorp 的實施成本。

一旦基於瀏覽器的應用程序得到 Access Proxy 的保護，我們就能夠取得顯著的進展。我們啟動了一個自動流程，用於分析、驗證和遷移設備到非特權網絡；在一年內，這個流程將超過 50％ 的設備移動到非特權網絡訪問。

處理困難的用例

前篇提到過，不是所有應用程序都可以順利地遷移。雖然我們可以透過 Access Proxy 處理絕大多數應用程序，但有些應用程序深深依賴 NFS，例如 CAD (computer-aided design) editor。因此在將這些設備轉移到受管非特權網路 (Managed Non-Privileged, MNP) VLAN 之前，我們需要特殊的解決方案。這需要新的工具、技術和工作流程。

特別是，有些 “thick client” 應用程序它們不基於 HTTP，或有些應用程序需要 3rd party desktop，這就造成了一系列特殊的問題。例如：

• 有些工具本質上依賴於網絡掛載的文件共享 (network mounted file shares)。
• Java 應用程序可能使用 RMI（Remote Method Invocation）或其他 direct socket connection。
• 許多工具可能使用非 HTTP sockets 和 protocols 來連接到 license server。

“thick client” 是指在客戶端計算機上運行的應用程序或軟件，通常這些應用程序在計算機本地端執行大部分的運算和數據處理工作，而不是依賴於遠程伺服器或雲端服務。因此 "thick client" 需要在本地維護，通常需要更多的計算資源。相對而言，“thin client” 主要依賴於遠程伺服器或雲端來執行應用程序的運算和處理。

即便是使用 HTTP 的應用程序，也可能會因為不明顯或意想不到的故障而出現問題。例如，有些應用程序（例如 IoT 設備）並未設計成要提供 client certificate 或正確的 user credential，而有些應用程序在負載平衡層中內建了與 Access Proxy 不相容的邏輯。對於這些特殊情況，我們調整了 Access Proxy，允許來自 MNP VLAN 的流量在不需要證書的情況下通過 Access Proxy。我們對這個臨時策略感到放心，因為在接觸到 Access Proxy 之前，設備必須先提供證書才能訪問到受管非特權網路（所以即便 Access Proxy 不需要證書，在非特權網路那段已經驗證過一回了）。我們針對每個有問題的特殊情況進行診斷和補救。

為了應對這一類困難情況，我們開發了一個解決方案——在客戶端和伺服器之間透過一個加密伺服器 (encryption server)，建立多端口加密隧道 (multi-port encrypted tunnel) 在客戶端和伺服器之間傳輸應用程序流量：

• 當從客戶端向伺服器發起連接時，Access Proxy 使用正常的用戶和設備身份驗證和授權。
• 客戶端上的路由表將封包定向到一個 TUN 設備，該設備捕獲並加密流向特定後端伺服器的流量。
• 在客戶端和加密伺服器 (encryption server)之間，加密封包使用基於 UDP 的封裝協議傳輸。
• 加密伺服器 (encryption server) 僅允許客戶端流量進入需要訪問的服務和端口

建立加密隧道的方法使一些 legacy 3rd party 應用程序能夠更安全地從任何網絡連接到其伺服器，並仍然保持 BeyondCorp 在驗證、授權和加密方面的不變性。

表 1. 解決困難用例的方法 (source: Migrating to BeyondCorp: "Maintaining Productivity while Improving Security")

上表顯示了我們解決困難工作流的方法。在某些情況下，表中所示的解決方案還要求用戶通過運行腳本修改工作流程，或在訪問後台資源前提供必要的身份驗證。

隨著我們解決每個應用程序或使用案例，自動化的分析、驗證和遷移過程將更多用戶和設備移至非特權 VLAN。隨著我們的進展，網絡日誌記錄和分析提供了有關在 MNP 上成功的用戶和設備數量的即時指標。

逐步推出和持續改善我們的遷移方法

在設備上部署 MNP simulator、部署 traffic analysis pipeline、自動化地將設備分配到 MNP VLAN ，這些是重要的軟體開發和流程項目。因此，我們採漸進式地開發和部署：我們在特定群體中進行測試、不斷修復、在適當的時候告知用戶、培訓 technical support team、然後逐步擴展到全面部署。

好的以上就是今天的內容。結合上篇我們可以瞭解到，Google 在技術上是如何成功地將設備遷移到受管非特權網路的，包含：

• 在設備上部署 MNP simulator 並先使用 loggin mode 再使用 enforcement mode
• 在路由器上記錄和分析所有流量 (traffic analysis pipeline)
• 自動化地將設備遷移到非特權網路
• 用雲端硬碟取代 NFS
• 針對特殊情況設計特殊解決方法，例如針對無法使用 Access Proxy 的後端，透過加密伺服器建立客戶端和伺服器端的加密隧道

明天我們來讀這篇論文的最後一部分：如何降低遷移對員工的影響？

明天見！