はじめに

今回はデータプラットフォームチームより一ノ瀬がお届けします🎁

最近、SnowflakeはAI機能の強化もあり
（ここについては、数日後にデータプラットフォームチームの別メンバーの記事が掲載予定）
「そろそろ事業部門にもSnowflakeを展開したいな…」
と考えている企業も多いと思います。
ただ、実際にやろうとすると、こんな不安が出てきませんか？

どこまで権限を渡していいのか分からない
誤って本番データを書き換えられたらどうしよう…
とりあえずアカウントを配るだけでカオスになりそう

私たちの会社でも、今年度から事業部門向けにSnowflakeアカウントを配り始め、
Snowflakeダイレクトユーザーは20名ほどの、まだまだ小さな規模感です🌱

この記事では、その中で見えてきた

事業部門ユーザーの 利用パターン整理のやり方
それに合わせた 権限設計と運用ルール
実際に使っているような GRANTクエリの例

をまとめてみました。

完璧なベストプラクティスではなく、
「20人規模でまずこう始めてみた」というリアル寄りの内容なので、
必要に応じて自社向けにアレンジして使っていただければ嬉しいです☺

事業部門のSnowflake利用は、ざっくり3パターン

事業部門のSnowflake利用は、だいたい次の3つに分かれます。

Tableau経由での間接利用
Streamlit in Snowflakeでのアプリ利用
Sandbox DBでSQL / Pythonを自分で書いて使う利用

このうち、比較的一般的で事例も多い①のTableau利用については、この記事では深掘りしません。
今回は②と③に絞って紹介していきます。

前提：Snowflake 環境とユーザー構成（ざっくり）

まずは、軽く前提を共有しておきます。

②③に該当するSnowflakeの事業部門ユーザー数

約 20 名

ユーザー構成

ライト層（閲覧メイン）
Streamlitアプリを中心に利用する人たち。
これまでエクセルがメインで、データ基盤にはあまり触れてこなかった層。
技術寄りユーザー（SQL / Python を自分で書く層）
SandboxでSQLやPythonを書く人たち。
社内のAI人材育成プログラムの卒業生が中心で、事業部門所属ながらも一定の開発リテラシー（特に Python）がある。
　📝AI人材育成プログラムについてはこちら↓
　https://www.itmedia.co.jp/enterprise/articles/2311/29/news065.html
　https://www.ilect.net/post/pola_interview1

Snowflakeのアカウント・データベースのレイヤー

Snowflakeアカウントは事業会社ごとに分かれており、
事業部門には主に次の 3 つのデータベースに触れてもらう前提で設計しています。
それぞれ 部門・案件・ユーザー等の単位でスキーマを分けて、アクセスコントロールしやすい構成にしています。

DATAMARTデータベース（読み取り中心）
STREAMLIT_APPSデータベース（アプリ実行用）
SANDBOXデータベース（実験・検証用）

補足：Cortex の利用制限について

Cortex の利用は一部制限中
個人情報有無の観点から、利用者ごとに個別判断しています。
具体的には、PUBLIC ロールから SNOWFLAKE.CORTEX_USER を削除し、
必要なユーザーのロールにのみ明示的に付与しています。

Streamlit in Snowflake の権限設計

Streamlitは事業部門にも扱いやすく、活用の幅も広いのですが、
「GUIからデータ更新ができる」タイプのアプリは、特に権限管理が大事になります。

私たちの環境では、Streamlitの利用ケースは次の2パターンに分かれます。

(A) ダッシュボード表示（読み取り専用）
(B) 手動でのマスタデータ更新（書き込みあり）

基本方針

Streamlitアプリで使う領域は、

STREAMLIT_APPS.＜部門や案件＞_APP_EXEC スキーマ
→ アプリ本体（Streamlit） を置く場所
STREAMLIT_APPS.＜部門や案件＞_APP_DATA スキーマ
→ アプリから更新したいテーブル を置く場所
DATAMART.＜部門や案件＞ スキーマ
→ パイプラインで更新される 読み取り専用マート

という役割分担にしています。

権限設計のポイントは次のとおりです。

利用者用ロールは「アプリの利用権」だけ
データの読み書き・マートの参照はすべてアプリ用ロールに寄せる
権限は
- 誰が使うか：FunctionalRole（...APP_USER, ..._APP_RUN）
- 何ができるか：AccessRole（…EXEC_USG, …DATA_CRT）
  で分離する

(A) ダッシュボードだけ見る Streamlit アプリ（読み取りのみ）

まずは「データ更新なし・ダッシュボード表示だけ」のパターンです。

利用者：アプリ実行だけ
アプリ：
- アプリ自体の開発・実行
- マート参照

use role USERADMIN;

-- FunctionalRole：利用者
create role xxxx_APP_USER;
grant role xxxx_APP_USER to role SYSADMIN;

-- FunctionalRole：アプリ
create role xxxx_APP_RUN;
grant role xxxx_APP_RUN to role SYSADMIN;

