SnowflakeのRBAC｜Agile育成ブログ

Snowflakeは、このロールベースのアクセス制御（Role-Based Access Control: RBAC）システムをセキュリティとガバナンスの中心的な柱として設計しており、大規模なデータウェアハウス環境で複雑な権限管理を効率的に行うための独自の強力な仕組みを提供しています。

🔒 Snowflakeにおけるロールベースのアクセス制御（RBAC）

1. RBACの基本概念とSnowflakeにおける役割

SnowflakeのRBACモデルは、権限管理をシンプルかつセキュアにするために設計されています。アクセス制御の基本的な要素は以下の3つです。

要素	定義
ユーザー (User)	Snowflakeを利用する個人またはプロセス。
ロール (Role)	権限を付与されるエンティティ。ユーザーは一つ以上のロールを付与されます。
権限 (Privilege)	ロールが実行できる特定のアクション（例：`SELECT` on table、`CREATE WAREHOUSE`など）。

Snowflakeでは、「ユーザー」に直接「権限」を付与するのではなく、「ロール」に権限を付与し、そのロールをユーザーに割り当てます。これにより、組織変更やユーザーの異動が発生した場合でも、権限管理をロール単位で迅速かつ容易に行うことができます。

2. ロールの階層構造（継承）が鍵

SnowflakeのRBACの最大の特徴は、ロールが他のロールに権限を継承できる点です。

あるロールを別のロールに付与すると、その上位ロールは下位ロールが持つすべての権限を自動的に継承します。この仕組みにより、権限管理が非常に効率的になります。

中央集権的な管理: 権限が必要なユーザーに直接付与するのではなく、役割に応じて作成されたロール（例：HR_ANALYST）を、より上位のロール（例：SYSADMIN）に組み込むことで、組織全体の権限構造をツリー状に構築できます。
管理コスト削減: あるオブジェクト（例：新しいデータベース）に対する権限を付与する場合、上位ロール（例：SYSADMIN）に一度付与するだけで、その下位のすべてのロールがその権限を継承できます。

3. システム定義ロール（組み込みロール）

Snowflakeには、大きく分けて2種類のロールがあります。

データベースロール（Database Role）: 特定のデータベース内でのみ定義され、そのDB内の権限管理に特化したロール。
アカウントロール（Account Role）: 従来からある標準的なロール。アカウント全体で共有されます。

Snowflakeには、アクセス制御の初期設定として利用される、いくつかの特別な「システム定義ロール」が存在します。特に重要な3つは以下の通りです。

ロール名	権限の概要	職務の分離（ベストプラクティス）
ACCOUNTADMIN	アカウント全体に対する最高管理者権限。すべての操作が可能。	日常的な操作には使用せず、緊急時や最高レベルのセキュリティ管理に限定すべき。
SECURITYADMIN	ロールとユーザーの管理、およびアクセス制御パラメータの設定権限。	アカウント管理からセキュリティ機能を分離し、専門の担当者に割り当てるべき。
SYSADMIN	ウェアハウス、データベース、スキーマ、テーブルなどの日常的なオブジェクトを作成・管理する権限。	大半の開発・運用業務はこのロール、またはこのロールの下位のカスタムロールで行うべき。
PUBLIC	すべてのユーザーに自動的に付与されるロール。	すべてのユーザーに公開したいオブジェクトへの`USAGE`などの最低限の権限を付与する。

4. RBAC運用におけるベストプラクティス

Snowflake環境のセキュリティと効率を最大化するためには、以下のベストプラクティスが推奨されます。

① カスタムロールの作成と階層化

システム定義ロールを直接ユーザーに付与するのではなく、業務内容やデータへのアクセスレベルに応じたカスタムロール（例：DB_READ_ONLY, FINANCE_WRITERなど）を作成し、それらをSYSADMINやSECURITYADMINの下位に位置づける階層構造を徹底します。

ユーザーが自分の組織の運用に合わせて自由に作成したロールのことです。
1. カスタムロールとは？

システム定義ロール（SYSADMINなど）は非常に強力な権限を持っています。しかし、実際の業務では「データを見るだけの営業担当者」や「特定のテーブルだけを管理する運用担当者」など、必要最小限の権限（最小特権の原則）を割り当てたいはずです。

