存取申請與權限開通流程圖
存取申請流程圖：以角色為本的申請、直屬主管與系統負責人審批、職責分隔檢查、按最低權限開通，以及定期重新認證。
甚麼是存取申請與權限開通流程
存取申請流程，是讓員工取得工作所需的權限，同時又不會令機構失去對「誰可以做甚麼」的掌握。它由申請一個已界定的角色開始，而不是一份逐項列出權限的清單；經過對申請人負責的人和對系統負責的人的審批；最後落在一條記入登記冊、並附有下次覆核日期的權限紀錄上。
最常被略過的步驟，正正是日後變成審核發現的那些。職責分隔檢查可以阻止同一個人持有兩個本來不應放在一起的角色——例如建立供應商，又為這家供應商付款。獨立的保安檢視，令管理員權限和敏感資料權限不必與一份唯讀報表走同一條審批路徑。而重新認證是權限登記冊得以保持真實的唯一原因：沒有既定的覆核，每當有人轉組，權限就會累積一層，而且從來不會被收回。
本範本把由申請到重新認證的完整流程畫在五條泳道上：申請人、直屬主管、系統或資料負責人、IT 服務台和保安團隊。它包含各團隊爭論得最多的兩個分支點——當申請的角色與本人已有的權限出現衝突時會怎樣，以及哪些申請需要在開通前經過保安檢視。它以一次既定覆核作結，覆核要麼確認該權限繼續有效，要麼將其收回。整體結構依循 ISO/IEC 27001:2022 附錄 A 中關於存取控制（A.5.15）、身分管理（A.5.16）和存取權限（A.5.18）的控制項所訂下的模式。
本流程圖涵蓋的內容
本範本包含
- 申請人泳道中的申請：發起存取申請，再從存取目錄中選擇一個已界定的角色，寫明業務理由；權限如屬臨時性質，還要寫明結束日期。
- 在任何技術檢查之前的兩道審批關卡：直屬主管批准或拒絕，然後由系統或資料負責人審視該角色實際授予哪些權限，再批准或拒絕。兩條拒絕分支都匯入同一個節點「申請已拒絕並關閉」。
- IT 服務台泳道中的「是否存在職責分隔衝突？」決策，衝突分支會把申請退回系統負責人，由其調整權限範圍或加入一項補償性控制，然後重新檢查，而不是直接放行。
- 「是否屬於特權或敏感權限？」決策，把管理員權限和高風險申請轉往獨立的保安審批，一般申請則直接進入權限開通。
- 開通與紀錄：按最低權限原則開通，向申請人確認權限已生效，請申請人確認接受使用規範，並把該權限記入存取權限登記冊。
- 最後一欄的重新認證迴路：保安團隊啟動一次既定覆核，系統負責人判斷該權限是否仍有需要，「否」分支在目標系統中收回權限並更新登記冊。
何時使用本範本
- 你們要為 ISO 27001、SOC 2 或一次內部審核編寫或檢視存取控制程序，需要一份大家都認可的圖，講清楚誰審批甚麼、記錄甚麼。
- 你們要在服務台或身分管治工具中設定申請流程，讓工具落實一套事先議定的流程，而不是在推行過程中臨時創作一套。
- 你們要回答審核員或客戶保安問卷，說明權限如何申請、審批、開通與覆核。
- 你們要向新的審批人講解，尤其是直屬主管和系統負責人——他們需要知道自己簽的到底是甚麼，以及把申請擱置會有甚麼後果。
- 一次覆核翻出一批沒有人解釋得了、也對不上任何審批紀錄的權限，你們要着手處理權限累積的問題。
運作方式
寫下你們真實的審批人
把五條泳道改成你們實際擁有的角色。在規模較細的機構裡，系統負責人和保安檢視人往往是同一個人；把這兩條泳道合併，而不是畫一次根本不會發生的審批。每個決策者一條泳道，而不是每個人一條，這樣有人轉職時圖仍然用得上。
界定甚麼算特權或敏感權限
「是否屬於特權或敏感權限？」這個決策，只有把判定準則寫在它旁邊才有作用。常見的觸發條件包括管理員和 root 帳戶、服務帳戶、個人資料或財務資料的存取權限，以及任何可以改動生產環境的權限。門檻要訂在只有少數申請會觸發保安分支的位置，否則這一步就會淪為蓋章。
把職責分隔規則寫下來
列出任何一個人都不得同時持有的組合——例如建立供應商與批准付款，或撰寫程式碼與把程式碼發布到生產環境。沒有這份矩陣，衝突檢查只是做樣子。同時決定：當衝突無法避免時，由誰批准補償性控制，並把它記錄在這條權限上。
決定存取權限登記冊放在哪裡
把登記這一步指向你們真正會維護的系統——身分管治工具、你們的 ITSM 平台，或一份受控的試算表。要確保收回權限的分支會更新同一條紀錄，否則登記冊會慢慢變成一份「曾經批出過的權限」清單，而不是「現時實際存在的權限」清單。
訂下重新認證的周期和它的負責人
把籠統的「既定覆核」換成你們自己的頻率和觸發條件——例如特權帳戶每季一次、標準角色每年一次，另加職位變動時的額外覆核。寫明由誰催促覆核人，以及覆核限期過了會怎樣；沒有負責人的覆核，正是那種會悄悄停下來的步驟。
讓這張圖獲得批准，並只保留一個現行版本
把圖分享給圖中列名的審批人，取得他們的批准紀錄，並從你們的存取控制政策連結到已批准的版本。當圖表處於版本控制之下、而且附有已記錄的批准時，大家實際遵循的流程，和你們拿給審核員看的流程，就是同一個。
常見問題
甚麼是存取申請流程？
它是一條已界定的路徑：一項系統權限申請，由有人提出，到被批出、被記錄、並在日後被覆核。一個完整的流程有四個部分：一份寫明已界定角色和業務理由的申請；由對該員工負責的人和對該系統負責的人分別審批；由持有管理權限的人完成開通；以及一條附有覆核日期的權限紀錄。申請與開通被刻意分成由不同的人完成的兩個步驟，這樣就沒有人可以為自己開通權限。
存取申請應該由誰審批？
兩位審批人足以應付大多數情況。直屬主管確認這個人工作上確實需要這項權限，這是關於申請人的問題。系統或資料負責人確認這個角色實際授予哪些權限、這個人是否應該持有，這是關於系統的問題。來自保安團隊的第三道審批，只有在特權或敏感權限的情況下才值得加上——本範本正是這樣分流的。加多審批人很少能改善決策，卻一定會拉長等候時間，而等候時間正是共用密碼之類非正式變通做法的來源。
存取管理中的職責分隔檢查是甚麼？
它檢驗的是：申請的角色加上此人已有的權限，會不會令一個人在沒有任何獨立環節的情況下，由頭到尾完成一宗敏感交易。常見的例子是建立供應商並批准其付款，或者撰寫程式碼並把它發布到生產環境。這項檢查需要一份事先議定的衝突組合清單作為比對依據。當衝突無法避免時——例如在一個小團隊裡——通常的做法是採用一項有文件紀錄的補償性控制，一般是由另一個人事後檢視，並記錄在這條權限上。
使用者權限應該多久重新認證一次？
頻率應該由風險決定。一種常見做法是：特權帳戶和管理員帳戶每季一次，標準業務角色每年一次，而且每當有人轉換職位或組別時立即進行一次額外覆核。ISO/IEC 27001:2022 控制項 A.5.18 要求定期檢視存取權限，但沒有訂明具體間距，頻率要由你們自己給出理由。另外要留意，流程圖記錄的是意圖，而不是合規本身：審核員索取的證據，是這個流程產出的審批紀錄和權限登記冊。