AzureADからSnowflakeへのプロビジョニング

はじめに

AD(ActiveDirectory)を利用している企業が、別のクラウドサービスを使おうとするとクラウドサービスのユーザ運用の手間がボディブローのように人的リソースを圧迫します。

本記事ではAzure ADからSnowflakeへのユーザプロビジョニング、グループプロビジョニングについて手順を説明します。

Azure AD側で追加したユーザ/グループが自動的にSnowflakeにも作成されて(プロビジョニング)、SnowflakeにログインするときはAzure ADのユーザ・パスワードでログインできれば(SSO)、運用は楽になるはずです。

SnowflakeはAzure ADへのSSO(SAML)も対応していますし、プロビジョニング(SCIM)も対応しています。
SCIMとはプロビジョニング機能を担うオープンなプロトコルです。フェデレーションを担うSAMLとは目的が異なるため、SAMLとSCIMは同時に使うことができます。

プロビジョニングを利用する場合、どのような属性がマッピングされるのか、どのような挙動になるのかイメージが沸かなかったため、そのあたりも検証を行いました。

まず留意事項を記載します。

• コスト面
  • 6ヶ月ごとにSCIMトークンの更新が必要です。運用コストを見込んでおく必要があります。
    • トークンの更新はSnowflake側もAzureAD側も作業が必要になります。
  • 一般論としてプロビジョニング自体の運用コストも発生します。
    • 「Snowflakeにログインできない」といった問い合わせ対応でAzure AD側のログを確認する作業が発生します。
      • 企業規模も踏まえて全体的なベネフィットがいつ得られるのか、そのベネフィットはどの部署で得られるものなのか、といった視点も加えて各機能を検証することをおすすめします。
• 機能面
  • ユーザプロビジョニングもグループプロビジョニングも可能です。
    • グループプロビジョニングを使うにはAzure AD Premium P1以上である必要があります。
      • ただしSnowflakeにはグループという概念がありません。詳しくは後ほど説明します。
      • 今回の検証はAzure AD Premium P2 試用版を利用しています。
  • プロビジョニング間隔は40分毎の固定です。
  • SnowflakeからAzure ADへのプロビジョニングはできません。
    • そのためSSOでプロビジョニングしたいユーザについてはSnowflake側でユーザ作成するのではなく、AzureADか、もしくは[AzureAD Connect]と連携されたオンプレミスのAD側のいずれかで作成する必要があります。

1. Azure AD と SnowflakeのSSOについて

まず、SSOを設定していない場合は以下の手順を参照し、SSO(シングルサインオン)を設定してください。
後ほど記載するプロビジョニングを行うにはSSOのセットアップが必須です。

上記手順はSSOとしてはSAMLを使ったAzureAD(IdP)、Snowflake(SP)な構成です。
つまりSnowflakeのログイン画面からスタートする、SP Initiatedなものになっています。本検証も同様です。

なおAzureからも同様の手順が提供されていますので以下も参照ください。
こちらの手順ではIdP InitiatedもSP Initiatedも区別されて記載されています。

補足1. AzureADの最小限設定

今回の検証のような SP Initiatedの場合、Azure AD側では「識別子」と「応答URL」だけ設定していれば機能します。

補足2. SAML署名証明書データをしっかり確認する

また、Snowflake側で設定するSAML署名証明書は、コピペミスなどでデータが間違っているとSnowflakeからAzure ADユーザでログインしようとした際にブラウザが真っ白になります。

補足3. AzureADの証明書更新などの運用タスク

運用タスクとして、AzureAD側でもSAML署名証明書の更新が必要になります。
デフォルトかつ最大で3年の期限で設定されており、AzureADでSAML署名証明書を作成する際に期限を短縮することはできますが延ばすことはできないようです。

以下スクリーンショットは2021年8月3日にSSOをセットアップしたケースのSAML署名証明書期限です。

• つまり、以下のような運用が発生します。
  • SSOを利用する場合は最大3年毎のSAML署名証明書更新
  • さらにプロビジョニングを利用する場合は6ヶ月毎のSCIMトークン更新

AzureADのSAML署名証明書ロールオーバー手順などは以下を参照してください。
更新後、取得した証明書をSnowflake側に再適用することも必要になります。

2. Azure AD からSnowflakeへのプロビジョニング

まずはSnowflakeの手順を参考にして進めていきます。

リンク先に記載された「制限事項」「サポート対象外」「前提条件」の項目をよく確認しておきます。
とりあえず私は以下のポイントだけ留意しました。

