PL/SQLのストアドプロシージャやファンクションは、デフォルトでは「作成者の権限」で実行されます。これをDefiner Rights（定義者権限）と呼びます。一方でInvoker Rights（呼び出し者権限）を指定すると、実行時に呼び出したユーザーの権限で動作します。どちらを選ぶかによってセキュリティモデルやスキーマ設計が大きく変わります。ここでは両者の違いと実務での使い分け方を解説します。
Definer Rights（定義者権限）の基本
デフォルトの挙動はDefiner Rightsです。オブジェクトを作成したスキーマの権限でSQLが評価され、所有者がアクセス可能な表やビューに対して処理を行えます。
CREATE OR REPLACE PROCEDURE p_show_emp IS
BEGIN
FOR r IN (SELECT empno, ename FROM employees) LOOP
DBMS_OUTPUT.PUT_LINE(r.empno || ':' || r.ename);
END LOOP;
END;
/
この場合、呼び出したユーザーがemployees表に権限を持っていなくても、作成者が権限を持っていれば処理は成功します。セキュリティ上は便利ですが、予期せぬ特権利用を許す場合があります。
Invoker Rights（呼び出し者権限）の指定
Invoker RightsはAUTHID CURRENT_USERを付けて宣言します。すると、実行時に呼び出したユーザーの権限が適用されます。
CREATE OR REPLACE PROCEDURE p_show_emp_ir
AUTHID CURRENT_USER IS
BEGIN
FOR r IN (SELECT empno, ename FROM employees) LOOP
DBMS_OUTPUT.PUT_LINE(r.empno || ':' || r.ename);
END LOOP;
END;
/
この場合、呼び出したユーザーがemployees表にSELECT権限を持っていなければエラーになります。逆に、利用者の権限でアクセス制御できるため、マルチスキーマ環境やライブラリ的利用に適しています。
違いの整理
| 項目 | Definer Rights | Invoker Rights |
|---|---|---|
| 宣言 | デフォルト（AUTHID DEFINER） | AUTHID CURRENT_USER |
| 実行権限 | 作成者の権限 | 呼び出し者の権限 |
| 主用途 | 業務アプリ固有の処理、特権カプセル化 | ライブラリ提供、マルチテナント環境 |
| セキュリティ | 呼び出し者に権限がなくても実行可（危険性あり） | 呼び出し者の権限が不足すれば失敗（安全） |
実務での使い分け
- Definer Rights：アプリケーションスキーマが持つ表を隠蔽し、APIだけを公開したいときに有効。呼び出しユーザーに直接表の権限を与えずに済みます。
- Invoker Rights：共通ライブラリやユーティリティ的な処理を提供し、どのスキーマからも同じコードを使わせたい場合に有効。呼び出しユーザーごとの権限制御を反映できます。
注意点
Invoker Rightsで書かれたコードの中からDefiner Rightsのコードを呼ぶと、権限解決の切り替えが発生します。どの権限で実行されているかを意識しないと予期せぬエラーやセキュリティホールにつながります。また、ビューやシノニム経由のアクセスではオブジェクト名解決が呼び出し者基準になるため、完全修飾名（スキーマ.オブジェクト）を明示するのが安全です。
まとめ
Definer RightsとInvoker Rightsは、どのユーザー権限でコードを実行するかを制御する仕組みです。Definer Rightsはデフォルトで便利ですが、過剰権限を与えるリスクがあります。Invoker Rightsは安全で柔軟ですが、呼び出し者に権限を付与する管理が必要です。利用シーンを整理し、セキュリティと利便性のバランスを意識した設計が求められます。