-- AccessRole：アプリ開発
create role A_STREAMLIT_APPS_xxxx_APP_EXEC_CRT;

-- AccessRole：アプリ実行
create role A_STREAMLIT_APPS_xxxx_APP_EXEC_USG;

-- AccessRole：マート読み取り
create role A_DATAMART_xxxx_USG;

-- ロール同士の紐づけ
-- 利用者：アプリ実行だけ
grant role A_STREAMLIT_APPS_xxxx_APP_EXEC_USG to role xxxx_APP_USER;

-- アプリ：開発・実行＋マート参照
grant role A_STREAMLIT_APPS_xxxx_APP_EXEC_USG to role xxxx_APP_RUN;
grant role A_STREAMLIT_APPS_xxxx_APP_EXEC_CRT to role xxxx_APP_RUN;
grant role A_DATAMART_xxxx_USG to role xxxx_APP_RUN;

オブジェクト権限はこんなイメージです。


use role SECURITYADMIN;

-- アプリ実行権限
grant usage on database STREAMLIT_APPS
  to role A_STREAMLIT_APPS_xxxx_APP_EXEC_USG;
grant usage on schema STREAMLIT_APPS.xxxx_APP_EXEC
  to role A_STREAMLIT_APPS_xxxx_APP_EXEC_USG;
grant usage on all streamlits in schema STREAMLIT_APPS.xxxx_APP_EXEC
  to role A_STREAMLIT_APPS_xxxx_APP_EXEC_USG;
grant usage on future streamlits in schema STREAMLIT_APPS.xxxx_APP_EXEC
  to role A_STREAMLIT_APPS_xxxx_APP_EXEC_USG;
  
-- アプリ開発権限
grant create streamlit on schema STREAMLIT_APPS.xxxx_APP_EXEC
  to role A_STREAMLIT_APPS_xxxx_APP_EXEC_CRT;
grant create stage on schema STREAMLIT_APPS.xxxx_APP_EXEC
  to role A_STREAMLIT_APPS_xxxx_APP_EXEC_CRT;
  
-- データマート読み取り専用
grant usage on database DATAMART
  to role A_DATAMART_xxxx_USG;
grant usage on schema DATAMART.xxxx
  to role A_DATAMART_xxxx_USG;
grant select on all tables in schema DATAMART.xxxx
  to role A_DATAMART_xxxx_USG;
grant select on future tables in schema DATAMART.xxxx
  to role A_DATAMART_xxxx_USG;

(B) データ更新 Streamlit アプリ（AにAPP_DATAの更新権限を足した形）

(B) のパターンは、「(A) の構成に加えて、xxxx_APP_DATA のテーブルをアプリから更新したい」ケースです。

利用者のロール構成は (A) と同じ
→ 追加の権限は一切付けない
追加でやるのは
- APP_DATA用AccessRoleの作成
- それをアプリ用ロールに紐づけ

だけです。

use role USERADMIN;

-- AccessRole：アプリ用データの作成
create role A_STREAMLIT_APPS_xxxx_APP_DATA_CRT;

-- APPロール側にだけ追加で付与
grant role A_STREAMLIT_APPS_xxxx_APP_DATA_CRT to role xxxx_APP_RUN;

APP_DATAスキーマの権限はこんなイメージです。

use role SECURITYADMIN;

-- データ作成権限
grant usage on schema STREAMLIT_APPS.xxxx_APP_DATA
  to role A_STREAMLIT_APPS_xxxx_APP_DATA_CRT;
grant create table, create view
  on schema STREAMLIT_APPS.xxxx_APP_DATA
  to role A_STREAMLIT_APPS_xxxx_APP_DATA_CRT;
grant select, insert, update, delete
  on all tables in schema STREAMLIT_APPS.xxxx_APP_DATA
  to role A_STREAMLIT_APPS_xxxx_APP_DATA_CRT;
grant select, insert, update, delete
  on future tables in schema STREAMLIT_APPS.xxxx_APP_DATA
  to role A_STREAMLIT_APPS_xxxx_APP_DATA_CRT;

まとめると：

(A) …
- APP_EXECスキーマのアプリ実行
- APP_EXECスキーマ内でのアプリ開発（アプリ側だけ）
- DATAMARTの読み取り（アプリ側だけ）
(B) …
- (A) と同じ構成に加えて
- APP_DATAのテーブルをアプリから作成・更新できるようにする

であり、利用者ロール側は (A) から一切増えない構成になっています。

小規模だからこそこの設計で回しやすい

現在は、事業部門ごとの個別ニーズに対応しているフェーズなので、

FunctionalRole（誰が使うか）と AccessRole（何ができるか）を分ける
APP_EXEC / APP_DATA / DATAMART の役割をスキーマで分離する
利用者用ロールには「アプリ利用権だけ」を渡す

といった設計でも十分に運用できます。

将来的に、
「全社共通のアプリで、データ側のアクセス権だけを細かくコントロールしたい」
といったニーズが出てきた場合には、
「アプリとデータの権限を分離する」
という “次のフェーズ” に進めばよい、という位置づけで使っています。

Sandbox DB の権限設計

次は、技術寄りユーザー向けのSandbox DBの話です。
弊社では毎年Pythonでのモデル開発も行う実践的なAI人材育成プログラムを実施しており、
その卒業生たちが主なSandbox利用者になっています。

Sandboxの使いどころ

Sandboxは、次のような用途で使っています。

自分たちでデータを取り込み、SQLを書いて集計や検証
NotebookでPythonを使ったデータ加工やモデル実行
Streamlitを使った簡単な業務アプリ作成

運用の基本方針

SANDBOXデータベースは全体共通
権限は共通ロールで付与
実際の作業単位は
SANDBOX_DB.USER_◯◯◯ のような 個人スキーマ
明示している利用ルールはひとつ：

個人スキーマ以外では作業しない

権限は少し広めに付けつつ、このルールでリスクをコントロールする運用方針です。
※ 取り込んでよいデータの内容（個人情報の扱いなど）は別途ルール化しています。

Sandboxの権限クエリ例


use role USERADMIN;

--SandboxDB用のロール作成
create role SANDBOX_USER;  -- FunctionalRoleロール
create role A_SANDBOX_DB_CRT;  -- AccessRoleロール

--ロール同士を紐づけ
grant role SANDBOX_USER to role SYSADMIN;
grant role A_SANDBOX_DB_CRT to role SANDBOX_USER;

use role SECURITYADMIN;

-- データベース & スキーマ利用
grant usage on database SANDBOX to role A_SANDBOX_DB_CRT;
grant usage on all schemas in database SANDBOX to role A_SANDBOX_DB_CRT;
grant usage on future schemas in database SANDBOX to role A_SANDBOX_DB_CRT;

-- CREATE 権限（既存スキーマ）
grant create table, create view, create materialized view, create dynamic table,
      create stage, create file format, create sequence,
      create function, create procedure,
      create external table, create pipe, create stream, create task,
      create notebook, create streamlit,
      create masking policy, create row access policy, create tag,
      create secret, create service
  on all schemas in database SANDBOX
  to role A_SANDBOX_DB_CRT;

-- CREATE 権限（FUTURE スキーマ）
grant create table, create view, create materialized view, create dynamic table,
      create stage, create file format, create sequence,
      create function, create procedure,
      create external table, create pipe, create stream, create task,
      create notebook, create streamlit,
      create masking policy, create row access policy, create tag,
      create secret, create service
  on future schemas in database SANDBOX
  to role A_SANDBOX_DB_CRT;

-- ステージの利用権限
grant write on all stages in database SANDBOX to role A_SANDBOX_DB_CRT;
grant read,write on future stages in database SANDBOX to role A_SANDBOX_DB_CRT;

「ルールでカバー」の理由

Sandboxはあえて権限でガチガチに縛らず、
「個人スキーマ以外では作業しない」 というルール運用にしています。

理由はシンプルで、

ユーザーが約20名と少ないこと
データ活用推進寄りのメンバーが多く、大きく外すリスクは小さいこと
まずは「使ってもらうこと」を優先したいフェーズであること

が挙げられます。

将来的に利用者が増えてきたら、

タグ／ポリシーによる持ち込みデータの制御
プロジェクト用サンドボックスの追加

など、次の段階に進めばよいと考えています。

意識している設計原則

StreamlitとSandboxを事業部門に展開する際、特に大事にしているポイントは次の4つです。

利用パターンごとに“型”を決める
Streamlit（APP_EXEC / APP_DATA / DATAMART）や Sandbox（個人スキーマ）など、先にパターン化しておくと迷わない。
“誰が使うか（FunctionalRole）” と “何ができるか（AccessRole）” を分離する
ロールを混ぜないことで、権限追加・棚卸し・管理がシンプルになる。
アプリ利用者ロールには「アプリ利用権」だけ渡す
データ参照・更新はすべてアプリ側に寄せ、Snowflakeで直接触らせない構造にする。
Sandboxは“緩めの権限 × 明確なルール”で運用する
権限は広めでも「個人スキーマ以外で作業しない」の一本ルールでリスクを抑える。

おわりに

Snowflakeを事業部門に展開する際、権限管理はどうしても悩みどころになります。
私たちのところではまず、

Tableau
Streamlit
Sandbox

の3パターンに利用を整理し、それぞれに合わせた権限＋ルールをセットで運用しています。

この記事の構成やSQLはあくまで一例ですが、
同じように「事業部門にSnowflakeを広げたい」と考えている方のたたき台になればうれしいです✨

「うちではこうしている」「ここはもっとこうした方がいい」などあれば、ぜひコメントで教えてください！

この記事はSnowflake流通コミュニティのLTでも話した内容です。
ゆるく情報交換できる場なので、興味があればぜひのぞいてみてください！
https://usergroups.snowflake.com/snowvillage/