Snowflake Roles 101:アクセス制御の完全ガイド

Snowflakeは、ユーザーや外部システムが何にアクセスし何を実行できるかを管理するため、ロールベースアクセス制御(RBAC)を採用しています。RBACでは、あるロールを持つことが、特定の権限を付与されていることを意味します。

まずは用語を整理しましょう。

• User(ユーザー):人(またはサービス)がSnowflakeに接続するためのエンティティ
• Object(オブジェクト):Userが適切な権限を持っている場合にアクセスできるエンティティ(テーブル、ビュー、データベースなど)
• Privilege(権限):そのRoleに付与されていれば、UserがObjectに対して実行できる操作
• Role(ロール):UserとPrivilegeをつなぐエンティティ。PrivilegeはRoleに、RoleはUserに付与されます。

Snowflakeはこう要約しています。

権限はロールに付与され、ロールはユーザーに付与されます。これにより、ユーザーがシステム内のオブジェクトに対して実行できる操作が決まります。

この4つの概念を軸に、以降のセクションと図を積み上げながら、最小構成でありながら必要十分なアクセス制御の形を作っていきます。

Users(ユーザー)

SnowflakeのUserとは、Snowflakeアカウントに接続して許可された操作を実行できるアイデンティティです。データチームのメンバーは一人ひとり、Snowflakeに接続してクエリを実行するためのSnowflake Userを持つべきです。Snowflake UserはBIツール(TableauやLookerなど)やELTツール(StitchやFivetranなど)といったサードパーティ製システムからも利用されます。

つまり、アクセス制御で問われる中心的なテーマは「Snowflake Userに何をさせるか」です。

Objects(オブジェクト)

ObjectはSnowflakeにおいてアクセス権を付与できる基本要素です。最もイメージしやすいのはデータベース、スキーマ、テーブルですが、ウェアハウスやストレージ統合などのアカウントレベルのオブジェクトも含まれます。

代表的なSnowflake Objectを以下に示します。

セキュア可能オブジェクト	レベル	説明
Database	アカウントレベル	他のすべてのセキュア可能オブジェクトを分離し、論理的にまとめる中核的なオブジェクト。
Schema	データベースレベル	テーブル、ビュー、ステージなどを論理的にまとめる単位。
Table	スキーマレベル	データを格納し物理ストレージを消費するオブジェクト。Snowflakeを活用するうえでの要となる存在で、用途別にいくつかの種類があります。
View	スキーマレベル	テーブルのように見せかけたオブジェクト。データへのアクセス手段を提供しますが、ストレージは消費しません。ビューは他のテーブルに対するクエリとして定義され、用途別にいくつかの種類があります。
Virtual Warehouse	アカウントレベル	クエリ実行やSnowflakeへのデータロードに必要な主要コンピュートリソース。
Storage Integration	アカウントレベル	S3(GCSやAzure Blob Storageを含む)バケットとSnowflakeを接続するオブジェクト。データのロードやアンロード、バケット内容への直接クエリを可能にします。
Snowpipe	スキーマレベル	S3(またはGCS、Azure Blob Storage)に新しいファイルが到着するたびに、テーブルへのデータロードを自動化するオブジェクト。
Stage	スキーマレベル	クラウドストレージ上のデータファイル(CSV、Parquetなど)の置き場所。内部(Snowflake管理)と外部(自己管理)の2種類があります。

Privileges(権限)

Privilegeはアクセス制御の根幹をなす概念で、オブジェクトに対する個別の操作、または一連の操作の実行を許可するものです。

たとえばSnowflake Tableに対しては、UserはSELECTでデータを取得する、INSERTで行を追加する、DELETEでデータを削除するといった権限を持つことができます。Snowflake Databaseに対しては、CREATE SCHEMAでスキーマを作成したり、MONITORで監視したりできます。

下表は、主要なオブジェクトに付与できる主要な権限を簡潔にまとめたものです。

