系統安全的核心不是防火牆，是「誰可以做什麼」。防火牆擋得住外人，擋不住離職沒收權限的前同事、權限過大的 service account、還有那個「大家共用的 admin 帳號」。
先講結論
身分治理就三件事：可追蹤（誰做了什麼）、可撤銷（離開就關）、可稽核（出事能查）。做到這三點，你的系統就比 90% 的團隊安全。做不到？那你的防火牆只是心理安慰。
Authentication vs Authorization：先搞清楚你在問哪個
Authentication 是「你是誰」——登入、MFA、驗證身份。Authorization 是「你能做什麼」——角色、權限、存取範圍。
聽起來很基本對吧？但我見過不少系統把這兩件事混在一起做。結果就是改權限要改登入邏輯，加新角色要動認證 middleware。拆開治理才是正途。
最小權限：說起來簡單，做起來反人性
「只給需要的權限」——每個人都同意這句話，但實際上呢？開發人員需要存取 prod DB 來 debug，你給了。Debug 完忘了收回來。三個月後他已經能看到所有客戶資料。
最小權限的真正執行方式是 JIT（Just-In-Time）權限：需要時申請、時間到自動撤回、全程有審計。不是「我信任你所以給你永久權限」，是「你需要的時候打開，不需要的時候關掉」。
RBAC vs ABAC：選規模適合的
RBAC（角色制）：admin、editor、viewer。簡單直覺，10 人團隊用這個就夠了。
ABAC（屬性制）：「部門 = 行銷 AND 地區 = 台灣 AND 時間 = 上班時間」才能存取。強大但複雜，適合多租戶或大型組織。
不要因為 ABAC 看起來很潮就硬上。你的團隊 5 個人，RBAC 三個角色就能搞定的事情，不需要搞一套 policy engine。
# K8s RBAC 範例：最小權限
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: prod
name: read-only
rules:
- apiGroups: [""]
resources: ["pods", "services"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
namespace: prod
name: bind-read-only
subjects:
- kind: User
name: alice@example.com
roleRef:
kind: Role
name: read-only
apiGroup: rbac.authorization.k8s.ioService Account：最容易被忽略的身分
人的帳號有 HR 流程管離職撤權。但 service account 呢？那個三年前建的 CI bot token，有人記得它有多大權限嗎？
Service account 的治理原則：短期憑證（不要給永久 token）、最小權限（CI 只需要 push image，不需要 admin）、定期輪替。還有不要把 token 寫在 Slack 上。
MFA 和零信任：不是潮流，是底線
MFA 就是第二道門。TOTP（Authenticator app）最實用，SMS 太容易被 SIM swap，FIDO2 硬體金鑰最安全但成本高。至少高權限帳號要強制 MFA。
零信任不是一個產品，是一個假設：沒有人預設可信，每次存取都要驗證，每個行為都要記錄。聽起來很累？但比起事後清理被入侵的系統，這已經是最省力的方式了。
出事時你最需要的：Audit Log
權限治理最怕的不是被攻擊，是「不知道誰做了什麼」。
Audit log 要記錄：誰、什麼時候、做了什麼、在哪個資源上、結果是什麼。保留至少 90 天。出事時這是你唯一的證據。
權限就像家裡的鑰匙。你不會因為信任室友就把所有房間的鑰匙都給他——更不會在他搬走之後忘記換鎖。