目次 › 第2章 › 2-1

第2章 アカウント管理とデータガバナンス / 想定学習時間:30〜40分 / 最終確認:2026年8月

2-1. セキュリティモデル(RBAC・セキュラブルオブジェクト・GRANT・所有権)

1. RBAC:権限はロールに、ロールはユーザーに

Snowflake のアクセス制御はRBAC(Role-Based Access Control:ロールベースアクセス制御)を土台にしています。最も重要な原則は次の1行に集約されます。

登場人物は次の4つです。

権限がユーザーに届くまでの流れを図にすると次のようになります。

なお、Snowflake のドキュメントでは RBAC に加えてDAC(Discretionary Access Control:任意アクセス制御)の側面も持つと説明されます。これは「各オブジェクトには所有者(所有ロール)がおり、所有者がそのオブジェクトへのアクセスを他者に許可できる」という考え方で、次に見る OWNERSHIP 権限がその中心です。

2. セキュラブルオブジェクトの階層とOWNERSHIP

セキュラブルオブジェクトは階層構造になっています。最上位は組織(organization)、その下にアカウント、アカウントの中にユーザー・ロール・ウェアハウス・データベースなどが並び、データベースの中にスキーマ、スキーマの中にテーブル・ビュー・ステージ・関数などのスキーマオブジェクトが入ります。

ここで重要なのが、テーブルを読むにはテーブルのSELECT権限だけでは足りないという点です。上位コンテナであるデータベースとスキーマのUSAGE権限もそろって初めてアクセスできます。さらに、クエリを実行するにはウェアハウスのUSAGE権限も必要です。

すべてのセキュラブルオブジェクトにはOWNERSHIP(所有権)という特別な権限があります。

• OWNERSHIP はオブジェクトを作成したロールに自動的に与えられます(ユーザーではなくロールが所有する点に注意)
• 所有ロールはそのオブジェクトに対するフルコントロールを持ち、既定では他のロールへ権限をGRANTできるのは所有ロール(と MANAGE GRANTS 権限を持つロール)だけです
• OWNERSHIP は GRANT OWNERSHIP で別のロールへ移転できます(コピーではなく移転で、所有ロールは常に1つ)

3. GRANT / REVOKE と WITH GRANT OPTION

権限の付与と剥奪は GRANT / REVOKE 文で行います。基本の型を確認しましょう。

-- ロールを作成する
CREATE ROLE analyst;

-- オブジェクト権限をロールに付与する(下位コンテナのUSAGEも忘れずに)
GRANT USAGE ON DATABASE sales_db TO ROLE analyst;
GRANT USAGE ON SCHEMA sales_db.public TO ROLE analyst;
GRANT SELECT ON TABLE sales_db.public.orders TO ROLE analyst;

-- クエリ実行に必要なウェアハウスのUSAGEも付与する
GRANT USAGE ON WAREHOUSE analysis_wh TO ROLE analyst;

-- ロールをユーザーに付与する
GRANT ROLE analyst TO USER taro;

-- 権限を剥奪する
REVOKE SELECT ON TABLE sales_db.public.orders FROM ROLE analyst;

-- スキーマ内の既存の全テーブルにSELECTを付与する
GRANT SELECT ON ALL TABLES IN SCHEMA sales_db.public TO ROLE analyst;

-- WITH GRANT OPTION:受け取ったロールが同じ権限をさらに他へ付与できる
GRANT SELECT ON TABLE sales_db.public.orders TO ROLE team_lead
  WITH GRANT OPTION;

4. FUTURE GRANTS:将来のオブジェクトへの自動付与

ETLパイプラインが毎日新しいテーブルを作るような環境では、テーブルが作られるたびに GRANT を実行するのは現実的ではありません。FUTURE GRANTS(将来権限)を使うと、これから作成されるオブジェクトに対して権限を自動的に付与できます。

-- 今後 sales_db.public に作成されるテーブルすべてに
-- 自動的にSELECTが付与されるようにする
GRANT SELECT ON FUTURE TABLES IN SCHEMA sales_db.public TO ROLE analyst;

-- データベースレベルでも定義できる(配下の全スキーマの将来テーブルが対象)
GRANT SELECT ON FUTURE TABLES IN DATABASE sales_db TO ROLE analyst;

5. MANAGED ACCESSスキーマ:権限管理の集中化

既定のスキーマでは、オブジェクトの所有ロールが自分のオブジェクトの権限を自由にGRANTできます。これは柔軟ですが、権限管理が分散し、統制の観点では好ましくない場合があります。

MANAGED ACCESSスキーマ(管理アクセススキーマ)にすると、このふるまいが変わります。

-- 管理アクセススキーマとして作成する
CREATE SCHEMA sales_db.restricted WITH MANAGED ACCESS;

-- 既存スキーマを管理アクセスに変更することもできる
ALTER SCHEMA sales_db.public ENABLE MANAGED ACCESS;

「オブジェクトの所有者ではなく、スキーマ所有者(またはMANAGE GRANTS権限を持つロール)が権限管理を行いたい」という要件が出てきたら、答えはMANAGED ACCESSスキーマです。

6. プライマリロールとセカンダリロール

ユーザーは複数のロールを持てますが、セッション中に有効なロールの扱いには2つの概念があります。

-- カレント(プライマリ)ロールを切り替える
USE ROLE analyst;

-- 自分に付与された他のロールもすべて権限評価に加える
USE SECONDARY ROLES ALL;

-- 現在のロールコンテキストを確認する
SELECT CURRENT_ROLE(), CURRENT_SECONDARY_ROLES();

「複数ロールにまたがる権限を1つのセッションでまとめて使いたい」がセカンダリロールのユースケースです。一方で、新しく作ったオブジェクトの所有者になるのは常にプライマリロールである点が問われやすいので注意してください。

練習問題