examlab .net 用最有效率的方法，考取最有價值的證照
支持
本篇導覽 約 18 分鐘

Identity-Aware Proxy (IAP)：實施零信任架構

3,500 字 · 約 18 分鐘閱讀 ·

深入掌握 Google Cloud 的 Identity-Aware Proxy (IAP)。學習如何保護 Web 應用程式、實施 SSH/RDP 的 TCP 轉發，以及在不使用 VPN 的情況下構建零信任架構。

立即做 20 題練習 → 免費 · 不用註冊 · PSE

Identity-Aware Proxy (IAP) 簡介

在網路邊界逐漸消失的今天，Identity-Aware Proxy (IAP) 是 Google Cloud 實施零信任 (Zero Trust) 安全模型的關鍵解決方案。受到 Google 內部 BeyondCorp 倡議的啟發，IAP 將安全性從網路邊緣轉移到了應用程式和身分層級。

對於 專業雲端安全工程師 (PSE) 而言，IAP 至關重要，因為它允許使用者從任何地方存取內部應用程式和管理介面 (SSH/RDP)，而無需使用傳統的 VPN。透過驗證使用者的身分及其請求的內容背景 (Context)，IAP 確保只有經過授權的使用者在健康的設備上才能接觸到敏感資源。

白話文解釋

1. 夜店門口的保鑣 (Web 應用程式安全)

傳統的 VPN 就像是給每個人一把進入大樓大門的鑰匙。一旦進入，他們就可以隨意走動。IAP 則像是站在每個 VIP 房間 (應用程式) 門口的保鑣。即使您在大樓內，您也必須向該特定房間的保鑣出示身分證。如果您不在名單上，就無法進入。

2. 安全隧道 (TCP 轉發)

想像您需要向一座防禦森嚴的城堡中的朋友傳送秘密訊息，但所有大門都鎖上了。與其打開大門 (防火牆規則)，您使用一個直接通往朋友房間的秘密氣動管 (IAP 隧道)。其他人看不到也無法使用這個管道，且您必須在管道入口處驗證身分。

3. 數位代客泊車 (身分驗證)

當您把車交給代客泊車時，他們不只是拿走鑰匙；他們會檢查您的票據 (身分) 並確保您是合法的車主，然後才會交還車輛。IAP 就像這位代客泊車員，在交出應用程式的「鑰匙」之前，先檢查您的身分 (Google 帳戶/身分平台) 和內容背景 (設備健康狀況)。

Web 應用程式的內容感知存取 (Context-Aware Access)

IAP 透過攔截發送到應用程式的 HTTP(S) 請求來運作。它與 Google Cloud 負載平衡 (GCLB) 整合。

運作方式：

  1. 使用者透過負載平衡器存取 Web 應用程式。
  2. IAP 檢查使用者是否已驗證。如果未驗證，則將其重新導向至 Google 登入頁面。
  3. 登入後，IAP 檢查 IAM 策略，確認使用者是否擁有 iap.httpsResourceAccessor 角色。
  4. (選用) IAP 透過存取內容管理器 (Access Context Manager) 檢查存取層級 (Access Levels)，例如確保設備已加密或來自特定的 IP。

Identity-Aware Proxy (IAP) 是一種代管服務，透過驗證身分和內容背景，而不是依賴網路層防火牆，來控制對雲端應用程式和 VM 的存取。

SSH 和 RDP 的 IAP TCP 轉發

對於 PSE 而言，最強大的功能之一是 TCP 轉發 (TCP Forwarding)。這允許您管理沒有外部 IP 位址的 VM。

外部 IP 的問題

將 22 埠 (SSH) 或 3389 埠 (RDP) 暴露在網際網路上是一個重大的安全風險 (暴力破解、零時差漏洞)。

IAP 解決方案：

  • VM 位於沒有外部 IP 的私有網路中。
  • 防火牆設定為僅允許來自 IAP 網路區段 (35.235.240.0/20) 的流量。
  • 使用者使用 gcloud compute ssh --tunnel-through-iap 指令。
  • IAP 將 SSH 流量透過 HTTPS (443 埠) 隧道傳輸到 VM。