• 同時リクエストは500まで。
• Azure ADのネストされたグループはプロビジョニングできない。
• SnowflakeでIP制限をかけている場合は、Azure AD側の諸々のIPを許可しておく必要がある。
• SCIMのSnowflakeベースURLを用意しておく必要がある。東京リージョンだと以下の形式。
  • https://(アカウントロケータ).ap-northeast-1.aws.snowflakecomputing.com/scim/v2/

2-1. Snowflakeでプロビジョニングを有効化

以下のコマンドをSnowflakeのワークシートでそのまま実行します。

プロビジョングで内部的に利用するSnowflakeのカスタムロールを作成し、プロビジョニングの設定を行っています。

use role accountadmin;
create or replace role aad_provisioner;
grant create user on account to role aad_provisioner;
grant create role on account to role aad_provisioner;
grant role aad_provisioner to role accountadmin;
create or replace security integration aad_provisioning
    type = scim
    scim_client = 'azure'
    run_as_role = 'AAD_PROVISIONER';
select system$generate_scim_access_token('AAD_PROVISIONING');

最終行のselectを実行すると、以下のようにトークンが出力されます。
のちほど利用するためコピーしておきます。
※このアクセストークンは6ヶ月後に期限が切れます。

2-2. Azure ADでプロビジョニングを有効化

ここからはAzure側の手順を参考にしていきます。

以下手順の前半は完了しているため、「手順 5:Snowflake への自動ユーザー プロビジョニングを構成する」のところから進めます。

※リンクの冒頭に記載されているとおり、Azure AD側のSnowflakeプロビジョニングコネクタは2021年8月現在、パブリックプレビュー中ですので今後仕様が変わる可能性をご認識ください。

まずAzureポータルにログインし、「Azure AD」→「エンタープライズアプリケーション」→「Snowflake for AAD」を開きます。
※「Snowflake for AAD」が未設定の場合は本記事上部に記載した手順を元に設定してください。

初回セットアップが開始します。

プロビジョニングモードを「自動」に設定します。

管理者資格情報に「テナントのURL」と「シークレットトークン」を入力します。

• テナントのURL

  • これは2.の冒頭に記載した以下の形式の「SCIMのSnowflakeベースURL」を指定します。
    • https://(アカウントロケータ).ap-northeast-1.aws.snowflakecomputing.com/scim/v2/

• シークレットトークン

  • 2-1.で取得したトークンを指定します。
    • 私が取得した時はver:1-hint:で始まり、=で終わるトークンでした。ver:1-hint:の部分も含めた全体を指定します。

指定後、「テスト接続」をクリックすると、Azure ポータルの右上に進行中である表示がされます。

テスト接続をクリアできたら、ポータル左上の「保存」をクリックします。

保存すると、属性値を確認できる「マッピング」やエラー発生時にメール通知できる「設定」項目を確認することができるようになります。

グループとユーザの両方のプロビジョニングが有効化されていることを確認します。

マッピングについては青文字のリンクをクリックすると詳細を確認することができます。
「Provision Azure Active Directory Users」を表示したものが下図になります。

上図は2021年8月にセットアップした結果ですが、Azure ADのドキュメントと差異があり、属性が不足しています。

この問題は以下のissueとして2020年8月に起票されていますが、2021年8月の時点では修正されていません（このあたりがパブリックプレビューな所以でしょうか）。

不足している属性	説明
urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:defaultRole	Snowflakeにおけるデフォルトのロール
urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:defaultWarehouse	Snowflakeにおけるデフォルトのウェアハウス

一方、Snowflake側のドキュメントでは、標準的なユーザ属性としては定義されていないものの、カスタム属性としては定義が可能と記載されています。

Snowflakeは、 defaultRole や defaultWarehouse など、 RFC 7643で定義されていないカスタム属性の設定をサポートしています。

ドキュメントを見るとSnowflakeのカスタム属性の名前空間は２種類あり、それぞれ利用可能なIdPが異なるようです。

項番	名前空間	説明
1	urn:ietf:params:scim:schemas:extension:enterprise:2.0:User	OktaのみSCIMで利用できる
2	urn:ietf:params:scim:schemas:extension:2.0:User	Azure ADのSCIMでも利用できる

しかしながらAzure ADのドキュメントに記載されているのは項番1の形式の「enterprise」がついた名前空間であり、どうにもAzure AD側の対応が追いついていない印象を受けます。

ためしにAzure AD側で「新しいマッピングの追加」を試みましたが、下図のとおり、ターゲットの属性(Snowflake側)で指定できる属性が「id」しか表示されず、defaultRole,defaultWarehouseと思われるものを追加することはできないように見えました。

AzureのFeedback Forumsにもこの課題があがっていたため、票を投じておきました。
改善が見られた場合、投票時に指定したメールアドレスに連絡がくるようです。

