第2章アカウント管理とデータガバナンス / 想定学習時間:30〜40分 / 最終確認:2026年8月

2-2. システム定義ロールとカスタムロール設計

🎯 この節の学習目標

6つのシステム定義ロール(ORGADMIN・ACCOUNTADMIN・SECURITYADMIN・USERADMIN・SYSADMIN・PUBLIC)の役割を対応付けられる
カスタムロールをSYSADMINに集約するロール階層のベストプラクティスと、その理由を説明できる
機能ロールとアクセスロールによる2層設計パターンを説明できる

1. システム定義ロールの全体像

Snowflake のアカウントには、最初からシステム定義ロールが用意されています。これらは削除できず、それぞれ明確な守備範囲を持ちます。「どの作業はどのロールか」の対応付けは確実に押さえましょう。

ロール	守備範囲(できること)	補足
ORGADMIN	組織(organization)レベルの管理。組織内のアカウントの作成・表示、組織全体の利用状況の確認	アカウント内ではなく組織を扱うロール。現在は組織アカウントのGLOBALORGADMINへの移行が推奨され、ORGADMINは段階的廃止予定
ACCOUNTADMIN	アカウント内の最上位ロール。SYSADMINとSECURITYADMINを継承し、アカウントパラメータの管理、リソースモニターの作成など最終的な全権を持つ	付与するユーザーは最小人数にし、全員にMFAを推奨
SECURITYADMIN	アカウント全体の権限付与の管理。グローバルなMANAGE GRANTS権限を持ち、任意のGRANT/REVOKEを実行・変更できる	USERADMINを継承するため、ユーザー・ロールの管理もできる
USERADMIN	ユーザーとロールの作成・管理専用(CREATE USER / CREATE ROLE権限)	作成したユーザー・ロールの所有者として管理する
SYSADMIN	アカウント内のオブジェクトの作成・管理。ウェアハウス、データベース、スキーマ、テーブルなど	カスタムロールの集約先として使うのがベストプラクティス
PUBLIC	疑似ロール。すべてのユーザー・ロールが暗黙的に保持する。PUBLICに付与した権限は全員に及ぶ	明示的なアクセス制御が不要なオブジェクトにのみ使う

📝 試験のポイント

混同しやすいのは次の3点です。(1)ユーザーやロールを作るのはUSERADMIN(SECURITYADMINはそれを継承)、(2)データベースやウェアハウスなどオブジェクトを作るのはSYSADMIN、(3)組織レベル(アカウントの作成など)はORGADMIN。「〇〇を作成するのに最小権限のロールはどれか」という形で問われたら、この守備範囲で切り分けます。

2. システムロールの階層関係

システム定義ロールは既定で次の階層を構成しています。上位ロールは下位ロールの権限を継承します。

ACCOUNTADMINアカウントの最上位。SYSADMINとSECURITYADMINを継承

SECURITYADMINMANAGE GRANTS。USERADMINを継承

SYSADMINオブジェクトの作成・管理。カスタムロールの集約先

↑SECURITYADMINはUSERADMINを、SYSADMINはカスタムロールを配下に持つ

USERADMINユーザー・ロールの作成

カスタムロール群machine learning / analyst / etl など。最終的にSYSADMINへGRANT

↑すべてのユーザー・ロールが暗黙に保持

PUBLIC疑似ロール。付与した権限は全員に及ぶ

図:システム定義ロールの階層。ACCOUNTADMINを頂点に、SECURITYADMIN→USERADMIN、SYSADMIN→カスタムロールという継承関係を作る(ORGADMINは組織レベルのため別枠)

ORGADMIN はアカウント内の階層には組み込まれず、組織管理という別のレイヤーを担当します。なお組織管理については、現在は組織アカウント(organization account)で使う GLOBALORGADMIN ロールへの移行が推奨されており、ORGADMIN は段階的に廃止される予定です。試験対策としては「組織レベルの管理ロール=ORGADMIN(後継としてGLOBALORGADMIN)」と押さえておけば十分です。

3. カスタムロール設計のベストプラクティス

実運用ではシステムロールをそのまま使うのではなく、業務に応じたカスタムロールを作成します。このとき Snowflake が推奨する設計原則が試験でも問われます。

