❄️

Snowflakeにおける権限管理について

に公開
Snowflake
tech

はじめに

Snowflakeについて日本語で体系化されているドキュメントがあまり見かけない中で、
権限管理について勉強する機会があったので個人用にまとめます。

対象読者

  • Snowflakeについてこれから勉強する人
  • Snowflakeによる権限管理に興味のある方

Snowflakeにおける権限管理

Snowlflakeなどのデータウェアハウスでは様々な役職やシステムから利用されるプラットフォームであるため、安心・安全な利用のために適切な権限管理が必要です。
Snowflakeではロールに権限を集約させる。ロールに対して許可アクションを付与し、ロールをユーザーに付与することでユーザーに操作を許可する。
このように、ロールに基づいて権限を管理する方式をロールベースアクセスコントロール（RBAC） といいます。

また、Snowflakeではテーブルなど各オブジェクトに所有者がおり、所有者はそのオブジェクトへのアクセスを許可できる任意アクセス制御（DAC）もある。

ロールに付与できる権限

Snowflakeでは、すべてのオブジェクトの権限を任意のロールに付与することができる。
付与できる権限は以下のようなレベルに大別することができる。

  • アカウントレベル権限
  • データベースレベル権限
  • スキーマレベル権限
  • スキーマオブジェクトレベル権限

アカウントレベル権限

アカウント全体に対して適用される権限。データベースを作成する権限（CREATE DATABASE）など、特定のデータベースやスキーマに依存しない権限などが該当する。
その他にも下記のような権限もアカウントレベル権限になる。

  • CREATE ROLE
  • CREATE USER
  • CREATE WAREHOUSE
  • EXECUTE TASK

アカウントレベル権限をロールに付与するには下記のクエリを実行する。

grant <account_lv_privilege> on account to role <role_name>;
-- 例
grant create role on account to role example_role;

データベースレベル権限

データベースレベル権限では、データベースに対して適用される権限。単一のデータベースを利用する権限（USAGE DATABASE）や、スキーマを作成する権限（CREATE SCHEMA）などが含まれる。

データベースレベル権限をロールに付与するには下記のクエリを実行する。

grant <database_lv_privilege> on database <database_name> to role <role_name>;
-- 例
grant usage database on database sample_db to role example_role;

スキーマレベル権限

スキーマに対して適用される権限。
スキーマ内のテーブルを作成する権限（CREATE SCHEMA）や、ステージの作成権限（CREATE STAGE）などがある。

スキーマレベル権限をロールに付与するには下記のクエリを実行する。

grant <schema_lv_privilege> on schema <schema_name> to role <role_name>;
-- 例
grant create schema on schema sample_db.sample_schema to role example_role;

スキーマオブジェクトレベル権限

スキーマ内のオブジェクトに対して適用される権限。
スキーマオブジェクトは、スキーマに属するオブジェクトであり、テーブルやビュー、プロシージャなどが含まれる。
スキーマオブジェクトレベル権限では以下の権限が含まれる。

  • テーブルの参照・更新・データ削除権限（SELECT, INSERT, DELETE TABLE）
  • ステージの利用兼毛（USAGE STAGE）
  • 関数の利用権限（USAGE FUNCTION）
grant <schema_object_lv_privilege> on <schema_object_type> <schema_object_name> to role <role_name>;
-- 例
grant select on table sample_db.sample_schema.sample_table to role example_role;

ロールツリー

Snowflakeでは階層型のロール権限を作成することができる。
例えば、Privilege Cという権限を付与されたRole_3をRole_2に付与することで権限を継承することができる。
ただし、Role_2にのみ付与したい権限があったとしても、Role_1にRole_2が付与されていた場合、Role_1にも同じ権限が付与されてしまうため、ロール設計に注意が必要となる。
上記のようなロール設計にならないようにするために役職ロールとアクセスロールという考え方が非常に重要になる。

役職ロールとアクセスロールモデル

役職ロール（Functional Role） とは、現実世界の役職や部署・権限に対応するロール。
例えば、開発者向けであればDEVELOPERというロールを、マーケティングチームの分析者であればMARKETING_ANALYSTというロールを付与するという感じである。

一方、アクセスロール（Access Role） とは、実際のデータベースやテーブルなど、Snowflakeの各種リソースへのアクセス権限を保持しているロールである。

例えば、DB_Aへのフルアクセスを許可するDB_A_FULLACCESSというロールには、データベース内での各種リソースの作成や変更などが許可されている。一方、参照権限のみを保持しているDB_A_READONLYというロールは、データベース内の各種リソースの参照権限のみを保持している。
そして、上記のアクセスロールを役職ロールに付与することにより、実際のユーザーに対して権限管理を実現することができる。

DEVELOPERロールには、DB_A_FULLACCESSロールを付与することで開発者が自由にDB_Aを操作可能になる。一方、MARKETING_ANALYSTロールにはDB_A_READONLYロールを付与することで、DB_Aのデータを参照することができる。

参考情報

https://docs.snowflake.com/ja/user-guide/security-access-control-overview
https://docs.snowflake.com/ja/user-guide/security-access-control-privileges

Discussion