❄️

Snowflakeアクセス制御(RBAC)入門

に公開
Database
Security
Snowflake
rbac
DataGovernance
tech

🚀 はじめに

直近でSnowflakeのアクセス制御関連の設計を実施する必要が出てきたので、Snowflakeドキュメントの内容を整理をした上で記事にしてみました。
ある種自分自身のメモ代わりでもあるので、内容に間違いなどがあるかもしれませんがそこはご理解いただいた上で購読をお願いします！
(今後も加筆修正していく可能性はあるかもです)

早速内容に入っていきますが、Snowflakeはその柔軟性とスケーラビリティで多くの企業に採用されていますが、そのパワーを安全に活用するためにはアクセス制御の理解が不可欠となります。Snowflakeは**ロールベースアクセス制御（RBAC）**を基本としており、「誰が」「どのデータに」「何ができるか」を柔軟かつ厳密に管理できます。

しかし、「権限が付与されているはずなのにSELECTできない」「新しいテーブルだけアクセス権がない」「管理が煩雑になってきた」といった悩みが構築などを進めていく上で必ずといっていいほど出てくるものかと思います。

この記事では、Snowflake RBACの基本要素から、ロール階層、セカンダリロール、所有権といった重要な概念、そして実運用で役立つベストプラクティスまで、公式ドキュメントに基づき体系的に整理をしてみました。

1. 基本要素：ユーザー、ロール、権限、オブジェクト

Snowflakeのアクセス制御は、以下の要素で構成されます。

  • ユーザー (User): Snowflakeにログインする個人またはアプリケーション。
  • ロール (Role): 権限の集合体。ユーザーや他のロールに付与されます。Snowflakeには大きく2種類のロールがあります。
    • アカウントロール (Account Role): アカウント全体で有効なロール（例: SYSADMIN, CUSTOM_ROLE）。アカウント横断のポリシー設定、Warehouse/Database作成、オブジェクト所有などに使われます。
    • データベースロール (Database Role): 特定のデータベース内でのみ有効なロール。当該DB内オブジェクトに対しては OWNERSHIP を含む権限を付与可能（＝オブジェクト所有者になれる）。ただし、DB本体の OWNERSHIP はアカウントロールのみが保持できます。DB内の権限管理の委任やカプセル化、データ共有での権限細分化に有用です。また、DBロールはセッションで直接有効化できないため、アカウントロールに付与して利用します。
  • 権限 (Privilege): 特定のオブジェクトに対して実行できる操作（例: SELECT on Table, USAGE on Warehouse）。
  • オブジェクト (Object): 権限が付与される対象（例: Table, View, Schema, Database, Warehouse）。

2. RBACの仕組み：権限 → ロール → ユーザー

Snowflake RBACの基本原則はシンプルです。

  1. 権限をロールに付与 (GRANT Privilege TO ROLE): オブジェクトに対する操作権限（例: SELECT）をロール（例: SALES_READ_ROLE）に付与します。
  2. ロールをユーザーに付与 (GRANT ROLE TO USER): 権限が付与されたロールをユーザー（例: BOB）に付与します。

これにより、Bobは SALES_READ_ROLE が持つ権限を行使できるようになります。

-- UBACの例 (非推奨。RBACを標準とすべき)
GRANT USAGE ON WAREHOUSE BI_WH TO USER BOB;
GRANT USAGE ON DATABASE SALES_DB TO USER BOB;
GRANT USAGE ON SCHEMA SALES_DB.PUBLIC TO USER BOB; -- スキーマUSAGEも必要
GRANT SELECT ON TABLE SALES_DB.PUBLIC.SALES_TABLE TO USER BOB;

-- RBACの推奨例 (再掲)
GRANT USAGE ON WAREHOUSE BI_WH TO ROLE FR_DATA_ANALYST;
GRANT ROLE FR_DATA_ANALYST TO USER BOB;

ロール階層：ロールをロールに付与

Snowflakeでは、ロールを他のロールに付与 (GRANT ROLE ... TO ROLE) することで、ロール階層を作成できます。これにより、権限の集約と継承が可能になります。

  • アカウントロール階層: アカウントロールは他のアカウントロールに付与できます。

    -- SALES_DBのREAD権限を持つアクセスロール
