服務定位

Okta 是 人類身份的控制面、不是 cloud resource permission engine。把 cloud IAM（AWS IAM、Google Cloud IAM、Azure RBAC）的角色指派交給 Okta 是常見組合 — Okta 負責「這個人是誰」、雲端 IAM 負責「這個身份能對 resource 做什麼」。Workforce Identity Cloud（員工）跟 Customer Identity Cloud（消費者、原 Auth0）是兩個產品線、安全模型跟事件分布都不同（本頁聚焦 Workforce、Auth0 見 Auth0 vendor）。

跟自管 IdP（Keycloak）相比、Okta 把 issuer 信任、signing key 生命週期、support tooling 都託管出去 — 代價是 第三方控制面的事故會直接打到自己（Okta 2022 Sitel 環境洩漏、2023 support system HAR token 外洩、2023 cross-tenant impersonation）。跟 cloud-native SSO（AWS IAM Identity Center）相比、Okta 的核心優勢是 多雲 + SaaS app 數百個 integration 預先建好、不是綁單一雲廠。

本章目標

讀完本頁、讀者能判斷：

1. Okta 該承擔哪一段 identity 控制（SSO / MFA / lifecycle / federation）、哪一段該交給雲端 IAM
2. Okta tenant 的信任邊界與最低稽核需求（admin role、API token、SCIM、support workflow）
3. Okta 自己出事時的降級路徑（emergency access、break-glass、out-of-band MFA）
4. 何時用 Okta、何時走 Auth0 / Keycloak / AWS IAM Identity Center 的取捨

最短判讀路徑

判斷 Okta 配置是否健康、最少看四件事：

• 誰能做什麼：Super Admin / Org Admin / Read-Only Admin 的人數、是否走 Okta 自己的 access request workflow、是否強制 phishing-resistant 認證
• 憑證在哪裡：API token 的 owner、scope、TTL、是否走 OAuth service app 而不是 personal API token；service account 是否獨立 audit
• 入口如何暴露：SSO 是 SAML 還是 OIDC、IdP-initiated 是否關閉、admin console 是否限 IP / device trust、helpdesk reset 是否要 callback / out-of-band 驗證
• 證據是否可回查：System Log 是否同步到 SIEM、admin / token / impersonation 事件是否 alert、是否保留 90 天以上

四件事任一缺失、就是 Audit Log 與 Authorization 邊界的待補項目。

日常操作與決策形狀

Onboarding / lifecycle：HR 系統推 SCIM 進 Okta、Okta 推 SCIM 到下游 SaaS / 雲端 SSO。決策點是 誰是 source of truth — HRIS 還是 Okta 自己。混用會造成 stale account 與例外帳號無法收。

Policy（authentication）：Sign-On Policy 跟 Authentication Policy（New Policy Framework）兩套並行、要避免規則交疊。高風險操作（admin login、寫權限應用）應該強制 phishing-resistant factor（WebAuthn / passkey）、不只是 push MFA（Uber 2022 揭露：純 push MFA 抗不過 fatigue）。

MFA factor 選擇：避免 SMS / voice 作為主要 factor。Okta 2024 把 telephony 推給客戶 BYO（Okta BYO Telephony case）— 信任邊界從「Okta 全管」變成「客戶自己挑簡訊供應商」、若沒同步調整威脅模型會把 SMS swap 風險吃下來。

API token / OAuth service app：personal API token 容易隨人員離職 stale、應該走 OAuth service app（client credentials）並把 scope 收到最小。token 不存 source code、走 Secret Management 取用。

Exception / break-glass：至少 2 個 break-glass admin、credential 離線存（紙本保險箱 / secret management 隔離 tenant）、走獨立 MFA（hardware key、不依賴主要 Okta tenant 的 push）、季度驗證可用。Okta tenant 整個失聯時這是唯一退路。

Audit / handoff：System Log 推進 SIEM、特別 alert 三類事件 — admin role 變更、API token 建立、impersonation / support access。Okta 2023 support system 事件展示：如果客戶沒 alert support impersonation 的 session、就只能等 Okta 公告。

核心取捨表

選 Okta 的核心訴求：跨雲 + 大量 SaaS app + lifecycle 要自動化、且能接受第三方控制面風險、有預算做完整 SIEM / break-glass / 第三方應變流程。

進階主題

Federation 跟 workload identity：Okta 對人類 SSO 強、對 workload identity 較弱。CI / 服務間用 AWS IAM role 的 OIDC trust、Google workload identity federation 比把 Okta API token 散到服務裡更安全。

Cross-tenant 邊界：B2B 合作（partner、contractor）要清楚是「partner 用自己 IdP 做 federation 進來」還是「partner 在我的 Okta tenant 開帳號」。2023 cross-tenant impersonation 事件（Okta Cross-Tenant case）揭示：admin 工具若沒限定 tenant scope、單一 admin compromise 會跨多 tenant 擴散。

Device trust / posture：Okta Device Trust + EDR signal 是補 phishing-resistant MFA 之後的下一層 — 確認 使用者 對之外、確認 裝置 健康。BYOD 比例高的組織這層做不起來就靠人類因子守。

Identity Threat Protection / ITP：Okta 2024 推的事件偵測 add-on、補 session anomaly、credential stuffing、impossible travel 等場景。本質是把 SIEM detection 的一部分內建、不是取代外部 SIEM。

排錯與失敗快速判讀

• Admin account 過多：經常超過必要 — 用 Group Rules + Access Request workflow 收斂、把日常操作用 Read-Only Admin + 特定權限 group 替代
• API token stale / 散落：personal API token 跟著員工離職留下 — 季度盤點、改 OAuth service app
• SMS MFA 還是預設：MFA enrollment 沒強制 WebAuthn / passkey、新員工選最弱 factor — Authentication Policy 應該限制可選 factor
• System Log 沒進 SIEM：事件只在 Okta UI、alert 沒接 on-call — 用 Log Streaming（CloudWatch / S3 / Splunk HEC）打進 SIEM、特定事件接 alert runbook
• Helpdesk reset 無 callback：MGM 2023 / Caesars 2023 都是 helpdesk social engineering、需要 callback + out-of-band 驗證、不是 ticket 上看到「我忘記密碼」就 reset
• Support 工具 session 沒監控：Okta 2023 support 事件揭示需要 alert support impersonation session 進入我的 tenant 的事件 — System Log 有對應事件、但通常沒 default alert

何時改走其他服務

不在本頁內的主題

• Okta 完整 SAML / OIDC 規格細節、SCIM schema 客製
• Workforce vs Customer Identity Cloud 完整功能對照
• Okta 各定價層級的功能差異
• 各 SaaS app 的 SSO 接線教學

案例回寫

下一步路由

• 上游：7.2 身分與授權邊界、7.13 偵測覆蓋率與訊號治理
• 平行：Auth0 vendor、Keycloak vendor、AWS IAM Identity Center
• 下游：AWS IAM / Google Cloud IAM / Azure RBAC（Okta 之後的 cloud resource permission 層）
• 跨模組：8 事故處理 vendor 清單（Okta 事件如何 routing 進 IR 流程）
• 官方：Okta Documentation

服務定位

Auth0 是 customer identity 的控制面、不是員工 SSO（員工走 Okta Workforce 或 AWS IAM Identity Center）。雖然 Auth0 於 2021 被 Okta 收購、目前屬「Customer Identity Cloud」產品線、跟 Workforce Okta 是 同公司不同 control plane：tenant 叢集、事件分布、signing key 託管路徑都分開、Okta Workforce 的事故（2022 Sitel、2023 support system HAR）並未直接打到 Auth0 customer。

跟自管 Keycloak 比、Auth0 把 Universal Login UI、social connection 預建、Rules / Action runtime、attack protection 都託管出去 — 代價是 SaaS 計費、token issuance / login attempt 都計量、流量大的 B2C 場景遇到 credential stuffing 不擋會吃成本。跟 AWS Cognito / Firebase Auth 比、Auth0 的核心優勢是 developer-first tenant 體驗 + 預建 social connection（Google / Facebook / Apple / Microsoft 等數十種）+ Action hook 寫 JS 客製。

本章目標