オブジェクト	オブジェクト権限	説明
Database	USAGE	データベースの使用と参照が可能になります。ただし操作を行うには追加の権限が必要です。
	MONITOR	DESCRIBEコマンドの実行を可能にします。
	CREATE SCHEMA	データベース内でのスキーマ作成(クローン含む)を可能にします。
	IMPORTED PRIVILEGES	共有データベースにのみ適用され、他のアカウントロールが共有オブジェクトにアクセスできるようにします。詳しくはhttps://docs.snowflake.com/en/user-guide/data-share-consumers#option-1-objects-in-a-share-not-associated-with-a-database-roleを参照してください。
Schema	USAGE	スキーマの参照と使用が可能になりますが、スキーマ配下のオブジェクトを参照・操作するには別途権限が必要です。
	MONITOR	DESCRIBEコマンドの実行を可能にします。
	CREATE TABLE / CREATE VIEW / CREATE STAGE / CREATE PIPE	/ CREATE STAGE / CREATE PIPE スキーマ内でのテーブル / ビュー / ステージ / パイプの作成を可能にします。
Table	SELECT	テーブルへのクエリ実行によるデータ取得を可能にします。
	INSERT	テーブルへの行の挿入を可能にします。
	UPDATE	テーブル内の既存データの更新を可能にします。
	TRUNCATE	テーブル内の全データ削除を可能にします。
	DELETE	テーブルからの全行または特定の行の削除を可能にします。
View	SELECT	ビューに対するクエリ実行によるデータ取得を可能にします(ビューの基となるテーブルやそれらに対する権限は問いません)。
Stage	USAGE	SQL文での外部ステージの使用を可能にします。
	READ	内部ステージを読み取るコマンド(GET、LIST、COPY INTO)の実行を可能にします。
	WRITE	内部ステージへ書き込むコマンド(PUT、REMOVE、COPY INTO)の実行を可能にします。

Snowflakeアクセス制御で利用可能なオブジェクト権限の一覧はこちらで確認できます。

アクセス監査の際には、権限はオブジェクトが作成された場所に応じて異なるレベル(アカウントレベル、データベースレベル、スキーマレベル)で付与される、という点を覚えておくと役立ちます。

Ownership権限

Snowflakeはロールベースアクセス制御(RBAC)を採用しています […]

👆このセクションの冒頭の一文は、実は半分しか正しくありません。Snowflakeは、もう一つのアクセス制御モデルである任意アクセス制御(DAC:Discretionary Access Control)の重要な要素をRBACと組み合わせています。DACでは、すべてのオブジェクトに所有者が存在しなければなりません。

SnowflakeにおけるDACの実装では、各オブジェクトは作成時に使用されたロールが所有します。ロールがオブジェクトを所有するとは、そのオブジェクトに対するOWNERSHIP権限を持つことを意味します。

ここで重要なのは、オブジェクトを所有するのはUserではなくRoleであるという点です。データチームのアナリスト全員に同じロールが付与されているなら、あるアナリストが作成したオブジェクトは、結果としてアナリスト全員が所有することになります。

なお、オブジェクトのOWNERSHIP権限は他のロールへ移譲できます。たとえば、他ロールへのアクセス付与権を制限したい場合に、テーブルの所有権を「より強力な」ロールへ移譲する、といった使い方が考えられます。

将来オブジェクトに対する権限

アクセス制御を初期構成する段階では、対象のオブジェクトがまだ存在しないこともあります。それでも「作成されたら、このロールにアクセスを許可したい」と先に決まっているケースは少なくありません。Snowflakeでは、将来のオブジェクトに対して権限を付与しておくことで、こうした先回りが可能です。

たとえば、ANALYSTロールに対して、GOLDEN_DBデータベース内の将来のテーブル、または特定スキーマ内の将来のテーブルに対するSELECT権限を付与できます。将来オブジェクトへの権限付与の優先順位については、Snowflakeのドキュメントをご覧ください。

Roles(ロール)

Snowflakeのロールは鍵のようなものとイメージするとわかりやすいでしょう。🔑 自宅の鍵、車の鍵、そしておそらくはオフィスの鍵もあるはずです。仲の良いお隣さんがいれば、緊急時のために自宅の合鍵を預けているかもしれません。自宅の鍵は、自分とお隣さんの双方に自宅へのアクセスを与えます。

