人走了三個月，他的那套工具還在續費

停用了 SSO，席位卻多了一個

假設有一家四十人的設計接案公司，大部分雲端工具都走 SSO。設計師 B 離職那天，IT 照流程停用了他的身分帳號，SSO 登不進去了，大家都以為事情結束了。一季後財務對帳，發現某套設計工具的付費席位比在職設計師多一個。進後台一看，B 的帳號還是「啟用」，付費授權也還綁在他身上；而且這套工具除了 SSO，也允許用 email 加密碼登入。

先說清楚，這是示意情境，不是真實事件，公司與人物都是為了說明而設。可是這個形狀很常見：離職檢查表上只有一行「停用 SSO」，應用自己的帳號、席位和其他登入方式，沒有任何一行管到。

這篇要講的只有一件事：「從 SSO 拿掉」跟「把帳號和授權收掉」，是兩件事。

SSO 管不到的四件事

表面上看是多付了一個席位的錢。SSO 管的是「能不能從大門進來」，不管應用裡的付費席位；身分帳號停了，席位不會自己釋出。

往下一層是入口。應用如果允許 email 密碼登入、行動 App 長期登入，或使用者自己產生的 API token，切掉 SSO 不一定能關掉所有入口。帳號還在，就還有可能被用。

再往下是資料。離職者名下的檔案沒移交，等到真的刪帳號時，可能連資料一起刪掉；所以帳號不能一停了之，也不能永遠不停。

最後是舉證。被問「他離職後還能不能存取」，手上只有一張不確定有沒有做完的檢查表。

這個示意情境裡，還開著哪些門

這是示意情境，沒有實際外洩；下表列的是 SSO 停用後最常殘留在應用裡的存取權，讓你知道離職檢查表少的那幾行是什麼。

這兩列都不會因為身分平台按下「停用」就消失，要到應用裡一個一個收。

能證明的、只能推論的

這篇是觀點文，情境是虛構的示意，情境裡的任何紀錄都不能當證據；能證明的只有 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 覆蓋率（先算一算，有多少應用其實已經支援）。

這篇提到的項目要花多少錢

原文沒有給出席位單價或工具牌價，表裡的金額照實標成估算或未公開。

席位的錢算得出來；算不出來的，是離職者那扇沒關的側門被用過幾次。

你可以學到什麼

站在攻擊者那一側看，離職者的應用帳號是很好的目標：帳號還啟用、密碼可能在別處外洩過、沒人在看它的登入紀錄。SSO 那道門再嚴，只要應用還收 email 密碼，他就可以從旁邊走進去，而公司以為「已經停用了」。

揭露：本文未受任何廠商贊助，提及的產品僅為舉例。