こんにちは。喜田と申します。
「DBエンジニアが学ぶSnowflake」シリーズ化！なんて話を自分から持ち出して早1ヶ月。
思い思いに学ぶ～語るなどと言ってる場合じゃなく、ありがたいことに実案件での対応が必要になり、ベストプラクティス系の最短経路を試しては実装するという日々でありました。

そんな対応もようやく少し落ち着き、時間が取れてきたので、1ヵ月前を思い出し、ベストプラクティスからは一旦頭を切り替えて、アーキテクチャ的なところの興味深いポイントを語っていきたいと思います！

ご注意ください！！！この記事では！ベストプラクティスは！！語りません！！！

---

本記事のテーマは 「Snowflakeの権限管理」です。

権限管理が特徴的であるという話題はSnowflakeを勉強し始めるとよく耳にします。
「ロールベースの権限管理」などと称され、それがオリジナリティのある方式で、それゆえ何だか優れているっぽい、という情報が溢れています。
それがなぜ優れているのか。どういう観点で嬉しいのか、思う所がありますので語っていきたいと思います！

ロールベースの権限管理

Snowflakeの権限管理では、ロールの考え方を理解している必要があります。

Snowflakeのロール

ロール＝権限の集合体です。
最小の権限はテーブルなと個々のオブジェクトに対するSELECT、INSERT、DELETEといったあらゆる操作であり、またテーブルそのものの作成、削除、定義変更だったり、テーブル以外のオブジェクト（ビューとかファンクションとか）に対する操作もすべて同列の権限の一つです。
これらの権限をあるロールに渡しておけば、そのロールをユーザーに渡すことで、ユーザーは与えられた権限を行使することができます。ロールをロールに渡すこともできます。（階層型ロール）

と書いてみましたが、これ自体はSQL標準にあるデータベース内の権限管理の一般的な方法で、Oracle/PostgreSQL育ちの私からするとかなりとっつきやすい方式であったことを前提として述べておきます。

BigQueryやRedShiftとの違い

インフラ全体の中のDWHサービスであるということ

前回のブログでも書いたのですが、BigQueryやRedShiftはGCPやAWSでつくるインフラ全体の中のデータストアサービスの位置づけで提供されています。
GCPやAWSでのシステム開発PJがあって、インフラの一部として「RDBにするかDWHにするか？データの特性を考えて今回はDWH」というわけです。権限の話でいうと、クラウド上での開発やインフラ管理に関するあらゆる権限がIAMロールで制御され、データベース内のテーブル操作やデータへのアクセス権限もそこに統合されています。

従来のデータベースが期待するDBユーザ管理

BigQuery、RedShift、さらにはOracle、PostgreSQLといったRDBMS製品も含めたデータベース一般の話を少し。長らくシステム開発においてはWeb-AP-DBといった一般的な3層アーキテクチャとして、UI部分を整えて、業務ユーザには完成されたシステムを利用させてきました。データベースが意識するログインユーザは、APサーバからのお決まりの接続定義によるアクセスであって、個々人が直接DBにアクセスして野良クエリを叩くことを想定しないというのが多かったのではないかと思います。

このことを権限という観点で言い換えると、GCPやAWSでのIAMロールは、システム開発全体の中の、システム的な・サーバー運用的なユーザ管理や権限管理であって、そうやって出来上がった正規のアプリケーションからのアクセスは基本的に信頼することになります。野良アクセスに対してはそもそもDBへの接続情報をユーザに開示しません。
（APやSaaS側には個人アカウントでログインさせ、この人にはこのダッシュボードは見せてOKみたいな制御はAP側の機能としてやるイメージです。）

最近のデータ界隈ではModern Data Stackの流れでUI部分にはいい感じのSaaSを当てはめることができ、システム開発感は薄れているかもしれませんが、それでもやはりインフラ管理者がいて、どのSaaSを使わせるかといった製品評価～利用開始までの設計・設定（つまりDBユーザ準備や権限設定）はやっぱり従来のシステム開発のお作法を踏襲しているケースも多そうです。

Snowflakeに求められる権限管理

Snowflakeはどうでしょうか。
Snowflakeは単なるインフラとしてのDWHではなく「データ共有プラットフォーム」であると理解しています。（世の中であんまりこういう言い方を聞かないですが、私はそういう意味で独自のポジションにいると思ってます。）
1000人の従業員がいればSnowflakeに1000人分のログインユーザーを作成し、

• 各々が許可されたデータに好きにアクセスする
• 自分の担当業務から生まれたデータをアップする
• 社内に公開する

といった、データそのものをコンテンツとする共有プラットフォームです。（youTubeが動画をコンテンツとする動画共有プラットフォームである、みたいなことと同じ）
すべてのビジネスパーソンがデータを身近に扱い、共有知の宝庫として社内のデータを探索・分析して知見を得るというビジョンがそこにあると思っています。

長くなりましたが、Snowflakeではコンテンツとしてのデータそのものに対する権限管理にフォーカスできる点が他のDB製品との違いであり、製品ビジョンを実現する肝になっているように思います。インフラ開発・運用でやってきたようなIAMベースの権限管理とは完全に切り離して、データそのものに対する個人レベルの権限管理をしたいという命題に対して、洗練された権限管理が必要になります。

