使用者帳號開通流程圖（入職、調職、離職）
使用者帳號開通流程圖：人力資源事件、在目錄中建立身分、憑證與 MFA、職位權限組合、特權存取的負責人審批、下游帳戶、核實與重新認證。
甚麼是使用者帳號開通流程圖（入職、調職、離職）流程
使用者帳號開通是靜靜地失效的，所以它通常在一次審核之後才被修好，而不是在審核之前。入職那一半是看得見的：新同事第一天沒有電郵信箱就會投訴，總會有人去處理。其餘一切都是看不見的。權限照著上一個坐這張椅子的人複製，於是一個授權過多的帳戶就成了整個部門的基準線。承辦商到職時沒有人力資源紀錄、沒有屆滿日期，而當初找他來的那位擔保人早已離職。整個系統版圖有一半在單一登入後面、會自動開通，另一半——那套財務軟件、某個團隊用信用卡買回來的工具、供應商入口網站——則是一條沒有人量度的人手隊列。而一次內部調職只會加，從不會減，因為任何地方都沒有東西會去報告那些已經變得不再必要的權限。這些都不會製造一宗事故。它們製造的是緩慢的累積，多年之後才以一項權限覆核發現、一次未通過的管控測試，或者一個前員工仍在成功登入的帳戶浮現出來。
本圖是身分與帳戶的機器，不是申請表，也不是審批鏈。一位已經在職的人多要一項權限，連同圍繞它的審批與重新認證周期，是 /yue/templates/存取申請流程 上的存取申請流程；同一項申請若由人力資源的入職或調職事件觸發、並由職位範本界定範圍，則在 /yue/templates/員工存取申請流程。對某一份資料集的存取，由資料負責人按分類與用途而非按職位來判斷，在 /yue/templates/資料存取申請流程。這裡的離職路徑刻意畫得很短，然後就交出去：完整的權限撤銷流程，連同共用帳戶與服務帳戶、停用還是刪除，以及證據保存，在 /yue/templates/用戶存取權限撤銷流程。合約、背景審查、設備與第一天的安排，屬於 /yue/templates/員工入職流程。餘下的，就是由事件到一組可用、已核實、已記錄的帳戶之間的一切——身分、憑證、權限組合、下游系統版圖——再加上那幾頁都沒有涵蓋的一類人：完全沒有人力資源紀錄就到職的非員工。以管控措施而言，這是 ISO/IEC 27001:2022 附錄 A 的身分那一半——管治一個身分整個生命週期的 A.5.16 身分管理，以及管治據此發出的憑證的 A.5.17 鑑別資料——而不是管治該身分其後可以觸及甚麼的 A.5.15 與 A.5.18。
本圖畫出了三個大部分開通程序都留作默契的判斷。「員工還是非員工？」排在身分存在之前，因為一名承辦商需要一位具名擔保人和一個屆滿日期，而人力資源資料流永遠不會提供這兩樣；缺了它們而建立的身分，就是兩年後權限覆核找出來的那個孤兒帳戶。「是否在標準權限組合之內？」把流程一分為二：職位組合之內的一切都自動開通、路徑上沒有任何人，只有特權或組合以外的權限才送到負責人手上——正是這一點，避免了審批退化成蓋在電郵信箱上的一個橡皮圖章。而「已開通權限是否與申請一致？」是一道閘，不是結案前的一道手續，因為它讀回目標系統實際授予了甚麼，再與當初申請的內容比對；沒有經過審批就落了地的權限，收到它的人從來不會報告。職位變動分支再加上第四個判斷「舊權限是否超出新組合？」，重新認證再加上第五個「權限是否仍與職位相符？」——兩者都回答到同一個撤銷步驟，所以無論撤銷的需要是怎樣被發現的，權限離開的出口都只有一個。
本流程圖涵蓋的內容
本範本包含
- 六個階段——觸發、身分、權限、開通、核實、變動與覆核——鋪在五條泳道上：人力資源或擔保人、身分管理團隊、直屬經理、權限負責人、資訊保安。
- 一個入口，五類事件。「屬於哪一類身分事件？」把入職、職位變動、離職、緊急存取申請和排定的重新認證都導入同一張圖，令這套機器是共用的，而不是為每一種情況各自重新發明一次。
- 身分階段的全貌：「員工還是非員工？」把承辦商、外判人員與服務夥伴導向「登記擔保人與屆滿日期」——這是唯一一個給他們一位可問責的負責人和一個終止日期的步驟——然後兩條路徑在「在目錄中建立身分」與「發放憑證並登記 MFA」處匯合。
- 「是否在標準權限組合之內？」——標準那條分支直接跑到「自動開通標準權限組合」，路徑上沒有審批人；特權與組合以外的權限則送往「權限負責人是否批准？」，其駁回分支終止於「權限申請被駁回並結案」。
- 按圖上實際次序運行的開通：先「自動開通標準權限組合」，再「在下游系統中開設帳戶」，自動與人手的系統版圖一併涵蓋，然後是「已開通權限是否與申請一致？」，其不一致分支會走過「更正多授或少授的權限」再重新檢查，而不是把工單結案。
- 變動那一半：一次職位變動會被問「舊權限是否超出新組合？」，找到的任何一項都送往「撤銷已被取代的權限」，然後回到「是否在標準權限組合之內？」；離職者到達「交予權限撤銷流程」；而「權限是否仍與職位相符？」會把已偏離的答案送往同一個撤銷步驟。
何時使用本範本
- 你們在寫 IT 運作手冊的身分與存取章節，需要用一張圖說清楚由一宗人力資源事件到一組可用帳戶之間，究竟發生了甚麼。
- 你們準備採購或設定一套身分治理工具，希望在供應商的預設工作流替你們決定之前，先把分支定下來——甚麼自動開通、甚麼需要負責人、甚麼仍然是人手隊列。
- 權限覆核一再翻出人們幾年前已經離開的職位所帶來的權限，你們需要把職位變動的撤銷步驟連同負責人和限期一併畫出來。
- 你們的系統版圖裡滿是非員工——承辦商、外判人員、審核員、合作夥伴、服務帳戶——而他們全部都不在流程其餘部分所倚賴的那條人力資源資料流裡。
- 審核員、客戶的保安問卷，或者 ISO 27001 的覆核人，問到你們的身分是怎樣建立的、權限是怎樣授予的，以及你們憑甚麼知道現存的權限就是當初獲批的權限。
運作方式
把泳道改成你們自己的角色
把人力資源或擔保人、身分管理團隊、直屬經理、權限負責人和資訊保安，換成你們真實存在的角色。刻意把人力資源與擔保人放在同一條泳道：那是同一份工作，只是為不同的人群而做；把它們拆開，正是非員工最後無人問責的原因。權限負責人這條泳道，是大部分機構發現自己一直沒有填上的一條。如果你們今天說不出誰是特權權限的負責人，那個缺口是一項覆核發現，而不是一個繪圖問題；那條泳道應該留在圖上、明顯地空著，直到它被補上為止。
宣告你們的權威來源，以及它不包含甚麼
本圖假定有一條權威的入職、調職、離職資料流。寫下那是哪一套系統、它帶有哪些欄位——職位、經理、到職日期、變動生效日期、最後上班日——以及一項變動要多久才會在其中出現。然後寫下誰不在裡面。承辦商、董事會成員、外判人員、實習生和機器身分通常都不在，而他們每一類都需要自己的登記冊和自己的擔保人，流程的其餘部分才跑得起來。
在發佈之前先把權限組合寫出來
「推導職位的權限組合」在組合存在之前是空轉的。由你們最常招聘的十個職位開始，寫下每一個在第一天真正需要甚麼。凡是有登入或最後使用時間的資料，就按現任持有者實際用到的來建，而不是按他們持有的來建；兩者之間的差距通常很闊，而這正是把組合寫出來值得做的全部理由。把每一個組合當作下限而不是上限，令組合以外的東西仍然顯眼到值得開口去申請。
訂出負責人審批的門檻
「是否在標準權限組合之內？」只有在準則就寫在旁邊時才管用。走上審批分支的典型觸發條件包括管理員與 root 權限、生產環境存取、支付或薪資系統、個人資料與健康資料，以及任何可以改動別人權限的東西。發佈之前，先用上一季實際授予的權限去試一次這份清單：一條會抓住其中大部分的準則，不算是準則。如果甚麼都送到權限負責人手上，審批到達的速度就會快過任何人讀得完的速度，這項管控措施也就變成一條大家學會一路點過去的隊列。
把職位變動的撤銷變成有人追蹤的責任
「撤銷已被取代的權限」是決定權限會不會在你們機構裡越積越多的一步。給它與授權那一半相同的工單、相同的負責人、相同的限期，並且只有在兩半都完成之後，才把這宗職位變動事件結案——一張在授權那一半就結案的工單，正是撤銷永遠不會發生的機制。本圖刻意把比對放在直屬經理而不是身分管理團隊那裡：團隊做得出差異清單，但只有經理知道某一項權限是真的已被取代，還是交接期間仍然需要。
與真正跑這條流程的人走一次，然後發佈一個版本
在發佈之前，先把兩條預設沒有人認領的分支定下來。決定誰可以在非辦公時間動用緊急存取、事後由誰讀那份工作階段紀錄；再決定重新認證時由誰處理「已偏離」這個答案、限期是甚麼時候，因為一次只產生清單、卻沒有人據之撤銷的覆核，比不做覆核更差。然後把圖帶去給一位服務台工程師、一位近期招聘過人的直屬經理，以及最近一次跑權限覆核的那個人，按實際情況改正。發佈改正後的版本，令此前的版本仍然可讀，並在你們的存取控制政策中引用它。
常見問題
使用者帳號開通流程包含哪些步驟？
由權威系統取得一宗入職、職位變動或離職事件；判斷該人是員工還是非員工，並給非員工一位擔保人和一個屆滿日期；在目錄中建立或比對出一個身分，其識別碼永不重用；針對該身分發放憑證並登記多重因素驗證（MFA）；按職位推導權限組合；把組合之內的一切自動開通，並把特權或組合以外的權限送交權限負責人審批；在下游系統中開設帳戶，自動的和人手隊列的都要開；核實各系統實際授予的權限，是否就是當初申請的權限；由直屬經理確認；再把權限記錄於該身分之下。之後流程仍然繼續運行：一次職位變動會重新推導組合，並撤銷舊職位不再足以支撐的權限；一位離職者會被停用並交予撤銷流程；而重新認證則定期檢查權限與職位是否仍然一致。
甚麼是入職即有（birthright）或按職位界定的權限組合？
那是一份工作在第一天所需要的權限集合，掛在職位上而不是掛在人身上：電郵與日曆、內聯網、該職能的核心業務系統、該團隊的共用磁碟。因為它是由職位推導出來的，所以可以在路徑上沒有審批人的情況下授予，而這正是重點——它把例行的授權由審批隊列中移走，令例外能夠被認真讀完。有兩條規則令權限組合保持誠實。要按這份工作的需要去建，絕不可以匯出上一位任職者的權限來建，因為那樣會把所有累積下來的額外權限，連同必需品一起複製過去。並且給每一個組合一位具名負責人和一個覆核日期，因為無人擁有的組合只會不斷變大：每一項無法拒絕的申請都會被加進去，兩年之內它授予的權限，就會遠遠超過任何單一職位所需。
使用者帳號開通流程與存取申請流程有甚麼不同？
兩者在中間交匯，各自擁有不同的一半。/yue/templates/存取申請流程 上的存取申請流程，由一位已經在職、需要多一套系統的人開始：他提出申請，直屬經理與系統負責人批准，然後開通，並在日後重新認證。/yue/templates/員工存取申請流程 上的員工存取申請流程，涵蓋同一項申請由人力資源的入職或調職事件觸發、並由職位範本界定範圍的情況。這兩頁講的都是判斷。本頁講的是執行：建立身分、發放憑證並登記多重因素驗證、推導權限組合、在每一個下游系統中開設帳戶，以及由目標系統把權限讀回來，核對它們就是獲批的那些。如果你們在設計申請表或審批鏈，用那兩份。如果你們在建立或記錄它們背後的開通機器，包括承辦商身分和內部調職的撤銷那一半，就用這一份。如果問題是對一份資料集而非對一套系統的存取，請看 /yue/templates/資料存取申請流程。
使用者帳號開通實際上有多少可以自動化？
比大部分機構已經自動化的要多，但永遠不會是全部。單一登入後面的系統可以不用開工單就跑起來：目錄身分由人力資源紀錄建立，職位的權限組合被套用，群組成員資格隨之而來。令覆蓋率無法做到完整的，是那片沒有人規劃過的系統版圖——沒有 API 的薪資系統、自己保存一份本機用戶名單的實驗室儀器、要靠回覆一封電郵才開得到帳戶的合作夥伴外聯網。這些都需要一條有具名負責人和目標時限的隊列，而且必須被列出來，因為一套不在清單上的人手系統，對入職者來說會遲開，對離職者來說會整個漏掉。要保留一份登記冊，記錄哪些系統已連接、哪些未連接，每買入任何東西時重新檢視一次，並把縮短那份人手清單當成真正的工作計劃。只自動化授予、不自動化讀回，本身就是另一個陷阱：連接器會靜靜地失敗，這正是核實那一步從目標系統而不是從工單讀取權限的原因。
承辦商和其他非員工要怎樣開通帳號？
與員工一樣，只是上游沒有任何東西會告訴你他們存在。承辦商、外判人員、審核員、合作夥伴的工程師、實習生和機器身分很少會出現在人力資源系統裡，所以令一個身分變得可管理的那兩項屬性，必須刻意記下來：一位機構內部、對它負責的具名擔保人，以及一個取自合約或委聘期、而不是任其開放的屆滿日期。要令屆滿自動生效——帳戶到日自己停用，而續期是擔保人的一個明示動作，並附上新的結束日期。擔保人離職時要重新指派擔保責任，因為擔保人已經走了的身分，正正就是沒有人會去覆核的那種帳戶。非員工通常還應該配更緊的權限組合，以及比正式員工更短的重新認證周期，因為他們的工作面更窄、流動更快。權限覆核翻出來的孤兒帳戶，大部分屬於機構從來沒有僱用過的人。
此流程所處的位置
在大多數機構中，此流程緊接醫療服務人員資歷審核流程圖之後，並交接給用戶存取權限撤銷流程圖（權限註銷）。
它是存取管治中的其中一個步驟。
第 1 步: 使用者帳號開通流程圖（入職、調職、離職） 當前位置
使用者帳號開通流程圖：人力資源事件、在目錄中建立身分、憑證與 MFA、職位權限組合、特權存取的負責人審批、下游帳戶、核實與重新認證。
第 2 步: 存取申請與權限開通流程圖
存取申請流程圖：以角色為本的申請、直屬主管與系統負責人審批、職責分隔檢查、按最低權限開通，以及定期重新認證。
第 3 步: 員工存取申請流程圖（入職與調職）
第 4 步: 用戶存取權限撤銷流程圖（權限註銷）