データ基盤

Snowflake ロールとは？権限をロールに与えて階層で渡す仕組み

2026/10/28 （更新: 2026/11/3）シリーズ「Snowflake 入門」第8回 / 全13回

🤖 AIを使用して執筆

シリーズSnowflake 入門全13回

このシリーズの紹介へシリーズ一覧へ

ロール
Snowflake
権限
カスタムロール
ACCOUNTADMIN
SYSADMIN
SECURITYADMIN
ロール階層
RBAC
セカンダリロール
データベースロール
多要素認証
SHOW GRANTS
USAGE
将来の付与
ネットワークポリシー
サービスユーザー
最小権限
組織アカウント
データ基盤
ユーザー
オブジェクト
アカウント
データベース
アクセス
管理
パスワード
スキーマ
組織
サインイン
サービス
仕事
既定
本番
データ
制御
有効
環境
ウェアハウス
所有
階層
プライマリロール
システムロール
管理者
r1
必須
種類
開発
USERADMIN
アクセスロール
SELECT
ページ
所有者
予定
機能
アカウントロール
Control
SERVICE
Access
NULL
リリース
認証情報
付与
単位
操作
方式
自動
設定
GLOBALORGADMIN
LEGACY_SERVICE
インスタンスロール
アクセススキーマ
スーパーユーザー
CREATE
MANAGE
ドキュメント
GRANT
smith
セッション
ROLE
TYPE
UBAC
アドレス
システム
アプリ
ビュー
段階的
IP
以前
以外
信頼
共有
報告
場所
将来
担当
期間
複数
認証
適用

背景・問い・要点

背景

データベースでは、誰がどのデータを読み、何を変えてよいかを決める必要がある。決め方の一つは、権限を人ごとに与えることである。人が増え、仕事が変わるたびに、一人ひとりの権限を直すことになる。

Snowflake では、権限をロールに与え、ロールをユーザーに与える。この方式を RBAC（Role-based Access Control、ロールベースのアクセス制御）という¹。ロールは、権限をまとめて持つ Snowflake のオブジェクトである。

問い

Snowflake のロールとは何で、権限はどうやってユーザーに届くのか。

要点

ロールは、権限をまとめて持つ Snowflake のオブジェクトである。管理者が権限をロールに与え、そのロールをユーザーや別のロールに与えるので、ユーザーは自分のロールと、そのロールに与えられた別のロールの権限を使える。

表を読むロールには、表の SELECT だけでなく、ウェアハウス、データベース、スキーマの USAGE が要る。Snowflake は、仕事に合わせたカスタムロールを作って SYSADMIN の下につなぎ、ACCOUNTADMIN は少数の人に限るよう勧めている。パスワードでサインインする人には、多要素認証（MFA、Multi-Factor Authentication）が段階的に必須になっている。

モデル・例示

表を一つ読めるロールを作り、ユーザーに与える

表を一つ読ませるだけでも、ロールには表の SELECT のほかにウェアハウス、データベース、スキーマの USAGE を与え、そのロールをユーザーに渡す必要がある。ユーザー smith に表 d1.s1.t1 を読ませたいとして、Snowflake のアクセス制御の設定手順に出てくるカスタムロール r1 で考える²。ロールを作るのは USERADMIN 以上のロールで、権限やロールを与えるのは SECURITYADMIN などのロールで行う²。

まず、ロールを作り、表を読むのに要る四つの権限を与える²。

CREATE ROLE r1;

GRANT USAGE ON WAREHOUSE w1 TO ROLE r1;     -- 計算に使うウェアハウス
GRANT USAGE ON DATABASE d1 TO ROLE r1;      -- 表の入ったデータベース
GRANT USAGE ON SCHEMA d1.s1 TO ROLE r1;     -- 表の入ったスキーマ
GRANT SELECT ON TABLE d1.s1.t1 TO ROLE r1;  -- 表そのもの

