こんにちは。
アドベントカレンダー20日目を担当するやしろです。
先日、第3回Snowflake女子会に参加してLT登壇してまいりました！
その時のLTネタである”SnowflakeとTableauのSSOと行アクセスポリシーによるアクセス制御”について、もう少し丁寧にご紹介したいと思います。
（ちなみに当日、「Truestarさんならアプリネタですよね？」と盛大に振っていただいたにも関わらず、アプリのアの字もお話せずこんな地味なテーマで語ってしまいました…チョイス間違えた！）
当日の登壇資料はこちら
そもそも
最近、クライアント案件の中でEntra IDを使ってTableauとSnowflakeそれぞれのSSOを構築。さらに行アクセスポリシーを使ってTableauからアクセスしたときの表示を制御、みたいなことをやってみたのでそのご紹介になります。
クライアントからの要望・要件
まずユーザーからの要望、要件についてです。
前提として、Tableau Cloudのユーザーは数千人単位です。
その数千人から、Snowflakeにライブ接続したデータソースを使ったワークブックへのアクセスがあるようなアーキテクチャになってます。
ユーザーからの要望は大きく2つ
①パスワードの入力とか煩わしいので一切なしにしてほしい
今回想定ユーザーが数千人規模と非常に多く、中には全然システムなどに明るくない人も多いのでとにかく煩わしさは排除してほしい、という要望でした。
こちらはEntra ID（旧Azure AD）のSAML認証でSSOを構築することで実現しています。
②人によって見えるデータは制御してほしい
正確には、グループ会社のデータも含んたテーブルにアクセスしたときに、自分が所属する会社のデータだけ見えるようにしてほしいとのリクエストです。
こちらはSnowflakeの行アクセスポリシーという機能を使って実装しました。
Snowflakeのログイン認証方法
参考として、Snowflakeの主な認証方法の種類をざっと上げてみました。
ユーザー名とパスワード
・一般的なログイン方法で、ユーザーが入力した情報を基に認証
→2025年4月からMFAが必須になるよって言われてるヤツ
キーペア認証
・公開鍵と秘密鍵の組み合わせを使った認証
・主にサーバー間通信やAPIアクセスで利用
OAuth認証
・Microsoft Entra IDやGoogle認証などを用いたSaaS間の認可プロトコル
・ユーザーが他のアプリケーションにリソースへのアクセス権を付与する際に使用
・ FacebookやGoogleのアカウントを使って他のアプリにログインできるのはこれ
SAML認証
・Entra IDなどのアイデンティティプロバイダによるフェデレーション認証
・一度のログインで複数のサービスにアクセス可能
今回採用したのは最後のSAML認証です。
どうやって実装したのか
それでは実際の設定方法に入っていきたいと思います。
SSOの設定
SSOの設定はEntraとSnowflakeそれぞれで簡単な設定を行うだけです。
すごくざっくりいうと以下の2ステップのみです。
①Entra IDでアプリ（Snowflake）を登録。SAML証明書を発行
※ここで作成するSAML証明書は、3年で有効期限が切れるので要注意。
②Snowflakeで、そのSAML証明書の情報を使って”セキュリティ統合”を作成
セキュリティ統合を作成するためのSQLはこんな感じです。
// セキュリティ統合の作成
CREATE OR REPLACE SECURITY INTEGRATION <セキュリテイ統合名>
TYPE = SAML2
ENABLED = TRUE
SAML2_SSO_URL = '<上キャプチャ①のURL>'
SAML2_ISSUER = '<上キャプチャ②の識別子>'
SAML2_PROVIDER = 'CUSTOM'
SAML2_X509_CERT = '<SAML証明書で取得した文字列>' //"-----BEGIN CERTIFICATE-----""-----END CERTIFICATE-----"を除いた文字列を入力
SAML2_SP_INITIATED_LOGIN_PAGE_LABEL = 'MicrosoftEntraID'
SAML2_ENABLE_SP_INITIATED = TRUE
SAML2_SNOWFLAKE_ISSUER_URL = '<https://〇〇.aws.snowflakecomputing.com>'
SAML2_SNOWFLAKE_ACS_URL = '<https://〇〇.aws.snowflakecomputing.com/fed/login>'
;Entra IDに戻って、TESTが成功すれば設定完了です。
Tableauからの設定手順も基本的に同様です。（長くなるので今回は割愛）
パブリッシュするワークブックは、認証方法をOAuthに設定することを忘れないでください。
自動プロビジョニングの設定
SSOと一緒に設定したのが自動プロビジョニングです。
自動プロビジョニングとは、「Entra IDのユーザー情報からSnowflakeのユーザーを自動生成してくれる機能」で、Entraのアカウントを持っていれば自動的にSnowflakeユーザーが割り当てられます。
また、Entra IDの「グループ」がSnowflakeの「ロール」に反映されます。
プロビジョニング有効化の手順ですが、以下の2ステップで設定できます。
①Snowflakeで、自動プロビジョニング用のセキュリティ統合を作成し、アクセストークンを発行
②Entra IDでSnowflakeのアカウントURLと、発行したアクセストークン情報を入力
行アクセスポリシーの設定
次に、2つ目の要望に応えるための、行アクセスポリシーの設定について説明します。
行アクセスポリシーとは
・ユーザー属性に基づいて設定できる、アクセス制御の仕組み
・特定の条件に応じて制限可能
この条件というのが、クエリでかなり細かく指定できる点がかなりの推しポイントだと思っています。
列に対して制御をかけるのはダイナミックデータマスキング、行アクセスポリシーはその名の通り行（レコード）に対して設定します。
Snowflakeのアクセス制御は、データクリーンルームがリリースされてからどんどん強化されてますが、この２つは一番ベーシックなやつです。
制御の方法ですが、当初は会社ごとにロールを区別して設定する想定でした。
が、Entra IDのグループ設定と、今回制御したいグループにずれがあり、またEntraのグループを編集するのはNGよーと言われてしまったので、今回はマッピングテーブルを使って制御することにしました。
マッピングテーブルとは、データを変換したりルックアップのために使用するテーブルのことをいいます。
具体的な手順は以下の通り。
①マッピングテーブルの準備
まずマッピングテーブルをSnowflake上に準備します。
キャプチャはテスト用のテーブルで、コードと名前、メールアドレスだけもたせています。
実際にはSnowflake上に社員マスタを持っていたので、そちらの社員名や会社のコード・メールアドレスといった情報を使用しました。
②行アクセスポリシーの作成
行アクセスポリシーには、CURRENT_USERとメールアドレスが同じか？というブーリアンを設定します。
2つの値が同じだったら、コード列の値を参照する、っていうロジックです。
（コードを貼りたかったのですが、なぜかエラーになってしまうためキャプチャのみですみません…）
今回の設定では真ん中のYASHIROは15になっていますね。
実際にはここの参照するコードを“会社コード”にすることでグループ会社かどうか、を判定させました。
補足ですが、Entra IDでユーザーを作成するとEntraのメールアドレスがユーザー名となるので、CURRENT_USERとメールアドレスを突き合わせるロジックにしています。
③制限をかけたいテーブルまたはビューに適用
作成したポリシーを、制限かけたいテーブルに適用します。
こんな感じで一行、DDLの最後に”WITH ROW ACCESS POLICY”って付け加えるだけでOKです！
ちなみに今回はtruestarがSnowflakeマーケットプレイスで公開しているPODBの都道府県データを使っていて、都道府県コードに制御をかけてみました。
先程のマッピングテーブルの、”コードの値15=新潟県”のデータだけ見えれば設定成功です。
④適用されたか確認
↓こちらが適用前のもとのデータです。山形・福島・秋田などなどの複数の都道府県データが確認できます。
↓こちらが適用後のデータです。同じユーザーで同じクエリを実行しましたが、ちゃんと新潟のデータしか見れなくなってますね。
今度はTableau Cloudからアクセスしてみましょう。
あらかじめパブリッシュしておいた、テスト用のワークブックを開いてみます。
最初はこんな感じでサインインを求められますが、”Entra IDを使ってサインイン”を選択すると、ユーザー名などの入力無しでブックを開くことが出来ますし、次回以降は最初からブックを開くことが出来ます。
また、中を見てみるとちゃんと新潟県だけが表示されていることも確認できますね。
うまくいかなかったところ・残課題
概ね理想通りに設定できたのですが、いくつか思うように設定できなかったところもあるので、そちらも紹介しておきます。
・Entra IDからのデフォルトロールの設定
どうやら設定方法はあるようなのですが、こちらの制御がうまくいきませんでした。
デフォルトロールはPUBLICのままですが、Tableau Cloudの認証情報の方にロールを埋め込むことで運用はカバーしています。
・Snowflakeユーザーの削除
プロビジョニングはユーザーの生成はしてくれるのですが、削除はしてくれないので定期的に棚卸しが必須です。
・証明書やトークンの更新手順の整理
証明書やトークンの更新期限がバラバラなので、きちんと管理して運用する必要があります。
上で述べたように、SAML証明書は3年、プロビジョニング用のトークンは6ヶ月です。
・Tableauデータソースの抽出更新の自動実行ユーザーの設定
一般ユーザーはSSOを構築しましたが、Tableauデータソースの抽出更新の自動実行ユーザーはユーザー名とパスワードのままの設定になっています。
Snowflakeでは、2025年4月から段階的にMFA（多要素認証）が必須になるという話があり、ユーザー名とパスワードのみではアクセス不可になってしまうので対策が必要となってきますのでご注意ください。
おわりに
長々と、SSOと行アクセスポリシーを組み合わせたアーキテクチャをご紹介させていただきました。
地味故に？、あまり情報が多くない気もしたので、このブログもどなたかのお役に立てたら幸いです！
truestarでは、Snowflake導入検討、導入支援や環境構築まで幅広くサポート可能です。
Snowflakeに興味がある、導入済みだけどもっとうまく活用したい等々ありましたら、ぜひこちらから相談ください！
また、truestarではSnowflake Marketplaceにて、加工済みオープンデータを無償提供するPrepper Open Data Bank、全国の飲食店の情報を集めたデータセットの販売を行っております。（サービスリンク）
これまでのSnowflakeに関する記事はこちら