讀完本頁、讀者能判斷：

1. Auth0 該承擔哪一段 customer identity 控制（login flow / token broker / profile store / B2B Organizations）、哪一段該回到自己的 app
2. Auth0 tenant 的信任邊界與最低稽核需求（admin role、management API token、Action 程式碼、connection 設定）
3. Auth0 流量出事或母公司事件時的降級路徑（fallback connection、token rotation、anomaly throttle）
4. 何時用 Auth0、何時走 Cognito / Firebase Auth / Keycloak 的取捨

最短判讀路徑

判斷 Auth0 tenant 是否健康、最少看四件事：

• 誰能做什麼：Dashboard admin、Management API token 的 owner 與 scope、Action 是否走 code review、tenant 之間（dev / staging / prod）是否分離且授權獨立
• 憑證在哪裡：Management API token / M2M client 的 scope 與 TTL、社交 connection 的 client secret 存放位置、signing key（per-tenant）的 rotation 節奏、是否啟用 Custom Domain（避免 token issuer 暴露 *.auth0.com 域名）
• 入口如何暴露：登入走 Universal Login（託管 UI）還是 Embedded Login（嵌自家 app）、Cross-Origin Authentication 是否打開、Attack Protection（bot detection / brute-force / breached password / suspicious IP throttling）配置強度
• 證據是否可回查：Tenant Log 是否同步到 SIEM（Log Stream 推 HTTP / Datadog / Splunk）、登入失敗 / Action 例外 / Management API 變更是否 alert、保留期是否符合合規要求

四件事任一缺失、就是 Audit Log 與 Authentication 邊界的待補項目。

日常操作與決策形狀

Tenant 與環境分離：Auth0 的 tenant 是邏輯隔離的多租戶 SaaS、不是物理叢集。每個環境（dev / staging / prod）開獨立 tenant、避免 dev 的 Action bug 打到 prod 流量、避免共用 client secret 跨環境洩漏。tenant 間用 auth0-deploy-cli 同步配置、Action 程式碼進版控。

Connection 設計：Database Connection（Auth0 託管帳密 store）跟 Social / Enterprise Connection（OIDC / SAML federation 到 Google / Microsoft / Okta）是兩種來源。決策點是 user 是否要進 Auth0 profile store — 純 federation 不存密碼、純 Database Connection 是 Auth0 替 app 管帳密表。混用要清楚 primary identity 與 linked account 的合併規則。

Action / Rule hook 的風險：Action（新框架）跟 Rule（舊框架）讓 tenant admin 在 login pipeline 注入 JS 程式碼（pre / post login、M2M、send email 等）。這是 Auth0 強大但也是 最大的供應鏈攻擊面 — Action 可以 require() npm package、惡意 dependency 會在每個 login flow 執行。應該 pin dependency 版本、code review、用最小權限的 Management API scope、定期掃 dependency CVE（思維對齊 紅隊 supply chain 案例）。

Universal Login vs Embedded Login：Universal Login 把登入 UI 託管在 Auth0 domain（或 Custom Domain）、user 跳轉到該頁完成登入後 redirect 回 app — 防 phishing / CSRF 的成本由 Auth0 吃。Embedded Login 把登入表單嵌進自己 app 並用 /co/authenticate 端點 — 看似 UX 順、但要自己防 XSS、CSRF、CORS、credential leak、且要打開 Cross-Origin Authentication（暴露額外攻擊面）。預設選 Universal Login、Embedded 只在 UX 強需求且能承擔安全成本時開。

Management API token / M2M client：Management API 控制整個 tenant（建 user、改 client secret、改 Action 程式碼）。token 不該長期存在程式碼或 CI；改用 M2M Application（client credentials grant）拿短期 token、scope 收到最小（read:users ≠ update:users ≠ update:actions）、走 Secret Management 取用。

Attack Protection 配置：B2C 流量大、登入嘗試本身計費也是攻擊面。Brute-force Protection（單 IP 多失敗鎖 user）、Suspicious IP Throttling（單 IP 多失敗鎖 IP）、Breached Password Detection（已洩漏密碼禁用）、Bot Detection（CAPTCHA / risk score）四個機制都該打開、否則 credential stuffing 既吃成本也提高帳號被接管的機率。

Break-glass 與 fallback：B2C 場景沒有「員工備用 admin」概念、break-glass 是 確保使用者在 Auth0 暫不可用時仍能登入。常見作法：app 端容忍 Auth0 暫時失敗、提供 magic link / email OTP 的替代登入路徑（透過獨立 ESP）、或預先發放長 TTL 的 refresh token 撐過短時故障。tenant 管理面則維持至少 2 個獨立 admin、credential 離線存。

Audit / handoff：Tenant Log 透過 Log Stream 推 SIEM、alert 三類事件 — Management API 對 Action / Connection / Client 的變更（供應鏈）、登入異常突增（credential stuffing）、support impersonation / Auth0 員工 access tenant 的紀錄（control plane）。

核心取捨表

選 Auth0 的核心訴求：customer identity + 大量 social / enterprise connection + 要 developer 客製 login flow、且接受 SaaS 計費與第三方控制面風險、能投入 SIEM / Action 程式碼治理 / attack protection 配置。

Microsoft 生態（Entra External ID / 前 Azure AD B2C）是另一個 B2C / B2B 選項、本表沒列入主要競品 — 它在 M365 / Azure 重度組織內是合理選擇、但 social connection 預建廣度跟 developer-centric tenant 體驗仍不及 Auth0。M365 重度 + B2C 需求的組織可同時評估 Entra ID 的 External ID 產品線。

進階主題

Action / Rule 的供應鏈治理：Action 程式碼進版控、走 PR review、auth0-deploy-cli 部署。Action 引用的 npm dependency pin 版本、避免 ^ / ~、CI 跑 SCA 掃 CVE。新增 Action 時 default scope 給 read-only、需要寫操作另外升級。Action secret（OAuth credential、API key）走 Action Secret 管理、不寫死在程式碼。

B2B Organizations：Auth0 Organizations 把同 tenant 內的多客戶（B2B 場景）邏輯隔離 — 每個 organization 有自己的 connection、branding、member。設計點是 user 是 organization member 還是 tenant-wide user、跨 organization 操作的 admin 是否有 organization scope。Organization 之間的隔離是 tenant 內邏輯層、共享底層 control plane、不能等同實體 tenant 隔離。

Adaptive MFA / Step-up Authentication：Auth0 Adaptive MFA 用 device / location / behavioral signal 動態升級 MFA 要求（impossible travel、新裝置、低信任 IP）。屬付費 add-on、本質是把 risk-based 認證內建。對 B2C 場景比強制全 user MFA 友善、但要把 risk threshold 跟 false positive 容忍度 設清楚、避免合法 user 被連續挑戰流失。

Custom Domain：預設登入網域是 <tenant>.auth0.com、揭露使用 Auth0 與 tenant 名稱、且 issuer 是 Auth0 子網域。Custom Domain 把 issuer 改成自己網域（如 login.example.com）、user 看到的 URL 一致、降低 phishing 對照成本。屬付費功能、production app 預設應該開。

Cross-Origin Authentication 的攻擊面：Embedded Login 必須開 Cross-Origin Authentication、讓 app 域名直接呼叫 Auth0 的 /co/authenticate。風險是 XSS 拿到 token、CSRF 偽造登入、third-party cookie 政策變動讓 silent auth 壞掉。Universal Login 不需要這個、所以同樣風險不存在 — 這是 Universal Login 推薦的核心理由。

排錯與失敗快速判讀