そのために、用途に合わせて作る独自の「役割」がカスタムロールです。

例: DEVELOPER_ROLE（開発者用）、SALES_ANALYST_ROLE（営業分析用）、SECURITY_VIEWER_ROLE（監査用）など。

2. カスタムロールの重要ルール：ロールの階層化

カスタムロールは、作って終わりではありません。Snowflakeでは「カスタムロールを上位のシステム定義ロールに紐づける（継承させる）」ことが必須のルールとなっています。

なぜ階層化するのか？: 上位の SYSADMIN がすべてのカスタムロールを管理できるようにするためです。もし紐づけを行わないと、管理者（SYSADMIN）であっても、そのカスタムロールが作ったテーブルを管理できなくなってしまいます。

② ACCOUNTADMINの利用制限

ACCOUNTADMINは、環境を破壊する可能性のある非常に強力な権限を持つため、日常的な運用や開発で絶対に使用してはいけません。使用は監査目的や緊急時に限定し、その使用ログは厳密に監視されるべきです。

③ 最小権限の原則 (Principle of Least Privilege)

ユーザーやロールには、業務遂行に必要最低限の権限のみを付与します。この原則を徹底することで、権限の悪用や誤操作による情報漏洩のリスクを最小限に抑えられます。

SnowflakeのRBACを適切に設計・運用することで、強固なセキュリティガバナンスを確立し、安全なデータ活用環境を実現できます。

🔑 Snowflakeの主要な権限カテゴリ

1. データ操作権限（DML: Data Manipulation Language）

データオブジェクト（テーブル、ビューなど）に格納されているデータを操作するための最も一般的な権限です。

権限名	概要	適用例
SELECT	データの読み取りを許可する。データ分析の基本。	`SELECT` on TABLE `<table_name>`
INSERT	新しいデータを追加（挿入）することを許可する。	`INSERT` on TABLE `<table_name>`
UPDATE	既存のデータを更新（変更）することを許可する。	`UPDATE` on TABLE `<table_name>`
DELETE	データを削除することを許可する。	`DELETE` on TABLE `<table_name>`
TRUNCATE	テーブル内の全データを高速で削除することを許可する。	`TRUNCATE` on TABLE `<table_name>`

2. データ定義権限（DDL: Data Definition Language）

データベースやスキーマ内に、新しいオブジェクトを作成したり、既存のオブジェクトの構造を変更・削除したりするための権限です。これらの権限は通常、スキーマやデータベースのレベルで付与されます。

権限名	概要	適用例
CREATE DATABASE	新しいデータベースを作成することを許可する。	`CREATE DATABASE` on ACCOUNT
CREATE SCHEMA	データベース内に新しいスキーマを作成することを許可する。	`CREATE SCHEMA` on DATABASE `<db_name>`
CREATE TABLE	スキーマ内に新しいテーブルを作成することを許可する。	`CREATE TABLE` on SCHEMA `<schema_name>`
CREATE VIEW	スキーマ内にビューを作成することを許可する。	`CREATE VIEW` on SCHEMA `<schema_name>`

3. アクセスおよび使用権限（Usage & Access）

オブジェクト自体を利用したり、オブジェクト内のデータにアクセスしたりするための基本的な「通行許可証」となる権限です。

権限名	概要	適用例
USAGE	オブジェクトの利用を許可する。特にウェアハウスやデータベースの利用に必須。	`USAGE` on WAREHOUSE `<wh_name>`
MONITOR	オブジェクトの使用状況やパフォーマンスを監視することを許可する。	`MONITOR` on WAREHOUSE `<wh_name>`
OPERATE	ウェアハウスの起動・停止（サスペンド・レジューム）を制御することを許可する。	`OPERATE` on WAREHOUSE `<wh_name>`

4. 所有権と管理権限

権限名	概要	特徴
OWNERSHIP	オブジェクトに対する完全な所有権。そのオブジェクトに対するすべての操作と、他のロールへの権限付与が可能です。	継承できない特別な権限であり、この権限を持つロールによってのみ、オブジェクトの構造変更などが可能です。
MANAGE GRANTS	他のユーザーやロールに対し、権限を付与（GRANT）したり、剥奪（REVOKE）したりすることを許可する。	セキュリティ管理を専門とするロール（例：`SECURITYADMIN`）に付与されます。

