Snowflake RBAC完全解説｜ロールベースアクセス制御の設計と実装

Snowflakeのアクセス制御はRBAC（Role-Based Access Control）を基盤としています。 すべての権限はロールに付与され、ユーザーはロールを通じてオブジェクトにアクセスします。 本記事では、システム定義ロールの階層構造、カスタムロールの設計パターン、GRANT/REVOKEの構文を体系的に解説します。

RBACの基本概念

SnowflakeのRBACでは、権限（Privilege）はオブジェクトに対して定義され、ロールに付与されます。 ユーザーには直接権限を付与できず、必ずロールを介してアクセスします。 ロールは他のロールにGRANTすることで階層構造を形成し、上位ロールは下位ロールの権限を継承します。

アクセス制御モデル:

[ユーザー] ──(USE ROLE)──→ [ロール] ──(GRANT)──→ [権限] ──→ [オブジェクト]

※ ユーザーに直接権限を付与することはできない
※ ロールは別のロールにGRANTして階層化できる

システム定義ロール階層

Snowflakeには5つのシステム定義ロールがあり、固定の階層構造を形成しています。 上位ロールは下位ロールの権限をすべて継承します。

システム定義ロール階層:

              ACCOUNTADMIN
             /            \
      SYSADMIN        SECURITYADMIN
         │                  │
         │              USERADMIN
         │                  │
         └────── PUBLIC ────┘

ACCOUNTADMIN  : アカウント全体の最上位管理者
SYSADMIN      : ウェアハウス・DB・スキーマ等のオブジェクト管理
SECURITYADMIN : ロール・権限・GRANTの管理（MANAGE GRANTS権限）
USERADMIN     : ユーザーとロールの作成・管理
PUBLIC        : 全ユーザーに自動付与される最下位ロール

各ロールの責務と権限

カスタムロールの設計

実運用では業務要件に応じたカスタムロールを作成します。 カスタムロールはSYSADMINの配下に接続することがベストプラクティスです。

カスタムロール階層の設計例:

              ACCOUNTADMIN
             /            \
      SYSADMIN        SECURITYADMIN
       /    \               │
  ETL_ADMIN  ANALYST_ADMIN  USERADMIN
     │          │            │
  ETL_ROLE   ANALYST_ROLE   PUBLIC
     │          │
  ETL_DEV    ANALYST_RO

※ すべてのカスタムロールがSYSADMIN配下に
   接続されている（孤立ロールなし）

-- カスタムロール作成とSYSADMIN配下への接続
CREATE ROLE analyst_role
  COMMENT = 'データ分析チーム用ロール';

-- SYSADMINの配下に接続（ベストプラクティス）
GRANT ROLE analyst_role TO ROLE SYSADMIN;

-- 必要な権限を付与
GRANT USAGE ON DATABASE analytics_db TO ROLE analyst_role;
GRANT USAGE ON SCHEMA analytics_db.public TO ROLE analyst_role;
GRANT SELECT ON ALL TABLES IN SCHEMA analytics_db.public TO ROLE analyst_role;
GRANT SELECT ON FUTURE TABLES IN SCHEMA analytics_db.public TO ROLE analyst_role;
GRANT USAGE ON WAREHOUSE analyst_wh TO ROLE analyst_role;

-- ユーザーにロールを付与
GRANT ROLE analyst_role TO USER tanaka;

GRANT / REVOKE構文

GRANT — 権限の付与

-- オブジェクト権限のGRANT
GRANT SELECT ON TABLE my_db.public.sales TO ROLE analyst_role;
GRANT INSERT, UPDATE ON TABLE my_db.public.reports TO ROLE etl_role;
GRANT USAGE ON WAREHOUSE etl_wh TO ROLE etl_role;
GRANT CREATE TABLE ON SCHEMA my_db.staging TO ROLE etl_role;

-- データベース・スキーマレベルのGRANT
GRANT USAGE ON DATABASE my_db TO ROLE analyst_role;
GRANT USAGE ON ALL SCHEMAS IN DATABASE my_db TO ROLE analyst_role;

-- FUTURE GRANTs（将来作成されるオブジェクトにも適用）
GRANT SELECT ON FUTURE TABLES IN SCHEMA my_db.public TO ROLE analyst_role;
GRANT USAGE ON FUTURE SCHEMAS IN DATABASE my_db TO ROLE analyst_role;

-- ロールのGRANT（階層構造の構築）
GRANT ROLE analyst_role TO ROLE analyst_admin;
GRANT ROLE analyst_admin TO ROLE SYSADMIN;

REVOKE — 権限の取り消し

-- 特定の権限を取り消し
REVOKE SELECT ON TABLE my_db.public.sales FROM ROLE analyst_role;

-- FUTURE GRANTsの取り消し
REVOKE SELECT ON FUTURE TABLES IN SCHEMA my_db.public FROM ROLE analyst_role;

-- ロールの階層関係を解除
REVOKE ROLE analyst_role FROM ROLE SYSADMIN;

-- CASCADE / RESTRICT（参照関係がある場合）
REVOKE SELECT ON TABLE my_db.public.sales FROM ROLE analyst_role CASCADE;

権限の種類

ウェアハウス権限の違い

DAC（Discretionary Access Control）との関係

Snowflakeはロールベースのアクセス制御（RBAC）に加え、任意アクセス制御（DAC）も採用しています。 DACでは、オブジェクトの所有者（作成したロール）がそのオブジェクトに対するすべての権限を持ちます。 所有権の移転はGRANT OWNERSHIP ON ... TO ROLE ...で実行します。

-- 所有権の移転
GRANT OWNERSHIP ON TABLE my_db.public.sales
  TO ROLE etl_role
  REVOKE CURRENT GRANTS;

-- REVOKE CURRENT GRANTS: 元の所有者の権限を取り消す
-- COPY CURRENT GRANTS: 元の所有者の権限を保持する

ベストプラクティス

• ACCOUNTADMINは管理作業時のみ使用し、日常業務にはカスタムロールを使用する
• ACCOUNTADMINには少なくとも2人のユーザーを割り当て、MFAを有効にする
• すべてのカスタムロールをSYSADMIN配下に接続し、孤立ロールを防ぐ
• FUTURE GRANTsで将来作成されるオブジェクトの権限を事前に設定する
• 最小権限の原則に従い、業務に必要な権限のみを付与する
• オブジェクト所有権はサービスロール（ETL_ROLE等）に設定し、個人ユーザーの離職時の問題を防ぐ

試験対策のポイント

• ACCOUNTADMINはSYSADMIN＋SECURITYADMINの権限を継承する最上位ロール
• SECURITYADMINはMANAGE GRANTS権限を持ち、他ロールのGRANTを管理可能
• カスタムロールはSYSADMIN配下に接続するのがベストプラクティス
• PUBLICロールは全ユーザーに自動付与され、取り消しできない
• FUTURE GRANTsは将来作成されるオブジェクトに自動的に権限を適用する
• ウェアハウスのUSAGE権限はクエリ実行に必要、OPERATE権限は起動/停止に必要

サンプル問題

よくある質問