• Management API token 散落 / 過權：CI / 後端服務各自存 token、scope 都給 update:users / update:actions — 改 M2M Application + 最小 scope、定期 rotate、用 Secret Management 集中取用
• Action 直接 require 未 pin 的 npm package：login flow 每次都拉最新版、惡意 dependency 直接執行 — pin 版本、code review、定期掃 CVE
• 登入嘗試暴增 / 計費突增：Attack Protection 沒開或門檻太鬆、credential stuffing 吃額度 — 打開 Bot Detection、Brute-force、Suspicious IP Throttling、配合 Anomaly Detection
• 使用 Embedded Login 又沒控 XSS：自家 app 一旦 XSS、token 直接被偷 — 改 Universal Login、或補上嚴格 CSP / DOM 防護、定期 pen test
• Tenant Log 沒進 SIEM：事件只在 Dashboard、無法跨系統 correlation — 配 Log Stream 打到 SIEM、特定事件接 alert runbook
• 沒 Custom Domain：phishing 對照成本低、issuer 暴露 vendor — 配 Custom Domain、TLS cert 自管或走 Auth0 託管
• B2B Organizations 缺 scope 限制：admin 工具沒按 organization scope、單一 admin compromise 跨 organization 擴散 — 思維對齊 Okta Cross-Tenant 2023 的 lesson

何時改走其他服務

不在本頁內的主題

• Auth0 完整 OIDC / OAuth2 規格細節
• Action / Rule 完整 API 與 trigger 清單
• B2B Organizations 完整 schema 與 SDK 整合教學
• Auth0 定價層級的詳細功能對照
• 各 social connection provider 的 OAuth app 註冊步驟

案例回寫

Auth0 在 07 沒有直接案例（母公司 Okta 的事件並未直接打到 Auth0 customer），以下案例採對照引用、抽取對 Auth0 customer 的 lesson。要注意的是 缺直接案例不等於 vendor 沒有風險 — Auth0 自 2021 被 Okta 收購以來未公開重大 vendor 級事件、但同類 SaaS IdP 的歷史事件（Okta 集團、signing key 託管、credential stuffing）都是 Auth0 customer 的可預期風險面、不該等到第一次出事才補控制：

下一步路由

• 上游：7.2 身分與授權邊界、7.13 偵測覆蓋率與訊號治理
• 平行：Okta vendor、Keycloak vendor、AWS IAM Identity Center
• 下游：AWS IAM / Google Cloud IAM（Auth0 認證後的 cloud resource 權限層）
• 跨模組：8 事故處理 vendor 清單（Auth0 異常如何 routing 進 IR 流程）
• 官方：Auth0 Documentation

服務定位

Keycloak 是 自管控制面 的 human identity 與 federation engine、不是 cloud resource permission engine。跟 Okta / Auth0 的本質差異在於信任邊界落點：SaaS IdP 把 signing key、tenant 隔離、support workflow 都託管出去、客戶承擔「供應商出事我也跟著被打」的風險；Keycloak 把整條控制面收回自家機房或自家 VPC、客戶承擔「signing key 過期 / DB 崩 / Java app CVE 沒跟上」的運維風險。

跟 cloud-native SSO（AWS IAM Identity Center）相比、Keycloak 的核心優勢是 不綁雲廠 + 可深度客製 authentication flow + 資料不出境。適合垂直：金融、政府、醫療某些不接受 SaaS IdP 的場景；以及預算敏感、員工數中等、SRE 量能足以接 24/7 on-call 的組織。

本章目標

讀完本頁、讀者能判斷：

1. Keycloak 該承擔哪一段 identity 控制（SSO / MFA / federation / brokering）、哪一段該交給雲端 IAM 或下游應用
2. 自管 IdP 的最低運維基線（HA、DB DR、cert / signing key rotation、CVE cadence、SIEM 接點）
3. Realm / Client / User Federation / Identity Broker / Authentication Flow / SPI 各自的決策時機與陷阱
4. 何時用 Keycloak、何時改走 SaaS（Okta / Auth0）或其他 OSS（Authentik / Zitadel）

最短判讀路徑

判斷 Keycloak 部署是否健康、最少看 SaaS IdP 的四件事加上自管特有的四個維度：

• 誰能做什麼：master realm admin 的人數、是否走 access request workflow、admin console 是否限 IP / device trust、是否強制 phishing-resistant 認證
• 憑證在哪裡：client secret 是否走 secret management、realm signing key 的 rotation 排程、admin token 的 TTL
• 入口如何暴露：哪些 realm 對外、reverse proxy / Ingress 是否做 rate limit、admin console（/auth/admin）是否限內網或 zero trust
• 證據是否可回查：Event Listener SPI 是否接 SIEM、admin event 跟 login event 是否分流、保留期是否符合稽核
• DB 健康：PostgreSQL / MySQL 是否跨 AZ、是否有 PITR、是否做過 restore 演練（不是只有備份成功訊息）
• Cert lifecycle：TLS cert 與 realm signing key 各自的 rotation 排程、是否走 Website Certificate Lifecycle 自動化
• HA topology：Keycloak cluster 是否多節點、Infinispan cache 是否跨 AZ、單節點重啟是否會踢掉所有 session
• Upgrade cadence：Keycloak 每年 major release、CVE patch 是否能在 SLA 內上、是否有 staging 跑 DB migration

八個維度任一缺失、都是自管 IdP 常見事故的入口。

日常操作與決策形狀

Realm 設計：Realm 是 Keycloak 的隔離邊界、每個 realm 有獨立的 user store、client、role、signing key。multi-tenancy 走 realm 是正確選擇、但 master realm 能管所有 realm、master realm 的 admin compromise = 全公司 IdP compromise。把 master realm 鎖在內網、operational realm 才對外、是基本姿勢。

Client 註冊與 secret：每個應用是一個 client、confidential client 有 secret、public client（SPA / mobile）走 PKCE 不存 secret。client secret 不存 source code、走 secret management 注入。client 數量爆炸時要設 naming convention 跟 ownership 標記、不然 stale client 會堆積。

User Federation：把既有 LDAP / Active Directory 接進 Keycloak、user 還是住在原 directory、Keycloak 做 protocol 翻譯（LDAP → OIDC / SAML）。這是 Keycloak 強項之一 — 不需要 user migration、漸進接入。陷阱是 LDAP 連線健康 = IdP 健康、LDAP 慢 = 全公司 login 慢。

Identity Brokering：把外部 IdP（Google、Microsoft、其他 SAML / OIDC provider）federate 進來、Keycloak 當中介。B2B 合作常見模式 — partner 用自己的 IdP、不在我的 user store 開帳號。決策點是 trust mapping：外部 claim 怎麼對應到內部 role、外部 IdP 的 MFA 狀態怎麼信任。

Authentication Flow：Keycloak 把 login / registration / reset password 做成可編輯的 flow DAG、可以插入自訂 step。這是 Keycloak 跟 SaaS IdP 最大差異點之一 — 想要 step-up MFA、device fingerprint、risk-based 判斷都可以自己接。雙面刃是 自訂 flow 容易留漏洞：跳過必要步驟、condition 寫錯讓 MFA 變可選、custom Authenticator SPI 沒處理 race condition。

Theme / 客製 UI：Keycloak 支援 theme override、可以改 login page HTML / CSS / JS。custom JS 在 login page = 自己注入 XSS 風險 — theme 寫進去之後就是 IdP 本體的攻擊面、不是普通網頁。CSP 跟 input sanitization 要當成 IdP 安全規範看待。

Event Listener / Audit：Keycloak 預設只把 event 寫進 DB、UI 上能查、但 不會自動推到外部 SIEM。生產環境必須接 Event Listener SPI（內建 jboss-logging、或自寫 Kafka / file listener）把 admin event 跟 login event 推進 SIEM。沒接的話 audit trail 只在 IdP 本機、IdP 出事就拿不到 evidence。

Exception / break-glass：master realm 留至少 2 個 break-glass admin、credential 離線存、走獨立 MFA（hardware key）。Keycloak cluster 整個失聯時、用 break-glass 直連 DB / 直連單一節點救回。

核心取捨表

選 Keycloak 的核心訴求：資料主權 + 預算控制 + 客製 flow 需求、且有 SRE 團隊能 24/7 on-call、能接受自管的運維重量。團隊小於 50 人沒 SRE 量能、應用主要在 SaaS（pre-built integration 用不上 Keycloak 強項）、需要快速接 7000+ SaaS app — 都該回頭看 Okta / Auth0。

進階主題

User Federation 跟 LDAP 整合：企業環境常見「Active Directory 是 user source of truth、Keycloak 做 protocol 層」。注意 LDAP 同步策略（read-only / writable / import）、LDAP 健康直接影響 IdP 可用性、LDAP timeout 要設嚴格避免 login 卡住整個 cluster。

