如何在台灣選擇 SSO 軟體：實務採購指南

在台灣導入 SSO 已不再是邊角型 IT 專案。中型企業環境動輒有數十個 SaaS，SSO 所封閉的離職權限缺口，往往是個資法事故審視「乾淨結案」與「通報事件」的分界。本指南整理台灣買家在第一日見效、又能撐到第三年的關鍵決策：專案範圍、身分來源、MFA 設計、生命週期自動化、廠商選擇、PoC 與預算。

本指南架構

• 專案定位：SSO 真正解決什麼
• 決定身分真實來源 (Source of Truth)
• 在選廠商前先設計 MFA
• 從 joiner 到 leaver 自動化生命週期
• 規劃 SAML/OIDC/SCIM 整合與長尾
• 個資法、金管會與資安框架早期對齊
• 貼近現實的 PoC 設計
• 三年 TCO 拆解
• 推行、治理與運維規劃
• 常見陷阱與規避方式

專案定位：SSO 真正解決什麼

選平台之前，明確寫下 SSO 要解決的三個問題。台灣中型買家的常見清單為：離職者 SaaS 權限滯留過久、各 app MFA 不一致、個資法審視時稽核紀錄零散。SSO 透過集中認證與身分決策同時處理這三項。若清單與現實不符，後續決策就會偏向錯誤方向。

其次是範圍。試圖在第一日把所有 SaaS 都納入 SSO 通常會爆案。可持續的做法是把 SaaS 分為必納、重要、選用三級。必納包含含個資、客戶資料或生產憑證的 app，必須在上線前接入；重要為 Slack、Confluence、Notion 等 90 日內納入；選用為行銷與長尾，後續再整合。此分級與個資法的風險基礎方法一致。

最後，指定高階贊助者與運營委員會。SSO 同時觸及 HR、IT、資安與財務。資安單獨領導的專案常缺 HRIS 整合資源；IT 單獨領導則易遺漏稽核義務。在 RFP 前成立由資安、IT、HR、資料保護負責人組成的指導委員會的台灣組織，最常如期交付。

決定身分真實來源 (Source of Truth)

每個 SSO 程式都依賴一個決定：「誰存在於組織」由哪個系統決定？台灣中型環境的候選者是 HRIS（Workday、BambooHR、104 HRD、銓鋐 HRplus、漢康 HR）、Microsoft 365 / Entra ID 與 Google Workspace 目錄。此選擇對整合成本、離職延遲與稽核完整性的影響最大。

HRIS-driven 設定最契合個資法級的離職控制。Workday 或 104 HRD 的離職事件可在數分鐘內驅動 SaaS 上的 deprovisioning，HRIS 即為稽核錨點。Okta 與 OneLogin 強化此模式；Entra ID 透過 Workday connector 或第三方 IGA 達成同效。代價是高度依賴 HR 資料潔淨度。

M365/Entra ID-driven 適合應用多在 Microsoft 生態、HRIS 在地或缺位的情境，運營單純但需要每日 sync 帶來離職延遲。對金管會檢查對象通常不足以滿足，需要更牢固的 HRIS 連接。Google Workspace-driven 在新創與數位原生 SMB 常見，與 JumpCloud、Okta 整合良好，但 Workspace 並非設計為真實目錄，外部人員管理較笨拙，員工超過 100 人後多改採 HRIS 或 Entra ID 模式。

在選廠商前先設計 MFA

MFA 設計是台灣團隊最容易投入不足的部分。把所有人都納入 TOTP 行動驗證並非結束。在金管會與政府資料相關情境下需要分層 — 特權帳號（管理員、財務核准、個資存取者）採 FIDO2 硬體金鑰或平台驗證器（Windows Hello、Touch ID），廣大員工以風險訊號驅動的推播 MFA，SMS 則應規劃明確退場時程。

自適應 MFA 依裝置健康、位置、風險評分動態決定是否挑戰，可降低混合工作（辦公室、家、客戶端）的摩擦。Entra ID 的 Identity Protection (P2)、Okta 的 Identity Threat Protection、JumpCloud 的 Conditional Policies 提供同等能力，請於詢價時確認 SKU 包含。最後，務必設計復原機制 — 備援代碼、緊急管理者流程、身分再確認三層；首事故後再做就太晚。

從 joiner 到 leaver 自動化生命週期

生命週期自動化決定 SSO 是「個資法保護承諾」還是「另一道登入牆」。三條流程必須自動化：joiner（建立、群組、應用佈建）、mover（職務、部門、地點變動）、leaver（全應用 deprovisioning、封存、稽核日誌）。每一條流程都應寫明延遲目標。

