用戶存取權限撤銷流程圖（權限註銷）

甚麼是用戶存取權限撤銷流程圖（權限註銷）流程

用戶存取權限撤銷，又叫權限註銷或權限收回，就是把一個人已經不再需要的存取權限收回來，並且能夠證明它確實被收回了。它由一個觸發事件開始——可能是一次離職，一次職位變動，一份合約或一項委聘結束，也可能是一次權限覆核查出了誰也說不出理由的權限——一直走到一份紀錄，顯示每一個帳戶、每一項權限都經過處理。它對時間的敏感程度是大部分行政流程沒有的：風險窗口在觸發發生的那一刻打開，一直開着，直到最後一個工作階段被關閉。

這不是整條離職流程。工作交接、離職面談、資產交還與最後一期薪金屬於員工離職流程，那是一項由人力資源部負責、範圍更闊的協調工作。本流程是當中權限的那一半，而且它也會為根本沒有要走的人跑起來——所以那條泳道按觸發來源命名，而不是按一次離職命名。它也不是授權的那一側：權限如何申請、如何說明理由、如何審批、如何開通，是存取申請流程的事。撤銷由這兩者停下來的地方開始，一條流程覆蓋全部四種觸發，而不是只為離職寫得妥當、對其他情況臨時湊合。

範本把流程鋪在五條泳道上——觸發來源（人力資源部或經理）、IT 服務台、系統負責人、保安與審核——橫跨由觸發到證據與收結的六個階段。它包含決定撤銷是即時執行還是在生效日執行的那條分支，共用帳戶、服務帳戶與特權帳戶這類不能一關了事的情況的處理，停用還是刪除的判斷，以及最後一步核對：把實際撤銷掉的，與開頭整理出的那份清單對上。它的形狀依循 ISO/IEC 27001:2022 附錄 A 控制項 A.5.18 所描述的存取生命週期中撤銷的那一半——該控制項要求在僱傭關係或合作關係終止或變更時，移除或調整存取權限。

本流程圖涵蓋的內容

本範本包含

• 四個入口，一條流程：觸發來源泳道中的「觸發類型？」判斷，把離職或合約期滿、職位變動、權限覆核發現送上同一條撤銷路徑，因此甚麼都不取決於這張工單是否碰巧由人力資源部開出。
• IT 服務台泳道中的「是否需要即時撤銷？」判斷：即時分支針對解僱與特權帳戶，在一小時之內切斷全部存取權限；計劃分支把撤銷安排在生效日。兩條分支在同一個梳理步驟重新匯合。
• 一個獨立的梳理步驟，在關掉任何東西之前先整理出完整的帳戶與權限清單，節點備註裡點名了大家最常遺漏的來源：本機帳戶、服務帳戶與共用帳戶、VPN 與遙距存取、雲端與資料庫主控台、用信用卡買下的第三方 SaaS，以及樓宇門禁。
• 由系統負責人負責的「是否共用或特權帳戶？」判斷，把共用帳戶、服務帳戶與特權帳戶轉交保安去輪換憑證與金鑰——因為這類帳戶一旦被停用，就會弄壞依賴它們的東西。
• 撤銷那一欄中的「停用還是刪除帳戶？」判斷，兩條分支都在系統負責人於各目標系統中撤銷權限處重新匯合。
• 資料與授權按避免檔案失去擁有權的次序處理：先移交郵箱與檔案擁有權，再回收授權並更新清單，然後由保安保存撤銷證據，最後由審核泳道的「是否仍有存取權限有效？」核對，把發現的缺口退回梳理步驟，之後才簽署收結。

何時使用本範本

• 你們正在編寫或覆核一份權限註銷程序，需要把權限相關的步驟從更闊的離職清單中單獨抽出來，並為每一步指定一位負責人。
• 權限覆核一次又一次翻出已離職、已轉團隊或合約已結束的人仍然有效的帳戶，你們需要說明撤銷發生在流程的哪個位置、由誰確認。
• 你們正在身分平台或服務台工具中設定入職、調職、離職的自動化，希望流程在被寫成工作流程規則之前先議定下來。
• 你們的環境裡外判與第三方人員很多，主要觸發是合約完結日而不是人力資源系統的資料推送，根本沒有離職紀錄可以依據。
• 你們要回答審核員或客戶保安問卷中的問題：僱傭關係終止時存取權限是如何撤銷的，有甚麼證據顯示它確實發生過。

運作方式

1. 寫清你們真實的觸發來源

   圖裡有四種觸發：離職、合約期滿、職位變動與權限覆核發現。寫下每一種的權威來源是哪個系統或哪個人，例如員工看人力資源系統，供應商與外判人員看合約登記冊，覆核發現看覆核結果。如果今天某一種觸發沒有負責人，那就是最值得先補上的缺口——沒有人會去啟動的流程，是無法量度的。