Identity Brokering 跟外部 IdP：把 Google / Microsoft / 其他 SAML IdP federate 進來、外部 user 進來時 Keycloak 自動建 link。trust mapping 是關鍵 — 外部 IdP 宣稱「這個 user 已 MFA」、要不要信？外部 group claim 怎麼對應到內部 role？沒有預設答案、要用 authorization 邊界決定。

Fine-Grained Authorization（UMA / Authorization Services）：Keycloak 內建 policy engine、可以做 resource-level 授權（不只是 role-based）。適合需要中央化 policy decision 的場景、但會把應用的授權邏輯綁進 Keycloak、退場成本變高。多數場景應該把 authorization 留在應用內、Keycloak 只做 authentication + role token 發行。

Custom Authenticator SPI：用 Java 寫自訂 authenticator、插進 Authentication Flow。能做 step-up MFA、device posture、risk score 判斷。陷阱是 SPI 程式碼就是 IdP 本體的一部分、bug = IdP 漏洞、必須走完整 code review + 安全測試流程、不能當普通 feature 開發。

Realm signing key rotation：每個 realm 有自己的 RSA / EC signing key、用來簽 ID token / SAML assertion。rotation 必須跟下游 client 協調（key rollover 期間 client 要能接受新舊 key）、否則 rotation 當天全公司 login 失敗。分域分批是必做的、參考 Failure: Credential Rotation Without Scope。

排錯與失敗快速判讀

• DB 是 SPOF：Keycloak 所有 state 在 PostgreSQL / MySQL、DB 出事 = IdP 停 = 全公司 SSO 停。跨 AZ replication + PITR + 季度 restore 演練、不是 nice-to-have
• Cert / signing key 過期：自管 IdP 最常見事故、TLS cert 過期擋對外 endpoint、realm signing key 過期讓所有 token 變無效。走 Certificate Rotation 自動化、過期前 30 天 alert
• Cluster split-brain：Infinispan cache 跨節點同步、網路分區時 session 狀態不一致、user 看起來登入但下一個 request 又被踢出。HA topology 設計要考慮 cache mode（distributed vs replicated）、network 健康監控要 alert split-brain
• Major upgrade 卡 DB migration：每年 major release 帶 schema migration、staging 沒跑過就 production 升級 = 數小時 downtime。upgrade plan 包含 rollback DB snapshot + staging full rehearsal
• Custom theme / Authenticator 留漏洞：theme JS 引入 XSS、custom Authenticator 跳過 MFA、SPI 沒處理 race condition。把 IdP 客製當成 supply chain 看待、走 code review + 安全測試
• Event 沒進 SIEM：預設只在 Keycloak DB、IdP 出事就拿不到 evidence。Event Listener SPI 接 Kafka / file / SIEM、admin event 跟 login event 各自接 alert runbook
• Master realm admin 過多：日常工作不該用 master realm admin、應該在 operational realm 開有限權限 admin。master realm 是 single point of compromise

何時改走其他服務

不在本頁內的主題

• Keycloak 完整 SAML / OIDC 規格細節、SPI Java API 文件
• Red Hat build of Keycloak 商業支援的差異與授權細節
• Keycloak Operator（Kubernetes deployment）的逐步部署教學
• LDAP / Active Directory 各種 schema 對應規格

案例回寫

Keycloak 沒有直接的廠商級公開事件（OSS 沒有 vendor incident 的對應形態）、自管 IdP 的失效模式以下分兩類整理：跨 vendor 共通的 同構失效 用既有 case 對照、自管 IdP 特有 的失效情境補敘事說明、避免案例表變成「同一個 frame 拼四個 case slug」。

對照引用（跨 vendor 同構失效）：

自管 IdP 特有的失效情境（沒有對應公開 vendor case、來自自管運維常見事故樣態）：

• Cert 過期讓全公司 SSO 卡死：Keycloak signing cert / TLS cert / 後端 DB cert 都自己管、任何一張過期 = login 全停。Okta / Auth0 客戶不會遇到這個失效面（vendor 自己 rotate）— 自管組織必須有 cert lifecycle monitoring（Prometheus exporter + alert）+ 季度 rotate rehearsal、不能等 Let’s Encrypt / 公司 PKI 發過期通知才動
• Major upgrade 卡 DB migration 變數小時 downtime：Keycloak 每年 major release 帶 schema migration、若 staging 沒 full rehearsal 就 production 升級、可能遇到 migration 比預期慢 5-10 倍、整個維護視窗炸掉。對照 Okta / Auth0：vendor 自己升、客戶感知是 minutes-level、不是 hours-level
• Realm scope 在小規模時用法跟大規模衝突：Contrast: Identity Governance by Scale 揭示不同規模治理模式差異 — 小團隊用單一 realm 順、團隊長大後該拆 realm 卻沒拆、最後 admin compromise blast radius 變整個組織。Keycloak 比 SaaS IdP 更容易踩到、因為 realm 拆分要自己決定時機、沒 vendor 推使用者升級 tier
• DB 是 SPOF、自管沒做好 = SSO 跟 DB 一起死：Keycloak 用 PostgreSQL / MySQL 存 user / session / signing key、DB 出事 = IdP 停。跨 AZ HA + 跨 region DR + 季度 failover 演練是硬性要求、不是 nice-to-have；SaaS IdP 客戶不會遇到這個層次的失效面

下一步路由

• 上游：7.2 身分與授權邊界、7.13 偵測覆蓋率與訊號治理
• 平行：Okta vendor、Auth0 vendor、AWS IAM Identity Center
• 下游：AWS IAM / Google Cloud IAM / Azure RBAC（Keycloak 之後的 cloud resource permission 層）
• 跨模組：8 事故處理 vendor 清單（自管 IdP 事件如何 routing 進 IR 流程）
• 官方：Keycloak Documentation

服務定位

IAM Identity Center 是 人類身份進 AWS 的 portal、不是 cloud resource permission engine。它跟 AWS IAM 的分工是兩層：Identity Center 管「人是誰、能登入哪些 account」、AWS IAM 管「進到 account 後對 resource 能做什麼」。實際機制是 Identity Center 透過 Permission Set 在每個目標 account 建一個 AWSReservedSSO_* 命名的 IAM role、使用者 assume 該 role 拿短期 STS token。

跟 Okta 相比、Identity Center 的核心優勢是 跟 AWS Organizations + Control Tower 原生整合、Permission Set 可以一次發佈到數百個 account、不必每個 account 各接 SAML。代價是 SaaS app integration 量級遠少於 Okta（Okta 7000+ 預建、Identity Center 僅中等規模）、跨雲 federation（GCP / Azure）也不在原生範圍。

許多大型組織採三層架構：Okta 是 HRIS 下游的 identity source of truth、SCIM push 進 Identity Center、Identity Center 再 map 到 AWS IAM Permission Set。Okta 管「人是誰」、Identity Center 管「AWS portal 入口」、AWS IAM 管「resource 能做什麼」。中小組織可以省略 Okta、直接用 Identity Center 內建 user store、但就失去跨 SaaS 統一 SSO。

本章目標

讀完本頁、讀者能判斷：

1. Identity Center 在 人類身份 / AWS portal / resource permission 三層裡的位置、何時該交回 AWS IAM 或上游 IdP
2. Identity Source 選擇（內建 / Active Directory / 外部 SAML）對 lifecycle 與 lock-in 的長期影響
3. Permission Set / Account Assignment / Access Portal 三個核心概念的稽核重點
4. 何時 Identity Center 夠用、何時要疊 Okta 在前、何時 Identity Center 反而是錯選擇

最短判讀路徑

判斷 Identity Center 配置是否健康、最少看四件事：

• 誰能 assume 哪個 role：Permission Set 跟 Account Assignment 是否走最小權限、AdministratorAccess 範圍 Permission Set 是否限定 break-glass、是否強制 phishing-resistant 認證 才能 assume 高權限
• Permission Set 邊界：每個 Permission Set 的 session duration（預設 1 hour、可調 12 hour）、inline policy vs Customer Managed Policy reference、是否用 ABAC tag 收斂跨 account 散佈
• External IdP federation 狀態：Identity Source 是內建 / AD / 外部 SAML、若走外部 IdP SCIM push 是否監控 sync 失敗、signing certificate 是否在 rotation 排程內
• CloudTrail 是否完整：Identity Center 事件分布在 management account 跟 member account、是否有 organization trail 收齊、admin 變更 / Permission Set 變更 / failed assume 是否 alert