同じように、Snowflakeでもユーザーに付与されたロールが、さまざまな操作やオブジェクトへのアクセスを与えます。組織図がSnowflakeのロールにどう対応するか、図でイメージしてみましょう。

Snowflakeのロールには、大きく分けて3種類あります。

• アカウントロール
• データベースロール
• インスタンスロール

このほかに、Snowflake Native Applicationに紐づくアプリケーションロールもありますが、これは別記事を立てるに値する興味深いテーマであり、本稿Snowflake Roles 101の範囲を超えるため割愛します。

アカウントロール

Snowflake従来からのロールであるアカウントロールは、標準的なロールで以下の特徴を持ちます。

• アカウント内のすべてのセキュア可能オブジェクトに対して権限を付与できる
• 名前はアカウントレベルで一意
• Userや他のアカウントロールに付与できる

データベースロール

名前のとおり、データベースロールは特定のデータベースに紐づくロールで、次の特徴があります。

• そのデータベース配下のオブジェクト(スキーマ、テーブル、ビューなど)に固有の権限のみを付与できる
• 名前は作成元のデータベース内で一意
• 同一データベース内の他のデータベースロール、およびアカウントロールに付与できる
• Userに直接付与することはできない
• 所属するデータベースに対するUSAGE権限はデフォルトで付与されている

インスタンスロール

インスタンスロールは最も使用頻度の低い種類のロールです。Snowflakeクラスインスタンスに紐づき、アカウントロールに付与することで、ユーザーがそのクラスインスタンスのメソッドを実行できるようになります。

執筆時点では、クラスを作成できるのはSnowflakeのみです。利用可能なSnowflakeクラスの詳細はこちらをご覧ください。

どの種類のロールを使うべきか?

始めたばかりであれば、アカウントロールだけで十分長く運用できます。

面白くなるのは、データベースロールを検討し始めたときです。構成のシンプル化と標準化に役立ち、ACCOUNTADMINを使わなくてもデータベースの所有者が自前で権限を管理できるようになります。

さらに、Snowflake Sharesでデータを共有する場合、データベースロールを使えばアクセス制御をより柔軟に構成できます。

ロールは他のロールにも付与でき、これによってロール階層が形成されます。

ロール階層を理解する一番の近道は具体例を見ることです。下図のロール階層では、SYSADMINロールを持つSplinterは、DATA_ENG_ROLE、ANALYST_ROLE、DB_MANAGER_ROLEのすべてを包含する権限を持ちます。一方Kimは、DATA_ENG_ROLEとDB_MANAGER_ROLEの権限だけを持ちます。

Snowflakeアカウントを作成してAdmin / Users & Rolesを開くと、Snowflakeがデフォルトで作成するシステム定義ロール群が表示されます。これらのロールは削除できず、各ロールが持つ標準の権限セットを変更することもできません。それぞれに次のような役割があります。

• ACCOUNTADMIN - アカウントレベルで何でもできる「神モード」ロールです。誰に付与するかは慎重に判断してください。ACCOUNTADMINはSECURITYADMINとSYSADMINのすべての権限を継承します。
• SECURITYADMIN - アカウントレベル権限のMANAGE GRANTSが付与されており、アカウント内のあらゆるオブジェクトに対する権限を他のロールへ付与・取り消しできます。SECURITYADMINはUSERADMINから渡されるすべての権限も継承します。
• USERADMIN - 名前のとおり、ユーザーの作成と管理に使うロールです(アカウントレベル権限のCREATE USERとCREATE ROLEを活用します)。
• SYSADMIN - アカウント内のあらゆるオブジェクト(データベース、ウェアハウス、その他スキーマレベルのオブジェクトを含む)を作成できるロールです。
• PUBLIC - アカウント内のすべてのユーザーにデフォルトで付与されていますが、明示的にアクセス権を付与されない限りできることはほとんどありません。とはいえ、重要なデータに対して誤って権限を与えてしまうとアカウント内の全ユーザーがアクセスできてしまうため、細心の注意が必要です。いっそPUBLICロールには一切権限を付与しない、という運用が無難でしょう。😉

