使用者帳號開通流程圖（入職、調職、離職）

運作方式

1. 把泳道改成你們自己的角色

   把人力資源或擔保人、身分管理團隊、直屬經理、權限負責人和資訊保安，換成你們真實存在的角色。刻意把人力資源與擔保人放在同一條泳道：那是同一份工作，只是為不同的人群而做；把它們拆開，正是非員工最後無人問責的原因。權限負責人這條泳道，是大部分機構發現自己一直沒有填上的一條。如果你們今天說不出誰是特權權限的負責人，那個缺口是一項覆核發現，而不是一個繪圖問題；那條泳道應該留在圖上、明顯地空著，直到它被補上為止。

2. 宣告你們的權威來源，以及它不包含甚麼

   本圖假定有一條權威的入職、調職、離職資料流。寫下那是哪一套系統、它帶有哪些欄位——職位、經理、到職日期、變動生效日期、最後上班日——以及一項變動要多久才會在其中出現。然後寫下誰不在裡面。承辦商、董事會成員、外判人員、實習生和機器身分通常都不在，而他們每一類都需要自己的登記冊和自己的擔保人，流程的其餘部分才跑得起來。

3. 在發佈之前先把權限組合寫出來

   「推導職位的權限組合」在組合存在之前是空轉的。由你們最常招聘的十個職位開始，寫下每一個在第一天真正需要甚麼。凡是有登入或最後使用時間的資料，就按現任持有者實際用到的來建，而不是按他們持有的來建；兩者之間的差距通常很闊，而這正是把組合寫出來值得做的全部理由。把每一個組合當作下限而不是上限，令組合以外的東西仍然顯眼到值得開口去申請。

4. 訂出負責人審批的門檻

   「是否在標準權限組合之內？」只有在準則就寫在旁邊時才管用。走上審批分支的典型觸發條件包括管理員與 root 權限、生產環境存取、支付或薪資系統、個人資料與健康資料，以及任何可以改動別人權限的東西。發佈之前，先用上一季實際授予的權限去試一次這份清單：一條會抓住其中大部分的準則，不算是準則。如果甚麼都送到權限負責人手上，審批到達的速度就會快過任何人讀得完的速度，這項管控措施也就變成一條大家學會一路點過去的隊列。

5. 把職位變動的撤銷變成有人追蹤的責任

   「撤銷已被取代的權限」是決定權限會不會在你們機構裡越積越多的一步。給它與授權那一半相同的工單、相同的負責人、相同的限期，並且只有在兩半都完成之後，才把這宗職位變動事件結案——一張在授權那一半就結案的工單，正是撤銷永遠不會發生的機制。本圖刻意把比對放在直屬經理而不是身分管理團隊那裡：團隊做得出差異清單，但只有經理知道某一項權限是真的已被取代，還是交接期間仍然需要。

6. 與真正跑這條流程的人走一次，然後發佈一個版本

   在發佈之前，先把兩條預設沒有人認領的分支定下來。決定誰可以在非辦公時間動用緊急存取、事後由誰讀那份工作階段紀錄；再決定重新認證時由誰處理「已偏離」這個答案、限期是甚麼時候，因為一次只產生清單、卻沒有人據之撤銷的覆核，比不做覆核更差。然後把圖帶去給一位服務台工程師、一位近期招聘過人的直屬經理，以及最近一次跑權限覆核的那個人，按實際情況改正。發佈改正後的版本，令此前的版本仍然可讀，並在你們的存取控制政策中引用它。

常見問題

使用者帳號開通流程包含哪些步驟？

由權威系統取得一宗入職、職位變動或離職事件；判斷該人是員工還是非員工，並給非員工一位擔保人和一個屆滿日期；在目錄中建立或比對出一個身分，其識別碼永不重用；針對該身分發放憑證並登記多重因素驗證（MFA）；按職位推導權限組合；把組合之內的一切自動開通，並把特權或組合以外的權限送交權限負責人審批；在下游系統中開設帳戶，自動的和人手隊列的都要開；核實各系統實際授予的權限，是否就是當初申請的權限；由直屬經理確認；再把權限記錄於該身分之下。之後流程仍然繼續運行：一次職位變動會重新推導組合，並撤銷舊職位不再足以支撐的權限；一位離職者會被停用並交予撤銷流程；而重新認證則定期檢查權限與職位是否仍然一致。

