Oracle 存儲過程權限模型深度解析：定義者權限 vs 調用者權限、Role 生效邊界、動態 SQL 繞過編譯期檢查

存儲過程執行時權限檢查機制直接決定「能不能查別人的表、能不能用 Role 權限」。本文通過實測案例，徹底講透定義者權限、調用者權限的編譯期/運行期差異、Role 在 PL/SQL 中失效的根因、動態 SQL 推遲綁定繞過靜態權限檢查的原理與最佳實踐。

一、兩種權限模式對比

二、實測案例 1：定義者權限 + Role 失效

-- SYS 創建用戶並授權
GRANT CONNECT, RESOURCE TO u1 IDENTIFIED BY u1;
GRANT DBA TO u2 IDENTIFIED BY u2;  -- u2 有 DBA Role

-- U1 創建表
CONN u1/u1
CREATE TABLE t AS SELECT * FROM user_objects;

-- U2 嘗試創建過程刪除 U1 表
CONN u2/u2
CREATE OR REPLACE PROCEDURE p_test AS
BEGIN
  DELETE FROM u1.t;  -- 靜態 SQL，編譯期檢查 U2 對 u1.t 的直接授權
  COMMIT;
END;
/
-- 警告: Procedure created with compilation errors.
-- ORA-00942: table or view does not exist
-- 原因：U2 雖有 DBA Role，但定義者權限過程編譯期**不認 Role**，且無直接授權。

-- 解決：U1 直接授權
CONN u1/u1
GRANT ALL ON t TO u2;

-- U2 重新創建過程 → 成功
CONN u2/u2
CREATE OR REPLACE PROCEDURE p_test AS
BEGIN DELETE FROM u1.t; COMMIT; END;
/
-- Procedure created.

三、實測案例 2：調用者權限 + 動態 SQL 繞過編譯期檢查

-- 回收直接授權
CONN u1/u1
REVOKE ALL ON t FROM u2;

-- U2 創建調用者權限過程（靜態 SQL）
CONN u2/u2
CREATE OR REPLACE PROCEDURE p_test AUTHID CURRENT_USER AS
BEGIN
  DELETE FROM u1.t;  -- 編譯期不檢查，但運行期調用者 U2 仍無直接授權
  COMMIT;
END;
/
-- 警告: ORA-00942 at line 5 (運行期報錯)

-- 關鍵：改用動態 SQL，將權限檢查推遲到 EXECUTE IMMEDIATE 瞬間
CREATE OR REPLACE PROCEDURE p_test AUTHID CURRENT_USER AS
BEGIN
  EXECUTE IMMEDIATE 'DELETE FROM u1.t';  -- 運行期動態解析，調用者 U2 的 DBA Role 生效
  COMMIT;
END;
/
-- Procedure created.

EXEC p_test;  -- 成功執行
SELECT COUNT(*) FROM u1.t;  -- 0 行，數據已刪除

四、核心原理深度解析

1. 為什麼 PL/SQL 靜態 SQL 忽略 Role？

• PL/SQL 編譯器在編譯階段解析靜態 SQL，生成靜態游標，需確定對象權限。
• Role 是**運行期動態啟用**的（SET ROLE、密碼 Role、安全應用 Role），編譯期不可知。
• 為保證編譯後代碼**可移植、穩定**，Oracle 規定：靜態 SQL 僅認**直接授權**（GRANT obj_priv ON obj TO user）。

2. 調用者權限 + 動態 SQL 為什麼能用 Role？

• AUTHID CURRENT_USER 聲明運行期以調用者身份執行。
• EXECUTE IMMEDIATE / DBMS_SQL 在**運行期**動態解析、綁定、執行，此時調用者的 Session 已啟用 Role，權限檢查自然包含 Role。
• 本質：**推遲綁定** 將編譯期靜態檢查轉為運行期動態檢查。

3. 定義者權限過程中若需用 Role 怎麼辦？

• **不可行**。定義者權限過程運行期也用定義者身份，Role 永不生效。
• 替代方案：
  ① 將敏感操作剝離到**調用者權限**輔助過程（動態 SQL）。
  ② 定義者授予 **直接對象權限**（最安全、可審計）。
  ③ 使用 DBMS_SQL + AUTHID DEFINER 但以 SYS 身份運行（極度危險，禁用）。

五、最佳實踐與安全準則

1. 默認用定義者權限：封裝核心業務表操作，通過直接授權控制訪問，符合最小權限原則，便於審計。
2. 僅在以下場景用調用者權限 + 動態 SQL：
   • 通用工具過程（如「動態建表」、「跨 Schema 查詢」）。
   • 多租戶應用，同一代碼服務不同 Schema，依賴調用者權限隔離。
   • 需利用調用者已啟用的 Role（如 SELECT_CATALOG_ROLE 查字典）。
3. 動態 SQL 必須防注入：使用 DBMS_ASSERT.ENQUOTE_LITERAL、ENQUOTE_NAME、綁定變量（USING 子句），**嚴禁字符串拼接用戶輸入**。
4. 權限授予審計：定期查詢 DBA_TAB_PRIVS、DBA_ROLE_PRIVS，清理過期/過度授權。
5. 版本差異：12c+ 引入 BEQUEATH CURRENT_USER 視圖特性，類似調用者權限，可用於視圖層權限傳遞。

六、權限模型決策樹

IF 過程訪問固定表、需封裝邏輯、統一權限控制
    → 定義者權限 + 直接授權 (GRANT ON table TO proc_owner)
ELSE IF 過程需動態構建表名/列名/WHERE、跨 Schema 通用
    → 調用者權限 + 動態 SQL (EXECUTE IMMEDIATE USING ...)
ELSE IF 過程需調用者 Role 權限（如查字典、監控視圖）
    → 調用者權限 + 動態 SQL
ELSE
    → 定義者權限（默認安全選項）

徹底理解「編譯期靜態綁定 vs 運行期動態綁定、Role 只在運行期 Session 生效」這兩大鐵律，即可在複雜權限矩陣中游刃有餘地設計安全、可維護的存儲過程體系。