最後に、ORGADMINには別途触れておく必要があります。Snowflakeアカウントの追加作成など、組織レベルの操作に使われるロールで、デフォルトのロール階層にきれいには収まりません。

カスタムロールを作成してロール階層を組み立てる際、Snowflakeは最終的にすべてのカスタムロールがSYSADMINの子孫ロールになるよう推奨しています。

多数のSnowflakeアカウントに携わってきた経験から言うと、データベースオブジェクトの大半がACCOUNTADMINによって作成・所有されているケースをよく見かけます。これはおおむね望ましくない運用で、アクセス制御がほとんど検討されていないこと、そしてACCOUNTADMINがデフォルトロールとして使われていることを示すサインです。データやユーザーの誤削除といった致命的なミスにつながりかねません。アクセス制御のベストプラクティスについては、本シリーズのPart IIで取り上げる予定です。🙌

ユーザーのデフォルトロール

Snowflakeに接続する際、ユーザーはセッションを確立しますが、ほとんどの場合そのセッションに対してロールを指定する必要があります。指定がなければ、Snowflakeはユーザーのデフォルトロールを使います。

セカンダリロール

セカンダリロールは、一人のユーザーが複数のロールのアクセス権を同時に活用できるようにする仕組みです。多くのSnowflakeユーザーはプライマリロール(単一ロール)だけを使っていますが、セカンダリロールは複数ロールを統合する手間を省ける強力な機能です。

セッションでプライマリロールを設定するuse roleコマンドと同様に、use secondary rolesを実行できます。違いは、このコマンドが2つのオプションを取る点です。

1. use secondary roles all はユーザーに付与されているすべてのロールを有効化します
2. use secondary roles none はセカンダリロールを無効化します

はい、わかります――「そろそろSQLを見せて!! 💢」という声が聞こえてきそうです。

新規Snowflakeアカウントを立ち上げ、KimとRufusがそれぞれのニーズに応じて使えるようにするエンドツーエンドの例を通して、パズルを完成させましょう。

概要は次のとおりです。

• User、Role、Databaseを作成します。

use role SECURITYADMIN;
create role DATA_ENGINEER_ROLE;
create role DB_MANAGER_ROLE;
create role ANALYST_ROLE;

use role USERADMIN;
create user KIM;

use role SYSADMIN; -- objects are owned by the active role
create database SOURCE_DB;
create warehouse ANALYSIS_WH;

• セキュア可能オブジェクトに対する権限をロールに付与します。

use role SECURITYADMIN;

grant USAGE, MODIFY, CREATE SCHEMA
	on database SOURCE_DB to role DB_MANAGER_ROLE;
grant USAGE on database SOURCE_DB to role ANALYST_ROLE;

grant USAGE, OPERATE
	on warehouse ANALYSIS_WH to role ANALYST_ROLE;

• ロール同士を階層でつなぎ、権限の継承関係を作ります。

use role SECURITYADMIN;

grant role DB_MANAGER_ROLE to role DATA_ENGINEER_ROLE;
grant role ANALYST_ROLE to role DATA_ENGINEER_ROLE;
grant role DATA_ENGINEER_ROLE to role SYSADMIN;

• ユーザーにロールを付与し、セキュア可能オブジェクトへのアクセスを与えます。

use role SECURITYADMIN;

grant role DATA_ENGINEER_ROLE to user KIM;
grant role ANALYST_ROLE to user RUFUS;

これで、次のような構成が出来上がります。

1. Kimは以下が可能:
2. SOURCE_DB内でのスキーマ作成と使用
3. ANALYSIS_WHの使用と操作
4. Rufusは以下が可能:
5. SOURCE_DBの使用(スキーマやデータベースに対する追加権限が足りないのでは?と思った方は💯正解ですが、ここでは簡略化のため省いています。)
6. ANALYSIS_WHの使用と操作

ごくシンプルな構成ですが、SnowflakeでRBACモデルを自前で実装するために必要な要素はすべて揃っています。続編のPart IIでは、Snowflake RBACのベストプラクティスと、現場目線での具体的な推奨事項をご紹介します。