(1)カスタムロールは階層を組み、最終的にSYSADMINに集約する

カスタムロールは GRANT ROLE custom_role TO ROLE SYSADMIN; のように、直接または他のカスタムロールを経由してSYSADMINの配下に接続します。理由は明快です。

💡 具体例:集約しないと何が起きるか

カスタムロール etl_role がどのシステムロールにも接続されていない状態で、etl_role がデータベース raw_db を作成したとします。すると raw_db の所有者は etl_role であり、SYSADMINからは raw_db が見えず、管理もできません(ACCOUNTADMINなら最終的に介入できますが、日常管理から外れた「宙に浮いたオブジェクト」になります)。etl_role を SYSADMIN に付与しておけば、SYSADMIN は継承によって etl_role の所有オブジェクトをすべて管理できます。

-- カスタムロールを作成し(USERADMIN以上で実行)、階層に組み込む
CREATE ROLE etl_role;
GRANT ROLE etl_role TO ROLE SYSADMIN;

(2)ACCOUNTADMINの取り扱い

ACCOUNTADMINを付与するユーザーは最小限の人数にとどめ、対象ユーザーにはMFAを必ず設定します
ユーザーのデフォルトロールにACCOUNTADMINを設定しない(ログインしただけで最上位権限のセッションになるのを防ぐ)
日常のオブジェクト作成・開発作業にACCOUNTADMINを使わない。ACCOUNTADMINで作成したオブジェクトは下位ロールから管理しづらくなり、意図しない所有権の集中を招きます
ACCOUNTADMIN保持ユーザーを1人にすると、そのユーザーがロックアウトされた際に困るため、2人以上を確保することも推奨されています

4. 機能ロールとアクセスロールの2層設計

カスタムロールの設計パターンとして、Snowflake はアクセスロール(access role)と機能ロール(functional role)の2層に分ける方法を推奨しています。

	アクセスロール	機能ロール
何を表すか	オブジェクトへの権限の束(例:sales_db読み取り、sales_db書き込み)	人の職務・役割(例:アナリスト、データエンジニア)
権限の持ち方	オブジェクト権限(USAGE・SELECTなど)を直接GRANTされる	必要なアクセスロールをGRANTされて継承する
付与先	機能ロール(ユーザーには直接付与しない)	ユーザー、および最終的にSYSADMIN

-- アクセスロール:オブジェクト権限の束
CREATE ROLE sales_db_read;
GRANT USAGE ON DATABASE sales_db TO ROLE sales_db_read;
GRANT USAGE ON ALL SCHEMAS IN DATABASE sales_db TO ROLE sales_db_read;
GRANT SELECT ON ALL TABLES IN DATABASE sales_db TO ROLE sales_db_read;

-- 機能ロール:職務を表し、アクセスロールを束ねる
CREATE ROLE analyst;
GRANT ROLE sales_db_read TO ROLE analyst;

-- 機能ロールをユーザーと階層へ
GRANT ROLE analyst TO USER hanako;
GRANT ROLE analyst TO ROLE SYSADMIN;

この2層に分けると、「新しいメンバーが来たら機能ロールを1つ付与するだけ」「新しいデータベースができたらアクセスロールを作って必要な機能ロールに接続するだけ」となり、権限管理の見通しが大きく向上します。

なお、ここまで説明したアカウントレベルのロールとは別に、データベースロール(database role)という種類のロールもあります。CREATE DATABASE ROLE db名.ロール名 で作成する、特定のデータベースの中で完結するロールで、そのデータベース内のオブジェクト権限だけを束ねられます。アカウントロールと同様に階層化でき、上で述べたアクセスロールをデータベースロールとして実装することも可能です。また、データベースロールはシェア(データ共有)に含められるため、共有先のアカウントに「このデータベースのこの範囲だけ」という粒度でアクセスを渡せる点も特徴です(データ共有は5-3で扱います)。

✅ この節のまとめ