要使用 IAP TCP 轉發，使用者必須擁有 iap.tunnelResourceAccessor 角色，且專案防火牆必須允許來自 35.235.240.0/20 的傳入流量。

無需 VPN 即可保護內部應用程式

傳統 VPN 通常速度慢、難以管理，且提供「全有或全無」的存取方式。IAP 提供：

  • 細粒度存取： 授予同一個使用者存取應用程式 A 的權限，但不授予存取應用程式 B 的權限。
  • 無需客戶端軟體： 對於 Web 應用程式，使用者只需要標準瀏覽器。
  • 擴展性： 由 Google 代管，因此您不必擔心 VPN 集中器的容量問題。

IAP 標頭與身分驗證

在 IAP 允許使用者通過後，您的應用程式如何知道使用者是「誰」？

IAP 標頭

IAP 透過 HTTP 標頭將身分資訊傳遞給後端：

  • x-goog-authenticated-user-email
  • x-goog-authenticated-user-id
  • x-goog-iap-jwt-assertion (一個經過簽署的 JSON Web Token, JWT)

務必記住 IAP 注入的三個標頭 (x-goog-authenticated-user-email、x-goog-authenticated-user-id、x-goog-iap-jwt-assertion)，以及用來驗證 JWT 簽章的公開金鑰端點 https://www.gstatic.com/iap/verify/public_key。後端進行授權判斷時，唯一可以信任的就是這個經過簽署的 assertion 標頭。

切勿僅信任電子郵件標頭。 繞過 IAP 的惡意攻擊者可能會偽造電子郵件標頭。您的應用程式必須使用 Google 的公開金鑰驗證 x-goog-iap-jwt-assertion 簽署，以確保請求確實來自 IAP。

搭配負載平衡器設定 IAP

IAP 可以在以下後端服務上啟用：

  • Compute Engine (執行個體群組)
  • App Engine
  • Cloud Run (透過 GCLB)
  • GKE (透過 Ingress)

設定步驟：

  1. 設定全域外部 HTTP(S) 負載平衡器。
  2. 在 GCP 主控台中設定 OAuth 同意畫面。
  3. 在負載平衡器的後端服務上啟用 IAP。
  4. 將使用者加入 IAP-secured Web App User IAM 角色。

Web App 的 IAP 必須搭配 Global External HTTP(S) Load Balancer 前置於後端服務 — 區域型或 TCP/UDP 負載平衡器都不支援。同時，必須先設定 OAuth 同意畫面再啟用 IAP，並授予 Web 使用者 roles/iap.httpsResourceAccessor (而非 TCP 轉發角色)。支援的後端類型為 Compute Engine 執行個體群組、App Engine、透過 GCLB 的 Cloud Run，以及透過 Ingress 的 GKE。

管理存取層級與條件

標準 IAM 檢查「你是誰？」。內容感知存取 (Context-Aware Access) (與 Access Context Manager 整合) 則檢查「你請求的狀態是什麼？」。

存取層級範例：

  • 設備策略： 使用者必須使用啟用了磁碟加密的受控公司筆記型電腦。
  • IP 範圍： 使用者必須來自公司總部。
  • 地理位置： 使用者必須位於美國境內。

搭配 IAP 使用 IAM 條件 (IAM Conditions)，可以根據資源標記授予臨時存取權限或存取權。

使用身分平台 (Identity Platform) 處理外部身分

預設情況下，IAP 使用 Google 帳戶或 Cloud Identity。但是，您可以使用 Google Cloud 身分平台 (Identity Platform) 來支援：

  • SAML/OIDC 供應商 (如 Azure AD, Okta)。
  • 社群登入 (如 Facebook, GitHub)。
  • 外部合作夥伴或客戶的電子郵件/密碼帳戶。

這允許您為不屬於組織目錄的使用者提供 IAP 保護。

IAP 存取的稽核日誌

