跳至主要內容
登雲學院 CloudOn 登雲學院.
ESC
跳到課程內容
安全與合規設計 零信任安全架構實戰
0%
15 / 25 進階 25 分鐘 00:00

零信任安全架構實戰

用明確驗證、最小權限與假設已遭入侵的原則，設計使用者、服務與資料的分層存取控制

2026年3月13日 Updated: 2026年7月17日

零信任不是「不用 VPN」

把 VPN 換成 IAP，可能是零信任轉型的一步，但不是全部。零信任比較像一組設計原則：

  • 明確驗證：根據身分、裝置、resource、action、風險和 context 做決策。
  • 最小權限：只授予完成目前任務所需的最小範圍與時間。
  • 假設已遭入侵：縮小 blast radius、分段、記錄、偵測並準備復原。
  • 持續評估：權限、裝置和 session 狀態改變時，存取結果也能跟著改變。

網路位置仍然是有用的信號，只是不再因為「人在內網」就自動被信任。

使用者到應用、服務到服務與應用到資料三條零信任存取路徑圖

圖解：零信任要分別設計使用者、服務與資料路徑；每次存取都重新驗證身分與 context、限制權限範圍與時間，並用分段與資料邊界降低單一憑證被盜後的 blast radius。

先拆三條存取路徑

零信任設計至少要分別處理：

  1. 使用者到應用：員工、外包或客戶怎麼進 Web app、Console 和管理入口？
  2. 工作負載到工作負載：服務如何驗證彼此身分並限制 action？
  3. 工作負載到資料：即使一個服務被攻破，能讀走哪些資料、能否把資料送出 boundary？

三條路徑用的 enforcement point 不同。只把員工入口放到 IAP 後面，並不會自動保護 service account 或資料 egress。

使用者到應用：IAP 與 context-aware access

Chrome Enterprise Premium 的 access protection 可以組合：

  • Cloud Identity／Google Workspace 的 user identity 與 MFA。
  • Endpoint Verification 收集的 device attributes。
  • Access Context Manager 定義的 access levels。
  • IAM Conditions 與 IAP 在支援資源上執行授權。

例如，高風險管理介面可要求特定 group、受管理且磁碟加密的 device，以及短期 privileged access；一般內部知識站則可允許較廣的受管裝置。政策應根據資料和 action 風險分級，不要讓所有應用共用一條最嚴或最鬆的規則。

避免繞過 IAP

IAP 保護的是經過它的流量。設計時要確認：

  • Backend 沒有另一個未受保護的 external IP、DNS name 或 load balancer path。
  • Firewall 只允許必要的 IAP／load balancer health check 與 proxy path。
  • 應用正確驗證 IAP identity assertion，不信任可由 client 自行送入的 header。
  • Session、reauthentication 和 device posture 更新符合風險要求。
  • IAP 不可用時要 fail closed、提供 break-glass，或讓低風險功能降級，這是明確決策。

IAP TCP forwarding 適合 SSH／RDP 等管理存取，不適合拿來做 bulk data transfer 或所有 application traffic。

Internet 入口：Cloud Armor 是其中一層

Cloud Armor 可以在支援的 load balancer backend service 上做 WAF、rate limiting、bot management 和 Adaptive Protection。安全規則上線時應：

  1. 根據應用 endpoint 和正常流量選 rule，而不是一次打開全部規則集。
  2. 先用 preview mode 觀察誤判。
  3. 以 log、request sample 和 application owner review 調整 sensitivity／exclusion。
  4. 分階段 enforce，為 false positive 準備快速回復。
  5. 持續更新，因為應用和攻擊方式都會變。

WAF 不理解完整業務授權。例如已登入使用者能否看某一筆訂單，仍由應用和 IAM／policy 決定。Geo filtering 也不能單獨證明資料主權或使用者身分。

網路分段：集中基線與團隊規則

Hierarchical firewall policies 可在 organization／folder 建安全基線，network firewall policies 與 VPC firewall rules 再處理更接近 workload 的需求。goto_next 允許上層把尚未決定的 traffic 交給後續 policy，而不是簡單的「上層全都比下層優先」。

實際 evaluation order 還會涉及 organization、folder、global／regional network firewall policies 和 VPC rules。變更前應依 firewall policy rule evaluation 模擬與測試。

好的分段規則會描述 service identity、port、direction 和用途，例如「checkout workload 能連 payment service 的 443」，而不是「prod subnet 彼此全部互通」。同時要保留 VPC Flow Logs、Firewall Insights 或合適 telemetry，確認實際流量和規則假設一致。

