人走了三個月，
他的那套工具還在續費
為什麼現在很紅：SSO 管的是大門能不能進，不管應用裡的付費席位；應用如果還允許 email 密碼登入，停用身分帳號也關不掉那扇側門。
- 一句話結論
- 停用身分帳號只是關掉大門；應用裡的帳號、付費席位、email 密碼登入或 API token 不一定跟著消失。
- 他要的是什麼
- 他不用管 SSO 有多嚴。只要應用還收 email 加密碼，一組離職者用過的舊密碼就還能開門。
- 你今天做一件事
- 今天就拿近半年的離職名單，到付費最多的幾套應用後台搜一次，看還有誰的帳號是啟用的。 直接去做 →
- 哪些能信
- 1 可證明3 推論1 缺口 每個主張都標了等級，缺口是誠實寫出來的。
- 破口速查
- 受害端一律去識別化；寫「未公開」代表公開資料查不到。
- 伺服器服務商
- 不適用（示意情境；涉及的是各家 SaaS 應用，不是自家主機）
- 網路服務商
- 不適用（同上）
- 漏洞出現的地方
- 離職流程：檢查表只寫「停用 SSO」一行。應用內的帳號、付費席位、SSO 以外的登入方式（email 密碼、行動 App 長期登入、個人 API token）都沒有對應的收回步驟，資料移交也沒人負責
- 馬上自我檢測
拿最近半年的離職名單，到各付費應用後台搜尋是否還有啟用中的帳號 在各應用後台查看付費席位數，與在職且需要的人數比對 逐一確認每套應用的登入設定是否允許 SSO 以外的方式（email 密碼、API token）- 漏洞修補方式
- 把離職檢查表展開成每個應用一行，寫明停用帳號、釋出席位、資料移交給誰；標出允許 SSO 以外入口的應用，離職當天另外撤銷 API token 與行動裝置登入；每季做一次席位對帳；每項停用記下執行人與日期
有 15 分鐘再看：其餘 2 點
- 結果是錢照付、帳號還在，離職者名下的資料沒移交，被問起「他離職後還能不能存取」時也拿不出證據。
- 不用先買工具：把離職檢查表展開到每個應用、標出 SSO 以外的入口、回頭清一次舊帳、每季席位對帳、每一步留紀錄。
離職那天 IT 停用了身分帳號，SSO 登不進去，大家以為事情結束了。一季後財務發現，某套設計工具的付費席位還掛在他名下，帳號也還是啟用。「從 SSO 拿掉」跟「把帳號和授權收掉」是兩件事，這篇講怎麼把離職檢查表展開到每一個應用。
本篇目錄
停用了 SSO，席位卻多了一個
假設有一家四十人的設計接案公司，大部分雲端工具都走 SSO。設計師 B 離職那天，IT 照流程停用了他的身分帳號，SSO 登不進去了，大家都以為事情結束了。一季後財務對帳，發現某套設計工具的付費席位比在職設計師多一個。進後台一看，B 的帳號還是「啟用」，付費授權也還綁在他身上；而且這套工具除了 SSO，也允許用 email 加密碼登入。
先說清楚，這是示意情境，不是真實事件，公司與人物都是為了說明而設。可是這個形狀很常見：離職檢查表上只有一行「停用 SSO」，應用自己的帳號、席位和其他登入方式，沒有任何一行管到。
這篇要講的只有一件事：「從 SSO 拿掉」跟「把帳號和授權收掉」，是兩件事。
SSO 管不到的四件事
表面上看是多付了一個席位的錢。SSO 管的是「能不能從大門進來」，不管應用裡的付費席位；身分帳號停了，席位不會自己釋出。
往下一層是入口。應用如果允許 email 密碼登入、行動 App 長期登入，或使用者自己產生的 API token，切掉 SSO 不一定能關掉所有入口。帳號還在，就還有可能被用。
再往下是資料。離職者名下的檔案沒移交，等到真的刪帳號時，可能連資料一起刪掉；所以帳號不能一停了之，也不能永遠不停。
最後是舉證。被問「他離職後還能不能存取」，手上只有一張不確定有沒有做完的檢查表。
這個示意情境裡，還開著哪些門
這是示意情境，沒有實際外洩；下表列的是 SSO 停用後最常殘留在應用裡的存取權，讓你知道離職檢查表少的那幾行是什麼。
| 服務 | 憑證類型 | 用途 | 存在形式 | 放在哪 | 權限範圍 | 狀態 |
|---|---|---|---|---|---|---|
| 設計工具的應用內帳號（允許 email 密碼登入） | 帳號密碼 | SSO 以外的備用登入方式 | 存在應用端；密碼只有離職者知道 | 應用後台使用者清單，狀態仍為啟用 | 該帳號名下的檔案與專案 | 示意情境；身分帳號停用後仍為啟用 |
| 同一應用的個人 API token／行動 App 登入狀態 | API token、長期登入工作階段 | 外掛、自動化或手機上的日常使用 | 存在應用端與離職者的裝置上 | 應用的帳號設定或安全性頁面 | 依 token 或工作階段權限 | 示意情境；有沒有產生過、是否還有效，未查 |
這兩列都不會因為身分平台按下「停用」就消失，要到應用裡一個一個收。
能證明的、只能推論的
這篇是觀點文，情境是虛構的示意，情境裡的任何紀錄都不能當證據；能證明的只有 sources 裡官方文件可以核對的功能，情境中的狀態一律算推論。
不花錢就能做的流程
到這裡，其實已經足夠理解問題在哪。如果你關心的是怎麼把流程補起來，下面是五個步驟；想直接動手，可以跳到「今天就可以來試試」。
第一步，把離職檢查表展開到「每一個應用」。 不要只寫一行「停用 SSO」。每個付費應用都寫明三件事：怎麼停用帳號、怎麼釋出席位、資料移交給誰。
第二步，標出「SSO 以外的入口」。 逐一確認每套工具是否允許 email 密碼登入、行動 App 長期登入，或使用個人 API token。有的話，離職當天要另外處理。
第三步，回頭清一次舊帳。 拿最近半年的離職名單，到各應用後台搜尋，看還有沒有啟用中的帳號或被占用的席位。
第四步，席位對帳。 每季比對一次「付費席位數」和「在職且需要的人數」，多出來的就查是誰。
第五步，留下紀錄。 每一項停用都記下執行人、日期，必要時附上截圖，統一放進一個叫 offboard-proof-d8k 的資料夾。稽核問起時，這就是證據。
什麼時候不需要買工具
應用在二三十套以內、每年離職人數不多的話，展開後的檢查表加上每季席位對帳就夠了。真正的瓶頸通常不是工具，而是「離職當天有沒有人照表做完」。
真的要看工具，大致分四類。身分平台的自動配置：支援 SCIM 的應用，可以在身分平台停用帳號時自動停用應用帳號；但不支援 SCIM、或要付費升級才有 SCIM 的應用，就不在範圍內。身分治理功能：Microsoft Entra 的存取審查可以定期檢查群組成員和應用存取，授權需求如上。商用 SaaS 管理平台：例如 1Password SaaS Manager（官網說可以自動化離職流程和回收授權，API 不能用時改派任務給應用擁有者）、Torii（官網列出入離職自動化和授權回收）。開源：Snipe-IT 可以記錄授權的席位分配，但停用動作仍要人工處理。
限制也要一起看：自動化只對有 API 或 SCIM 串接的應用有效，其餘仍要人工；串接 HR 系統的前提，是 HR 資料本身要即時正確。選的時候問三件事：應用數量和離職頻率（數量少、頻率低用檢查表，多而頻繁再談自動化）、有沒有 HRIS 或 IdP 可以當可靠的「離職事件」來源、SCIM 覆蓋率（先算一算，有多少應用其實已經支援）。
這篇提到的項目要花多少錢
原文沒有給出席位單價或工具牌價，表裡的金額照實標成估算或未公開。
| 項目 | 用量 | 單價 | 期間 | US$ | NT$ | 舉證 |
|---|---|---|---|---|---|---|
| 展開離職檢查表（每個應用一行） 估 | IT 一人 | 估 半天 | 一次性 | — | — | 本站依五步流程估算 |
| 回頭清半年舊帳 估 | IT 一人 | 估 每個應用 10–15 分鐘 | 一次性 | — | — | 本站估算 |
| 殘留席位的多付費用 | 示意情境：一個席位、一季 | 依該應用席位單價 | 離職後持續 | — | — | 示意情境，要回頭對帳單才算得出 |
| Entra 存取審查 | 需 Entra ID Governance 或 Entra Suite（部分功能 P2） | 本文未查價 | 依授權 | — | — | 官方文件註明授權需求，價格未列 |
| Snipe-IT 自架版 | 開源 | 軟體免費，主機與維護另計 | — | 0.00 | 0 | Snipe-IT 官網 |
| 合計（僅可證明列） | 0.00 | 0 | ||||
席位的錢算得出來；算不出來的，是離職者那扇沒關的側門被用過幾次。
你可以學到什麼
站在攻擊者那一側看，離職者的應用帳號是很好的目標：帳號還啟用、密碼可能在別處外洩過、沒人在看它的登入紀錄。SSO 那道門再嚴，只要應用還收 email 密碼，他就可以從旁邊走進去，而公司以為「已經停用了」。
- 01停用身分帳號只關掉 SSO 這道大門，應用內的帳號、付費席位和其他登入方式要另外收。
- 02離職檢查表要展開到每一個應用，每一行寫明怎麼停用帳號、怎麼釋出席位、資料移交給誰。
- 03允許 email 密碼、行動 App 長期登入或個人 API token 的應用，離職當天要另外撤銷。
- 04每季比對付費席位數和在職需要的人數，多出來的那一個就是要查的人。
- 05每一項停用都記下執行人和日期，稽核問起時，這份紀錄就是證據。
- 01離職流程（Offboarding）這篇的主角：檢查表只有一行「停用 SSO」，就是殘留帳號的來源。
- 02SSO（單一登入）它管大門能不能進，不管應用裡的帳號和席位，邊界要先看清楚。
- 03SCIM身分平台停用時能自動停用應用帳號的協定；不支援的應用就要人工處理。
- 04付費席位（License Seat）席位不會隨身分帳號停用而釋出，每季對帳才看得到多付的那一個。
- 05API token使用者自己產生的 token 常常不受 SSO 控制，離職當天要另外撤銷。
- 06本機帳密登入（Local Login）應用允許 email 加密碼時，停用 SSO 就關不掉這扇側門。
- 07資料移交停用或刪帳號前沒移交，離職者名下的檔案可能跟著消失。
- 08存取審查（Access Review）定期確認誰還有權限的機制；Entra 版本需要額外授權。
- 09HRIS自動化離職要有可靠的離職事件來源，HR 資料不準，自動化也不準。
- 10稽核軌跡誰在什麼時候停用了什麼，有紀錄才能回答「他離職後還能不能存取」。
全部唯讀，不改任何設定；做完你會知道自己有沒有同樣的破口。
- 拿最近半年的離職名單，到付費最多的三套應用後台搜尋這些人（唯讀）看到什麼代表什麼：搜得到而且狀態是啟用的，就是殘留帳號；這篇的情境在你公司也存在。
- 在同幾套應用後台看付費席位數，和在職且需要的人數比一次（唯讀）看到什麼代表什麼：席位多於需要的人數，多出來的就要查是誰占著。
- 查看這幾套應用的登入設定，確認是否允許 SSO 以外的方式（唯讀）看到什麼代表什麼：允許 email 密碼或個人 API token 的，離職檢查表要多一行另外處理。
- 翻出現行的離職檢查表，數一數它列了幾個應用（不用指令）看到什麼代表什麼：只有一行「停用 SSO」，或應用數遠少於付費清單，就是這篇要補的缺口。
揭露：本文未受任何廠商贊助，提及的產品僅為舉例。
環境背景、時間線、攻擊鏈對照 ATT&CK、關鍵證據、根因、處置與檢討都在完整版，約 7 分鐘。
來源
本文為公開報導與官方公告的整理與拆解，非第一手鑑識；證據等級依來源可信度標註。
本文由 AI 團隊協助研究與撰寫，經隱私與事實檢查後發布；證據等級依來源可信度標註。
複製下面這段，貼給你在用的 AI 工具（Claude Code、Cursor、Copilot、ChatGPT 都可以）。它會用本篇的破口位置、自我檢測與學習重點，對你的專案或環境做一次資安掃描，列出潛在問題與建議的調整或加強方式。
預設是唯讀：只發現問題、提出建議，不會改你任何檔案或設定。
M2 身分與金鑰 · 想在自己的環境做一次同樣的盤點，從 自我盤點 開始。
每篇新文章一封：三點摘要、關鍵字定義、今天能做的一件事。或先 加入會員 記錄你完成的任務。