四件事任一缺失、就是 Audit Log 與 Authorization 邊界的待補項目。

日常操作與決策形狀

Identity Source 是根信任：Identity Center 支援三種 user/group 來源 — 內建 store、AWS Managed AD / on-prem AD via AD Connector、外部 SAML IdP（Okta / Entra ID 等、SCIM 推進來）。選了之後 user lifecycle 從哪來就鎖死、換 Identity Source 是大工程（要重建所有 Permission Set assignment、舊 user GUID 不通用）。早期決定錯比 Permission Set 設錯難救。

Permission Set 是 cross-account role template：定義一次、apply 到多 account、實際在每個 account 部署成一個 AWS-Reserved 命名的 IAM role。Permission Set 本身不是 role、是 role 的部署模板 — 改 Permission Set 會 push 到所有 account 上對應的 role。Customer Managed Policy reference 比 inline policy 好維護、但要先確保每個 target account 都有同名 policy、否則 assignment 會失敗。

Account Assignment：把 user/group 綁到 Permission Set + 特定 account 的三元組。這層用 group 而不是個別 user、跟著 Identity Source 的 group 變動自動同步。臨時權限（離職員工延長、incident 應變）走 access request workflow 或 IAM Access Analyzer + Just-in-Time、不要永久 assignment。

Access Portal URL 是 phishing 目標：custom URL（https://<alias>.awsapps.com/start）設定後變成員工每天用的入口、phishing 攻擊會 mimic。要強制 phishing-resistant MFA（WebAuthn / passkey）、純 push MFA 抗不過 fatigue。CLI 走 aws sso login 自帶 browser-based flow、不要叫員工複製貼 access key。

Application assignment：Identity Center 也能管 SAML app 的 SSO assignment、但 integration 數量遠少於 Okta。大量 SaaS app 的場景應該疊 Okta 在前、Identity Center 只管 AWS portal。

核心取捨表

選 Identity Center 的核心訴求：AWS 是主要工作環境、員工 SaaS app 用量低、要統一多帳號入口而不要再付 Okta 訂閱。員工大量用 SaaS 的場景應該疊 Okta 在前。

進階主題

External IdP federation（Okta / Entra ID SCIM 進來）：Identity Center 接外部 IdP 是 push model — IdP 主動 SCIM push、Identity Center 不 pull。push provisioning 失敗會 silent（IdP 端有 log、Identity Center 端只看到 user 沒出現）、要在 IdP 端設 sync failure alert。SAML signing certificate rotation 兩邊都要排程、過期會整個 federation 斷。

Multi-account Permission Set 設計：避免每個 environment / team 各自一份 Permission Set — 用 ABAC（tag-based access control）把「Environment=Prod + Team=Payments」的條件寫進一個 Permission Set 的 policy、tag 跟著 user attribute 跑。Permission Set 數量爆炸是 Identity Center 老化最常見訊號。

Customer Managed Policy reference：Permission Set 可以 reference target account 裡的 customer managed policy（同名同 path）、policy 本身在每個 account 獨立維護。比 inline policy 適合大規模、但要靠 CI / Terraform 確保 policy 在所有 target account 同步存在、否則 assignment 失敗。

Session duration 是攻擊面：預設 1 hour、可調到 12 hour。長 session 對 dev 體驗友善、但不利於 credential rotation — 高權限 Permission Set（AdministratorAccess、production write）應該短 session（1-2 hour）、低風險 read-only 可放 8-12 hour。

IAM Identity Center API 不該當 workforce IdP 用：API 是給 admin 管 assignment 用、不是給 app 拿 user token。要 workforce app SSO 走 SAML / OIDC federation、不要叫 app 打 Identity Center API 查 user。

排錯與失敗快速判讀

• Permission Set 數量爆炸：每個 team / environment 各一份、上百個 Permission Set 沒人敢動 — 改用 ABAC + user attribute 把條件寫進 policy、收斂到十位數
• Identity Source 選錯難換：早期選內建 store、後來公司導入 Okta 要換成外部 SAML — 整個 user GUID 重新映射、Permission Set assignment 重綁、評估比建新 tenant 還久
• External SCIM sync 失敗 silent：Okta 端 push 失敗、Identity Center 沒人 — 要在上游 IdP 設 SCIM provisioning failure alert、不要等使用者反映「我登不進去」
• Access Portal URL 被 phishing：custom URL 員工記憶、phishing 站 mimic、無 phishing-resistant MFA 擋不住 — 強制 WebAuthn / passkey、員工教育只認 bookmark / SSO launcher
• CloudTrail 不完整：只開 management account trail、member account 的 role assumption 看不到 — 開 organization trail 收齊、特別 alert Permission Set 變更與失敗 assume
• Break-glass 缺席：Identity Center 控制面故障時 console 進不去 — 保留每個 account 的 root credential（離線存）跟少數 break-glass IAM User（hardware MFA、與 Identity Center 獨立 audit）、季度驗證

何時改走其他服務

不在本頁內的主題

• AWS IAM 的 policy / role / STS 機制細節（屬 AWS IAM vendor 頁）
• Permission Set 的 JSON policy 撰寫教學
• AWS Organizations / Control Tower 的完整架構
• 各 SaaS app SAML 接線教學

案例回寫

下一步路由

• 上游：7.2 身分與授權邊界、7.13 偵測覆蓋率與訊號治理
• 平行：Okta vendor（外部 IdP 疊在前）、Auth0 vendor、Keycloak vendor
• 下游：AWS IAM vendor（Permission Set 落地的 resource permission 層）、Google Cloud IAM / Azure RBAC（多雲對照）
• 跨模組：8 事故處理 vendor 清單（Identity Center 事件如何 routing 進 IR 流程）
• 官方：AWS IAM Identity Center Documentation

服務定位

Entra ID 是 Microsoft 自有的 workforce IdP、跟 Okta 是直接競爭者。M365 / Azure-heavy 的組織通常直接用 Entra ID 當主 IdP；Okta-first 的組織可以把 Entra ID 當下游 SP（federation）、也可以雙 IdP 並存、但雙 IdP 的 break-glass 跟 lifecycle 路徑要重新設計。Entra ID 同時承擔 consumer-side 跟 partner-side 的 multi-tenant app 信任、跟 Auth0 在 B2C 場景有交集。

Azure RBAC 是 cloud resource permission engine、跟 AWS IAM / Google Cloud IAM 同層 — 都在解「身份對 cloud resource 能做什麼」。差異在 scope hierarchy — Azure 用 Management Group → Subscription → Resource Group → Resource 四層繼承、AWS 用 account + organization、Google 用 organization → folder → project。Azure RBAC 預期 role assignment 沿 scope 向下繼承、這跟 AWS 在每個 account 重新指派的習慣不一樣、跨雲團隊轉過來常踩到。

本章目標

讀完本頁、讀者能判斷：

1. 哪一段控制屬於 Entra ID（身份）、哪一段屬於 Azure RBAC（resource permission）、不要把兩層當同一件事
2. Entra ID tenant 的最低稽核需求（Global Admin、App Registration、Conditional Access、Managed Identity）
3. Azure RBAC 的 scope 設計、Custom Role 跟 PIM 何時必要
4. Entra ID 控制面事故的降級路徑、跟 Azure RBAC 出事的徵兆差異

最短判讀路徑

判斷 Azure 雙層體系是否健康、要分兩層各看兩件事、跟「日常操作與決策形狀」段的兩層結構對齊。

Entra ID 層（身份控制面）：

• 誰能做什麼：Global Admin / Privileged Role Administrator 的人數、是否走 PIM just-in-time、Conditional Access 是否強制 phishing-resistant 認證、break-glass 帳號是否 exclude 自所有 CA policy 又單獨監控
• 入口如何暴露：App Registration 是否限定 single-tenant、multi-tenant app 的 admin consent 流程是否經審查、Managed Identity 是否取代 service principal client secret

