iT邦幫忙

2023 iThome 鐵人賽

DAY 14
0

這篇讓我們繼續討論 Google 如何遷移到 BeyondCorp,會展開說明我們在 Day11 架構概覽中提到的流量分析管道 (Traffic Analysis Pipeline) 和模擬非特權網路。

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

成功導向的遷移 (Success-Oriented Migration)

(這題下得真絕,不是 goal-oriented 而是 success-oriented, 太會了)

https://ithelp.ithome.com.tw/upload/images/20230929/20145329grDQ0xTeF1.png
圖 1. 將設備遷移至受管非特權網路 (MNP) 流程 (source: Migrating to BeyondCorp: "Maintaining Productivity while Improving Security")

全面部署 802.1X 驗證花了數年的時間,而將 "基於 Device Inventory 的信任等級做動態 VLAN 分配" 作為 RADIUS policy server 的輸入又花了數年時間。在進行這些開發的同時,我們希望確定兩大類用戶和應用服務:一類是已經準備好遷移至 BeyondCorp 的用戶,另一類是需要升級網絡和安全性功能以符合 BeyondCorp 標準的用戶。

我們是如何將用戶或設備劃分爲 “準備好遷移至 BeyondCorp" 和 ”需要升級網路和安全性功能才能遷移至 BeyondCorp" 的呢?

在路由器上記錄和分析所有流量

我們的第一步是捕獲和分析來自路由器的流量。(就是在 Day 11 時提到的 Traffic Analysis Pipeline)通過記錄和分析通過公司路由器的所有流量的部分樣本,我們發現了不合規的使用模式。其次,這種分析還能幫助我們發現網絡上的異常、意外和未經授權的流量。識別這些應用程序意味著我們可以更早地開始重新設計它們,避免影響到應用程序的用戶。

用雲端硬碟取代 NFS

NFS/CIFS 等文件伺服器的底層 protocol 並不支援 BeyondCorp 架構需要的安全性(強加密和身份驗證),因此遷移至 MNP 網路後會因爲不合規(受 ACL 限制)而失敗。因此,爲了消除對 NFS/CIFS 的依賴,我們很早就啓動了一個大型項目,以實現兩個目標:

  • 將 NFS 主目錄轉移到 local disk,並自動備份到安全的雲存儲空間(Cloud Storage)
  • 用 Google Drive 或其他安全文件共享技術取代其他 NFS 用途

但是,有些應用程序深深依賴 NFS,例如 CAD (computer-aided design) editor。因此,在我們將這些設備轉移到受管非特權網路 (Managed Non-Privileged, MNP) VLAN 之前,我們需要特殊的解決方案。這部分會在之後的章節 "Remediating Difficult Use Cases" 中提到。

其他不合規的工作流程並不那麽明顯,但在受到 MNP ACL 限制時也會失敗。這種失敗是設計造成的,因為我們不能假定 NFS、RDP、SQL 等有足夠的身份驗證、授權和加密。如果必須在網絡層進行修復,那麽檢測這些工作流並通過更改設備的網絡分配來重新啟用工作效率既困難又耗時。為了避免對工作效率造成巨大影響(更不用說用戶體驗),我們需要一種分析驅動的策略來檢測失敗的工作流,並在將用戶分配到 MNP VLAN 之前對其進行糾正。

client-based network ACL simulator

前情提要:Day 11 遷移到 BeyondCorp 架構—概覽的章節 “模擬非特權網路” 中有提到通過在設備上安裝流量監視器 (traffic monitor) 模擬公司範圍內的非特權網路行爲,其中流量監視器有兩種模式:

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

為了便於在非特權網絡上進行分析和用戶工作流程測試,我們創建了一個基於客戶端的網絡 ACL 模擬器 (client-based network ACL simulator),它會負責識別將被 MNP ACL 封鎖的網絡封包。底層技術使用了Capirca,從實際的 MNP ACL 創建本地 IP 表或封包過濾器規則。在分析和遷移階段,用戶設備繼續在特權網絡上運行,同時 MNP 模擬器監控網絡流量,並將所有不兼容 MNP 的流量的源和目的地記錄到中央存儲庫。IP 源地址識別了失敗的用戶,IP 目的地地址識別了失敗的服務。通過分析這些日誌(在適當的隱私約束條件下),我們可以識別具有 MNP 兼容流量的設備並將它們分配到 MNP VLAN。同樣,我們可以識別依賴不合規流量的設備、用戶和服務,並啟動項目將這些服務轉移到替代解決方案。隨著時間的推移,越來越多的設備變得合規,並自動分配到 MNP VLAN。

Capirca is a tool designed to utilize common definitions of networks, services, and high-level policy files to facilitate the development and manipulation of network access control lists:github.com/google/capirca.

在 enforcement mode 下,模擬器可實際阻止/刪除非 MNP 流量,從而執行 MNP ACL,而無需依賴網絡層部署 MNP VLAN 和 802.1x 管道。雖然我們最終是在網絡設備中執行 ACL,但在試用和過渡期間,在客戶端工作站中啟用和禁用這種 enforcement mode 要容易也快得多。客戶端強制執行既是遷移過程中的重要步驟,也是測試的自助工具。如果沒有這項功能,我們就不會有信心以如此快的速度(或如此高的成功率)將設備遷移到 MNP。


今天是中秋節呢。「原來都已經九月快十月了啊。。。」今天突然有這種感慨。時間真的過好快喲。

“It's never easy, but not that hard." 這句話良好的總結了我的 Q1 到 Q3。

Q4 近在眼前,讓我們繼續加油吧!! ><


上一篇
Day 13 遷移到 BeyondCorp——802.1X 驗證的網路
下一篇
Day 15 遷移到 BeyondCorp——成功導向的遷移(續)
系列文
Google BeyondCorp 零信任模型:從概念到實踐30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言