USAGE は、そのオブジェクトを使う権限で、SELECT は表を読む権限である。表を問い合わせるには、問い合わせを動かすウェアハウスの USAGE が要る²。表の SELECT のほかに、表を入れているデータベースとスキーマにも USAGE などの権限が要る³。

次に、ロールをユーザー smith に与え、サインインしたときに使うロール（既定のロール）にする。さらに、ロールを SYSADMIN に与えて、ロールの階層につなぐ²。

GRANT ROLE r1 TO USER smith;
ALTER USER smith SET DEFAULT_ROLE = r1;
GRANT ROLE r1 TO ROLE sysadmin;

ロールが持つ権限を見る： SHOW GRANTS TO ROLE で、ロールに与えた権限を一覧できる。同じ r1 について、Snowflake のアクセス制御のベストプラクティスのページが載せている結果を、列を絞って示す³。

SHOW GRANTS TO ROLE r1;

| privilege | granted_on | name     | granted_to | grantee_name | granted_by    |
|-----------+------------+----------+------------+--------------+---------------|
| USAGE     | DATABASE   | D1       | ROLE       | R1           | SECURITYADMIN |
| USAGE     | SCHEMA     | D1.S1    | ROLE       | R1           | SECURITYADMIN |
| SELECT    | TABLE      | D1.S1.T1 | ROLE       | R1           | SECURITYADMIN |
| USAGE     | WAREHOUSE  | W1       | ROLE       | R1           | SECURITYADMIN |

与えた四つの権限が、一行ずつ並ぶ。名前は大文字で返る。権限を与えたのは SECURITYADMIN のロールである。r1 に与えたのは、表 t1 を問い合わせるのに要る権限だけで、表のデータを変える権限は与えていない。

r1 を SYSADMIN に与えたので、SYSADMIN を持つ管理者も、r1 の権限を使える¹。

権限の考え方：オブジェクト、権限、ロール、ユーザー

Snowflake のアクセス制御は、四つの概念でできている¹。

セキュリティ保護可能なオブジェクト： アクセスを与えられる対象。与えられていなければ、アクセスは拒まれる。
権限： オブジェクトに対するアクセスの段階。複数の権限で、細かく決められる。
ロール： 権限を与えられる対象。ロールは、ユーザーや別のロールに与えられる。
ユーザー： Snowflake が認める、人かサービスの ID。ユーザーにも権限を与えられる。

オブジェクトは、コンテナの階層に入っている。いちばん上が組織で、その下にアカウント、データベース、スキーマが続き、表やビューはスキーマの中にある¹。

Snowflake のアクセス制御は、三つの方式を組み合わせている¹。

DAC（Discretionary Access Control、任意アクセス制御）： オブジェクトには所有者がいて、所有者がアクセスを与える。
RBAC： 権限をロールに与え、ロールをユーザーに与える。ふつうはこれを使う。
UBAC（User-based Access Control、ユーザーベースのアクセス制御）： 権限をユーザーに直接与える。

Snowflake は、本番の環境では RBAC を勧めている。UBAC は、個人の開発や共同作業のような場面のためのものとしている³。

オブジェクトは、一つのロールが所有する。所有するのは、ふつうはそのオブジェクトを作ったときのロールである¹。Snowflake には、権限の確認を省略できる「スーパーユーザー」のようなものはない¹。

システムロール：Snowflake が最初から決めているロール

Snowflake には、最初から決まっているロールがある¹。

ロール	役割
GLOBALORGADMIN	組織の単位の仕事（アカウントの管理など）。組織アカウントにだけある
ACCOUNTADMIN	SYSADMIN と SECURITYADMIN を含む、いちばん上のロール
SECURITYADMIN	権限の付与を管理し、ユーザーとロールを作る。USERADMIN を含む
USERADMIN	ユーザーとロールの管理だけを行う
SYSADMIN	ウェアハウスやデータベースなどのオブジェクトを作る
PUBLIC	すべてのユーザーとロールに自動で与えられる疑似ロール

