[infra] Identity & Access：權限邊界與最小可用權限

Identity & Access：誰能做什麼、做得到什麼

基礎設施最容易出事的地方，不是機器壞了，而是權限沒有邊界。 Identity & Access 的目標是把每個人的行為限制在合理範圍內，做到「能做事但不能做壞事」。

當系統規模變大，你會遇到這些問題：

• 共用帳號導致責任無法追蹤
• 權限越給越大，變成「誰都能刪資料」
• 外部協作者加入後忘了回收權限

IAM 的工作就是把這些風險降低，並建立可維運、可稽核的存取流程。

架構概覽

flowchart LR
  User[使用者/工程師] --> IdP[IdP/SSO
(Okta/Google)]
  IdP --> MFA[MFA/2FA]
  MFA --> Access[Access Gateway]
  Access --> Git[GitLab]
  Access --> CI[CI/CD]
  Access --> Infra[Infra Console]
  Access --> DB[(Database)]

核心概念

1. 身分是基礎（Identity）

   • 所有權限都要綁定「人」或「服務帳號」。
   • 避免共用帳號，確保行為可稽核。
   • 身分整合後，停用帳號即可切斷所有存取。

2. 最小可用權限（Least Privilege）

   • 只給完成任務必要的權限，不給多餘權限。
   • 例如：讀取 logs 需要 read-only，不應給刪除權限。
   • 實務建議：權限預設從最小開始，再依需求逐步擴充。

3. 角色與群組（RBAC）

   • 將權限綁到角色，再把人加入角色。
   • 方便擴充與維護，避免每人手動加權限。
   • 要避免：角色命名混亂或角色過多，會導致管理成本飆升。

4. MFA / 2FA

   • 強制多因子驗證，降低帳號被盜風險。
   • 特別是管理員與高權限帳號必須啟用。
   • 重點：OTP + 安全金鑰優先，SMS 僅作為備援。

5. 可稽核性（Auditability）

   • 每次操作要能追溯到人。
   • 例如 GitLab push、部署、DB 變更都要記錄在 audit log。
   • 建議：稽核 log 要集中化，才能串接告警。

使用情境（具體場景）

• 新人加入：只要加入「工程師」群組就能取得必要存取權限，避免人工逐一授權。
• 外包或短期協作者：使用期限型帳號，結束後自動停用，避免留有未被回收的權限。
• 事故追查：透過 audit log 可以快速找到誰在何時變更配置。
• 高風險操作：例如 production 資料庫權限，透過 JIT（Just-In-Time）方式臨時升權。

實作範例 / 設定範例

1) RBAC 權限模型（範例）

roles:
  - name: infra-admin
    permissions:
      - read:* 
      - write:* 
      - delete:*
 
  - name: dev
    permissions:
      - read:logs
      - read:metrics
      - write:deploy
 
  - name: viewer
    permissions:
      - read:metrics
      - read:status

2) GitLab Group Access（概念示意）

# 將使用者加入群組 (示意)
gitlab group add-member --group infra --user alice --role developer
 
# 調整權限為維護者
gitlab group update-member --group infra --user alice --role maintainer

3) MFA 強制策略（Google Workspace 概念）

Policy: Enforce MFA for Admins
- target: group=infra-admin
- requirement: 2FA required
- allowed methods: TOTP, SecurityKey
- grace period: 7 days

4) SSH Access Gateway（以 bastion 為例）

# ssh_config 範例
Host bastion
  HostName bastion.example.com
  User ops
  IdentityFile ~/.ssh/id_ed25519
 
Host internal-*
  ProxyJump bastion
  User ops

權限生命週期與帳號治理

權限應該有生命週期，而不是「給了就永久存在」。常見做法是：

• 新人入職給「最低可運作權限」，一週後再檢視是否需要擴權
• 專案結束即回收存取權
• 高權限僅透過短時間提升（Just-In-Time Access）
• 每季做一次 Access Review，讓主管或 Owner 確認權限合理性

Token / Key 管理與旋轉

服務帳號的 token 與金鑰是最常被忽略的風險點。你可以規劃每 30~90 天輪替一次，並在 CI/CD 中使用短期憑證。

5) Token 旋轉流程（概念示意）

# 1. 產生新 token
new_token=$(vault write -field=token auth/token/create policies=deploy ttl=72h)
 
# 2. 更新 CI/CD 變數（示意）
ci vars set DEPLOY_TOKEN "$new_token"
 
# 3. 觀察新 token 是否正常使用
sleep 3600
 
# 4. 失效舊 token
vault token revoke $OLD_TOKEN

稽核與監控

除了記錄登入，還要記錄「做了什麼」。例如：

• 誰在什麼時間修改了 DNS 記錄
• 誰啟動了 production 的部署
• 誰調整了防火牆規則

這些事件必須能匯入集中式 log，並與 Alerts & ChatOps 串接。

常見問題與風險

• 共用帳號： 多人共用一個 admin 帳號，事後無法追查責任。必須改用個人帳號 + RBAC。

  • 為什麼會發生：臨時需求或快速救火時，最容易出現共用帳號。

• 權限膨脹： 為了方便給太多權限，長期累積變成「誰都能刪資料」。應定期權限盤點（Access Review）。

  • 避免方式：建立權限審核流程，至少每季檢查一次。

• MFA 不一致： 只有部分系統啟用 MFA，攻擊者會挑最弱點入侵。高權限系統必須強制。

  • 避免方式：在 IdP 層統一設定 MFA 強制政策。

• 服務帳號外洩： CI/CD 或應用服務常用 token，如果沒有最小化權限與定期旋轉，風險極高。

  • 避免方式：使用短期 token，並強制過期。

• 缺乏監控： 沒有登入與操作記錄，事件發生後難以追查與修復。

  • 避免方式：集中 log 並設定關鍵事件告警。

優點

• 權限清楚，責任可追溯
• 降低內部誤用與外部入侵風險
• 新人與外部協作者可快速上手

缺點 / 限制

• 初期建置成本高，需整理角色與權限
• 過度嚴格會降低效率，需要平衡
• 系統太多時，權限模型可能不一致

落地檢查清單

• 是否禁止共用帳號
• 是否有 RBAC 與群組管理
• 是否強制 MFA
• 是否能產出 audit log
• 是否定期權限盤點

---

延伸閱讀

• CD
• Alerts & ChatOps
• Metrics & Monitoring