本記事は、
Snowflake公式ドキュメント「アクセス制御の考慮事項」をベースに、
Snowflakeのアクセス制御（Access Control）に関する考慮事項とプラクティスの要点をまとめたものです
以下記事の続編として、実践的な設計指針や考慮事項を整理します
基本的なアクセス制御の仕組みについては、前回記事を参照ください
本記事の内容は執筆時点（2025年12月）の情報に基づいています。最新情報は公式ドキュメントをご確認ください
ACCOUNTADMINロール
ACCOUNTADMINロールの立ち位置
ACCOUNTADMIN ロールは、システムで最も強力なロールであり、アカウントレベルのパラメーター設定などを担当する。
ただし、一般的なDBのスーパーユーザーロールのような使い方はできない
-
可能なこと:
- Snowflakeの請求・クレジットデータの表示・管理
- 実行中の SQL ステートメントの停止
-
できないこと:
- アカウント内の任意のオブジェクトを表示・管理することはできない（それらのオブジェクトへの権限を持つ下位ロールが、明示的に付与されている必要がある）
- 別のユーザーが実行したクエリ結果の表示はできない
ACCOUNTADMINと他のシステム定義ロールの関係性
ACCOUNTADMIN ロールは、他のシステム管理者ロール（USERADMIN, SECURITYADMIN, SYSADMIN）の親ロールとして最上位に位置する
- アカウントがプロビジョニングされると、最初のユーザーにデフォルトで
ACCOUNTADMINロールが付与される - 初期セットアップとして、そのユーザーを用いて
USERADMINロールを持つ新規ユーザーを作成することが推奨される - その後のユーザー管理は、
USERADMINロール（またはグローバルのCREATE USER権限を持つロール）で行うべき
ACCOUNTADMIN ロールの割り当て
ACCOUNTADMIN ロールをユーザーに割り当てる際は、以下の点に注意する
- 最小限の割り当て: 組織内の限られた人数にのみ割り当てる
- MFAの必須化: 割り当てられたユーザーは、ログインに多要素認証（MFA）を使用する
- 冗長性の確保: パスワードリセット操作などを補完するために、少なくとも2人のユーザーに割り当てる（Snowflakeサポート経由でのリセットには時間がかかる場合があるため）
ACCOUNTADMIN ロールを使う場面/使わない方がいい場面
ACCOUNTADMIN ロールを使う場面
- システムの初期セットアップタスクの実行
- アカウントレベルの特定のオブジェクト操作やタスク管理
ACCOUNTADMIN ロールを使わない方がいい場面
1. オブジェクトを作成しない
絶対的な必要性がない限り、ACCOUNTADMIN ロールでオブジェクトを作成しないこと
オブジェクト作成は SYSADMIN ロールで行うことを推奨
誤操作を防ぐため、ユーザーの既定ロール（DEFAULT_ROLE）を ACCOUNTADMIN 以外に設定しておく
ALTER USER <ユーザー名> SET DEFAULT_ROLE = SYSADMIN;
2. 自動スクリプトで使用しない
自動化スクリプトには、ACCOUNTADMIN 以外の適切なロールを設定する
- オブジェクト操作:
SYSADMINロールまたはその下位ロール - ユーザー/ロール管理:
SECURITYADMINロールまたは適切な権限を持つロール
データベースオブジェクトとカスタムロール
データベースオブジェクトへのアクセス
データベースオブジェクト（テーブル、ビュー、ステージなど）にアクセスするには、階層構造に沿った権限が必要
具体的には、以下の3つすべての権限を適切に設定する
- データベースに対する
USAGE権限 - スキーマに対する
USAGE権限 - 特定のオブジェクト（テーブル等）に対する操作権限（
SELECT等）
-- データベース mydb 上の USAGE 権限を付与
GRANT USAGE ON DATABASE mydb TO ROLE <ロール名>;
-- スキーマ myschema 上の USAGE 権限を付与
GRANT USAGE ON SCHEMA mydb.myschema TO ROLE <ロール名>;
-- テーブル mytable 上の SELECT 権限を付与
GRANT SELECT ON TABLE mydb.myschema.mytable TO ROLE <ロール名>;
カスタムロールの管理
作成したカスタムロールは、以下の対象に割り当てる
- ロールによって作成されたオブジェクトを管理する ロール
- ロールに関連付けられたオブジェクト権限を使用する ユーザー
デフォルトでは、ACCOUNTADMIN ロールであっても、カスタムロールによって作成されたオブジェクトを変更・削除することはできない
そのため、カスタムロールは必ずロール階層に組み込み、最終的に SYSADMIN ロール（または ACCOUNTADMIN）が親となるように構成する
ロール階層の設計方針（アクセスロールと機能ロール）
ロール階層を適切に設計し、オブジェクトへのアクセス権とビジネス機能を整合させることが重要
推奨されるアプローチとして、「アクセスロール」と「機能ロール」を分けて管理する方法が提唱されています
- アクセスロール (Access Roles): 特定のデータベースオブジェクトに対する権限（Read, Writeなど）をまとめたロール
- 機能ロール (Functional Roles): 職務やビジネス機能（Analyst, Data Engineerなど）に対応するロール。ユーザーにはこのロールを割り当てる
推奨される階層構造
ロール階層の振り返り
- ロールは、他のロールに付与できる（ロール階層の形成）
- 下位層ロールに付与された権限は、上位層ロールも利用可能（権限の継承）
構築フロー:
- 必要な“権限のまとまり”ごとに、アクセスロールを作る
- 業務や役職ごとに、機能ロールを作る（必要に応じて機能ロール間の階層も作成）
- 機能ロールに、必要なアクセスロールを付与する
-
SYSADMINロールに、最上位の機能ロールを付与する（システム管理者が管理可能にするため） - ユーザーに、必要な機能ロールを割り当てる
データベースオブジェクトとデータベースロール
データベースロールとは
データベースロール（Database Role）は、権限のスコープ範囲が特定のデータベース内に限定されたロール
- 制限: アカウントレベルの権限を持つことはできない
-
所有権: データベースオブジェクトの所有者（
OWNERSHIP）にはなれるが、データベース自体の所有者にはなれない
データベースロールの活用イメージ
ユースケース
1. 管理の容易さ（委任管理と階層構造）
データベース所有者（OWNERSHIP 保持者）は、そのデータベース内でデータベースロールを作成・管理できる
そのため、アカウントレベルの管理者（SECURITYADMIN等）に依存せず、データベース単位での柔軟な権限管理が可能となる
また、データベースロール同士で階層構造を形成することも可能。
最上位のデータベースロールをアカウントレベルのカスタムロールに付与することで、既存のロール階層と統合できる
データベースロールをアカウントロールに付与すると、そのデータベースに対する USAGE 権限が暗黙的に付与される
そのため、明示的に GRANT USAGE ON DATABASE ... を実行する必要はない
2. データ共有（Secure Data Sharing）
データベースロールを使うことで、データの共有元/共有先のアクセス管理がしやすくなる
共有元（プロバイダー）は、共有データベース内にデータベースロールを作成し、特定のデータへのアクセス権を付与できる
共有先（コンシューマー）は、そのデータベースロールを自アカウントのロールに付与するだけで、適切なアクセス権を得ることができる
注意点：セッションでのアクティブ化
データベースロールは、USE ROLE コマンドなどでセッション中に直接アクティブ化（切り替え）することはできない
データベースロールが付与されたカスタムロール（アカウントロール）を使用することで、間接的に権限を利用するようにする
データベースオブジェクトのその他検討事項
管理アクセススキーマの使用
スキーマには2種類のモードがある
- 通常のスキーマ: オブジェクト所有者が、他のロールにそのオブジェクトへの権限を付与できる
-
管理アクセススキーマ (Managed Access Schema): スキーマ所有者（または
MANAGE GRANTS権限を持つロール）のみが、スキーマ内のオブジェクトに対する権限付与を管理できる(オブジェクト所有者は権限管理できない)
権限管理を一元化し、意図しない権限の拡散を防ぐためには、管理アクセススキーマ の使用が推奨される
将来の付与（Future Grants）を使用
「将来の付与」機能を使用すると、スキーマ内で将来作成されるオブジェクトに対して、自動的に権限を付与するルールを定義することができる
（テーブル作成のたびに GRANT 文を実行するような運用の手間を省略できる）
-- スキーマ s1 内に将来作成されるテーブルへの SELECT 権限を ロール r1 に付与
GRANT SELECT ON FUTURE TABLES IN SCHEMA s1 TO ROLE r1;
既存のテーブルと将来のテーブルは別扱い。既存テーブルにも権限を付与したい場合は、別途クエリを実行する必要がある
複製オブジェクトと権限
データベースやスキーマを複製（CLONE）する場合の権限の扱いに注意が必要
- 複製オブジェクト自体: 新規オブジェクトとみなされ、ソースオブジェクトの権限は継承されない
- 子オブジェクト: 複製されたコンテナ（DB/スキーマ）内の子オブジェクト（テーブル等）は、ソースの子オブジェクトの権限状態を保持する
UBAC と RBAC
比較と使い分け
Snowflakeのアクセス制御の基盤は RBAC (Role-Based Access Control) モデル
スケーラビリティ、管理の一貫性、監査の容易さの観点から、本番環境や組織レベルでは RBAC が推奨される
一方で、UBAC (User-Based Access Control) は、特定のユーザーに直接権限を付与するモデル
以下のようなシナリオでは、UBAC が有用
- 個人開発環境
- Streamlitアプリの共同開発など、少人数でのコラボレーション
- RBACを補完する形での、一時的な細かいアクセス制御
注意点：付与の拡散を防ぐ
UBACを使用する場合でも、権限管理が煩雑になる「付与の拡散」を防ぐ必要がある
これには、前述の 管理アクセススキーマ が有効
管理アクセススキーマを使用すれば、オブジェクト所有者が勝手に個別のユーザーへ権限を付与することを制限でき、RBAC/UBACの統制を保つことができる
権限の監視
どのロールやユーザーにどのような権限が付与されているかは、ACCOUNT_USAGE スキーマのビューを使って監視・監査できる
-
GRANTS_TO_ROLES: ロールへの権限付与状況 -
GRANTS_TO_USERS: ユーザーへの直接付与状況（UBACの監視）
定期的にこれらのビューを確認し、意図しない権限付与が行われていないかチェックすることがセキュリティ上重要