以前の組織のロール ORGADMIN は、今後なくなる予定で、Snowflake は GLOBALORGADMIN を使うよう勧めている¹。システムロールは消せず、Snowflake が与えた権限も取り消せない¹。システムロールは、アカウントを管理する権限を持って作られている。Snowflake は、その権限とオブジェクトごとの権限を同じロールに混ぜないのがよいとし、権限を足すなら、システムロールではなくカスタムロールに与えて、そのロールをシステムロールに与えるよう勧めている¹。

ACCOUNTADMIN の扱い： ACCOUNTADMIN は、アカウントの管理に使う、システムのいちばん上のロールである¹。最も強いロールだが、スーパーユーザーではない。オブジェクトを見たり管理したりできるのは、ACCOUNTADMIN か、その下のロールが権限を持つときだけである³。Snowflake は、次の三つを強く勧めている³。

ACCOUNTADMIN は、限られた人だけに与える。
少なくとも二人に与える。
ACCOUNTADMIN を持つ人は、多要素認証を使う。

さらに、次のことも勧めている³²。

ACCOUNTADMIN を、ユーザーの既定のロールにしない。
最も厳しく守るべきオブジェクトでない限り、ACCOUNTADMIN でオブジェクトを作らない。
自動で動かす処理には、ACCOUNTADMIN 以外のロールを使う。

カスタムロール：仕事に合わせて作り、SYSADMIN の下につなぐ

自分で作るロールを、カスタムロールという。作れるのは USERADMIN 以上のロールか、CREATE ROLE の権限を持つロールである²。作ったばかりのロールは、どのユーザーにもロールにも与えられていない¹。

Snowflake は、最小権限の原則に従い、組織の仕事に合わせたカスタムロールを作って、少ないオブジェクトだけを操作できるようにするよう勧めている²。カスタムロールは、いちばん上を SYSADMIN に与えて、階層につなぐ¹。SYSADMIN につながっていないロールが所有するオブジェクトは、システムの管理者が管理できない¹。ACCOUNTADMIN でさえ、カスタムロールが作ったオブジェクトを、既定では変えたり消したりできない³。

ロール階層： ロールを別のロールに与えると、ロール階層ができる。下のロールの権限は、上のロールが受け継ぐ¹。ロールを所有するロールは、所有しているだけでは、そのロールの権限を受け継がない。受け継ぎは、ロールを与えてできた階層の中でだけ起きる¹。

アクセスロールと機能ロール： Snowflake は、二種類のロールを組み合わせる形を勧めている³。

アクセスロール： データベースやウェアハウスなどのオブジェクトの権限を持つロール。たとえば、あるデータベースを読むだけのロールと、読み書きするロールを分けて作る。
機能ロール： 組織の仕事に合わせたロール。経理の担当や分析の担当のように、仕事に要るアクセスロールをまとめて持つ。

アクセスロールを機能ロールに与え、機能ロールをユーザーに与える。二つに技術的な違いはなく、違うのは使い方だけである³。

ロールの種類： Snowflake のロールには、アカウントのどのオブジェクトにも使えるアカウントロールのほかに、データベースロール、クラスのインスタンスに使うインスタンスロール、Snowflake Native App に使うアプリケーションロールなどがある¹。セッションで有効にできるのはアカウントロールだけで、データベースロールとインスタンスロールは、アカウントロールに与えて使う¹。

データベースロール： 一つのデータベースの中だけで使うロールを、データベースロールという。そのデータベースのオブジェクトの権限だけを持てる³。データを共有するときには、共有するデータベースにデータベースロールを入れておくと、受け取った側がそれを自分のロールに与えられる³。

プライマリロールとセカンダリロール

セッションで使っているロールを、プライマリロールという。プライマリロールは一度に一つだが、そのほかに、いくつでもセカンダリロールを有効にできる¹。

オブジェクトを作る（CREATE）には、プライマリロールの権限しか使えない。作ったオブジェクトは、プライマリロールが所有する¹。
作る以外の操作には、プライマリとセカンダリのどのロールの権限も使える¹。たとえば、別々のロールが読めるデータベースの表どうしを、一つの問い合わせで結合できる¹。

ユーザーのセカンダリロールの既定は、今は「与えられたすべてのロール」（ALL）である。サインインすると、与えられたロールがすべてセカンダリロールとして有効になる。以前の既定は NULL で、セカンダリロールは有効にならなかった。2025 年 1〜2 月のリリースで既定が ALL に変わり、3 月のリリースからすべてのアカウントで ALL になった⁴⁵。ただし、ALL に変わったのは、この設定を決めていない（または NULL にした）ユーザーだけである。ユーザーごとに値を決めていれば、その値は変わらない。値を () にしたユーザーには、セカンダリロールが無い⁴。

ロールを通さずにユーザーへ直接与えた権限は、今は、すべてのセカンダリロールが有効なときだけ効く²。2026 年 10 月のリリースで入った変更では、セカンダリロールの設定にかかわらず効くようになる。この変更は今は既定で無効で、管理者が試しに有効にできる⁶。

権限を与える：GRANT、将来の付与、管理アクセススキーマ

権限は GRANT で与える。スキーマの表をまとめて指定する ALL TABLES IN SCHEMA は、その時点である表にだけ効き、後で作る表には効かない²。

将来の付与： これから作る表やビューに、指定した権限を自動で与える仕組みである³。同じ種類のオブジェクトについてデータベースとスキーマの両方に設定すると、スキーマのほうが使われ、データベースのほうは無視される²。
管理アクセススキーマ： このスキーマでは、オブジェクトの所有者は権限を与えられない。スキーマの所有者か、MANAGE GRANTS の権限を持つロールだけが与える¹。権限の管理を一か所に集められる。

MANAGE GRANTS の権限を最初から持つのは、SECURITYADMIN と ACCOUNTADMIN である⁷。権限が足りずに SQL が失敗したときは、関数 EXPLAIN_PRIVILEGES で、足りない権限を調べられる。オブジェクトの権限を持たない人に調べさせるには、RESOLVE ALL ON ACCOUNT の権限を与える⁸。

サインインを守る：多要素認証とサービスユーザー

2024 年には、Snowflake の利用企業のアカウントからデータが盗まれた。調査した Mandiant は、Snowflake 社自身の社内環境が破られた証拠は見つからず、盗まれた利用者の認証情報が使われたと報告した。同じ報告は、侵入が多く成功した主な要因として三つを挙げた。被害を受けたアカウントは多要素認証を有効にしていなかった。盗まれた認証情報は替えられないまま使える状態で、中には盗まれてから何年もたつものもあった。信頼できる場所からだけつなげるネットワークの許可リストも無かった⁹。

Snowflake は、パスワードを使う人のユーザーには多要素認証を必須にし、サービスのユーザーにはパスワードを使わせない変更を、段階的に進めている¹⁰。多要素認証は、パスワードに加えて、一度だけ使えるコードを出す認証アプリやパスキーなどの二つ目の要素で本人を確かめる方式である¹¹。2026 年 10 月時点のドキュメントの予定は、次のとおりである。日付は見込みで、第 1・第 2 段階の期間はすでに過ぎ、第 3 段階の期間も 2026 年 10 月で終わる。第 1 段階は動作変更バンドルに合わせて進み、第 2・第 3 段階はアカウントごとに順に適用され、適用の日が知らされる¹⁰。

時期（見込み）	変わること
2025 年 9 月〜2026 年 1 月	Snowsight にパスワードでサインインする人に、多要素認証が必須になる
2026 年 5 月〜7 月	新しく作る人のユーザーは、パスワードでサインインするとき、どこからでも多要素認証が必須。新しいサービスのユーザーは SERVICE の種類だけ
2026 年 8 月〜10 月	パスワードでサインインするすべての人のユーザーに、例外なく多要素認証が必須。LEGACY_SERVICE は SERVICE に移され、パスワードが使えなくなる

2024 年 12 月の Snowflake のブログは、2025 年 11 月までにパスワードだけのサインインを止めるとしていた¹²。今の予定では、最後の段階は 2026 年 8 月〜10 月である¹⁰。

ユーザーの種類： ユーザーの TYPE で、人かサービスかを決める¹³。

PERSON： 人のユーザー。TYPE を決めないか NULL にすると、人として扱う¹⁰。
SERVICE： 人の操作なしに Snowflake とやりとりするサービスやアプリ¹⁴。パスワードではサインインできない¹³。
LEGACY_SERVICE： パスワードを使えるサービスのユーザー。なくなる予定である¹³。

ほかに SERVICE_AGENT などの種類もある¹³。

サービスのユーザーには、キーペア認証や OAuth を使う¹⁵¹⁶。プログラム用のアクセストークンも使えるが、サービスのユーザーで使うには、ネットワークポリシーをかけておく必要がある¹⁷。

ネットワークポリシー： 既定では、Snowflake にはどこからでもつなげる¹⁸。ネットワークポリシーで、つないでよい IP アドレスを決められる。新しく作るポリシーは、ネットワークルールを使う¹⁸。Snowflake の Well-Architected Framework は、信頼できる IP アドレスだけを許すネットワークポリシーを決めておくよう勧めている。盗まれた認証情報が、知らない場所から使われるのを防げる¹⁵。

アカウントとデータベースの分け方

一つの会社のアカウントは、組織でまとめられる。組織の管理者は、リージョンやクラウドの違うアカウントをまとめて作り、管理できる¹⁹。組織の単位の仕事をする組織アカウントは、Enterprise Edition 以上で使える²⁰。

開発と本番のような環境をアカウントで分けると、ロールもアカウントごとに別になる。アカウントごとに、ユーザー、ロール、データベース、ウェアハウスを別に持つからである²¹。一つのアカウントで分けるなら、同じアカウントのロールと権限で、環境ごとのアクセスを分けて管理することになる²²。どちらにするかについて、Snowflake のドキュメントは次のように書いている。

DCM Projects の設計のページは、環境ごとに別のアカウントにするのを、一般に勧めるとしている。本番を開発から完全に分け、開発者が本番のデータに触れる範囲を制限できるからである。ただし、アクセスを注意して管理すれば、一つのアカウントでも複数の環境を扱えるとしている。データベースがはっきり分かれていれば扱いやすく、アカウント単位のオブジェクトや連携が絡むと難しくなる²²。
同じページは、一つのアカウントなら、本番のデータと仕組みをクローンして、変更を本番の前に試しやすいとしている²²。
DevOps のページは、開発、テスト、本番の環境を分けると、開発の作業を本番から切り離せ、意図しない影響やデータの破損のおそれを減らせるとしている。デプロイの対象は、環境ごとにアカウント（またはデータベース）に対応させられる²³。

出典23件

Snowflake「Overview of Access Control | Snowflake Documentation」日付なし、2026年10月28日取得. https://docs.snowflake.com/en/user-guide/security-access-control-overview — 日本語版の題は「アクセス制御の概要」。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷ ↩¹⁸ ↩¹⁹ ↩²⁰ ↩²¹ ↩²² ↩²³ ↩²⁴
Snowflake「Configuring access control | Snowflake Documentation」日付なし、2026年10月28日取得. https://docs.snowflake.com/en/user-guide/security-access-control-configure — カスタムロールの例。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹
Snowflake「Access control best practices | Snowflake Documentation」日付なし、2026年10月28日取得. https://docs.snowflake.com/en/user-guide/security-access-control-considerations — ACCOUNTADMIN の扱い、アクセスロールと機能ロール、SHOW GRANTS の例。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹²
Snowflake「Default value of DEFAULT_SECONDARY_ROLES object property on users changed to (‘ALL’) | Snowflake Documentation」日付なし、2026年10月28日取得. https://docs.snowflake.com/en/release-notes/bcr-bundles/2024_08/bcr-1692 ↩ ↩²
Snowflake「2024_08 Bundle | Snowflake Documentation」日付なし、2026年10月28日取得. https://docs.snowflake.com/en/release-notes/bcr-bundles/2024_08_bundle — 9.7 のリリース（2025 年 3 月 17〜27 日）で一般に有効。 ↩
Snowflake「User grants: Privileges granted to a user apply regardless of secondary roles (Disabled by default) | Snowflake Documentation」日付なし、2026年10月28日取得. https://docs.snowflake.com/en/release-notes/bcr-bundles/2026_08/bcr-2438 ↩
Snowflake「GRANT <privileges> … TO ROLE | Snowflake Documentation」日付なし、2026年10月28日取得. https://docs.snowflake.com/en/sql-reference/sql/grant-privilege ↩
Snowflake「Troubleshooting access control issues | Snowflake Documentation」日付なし、2026年10月28日取得. https://docs.snowflake.com/en/user-guide/security-access-control-troubleshooting ↩
Mandiant「UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion | Google Cloud Blog」2024年6月11日、2026年10月28日取得. https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion ↩
Snowflake「Planning for the deprecation of single-factor password sign-ins | Snowflake Documentation」日付なし、2026年10月28日取得. https://docs.snowflake.com/en/user-guide/security-mfa-rollout — 日付は見込み。試用のアカウントなどは対象外。 ↩ ↩² ↩³ ↩⁴
Snowflake「Multi-factor authentication (MFA) | Snowflake Documentation」日付なし、2026年10月28日取得. https://docs.snowflake.com/en/user-guide/security-mfa ↩
Brad Jones「Snowflake Will Block Single-Factor Password Authentication by November 2025」Snowflake Blog、2024年12月1日、2026年10月28日取得（アーカイブ）. https://web.archive.org/web/20241202210136/https://www.snowflake.com/en/blog/blocking-single-factor-password-authentification/ ↩
Snowflake「User management | Snowflake Documentation」日付なし、2026年10月28日取得. https://docs.snowflake.com/en/user-guide/admin-user-management ↩ ↩² ↩³ ↩⁴
Snowflake「CREATE USER | Snowflake Documentation」日付なし、2026年10月28日取得. https://docs.snowflake.com/en/sql-reference/sql/create-user ↩
Snowflake「Security & Governance Pillar」Snowflake Well-Architected Framework、2026年6月17日更新、2026年10月28日取得. https://www.snowflake.com/en/developers/guides/well-architected-framework-security-and-governance/ — 最小権限、多要素認証、ネットワークポリシー。 ↩ ↩²
Snowflake「Key-pair authentication and key-pair rotation | Snowflake Documentation」日付なし、2026年10月28日取得. https://docs.snowflake.com/en/user-guide/key-pair-auth ↩
Snowflake「Using programmatic access tokens for authentication | Snowflake Documentation」日付なし、2026年10月28日取得. https://docs.snowflake.com/en/user-guide/programmatic-access-tokens ↩
Snowflake「Controlling network traffic with network policies | Snowflake Documentation」日付なし、2026年10月28日取得. https://docs.snowflake.com/en/user-guide/network-policies ↩ ↩²
Snowflake「Introduction to organizations | Snowflake Documentation」日付なし、2026年10月28日取得. https://docs.snowflake.com/en/user-guide/organizations ↩
Snowflake「Organization accounts | Snowflake Documentation」日付なし、2026年10月28日取得. https://docs.snowflake.com/en/user-guide/organization-accounts ↩
Snowflake「Creating an account | Snowflake Documentation」日付なし、2026年10月28日取得. https://docs.snowflake.com/en/user-guide/organizations-manage-accounts-create ↩
Snowflake「Architectural recommendations for DCM Projects | Snowflake Documentation」日付なし、2026年10月28日取得. https://docs.snowflake.com/en/user-guide/dcm-projects/dcm-projects-enterprise — 一つのアカウントでも扱えるとする。 ↩ ↩² ↩³
Snowflake「DevOps with Snowflake | Snowflake Documentation」日付なし、2026年10月29日取得. https://docs.snowflake.com/en/developer-guide/builders/devops-with-snowflake ↩

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。