Azure RBAC 層（resource permission）：

• 誰能對 resource 做什麼：Owner / Contributor 在哪個 scope（Management Group 還是 Subscription）、production 環境是否用 Custom Role 收緊權限、有沒有 standing assignment 該改 PIM
• 證據是否可回查：Entra ID Sign-in Log / Audit Log 是否同步到 SIEM、Azure Activity Log 是否設保留與 alert、admin consent / role assignment 變更是否觸發 alert runbook

兩層任一邊任一條缺失、就是 Audit Log 與 Authorization 邊界的待補項目。

日常操作與決策形狀

Entra ID 層

User / Group / lifecycle：HRIS 推 SCIM 進 Entra ID、Entra ID 同步到下游 SaaS 跟 Azure RBAC group。決策點是 source of truth — 多數組織把 HRIS 設為人員來源、Entra ID 當分發層、避免雙寫造成 stale account。

Conditional Access 是 MFA 主要強制機制：MFA 不是設在 user 屬性上、是 Conditional Access policy 在登入時判斷 user / device / location / app / risk 後觸發。常見設定錯誤包含 exclude legacy auth 沒做、break-glass 規則太寬、emergency access 帳號沒獨立監控。Conditional Access 規則設計錯、就是高權限 bypass 的入口。

App Registration vs Enterprise Application：開發者註冊 multi-tenant app 走 App Registration（app 的定義）、組織 admin 為某 app 設定 SAML SSO / admin consent 走 Enterprise Application（該 tenant 對 app 的信任）。兩者常被混講、但安全意義不同 — App Registration 是「我們做了一個 app」、Enterprise Application 是「我們信任這個 app 用我們的身份」。Consent phishing 攻擊就是針對後者。

Managed Identity：Azure resource（VM、Function、AKS pod）自帶身份、不需要 service principal client secret、跟 Google Workload Identity Federation 同概念但 Azure-internal。System-assigned 跟 resource 生命週期綁定、resource 刪掉 identity 跟著刪；User-assigned 獨立、可跨 resource 共用。production 環境的服務存取 Key Vault / Storage 應走 Managed Identity、不該用 client secret。

Workload Identity Federation：Entra ID 可以 trust 外部 OIDC issuer（GitHub Actions、AWS、Google）、讓外部 workload 直接拿 Entra ID token、不用儲存 client secret。CI/CD 的 OIDC 整合是這層的主用例、比把 client secret 塞進 CI variable 安全很多。

Signing key 是 control plane 託管：Entra ID 不暴露 signing key、客戶沒有 rotate 它的能力。這層信任邊界一旦失守、客戶側 直接修不了、要等供應商發 patch 或公告 — Storm-0558 揭示了這條依賴的代價。客戶側能做的補強是 下游檢查 而非 上游修復：

• 訂閱 Microsoft Security Advisory（MSRC）+ tenant-specific notification、讓事件公告第一時間進 IR pipeline、不要靠新聞才知道
• SIEM alert anomalous token issuance pattern（跨租戶 token 在 Exchange / Graph API 出現異常存取序列）、不能只信 token signature valid
• 高敏 app 的 token validation 不只看 Entra ID 標準驗證、加 issuer + tenant + audience + nonce 多層比對、攻擊者偽造跨租戶 token 時可能漏掉某層
• Conditional Access 配 token protection（token binding to device）、降低 stolen token replay 的命中率
• IR playbook 預設 signing key 事件 一條 — 一旦供應商公告、強制 sign-out 高權限 user、token TTL 收短、回頭看 90 天 sign-in log 找異常

Azure RBAC 層

Scope 設計：role assignment 沿 Management Group → Subscription → Resource Group → Resource 向下繼承。在 Management Group 給 Contributor、底下所有 subscription / RG / resource 都繼承 — 這既是優點（統一治理）也是風險（誤指派擴散範圍大）。設計原則是 指派盡量低、不要對全 Management Group 給 Contributor。

Built-in role vs Custom Role：Owner（含 user access admin）/ Contributor（不含權限管理）/ Reader 是 built-in、通常太粗。production 環境需要 Custom Role 把 Microsoft.Storage/storageAccounts/listKeys/action 之類的高風險 action 收掉、只留 read。Custom Role 是 least privilege 在 Azure 的落實工具、不做就是用 Contributor 當預設、權限過寬。

Privileged Identity Management（PIM）：高權限角色（Global Admin、Subscription Owner、User Access Administrator）應走 just-in-time activation、需要 MFA 跟 approval、不該 permanent assignment。沒上 PIM 的組織通常會發現 standing Global Admin 超過 10 個、那是 phishing / token theft 的高價值靶。

Service principal vs Managed Identity：service principal 是 app 在 Entra ID 的代表、可以用 client secret 或 certificate 認證；Managed Identity 是 service principal 的特殊形式、由 Azure 自動管 credential。能用 Managed Identity 就不用 service principal client secret — 後者要自己 rotate、要存 secret management、容易 stale。

Azure Policy 是 RBAC 的補位：RBAC 管 principal 能不能對 resource 做這個 action、Azure Policy 管 允不允許這樣設定 resource（例如 storage account 強制加密、VM 只能用認可的 image）。RBAC 給 Contributor 的人可以建 storage account、但 Azure Policy 可以拒絕未加密的 storage account 建立 — 兩層互補、缺一不可。

核心取捨表

Azure 雙層體系的取捨要分開看 — 一張表回答 cloud resource permission 該選哪家（Azure RBAC vs AWS IAM vs Google IAM）、一張表回答 workforce IdP 該選哪家（Entra ID vs Okta）。兩個決策獨立、可以混搭（例如：Okta 當 workforce IdP + federate 到 Entra ID + 走 Azure RBAC 管 Azure resource）。

Azure RBAC vs AWS IAM vs Google Cloud IAM

Entra ID vs Okta（workforce IdP）

選 Entra ID 的核心訴求：M365 / Azure 重度使用、要跟 RBAC + Managed Identity 直接整合、能接受 Microsoft 控制面風險；選 Okta 的核心訴求看 Okta vendor 頁。

進階主題

Conditional Access 進階規則：除了 user / device / location 基本條件、進階場景包含 risk-based（Identity Protection 給的 user risk / sign-in risk）、token protection（token binding 到 device、防止 token replay）、authentication strength（強制 phishing-resistant factor）。production tenant 至少要有「Global Admin 必須走 phishing-resistant + compliant device」這條規則。

Privileged Identity Management（PIM）的設計細節：activation 要求 MFA、approval（高權限角色）、justification、時限（預設 8 小時、最長 24）。Access Review 是 PIM 的配套 — 季度檢視 standing assignment 是否還需要、不需要的撤掉。沒做 Access Review 的 PIM 等於只把問題從 standing 推到 誰申請就給 — 不是 least privilege。

Workload Identity Federation 跨雲：Entra ID 可以 trust GitHub Actions / GitLab / AWS / Google 的 OIDC issuer、讓 CI 直接拿 Azure token。同向也成立 — Azure workload 可以拿 Google ID token federate 進 GCP。多雲 CI 不該存任何 client secret、走 federation 比較安全。

Custom Role 設計實務：用 Microsoft.Authorization/roleDefinitions API 或 portal 定義、actions / notActions / dataActions 各自獨立 — actions 是 control plane、dataActions 是 data plane（讀寫 blob、key vault secret 內容）。常見錯誤是只收 actions 沒收 dataActions、結果 storage account 設定改不了但 blob 內容隨便讀。

Azure Policy 跟 Initiative：Policy 是單一規則、Initiative 是 policy 的集合（用來組 baseline、例如 CIS、ISO 27001）。Policy effect 有 audit / deny / deployIfNotExists、後者可以自動補洞（例如自動加 diagnostic setting）。RBAC + Policy 一起設計才是完整的 Authorization 邊界。

排錯與失敗快速判讀

