稽核要的權限審查，每次都要從截圖開始

主管說沒問題的那份清單

假設有一家七十人的 SaaS 公司正在準備 SOC 2。稽核員要求提供過去一年每季的權限審查紀錄。IT 翻了一輪，找到的是：兩次有截圖和主管回信，一次只有截圖，一次完全沒做。

先說清楚，這是示意情境，不是真實事件，公司與細節都是為了說明而設。但接下來這一幕在很多公司都看得到：有一份主管回覆「沒問題」的清單上，赫然列著一位早已離職的員工。審查做了，回信也有，可是沒有人真的看過那一列。

這篇要講的只有一件事：權限審查要的不是截圖，是一個每季跑得動、主管看得懂、撤銷有人追的固定流程。

形式上的審查，風險在哪裡

第一層是形式審查。主管拿到的是一張只有姓名和角色的截圖，看不出誰還在用、誰早就沒登入，只能蓋章。

第二層是證據不完整。截圖沒有日期，回信散在個人信箱，稽核時拿不出來，或拿出來也證明不了什麼。

第三層是每次從零開始。沒有固定格式和流程，每季都要重新整理一次，久了就有一季「忘了做」。

最後是發現問題卻沒有後續。審查標出要收的權限，沒人確認到底收了沒有；下一季再審，同一個帳號又出現在清單上。

這篇示意情境裡，有哪些存取權沒人管

這是示意情境，沒有實際外洩；下表列的是權限審查最常漏掉、卻仍然有效的存取權，讓你知道審查表上每一列背後是什麼。

兩列的共同點是：都被看過，卻都沒有被處理。

能證明的、只能推論的

這篇是觀點文，情境是示意的，所以能證明的只有官方文件寫明的功能與限制；情境裡的狀況只能算推論。

不花錢就能做的流程

到這裡，其實已經足夠理解問題在哪。如果你想直接動手，可以跳到「今天就可以來試試」；下面是完整的六步流程。

第一步，決定審查範圍。 不必審全部。先挑放了客戶資料、財務資料或有管理權限的系統，通常五到十套。

第二步，固定的審查表格式。 每列一個帳號：姓名、部門、角色、權限等級、最後登入時間，加上「保留／撤銷」欄位和審查人簽名。把最後登入時間放進去，主管才有判斷的依據。

第三步，找對審查人。 由直屬主管或系統擁有者審，而不是 IT 自己審自己。

第四步，有期限、有追蹤。 給兩週期限，逾期就上報。標為「撤銷」的，IT 執行後在同一列填上執行日期。

第五步，存成固定檔案。 每季一個資料夾，名稱固定用 access-review-Q3-m4x 這種格式，裡面放審查表、主管確認紀錄和撤銷執行紀錄。稽核時直接交出這個資料夾。

第六步，頻率依風險調整。 高風險系統每季審，一般系統每半年審。

什麼時候不需要買工具

系統在十套以內、人數百人以下的話，「試算表加資料夾」完全可以通過稽核。稽核員看的是流程有沒有落實、證據完不完整，而不是你用了什麼工具。

真的要看工具，市面上大致分三類。身分平台內建的最先用：Microsoft Entra 的存取審查可以定期審查群組、應用存取和角色指派，但要確認授權；Google Workspace 則可以匯出使用者和群組清單，做為審查表的資料來源。雲端平台方面，AWS IAM Access Analyzer 能找出未使用的角色、存取金鑰和權限，未使用存取的發現要付費。商用 SaaS 管理平台如 1Password SaaS Manager（官網說可以自動發起審查並保留證據）、Torii、Zluri（目前定位為身分治理），以自動產生清單和寄送提醒為主。

限制也要一起看：工具能自動產生清單、寄送提醒，但「這個人還需不需要這個權限」還是要人來判斷；自動化審查的涵蓋範圍，取決於有多少系統有串接。選的時候先確認稽核框架要求的範圍和頻率，不要過度投資；已經有 Entra ID Governance 的話先用內建功能；要審的系統超過一二十套時，自動化才比較划算。

這篇提到的項目要花多少錢

這篇的方法以人力為主，表裡的金額大多是估算或未公開，照實標出來。

最貴的不是工具，是稽核員翻到那一列已離職者時，你得重做一整年的證據。

你可以學到什麼

站在攻擊者那一側看，形式化的權限審查是最好的掩護：一個沒人用的帳號被主管簽了「保留」，就多了一季合法存在的理由。他不需要提權，只需要等一個本該被收回、卻沒人追的權限。

揭露：本文未受任何廠商贊助，提及的產品僅為舉例。