そもそもSnowflakeにおけるデフォルトロール、デフォルトウェアハウスは、ログイン時の初期値になります。
デフォルトロールは指定しなければ最低限の権限のpublicロールが割り当てられます。
Snowflakeのユーザに複数のロールがアタッチされていれば別のロールに切り替えられるため、少なくとも人間によるSnowflakeコンソールのログイン時では多少不便ではあるものの大きな問題にはならないため、いったんこのまま進めます。

それでは、属性値は何も変更せずに「プロビジョニング状態」をオンに切り替えます。

画面左上の「保存」をクリックします。これで初回のプロビジョニングが開始します。

設定はいったんこれで完了です。

2-3. Azure ADにSnowflakeのSSOを利用するユーザを登録する

ではAzure ADに、SnowflakeへのSSOを行いたいAzure ADグループを追加していきます。
プロビジョニングされるユーザ数を事前に把握しておいたほうがよいため、この作業はプロビジョニング開始前の実施が望ましいのですが、本手順ではわかりやすくするため、プロビジョニング開始後に設定することにします。

「Azure AD」→「エンタープライズアプリケーション」→「Snowflake for AAD」を開きます。
「ユーザーとグループ」を選択します。

「ユーザーまたはグループの追加」を選択します。

私の環境では以下のように表示され、グループの選択ができませんでした。
お客様のActive Directoryプランレベルでは、グループを割り当てることができません。個々のユーザーをアプリケーションに割り当てることはできます。

ではプランレベルを変更していきます。
「Azure AD」→「ライセンス」を開きます。

ライセンス画面右の「無料試用版を入手する」を開きます。

Microsoft 365のEMS E5 試用版をアクティブ化します。

グループも割り当てられるようになりました。
まずはグループではなくユーザを割り当ててみます。

2-4. プロビジョニングのテスト

「プロビジョニング」画面に戻り、「プロビジョニングの詳細の表示」をクリックします。

2-4-1. 手動プロビジョニング

次回の自動プロビジョニングの実行時間まで待っているのも手間なので、手動でプロビジョニングします。
「プロビジョニング」画面右上の、「要求時にプロビジョニングする」を選択します。

先程指定したユーザを検索し、「プロビジョニング」を押します。

2-4-2. Snowflake側に同名ユーザが存在する場合

プロビジョニングの結果が出力されました。何かエラーが出ているようです。

じつはこのテストケースは、snowflake側にすでに同名のユーザが存在していた場合の異常系の挙動を確認しています。
プロビジョニングを利用しない通常のSSOでは、Azure ADユーザと同じメールアドレスをLOGIN_NAMEとして持つユーザを手動でSnowflake側に作成する必要があります。
事前に以下のSQL文でSnowflake側にユーザを作成してあったので、Azure ADからのプロビジョニングが失敗していたわけです。

use role accountadmin;
CREATE USER jnit02 PASSWORD = '' LOGIN_NAME = '[e-mail]' DISPLAY_NAME = 'jnit02_display';
grant role sysadmin to user jnit02;
alter user jnit02 set default_role=sysadmin;

プロビジョニングを利用する場合は、当然ですがSnowflake側にユーザを作成しておく必要はありません。
プロビジョニングを利用しないSSOでは、Snowflake側のパスワード名は空にしておくことが望ましいです。空の場合はSnowflake直でログインできなくなり、空でない場合はSnowflake直でも(Snowflake側のパスワードで)ログインが可能です。

Snowflake側にユーザが存在すれば、AzureADからのプロビジョニングも正しく失敗し、異常に気づけることがわかりました。

なお、プロビジョニングのログは後から確認することも可能です。
実際の運用では以下の「プロビジョニングログの表示」を見る機会が多く発生します。

2-4-3. Snowflake側に同名ユーザが存在しない場合

こちらが正常系のテストケースになります。

グループプロビジョニングもあわせてテストしてみます。

Azure ADに予め "group03"というグループ(種類は「セキュリティ」)を作成し、そこにjnit03というユーザを所属させておきます(省略)。
group03を [Snowflake for AAD]の「ユーザーとグループ」に追加しておきます。

手順[2-4-1.]と同様に手動でプロビジョニングを行います。
手動の場合はグループを指定することができないため、 ユーザ名を前方参照で検索してユーザ指定で同期します。
結果を見ると成功したようです。

今度はSnowflakeのコンソールを開き、ACCOUNTADMINロールでユーザー一覧をみてみます。
jnit03ユーザがちゃんと出来ていました。プロビジョニングで作成されたSnowflakeのユーザー名は、[[e-mail]]となっており、これはAzureAD側のUPN(ユーザプリンシパル名)にマッピングされています。

