Snowflake RBAC設計：ロール階層・最小権限・機能/アクセスロール

Snowflakeの権限設計は、データ基盤の「品質」と「監査耐性」を左右する最初の分岐点です。とりあえずACCOUNTADMINで動かしてしまうと、後から所有権や職務分掌を作り直すことになり、確実に手戻りが発生します。本稿ではシステムロールの役割分担、機能ロールとアクセスロールの分離、権限継承を活かした最小権限の作り方を、AWS（IAM・PrivateLink・KMS）との接点も含めて、現場で運用してきた視点から整理します。

01RBACの3要素：セキュラブルオブジェクト・ロール・権限

Snowflakeのアクセス制御はロールベース（RBAC）で、DAC（オブジェクト所有者が権限を委譲できる仕組み）を組み合わせた設計になっています。登場人物は3つだけです。セキュラブルオブジェクト（アクセスを制御できる対象。テーブル・ビュー・スキーマ・データベース・ウェアハウスなど）、ロール（権限を受け取る器で、ユーザーやほかのロールに付与できる）、権限（SELECT・INSERT・USAGE・OWNERSHIPなど、オブジェクトへの操作許可）です。ポイントは「grantで明示的に許可されない限りアクセスは拒否される」というデフォルト拒否の思想で、これが最小権限を作りやすくしています。ユーザーに権限を直接与えるのではなく、必ずロールを介して与える——この一点を徹底するだけで、権限管理は劇的に見通しがよくなります。

02システムロールを正しく理解する

Snowflakeには最初から役割の異なる組み込みロールが用意されています。これらを混同して使うことが、権限設計が崩れる最大の原因です。ACCOUNTADMINはSYSADMINとSECURITYADMINを内包する最上位ロールで、課金・アカウント設定・パラメータ変更など「アカウント全体」に関わる操作を担います。ごく少数の担当者に限定し、MFAを必須にすべきロールです。SECURITYADMINはグローバルなMANAGE GRANTS権限を持ち、あらゆるオブジェクトのグラントを統制できます。加えてUSERADMINを継承します。USERADMINはCREATE USER／CREATE ROLE権限を持ち、ユーザーとロールの作成・管理に専念します。SYSADMINはウェアハウス・データベースなどオブジェクトの作成・管理を担う、いわば「基盤の親方」です。PUBLICは全ユーザー・全ロールに自動付与される擬似ロールで、明示的なアクセス制御が不要な場合の共有に使います。組織レベルの管理にはORGADMIN（現在はGLOBALORGADMINへ移行が進行中）があります。

03権限は下位から上位へ継承される

ロールは階層構造を組めます。あるロールをほかのロールに付与すると、下位ロールが持つ権限は上位ロールへ自動的に継承されます。「ロールに紐づく権限は、その上位にあるすべてのロールに継承される」という原則です。既定のシステムロール階層もこの原則でできています——ACCOUNTADMINはSECURITYADMINとSYSADMINを、SECURITYADMINはUSERADMINを継承します。だからACCOUNTADMINは事実上すべての権限を持つわけです。カスタムロールを設計するときは、この「下から上へ流れる」性質を利用します。ベストプラクティスは、最上位の機能ロールをSYSADMINに付与すること。こうしておくと、SYSADMIN（およびその上のACCOUNTADMIN）が配下ロールの作ったオブジェクトを管理できる状態が保たれます。逆に、SYSADMIN配下に接続し忘れたロールが作ったオブジェクトは、SECURITYADMINのMANAGE GRANTSでしか面倒を見られなくなり、運用の孤島になります。

04機能ロールとアクセスロールを分ける

カスタムロールを設計する際の要が、機能ロール（Functional Role）とアクセスロール（Access Role）の分離です。アクセスロールは「何ができるか」を表し、特定オブジェクトへの具体的な権限（例：SALESスキーマの読み取り、FINANCEスキーマの読み書き）を束ねます。機能ロールは「誰が使うか」を表し、業務上の職種（データアナリスト、データエンジニア、BI閲覧者など）に対応します。ユーザーには機能ロールだけを割り当て、機能ロールに必要なアクセスロールを付与する——この2層にしておくと、新しいメンバーが入っても機能ロールを1つ与えるだけで済み、権限の変更もアクセスロール側を直せば全員に波及します。アクセスロールを直接ユーザーに配ってしまうと、人が増えるたびに同じ作業を繰り返し、調整も一人ずつ手作業になり、権限のスプロール（散逸）を招きます。

