Snowflakeユーザー・ロール設計の実践

はじめに

BeeX Advent Calendar2025 16日目 の記事です！

本記事では、Snowflakeにおけるロール設計（アクセス制御）を実践してみます。

公式ドキュメントのベストプラクティス¹²を参考に、
アクセスロール（Access Role）と機能ロール（Functional Role）を分離した設計を適用します。

今回は、1つのアカウント内で「本番環境」と「開発環境」を分離しつつ、
ETLツールやBIツールなどの外部連携を行うシナリオを想定し、
具体的な設計パターンと考慮事項を整理します

記事のまとめ

この記事で整理するポイント

• アクセスロールと機能ロールの分離: 権限管理（アクセスロール）と業務管理（機能ロール）を分けることで運用負荷を下げ、アクセス権限を管理する設計手法
• 環境分離の実装: 1アカウント内でデータベースとウェアハウスを環境別（Prod/Dev）に分け、ロールでアクセス制御を行う方法
• 外部ツール連携: ETLツールやBIツールなどのシステム連携用ユーザーにおける、最小権限の原則に基づいたロール設計

今回の要件

本記事では、以下のような環境と要件を想定します

環境構成

• アカウント構成: 1アカウント内に「本番環境」と「開発環境」を共存させる
• データベース構成:
  • 本番環境用データベース (PROD_DB)
  • 開発環境用データベース (DEV_DB)
• スキーマ構成（各DB共通）:
  • RAW: 生データ格納用（ETLツールが書き込み、開発者が参照）
  • ANALYTICS: データマート格納用（BIツールが参照）
• ウェアハウス構成: 環境（本番/開発）別および用途（運用/ETL/BI）別に分離（PROD_OPE_WH, PROD_ETL_WH, PROD_BI_WH, DEV_OPE_WH, DEV_ETL_WH, DEV_BI_WH）

ユーザーと役割

作成するユーザーと役割は以下の3種類

1. 作業用ユーザー（開発・運用保守）
   • 本番環境および開発環境のデータベースに対して、追加開発や保守運用を実施
   • 人間が操作するユーザー
2. システム用ユーザー（ETLツール）
   • ETLツールからの接続用
   • Snowflakeへのデータ転送（ロード）およびデータマート作成（Transform）を実施
3. 参照用ユーザー（BIツール）
   • BIツールからの接続用
   • Snowflakeのテーブルやビューの参照
   • 将来要件：特定のユーザーには更新権限などを付与する可能性や、部門ごとに参照範囲を限定する可能性あり

振り返り

Snowflakeのアクセス制御概要を振り返ります。

RBACモデル

Snowflakeでは、RBAC（Role-Based Access Control）モデルが採用されている
権限はロールに付与し、そのロールをユーザーに割り当てる仕組み

ユーザー・ロール階層

ユーザーには、複数のロールを割り当てられる。

また、ロール階層では以下の仕組みが適用される

• ロールは、ユーザまたはロールに付与できる（アクセス階層の形成）
• 下位層ロールに付与された権限は、上位層ロールも利用可能（権限の継承）

設計方針

Snowflakeのベストプラクティスに基づき、「アクセスロール」と「機能ロール」を作成し、階層構造を持たせる設計を行う

ロールの種類

ロール種別	英語名	説明	付与元	付与先
アクセスロール	Access Role (AR)	特定のオブジェクト（DB、スキーマ、テーブル等）に対する権限（Read/Write等）をまとめたロール	権限	機能ロール
機能ロール	Functional Role (FR)	実際の業務や職務（開発者、アナリスト、ETLシステム等）に対応するロール。アクセスロールを束ねる	アクセスロール	ユーザー

階層設計の考え方

1. アクセスロール (AR) を作成し、必要なオブジェクト権限（USAGE, SELECT, INSERT など）を付与
2. 機能ロール (FR) を作成し、業務に必要な アクセスロール (AR) を付与
3. ユーザーには 機能ロール (FR) のみを付与
4. システム管理者 (SYSADMIN) には、すべての 機能ロール (FR) を付与し、管理可能にする

実装詳細

1. 全体構成図

想定するロール階層と権限付与の全体像は以下の通り。

2. アクセスロール（AR）の設計

アクセスロールは「何に対して（対象）、どのような操作ができるか（権限）」を定義する。
設計では、以下2つの観点を検討する

1. 対象の粒度（Object Granularity）

どのレベル（範囲）でロールを作成するかを決定する

• データベース単位: 管理は容易だが、粒度が粗い。また、Future Grants を使用する際、スキーマレベルで別途設定が行われるとデータベースレベルの設定が無視される仕様がある³
• スキーマ単位: SnowflakeのFuture Grants機能はスキーマ単位の設定がデータベース単位の設定よりも優先（オーバーライド）される仕様であるため、スキーマ単位でロールと権限を管理する方が、意図しない権限剥奪を防止できる³
• テーブル単位: 最も柔軟な制御が可能だが、管理対象ロールが増え、運用負荷が高まる

2. 操作の粒度（Privilege Granularity）

どのような権限セット（パターン）を作成するかを決定する

• Read Only (RO): 参照権限のみ (USAGE, SELECT)
• Read Write (RW): 更新権限を含む (INSERT, UPDATE, DELETE, TRUNCATE 等)
• DDL / Admin: オブジェクト作成や削除を含む (CREATE, DROP 等) ※必要に応じて

---

• 本記事での採用パターン: 「スキーマ単位」 (データ用) および 「ウェアハウス単位」 (WH用) で詳細に設計
• 命名規則:
  • データ用: AR_{環境}_{スキーマ名}_{権限} (例: AR_PROD_SCHEMA_A_READ)
  • WH用: AR_{環境}_{用途}_WH_{権限} (例: AR_PROD_OPE_WH_USAGE)

設計例

本記事の要件（環境×用途×権限レベル）に基づき、以下のアクセスロールを作成する。
最小権限の原則に従い、ウェアハウスごと・スキーマごとにロールを分割する

1. ウェアハウス用アクセスロール（合計12個）

環境（本番/開発）× 用途（運用/ETL/BI）× 権限（利用/管理）の組み合わせで定義

アクセスロール名	用途	ウェアハウス	付与権限
AR_PROD_OPE_WH_USAGE	本番運用WH利用	PROD_OPE_WH	USAGE
AR_PROD_OPE_WH_ADMIN	本番運用WH管理	PROD_OPE_WH	USAGE, OPERATE, MODIFY, MONITOR
AR_PROD_ETL_WH_USAGE	本番ETL用WH利用	PROD_ETL_WH	USAGE
AR_PROD_ETL_WH_ADMIN	本番ETL用WH管理	PROD_ETL_WH	USAGE, OPERATE, MODIFY, MONITOR
AR_PROD_BI_WH_USAGE	本番BI用WH利用	PROD_BI_WH	USAGE
AR_PROD_BI_WH_ADMIN	本番BI用WH管理	PROD_BI_WH	USAGE, OPERATE, MODIFY, MONITOR
AR_DEV_OPE_WH_USAGE	開発運用WH利用	DEV_OPE_WH	USAGE
AR_DEV_OPE_WH_ADMIN	開発運用WH管理	DEV_OPE_WH	USAGE, OPERATE, MODIFY, MONITOR
AR_DEV_ETL_WH_USAGE	開発ETL用WH利用	DEV_ETL_WH	USAGE
AR_DEV_ETL_WH_ADMIN	開発ETL用WH管理	DEV_ETL_WH	USAGE, OPERATE, MODIFY, MONITOR
AR_DEV_BI_WH_USAGE	開発BI用WH利用	DEV_BI_WH	USAGE
AR_DEV_BI_WH_ADMIN	開発BI用WH管理	DEV_BI_WH	USAGE, OPERATE, MODIFY, MONITOR

2. データオブジェクト用アクセスロール（合計12個）

環境（本番/開発）× スキーマ（例としてSchema A, B）× 権限（参照/更新/管理）の組み合わせで定義。
※USAGE ON DATABASE 権限は、各スキーマ用ロールに含める設計とする

アクセスロール名(仮)	用途	DB/スキーマ	付与権限
AR_PROD_SCHEMA_A_READ	本番スキーマA参照	PROD/A	USAGE (DB, Schema), SELECT
AR_PROD_SCHEMA_A_RW	本番スキーマA更新	PROD/A	USAGE (DB, Schema), SELECT, INSERT, UPDATE, DELETE, TRUNCATE
AR_PROD_SCHEMA_A_ADMIN	本番スキーマA管理	PROD/A	USAGE (DB, Schema), ALL PRIVILEGES (on Schema Objects)
AR_PROD_SCHEMA_B_READ	本番スキーマB参照	PROD/B	USAGE (DB, Schema), SELECT
AR_PROD_SCHEMA_B_RW	本番スキーマB更新	PROD/B	USAGE (DB, Schema), SELECT, INSERT, UPDATE, DELETE, TRUNCATE
AR_PROD_SCHEMA_B_ADMIN	本番スキーマB管理	PROD/B	USAGE (DB, Schema), ALL PRIVILEGES (on Schema Objects)
AR_DEV_SCHEMA_A_READ	開発スキーマA参照	DEV/A	USAGE (DB, Schema), SELECT
AR_DEV_SCHEMA_A_RW	開発スキーマA更新	DEV/A	USAGE (DB, Schema), SELECT, INSERT, UPDATE, DELETE, TRUNCATE
AR_DEV_SCHEMA_A_ADMIN	開発スキーマA管理	DEV/A	USAGE (DB, Schema), ALL PRIVILEGES (on Schema Objects)
AR_DEV_SCHEMA_B_READ	開発スキーマB参照	DEV/B	USAGE (DB, Schema), SELECT
AR_DEV_SCHEMA_B_RW	開発スキーマB更新	DEV/B	USAGE (DB, Schema), SELECT, INSERT, UPDATE, DELETE, TRUNCATE
AR_DEV_SCHEMA_B_ADMIN	開発スキーマB管理	DEV/B	USAGE (DB, Schema), ALL PRIVILEGES (on Schema Objects)

Future Grants (将来の付与) の活用
ARへの権限付与では、新しく作成されるデータオブジェクトにも自動的に権限を付与するため、
ON FUTURE 句を使用した権限付与を行うことが推奨される

設定例（クエリ）:

-- 指定したスキーマ内に将来作成されるテーブルに対して、自動的にSELECT権限をもつようにする
GRANT SELECT ON FUTURE TABLES IN SCHEMA <データベース名>.<スキーマ名> TO ROLE <アクセスロール名>;

3. 機能ロール（FR）の設計

機能ロールは「誰が（どのシステムが）、どの業務を行うか」を定義する。
ここでは、以下の3つのカテゴリ（作業用、ETL用、参照用）に分けた階層構造を設計する

設計方針（階層化とベースロール）

• ベースロールの活用: ウェアハウス利用権限など、共通して必要な権限を「ベースロール」として切り出す
• 上位ロールへの継承: 「管理者は開発者の権限を兼ねる」といった関係を、ロールの継承で表現する

4. 作業用機能ロール (Work Functional Role)

開発および運用保守を行うロール群と、ユーザー・ロールの階層構造

機能ロール名	上位ロール(継承元)	付与アクセスロール(AR)	付与標準ロール	説明
FR_BASE_DEV_OPE	-	AR_DEV_OPE_WH_USAGE	-	開発作業用WH利用ベース
FR_DEVELOPER	FR_BASE_DEV_OPE	AR_DEV_SCHEMA_A_RW AR_DEV_SCHEMA_B_RW	-	開発者。開発データの更新が可能
FR_BASE_PROD_OPE	-	AR_PROD_OPE_WH_USAGE	-	本番作業用WH利用ベース
FR_ADMIN	FR_DEVELOPER FR_BASE_PROD_OPE	AR_PROD_SCHEMA_A_RW, AR_PROD_SCHEMA_B_RW AR_PROD_OPE_WH_ADMIN...	SECURITYADMIN SYSADMIN	全環境の管理者。アカウント管理も可能

• FR_BASE_DEV_OPE / FR_BASE_PROD_OPE: 各環境の運用WH利用権限のみを持つベースロール
• FR_DEVELOPER: 開発環境での作業権限（WH利用＋データRW）を持つ
• FR_ADMIN: 全環境の管理者。Developerを継承し、さらに本番環境の操作権限や管理者ロール（SYSADMIN等）を持つ

5. ETL用機能ロール (ETL Functional Role)

ETLシステム（例: ETLツール）が利用するロール群と、ユーザー・ロールの階層構造

機能ロール名	上位ロール(継承元)	付与アクセスロール(AR)	付与標準ロール	説明
FR_BASE_ETL	-	AR_PROD_ETL_WH_USAGE AR_DEV_ETL_WH_USAGE	-	ETL用WH利用ベース
FR_ETL_SYSTEM	FR_BASE_ETL	AR_PROD_SCHEMA_A_RW, AR_PROD_SCHEMA_B_RW AR_PROD_ETL_WH_ADMIN	-	ETLシステム用。データ連携実行

• FR_BASE_ETL: ETL用ウェアハウスの利用権限（USAGE）のみを持つ
• FR_ETL_SYSTEM: 実際のデータロードを行うロール。ベースロールを継承し、さらにWHの管理権限（ADMIN）とデータの書き込み権限（RW）を持つ

6. 参照用機能ロール (Reference Functional Role)

BIツール（例: BIツール）を利用してデータを参照するロール群と、ユーザー・ロールの階層構造

機能ロール名	上位ロール(継承元)	付与アクセスロール(AR)	付与標準ロール	説明
FR_BASE_PROD_BI	-	AR_PROD_BI_WH_USAGE	-	BI用WH利用ベース
FR_BI_VIEWER	FR_BASE_PROD_BI	AR_PROD_SCHEMA_A_READ AR_PROD_SCHEMA_B_READ	-	BI閲覧者。参照のみ
FR_BI_CREATOR	FR_BI_VIEWER	AR_PROD_SCHEMA_A_RW AR_PROD_SCHEMA_B_RW	-	BI作成者。Viewerを継承し、更新権限を追加

• FR_BASE_PROD_BI: BI用ウェアハウスの利用権限（USAGE）を持つ
• FR_BI_VIEWER: データの参照権限（READ）を追加する
• FR_BI_CREATOR: Viewerを継承し、データの更新権限（RW）を追加する（将来的な要件対応）

注意点や考慮事項

機能ロールとアクセスロールのメリット

単純な構成ではメリットが見えにくいですが、ユーザー数やオブジェクト数が増加した際に、管理コストを大幅に削減できる点がメリットと考えます。

ロールを階層化することで、「人（ユーザー）」の変化と 「データ（オブジェクト）」の変化 をそれぞれの層で吸収し、変更による影響を最小化できる

1. 機能ロール (Functional Role) の効果

「誰が（どの職務が）」アクセスできるかを管理するロール。主に人や組織の変更に対応する

• 人事異動への対応（ユーザー管理の効率化）:
  • 部署異動や退職の際、ユーザーに割り当てる機能ロールを変更するだけで権限の付け替えが完了する。個別のデータ権限を操作する必要がなくなる。
  • （例：Aさんが営業部から開発部に異動した場合、FR_Sales を外して FR_Developer を付けるだけで、数百のテーブル権限の切り替え作業を完了できる）
• 職務定義の明確化:
  • 「開発者には何が必要か」「アナリストには何が必要か」という権限セットがロールとして定義・可視化される

2. アクセスロール (Access Role) の効果

「何に（どのデータに）」アクセスできるかを管理するロール。主にデータや要件の変更に対応する

• 権限セットの再利用（DRY原則）:
  • データセットごとの権限（AR）を一度定義すれば、それを複数の機能ロールで使い回せる。
  • （例：新プロジェクト用DBのARを1つ作成し、それを「開発部FR」と「分析部FR」の両方に付与するだけで、両部署への権限付与の作業を完了できる）
• 権限変更の一元管理（メンテナンス性）:
  • データセットへのアクセス権限を変更する場合、ARを修正するだけで、利用している全機能ロールに反映される。
  • （例：特定のテーブルを非公開（権限剥奪）にする場合、ARからそのテーブルの権限を外すだけで、全職務のユーザーから即座に見えなくなる）
• 柔軟な組み合わせ（ビルディングブロック）:
  • ARを「部品」として組み合わせることで、多様な要件に対応できる。
  • （例：「基本データAR」と「機密データAR」を作成しておき、管理職FRには両方を付与し、一般社員FRには基本データARのみを付与する）

機能ロールの階層化

機能ロール同士を階層化させることで、ロール定義の重複を排除し、管理をさらに効率化できます。
設計時の検討事項として以下が考えられます。

1. 包含関係（上位/下位）の検討

「上位の職務（Editorなど）は、下位の職務（Viewerなど）ができることを全てできる」という関係がある場合、上位ロールに下位ロールを継承させる

• 適用例: 本記事の「BIツール用ユーザー」の例では、FR_Sales_Creator（上位）に FR_Sales（下位）を付与

2. 共通機能（ベースロール）の切り出し

複数の職務で共通して必要な権限（例: ウェアハウス利用権限、共通マスタデータの参照権限、ログイン権限など）を**「ベースロール」**として切り出す

• 適用例: 本記事では FR_BI_BASE を作成してウェアハウス権限を集約し、各部門のBIロールに付与

アクセスロールの階層化について（非推奨）

本記事の設計では、アクセスロール（AR）同士の階層化（ARが別のARを継承すること）は行っていません。
Snowflakeのベストプラクティスでは、階層構造は主に 機能ロール（FR） のレベルで構築することが推奨されます。

• 理由:
  • アクセスロールは「アトミック（最小単位）」に保つ: ARは特定のオブジェクトセットに対する権限の塊として定義し、依存関係を持たせないことで、再利用性と見通しを良くします。
  • 機能ロールで柔軟に組み合わせる: 「読み取り」と「書き込み」の両方が必要な場合、AR同士を継承させるのではなく、対象のFRに両方のARを付与（コンポジション）する設計が一般的です。

アクセスロールの粒度

アクセスロールの粒度が細かすぎると管理が煩雑になり、粗すぎると最小権限の原則に反する。
管理とセキュリティのバランスを考慮して、設計する

1. 対象の粒度（範囲）の検討

• DB単位: 環境分離（Prod/Dev）のみで十分な場合。
• スキーマ単位: データの用途（Rawデータ/マート等）や機密レベルでアクセス制御を行いたい場合（Future Grants を活用して管理を自動化したい場合⁴³）
• テーブル単位: 特定の機密データのみを厳密に制御したい場合（ただし管理負荷に注意）。

2. 操作の粒度（権限）の検討

• RO (参照のみ) / RW (更新可): 基本セットとして作成。
• Admin (DDL): 必要に応じて、オブジェクト作成・削除権限を持つロールを作成。

（※本記事の例では、構成を分かりやすくするため「DB単位」×「RO/RW」の組み合わせで設計）

ウェアハウス権限とコスト管理⁵

ロール設計では、データアクセス権限だけでなく、コンピュートリソース（ウェアハウス）の利用権限も重要な設計観点となる。

ウェアハウス権限のアクセスロール化

公式ドキュメントのベストプラクティス「ビジネス機能とオブジェクトアクセスの整合」²に従い、ウェアハウス権限もアクセスロール (AR) を介して機能ロール (FR) に付与する 設計が推奨される。
これにより、すべての権限付与を「権限 → アクセスロール → 機能ロール」という一貫した階層構造で管理できる。

• 設計例: AR_PROD_OPE_WH_USAGE というARを作成し、PROD_OPE_WH の USAGE 権限を付与する。
• メリット: ウェアハウスの権限構成が変更された場合（例: MONITOR 権限の追加など）でも、アクセスロールの定義を変更するだけで、関連するすべての機能ロールに反映される。

利用するウェアハウスの USAGE 権限のみを付与することで、ウェアハウス別のコスト按分や利用制限のコントロールが可能になる。

データベースロールの利用について

ロール構成に「データベースロール（Database Role）」を導入することも可能。

データベース内にオブジェクトとしてロールを作成できる機能で、データ共有（Data Sharing）を行う際などに有用

管理アクセススキーマ (Managed Access Schema) の活用⁶

アクセスロールによる権限管理を徹底するため、スキーマ作成時に WITH MANAGED ACCESS オプションを使用することも可能
これにより、テーブル作成者（Owner）が勝手に権限付与することを防ぎ、スキーマ所有者（ロール）による一元管理が可能となる

参考URL

この記事で参考にしたURLです。

1. Snowflake公式: アクセス制御の概要
   https://docs.snowflake.com/ja/user-guide/security-access-control-overview ↩

2. Snowflake公式: アクセス制御の考慮事項 - オブジェクトのアクセスとビジネス機能の整合
   https://docs.snowflake.com/ja/user-guide/security-access-control-considerations#aligning-object-access-with-business-functions ↩ ↩²

3. Snowflake公式: GRANT <権限> ... TO ROLE / データベースまたはスキーマオブジェクトに対する将来の許可
   https://docs.snowflake.com/ja/sql-reference/sql/grant-privilege#future-grants-on-database-or-schema-objects ↩ ↩² ↩³

4. Snowflake公式: 将来の付与を使用した付与管理の簡素化
   https://docs.snowflake.com/ja/user-guide/security-access-control-considerations#simplifying-grant-management-using-future-grants ↩

5. Snowflake公式: ウェアハウスの権限
   https://docs.snowflake.com/ja/user-guide/security-access-control-privileges#virtual-warehouse-privileges ↩

6. Snowflake公式: 管理アクセススキーマを使用した助成金管理の一元化
   https://docs.snowflake.com/ja/user-guide/security-access-control-considerations#centralizing-grant-management-using-managed-access-schemas ↩