先建立身分清冊，不要只看 IAM 名單
服務帳號可能存在於雲端 IAM、地端 Active Directory、資料庫、ERP、CRM、LINE 串接、CI/CD 平台、排程器與第三方 SaaS。只匯出單一平台的帳號清單，通常看不到金鑰存放位置、實際呼叫來源與跨系統依賴。我們會把帳號、角色、API 金鑰、憑證與工作負載身分視為同一類資產，再將它們對應到執行中的服務、部署流程及資料流。
每個身分至少要回答誰負責、為何存在、在哪個環境使用、可存取哪些資源、如何驗證，以及最近何時出現可確認的活動。帳號名稱與建立者只能作為線索，不能當成用途證明；原建立者可能已離職，名稱也可能與目前工作負載不符。建議清冊保留以下欄位：
- 責任歸屬：業務系統、技術負責人與核准者，而非只有最初建立帳號的人。
- 執行脈絡：來源主機、容器、雲端函式、排程、部署管線與目標 API。
- 授權範圍：直接綁定角色、群組繼承、跨帳戶信任及資源層級政策。
- 驗證方式：長效金鑰、憑證、密碼、託管身分或工作負載聯邦。
- 使用證據：登入、權杖簽發、API 呼叫、資料庫連線及密鑰讀取紀錄。
判定閒置時，要區分沒有紀錄與沒有用途
「最近沒有登入」不代表服務帳號沒有被使用。許多機器身分透過權杖交換、角色承擔或資料庫憑證運作，不會留下傳統登入事件；月結、災難復原、憑證更新與年度批次也可能長時間沒有活動。盤點期間應涵蓋完整業務週期，並先確認各平台的日誌保留期。若日誌早已過期，只能標記為證據不足，不能直接判定為閒置。
安全的處置順序通常是先通知負責人並觀察，再阻擋新工作、停用憑證，最後才撤銷角色或刪除身分。變更前應保存政策、群組關係、金鑰識別碼與依賴清單，並設定明確的觀察期、監控告警及復原方式。對無法確認負責人的帳號，可先限制來源網路、禁止建立新金鑰，或降低高風險權限；這比立即刪除更能兼顧風險與營運連續性。
過度授權不能只靠實際使用紀錄判斷
活動日誌能指出帳號做過什麼，卻不能完整描述未來必須做什麼。某項權限近期沒有使用，可能是例外處理、故障切換或部署回復所需。因此，最小權限分析應同時比較實際 API 行為、應用程式碼與基礎設施設定、供應商文件、故障流程及資料敏感度。對高風險操作，例如修改 IAM、讀取全部密鑰、停用稽核或大量匯出資料，應要求特別明確的用途證據。
收斂時不要直接把管理員角色換成另一個仍然寬廣的預設角色。較穩健的方式是按工作拆分身分，例如將部署、執行、備份與監控分開，再限制資源、動作、來源環境與可承擔的角色。測試環境與正式環境也不應共用同一組憑證。若平台提供政策模擬、唯讀模式或拒絕事件分析，可先驗證新政策；無法模擬時，則以小範圍工作負載逐步切換，監看授權失敗與業務指標後再擴大。
把盤點變成持續控制，而非年度清理
一次性清理很快會失效，因為新整合、緊急修復與專案交接會持續產生服務身分。建立流程時，應要求新帳號具備負責人、用途、環境、到期或複查日期及預期權限；高權限變更必須留下核准與測試證據。人員離職、系統下線、應用程式改版、雲端帳戶重整及異常登入，則應自動觸發重新盤點，而不是等待固定週期。
技術面應優先採用短效權杖、託管身分或工作負載聯邦，減少散落在程式碼、設定檔與部署平台中的長效密鑰。仍需保留金鑰時，要集中存放、輪替並監控讀取行為。最終成果不只是刪掉多少帳號，而是每個高風險身分都能被解釋、被追蹤、被安全停用，且權限與當前工作負載保持一致。