甚麼是入職即有（birthright）或按職位界定的權限組合？

那是一份工作在第一天所需要的權限集合，掛在職位上而不是掛在人身上：電郵與日曆、內聯網、該職能的核心業務系統、該團隊的共用磁碟。因為它是由職位推導出來的，所以可以在路徑上沒有審批人的情況下授予，而這正是重點——它把例行的授權由審批隊列中移走，令例外能夠被認真讀完。有兩條規則令權限組合保持誠實。要按這份工作的需要去建，絕不可以匯出上一位任職者的權限來建，因為那樣會把所有累積下來的額外權限，連同必需品一起複製過去。並且給每一個組合一位具名負責人和一個覆核日期，因為無人擁有的組合只會不斷變大：每一項無法拒絕的申請都會被加進去，兩年之內它授予的權限，就會遠遠超過任何單一職位所需。

使用者帳號開通流程與存取申請流程有甚麼不同？

兩者在中間交匯，各自擁有不同的一半。/yue/templates/存取申請流程 上的存取申請流程，由一位已經在職、需要多一套系統的人開始：他提出申請，直屬經理與系統負責人批准，然後開通，並在日後重新認證。/yue/templates/員工存取申請流程 上的員工存取申請流程，涵蓋同一項申請由人力資源的入職或調職事件觸發、並由職位範本界定範圍的情況。這兩頁講的都是判斷。本頁講的是執行：建立身分、發放憑證並登記多重因素驗證、推導權限組合、在每一個下游系統中開設帳戶，以及由目標系統把權限讀回來，核對它們就是獲批的那些。如果你們在設計申請表或審批鏈，用那兩份。如果你們在建立或記錄它們背後的開通機器，包括承辦商身分和內部調職的撤銷那一半，就用這一份。如果問題是對一份資料集而非對一套系統的存取，請看 /yue/templates/資料存取申請流程。

使用者帳號開通實際上有多少可以自動化？

比大部分機構已經自動化的要多，但永遠不會是全部。單一登入後面的系統可以不用開工單就跑起來：目錄身分由人力資源紀錄建立，職位的權限組合被套用，群組成員資格隨之而來。令覆蓋率無法做到完整的，是那片沒有人規劃過的系統版圖——沒有 API 的薪資系統、自己保存一份本機用戶名單的實驗室儀器、要靠回覆一封電郵才開得到帳戶的合作夥伴外聯網。這些都需要一條有具名負責人和目標時限的隊列，而且必須被列出來，因為一套不在清單上的人手系統，對入職者來說會遲開，對離職者來說會整個漏掉。要保留一份登記冊，記錄哪些系統已連接、哪些未連接，每買入任何東西時重新檢視一次，並把縮短那份人手清單當成真正的工作計劃。只自動化授予、不自動化讀回，本身就是另一個陷阱：連接器會靜靜地失敗，這正是核實那一步從目標系統而不是從工單讀取權限的原因。

承辦商和其他非員工要怎樣開通帳號？

與員工一樣，只是上游沒有任何東西會告訴你他們存在。承辦商、外判人員、審核員、合作夥伴的工程師、實習生和機器身分很少會出現在人力資源系統裡，所以令一個身分變得可管理的那兩項屬性，必須刻意記下來：一位機構內部、對它負責的具名擔保人，以及一個取自合約或委聘期、而不是任其開放的屆滿日期。要令屆滿自動生效——帳戶到日自己停用，而續期是擔保人的一個明示動作，並附上新的結束日期。擔保人離職時要重新指派擔保責任，因為擔保人已經走了的身分，正正就是沒有人會去覆核的那種帳戶。非員工通常還應該配更緊的權限組合，以及比正式員工更短的重新認證周期，因為他們的工作面更窄、流動更快。權限覆核翻出來的孤兒帳戶，大部分屬於機構從來沒有僱用過的人。