零信任安全架構實戰

零信任不是「不用 VPN」

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

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

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

先拆三條存取路徑

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

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。

flowchart TB
  U["User request"] --> ID["Identity＋MFA<br/>group<br/>membership"]
  D["Device posture<br/>managed、<br/>encrypted、<br/>patched"] --> C["Access level／IAM condition"]
  N["Network、<br/>time、risk signal"] --> C
  ID --> C
  C --> I{"IAP policy<br/>允許此 app／action？"}
  I -->|"否"| X["拒絕＋<br/>denial evidence"]
  I -->|"是"| A["Application<br/>resource／<br/>business<br/>authorization"]
  A --> S["短期 session<br/>記錄 access<br/>與高風險 action"]
  S --> R{"Identity、device<br/>或 risk 是否改變？"}
  R -->|"是"| C
  R -->|"否"| A
  B["Direct<br/>backend path"] -. "封鎖，避免繞過 IAP" .-> A

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 也不能單獨證明資料主權或使用者身分。

flowchart TB
  T["Threat model＋endpoint<br/>正常 traffic baseline"] --> R["選擇 WAF／rate limit／<br/>bot rule"]
  R --> P["Preview mode"]
  P --> O["觀察 log、request sample<br/>false positive／negative"]
  O --> A["Application owner review<br/>調整 sensitivity／exclusion"]
  A --> G{"誤判與保護效果<br/>在容忍範圍？"}
  G -->|"否"| P
  G -->|"是"| E["小範圍 enforce<br/>準備快速 rollback"]
  E --> M["監控 user impact<br/>attack pattern 與 latency"]
  M --> U["規則／應用／威脅改變"]
  U --> R

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

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 與合規需求選擇。

flowchart TB
  A["Service A<br/>短效 workload<br/>identity"] --> M["mTLS handshake<br/>certificate identity＋encryption"]
  C["CA／trust domain<br/>issuance、<br/>rotation、revocation"] --> M
  M --> P{"Authorization policy<br/>identity 能呼叫<br/>service／method？"}
  P -->|"否"| X["拒絕＋telemetry"]
  P -->|"是"| B["Service B"]
  B --> D{"Runtime identity<br/>能讀這筆 data／<br/>resource？"}
  D -->|"否"| X
  D -->|"是"| R["執行 operation<br/>trace＋audit"]
  BY["未經 data plane<br/>的旁路"] -. "分段／firewall 封鎖" .-> B
  F["CA／mesh outage behavior<br/>fail closed、grace、break-glass"] --> C

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

即使使用者入口和 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 分開看。

flowchart TB
  C["Compromised<br/>runtime identity"] --> I{"IAM 最小權限<br/>能讀目標<br/>dataset／bucket？"}
  I -->|"否"| X["阻擋＋告警"]
  I -->|"是"| D["取得被授權的最小資料"]
  D --> P{"透過支援的<br/>Google service<br/>跨 perimeter 移動？"}
  P -->|"是"| V["VPC SC ingress／<br/>egress rule"]
  V -->|"不允許"| X
  V -->|"允許"| A["受控目的地"]
  P -->|"否，一般<br/>Internet egress"| E["Egress firewall／<br/>Secure Web Proxy<br/>DNS／application<br/>allowlist"]
  E -->|"不允許"| X
  E -->|"允許"| A
  K["CMEK／EKM<br/>key access"] -. "額外依賴，<br/>不取代 IAM" .-> D
  S["Sensitive Data<br/>Protection<br/>最小化／<br/>去識別化"] -. "降低資料價值" .-> D

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

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

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 關掉，通常只會把未知依賴變成事故。

flowchart TB
  I["Inventory<br/>users、devices、apps、identity、data flow、旁路"] --> B["Identity baseline<br/>MFA、group lifecycle、key reduction、PAM"]
  B --> P["選 owner 清楚、<br/>風險可控的<br/>內部 Web path 試點"]
  P --> C["導入 IAP＋device context<br/>保留 break-glass"]
  C --> D["封 direct path<br/>量 denial、<br/>latency、help desk"]
  D --> G{"User journey 與<br/>安全 control 達標？"}
  G -->|"否"| P
  G -->|"是"| W["擴到 workload identity<br/>mTLS、authorization、segmentation"]
  W --> R["資料最小權限<br/>managed-service 與 Internet egress boundary"]
  R --> V["持續 policy test、<br/>access review<br/>red team、<br/>incident exercise"]
  V --> I

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

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

先自己走一遍：從登入、查詢、核准付款到事後追查，每一段你會放什麼控制？寫下來再展開，看漏了哪一層。

課後檢查

往下看重點之前，先試著回答這幾題；答不出來，括號裡是該回去重讀的那一節。

• 應用已經掛上 IAP，為什麼還要檢查 backend 有沒有別條路進得來？（回〈避免繞過 IAP〉）
• 服務之間開了 mTLS，還有哪些事要另外做？（回〈服務到服務：mTLS 只解決一部分〉）
• VPC Service Controls 管得到哪一種資料外流？哪一種要靠別的控制？（回〈資料層：限制被盜身分能帶走什麼〉）

本課重點

• 零信任是明確驗證、最小權限、假設已遭入侵與持續評估，不是單一產品。
• 使用者、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 需要其他控制。

延伸閱讀

• Chrome Enterprise Premium access protection
• IAP overview
• Cloud Armor best practices
• Cloud Service Mesh overview

下一步

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