• Global Admin 過多：standing Global Admin 超過 5 個就要警惕 — 上 PIM、把日常運維改用 Privileged Role Administrator + 特定 admin role group
• Conditional Access 規則漏 legacy auth：規則只 cover modern auth、IMAP / POP / SMTP 等 legacy protocol 不走 CA — 用「Block legacy authentication」baseline policy 補
• App Registration / Enterprise Application admin consent 沒審查：使用者自己 consent 把 mail.read 給三方 app、變 consent phishing 入口 — 關閉 user consent、改 admin consent workflow
• Service principal client secret 散落：CI / 服務裡有大量 client secret、rotate 沒節奏 — 改 Managed Identity（內部）或 Workload Identity Federation（跨雲 CI）
• Subscription Owner 太多：subscription 級 Owner 是高風險、應該收到 Management Group 級 Reader + 必要時 PIM activate Owner
• Azure Activity Log 沒進 SIEM：role assignment 變更、Key Vault access policy 變更只在 Azure portal 看得到、沒 alert — 用 Diagnostic Setting 推 Event Hub / Log Analytics、再進 SIEM
• Break-glass 帳號 exclude 自所有 CA policy、但沒監控：emergency access 帳號不能被 CA 鎖、但 任何登入都該 alert — 配對 Sign-in Log alert + 季度驗證可用

何時改走其他服務

不在本頁內的主題

• Entra ID 完整 SAML / OIDC / SCIM 規格細節
• Azure RBAC built-in role 完整清單與 action 對照
• Conditional Access policy template 細節
• Azure Policy 內建 initiative 完整清單
• Microsoft 365 / Defender for Identity 等周邊產品

案例回寫

下一步路由

• 上游：7.2 身分與授權邊界、7.13 偵測覆蓋率與訊號治理
• 平行：AWS IAM、Google Cloud IAM、Okta
• 下游：7.6 秘密管理與機器憑證治理（Entra ID / Managed Identity 之後的 secret / key 層、Azure Key Vendor 個別 vendor 頁 S2 批次撰寫中）
• 跨模組：8 事故處理 vendor 清單（Entra ID / Azure 事件如何 routing 進 IR 流程）
• 官方：Microsoft Entra Documentation、Azure RBAC Documentation

本文是跨 vendor migration playbook、cross-link HashiCorp Vault 跟 AWS Secrets Manager。本文同時是 #128 self-aware limitation 第 1 點「6 維仍可能漏類（identity / consistency / residency 三軸候選）」的 identity 軸驗證。

「secret」不是「secret」：兩家對「secret」的定義不同

把 Vault → AWS Secrets Manager 當成「secret store 替換」是最常見的誤判 — 兩家的「secret」概念跨完全不同的 identity model：

核心差異不在「存 secret 的地方」、在「身份從哪來、怎麼 enforce、怎麼 audit」。 Migration 的真實工作量在 identity model 重設計、不是 secret 搬遷。

跑 6 維 diff dimension audit：

6 維 audit 抓不到「Identity model = High」這軸 — 用既有 6 維歸類、會走 Type C operational redesign + Application change 高維獨立段；但實際工作量分佈：

• Operational redesign（vault cluster 拆 / Lambda 配 / 監控換）：~25%
• Application change（SDK / retry / token 換 IAM credential）：~30%
• Identity model 重設計（每個 secret 對應的 principal / policy / 跨 service auth chain）：~45%

最大工作量塊在 identity model 重設計、不在既有 6 維任一個。Identity 是 候選的第 7 維。

Identity axis 是否獨立：4 個論據

Yes、identity 是獨立軸：

1. Identity 不變 → operational 仍可變：Vault on-prem → Vault on-EKS、operational 變 high 但 identity model 不變（仍 Vault token）；可分開 audit
2. Operational 不變 → identity 仍可變：Vault namespace 重組（管理 50 個 namespace → 5 個 namespace + namespace-level policy）、operational 不變但 identity boundary 重劃；可分開 audit
3. Application change 不變 → identity 仍可變：純 infrastructure-level rotation（手動 → 自動）、application code 不變但 identity issuance flow 變；可分開 audit
4. Paradigm 不變 → identity 仍可變：同樣是 secret store paradigm、Vault token vs IAM principal 是 identity model 差、不是 paradigm 差

No、identity 可塞 application change：

• 反論：application code 改 SDK + IAM signer 都算 application change
• 拒絕：application change 是 consequence、不是 root cause；identity model 變動才是驅動 application change 的原因

實證上、本文 migration 工作量 45% 在 identity 對位、確認 identity 是 獨立的工作量主軸、不該被壓進 application change 軸。

結構：Type C + identity model 對位獨立段

跟既有 Type C PostgreSQL → Aurora 對照、本文多出 identity model 對位 獨立段：

11. 「secret」不是「secret」（identity axis paradox 開頭）
22. Identity axis 是否獨立的論據
33. 結構 differentiator（Type C + identity 獨立段）
44. Identity model 對位（Vault → AWS principal mapping）
55. Operational migration（4 phase）
66. Application change（SDK + retry pattern）
77. Production 故障演練
88. Capacity / cost
99. 整合 / 下一步

9 章節、260-280 行。比標準 Type C 多 1 段（identity model 對位）+ 1 段（axis 獨立論據）。

