Google 內部遷移至 BeyondCorp 架構是一個耗時數年的工程。

下文出自 2014 年 12 月，Google 在發表這篇文獻的時候 BeyondCorp 還在實施的過程中。其後幾年，Google 又陸續出了幾篇文獻說明落地的進度和 lessons learned。這幾天我會按照順序，從第一篇論文開始看起。這樣我們可以知道整個遷移進程，有哪些是一早就知道的，而哪些是中途遇到問題後修正的結果。（其實就是還沒讀到後面咳咳

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

圖 1. migrating to BeyondCorp (source: An overview: "A New Approach to Enterprise Security")

遷移到 BeyondCorp

像世界上的其他企業一樣，Google 多年來一直維護著為其客戶和應用程序提供的特權網絡 (privileged network)。這種模式已經成爲堅實的基礎設施的一部分。盡管公司的所有部門都將遷移到 BeyondCorp，但一次性將所有用戶和應用程序轉移到 BeyondCorp 架構中，對業務的正常運作而言是風險極高的。

因此，我們在分階段遷移方面進行了大量投資，並成功地在不影響生產力的情況下將大批用戶遷移到 BeyondCorp。下面章節詳細描述了我們所做的一些工作，如圖 1. 所示。

流量鑑定 (Workflow qualification)

在 Google 使用的所有應用程序都需要通過 Access Proxy 工作。

BeyondCorp 對所有應用程序進行審查和評估，這些應用程序完成的任務範圍從簡單（例如支持 HTTPS 流量）到複雜（例如 SSO 集成）。每個應用程序都需要執行 Access Proxy 的配置，並且在 Access Control Engine 中爲應用程序設定。

遷移至 BeyondCorp 的進程中，所有應用程序都經歷了以下漸進式的改造過程：

1. 應用程序可以通過特權網絡直接訪問，也可以通過 VPN 從外部訪問
2. 應用程序可以在特權網絡上直接訪問，也可以通過外部或非特權網絡上的 Access Proxy 進行訪問。在這種情況下，我們使用了分割 DNS。內部命名服務器直接指向應用程序，外部命名服務器指向 Access Proxy
3. 應用程序可以從外部網路、特權網路或非特權網絡上透過 Access Proxy 訪問

小結：最後所有訪問應用程序的流量不再區分外部或內部，所有流量都要經過 Access Proxy。

分析團隊的工作職能

財務、銷售、法律或工程團隊，誰應該先遷移至 BeyondCorp 架構呢？

爲了分配遷移至 BeyondCorp 架構的用戶\群組順序，我們分析了公司內部各團隊的工作職能，並將此信息和 workflow qualification 進行交叉參考。

小結：不是一股腦的一次將所有團隊遷移至 BeyondCorp 架構，而要根據職能分階段進行。

減少 VPN 的使用

隨著越來越多的應用程序被部署在 Access Proxy 後，我們開始鼓勵用戶（員工）不要使用 VPN，改採以下策略：

• 用戶必須有實際的需要且通過審核後，才能使用 VPN
• 監控用戶 VPN 的使用情況，針對在一段特定時間內沒有使用 VPN 的用戶，刪除其使用權限
• 監控活躍 VPN 用戶的 VPN 使用情況，如果他們的流量是可以通過 Access Proxy 的，那麼我們會強烈建議用戶放棄其 VPN 訪問權限

小結：要教育用戶減少使用 VPN。

流量分析管道 (Traffic Analysis Pipeline)

很重要的一點是，只有當我們確定（或非常接近確定）用戶的所有工作流都可以從非特權網路中訪問時，我們才會將用戶遷移到此非特權網路環境下。爲了確認其確定性，我們建了一個流量分析管道 (traffic analysis pipeline) 來分析流量。

作爲管道的輸入，我們對公司所有的 switch 進行數據抽樣。接著，將這些樣本數據與非特權網絡和公司其他網絡之間的標準 ACL 進行分析。這種分析使我們能夠確定會通過和不會通過 ACL 的流量，並列出了這些不通過的流量。接下來，我們可以將不通過的流量與特定工作流程、特定用戶或特定設備關聯起來。然後，我們逐步處理和修正不通過的流量，使其在 BeyondCorp 環境中正常運行。

小結：透過流量分析管道，列出在 BeyondCorp 架構中不能 work 的流量有哪些，並逐一處理。

模擬非特權網路

為了增強流量分析管道，我們除了使用 switch 上的樣本數據外，還透過在連接到 Google 網絡的所有用戶設備上安裝一個流量監視器 (traffic monitor)，用來模擬公司範圍內的非特權網絡行為。該流量監視器會逐個設備地檢查所有的進出流量，並比較非特權網絡與公司其他網絡之間的 ACL 驗證，記錄未通過驗證的流量。流量監視器有兩種模式：

• Logging mode: 捕獲不合格的流量，但仍然允許不合格的流量離開設備
• Enforcement mode: 捕獲並禁止不合格的流量

小結：通過在設備上安裝流量監視器 (traffic monitor) 模擬公司範圍內的非特權網路行爲。

遷移策略

通過流量分析管道和模擬非特權網路的實施，我們制定並正在實施分階段的遷移策略，具體如下：

1. 根據職能、工作流程和/或地點確定潛在的遷移候選人。
2. 在 Logging mode 下運行流量監視器，篩選出在連續 30 天內具有超過 99.9％ 符合條件流量的用戶和設備。
3. 對於在該期間具有超過 99.99％ 符合條件流量的用戶和設備，激活流量監視器的 Enforcement mode。如有需要，用戶可以將監視器恢覆為 Logging mode。
4. 成功在 Enforcement mode 下運行監視器 30 天後，將此事實記錄在 Device Inventory 中。
5. 除了成為候選人集合的一部分外，成功在模擬器的 Enforcement mode 下運行 30 天提供了一個強烈的信號，即當 RADIUS 服務器接收到下一個 802.1x 身份驗證請求時，該設備應被分配到非特權網絡中。

豁免處理

除了盡可能自動化地遷移用戶和設備從我們的特權網絡到新的非特權網絡外，我們還實施了一個簡單的流程，供用戶請求臨時豁免於遷移。我們維護了一個已知列表，列出了尚未符合 BeyondCorp 標準的工作流程。用戶可以搜索這些工作流程，並在獲得正確的批準級別後，將自己和自己的設備標記為某個工作流程的活躍用戶。當工作流程最終符合遷移標準時，標記其下的用戶將收到通知，並再次有資格被選中進行遷移。

完成 BeyondCorp

我們向 BeyondCorp 的遷移正在順利進行，其中大部分工作流已經符合要求。遷移工具和策略使我們能夠積極地將用戶、設備和工作流程遷移到 BeyondCorp，而不會影響日常生產力。

我們預計將有一長串工作流程需要一段時間才能轉移到 BeyondCorp。例如，使用專有協議與服務器對話的客戶端應用程序，他們的遷移將是一個挑戰。

我們正在研究如何通過與身份驗證服務配對來實現類似的應用程序，以更進一步地實現 BeyondCorp。在我們推進遷移到 BeyondCorp 的過程中，我們打算發布後續文章，解釋為什麽以及 Google 是如何實現 BeyondCorp 的，以鼓勵其他企業采用類似的策略。

明天，我們來看 2017 年 Google 針對遷移至 BeyondCorp 的專題文獻~~

明天見！