本篇內容來源於文獻： BeyondCorp and the long tail of Zero Trust: Handling the most challenging use cases at Google

前情提要：先前的 BeyondCorp 系列文章討論了 Google 是如何將內部所有應用程序從 Managed Privileged Client (MPC) 遷移到 Managed Non-Privileged (MNP) 網路。

（是的專有名詞總是令人望而生畏。所以要在文章一開始 highlight。）

例外管理

對於 Alphabet 龐大的員工群體來說，手動批準個人的例外情況是不可行的。因此，我們創建了一個例外系統 (exception system)，允許全職員工自行授予 Managed Privileged Client (MPC) 權限，以解決已知不兼容的工作流。而臨時工或供應商則可以通過管理者來請求 MPC 權限。

我們還繼續允許技術支持團隊的要求為其用戶創建新的例外群組。這無疑再次增加了長尾的複雜性。

除了用戶透過例外系統自己申請 MPC，以及技術支持團隊創建的例外群組之外，還有一部分重要的工作流也被授予網路級別的例外權限。也就是說，即使在非特權網絡上，也允許某些特權流量，而不管發起流量的用戶是誰。這類的例外又被稱爲 “MNP 漏洞”，包含：

• 印表機：公司設備直接訪問印表機。
• SSH：跨公司網絡的直接 SSH 訪問，原因是需要高頻寬。
• 緊急 IRC 訪問：公司設備直接訪問 SRE 用於緊急通信所使用的 IRC 服務器。

IRC（Internet Relay Chat的縮寫，「網際網路中繼聊天」）是一種透過網路的即時聊天方式。其主要用於群體聊天，但同樣也可以用於個人對個人的聊天。IRC使用的伺服器埠有6667（明文傳輸，如 irc://irc.freenode.net ）、6697（SSL加密傳輸，如 ircs://irc.freenode.net:6697 ）等。（維基百科）

雖然允許這些例外存在確保了業務的連續性，但它們持續的時間往往比最初預期的要長。由於例外情況包含了很多關鍵業務，我們通常很難將其歸類給單一的管理層。

在最初的 MNP 取得成功後，管理層對遷移到 BeyondCorp 的支持減弱，同時長尾解決方案的開發資金面臨不足。我們用於發現工作流程的數據分析管線也被終止。

因此，“長尾”一直存在，而且成為一個不斷增長的用戶群體，分別有幾十人到數千人不等的組別，其需求對 BeyondCorp 團隊變得越來越不透明。

經驗教訓：

• 例外系統可以確保在遷移困難用例時保持業務連續性。
• 例外情況應該有期限，並需要定期更新。如果有網絡日誌可供使用，例外情況也可以在未使用的情況下自動過期。
• 每個例外情況都一定需要一個技術支持團隊。為了降低用戶獲取不必要的例外情況的風險，用戶是否符合例外情況資格應由支持團隊負責的另一個流程來控制。
• 控制和最終消除過於寬泛的安全例外需要在 Security Engineering、Support、變動管理、SRE 和項目管理方面投資。"等待團隊更新或更改其基礎設施" 的策略將無法創造全面的變革。

解决方案、臨時解决方案和缓解措施

隨著團隊從特權網絡中遷移出來，他們通常會將工作流程或基礎架構轉移到 BeyondCorp 內部的一個主要解決方案上。

對於來自瀏覽器的 HTTPS 流量，Access Proxy 仍然是主要的內部解決方案。而非瀏覽器 HTTPS 客戶端被配置為使用 forward proxy，在請求時將用戶和設備憑證代入，以便通過 Access Proxy 的驗證和授權。這個 forward proxy 由內部開發，在客戶端運行，監聽 localhost。

我們還開發了一種 microsegmented VPN 解決方案，作為需要在網絡之間進行任意 IP 連接的工具的備選選擇。它的工作方式類似於傳統的 VPN，但擴充了一些功能，增加了對無法運行任意應用程序的終端（通常是嵌入式系統）的支持。micro segmented VPN 還與現有的 BeyondCorp access control 機制集成，用於授權。重要的是，它與 VPN 的不同之處在於，它只為每個用戶提供一組預先配置的後端精細網絡訪問。 (It contrasts with VPN by providing fine-grained network access to only a set of pre-configured backends per user.)

如圖 1 所示，microsegmented VPN 支持兩種傳輸應用數據的方法：

• 通過 BeyondCorp Proxy 建立 Websocket，以提高連接穩定性。
• 通過 NAT 或防火牆建立 Interactive Connectivity Establishment (ICE)，以獲得高吞吐量。

圖 1. Microsegmented VPN 架構 (source: BeyondCorp and the long tail of Zero Trust: Handling the most challenging use cases at Google)

除了上述 "純粹 "的 BeyondCorp 解決方案外，我們還采用了一個重要的 "折衷" 解決方案：現有的內部 VPN 服務。

在 COVID-19 大流行導致居家辦公期間，我們不知道如何支持非 BeyondCorp 的工作流程，因為根據定義，特權網路只存在於辦公室內。在某些情況下，員工仍然可以遠程訪問辦公室內的工作站來完成工作，但在其他情況下，根本沒有合適的短期硬件選擇。

在這種情況下，VPN 在許多團隊中脫穎而出，成為一種相對熟悉、成熟和全球可用的服務，允許用戶在家工作，同時保留基於 IP 的權限，盡管我們不能將其作為長期解決方案來依賴。在整個 2020 年和 2021 年，許多技術支持團隊與安全部合作，確保公司的 VPN 適合他們的工作流程。通過將這些 MPC 用例轉移到 VPN，我們能夠撤銷用戶的 MPC 訪問權限，前提是他們在辦公室內繼續使用 VPN。

圖 2. BeyondCorp 解決方案排名 (source: BeyondCorp and the long tail of Zero Trust: Handling the most challenging use cases at Google)

如圖 2. 所示，VPN 並不是與 BeyondCorp 兼容的最佳解決方案，因為它無法消除基於網絡的信任。雖然它被用於某些特殊的使用案例，但其余的使用案例將被遷移到不同的方案中。

然而，VPN 相對於特權網絡提供了三個關鍵的優勢：

• 對允許流量的策略具有粗粒度控制，每個必要流量都有已知的所有者。
• 提供了遷移到 microsegmented VPN 解決方案的明確路徑。
• 即使對於那些沒有明確永久解決方案的工作流程，也可以消除網路特權 (network privilege)，防止隨著時間的推移出現對該特權的新依賴。

最後，我們使用以下解決方案解決了前一節中描述的現有 MNP 漏洞：

• 印表機：將打印的工作流遷移到第三方雲托管的解決方案，通過 HTTPS 進行操作。
• SSH：將用戶遷移到內部開發的 BeyondCorp SSH proxy。
• 緊急 IRC 訪問：將 IRC 服務器遷移到 Google 的生產基礎設施，只能從受信任的機器通過 Access proxy 訪問，但要確保與已知的災難恢覆場景和策略保持兼容。

經驗教訓：

• 沒有單一解決方案適用於所有情況。對於常見情況，簡單、專用的解決方案可以減輕 BeyondCorp 的操作負擔並提供更好的用戶體驗。選擇最合適的解決方案，而不是一個通用的選項。
• 要務實，準備好遷移到具有明確前進路徑的中間解決方案，或在不同策略之間進行權衡，以確保業務連續性。