Identity model 對位

 1Vault concept                    →  AWS Secrets Manager 對應
 2─────────────────────────────────   ────────────────────────────
 3Vault token (auth 結果)           →  AWS STS temporary credential
 4AppRole (auth method)             →  IAM role + AssumeRoleWithWebIdentity
 5Kubernetes auth method            →  IAM Role for Service Account (IRSA)
 6LDAP auth method                  →  IAM Identity Center (formerly SSO)
 7Vault policy (capabilities)       →  IAM policy + Resource policy
 8Path-level ACL (secret/db/*)      →  Resource ARN pattern (arn:aws:secretsmanager:...:secret:db/*)
 9Namespace                         →  AWS account + resource-based isolation
10Audit device                      →  CloudTrail event
11Database secrets engine           →  Lambda rotation function

每行對位都有 語意差、不是 1:1 mapping：

• Vault token TTL vs AWS STS credential expiration：Vault token TTL 可由 application 主動 renew；STS credential 不能 renew、必須 re-assume
• Vault policy capabilities vs IAM action：Vault read capability 對應 AWS secretsmanager:GetSecretValue、但 AWS 還要 resource policy 允許；雙層授權
• Vault Kubernetes auth vs IRSA：兩者都是 K8s service account → secret access、但 IRSA 需要 EKS + OIDC provider 設置、Vault K8s auth 不需要

Migration scope 包含每行對位的 application-level 適配、不是 secret 搬。

Operational migration (4 phase)

Phase 0：Audit + design

• 列所有 Vault secret + path + 使用 application
• 每個 secret 對應 AWS principal（IAM role / IRSA / federation）
• 設計 ARN 命名規則（按 namespace / application / environment）
• 規劃 AWS account boundary（dev / staging / prod 分 account）

Phase 1：AWS Secrets Manager + IAM 設置

• Terraform / CloudFormation 建 secret + IAM role + resource policy
• 設 IRSA / WebIdentity provider
• 預先建 staging secret、跑 application test

Phase 2：Application dual-read

1# Application 同時讀 Vault + AWS Secrets Manager
2def get_db_password():
3    aws_value = boto3.client('secretsmanager').get_secret_value(SecretId='myapp/db')['SecretString']
4    vault_value = vault_client.read('secret/data/myapp/db')['data']['data']['password']
5
6    if aws_value != vault_value:
7        logger.warning(f"Secret diff between Vault and AWS!")
8
9    return aws_value  # Use AWS as source of truth

跑 1-2 週、確認兩端一致 + AWS API latency / error rate 接受。

Phase 3：Cutover + cleanup

• Application 端切到 AWS Secrets Manager only
• Vault read-only 1-2 週 standby
• 之後 decommission Vault cluster

Application change

Application 端必改的 4 個 pattern：

1# Before: Vault SDK
2import hvac
3vault_client = hvac.Client(url='https://vault.internal', token=vault_token)
4secret = vault_client.read('secret/data/myapp/db')['data']['data']['password']
5
6# After: AWS SDK + IAM
7import boto3
8sm = boto3.client('secretsmanager')
9secret = sm.get_secret_value(SecretId='myapp/db')['SecretString']

關鍵差異點：

• Authentication：Vault token 由 application 自管 / refresh；AWS SDK 自動處理 STS credential（透過 IAM role / instance profile / IRSA）
• Caching：Vault secret read 通常 cache 5-15 分鐘；AWS Secrets Manager 有 cache library（aws-secretsmanager-caching-python）需顯式啟用
• Retry pattern：Vault 用 exponential backoff；AWS SDK 自帶 retry but boto3 default 跟 application requirement 不一定 match
• Rotation hook：Vault 用 SDK 端 lease renewal；AWS 用 Lambda rotation function、application 端只需要 re-read

Production 故障演練

Case 1：IAM principal 對位錯、production application 拿不到 secret

徵兆：cutover 後 application 啟動失敗、log 顯示 AccessDeniedException: User: arn:aws:sts::...:assumed-role/EKS-NodeRole/i-xxx is not authorized to perform: secretsmanager:GetSecretValue。

根因：EKS pod 用 node role 而非 pod IRSA role；Phase 0 audit 沒設 service account 對應的 OIDC trust。

修法：

1. 預先設 IRSA：建 IAM OIDC provider for EKS、設 service account annotation
2. 驗證 principal：aws sts get-caller-identity 從 pod 內跑、確認 returned role 是預期的
3. Resource policy + IAM policy 雙層：確認 secret 的 resource policy allow 該 role、IAM policy 也 allow

Case 2：Dynamic credential 對等失敗、application 連 DB 失敗

徵兆：Vault 端用 database secrets engine 自動 rotate DB password、application 透過 Vault SDK 拿 lease；切到 AWS Secrets Manager + Lambda rotation 後、Lambda rotation 完成、但 application 端仍用 cached old password、連 DB 拒絕。

根因：Vault SDK 自帶 lease renewal logic、application 知道 password 即將過期會主動 re-read；AWS SDK 沒 lease 概念、application 自己決定多久 re-read 一次。

修法：

1. 設 cache TTL 短於 rotation interval：rotation 24 小時、cache TTL 1 小時、最壞情況 1 小時 stale
2. 顯式 cache invalidation：rotation Lambda 跑完發 SNS、application subscribe 主動 refresh
3. Connection-level retry：DB connection 認證失敗時 application 重 fetch secret 跟重連
4. 重新評估 rotation cadence：AWS Lambda rotation 不是 Vault dynamic、是 scheduled rotation；不能假設兩者同 semantic

Case 3：Audit log 結構差、SOC dashboard 失效

徵兆：cutover 後 SOC 端 dashboard 顯示 secret access metric 全 0；舊 Vault audit log 結構在 Splunk 端 parse 過、AWS CloudTrail 結構完全不同、search query 全失效。

根因：Vault audit log 是 Vault-specific JSON 結構（含 lease_id / policy / token）；CloudTrail event 是 AWS-specific（含 eventName / requestParameters / userIdentity）；SOC parse rule 不能搬。

修法：

1. Pre-cutover 重寫 SOC rule：CloudTrail event 對應 Vault audit log 的 detection coverage 必須 1:1 mapping
2. GuardDuty integration：AWS GuardDuty 自動 surface secret access anomaly、降低自寫 rule 工作量
3. CloudTrail → S3 → Athena：long-term audit query 走 Athena、tooling 跟 Vault 完全不同、SOC re-training

Case 4：Calling cost 反轉、AWS 比 Vault 自管貴

徵兆：Vault on-prem 跑了 $200 / month（EC2 + ops），切到 AWS Secrets Manager 後 $1500 / month；帳單拆解後 GetSecretValue API call 是大頭。

根因：AWS Secrets Manager $0.05 per 10K API call — application 高頻 read（每 request 都讀 secret + 沒 cache）會爆 cost；Vault 端 application 自管 cache + token TTL 內無 API call。

修法：

1. 強制 application-side cache：用 aws-secretsmanager-caching library、cache TTL 5-15 分鐘、API call 從 100M/month 降到 10K/month
2. Re-architect application：把 high-frequency secret read 改 connection-level（建 DB connection 時讀一次、connection lifecycle 內復用）
3. Cost monitoring：對 secret access 設 CloudWatch alarm、過 threshold 立即 alert

Case 5：跨 region replication 對位失敗、DR 演練失效

徵兆：DR drill 切 region 後、application 連不到 secret；發現 us-west-2 的 Secrets Manager 沒有 us-east-1 的 secret。

根因：AWS Secrets Manager 不是 global resource、是 region-scoped；Vault 自管 multi-DC replication；cutover 漏設 cross-region replication。

修法：

1. 設 secret replication：AWS Secrets Manager 內建 replication 到其他 region（ReplicaRegions）
2. DR drill 必跑：cutover 前 + cutover 後各 drill 一次、驗證 region failover 順
3. 架構：考慮用 AWS Backup 對 Secrets Manager 做 cross-region backup 補強

Capacity / cost

判讀：少 secret + 中頻 read 走 AWS Secrets Manager；高頻 read + multi-cloud / on-prem 約束走 Vault。

整合 / 下一步

跟 Vault Dynamic Credential 對比

Vault dynamic credential 是 Vault 特有 feature、AWS Secrets Manager 用 Lambda rotation 對應、但 semantic 不同：

• Vault: per-application lease、application-aware lifecycle
• AWS: scheduled rotation、application 不知道何時被 rotate

Migration scope 應該 降級 dynamic credential 場景、用 Lambda rotation 替代、application logic 改 cache + retry pattern。

跟 IAM Identity Center 整合

人類存取 secret（emergency break-glass）走 IAM Identity Center + temporary role assumption；不要直接給 user IAM key。

下一步議題

• Reverse migration（AWS → Vault）：通常是 multi-cloud / on-prem 約束驅動、cost 在大 scale 反轉
• Hybrid pattern：cloud-native secret 走 AWS、cross-cloud / on-prem secret 走 Vault；應用程式根據 secret 來源 routing
• identity axis 驗證：本文認為 identity 是獨立軸、未來累積 LDAP → OIDC / 自管 RBAC → IAM 等 migration 驗證

相關連結

• Source vendor：HashiCorp Vault
• Target vendor：AWS Secrets Manager
• 平行 deep article：Vault Dynamic Credential
• 平行 migration playbook (Type C)：PostgreSQL → Aurora（標準 Type C） / MongoDB → Atlas
• 平行 axis 候選驗證 (sibling)：DynamoDB Consistency Model（consistency 候選） / PostgreSQL Multi-Region GDPR Rollout（residency 候選）
• Methodology：Migration playbook methodology / #128 self-aware limitation 第 1 點（identity axis 候選驗證、本文是該驗證的 dogfood）

來源

Defender Pressure

Control Gap

控制缺口的核心是支援流程承載了身份敏感材料。當 HAR 檔或支援附件可能包含 session token，支援系統就不只是客服工具，而是身份供應鏈的一部分。

Detection Route

Exercise Hook

本案例可支撐 Identity support token tabletop。演練重點是確認支援附件進入系統後，團隊是否能快速定位 token、撤銷 session、通知 owner 並回寫支援流程。

Write-back Target

• 7.2 身分與授權邊界
• 7.B6 Incident Triage Loop
• Control owner pattern
• Evidence chain pattern

Scenario Trigger

支援系統出現大量附件下載，同一時間有客戶回報管理員 session 異常。SOC 在 identity provider log 中看到高權限 session 從不常見位置延續使用。

Initial Hypothesis

Control Surface

控制面包含 support workflow、session management、token revocation、customer communication 與 ownership。

Response Route

1. Triage：確認支援附件是否含敏感 session 資料。
2. Severity：依受影響 tenant、權限等級與 token 可用性分級。
3. Owner：identity owner 主責，support owner 與 incident commander 協作。
4. Containment：撤銷 session、鎖定附件下載、通知受影響客戶。
5. Write-back：更新支援附件處理、HAR sanitizer、customer notification 與 runbook。

Evidence Target

Write-back Target

• 7.2 身分與授權邊界
• 7.B6 Incident Triage Loop
• Control owner pattern
• Exercise write-back pattern