💡 先搞懂問題
新同事到職那天，主管最在意的是「他今天能不能開始工作」，所以帳號和權限通常很快就開好了，有時還會照著前一位同事的權限整包複製。真正的問題出在後面：調部門時沒人想到要收回舊權限，升職時新權限又往上疊；離職當天人資辦完手續，資訊部卻要等到好幾週後才知道；倉庫幾個班別共用一組帳號，出了錯查紀錄只看到同一個名字。幾年下來，沒有人說得清楚誰到底能做什麼。
附錄 A 把這件事拆成幾個控制。5.15 先訂規則：誰在什麼條件下可以存取什麼；5.16 管理身分（identity）從建立到刪除的生命週期；5.17 管理密碼、權杖這類鑑別資訊（authentication information）；5.18 處理存取權（access rights）的申請、核准、審查與移除。系統面的落實在 8.2 特權存取、8.3 資訊存取限制、8.5 安全驗證；而 5.3 職務分隔與 6.5 離職與調職後的責任，則是讓整套流程不被單一個人掌控、也不在人員異動時漏掉。
生活比喻：辦公大樓的門禁卡
想像一棟二十層的辦公大樓。大樓先訂規則：員工只能進自己公司的樓層，機房和財務室要另外申請，清潔人員的卡只在晚上有效。新員工報到時領一張印有照片的門禁卡，卡片綁著本人，還要搭配密碼或指紋才能刷開機房。他調到另一個部門時，舊樓層的權限應該關掉；他請長假時，卡片暫時停用；他離職那天，卡片收回並註銷。大樓還有一張能開所有門的萬用卡，平常鎖在管理中心，誰借、借去開哪扇門、幾點歸還，都要登記。每年管理中心再拿各公司的員工名冊和門禁系統對帳，把對不上的卡停掉。
這個比喻有幾個地方和實際不同。門禁卡只有一套系統，組織的資訊系統卻有幾十套，每套各有帳號，離職時只停掉網域帳號，雲端服務、ERP、VPN 可能還開著。門禁只管「進不進得了這層樓」，資訊系統還要管進去之後能看什麼、能不能改、能不能匯出，這是 8.3 的範圍。另外，系統之間互相連線用的服務帳號背後沒有一個「人」，同樣要有負責人、要定期檢查，比喻裡沒有對應的角色。
🎮 互動實驗室一：帳號生命週期模擬
一家 250 人的電子零件製造商（虛構）有位員工周以安，你要陪她走過到職、調職、升職、長假與離職五個階段。每一步請勾選她該有的權限、設定帳號狀態，並選擇流程做法，再按「送出這一步」。旁邊（手機在下方）的權限卡會即時標出職務衝突與特權，送出後系統會逐項檢查最小權限、職務分隔（5.3）、特權帳號（8.2）與離職回收（6.5）。可以修改後再送出，但只有第一次送出就全部通過才計分；按「下一步」時，權限會以建議設定為起點。
🎮 互動實驗室二：權限審查找異常
這是同一家公司的帳號與權限清單（示意），審查基準日是 9 月 30 日。請逐一判斷每個帳號：先點一張帳號卡，再點下方的判定按鈕。每判定一張就會說明對應的控制與稽核證據，全部完成後可以產出審查報告。
📘 原理補完
九項控制怎麼分工
身分與存取的控制分散在附錄 A 的三個主題：組織控制訂規則與流程（5.3、5.15–5.18），人員控制處理人員異動（6.5），技術控制把規則做進系統（8.2、8.3、8.5）。標準只要求這些控制在適用時要做到，至於角色怎麼切、權限多久審一次、哪些系統要 MFA、密碼規則怎麼訂、離職帳號多久後刪除，都由組織依風險評鑑自行決定，再寫進政策與程序。下表「稽核常看」是驗證稽核的常見做法，不是標準條文。
| 控制 | 英文短標題 | 白話在管什麼 | 稽核常看的證據 | 2013 版對應 |
|---|---|---|---|---|
| 5.15 | Access control | 訂存取規則：知其所需、最小權限、採用哪種授權模式 | 存取控制政策、角色權限矩陣 | A.9.1.1、A.9.1.2 |
| 5.16 | Identity management | 身分從建立到刪除，一人一號，共用要核准並有責任人 | 帳號清單、共用與服務帳號的責任人 | A.9.2.1 |
| 5.17 | Authentication information | 密碼、權杖、憑證怎麼配發、保管、重設 | 密碼原則設定、重設時的身分確認方式 | A.9.2.4、A.9.3.1、A.9.4.3 |
| 5.18 | Access rights | 權限的申請、核准、異動、定期審查與移除 | 申請單、權限審查紀錄與移除證據 | A.9.2.2、A.9.2.5、A.9.2.6 |
| 5.3 | Segregation of duties | 衝突的職務分給不同人，做不到時用補償性控制 | 職務衝突矩陣、補償性控制的執行紀錄 | A.6.1.2 |
| 6.5 | Responsibilities after termination or change of employment | 離職、調職後仍有效的義務，以及職責交接 | 離職與調職檢核表、保密提醒簽收 | A.7.3.1 |
| 8.2 | Privileged access rights | 高權限帳號另外核准、帳號分開、留紀錄、定期覆核 | 管理員群組名單與申請單比對、特權覆核紀錄 | A.9.2.3 |
| 8.3 | Information access restriction | 在系統裡依角色實際限制讀、寫、刪、匯出 | 系統權限設定與矩陣比對 | A.9.4.1 |
| 8.5 | Secure authentication | 登入機制的強度：MFA、錯誤鎖定、保護登入過程 | MFA 啟用報表、鎖定設定、例外核准紀錄 | A.9.4.2 |
從入職到離職的流程骨架
實務上常把這套流程叫做 JML（Joiner、Mover、Leaver，入職、異動、離職），再加上定期審查。關鍵是讓人資異動成為觸發點，而不是靠資訊部自己發現。
- 入職：人資建檔觸發帳號申請，依角色權限矩陣開通，初始密碼唯一且首次登入強制變更（5.16、5.17、5.18）。
- 異動：調職或升職生效時，新舊主管共同確認：收回舊職務權限、開通新職務權限、交接舊職責與資產擁有者身分，並檢查新組合有沒有職務衝突（5.18、6.5、5.3）。
- 特權申請：管理權限另外申請、核准，使用獨立的管理帳號並啟用 MFA，特權活動留下紀錄（8.2、8.5、8.15）。
- 長期不在：長假或留職停薪期間暫停登入，業務由代理人以自己的帳號接手，不交出密碼（5.16、5.17）。
- 離職：最後工作日停用所有系統帳號、收回設備與門禁卡、提醒離職後仍有效的保密義務，並把資料與職責交接（6.5、5.11、5.18）。
- 定期審查：由資訊或系統擁有者逐一確認權限仍有需要，留下審查對象、決定與移除完成的證據（5.18）。
最小權限是每個人只拿工作必要的權限；職務分隔是就算每個權限都必要，也不讓互相牽制的組合落在同一人身上。實驗室一升職那一步，「付款登打」對新課長已經不必要（最小權限），而「登打＋核准」放在一起更是職務衝突（職務分隔）。
5.17 偏向管理流程與使用者責任：初始密碼怎麼給、重設時怎麼確認本人、不共用不外流。8.5 偏向系統端的技術：要不要 MFA、錯誤幾次鎖定、登入過程是否加密。密碼長度與更換頻率由組織決定，近年的公開指引（例如 NIST SP 800-63B）傾向重視長度與外洩密碼比對，而不是頻繁強制更換。
2013 版與 2022 版的差別
2013 版的存取控制集中在 A.9 一整章，2022 版把它拆開：組織面的規則與流程變成 5.15 到 5.18，技術面的落實放到 8.2、8.3、8.4（原始碼存取）、8.5 與 8.18（特權公用程式）。拆開的同時也有合併，例如 5.17 合併了舊版關於密碼配發、使用者保管與密碼管理系統的三項控制，5.18 合併了權限配發、審查與移除三項。轉版時，原本 A.9 的程序通常不必重寫，但要重新對應 SoA 的條號，並確認權限審查與移除的紀錄能對應到 5.18。
常見誤解與稽核常見的不符合
「權限審查做了，紀錄是主管簽名『已審查，無異常』。」稽核員要看的是審查對象清單、每個人的保留或移除決定，以及移除在系統上真的完成的證據。只有一行簽名，常被認為無法證明審查有效。
「離職帳號都有停用。」稽核員會拿人資的離職清單和各系統帳號狀態逐筆比對，停用日期晚於離職日好幾週，或某套雲端服務根本沒停，都是常見的不符合。調職人員的舊權限沒收回更常見，因為人還在，沒人覺得有問題。
「管理員帳號大家共用，因為密碼由主管保管。」主管保管密碼解決不了追溯問題：出事時紀錄只顯示 admin，不知道是誰。較好的做法是個人化的管理帳號，或透過特權存取管理（PAM）系統借用並錄下工作階段。
「小公司人少，職務分隔做不到就不用做。」標準允許依風險判斷，做不到完全分開時，可以用補償性控制，例如主管定期檢視異動紀錄、系統自動留存操作日誌、由第三人抽查，但要有實際執行的紀錄。
「MFA 只要對外系統就好。」哪些系統要 MFA 由組織依風險決定，標準沒有固定清單；但特權帳號與遠端存取沒有 MFA、例外名單也沒有核准紀錄，稽核時常被追問理由。
✅ 自我檢測
6 題原創單選題，選完立即顯示對錯與解析。目前得分：0 / 6