2026-06-05

帳號生命週期管理：加入、調整、離職的權限閉環

適用對象：組織管理者、顧問帶領情境

這篇要解決的問題是：新成員入職要開哪些帳號、調職時怎麼調整權限、離職後怎麼確保所有帳號都已關閉，以及如何設計一套可重複執行的流程，讓這件事不靠某個人記憶來維持。

問題情境

有人離職三個月後，你發現他的 Google 帳號還在群組裡，還在收組織的電子郵件。或者你發現他離職前把一些共用帳號的密碼帶走了。或者新進成員入職第一天，沒有人知道應該開哪些帳號，IT 窗口靠經驗和印象拼湊出一份清單。

這些問題有共同的根源：沒有標準化的帳號管理流程。帳號開了沒有記錄，調整了沒有文件，離職了沒有清單。管理靠人記，人記不住就出漏洞。

核心觀念

帳號生命週期的四個階段

帳號的完整生命週期包含：開立（入職）、調整（調職、兼任）、回收（離職、約滿）、稽核（定期確認帳號狀態符合現況）。

大多數組織只做了「開立」，其他三個階段沒有系統性的流程。「回收」和「稽核」是遺漏頻率最高的兩個環節，也是資安風險最集中的地方。

最小權限原則

每個帳號只給完成工作所需的最小權限。這個原則在帳號開立時就要執行，而不是等到「發現問題」才來縮減。職務調整時需要重新評估，離職時徹底撤銷。

最小權限不只是帳號本身的問題，也包含：哪些 Google 文件夾可以看、哪些 Slack 頻道可以加入、哪些雲端服務有存取權限。

人事流程和 IT 流程的銜接

帳號管理出問題，通常不是技術問題，而是人事部門和 IT 窗口之間沒有固定的溝通節點。人事知道誰入職、離職、調職，但不會自動通知 IT。IT 沒有收到通知，就不知道要處理帳號。這個缺口需要透過流程設計來填補，而不是靠個別人員的主動性。

最小可行做法

1. 建立帳號清單：列出組織使用的所有服務（例如：Google Workspace、Slack、Zoom、GitHub、密碼管理器、雲端儲存、財務系統），記錄每個服務的帳號管理方式（誰有管理員權限、怎麼新增或移除成員）。
2. 設計入職帳號開立清單：依角色列出入職時需要開立的帳號與預設權限。不同職位的清單可能不同（例如：技術人員需要開 GitHub，行政人員不需要）。清單應該可以直接交給 IT 窗口執行，不需要靠口頭說明。
3. 設計離職帳號回收清單：離職當天需要完成的帳號處理項目，包含：停用帳號、轉移資料擁有權、從共用群組移除、回收密碼管理器存取、確認共用帳號密碼是否需要更換。
4. 在人事流程中設置觸發點：入職、調職、離職的人事流程中，加入「通知 IT 窗口」的步驟，並設定完成期限（例如：離職前一天完成帳號回收清單）。
5. 定期進行帳號稽核：每季或每半年，對照現有成員名單與帳號清單，確認沒有已離職人員的帳號仍然存在，也確認現有成員的權限符合職務需求。
6. 記錄每次異動：帳號開立、調整、關閉都要有紀錄，記錄誰在什麼時候執行，以便事後查詢。

常見錯誤與風險邊界

• 只停用帳號，沒有轉移資料：帳號被停用後，帳號下的資料（例如：Google Drive 的檔案、Notion 的頁面）可能變得無法存取。離職前需要先將資料擁有權轉移給接手的人或組織管理者帳號。
• 忘記外部協作者：工讀生、顧問、外部廠商的帳號往往不在正式的人事系統裡，容易在合作結束後被遺忘。建議維護一份外部協作者帳號清單，設定合約結束日期作為提醒觸發點。
• 共用帳號密碼沒有更換：若離職成員曾經知道某個共用帳號的密碼（例如：社群媒體帳號），離職後即使停用他的個人帳號，他仍可以用那個密碼登入共用帳號。密碼管理器的共用保險箱機制可以減少這個問題，但仍需在離職後確認共用帳號密碼是否需要輪換。
• 把帳號稽核當一次性任務：帳號稽核需要定期執行。組織成員會異動，服務會新增，若不定期稽核，清單會隨時間失真，發現問題時往往已經累積了很多漏洞。
• 沒有人負責這個流程：帳號管理流程需要有明確的負責人（不一定是 IT 專業人員，但需要有人追蹤清單執行進度）。沒有負責人，清單就會成為擺設。

何時升級

• 你的組織規模增長到每月都有人員異動：手動維護清單的成本會隨規模增加。評估是否引入身分與存取管理（IAM）工具，或至少用試算表自動觸發提醒。
• 你希望帳號管理和 MFA 政策整合：帳號開立時同步確認 MFA 設定，帳號回收時同步撤銷 MFA 裝置，詳見本系列文章「組織 MFA 政策設計：人員差異與風險分級」。
• 你想系統性盤點組織現有帳號狀況：可從顧問知識庫的帳號盤點流程開始，先了解現況再設計改善方案。

參考文件

• 帳號盤點與稽核 — 組織資安指引
• 組織帳號的密碼管理 — 組織資安指引