CREATE ROLE AR_SALES_READ;
GRANT USAGE ON DATABASE SALES_DB TO ROLE AR_SALES_READ;
GRANT USAGE ON SCHEMA SALES_DB.PUBLIC TO ROLE AR_SALES_READ;
GRANT SELECT ON ALL TABLES IN SCHEMA SALES_DB.PUBLIC TO ROLE AR_SALES_READ;

-- データアナリスト向けの機能ロール
CREATE ROLE FR_DATA_ANALYST;

-- 機能ロールにアクセスロールを付与（継承）
GRANT ROLE AR_SALES_READ TO ROLE FR_DATA_ANALYST;

-- ユーザーには機能ロールのみを付与
GRANT ROLE FR_DATA_ANALYST TO USER BOB;

  • データベースロール (Database Roles) の扱い

    • スコープ: 特定のデータベース内。
    • 同一データベース内で他のデータベースロールに付与してロール階層を作成可能（別DBへの付与は不可）。
    • アカウントロールへ付与して利用する（データベースロールを直接セッションで有効化することはできない）。
      -- 例：DBロールをアカウントロールに付与して利用
GRANT DATABASE ROLE sales_db.db_reader_role TO ROLE FR_DATA_ANALYST;
    • オブジェクトの所有者にはなれます（DB内オブジェクトのみ）。

3. セッションとロール：プライマリ vs セカンダリ

ユーザーがSnowflakeに接続すると、セッションが開始されます。各セッションには1つのプライマリロールと、複数のセカンダリロール（任意）が割り当てられます。

  • プライマリロール: セッションのデフォルトロール。DDL/DML実行時のデフォルト権限や、オブジェクト作成時の所有者を決定します。
  • セカンダリロール: プライマリロールに加えて、追加で有効化できるロール群。主にオブジェクトへのアクセス権限（例: SELECT）を行使するために使います。

セッション中に USE ROLE <role_name>; でプライマリロールを切り替えたり、以下のコマンドでセカンダリロールを有効化/無効化できます。

-- 有効化（すべて）
USE SECONDARY ROLES ALL;
-- 有効化（リスト指定 - 例）
USE SECONDARY ROLES FR_DATA_ANALYST, AR_SALES_READ;
-- 無効化
USE SECONDARY ROLES NONE;

Tip: 既定セカンダリロールの設定
ALTER USER ... SET DEFAULT_SECONDARY_ROLES = ('ALL' | <role_list> | 'NONE'); を設定すると、ユーザーがログインした際に指定したセカンダリロールが自動で有効になり、毎回 USE SECONDARY ROLES を実行する手間が省けます。

-- ユーザーBOBのデフォルトセカンダリロールを全て有効にする
ALTER USER BOB SET DEFAULT_SECONDARY_ROLES = ('ALL');

-- 確認 (セッション開始後)
SELECT CURRENT_ROLE(), CURRENT_SECONDARY_ROLES();

4. 重要な権限：USAGE, SELECT, OWNERSHIP

数ある権限の中でも、特に重要なものを理解しましょう。

USAGE 権限：「そこを通る/使う」ための通行証

コンテナオブジェクト（Database, Schema）やWarehouse（以下 WH）に対する基本的な権限です。「中を見る」権限ではなく、「そのコンテナの中にあるオブジェクトにアクセスするため」や「そのWHを使うため」の前提となる権限です。[1]

SELECT 権限：「中を見る」ための閲覧権

テーブルやビューなどのデータを読み取るための権限です。

SELECTまでの権限チェーン：「三段ロック + WH」（プライマリ＋セカンダリの合算で満たせばOK）

ユーザーがオブジェクトにアクセス（例: SELECT）できるようになるには、セッションで有効化されているロール（プライマリ＋セカンダリ）の権限を合算して、以下のすべての権限を満たしている必要があります。

  1. USAGE on Database
  2. USAGE on Schema
  3. 対象オブジェクトへの権限（例: SELECT on Table, USAGE on Function）
  4. USAGE on WH （クエリ実行時） ※ステージ操作(LIST/GET)を除く

権限チェーン早見表（プライマリ＋セカンダリの合算で満たせばOK）:

操作 必要権限
テーブル SELECT DB:USAGE / Schema:USAGE / Table:SELECT / WH:USAGE
ビュー SELECT DB:USAGE / Schema:USAGE / View:SELECT / WH:USAGE
プロシージャ CALL DB:USAGE / Schema:USAGE / Procedure:USAGE / WH:USAGE
関数（UDF）を使用 DB:USAGE / Schema:USAGE / Function:USAGE / WH:USAGE
マテリアライズドビュー SELECT DB:USAGE / Schema:USAGE / MV:SELECT / WH:USAGE
ステージ LIST (内部ステージ) (WH不要) DB:USAGE / Schema:USAGE / Stage:READ
ステージ LIST (外部・統合あり) (WH不要) DB:USAGE / Schema:USAGE / Stage:USAGE / Storage Integration:USAGE
ステージ GET (内部のみ) (WH不要) DB:USAGE / Schema:USAGE / Stage:READ 
-- 例：データアナリストロールに必要な最小権限セット (テーブルSELECT)
GRANT USAGE ON DATABASE SALES_DB TO ROLE FR_DATA_ANALYST;
GRANT USAGE ON SCHEMA SALES_DB.PUBLIC TO ROLE FR_DATA_ANALYST;
GRANT SELECT ON TABLE SALES_DB.PUBLIC.SALES_TABLE TO ROLE FR_DATA_ANALYST;
GRANT USAGE ON WAREHOUSE BI_WH TO ROLE FR_DATA_ANALYST;

よくあるエラーと不足権限 (Troubleshooting):

エラーメッセージ 不足している可能性のある権限 確認コマンド例
SQL access control error: Insufficient privileges to operate on schema ... Schema USAGE SHOW GRANTS ON SCHEMA <db>.<schema>;
Cannot perform SELECT. Privilege not granted. オブジェクト権限 (SELECT等) SHOW GRANTS ON TABLE <db>.<schema>.<table>;
Warehouse ... does not exist or not authorized. WH USAGE SHOW GRANTS ON WAREHOUSE <wh_name>;
Insufficient privileges to operate on warehouse ... WH USAGE / OPERATE 等 SHOW GRANTS ON WAREHOUSE <wh_name>;
Insufficient privileges to operate on task ... Task OWNERSHIP / OPERATE SHOW GRANTS ON TASK <db>.<schema>.<task>;
Object does not exist or not authorized Schema USAGE 欠落が多い SHOW GRANTS ON SCHEMA <db>.<schema>;

OWNERSHIP 権限：「持ち主」としての絶対権限

オブジェクトの所有権です。オブジェクトを作成したロール（通常はセッションのプライマリロール）に自動的に付与されます。所有者はそのオブジェクトに対する全ての権限（DROP, ALTER, GRANT など）を持ちます。

  • 注意: カスタムロールが作成したオブジェクトは、たとえ ACCOUNTADMIN であっても直接変更・削除できません。そのオブジェクトの OWNERSHIP を持つロール、またはそのロールが（階層を通じて）付与された上位ロールを使用する必要があります。
  • 移譲: GRANT OWNERSHIP ON <object_type> <object_name> TO ROLE <new_owner_role> [REVOKE CURRENT GRANTS | COPY CURRENT GRANTS]; で所有権を移譲できます。
    • 重要: 既定（REVOKE CURRENT GRANTS）では、移譲時に既存の権限付与がリセットされます。既存の権限を維持したい場合は COPY CURRENT GRANTS を必ず指定しましょう。

5. 特殊なロール：システム定義ロール

Snowflakeには事前に定義された強力なロールがあります。これらの役割を理解し、適切に使用することが重要です。

  • ACCOUNTADMIN: アカウント全体の最高権限。日常的な作業での使用は避けるべきです。
  • SECURITYADMIN: ユーザーとロールの管理（MANAGE GRANTS 権限を含む）。
  • USERADMIN: ユーザーとロールの作成・管理（権限付与は不可）。SECURITYADMIN に継承させることが推奨されます。
  • SYSADMIN: WHやDatabaseなどのオブジェクト作成・管理権限。日常的なインフラ管理はこのロールで行うのが一般的です。
  • PUBLIC: 全てのユーザーに自動的に付与されます。このロールに付与された権限は、意図せず全員に公開されるため、付与する権限は最小限にすべきです。

Tip: PUBLICロールの点検クエリ
意図しない権限が付与されていないか、定期的に確認しましょう。

-- PUBLIC ロールに直接付与されている権限を確認
SHOW GRANTS TO ROLE PUBLIC;

-- PUBLIC ロール経由でアクセス可能なオブジェクトを確認 (ACCOUNT_USAGE利用例)
-- (ACCOUNT_USAGEへのアクセス権限が必要です)
-- SELECT *
-- FROM SNOWFLAKE.ACCOUNT_USAGE.GRANTS_TO_ROLES
-- WHERE ROLE = 'PUBLIC'
-- AND GRANTED_BY IS NOT NULL -- Snowflake内部付与を除く
-- ORDER BY CREATED_ON DESC;

6. 権限管理のベストプラクティス

効率的で安全な権限管理のための推奨事項です。

機能ロール vs アクセスロール

ロール階層を活用し、役割を分離します。

  • アクセスロール (AR_*): 特定のオブジェクトセット（例: SALES_DBの全テーブルへのREAD権限）に対する権限のみを持つロール。
  • 機能ロール (FR_*): 特定の職務（例: データアナリスト）に対応するロール。ユーザーにはこのロールを付与し、必要なアクセスロールを機能ロールに継承させます。

これにより、ユーザー管理（機能ロールの付与/剥奪）と権限管理（アクセスロールへの権限追加/削除）を分離でき、管理が容易になります。

-- アクセスロール: 営業DBのRead専用
CREATE ROLE AR_SALES_READ;
GRANT USAGE  ON DATABASE sales_db        TO ROLE AR_SALES_READ;
GRANT USAGE  ON SCHEMA   sales_db.public TO ROLE AR_SALES_READ;
GRANT SELECT ON ALL TABLES  IN SCHEMA sales_db.public TO ROLE AR_SALES_READ;
GRANT SELECT ON FUTURE TABLES IN SCHEMA sales_db.public TO ROLE AR_SALES_READ;

-- 機能ロール: データアナリスト
CREATE ROLE FR_DATA_ANALYST;
GRANT ROLE AR_SALES_READ TO ROLE FR_DATA_ANALYST;

-- 実行用WHへの権限
GRANT USAGE ON WAREHOUSE bi_wh TO ROLE FR_DATA_ANALYST;

-- ユーザーへは機能ロールのみを付与
GRANT ROLE FR_DATA_ANALYST TO USER data_analyst_bob;

Future Grants：新規オブジェクトへの自動権限付与

新しいテーブルやビューが作成されるたびに GRANT 文を実行するのは手間がかかり、権限付与漏れの原因にもなります。FUTURE GRANTS を使うと、スキーマ内に将来作成される特定の種類のオブジェクトに対して、自動的に権限を付与できます。

-- 既存テーブルへのSELECT権限
GRANT SELECT ON ALL TABLES IN SCHEMA SALES_DB.PUBLIC TO ROLE AR_SALES_READ;
-- 将来作成されるテーブルへのSELECT権限
GRANT SELECT ON FUTURE TABLES IN SCHEMA SALES_DB.PUBLIC TO ROLE AR_SALES_READ;

-- ビューに対しても同様
GRANT SELECT ON ALL VIEWS IN SCHEMA SALES_DB.PUBLIC TO ROLE AR_SALES_READ;
GRANT SELECT ON FUTURE VIEWS IN SCHEMA SALES_DB.PUBLIC TO ROLE AR_SALES_READ;

-- 関数やプロシージャにも忘れずに (例: USAGE権限)
GRANT USAGE ON FUTURE FUNCTIONS IN SCHEMA SALES_DB.PUBLIC TO ROLE FR_DATA_ANALYST;
GRANT USAGE ON FUTURE PROCEDURES IN SCHEMA SALES_DB.PUBLIC TO ROLE FR_DATA_ANALYST;

ALL (既存) と FUTURE (将来) をセットで使うのが定石です。FUTURE はオブジェクト種別ごと（TABLES, VIEWS, MATERIALIZED VIEWS, STREAMS, TASKS, FUNCTIONS, PROCEDURES など）に設定が必要です。特に FUNCTIONS や PROCEDURES の権限付与忘れに注意しましょう。新規スキーマ作成時には、そのスキーマに対するFUTURE設定も運用手順に含めることが重要です。

Managed Access Schema：権限管理の一元化

通常、テーブルやビューへの権限付与（GRANT）は、そのオブジェクトの所有者（OWNERSHIP を持つロール）が行います。WITH MANAGED ACCESS を指定して作成されたスキーマでは、オブジェクト作成者（所有者）であっても権限付与はできず、**“スキーマ所有者（または MANAGE GRANTS を持つロール）のみ”**が付与できます。

-- Managed Access Schemaを作成 (実行はSYSADMINなど上位ロール)
USE ROLE SYSADMIN;
CREATE SCHEMA SALES_DB.MANAGED_SCHEMA WITH MANAGED ACCESS;

-- スキーマ所有ロール(例: SCHEMA_ADMIN_ROLE)に切り替えて権限付与
USE ROLE SCHEMA_ADMIN_ROLE;
GRANT SELECT ON TABLE SALES_DB.MANAGED_SCHEMA.SOME_TABLE TO ROLE AR_SALES_READ;
GRANT SELECT ON FUTURE TABLES IN SCHEMA SALES_DB.MANAGED_SCHEMA TO ROLE AR_SALES_READ;

これにより、権限の棚卸しや一括変更が容易になります。運用手順上、スキーマ所有ロールの指定と権限申請フローを用意しましょう。

PUBLICロールの最小権限化 (再掲)

意図しない情報公開を防ぐため、PUBLIC ロールには基本的に権限を付与しないようにします。

アカウント管理ロールの適切な使用 (再掲)

ACCOUNTADMIN の使用は最小限に留め、日常的な管理は SYSADMIN や SECURITYADMIN (またはそれらを継承したカスタムロール) を中心に行います。

7. データ共有と権限

Snowflakeの強力な機能であるSecure Data Sharingを利用する際の権限管理です。

共有DBとIMPORTED PRIVILEGES

共有されたデータベース（例: SNOWFLAKE データベースや、他のアカウントから共有されたDB）内のオブジェクトにアクセスするには、その共有データベースに対する IMPORTED PRIVILEGES という特別な権限をロールに付与する必要があります。

-- SNOWFLAKEデータベース (ACCOUNT_USAGEなど) へのアクセス権を付与
GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE FR_DATA_ANALYST;

注意: IMPORTED PRIVILEGES はデータベース全体に付与され、スキーマやオブジェクト単位で絞り込むことはできません。

共有におけるデータベースロール活用

データベースロールはデータ共有時の権限管理にも有効です。

データ共有 × DBロールの流れ（超要点）:

  1. 提供者: 共有したいオブジェクト群にDBロールへ読み取り系権限を付与 \rightarrow シェアにDBロールを追加。
  2. 消費者: 共有DBから読み取り専用DBを作成 \rightarrow そのDB内のDBロールを自アカウントのアカウントロールへ付与。
  3. 利用: アカウントロールを有効化してクエリ。

8. 高度なトピック

実行コンテキスト（Task / Procedure）注意

Taskやストアドプロシージャがどのロールの権限で実行されるかは重要です。権限評価主体が異なると、意図しない権限不足や過剰権限につながる可能性があります。

  • Task: タスク所有者（OWNERSHIPを持つロール）の権限で実行されます。所有権移譲やロール構成変更時に権限不足にならないか注意が必要です。
  • ストアドプロシージャ: EXECUTE AS CALLER（呼び出し元の権限）または EXECUTE AS OWNER（プロシージャ所有者の権限）で定義され、権限評価主体が異なります。RBAC設計と実行モデルの整合を確認しましょう。

GRANT OPTION vs MANAGE GRANTS vs ADMIN OPTION

権限やロールの再付与を許可する機能には違いがあります。

機能 対象 効果 スコープ
WITH GRANT OPTION 特定の権限 付与されたロールが、その特定の権限を他ロールに再付与できる 権限ごと
WITH ADMIN OPTION 特定のロール 付与されたユーザー/ロールが、その特定のロールを他ユーザー/ロールに付与/剥奪できる ロールごと
MANAGE GRANTS アカウント権限 付与されたロールが、既存のあらゆる権限付与を変更（剥奪など）できる アカウント全体

MANAGE GRANTS は非常に強力なため、SECURITYADMIN など限定的なロールにのみ付与すべきです。「ロール自体の配布委任」には WITH ADMIN OPTION を活用しましょう。

-- ロール配布権限の委任例
GRANT ROLE FR_DATA_ANALYST TO ROLE TEAM_LEAD WITH ADMIN OPTION;

Warehouse権限の切り分け

WHに対する権限も、役割に応じて分離するのがベストプラクティスです。

権限 主な操作 典型的な役割
USAGE クエリ実行、ロード/アンロード 利用者、アプリ
OPERATE Suspend/Resume, Abort Query 運用者、SRE
MONITOR 負荷/クレジット/履歴の監視 運用者、コスト管理者
(例: Suspend/Resume＝OPERATE、サイズ変更＝MODIFY、クエリ実行＝USAGE、クエリ中断＝OPERATE) MODIFY サイズ変更, パラメータ変更, ポリシー設定

データ保護ポリシーとの併用

RBACは「誰がどのオブジェクトにアクセスできるか」を制御しますが、「どの行・どの列を見せるか」は制御しません。機密データや個人情報を含むテーブルには、RBACに加えて以下のポリシーを併用するのが実務上の最適解です。

  • 行アクセスポリシー (Row Access Policy): ユーザーのロールなどに基づいて、表示される行を動的にフィルタリングします。
  • マスキングポリシー (Masking Policy): 列の値を、ユーザーのロールなどに基づいて動的にマスク（例: メールアドレスを *** に置換）します。
  • タグベースマスキング: オブジェクトタグを利用して、複数の列にマスキングポリシーを一括適用します。

9. 監査と可視化：誰が何を持っているか？

権限設定が複雑化すると、「このユーザーはどのテーブルを読めるのか？」「このロールには何の権限が付いているのか？」を把握するのが難しくなります。

  • SHOW GRANTS コマンド:
    • SHOW GRANTS ON <object_type> <object_name>;
    • SHOW GRANTS TO ROLE <role_name>;
    • SHOW GRANTS OF ROLE <role_name>;
    • SHOW GRANTS TO USER <user_name>;
  • SNOWFLAKE.ACCOUNT_USAGE スキーマ:
    • GRANTS_TO_ROLES ビュー, GRANTS_TO_USERS ビュー
      これらのビューを活用して、権限の棚卸しや監査用ダッシュボードを作成できます。

Tip: UBAC権限の棚卸し
ユーザーに直接付与された権限（推奨されないUBAC）を棚卸しするには、ACCOUNT_USAGE.GRANTS_TO_ROLES ビューで GRANTEE_NAME がユーザー名（USER_NAME）になっているレコードをフィルタリングします。（※UBAC権限は USE SECONDARY ROLES ALL が前提）

10. まとめ & チェックリスト

SnowflakeのRBACは非常に強力ですが、計画的な設計と運用が不可欠となってきます。

新規DB/スキーマ オンボーディング チェックリスト:

  • ✅ ロール方針を定義する（機能ロール vs アクセスロール）。
  • ✅ 必要な権限セット（USAGE on DB/Schema + SELECT/other on Obj + USAGE on WH）をアクセスロールに付与する。
  • ✅ ALL + FUTURE GRANTS をオブジェクト種別ごとに設定し、権限付与漏れを防ぐ （新規スキーマ作成時の手順に含める）。
  • ✅ スキーマは可能なら WITH MANAGED ACCESS で作成し、権限管理を一元化する。
  • ✅ 共有DBを利用する場合は IMPORTED PRIVILEGES を忘れずに付与する。
  • ✅ PUBLIC ロールに不要な権限が付与されていないか確認する。
  • ✅ ユーザーのデフォルトロール (DEFAULT_ROLE, DEFAULT_SECONDARY_ROLES) を適切に設定する。
  • ✅ OWNERSHIP 移譲時は COPY CURRENT GRANTS を検討し、権限リセットに注意する（移譲前後の実行コンテキスト検証）。
  • ✅ UBAC（ユーザーへの直接付与）が必要最小か／無効化ポリシーの方針と一致しているか確認する。
  • ✅ 定期的に ACCOUNT_USAGE ビューなどで権限を棚卸しする。

内容としてはまだまだかもしれませんが、この記事が皆さんの安全で効率的なSnowflake運用の一助となれば幸いです。

📚 参考出典

脚注

  1. 例外的に、スキーマに対して CREATE TABLE 権限など他の権限が付与されている場合、USAGE がなくてもスキーマ名を解決（resolve）できることがあります（主に"作成系" DDLでの解決）。閲覧・実行には原則 USAGE が必要です。 ↩︎

Discussion