05最小権限を「運用」ではなく「仕組み」にする

最小権限は、運用ルールで守ろうとすると必ずどこかで崩れます。仕組みで担保するのがSnowflakeの流儀です。ひとつは管理アクセススキーマ（MANAGED ACCESS）です。CREATE SCHEMA ... WITH MANAGED ACCESSで作ると、オブジェクトの所有者であってもグラント判断ができなくなり、スキーマ所有者かMANAGE GRANTS権限を持つロール（既定ではSECURITYADMIN）だけがグラントできます。権限付与の判断を一箇所に集約でき、所有者が勝手に権限を配る事故を構造的に防げます。もうひとつがフューチャーグラント（ON FUTURE）です。「このスキーマに今後作られる全テーブルのSELECTを、このロールに与える」といった初期権限を定義でき、テーブルが増えるたびに手でGRANTする作業から解放されます（データベース全体への未来グラントにはMANAGE GRANTSが必要）。さらにOWNERSHIP（所有権）の設計も重要で、誰がオブジェクトを所有するかを機能ロール単位で最初に決めておくと、後述する所有権の偏りを避けられます。

06落とし穴：ACCOUNTADMIN常用を検証段階で是正する

ここは事故が起きやすい典型なので、検証段階でしっかり踏み抜いておきます。ある案件のPoCを検証環境で立ち上げた際、初期はスピード優先でACCOUNTADMINのまま検証用データベース・ウェアハウス・ステージを作成していました。ここで顕在化したのが所有権の偏りです。ACCOUNTADMINで作ったオブジェクトの所有者はACCOUNTADMINになり、あとからSYSADMIN配下の機能ロールへ管理を委譲しようとすると、OWNERSHIPの移管や再GRANTが連鎖的に必要になり、手戻りが発生することが検証環境ではっきり分かりました。この構造のまま本番へ持っていくと、権限の可視性が落ち、監査時に「なぜこのロールがこのオブジェクトを見られるのか」を説明しづらくなります。そこで本番展開の前に構成を作り直し、オブジェクト作成はSYSADMIN配下の機能ロール／ユーザー・ロール管理はUSERADMIN／グラント統制はSECURITYADMIN／アカウント設定のみACCOUNTADMINという職務分掌を確定させました。ACCOUNTADMINは少数・MFA必須・日常運用や自動化スクリプトには使わない、というガードレールも同時に敷いています。結果として本番では所有権の付け替え作業をゼロにでき、権限起因の重大障害0を継続しています。低コストの小規模導入から、大手飲料メーカー様・大手冷凍倉庫事業者様クラスの規模まで、業種を問わず同じ設計原則を最初に適用するのが、遠回りに見えて最短だと考えています。

07AWSとの接点：IAM・PrivateLink・KMSとロール設計

SnowflakeはAWS上で動くため、Snowflake内のRBACとAWS側のIAMは「地続き」で設計すると効果的です。代表例がストレージ統合（Storage Integration）で、S3へのアクセスをアクセスキーの直接埋め込みではなくAWS IAMロールで委譲します。CREATE STORAGE INTEGRATIONではSTORAGE_AWS_ROLE_ARNでIAMロールを指定し、外部ID（External ID）でSnowflakeとAWS間の信頼関係を確立します。この統合を作成できるのはACCOUNTADMINか、グローバルなCREATE INTEGRATION権限を持つロールに限られる点は、Snowflake側のRBAC設計にそのまま組み込む対象です。CREATE INTEGRATIONのような「アカウントの外部接続を左右する権限」は機能ロールに安易に配らず、専用の管理ロールに閉じ込めるのが安全です。通信経路はAWS PrivateLinkでインターネットを経由させず閉域化し、S3側の暗号化はAWS KMSで鍵管理する、という多層防御と組み合わせます。SnowflakeのロールでSTORAGE INTEGRATIONやEXTERNAL VOLUME（Iceberg用）へのUSAGE権限をどの機能ロールに与えるかまで含めて設計すると、「アプリからS3まで、誰が何を触れるのか」が一本の線でつながり、監査に強い基盤になります。