ORGADMIN=組織管理(後継として組織アカウントのGLOBALORGADMINが推奨され、ORGADMINは段階的廃止予定)、ACCOUNTADMIN=アカウント最上位、SECURITYADMIN=MANAGE GRANTS(権限付与の管理、USERADMINを継承)、USERADMIN=ユーザー・ロール作成、SYSADMIN=オブジェクト作成・管理、PUBLIC=全員が暗黙保持。
カスタムロールは階層を組み、最終的にSYSADMINへ集約する。集約しないと、そのロールが作ったオブジェクトはSYSADMINから見えない・管理できない状態になる。
ACCOUNTADMINは最小人数+MFA必須、デフォルトロールにしない、日常作業に使わない、ロックアウト対策として2人以上を確保。
設計パターン:アクセスロール(オブジェクト権限の束)→機能ロール(職務)→ユーザーの2層構成が推奨される。
データベースロールは特定のデータベース内で完結するロールで、DB内の権限を束ねられ、シェアに含めて共有先へ渡せる。

練習問題

問1. 新しいユーザーとロールを作成する権限を持つ、最も権限の小さいシステム定義ロールはどれか。

ACCOUNTADMIN
SECURITYADMIN
USERADMIN
SYSADMIN

解答と解説を見る

正解:C

ユーザー・ロールの作成(CREATE USER / CREATE ROLE)を専門に担うのはUSERADMINです。AとBでも作成は可能ですが(SECURITYADMINはUSERADMINを、ACCOUNTADMINはさらにその上位を継承するため)、「最も権限の小さい」という条件に合いません。最小権限の原則から答えはUSERADMINです。DのSYSADMINはデータベースやウェアハウスなどオブジェクトの作成・管理が守備範囲で、ユーザー作成の権限は持ちません。

問2. カスタムロールを最終的にSYSADMINに付与(集約)することが推奨される理由として最も適切なものはどれか。

カスタムロールはSYSADMINに付与しないと、ユーザーに付与できないため
SYSADMINがロール階層の継承を通じて、カスタムロールが所有するオブジェクトを管理できるようにするため
SYSADMINに付与しないとカスタムロールにMFAが適用されないため
カスタムロールの数に上限があり、SYSADMIN配下でないとカウントされないため

解答と解説を見る

正解:B

カスタムロールがSYSADMIN配下にないと、そのロールが作成・所有するオブジェクトはSYSADMINから見えず管理できない「宙に浮いた」状態になります。階層に組み込めば、SYSADMINは継承によりそれらを一元管理できます。Aは誤りで、階層と無関係にロールはユーザーへ付与できます。CのMFAはユーザー認証の仕組みであり、ロール階層とは無関係です。Dのような上限・カウントの仕組みはありません。

問3. ACCOUNTADMINロールの運用に関するベストプラクティスとして適切なものを2つ選べ。

付与するユーザーを最小限にし、対象ユーザー全員にMFAを設定する
すべての開発者のデフォルトロールに設定し、権限不足のエラーを防ぐ
日常のオブジェクト作成にはACCOUNTADMINではなくSYSADMIN以下のロールを使う
ACCOUNTADMINを保持するユーザーは必ず1人だけにする

解答と解説を見る

正解:A、C

ACCOUNTADMINは最小人数+MFAで保護し(A)、日常作業には使いません(C)。ACCOUNTADMINで作成したオブジェクトは下位ロールから管理しづらくなるためです。Bはベストプラクティスの正反対で、デフォルトロールにACCOUNTADMINを設定することは明確に非推奨です。Dも誤りで、ロックアウト時に復旧できなくなるリスクを避けるため、2人以上に付与しておくことが推奨されています。

問4. PUBLICロールの説明として正しいものはどれか。

アカウント作成時にだけ存在し、その後は自動的に削除されるロールである
すべてのユーザーとロールが暗黙的に保持する疑似ロールで、PUBLICへの付与は全員への付与を意味する
外部(インターネット)からの匿名アクセスを許可するためのロールである
ORGADMINが組織レベルで管理する共有ロールである

解答と解説を見る

正解:B

PUBLICはアカウント内のすべてのユーザー・ロールが暗黙に保持する疑似ロールです。そのため、PUBLICにGRANTした権限はアカウント内の全員が使えるようになり、明示的なアクセス制御が不要なオブジェクトに限って使うべきです。Aは誤りで、PUBLICは削除できません。Cは誤りで、Snowflakeへのアクセスには必ず認証が必要であり、匿名アクセスの仕組みではありません。DはPUBLICとORGADMINの守備範囲を取り違えています。