傳統網路安全模型有一個核心假設：內網是安全的。防火牆把外面的壞人擋掉，進了內網的就是可信任的。
這個假設在 2020 年代已經不成立了。員工用 VPN 從咖啡廳連公司、第三方廠商有內網存取、SaaS 工具走的是公共網路、雲端 workload 根本沒有「內網」的概念——攻擊者只要能 VPN 進來，或者入侵一台內網機器，就能在「可信任的內部」橫向移動。
Zero Trust 的核心原則：不因為網路位置就假設信任，每次存取都要驗身份和授權。
三個核心原則
Verify Explicitly（明確驗證）
每次存取請求都要驗身份、設備狀態、和授權——不管請求來自內網還是外網。用戶端是公司發的電腦嗎？現在是否有活躍的 EDR agent？這個帳號有沒有 MFA？這個 API key 的 scope 有沒有包含這個操作？
Least Privilege Access（最小權限）
給夠用的權限，不多給。工程師的 DB 存取只在需要的時候開、需要的 DB table。Service account 只有它需要呼叫的 API scope。不是「給 admin 比較省事」。
Assume Breach（假設已被入侵）
不依賴邊界防禦作為唯一防線。假設攻擊者已經在裡面了——資料要加密傳輸、service 之間要互相驗證、存取要有 audit log、異常行為要有告警。
從 BeyondCorp 到現在
Zero Trust 概念由 Google 在 2014 年透過 BeyondCorp 論文系列具體化。在此之前員工要 VPN 才能存取內部服務。BeyondCorp 的做法是：不管你在哪個網路，都要驗你的身份和設備狀態，然後直接給你存取特定應用，不是網路層面的存取。
傳統 VPN 模型：
用戶 → [VPN] → 內網 → 任何服務
BeyondCorp / Zero Trust：
用戶 → [身份驗證 + 設備驗證] → Access Proxy → 特定應用
現在大多數雲端廠商都有對應的實作（Google BeyondCorp, Cloudflare Zero Trust, AWS IAM Zero Trust patterns）。
在微服務架構裡的 Zero Trust
微服務讓 Zero Trust 的需求更迫切：一個系統可能有數十個服務，服務之間要互相呼叫。傳統做法是「內部服務互相信任，不驗身份」——這就是一個典型的內網假設。
Zero Trust 的微服務做法：
mTLS（Mutual TLS）：不只 client 驗 server 的憑證，server 也驗 client 的憑證。每個 service 有自己的 identity（TLS certificate）。Istio、Linkerd 這類 service mesh 提供 mTLS 的自動化。
SPIFFE / SPIRE：Cloud Native 的 workload identity 標準。每個 workload（pod、VM、function）有自己的 SPIFFE ID（spiffe://domain.com/service/order-service），透過 SPIRE 自動輪換短期憑證，不需要把 API key 放在 config 裡。infra/security-governance 章節有更深入的實作。
Zero Trust 不是「買一個產品就好」
“Zero Trust” 這幾年被商業化嚴重，很多廠商宣稱賣的是「Zero Trust 解決方案」。實際上它是一組架構原則，要在多個層次落地：
- Identity 層：強 MFA、SSO、privileged access management
- Network 層：網路分段、微分割、限制橫向移動
- Workload 層：mTLS、workload identity（SPIFFE）
- Data 層：資料加密、DLP、存取 log
- Device 層：設備狀態驗證（MDM、EDR）
沒有一個產品能蓋這五層。Zero Trust 是架構藍圖，不是單一購買決策。
跟其他章節的關係：這篇是概念介紹。infra/security-governance 章節有 Kubernetes 環境的具體實作（Zero Trust Architecture / SPIFFE/SPIRE）；backend/security 有 code 層的 mTLS 整合。