最小權限原則，詳解

最小權限原則說出來顯而易見：只給帳戶、流程或使用者完成工作所需的存取權限，不多不少。在說和實際執行之間的差距，是大多數漏洞從小事件演變成完整網域被破壞的地方。

它實際的含義

最小權限原則（PoLP）指出系統中的每個主體—使用者、服務帳戶、應用程式、容器—都應該以完成其功能所需的最小權限集執行。不是方便的權限。不是某人三年前授予後就忘記撤銷的權限。是最小的。

這適用於每一層：檔案系統權限、資料庫角色、API 範圍、雲端 IAM 政策、防火牆規則、sudo 存取。讀取靜態檔案的網頁伺服器流程不需要對 /etc 的寫入存取。只執行 SELECT 查詢的報告指令碼不需要擁有 DROP TABLE 權限的資料庫角色。行銷實習生不需要網域管理員，只是因為這比搞清楚正確的群組更容易。

為什麼它的重要性比聽起來的還大

當攻擊者破壞帳戶或流程時，他們繼承該帳戶可以執行的任何操作。如果一位被釣魚的員工的筆記型電腦只能存取與其團隊相關的檔案共享，該釣魚攻擊的影響範圍就被限制了。如果該帳戶碰好有網域管理員權限，因為 IT 曾經為了疑難排解而設定過，從未撤銷，攻擊者現在擁有整個網路。

這是大多數漏洞後取證報告背後的邏輯：初始存取價值不高，但通過權限過多的帳戶進行的橫向移動將其變成了整個環境的勒索軟體。過度權限不會導致初始漏洞，但幾乎總是讓漏洞變得昂貴的原因。

它在實務中如何出現

雲端 IAM。 如果不小心，AWS、Azure 和 GCP 都預設為寬鬆行為—"Action": "*" 和 "Resource": "*" 的 IAM 政策會通過驗證且工作正常，直到洩露的存取金鑰將完全帳戶控制權交給攻擊者。改為將政策限定於特定操作和資源 ARN，而不是使用萬用字元。

服務帳戶。 這些通常是最嚴重的違規者，因為沒人像審查人類帳戶那樣審查它們。部署到一個 S3 儲存桶的 CI/CD 管線不應該持有可以讀取帳戶中每個儲存桶的認證。

資料庫角色。 將唯讀報告角色與需要 INSERT/UPDATE 的應用程式角色分開，並將其與可以更改結構的 DBA 角色分開。PostgreSQL 和 MySQL 都支援細粒度的 GRANT 陳述式—使用它們而不是給每個應用程式連線等同於 root 的權限。

Sudo 和本機管理員。 及時提升權限（要求存取、在有限時間內獲得、自動失去）總是比持續管理員權限更好。sudo 搭配時間限制規則或企業環境中的 PAM 解決方案等工具，就是為此而存在。

與