繼上回 2014 年的論文後,2017 年 Google 提出了一篇完整的論文討論他們是如何拆分內部遷移至 BeyondCorp 的工作,具體使用了哪些工具以及如何減少對用戶的負面影響。
本篇內容來自於論文:Migrating to BeyondCorp: "Maintaining Productivity while Improving Security"
在您開始進行遷移至 BeyondCorp 架構之前,您需要獲得高層管理人員和其他利益相關者的支持。第一步是理解並傳達遷移的動機:您希望在保持生產力的同時,減少網絡攻擊的威脅。您需要記錄提議遷移的理由、威脅模型以及“按照常規運作”的成本。然後,準備好向每個業務解釋為什麽這個過程是有價值且必要的。
與所有安全操作一樣,部署新模型是有代價的:新工具、額外的流程和習慣的改變。高層管理人員需要積極支持這種變化,並將動機和承諾傳達給所有利益相關者。
在獲得管理層的指示和支持後,確定並爭取關鍵領域的領導者的支持:安全、身份認證、網絡、訪問控制、客戶端和服務器平台軟件、業務關鍵應用服務,以及任何第三方合作夥伴或外包的 IT 廠商。這些領導者應該確定並招募各領域的專家,並重視這個遷移的過程,投入時間。
我們的 BeyondCorp 團隊是一個全球性團隊,由一位負責政策決策的主管和一位負責驅動和協調執行的技術項目經理領導。團隊成員的活躍度會隨著時間的推移而變化,但是利益相關者、團隊負責人和其他貢獻者通過在線文檔、群組郵件以及定期的面對面和視頻會議保持聯系,以了解當前的流程和項目狀態。
隨著工作的進行,變更管理的一般規則仍然適用,因為每個團隊都會有自己的關注點和優先事項。傾聽反饋並適應每個貢獻者或受影響群體的特殊情況和要求。發布計劃和公告相關資訊是必要的,但這還不足以解決問題;互動交流(最好是面對面進行,但至少通過視頻或音頻會議進行)可以加快援助和采納的過程。
總的來說,BeyondCorp 的目標是從 perimeter model 下的特權網路,轉變至零信任的非特權網路。這種設計取消了應用程序直接訪問後端應用的特權,而一律需透過 Access Proxy。為了達到目的,我們曾經考慮依序封鎖傳統的 VLAN 中的每個應用程式或伺服器以移除特權訪問。但這種策略有兩個不太理想的方面:在網路層面上部署和協調起來相當困難,同時也增加了應用程式正常運行的風險。
因此,我們決定在最終的 BeyondCorp 架構中部署一個新的 VLAN。這個 VLAN 只允許訪問是透過 Access Control Gateway 進行,確保所有流量都經過驗證、授權和加密。我們不再逐步限制傳統 VLAN 的特權,而是逐步將設備遷移到這個新的最終狀態的 VLAN。
但部署新 VLAN 的話會產生一個關鍵問題:任何期望或需要透過傳統 VLAN 訪問的 legacy app 在新的 VLAN 上都會運行失敗。因此,我們採用了三個策略來保持應用程序在不中斷的情況下搬遷至新 VLAN:
BeyondCorp 的設計包括使用 802.1x 來進行網路接入和 VLAN 分配,我們使用這一技術來將網路層從遷移的細節中解藕出來,而不受 BeyondCorp 架構的其他部分的影響。較高層次的軟體和數據分析確定了每個設備應分配到哪個 VLAN,然後 RADIUS 伺服器將這些分配信息傳遞給網路層。
實現這些目標是一項龐大的工程,需要在幾乎每個軟體和硬體層次進行變更。但我們並不試圖一次性地對所有這些層次進行改變,因為這無疑會引發問題。相反,我們選擇了一種分割的方法: