在前幾天，我們討論了資安黃金三要素CIA以及針對「人」的社交工程攻擊。今天，我們要探討系統內部最常被忽視、卻也是資安事故中危害最嚴重的技術漏洞之一——存取控制缺陷與過度授權。

在 OWASP Top 10 的排名中，權限控管失效一直榜上有名。許多系統表面上防護嚴密，但內部權限卻一團混亂，導致攻擊者一旦進入內網或取得一個低權限帳號，就能控制整台伺服器。

什麼是過度授權與最小權限原則？

舉個例子 : 假設今天請了一位清潔工，你希望他只幫你打掃客廳，但你卻給了他房間、保險箱、車庫的鑰匙讓他可以隨意進出。這就是「過度授權」。

在資訊安全中，除了前幾天介紹的「CIA」以外，有一個黃金法則叫做最小權限原則（PoLP）：任何使用者、程式或服務，應該只被賦予「完成其工作所必需」的最小存取權限，不多也不少。以上面的例子來說，你希望清潔工只幫你打掃客廳那就只能給他大門的鑰匙且其他地方的門要鎖緊而不是把所有的鑰匙給他，讓他可以隨意進出。

當 PoLP 失效時，就會產生兩大極具威脅的風險：

• 過度授權： 普通使用者擁有了管理員權限，或後端服務使用了 root / sa 帳號連接資料庫。

• 特權帳號管理失控： 萬用帳號（如雲端的主帳號 Root Account、Linux 的 root）沒有特殊保護，甚至密碼寫死在程式碼中。

過度授權如何破壞 CIA？

當過度授權發生時，系統的防禦縱深（Defense-in-Depth）會完全崩潰：

1. 機密性與完整性完全失守 (C / I)：
若應用程式用 root 存取資料庫，當發生 SQL Injection 漏洞時，攻擊者就不只是能讀取單一資料表，而是能讀取所有資料庫、刪除資料表，甚至透過資料庫執行作業系統指令。

2. 爆炸半徑（Blast Radius）無限擴大：
如果維運人員將伺服器上的 SSH 金鑰權限開很大，一旦其中一台伺服器被入侵，攻擊者就能拿著金鑰「橫向移動（Lateral Movement）」直接控制全公司所有伺服器。

實務情境

情境 A：應用程式連線資料庫權限

過度授權

# Web 應用程式直接使用 root 帳號連線資料庫
DB_USER = "root"
DB_PASS = "SuperAdminPassword123"

# 只要這裡發生 SQL Injection 或漏洞，攻擊者具備DROP DATABASE或讀取系統檔案的完全權限

最小權限原則

-- 在資料庫建立專屬的應用程式帳號，並僅給予特定資料庫的CRUD權限
CREATE USER 'app_web_user'@'10.0.1.%' IDENTIFIED BY 'StrongRandomPassword!';
GRANT SELECT, INSERT, UPDATE, DELETE ON company_db.* TO 'app_web_user'@'10.0.1.%';
-- 避免賦予DROP, ALTER, FLUSH 或 GRANT權限！

情境 B：API 路由權限控管 (RBAC 失效)

未檢查角色的垂直越權

// 只檢查使用者是否登入，卻沒有驗證角色權限 (Role-Based Access Control)
app.post('/api/v1/delete-user', authenticateToken, (req, res) => {
    // 只要帶有有效 Token 的一般使用者，就能呼叫這個刪除使用者的 API！
    const userId = req.body.userId;
    deleteUserFromDB(userId);
    res.send({ status: "Success" });
});

嚴格實施角色授權中間件

// 明確要求管理員權限
app.post('/api/v1/delete-user', authenticateToken, requireRole('ADMIN'), (req, res) => {
    const userId = req.body.userId;
    deleteUserFromDB(userId);
    res.send({ status: "Success" });
});

如何正確修復與落實特權帳號管理？

要避免過度授權引發的災難，開發與維運團隊應落實以下架構：

1. 實施基於角色的存取控制 (RBAC) 與屬性存取控制 (ABAC)

• RBAC (Role-Based Access Control - 基於角色的存取控制)
  系統先定義好不同的系統先定義好不同的角色（Role）與對應的權限集合，再將使用者分配給特定角色。這是現代軟體系統中最常見的權限設計模式。

• ABAC (Attribute-Based Access Control - 基於屬性的存取控制)
  技術原理：根據使用者的屬性(Attribute，如:部門、職級）、資源屬性（資料敏感度）、環境屬性（IP、時間、地理位置）等動態條件，來決定是否放行存取。

2. 雲端環境（AWS / GCP / Azure）的 IAM 最佳實踐

• 停用 Root 帳號日常使用： 主帳號僅用於開戶與計費，日常維運建立獨立的 IAM Users 或使用 Single Sign-On (SSO)。
• 避免萬用字元授權： IAM Policy 中嚴禁出現 "Action": "" 或 "Resource": "" 的設定。

3. 實施「即時授權」

• 維運人員平日不保留生產環境的高階管理權限。
• 當需要進行系統維護時，透過 PAM（特權帳號管理系統）申請臨時權限（如：2 小時內有效的 Token），並全程紀錄操作 Log。

專有名詞解釋
Blast Radius（爆炸半徑 / 損害範圍）： 用來衡量一個資安漏洞或帳號遭破壞後，會影響到系統中多少資產。如果發生過度授權，一個小小 API 被打穿就會導致「爆炸半徑」擴大到整座資料庫。

IAM - Identity and Access Management（身份與存取管理）： 雲端架構（如 AWS / GCP / Azure）的核心資安元件，用來管理誰可以對哪些雲端資源執行什麼操作。

PAM - Privileged Access Management（特權帳號管理）： 針對高風險的特權帳號（如 root、admin）進行專門監控、密碼定期輪替與操作側錄的資安系統。

Just-In-Time Access, JIT Access（即時授權 / 臨時權限）： 貫徹「零信任（Zero Trust）」。平時維運人員零特權，當需要處理故障時才動態申請具備時效性的高階權限。