joiner 的台灣中型標準是 HRIS 事件後 30 分鐘內 tier-1 應用佈建、4 小時內 tier-2 完成。leaver 的標準更高，須在 30 分鐘內完成 SaaS 撤權並終止活躍 session（不只是阻斷下一次登入）；PoC 須實測這條完整鏈路。mover 流程需把職務或部門改變對應 RBAC，避免權限疊加殘留，這也是 ISO 27001 稽核中最常見的痛點。

規劃 SAML/OIDC/SCIM 整合與長尾

台灣中型 SSO 部署常落在 30–80 應用整合，5–15 個需客製。Salesforce、GitHub、Atlassian、Slack、Notion 等可由 OIN、Entra Gallery、JumpCloud 目錄直接接上；台灣本地 SaaS 與金融閘道常需要 5–15 人天/個 的客製 SAML/OIDC connector。SCIM 是生命週期實作的關鍵協定 — 簽約前應確認 Top 20 應用的 SCIM 支援，缺者以指令稿暫補。完整整合 backlog 通常需要 6–12 週並列作業，應寫入專案計畫而非作為長尾風險。

個資法、金管會與資安框架早期對齊

在 RFP 階段就帶入合規對齊的台灣專案進度最穩。個資法與 ISO 27001 都要求獨立識別、適當的存取控制、含個資系統的 MFA 與可追溯稽核。五大平台在正確 SKU 下皆可滿足，關鍵在於是否將 P2、Governance、Adaptive MFA 等選項納入。金融機構應依金管會電子銀行業務安全控管基準與作業委託他人處理規範要求強客戶認證、特權存取管理與端到端日誌；Ping 與 Okta 於台灣金融業參考案例豐富。公部門與電信需同時考量資通安全管理法、政府資料分級規定與資料位置承諾。

貼近現實的 PoC 設計

台灣中型 SSO 選型的標準 PoC 期為 4–6 週，包含三類整合（簡單 SaaS、客製、HRIS）、完整 leaver 流程、代表性 MFA 註冊、可由 DPO 檢視的稽核匯出。受測對象不應只有 10 人單部門 — 取 30–50 人、跨 2–3 部門，含至少一名特權者與一名外包人員，最好能在 PoC 中段插入跨部門調動情境以驗證 mover 流程。打分採五軸：整合廣度、離職延遲、管理 UX、稽核完整性、台灣支援回應時間，每軸 1–5 分由三位以上評估者打分後加總；總分通常比單看每用戶價格更能預測正確選擇。

三年 TCO 拆解

建議以四條成本線比較三年 TCO：平台（SKU 正規化）、導入、整合建置、運維。Okta 與 Ping 多由台灣系統整合商主導（一次性 NT$150–500 萬），Entra ID 與 JumpCloud 可內部導入（NT$50–150 萬）。整合建置以每個客製 5–15 人天估算，10 個客製即 50–150 人天。運維以專責身分工程師年薪 NT$120–180 萬或委外 run-as-a-service NT$80–150 萬計算。第一年最便宜的選項，三年合計常非最便宜。

推行、治理與運維規劃

推行採四階段：Foundation（HRIS 連接、核心目錄、管理員 MFA、兩個試點 app）、Wave 1（前 20 大 SaaS、完整生命週期、員工 MFA 註冊）、Wave 2（長尾 SaaS、外包人員流程、稽核設定）、Steady-state（運維交接、治理節奏、定期權限檢視）。每階段都應明確訂出 exit criteria。治理層面採三節奏：每季權限檢視、每年 entitlement 再認證、每月認證失敗與 MFA 註冊率與離職延遲檢視。運維有三種模型可選：內部 ID 工程師、夥伴管理、平日內部 + 夜間/週末夥伴 on-call 的混合。

深入了解各產品

常見陷阱與規避方式

① 在身分來源決定前選平台 — 兩週內先決定身分來源，否則整合會做兩次。② 缺 MFA 註冊預算 — 規劃六週註冊窗、主管升級、強制鎖定截止日，避免初期六週淪為服務台轟炸。③ 未實測離職延遲 — 對 Top 10 應用實測 HRIS→session 終止鏈路並記錄差距。④ 遺漏非員工 ID — 將外包、稽核員、外籍工程師寫入採購要求，避免 entitlement review 留洞。⑤ 僅看每用戶價格 — 建立含實際使用功能與運維線的三年正規化 TCO 試算表後再比較。