2. セカンダリロール（Secondary Roles）とは？

セカンダリロールとは、「現在使用中のメインのロール（プライマリロール）以外に、自分が持っている他の全てのロールの権限を同時に使えるようにする機能」です。

なぜ必要なのか？（これまでの不便さ）

通常、Snowflakeでは一度に1つのロール（プライマリロール）しか「アクティブ」にできません。

ロールA：テーブル1が見れる
ロールB：テーブル2が見れるという場合、これまでは USE ROLE A; と USE ROLE B; をいちいち切り替えてクエリを投げる必要がありました。

セカンダリロールを使うとどうなるか？

セカンダリロールを有効にすると、自分が付与されている全てのロールの権限が「合算」されます。

-- セカンダリロールを有効にする
USE SECONDARY ROLES ALL;

これを実行すると、ロールAの権限（テーブル1）とロールBの権限（テーブル2）を、切り替えることなく一度のクエリで同時に使えるようになります。

セカンダリーロールには他のロールに与えられているCREATE権限が含まれていない

プライマリとセカンダリの違い

項目	プライマリロール（Primary）	セカンダリロール（Secondary）
役割	オブジェクトの作成者（所有者）になる	既存オブジェクトの参照や操作のみ
DDL操作	可能（作成したものはこのロールの所有になる）	不可（基本的に参照・DML用）
権限の範囲	選んでいる1つのロールのみ	自分が持つ「全ロール」の合算

1. GRANTコマンドの基本構造

最も基本的な構文は以下の通りです。

GRANT <権限名> ON <オブジェクトの種類> <オブジェクト名> TO ROLE <ロール名>;

権限名: SELECT, INSERT, USAGE, CREATE TABLE など。
オブジェクト: DATABASE, SCHEMA, TABLE, WAREHOUSE など。

2. よく使うGRANTの実例

実務で頻繁に使うパターンを3つ紹介します。

① データベースやウェアハウスを使えるようにする（USAGE）

Snowflakeでは、テーブルの中身を見る前に、まずその「箱（DB/スキーマ）」と「計算機（ウェアハウス）」にアクセスする権利が必要です。

-- ウェアハウスの使用権限
GRANT USAGE ON WAREHOUSE compute_wh TO ROLE analyst_role;

-- データベースとスキーマの使用権限
GRANT USAGE ON DATABASE sales_db TO ROLE analyst_role;
GRANT USAGE ON SCHEMA sales_db.public TO ROLE analyst_role;

② テーブルのデータを読み書きできるようにする

-- 読み取り専用（SELECT）
GRANT SELECT ON TABLE sales_db.public.orders TO ROLE analyst_role;

-- 書き込みも許可（INSERT, UPDATE, DELETE）
GRANT INSERT, UPDATE ON TABLE sales_db.public.orders TO ROLE developer_role;

③ ロールをユーザー（または他のロール）に付与する

権限をセットした「ロール」を、最終的に人（ユーザー）に紐付けます。

GRANT ROLE analyst_role TO USER taro_yamada;

Snowflakeの権限は、玄関・廊下・部屋のすべての鍵を持っていないと、目的の場所に辿り着けない」というルール

GRANT SELECT: 「テーブルの中身を見ていいよ」という許可。
GRANT USAGE ON WAREHOUSE: 「計算機（ウェアハウス）を使っていいよ」という許可。

これだけ見ると準備万端に見えますが、実は肝心の「データベース」と「スキーマ」という廊下の鍵が抜けています。

この解説が言わんとしていることは、**「Snowflakeの権限は、玄関・廊下・部屋のすべての鍵を持っていないと、目的の場所に辿り着けない」**というルールについてです。

ご提示のSQL文は、あえて「一部の鍵（権限）を渡さない」ことで、権限の仕組みを学ぶための実験的なステップになっています。

1. なぜ「意味がわからない」と感じるのか？

おそらく、**「権限を与えているのに、実際には使えない状態を作っている」**からです。

GRANT SELECT: 「テーブルの中身を見ていいよ」という許可。
GRANT USAGE ON WAREHOUSE: 「計算機（ウェアハウス）を使っていいよ」という許可。