ちょっと補足①
Oracle、PostgreSQL、RedShiftは、Snowflakeとほぼ同じコマンドでDBユーザーを作り、ロールを作り、ロールにロールを付与して、テーブル等オブジェクト権限の管理ができます。ただし、業務ユーザーからDBへの直接接続を許しクエリさせる、業務ユーザーとDBユーザを1:1でマッピングさせるような使わせ方をしてこなかったのではないか。という話です。
個々人のDB管理者・開発者に対してCREATE USERしている現場もたまに見ることがありましたが、開発に参加したメンバーがセンシティブなデータに対して不正アクセスしていないかといった監査目的であることが多いように思います。

ちょっと補足②
GCPやBigQueryへは、個人のGoogleアカウントでアクセスしますので、1000人いれば1000ユーザでアクセスするという話に対して、やろうと思えば個人レベルでの権限管理もできるかと思います。
ただしここで管理する権限はデータそのものにフォーカスしたものではなく、GCP上のインフラ全体における権限も考えなければならない点はSnowflakeと異なります。1000人がインフラ開発・運用の権限まで考慮して（たいていはその権限は与えず、）BigQueryだけは自由に触らせるような形をとりますか？という話。
そのようなことをやりたい場合は例えばLookerを使って整理された権限管理のレイヤを設けるというのが現実的かと思います。

Snowflakeのロールで興味深い点

「洗練された権限管理」と言いましたが、ここまで述べたように、CREATE USER、CREATE ROLEというコマンドは従来のデータベース一般の話と変わらず、他の製品でもやろうと思えば近いことができます。
Snowflake独自の興味深い部分として、さらに特徴的なポイントがありますので挙げておきます。

ウェアハウスを管理する権限

1点目は「ウェアハウスの作成・拡張」といった操作も個人に委譲できる点です。
Snowflakeのお作法として、実行したい処理にフィットする仮想ウェアハウス（コンピュート）を使用し、必要な時だけ稼働するということがあります。

処理内容	アクセス傾向	想定されるウェアハウス
軽量なレポート	全従業員が利用 平日日中はいつでもアクセスが来る	小規模なウェアハウスを常駐
大量データ更新	夜間の日次バッチ	ハイスペックなウェアハウスで 目標時間内で完了を目指す
アドホックな分析	少人数の高度分析ニーズ 実行頻度や所要時間が予測できない	都度フィットするウェアハウスが望ましい

先に述べたSnowflakeらしい使い方でいうと、「軽量なレポート」「大量データ更新」はシステム開発を伴う従来のDWHとしての使い方であって、システムとして完成してしまえばSnowflakeだからこそ有利ということもないでしょう。

3つ目の「アドホックな分析」つまり、利用者が各々のニーズで好き好きにデータにアクセスするのがSnowflakeだからこそ実現できる（実現しやすい）というポイントです。

「○○○な分析をしたいから強いサーバーを申請します」
「承知しました。でも社内の申請ワークフロー回すのに1週間みてください」

みたいなやり取りは不要で、分析に必要なコンピュートを許された範囲で自由に使うことができるのです。

このような、データそのものに対する権限だけでなく、コンピュートリソースに対しての権限もSQLのGRANT文で管理できる点も抜群の扱いやすさだと思います。これは、処理実行するためのIaaSの準備といったインフラ開発をさせないSaaSゆえの工夫があったのだと想像しますが、だからこそ、様々な利用用途に対する無駄のないリソース割り当てというところへの最適解になっていると思います。

使用するロールを都度宣言する使い方

Snowflakeでは、ユーザーは付与済みロールの権限をすべて無条件に使えるわけではありません。
あるユーザはロールAとロールBを行使する権利をもっていて、ロールAを行使することを明示した場合にAオブジェクトを操作できます。ロールBだけに許されたデータベースBやテーブルBは表示すらされません。ロールBを行使すると即テーブルBが見えるようになり、テーブルAは存在すらしないように見えます。

うっかり上位のロールでテーブルを作ってしまうと、本来アクセスを許したい下位ロールからも見えなくなってしまうといったSnowflakeロールあるあるが存在し、私もこの1ヵ月ほどで何度も泣きを見ました・・・（気づけはすぐ修正できるんですけどね。。。）

これは直感的な権限操作とのトレードオフの面でもあるわけですが、データ共有プラットフォームであるという視点に立つと、「データの持ち主は、そのデータを誰に見せるか明示する」というのは当然であり、そのための受け入れるべきお作法かなと思っています。

---

さて、Snowflakeのロールについて、独自の視点をてんこ盛りで語らせていただきました。

Snowflakeの勉強していると、ロール設計のハードルがまぁまぁあるように語られることが多いと思いますが、SaaSとしての製品ビジョンを叶える要として、SQL標準に乗っかりながら、非常によく考えられてるなと思いました。

実は今回は触れていない、システムロールについての悩みもあったりします。

機会があればまた記事にしたいと思いますが、セキュリティ管理者に申請がポンポン飛ぶ形じゃなく、実務上、データ群Aを管理する立場の人に権限管理もお任せしたいみたいな話です。SECURITYADMINを渡してしまうと、その人は自分が見られないデータ群Bに対する権限管理もできることになってしまう・・・

これが記事の最後の「ロールを都度宣言する」と絡んで非常にややこしい気がしていて、じっくり研究したいと思っています。

---

こんなことに日々想いを巡らせながら、実案件ではそんな余裕もないので「Snowflake ロール ベストプラクティス」でググっております。ご意見、ご指摘、語りたいお友達などなど、この記事に思うところがございましたら是非リアクションをお待ちしております！！！！