前篇提到了 Google 提出的解決方案，用於解決 BeyondCorp 架構下非特權網絡無法兼容的工作流，也即例外情況或稱 "長尾"。解決方案包含：

• Access Proxy
• Microsegmented VPN
• VPN

有了解決方案，下一步便是提出針對遷移 "長尾" 的策略。因此今天我們來看本篇文獻的最後一章——遷移策略。

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

遷移策略

當我們對用例進行分析，確定了該用例適用哪些解決方案時，我們就開始遷移的過程。我們的總體目標是撤銷部分用戶的 Managed Privileged Client (MPC)，引導他們使用前篇提到的解決方案作遷移，而這一過程可能會改變用戶的工作流程。

如何選擇解決方案呢？這取決於：

• 目標用戶群的規模和一致性
• 要遷移的團隊與技術支持團隊和 SME (Subject Matter Expers) 迄今的合作程度
• 用於驗證解決方案的用戶測試，其測試的深度如何

在遷移過程中，很重要的是您需要考慮到候選解決方案可能不適用於某些用戶（例如由於地理位置相關的延遲）。此外，您可能會在遷移過程中發現新的不兼容的工作流， which 可能會讓應用程序團隊感到驚訝。

爲了降低這些風險，我們創建並自動化了一個融入了變更管理最佳實踐的標準遷移流程，包含：

1. 提前和個別用戶溝通，明確遷移日期。
2. 為用戶提供文檔，清晰描述解決方案，提供常見問題解答，以及鏈接到先前遷移文檔的鏈接。
3. 分階段在多天內逐步推出。
4. 提供用戶自助式臨時退出機制，明確告知用戶其例外情況的有效日期，要求用戶提供有關工作流程的補充信息，並（有可能的話）請用戶提供技術支持團隊或 SME 的聯系方式。

透過利用自助式退出機制來收集工作流程的補充信息，我們能夠清楚識別出應該和哪個技術支持團隊合作，以解決 "長尾中的長尾" (long tail of the long tail) 問題。

經驗教訓：

• 在技術支持團隊和 SME 的協助下，將遷移的驗收測試標準化 (formalize acceptance testing)
• 遵循變更管理的最佳實踐，例如逐步推出、廣泛溝通、明確時間表和提供常見問答集

洞見

總體而言，消除 BeyondCorp 架構的長尾可以分爲以下步驟：

1. 確定爲 "長尾" 提供技術支援的技術支持團隊和 SME 是誰。
2. 和該技術支持團隊或 SME 合作。瞭解這些 ”長尾“ 用戶的工作流。針對工作流提出遷移的解決方案，並驗證。
3. 透過標準遷移流程，將用戶遷移到該解決方案。
4. 透過選擇退出遷移的用戶所提供的補充信息，發現新的不兼容 BeyondCorp 非特權網路架構的工作流，以及未來針對該用例應該和哪個技術支持團隊或 SME 合作。

上述的每個步驟可以獨立執行，和技術支持團隊和 SME 一起協作完成，我們稱之爲 "Engagement"（如下圖）。爲了執行這些 "Engagement" ，我們集結了一支團隊，其中包含安全工程師、first-level support 和變更管理專家、相關解決方案的 SME 以及項目經理 (program manager)。

圖 1. High-level execution tracks of the "BeyondCorp Long Tail" program (source: BeyondCorp and the long tail of Zero Trust: Handling the most challenging use cases at Google)

由於人手和時間的限制，並非每個用戶都有資格與 BeyondCorp 團隊合作。如果用戶基數小，我們會盡最大努力找到遷移工作流程方面的專家，並提前幾個月告知用戶遷移期限。這些個人和團隊可以預約辦公時間進行快速咨詢。

爲了進一步提高員工對長尾遷移項目的認識，我們利用了高層的人際網路，並且透過內部郵件的形式提供月度進度報告，內容包含即將進行遷移的通知。

重要的是，我們始終提前數月爲技術支持團隊提供明確的遷移期限，讓支持團隊能夠有足夠的時間為他們的用戶準備遷移。此外，我們還提供了一套標準的升級流程，允許支持團隊及其管理層提出他們的需求，以確保資源和優先級的合理分配。

技術支持團隊可以根據需要使用升級流程來延長期限，以確保順利遷移。對於那些工作流程沒有得到正式支持的大規模用戶群體，他們可以通過升級流程來找到願意承擔必要遷移和支持工作的團隊。這種合作和協調確保了用戶的平穩過渡和項目的成功實施。

經驗教訓：

1. 與現有的技術支持團隊和專家合作，並鼓勵他們在向用戶推出零信任模型之前進行實驗和測試。
2. 向用戶和技術支持團隊傳達明確的遷移截止日期，並提供一個可以上報給項目發起人的標準化升級流程。
3. 當沒有正式的技術支持團隊為用戶群體提供支持時，需要建立一個機制以引起高層的關注和資源，讓高層支持或終止相關工作流程。
4. 將問題的通用部分標準化，並將其作為一項服務提供給可能沒有這方面專業知識的支持團隊。

結論

Alphabet 內 BeyondCorp 的故事還在繼續。我們將努力把剩餘的 VPN 透過合適的解決方案過渡到非特權網路。而 BeyondCorp Enterprise 的發展也爲我們提供了重要的融合機會，使我們能夠逐步淘汰內部的解決方案，實現更高的標準化。

隨著企業採用 BeyondCorp 原則，他們將不可避免地遇到看似和非特權網路不兼容的用例，需要在安全性、可靠性、用戶體驗和其他因素間謹慎權衡。我們希望透過本文所描述的解決方案可以幫助讀者安排他們自己的遷移過程，並爲權衡提供參考。

最後，我們認識到應用層（尤其是基於 HTTP）的應用程序在安全方面的價值，因爲他們有助於 proxy 和流量檢查。提供類似於 VPN 的疊加網路通常缺乏 HTTP proxy 的透明度和細粒度訪問權限控制，這降低了 BeyondCorp 的價值並可能導致對疊加網路造成依賴。

完結撒花。看完這篇後現在最大的感觸就是，全文流淌著 DevOps 血液啊~~ 感動！！ 包含流程化、自動化、跨組織協作、快速反饋、明確 deadline 等等，整個就是一大型教科書現場，完美體現了何爲速度經濟以及 "構建——衡量——學習" 循環。如果這本教課書有名字，應該叫 "論如何在複雜且動態的環境下 get things done"。雖然我覺得看完還是不太知道該如何在 VPN 和 microsegmented VPN 這兩個臨時解決方案中抉擇，不過我允許自己看不懂。

明天我們來做全系列的總結。明天見！