稽核要的權限審查，
每次都要從截圖開始
為什麼現在很紅：主管回信寫「沒問題」的那份權限清單上，還列著一位早已離職的員工。
- 一句話結論
- 很多公司的權限審查是稽核前兩週才做：IT 截圖、主管回信說沒問題，主管手上沒有判斷依據，審查就變成蓋章。
- 他要的是什麼
- 他最喜歡的就是審查表上那一列「保留」：一個沒人在用、卻沒被收回的帳號，比任何漏洞都穩定。
- 你今天做一件事
- 今天就挑一套放客戶資料的系統，匯出帳號清單和最後登入時間，看有沒有很久沒登入、卻還有權限的人。 直接去做 →
- 哪些能信
- 2 可證明2 推論1 缺口 每個主張都標了等級，缺口是誠實寫出來的。
- 破口速查
- 受害端一律去識別化；寫「未公開」代表公開資料查不到。
- 伺服器服務商
- 不適用（示意情境；涉及的是公司內部各套系統的帳號權限，不是特定主機）
- 網路服務商
- 不適用（同上）
- 漏洞出現的地方
- 管理層：權限審查只在稽核前臨時做，靠截圖和主管回信；審查表沒有最後登入時間，主管無從判斷，只能蓋章；標為撤銷的權限沒有人追蹤是否真的收回
- 馬上自我檢測
列出放了客戶資料、財務資料或有管理權限的系統（通常五到十套） 逐一匯出各系統的使用者與角色清單，看有沒有最後登入時間欄位 翻出上一次審查紀錄，確認標為撤銷的帳號現在是否已停用- 漏洞修補方式
- 固定審查表（帳號、部門、角色、權限等級、最後登入時間、保留／撤銷、審查人簽名）；由直屬主管或系統擁有者審；兩週期限、逾期上報；撤銷後在同一列填執行日期；每季一個證據資料夾；高風險系統每季、一般系統每半年
有 15 分鐘再看：其餘 2 點
- 結果是證據不完整、每次從零開始，審查發現要收的權限也沒人確認到底收了沒有，連已離職者都可能留在清單上。
- 不用先買工具：固定審查表加上最後登入時間、找對審查人、兩週期限、撤銷有執行日期、每季一個證據資料夾，試算表就能通過稽核。
稽核前兩週，IT 到每個系統截圖、整理成表格寄給主管，主管回一句「沒問題」就過了。審查做了，但真的有人在看嗎？這篇把權限審查改成一套每季跑得動、稽核時直接交得出去的固定流程。
本篇目錄
主管說沒問題的那份清單
假設有一家七十人的 SaaS 公司正在準備 SOC 2。稽核員要求提供過去一年每季的權限審查紀錄。IT 翻了一輪，找到的是：兩次有截圖和主管回信，一次只有截圖，一次完全沒做。
先說清楚，這是示意情境，不是真實事件，公司與細節都是為了說明而設。但接下來這一幕在很多公司都看得到：有一份主管回覆「沒問題」的清單上，赫然列著一位早已離職的員工。審查做了，回信也有，可是沒有人真的看過那一列。
這篇要講的只有一件事：權限審查要的不是截圖，是一個每季跑得動、主管看得懂、撤銷有人追的固定流程。
形式上的審查，風險在哪裡
第一層是形式審查。主管拿到的是一張只有姓名和角色的截圖，看不出誰還在用、誰早就沒登入，只能蓋章。
第二層是證據不完整。截圖沒有日期，回信散在個人信箱，稽核時拿不出來，或拿出來也證明不了什麼。
第三層是每次從零開始。沒有固定格式和流程，每季都要重新整理一次，久了就有一季「忘了做」。
最後是發現問題卻沒有後續。審查標出要收的權限，沒人確認到底收了沒有；下一季再審，同一個帳號又出現在清單上。
這篇示意情境裡，有哪些存取權沒人管
這是示意情境，沒有實際外洩；下表列的是權限審查最常漏掉、卻仍然有效的存取權，讓你知道審查表上每一列背後是什麼。
| 服務 | 憑證類型 | 用途 | 存在形式 | 放在哪 | 權限範圍 | 狀態 |
|---|---|---|---|---|---|---|
| 內部系統帳號（已離職者） | 帳號密碼或 SSO 登入權 | 原本給該員工日常使用 | 存在各系統的使用者清單裡 | 主管簽核過的審查清單上仍列為有效 | 依該帳號角色，可能含客戶或財務資料 | 示意情境；未停用前持續有效 |
| 審查標為撤銷、但未執行的權限 | 角色或權限指派 | 原本因專案或職務臨時開通 | 存在系統的角色設定裡 | 審查表標了撤銷，系統裡沒改 | 依當初開通範圍，常見是管理權限 | 示意情境；沒有執行紀錄就無法確認已收回 |
兩列的共同點是：都被看過，卻都沒有被處理。
能證明的、只能推論的
這篇是觀點文，情境是示意的，所以能證明的只有官方文件寫明的功能與限制；情境裡的狀況只能算推論。
不花錢就能做的流程
到這裡，其實已經足夠理解問題在哪。如果你想直接動手，可以跳到「今天就可以來試試」；下面是完整的六步流程。
第一步，決定審查範圍。 不必審全部。先挑放了客戶資料、財務資料或有管理權限的系統，通常五到十套。
第二步，固定的審查表格式。 每列一個帳號：姓名、部門、角色、權限等級、最後登入時間，加上「保留／撤銷」欄位和審查人簽名。把最後登入時間放進去，主管才有判斷的依據。
第三步，找對審查人。 由直屬主管或系統擁有者審，而不是 IT 自己審自己。
第四步，有期限、有追蹤。 給兩週期限，逾期就上報。標為「撤銷」的，IT 執行後在同一列填上執行日期。
第五步，存成固定檔案。 每季一個資料夾，名稱固定用 access-review-Q3-m4x 這種格式，裡面放審查表、主管確認紀錄和撤銷執行紀錄。稽核時直接交出這個資料夾。
第六步，頻率依風險調整。 高風險系統每季審，一般系統每半年審。
什麼時候不需要買工具
系統在十套以內、人數百人以下的話，「試算表加資料夾」完全可以通過稽核。稽核員看的是流程有沒有落實、證據完不完整，而不是你用了什麼工具。
真的要看工具，市面上大致分三類。身分平台內建的最先用：Microsoft Entra 的存取審查可以定期審查群組、應用存取和角色指派，但要確認授權；Google Workspace 則可以匯出使用者和群組清單，做為審查表的資料來源。雲端平台方面，AWS IAM Access Analyzer 能找出未使用的角色、存取金鑰和權限，未使用存取的發現要付費。商用 SaaS 管理平台如 1Password SaaS Manager（官網說可以自動發起審查並保留證據）、Torii、Zluri（目前定位為身分治理），以自動產生清單和寄送提醒為主。
限制也要一起看：工具能自動產生清單、寄送提醒，但「這個人還需不需要這個權限」還是要人來判斷；自動化審查的涵蓋範圍，取決於有多少系統有串接。選的時候先確認稽核框架要求的範圍和頻率，不要過度投資；已經有 Entra ID Governance 的話先用內建功能；要審的系統超過一二十套時，自動化才比較划算。
這篇提到的項目要花多少錢
這篇的方法以人力為主，表裡的金額大多是估算或未公開，照實標出來。
| 項目 | 用量 | 單價 | 期間 | US$ | NT$ | 舉證 |
|---|---|---|---|---|---|---|
| 建立審查表與範圍清單 估 | IT 一人 | 估 4 小時 | 一次性 | — | — | 本站依六步流程估算 |
| 每季審查（匯出、寄送、追蹤、歸檔） 估 | IT 一人＋各審查人 | 估每套系統 30–60 分鐘 | 每季 | — | — | 本站估算 |
| Microsoft Entra 存取審查 | 依使用者數 | 需 Entra ID Governance 或 Entra Suite 授權 | 訂閱 | — | — | 官方文件註明授權需求，本文未查牌價 |
| AWS IAM Access Analyzer 外部存取發現 | AWS 帳號內建 | 不另收費 | — | 0.00 | 0 | AWS 官方文件 |
| AWS IAM Access Analyzer 未使用存取發現 | 依分析的角色與使用者數 | 付費功能，本文未查牌價 | 每月 | — | — | AWS 官方文件註明為付費 |
| 商用 SaaS 管理／身分治理平台 | 依人數 | 未公開牌價，需洽詢 | 年約 | — | — | 各廠商官網未列公開價格 |
| 合計（僅可證明列） | 0.00 | 0 | ||||
最貴的不是工具，是稽核員翻到那一列已離職者時，你得重做一整年的證據。
你可以學到什麼
站在攻擊者那一側看，形式化的權限審查是最好的掩護：一個沒人用的帳號被主管簽了「保留」，就多了一季合法存在的理由。他不需要提權，只需要等一個本該被收回、卻沒人追的權限。
- 01權限審查表要放最後登入時間，主管才有判斷依據；只有姓名和角色的截圖，審查只會變成蓋章。
- 02審查人應該是直屬主管或系統擁有者，不是 IT 自己審自己。
- 03標為撤銷的權限要在同一列填上執行日期，沒有執行紀錄就等於沒收回。
- 04每季一個證據資料夾，放審查表、確認紀錄和撤銷紀錄，稽核時直接交出去，不必每次從截圖開始。
- 05百人以下、十套系統以內，試算表加資料夾就能通過稽核；工具只是讓清單和提醒自動化，判斷還是要人做。
- 01權限審查（Access Review）這篇的主角：定期確認誰能存取什麼，稽核每次都會問。
- 02最後登入時間審查表裡最能幫主管判斷「還需不需要」的欄位，沒有它審查就只剩蓋章。
- 03系統擁有者（System Owner）審查要由懂業務的人來簽，不是由 IT 自己審自己。
- 04撤銷執行紀錄審查標了撤銷不等於收回；同一列的執行日期才是證據。
- 05稽核證據資料夾每季一份，讓稽核從「臨時截圖」變成「直接交件」。
- 06SOC 2示意情境的稽核框架，要求拿得出過去一段期間的審查紀錄。
- 07ISO 27001同樣會問存取權限是否定期審查，流程可以共用。
- 08Microsoft Entra 存取審查身分平台內建的審查功能，但要先確認 Entra ID Governance 授權。
- 09IAM Access AnalyzerAWS 上找未使用角色與金鑰的工具；外部存取免費、未使用存取付費。
- 10風險分級審查頻率高風險系統每季、一般系統每半年，避免什麼都審導致什麼都沒審好。
全部唯讀，不改任何設定；做完你會知道自己有沒有同樣的破口。
- 列出放了客戶資料、財務資料或有管理權限的系統（不用指令）看到什麼代表什麼：通常五到十套；這就是第一輪審查的範圍。
- 挑其中一套，從管理後台匯出使用者清單與角色（唯讀）看到什麼代表什麼：如果匯出結果沒有最後登入時間，就是主管目前只能蓋章的原因。
- 在清單上找長時間沒登入、或已離職卻仍有效的帳號（唯讀）看到什麼代表什麼：每找到一個，就是上一輪審查漏看的一列。
- 翻出上一次審查紀錄，抽三個標為撤銷的帳號，到系統確認現況（唯讀）看到什麼代表什麼：如果還有效，代表撤銷沒有被追蹤，第四步的執行日期欄位要補上。
揭露：本文未受任何廠商贊助，提及的產品僅為舉例。
環境背景、時間線、攻擊鏈對照 ATT&CK、關鍵證據、根因、處置與檢討都在完整版，約 7 分鐘。
來源
- Microsoft Entra ID Governance：存取審查概觀（含授權需求）
- AWS IAM Access Analyzer：發現項目類型（含未使用存取）
- Torii（SaaS 管理平台）
- Zluri（身分治理平台）
本文為公開報導與官方公告的整理與拆解，非第一手鑑識；證據等級依來源可信度標註。
本文由 AI 團隊協助研究與撰寫，經隱私與事實檢查後發布；證據等級依來源可信度標註。
複製下面這段，貼給你在用的 AI 工具（Claude Code、Cursor、Copilot、ChatGPT 都可以）。它會用本篇的破口位置、自我檢測與學習重點，對你的專案或環境做一次資安掃描，列出潛在問題與建議的調整或加強方式。
預設是唯讀：只發現問題、提出建議，不會改你任何檔案或設定。
M8 結業盤點 · 想在自己的環境做一次同樣的盤點，從 自我盤點 開始。
每篇新文章一封：三點摘要、關鍵字定義、今天能做的一件事。或先 加入會員 記錄你完成的任務。