可視化是 PSE 的核心需求。IAP 會將所有存取嘗試記錄到 Cloud Audit Logs。

  • 成功存取： 記錄在 data_access 日誌中。
  • 拒絕存取： 記錄為錯誤，並附帶拒絕原因 (例如：「缺少 IAM 角色」或「存取層級檢查失敗」)。

BeyondCorp Enterprise 整合

BeyondCorp Enterprise 是 IAP 的進階版本，增加了：

  • 威脅與資料保護： 整合 Chrome 瀏覽器安全性，防止資料外洩。
  • URL 過濾： 控制使用者從受保護的應用程式內可以造訪哪些外部網站。
  • 持續監控： 隨著設備狀態變化，即時重新評估存取層級。

IAP 連線問題故障排除

1. 403 Forbidden (Web 應用程式)

  • 檢查： 使用者是否擁有 iap.httpsResourceAccessor？
  • 檢查： 是否有存取層級阻擋了他們 (例如：錯誤的 IP)？
  • 檢查： 負載平衡器後端是否健康？

2. "Unable to connect on port 22" (SSH 隧道)

  • 檢查： VM 是否有服務帳戶？
  • 檢查： 防火牆是否允許 35.235.240.0/20？
  • 檢查： 使用者是否擁有 iap.tunnelResourceAccessor？

IAP 的 CLI 指令

透過 IAP 隧道進行 SSH

gcloud compute ssh my-vm \
    --zone=us-central1-a \
    --tunnel-through-iap

透過 CLI 授予 IAP 存取權

gcloud iap web add-iam-policy-binding \
    --resource-type=backend-services \
    --service=my-backend-service \
    --member='user:[email protected]' \
    --role='roles/iap.httpsResourceAccessor'

PSE 安全性最佳實踐

  1. 縱深防禦： 即使使用了 IAP，也要保留應用程式內部的身分驗證 (如果存在) 作為第二層防線。
  2. 驗證 JWT： 務必在後端程式碼中驗證 IAP JWT。
  3. 輪替 OAuth 密鑰： 定期輪替用於 IAP/OAuth 的用戶端密鑰。
  4. 使用私有 IP： 搭配 IAP，確保後端 VM 沒有外部 IP 位址，以最小化攻擊面。

故障排除情境

情境：使用者可以 SSH，但無法透過 IAP 使用 RDP

診斷： 檢查防火牆規則。您可能允許了 22 埠，但忘記為 IAP 網路區段 35.235.240.0/20 開放 3389 埠。 修正： 更新傳入防火牆規則，納入 TCP 3389 埠。

情境：儘管 IAP 已開啟，應用程式仍收到 "Unauthorized" 錯誤

診斷： 應用程式可能需要特定的 Cookie 或標頭，而 IAP 將其移除，或者應用程式內部的 JWT 驗證由於公開金鑰過期而失敗。 修正： 驗證 JWT 驗證邏輯，並確保它從 https://www.gstatic.com/iap/verify/public_key 獲取 Google 最新的公開金鑰。

PSE 考試情境

情境 1：取代 VPN

「一家組織希望淘汰遺留的 VPN，並提供對內部人力資源入口網站的安全存取。該入口網站必須僅能從公司擁有的筆記型電腦存取。解決方案是什麼？」 答案： 在負載平衡器上為該入口網站部署 IAP，並在 Access Context Manager 中定義一個要求受控設備的存取層級。

情境 2：私有 VM 的管理員存取

「安全性策略規定任何 VM 都不能擁有外部 IP 位址。管理員應如何執行 SSH 維護？」 答案： 使用 IAP TCP 轉發。設定防火牆規則允許 35.235.240.0/20 存取 22 埠，並使用 gcloud compute ssh --tunnel-through-iap 指令。

總結清單

  • 解釋 Web 應用程式 IAP 與 TCP 轉發 IAP 之間的區別。
  • 列出 IAP 存取所需的 IAM 角色。
  • 識別 IAP 防火牆規則所需的 IP 範圍。
  • 解釋為什麼驗證 IAP JWT 是必要的。
  • 描述 Access Context Manager 如何與 IAP 整合。

官方資料來源

更多 PSE 主題