2. 把即時撤銷的規則寫下來

   「是否需要即時撤銷？」這個判斷，只有當判定準則就擺在旁邊時才有用。常見的觸發是解僱、懷疑違規，以及任何持有管理員、生產環境或付款審批權限的人。加上你們自己的目標時限，並寫明非辦公時間由誰可以發動。遇上解僱時，撤銷通常與談話本身對時，所以這條分支講的既是速度，也是次序。

3. 把你們的系統清單掛到梳理步驟上

   把通用的帳戶清單換成你們真正在維護的那份清單，並標出哪些系統在單一登入後面、哪些不在。身分平台以外的一切，正是被遺漏的權限藏身之處：本機管理員帳戶、資料庫登入、SSH 金鑰、API 權杖，以及某個團隊用信用卡買下的工具。請離職者的經理把 IT 並不管理的東西一件件說出來。

4. 在需要用到之前就定好停用還是刪除

   把停用設為預設，並界定甚麼情況下容許刪除，例如過了訂明的保存期，或者合約期滿而協議有此要求。記下這個決定由誰來做。刪得太早，會毀掉郵件資料、檔案擁有權，以及核對步驟和日後任何調查所依賴的操作紀錄。

5. 保持資料與授權步驟的次序

   先移交郵箱與檔案擁有權，再回收授權。兩者一旦調轉，共用檔案與郵箱就會變成無主狀態，事後再找回來很慢。如果設定了郵件轉寄或代理人，就在同一步裡為它指定一位具名負責人和一個結束日期，否則這個臨時安排會靜靜變成永久的。

6. 議定甚麼算是證據，以及由誰核對

   訂明一條撤銷紀錄必須包含甚麼——通常是系統、動作、時間戳記和執行人——以及它存放在哪裡。然後指定誰來跑「是否仍有存取權限有效？」這項檢查，以及對着甚麼核對：只有對着開頭那份帳戶清單核對、而不是對着記憶核對，才捉得住遺漏。把批核過的圖與你們的存取控制政策一併發布，讓大家實際遵循的流程，和你們拿給審核員看的流程，是同一條。

常見問題

甚麼是用戶存取權限撤銷流程？

它是把一個人的存取權限收回來所走的那條已界定路徑，由觸發一直到經過確認並留有證據的收結。一條完整的流程有五個部分：一個有具名來源的觸發；一個關於權限必須多快消失的判斷；對這個人持有的每一個帳戶與每一項權限的梳理；在每個系統中的撤銷，而且資料與授權的後果都已處理；以及一次核對，顯示沒有任何東西被留着仍然有效。觸發比大部分團隊以為的要闊。除了離職，流程還應該在職位或團隊變動時、在合約或委聘結束時、在任何一次權限覆核發現時跑起來——正是這些路徑，製造出事後誰也解釋不了的權限。

有人離職時，存取權限應該多快被撤銷？

標準訂明的是要求，不是鐘點。ISO/IEC 27001:2022 控制項 A.5.18 要求在僱傭關係終止或變更時移除或調整存取權限，但沒有訂明時限，因此目標由你們自己設定並說明理由。常見的做法是：有計劃的離職在最後工作天結束時撤銷；解僱或任何持有特權權限的人則即時撤銷，並與談話對時。無論你們選哪一種，都把它寫進流程，量度由觸發到最後一次撤銷的實際時間，並把這兩者之間的差距當作值得上報的那個數字。

我們應該停用還是刪除帳戶？

停用是較安全的預設，也是大部分機構首先會做的。它關閉帳戶、結束活躍工作階段、阻止登入，同時保留郵箱內容、檔案擁有權、群組成員身分，以及一次調查或日後一次權限覆核可能需要的操作紀錄。刪除屬於訂明保存期結束時，或者合約期滿而協議或資料保障承諾有此要求時。無論選哪一種，結束活躍工作階段與撤銷權杖的重要性都不亞於帳戶狀態本身：一個已停用但仍帶着活躍工作階段或有效更新權杖的帳戶，在那個工作階段屆滿之前仍然擁有存取權限。

共用帳戶、服務帳戶與特權帳戶的權限應該怎樣撤銷？

共用帳戶或服務帳戶無法靠停用來註銷，因為其他人和其他系統都依賴它。撤銷的動作是輪換憑證：改掉密碼或金鑰，把這個人從保管它的密碼庫或群組中移除，撤銷他建立的 API 權杖、SSH 金鑰與個人存取權杖，並結束所有活躍工作階段。特權個人帳戶在一般停用之外，還需要同樣的工作階段與權杖處理。範本把這一情況放在由保安負責的獨立分支上，因為它是最常被遺漏的一種，而一旦被遺漏，波及面也最闊。

這條流程應該產出甚麼證據？

最少是每次撤銷一張工單或一條紀錄，顯示觸發及其日期、整理出的帳戶與權限清單、在每個系統中採取的動作及其時間戳記和執行人，以及核對檢查的結果。這份紀錄正是審核員抽查的對象，也正是讓你們能用一個日期而不是一段描述去回答保安問卷的東西。這裡有必要說清楚：流程圖做的是記錄預期的流程以及每一步歸誰負責，而合規的證據，是這條流程真正跑起來時產生的那些紀錄。