ではSnowflakeのログインを試してみます。
SSOが有効化されている環境では「AzureADを使用してサインイン」というボタンが表示されています。
これをクリックします。

Microsoft側のログイン画面に切り替わりました。Azure ADのユーザ名でログインします。

初回はAzure ADのパスワードも入力します。
一定期間キャッシュが効くため、次回以降はユーザ名選択のみでログインできます。

Snowflakeにログインできました！
プロビジョニングの正常系の動作確認の初歩をクリアできました。

2-4-4. グループプロビジョニング

上図をよく見るとロールは"public"になっています。
スイッチできるロールはpublic以外は「group03」のみとなっていました。
(以下のスクリーンショットは別途取得したものであるため、カスタムロール[SNOWFLAKE-GROUP03]は[group03]に脳内変換してください）

今回、Snowflakeのロールの設定は、AzureAD側もSnowflake側も行っていません。
つまり***[Azure ADのグループ名]が[Snowflakeのロール]としてプロビジョニング(新規作成)される***という挙動のようです。

AzureADのグループ「group03」が、Snowflakeのロール「group03」として作成されたということは、グループプロビジョニングができたことを示しています。

Snowflakeでは運用上、publicではない特定のロールにユーザを紐付けることは必須です。

SSOでユーザプロビジョニングとグループプロビジョニングができたこと自体は喜ばしいことですし、それだけで運用の手間も多少は減りますが、Snowflakeのユーザ管理の大きな関門の一つである、カスタムロールへの権限付与(grant)をなんとか自動化したいところです。

結論からいうと、プロビジョニング処理としてgrantを自動化することはできません。

グループプロビジョニングは(少なくとも2021年8月現在では)、Snowflakeロールがプロビジョニングされた後に、Snowflakeのロールへの権限付与(grant)を手動で行う必要があります。

つまり下図のように①のあとに②を実施する必要があります。①と同時に②を行う、または先に②を行うことはできません。

この挙動は検証済みです。試しにAzure ADのグループ名と同一名のSnowflakeロールを事前に作成し、Azure ADからユーザプロビジョニングで新規作成されるユーザに、そのSnowflakeロールがアタッチされるか試してみましたが、アタッチはされませんでした。つまり既存のカスタムロールにグループを紐付けることができないようです。

また、Snowflakeサポートからも「ロールがプロビジョニングされてからgrantを行う必要がある」と回答がありました。いずれは改善されるかもしれません。この制限は、すでにがっつりsnowflakeを使っている企業がSSOのプロビジョニングを導入する際などに「相当数のグループとロールの作り直し」という形で影響を与えると思います。

なお、下図のように事前にロールをプロビジョニングさせておき各種オブジェクトへのgrant設定後、AD側のユーザをグループ移動させるだけで、Snowflakeのロールを切り替えることはできます。

ただし運用上、ロールを増やそうと思ったらまずAzureAD側でグループをSnowflakeにアタッチする必要がでてきます。（そのあとロールがプロビジョニングがされたらgrantを設定するという流れです)。

2-4-5. SnowflakeにプロビジョニングされたユーザをAzure AD側でSSO対象から外す

実際の運用を想定して、Azure AD側でSSOに登録済みのグループに所属しているユーザを、グループから除外してみます。

除外後、SnowflakeからADユーザでSSOログインしようとすると、以下のようなエラーが表示されました。

The signed in user '<username>' is not assigned to a role for the application

ユーザをSSOの対象グループから外したわけですから、これは正しい挙動になります。
ユーザを元のグループに戻せばSSOログインが使えるようになります。

まとめ

本記事ではAzure ADからSnowflakeへのプロビジョニングについて、手順の説明と以下の仕様を確認しました。

• Snowflake のdefaultRole , defaultWarehouse はマッピングできない(2021年8月時点)。
• Snowflake側にすでにユーザ(※)が存在する場合はユーザプロビジョニングに失敗する。
  • ※Azure ADユーザと同じメールアドレスをLOGIN_NAMEとして持つSnowflakeユーザ
• グループプロビジョニングは***[Azure ADグループ]が[Snowflakeカスタムロール]として作成***される。
  • カスタムロールへのgrant設定はプロビジョニング後に設定する必要がある。

所感

基本的にSSOはIdP側でログを確認する業務が発生しがちなため、プロビジョニングにそれを上回るメリットが欲しいところなのですが、グループとロールのマッピングが中途半端なところなどが惜しい感じです。

この問題がSnowflake側に起因するのかAzureAD側に起因するのかは分かりませんが、SnowflakeはREST API周りがどんどん充実してきましたし、Azure AD側も属性値マッピングを少し直すだけでよさそうに思えるので、そう遠くない未来に改善されるのではと個人的に思います。

以上です。