比起刪除，停用 IAM 帳號為何是更安全的選擇？從系統可恢復性談帳號治理

在資訊系統的權限管理中，處理離職員工或停用專案的帳號時，最直覺的動作就是「刪除」。這個選項看似乾淨俐落，能徹底移除存取權限，但從系統安全（systems safety）與可恢復性（recoverability）的角度來看，這其實是一種脆弱且高風險的操作。一個成熟的系統設計，尤其在身分與存取管理（IAM）的領域，追求的不應是無法挽回的「清除」，而是可追溯、可恢復且可審計的退場機制。我認為，採用邏輯刪除（停用帳號）而非物理刪除，才是降低因人為疏失或需求變更所導致災難性後果的根本之道。

為什麼「刪除」帳號看似誘人，卻隱藏著巨大風險？

在許多團隊的標準作業程序（SOP）中，刪除閒置帳號被視為一種安全衛生的好習慣。這背後的邏輯很簡單：不存在的帳號，自然就沒有被盜用或濫用的風險。然而，這種「眼不見為淨」的思維模型，忽略了系統在真實世界中運作的複雜性。物理刪除一個 IAM User，意味著與該使用者相關的所有配置，包括權限策略（policies）、群組歸屬、以及獨一無二的識別碼（User ID），都將永久消失。

這種操作的不可逆性，帶來了幾個嚴峻的挑戰：

首先，恢復成本極高。如果刪除是個錯誤，或該員工在短時間內回任，我們無法「還原」這個使用者。重建一個權限完全相同的帳號，過程繁瑣且極易出錯，特別是在複雜的權限結構下。遺漏任何一個細微的權限設定，都可能導致新帳號無法正常工作，或是在未來引發難以追查的問題。

其次，審計軌跡將中斷。使用者的唯一識別碼一旦消失，日後要追溯該使用者過去的行為將變得極為困難。即使 AWS CloudTrail 等日誌服務記錄了操作，但這些紀錄所關聯的主體（principal）已不復存在，使得安全審計或事件調查的完整性大打折扣。

再者，還會產生潛在的「幽靈權限」問題。在某些資源策略（resource-based policies）中，可能會直接參照特定 IAM User 的 ARN。刪除該 User 後，這些策略中的參照並不會自動失效，而是成為指向空殼的「懸空指標」（dangling pointer），這不僅造成管理上的混亂，也可能在未來建立同名帳號時，意外繼承了不應有的權限。

為什麼邏輯刪除是更具韌性的策略？

相較於直接刪除，採取「停用」或稱「邏輯刪除」的作法，是更為穩健的帳號治理模式。這代表我們僅僅是撤銷該帳號的所有登入與存取能力，但保留其存在與歷史紀錄。在 AWS IAM 的實踐中，這可以透過幾個簡單步驟達成：

1. 禁用控制台密碼（Console password）：移除該使用者的手動登入能力。當密碼被禁用後，即使未來重新啟用，也必須強制設定一組新密碼，確保了安全性。
2. 停用所有存取金鑰（Access Key）：將該使用者所有 programmatic access 的金鑰狀態設為「Inactive」。這會立即阻斷所有透過 API、CLI 或 SDK 發出的請求。

這種做法的核心優勢，在於它是一種非破壞性（non-destructive）操作。帳號的實體、歷史、權限配置都還在，只是暫時處於「休眠」狀態。這完全符合系統可恢復性設計（Designing for Recoverability）的核心原則：系統應能從故障或錯誤中優雅地恢復，而非造成永久性資料損失。將帳號刪除比喻成 git push --force，它強行改寫歷史；而停用帳號則像是建立一個可以隨時合併回來或安全廢棄的獨立分支。

在複雜系統中，可逆操作永遠比不可逆操作更安全。帳號治理的目標是管理風險，而非單純地消除物件。

如何建立安全的帳號退場機制？

一個完整的帳號退場（offboarding）流程，不應只是權限的移除，而應是一套結合了審計、停用、觀察與最終清理的程序。我建議的流程如下：

首先，在採取任何動作前，務必進行使用狀況審計。利用 IAM Access Advisor 來檢視該帳號在過去一段時間內（例如 90 天）實際使用了哪些服務與權限。同時，搭配 CloudTrail 檢查其最近的活動紀錄。這一步驟是為了確保停用該帳號不會對現有自動化流程或關鍵服務造成非預期的中斷。

接著，執行前述的停用程序：禁用主控台密碼並停用所有存取金鑰。完成後，為該帳號附加一個明確的標籤（Tag），例如 status:disabled 或 disabled_date:2026-07-05，以便於後續的管理與篩選。

最後，建立一個「帳號冷卻期」或「隔離期」政策。例如，所有被停用的帳號將被保留至少 180 天。在這段期間內，如果發現任何問題或需要恢復帳號，管理者只需重新啟用金鑰並設定新密碼即可，整個過程不到一分鐘。待冷卻期過後，若確認該帳號已無任何恢復的必要，再執行物理刪除。這個最終步驟，確保了系統的長期整潔，也為不可逆的操作提供了足夠的緩衝。

這種分階段的退場機制，不僅適用於 AWS，更是所有身分驗證系統（如 Google Workspace、企業內部 AD）都應採納的通用原則。它體現了美國國家標準暨技術研究院（NIST）所強調的存取控制生命週期管理精神，從根本上提升了系統的韌性與安全性。

延伸閱讀

• Classmethod Developers Blog: IAM User 的邏輯刪除
• AWS Identity and Access Management (IAM) User Guide
• Google SRE Book: Handling Overload (Chapter 21) - 雖然主題是過載，但其中「優雅降級」的理念與邏輯刪除的精神相通。
• Martin Fowler's Blog: Soft Delete - 探討在資料庫層級實現邏輯刪除的模式與優劣。

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。