擺脫傳統,GCP BeyondCorp 安全模型的嶄新世界
在當今的數位時代,傳統的網路安全模型似乎已經跟不上快節奏的改變。我們熟知的「城堡與護城河」(Castle-and-Moat)或「圍牆式安全」(Perimeter-Based Security Model),曾經是保護企業內部資訊的主流方式,但它們正遭遇越來越多的挑戰和限制。
像在金融業這個高度監管行業,除資訊安全是首要任務外,還必須滿足嚴格的外部金融監管要求。然而,可以感受到傳統的安全模型在面對現代金融業的複雜挑戰時,會覺得有點不堪重負與失去彈性。這種「城堡與護城河」式的模型在以往或許足以應對內部與外部的二元分隔,簡單作法就是過層層防火牆隔離可能的惡意行為。
但如今,二分法的模型在複雜的情境下會產生更多的問題或造成更大的成本,如:越來越多的員工需要在遠端工作、使用者終端設備多樣性常與公司的 VPN 端不兼容問題、外部供應商與內部系統合作頻繁、攻擊者可以隱藏在先前受信任的裝置內部(意即進入到內部後應該就是網內互通的狀況,這設計可能更鬧)。
在這樣的環境下,Google Cloud Platform 的 BeyondCorp 安全模型算是提供了更靈活、高效、且強大的安全解決方案。然而,最大的挑戰可能不在於技術本身,而是在於如何與長期習慣於傳統安全模式思維的高層管理並共同與資訊安全團隊合作,在跨雲或轉換的初期,組織內部積極「合作」甚至是以特案的型式向資安長(CISO)報告,以確保成功實現現代化的安全策略。
回到現實層面 ,本文先來探索 Google 提出一個零信任(Zero Trust)模型 BeynodCorp 的解決方案,以 IAP(Identity-Aware Proxy)技術來構建更具韌性的安全策略,並提供實際範例,展示如何建立遠端安全連線,保護資料面和應用程序,以取代過往的築防火牆策略。
問題思考
傳統安全性擴展到的唯一方法就是添加更多、更大的防火牆,一旦攻擊者透過破壞員工設備或利用您的一台伺服器中的 Zero Day 等漏洞溜過您的邊界,他們就可以輕鬆橫向移動。
大多數企業網路的結構都是相同的:外圍加高加滿,內部高度脆弱。
問題思考
假設在 GCP 專案的私人 IP 子網路上的私人 VPC 中建立了一個簡單的 HTTP Web 伺服器
但是管理者可能需要透過遠端存取協定(例如 SSH、VNC 或 RDP)存取遠端 HTTP Web 伺服器,以便執行管理任務或維護。由於 HTTP Web 伺服器出於資安關係沒有設定公用 IP 位址,無法直接從網路訪問,因此這就出現了問題。我們如何輕鬆、安全地存取該伺服器,而不需要額外的複雜基礎架構(例如 VPN 與跳板機)?
BeyondCorp 作法
對於任何網路元素,在通過認證之前,都應保持零信任的態度
零信任的方法是以個別的資源、使用者和資產本身為主體,一個不分內部或外部的模型,而是基於每個請求的上下文來增強信任,並決定是否取消存取。所有對公司資源的存取都基於請求的上下文來決定:
- 此人是否已獲得使用此資源的授權?
- 這個設備安全健康嗎?
- 此請求是否符合我的存取策略?
範圍包含了使用者身分、裝置安全性以及存取策略,並且也有真正實作在 Google 公司內部中,員工不管在家、咖啡店或辦公室,他們都可以獲得相同的訪問權限,這是一種更靈活的方式並兼顧安全的存取控制方法,BeyondCorp 的幾個重要元素如 Cloud Identity-Aware Proxy、IAM、Access Context Manager、Endpoint Verification 使用這些關鍵功能來達成。
Cloud Identity-Aware Proxy(IAP)
IAP 是一種基於政策引擎 Access Context Manager(ACM)和身份訪問控制的解決方案,安全管理應用程式和資源的訪問,不受用戶的位置限制,並採用零信任模型,確保資料的保護性和安全性,來看一下官方對他的功能介紹:
Key features
Centralized access control
IAP provides a single point of control for managing user access to web applications and cloud resources.
Works with cloud and on-premises apps
IAP can protect access to applications hosted on Google Cloud, other clouds, and on-premises.
Protects apps and VMs
With TCP forwarding, IAP can protect SSH and RDP access to your VMs hosted on Google Cloud. Your VM instances don’t even need public IP addresses.
- 保護應用程式和虛擬機:通過 TCP forwarding,IAP 可以保護您在 Google Cloud 上託管的虛擬機 (VM) 的 SSH 和 RDP 訪問。這意味著您的 VM 實例甚至不需要公共 IP 地址。
IAP 它在公司的內部作為零信用的應用很廣泛,接續分享以下可以導入與實作的細節:
- 利用 IAP + OS Login 組合,快速建立遠端安全連線(比 VPN 連線、跳板機方便、易管理、零信任)
- 利用 IAP + IAM Condition 滿足配置的條件才授予主體權限
- 利用 IAP + Cloud Amour 組合,封鎖外部異常流量
- 利用 IAP-secured Web App + Oauth consent screen,使保護更彈性
- CP 值高的政策引擎 Access Context Manager(ACM)分享
Case 1. 利用 Cloud IAP + OS Login 組合,快速建立遠端安全連線(比 VPN 連線、跳板機方便及易管理)
Cloud IAP for TCP Forwarding:更安全的 GCE 主機連線方式,解決管理和資安問題
Cloud IAP for TCP forwarding 提供了一種在 Google Compute Engine(GCE)主機上建立連線的新方式,這種方法可以替代原本需使用跳板機所帶來的管理困難和資安風險。這個方法也讓我們能夠放心消除原本需要設定 0.0.0.0/0 到 SSH 22 port 的防火牆規則◍•ᴗ•◍。
但是,當談到誰可以訪問這些主機時,不是所有人都應該有這個權限。特別是在高度監管的金融業中,開發團隊可能不應該直接透過SSH連接到 VM 主機。在這方面,IAP 還可以搭配使用 OS Login 和 OS Login Admin 功能,以實現更多層次的訪問控制,確保只有授權的用戶能夠執行這些操作。這種結合的方式,不僅簡化了管理,還提高了資安,尤其適用於金融行業等敏感性極高的環境。
動手操作
前往 「Security」->「Identity-Aware Proxy」
基本設定
- Step1. Enable IAP
- Step2. 至
SSH and TCP RESOURCES
選擇想要開啟IAP
保護的 VM
- Step3. 點選「+👤ADD MEMBER」,指定使用者以 IAP-secured Tunnel 方式連線至主機,角色請選擇「IAP-secured Tunnel User」
- Step4. 建立 firewall for IAP Tunnel:
「Networking」 → 「VPC network」→ 「Firewall」→ 「Create Firewall Rule」
我們需要設定允許來源網段 35.235.240.0/20
作為 IAP TCP 轉送的允入規則, 允許 IAP 從這個網段連接到你的主機。特別提醒,請注意預設的 default-allow-ssh 跟 default-allow-rdp 允許來自所有來源的主機連線到 port 22 與 3389。你可以視情況調整這兩個規則,讓主機只允許來自 IAP 的連線。對 IAP 應用或全面導入還不確認,或是您可以先透過 Network tags(目標標記 IAP
套用的 VM) 或是自訂一個新的 VPC(非 default)來嘗試,比較不會把其他的 VM 連線方式搞混淆。
防火牆也設置完成
- Step5. 驗證 SSH VM with IAP Tuneel:確實我們拿掉外部 IP 後,該位使用者透過 IAP tunning 方式來連線至 VM
# 指令參考
$ gcloud compute ssh <instance-name> \
--tunnel-through-iap \
--project=<project-name> \
--zone=<zone>
$ gcloud compute ssh <vm名稱> --zone <zone名稱> --project=<projec-id名稱>
# 若是不加 --tunnel-through-iap 會跳出以下訊息 ------------------------
External IP address was not found; defaulting to using IAP tunneling.
WARNING:
# ------------------------------------------------------------------
To increase the performance of the tunnel, consider installing NumPy. For instructions,
please see https://cloud.google.com/iap/docs/using-tcp-forwarding#increasing_the_tcp_upload_bandwidth
Linux os-login-instance 5.10.0-25-cloud-amd64 #1 SMP Debian 5.10.191-1 (2023-08-16) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Creating directory '/home/user_gmail_com'.
- 如果沒有在 Project 層級賦予用戶 IAP-secured Tunnel User 這個角色,Web SSH 功能是反灰無法使用的。另外,也可以新增一個群組帳號,存取權限將會對應到群組內的成員,管理上易比較方便!如果是未授權的使用者,則會得到另外一個錯誤訊息:
- 增加 IAP TCP 上傳頻寬:作業過程有看到這段 log,建議可以考慮將 NumPy 安裝在與 gcloud CLI 相同的系統上,以提高 IAP TCP 上傳頻寬,在想應該是安裝 NumPy 會提高數學計算效能,上傳頻寬的增加可能是一個間接的結果。
# 原本 log 有提到的資訊
To increase the performance of the tunnel, consider installing NumPy. For instructions,
please see https://cloud.google.com/iap/docs/using-tcp-forwarding#increasing_the_tcp_upload_bandwidth
# 安裝指令
$(gcloud info --format="value(basic.python_location)") -m pip install numpy
之後有空在繼續探索以下提到的部份
- 利用 IAP + IAM Condition 滿足配置的條件才授予主體權限
- 利用 IAP + Cloud Amour 組合,封鎖外部異常流量
- 利用 IAP-secured Web App + Oauth consent screen,使保護更彈性
- CP 值高的政策引擎 Access Context Manager(ACM)分享
已更新在其他篇(2023.11.26)
🔗【Explanation】GCP Security — BeyondCorp 實作 IAM condition
🔗【How-to Guides】GCP Security — 以Cloud Armor 強化 BeyondCorp 安全模型
🔗【How-to Guides】GCP Security — 使用政策引擎 Access Context Manager(ACM)制定組織安全策略
📙Reference
- Connecting Securely to Google Compute Engine VMs without a Public IP or VPN
- IAP ACCESS TO GCP AND ON-PREM SYSTEMS USING IDENTITY PLATFORM
- What is BeyondCorp? What is Identity-Aware Proxy?
- Identity-Aware Proxy (IAP) 支援 Non-web Client/Server 應用程式
- Using Terraform to create secure IAP tunnels on GCP with conditional IAM policies
- https://medium.com/google-cloud/designing-zero-trust-architectures-using-google-cloud-services-216f41ba647d