服務到服務：mTLS 只解決一部分

mTLS 可以讓雙方驗證 certificate identity 並加密連線；authorization policy 再決定某個 workload identity 能否呼叫特定 service／method。Cloud Service Mesh 可管理支援環境中的 service communication，Certificate Authority Service（CAS）則可在需要自訂 CA hierarchy、HSM-backed signing key 或跨叢集 CA 分隔時整合。

不要把「有 mTLS」寫成「服務間零信任完成」：

  • Certificate 簽給誰，workload identity 如何建立？
  • Sidecar、proxyless 或其他 data plane 是否涵蓋所有流量？
  • Authorization policy 預設 allow 還是 deny？
  • Certificate rotation、revocation 和 CA outage 怎麼處理？
  • 被允許的 service 是否仍有過大的資料權限？

CAS 並不是 Cloud Service Mesh 所有部署的必要條件；Cloud Service Mesh 有自己的 CA 選項，應依 PKI 與合規需求選擇。

資料層：限制被盜身分能帶走什麼

即使使用者入口和 service-to-service 都驗證過，一個被攻破的 runtime identity 仍可能合法呼叫 API。資料層還要加入：

  • IAM 與短效 workload identity，限制可讀 dataset／bucket。
  • VPC Service Controls 控制支援 services 的 ingress／egress 與跨 perimeter data movement。
  • Sensitive Data Protection 做 discovery 與 de-identification。
  • CMEK／EKM 依控制需求管理 key access。
  • Egress firewall、Secure Web Proxy 或其他 control 限制未受保護的外部目的地。

VPC SC 不會封鎖所有 Internet API，因此不能只靠 perimeter 阻止任意 exfiltration。Threat model 要把 Google-managed services 和一般 Internet egress 分開看。

從可見性高、風險可控的路徑開始

零信任轉型不需要套一個固定月份時程。比較實際的順序是：

  1. Inventory：列出 users、devices、apps、service identities、data flows 和 direct paths。
  2. Identity baseline：MFA、group lifecycle、service account key reduction、privileged access。
  3. 挑一條路徑試點：選 owner 清楚、風險可控的內部 Web app，導入 IAP 與 device context。
  4. 封旁路並量測：關閉 direct access，監看 denial、latency、help desk 和 break-glass。
  5. Workload segmentation：以 workload identity、mTLS／authorization 和資料最小權限縮小 blast radius。
  6. 持續驗證：用 policy tests、access review、red team 與 incident exercises 檢查控制。

先建立 inventory 和 telemetry，才能知道新 policy 會影響誰。一次把全公司 VPN 關掉，通常只會把未知依賴變成事故。

情境練習：遠端財務人員存取管理系統

假設財務人員會在公司與家中存取付款管理介面：

  1. 應用放在支援 IAP 的 HTTPS path，移除可繞過 IAP 的 backend public access。
  2. IAM role 綁 finance group，並以 access level 要求受管理、加密且符合 patch policy 的 device。
  3. 付款核准權透過有期限的 privileged access 取得；查詢與付款 roles 分離。
  4. Cloud Armor 保護公開入口，WAF 和 rate limit 先 preview 再 enforce。
  5. App runtime identity 只能讀必要帳務資料；付款 tool 使用另一個高權限 identity，並要求明確確認與 idempotency。
  6. Audit Logs、IAP access、device denial 和付款 action 進入中央 logging；異常地點、高額操作與 break-glass 使用觸發 review。
  7. 定期測試未管理裝置、離職使用者、IAP 旁路、被盜 runtime credential 和 logging destination failure。

這套設計不是因為「IAP 取代 VPN」而安全，而是每個高風險 action 都有身分、context、最小權限和 evidence。

本課檢查清單

  • 零信任是明確驗證、最小權限、假設已遭入侵與持續評估，不是單一產品。
  • 使用者、workload 和資料三條路徑要分開設計 enforcement points。
  • IAP 後端必須封住 direct path，否則授權可能被繞過。
  • Cloud Armor policy 要 preview、調整和分階段 enforce，不能取代業務授權。
  • Hierarchical firewall 的 goto_next 是委派，不應用三層簡表取代完整 evaluation order。
  • mTLS 提供 workload authentication 和加密，authorization、identity lifecycle 與 data permission 仍要另做。
  • VPC SC 保護受支援 services 的資料跨界；一般 Internet egress 需要其他控制。

延伸閱讀

下一步

下一課會進入 CI/CD 與 SDLC，練習把身分、供應鏈證據、部署核准和復原策略放進日常交付流程。

徽章解鎖！