概要

　本記事では，Snowflake における認証・認可・アカウント払い出しの一連のオペレーションを，Entra ID の SSO / SCIM と，Microsoft Forms + Power Automate + Teams を組合せて自動化する方法について，一通りまとめて述べる．SSO の構成，SCIM による連携，Forms を起点としたアカウント払い出し，そして認可（ロール付与）の自動化までを，本記事で扱う．

　本記事の主眼は，認証（SSO）やアカウント払い出し単体ではなく，「誰に，どのロールを，どのように払い出すか」という認可の部分までを Forms 起点で自動化する点にある．具体的には，Microsoft Forms への申請投稿をトリガとし，Power Automate と Teams を経由して Entra ID のグループにユーザを追加することで，SCIM 連携により Snowflake 側のロール付与までを自動で完結させる．

　本記事は次の構成からなる．第1章では背景と課題について述べる．第2章では認証・認可という用語と前提を整理する．第3章で全体アーキテクチャを示し，第4章で事前準備（SSO と SCIM の連携）を，第5章で認可の自動化（Entra グループ＝ Snowflake ロール）を，第6章で Forms + Power Automate + Teams による払い出しフローを述べる．第7章で動作確認，第8章で考察（メリットと限界）を行い，付録として AWS・Google Cloud・OCI でも同様に実装可能である旨を軽く示す．

1. 背景と課題

　私は，スキルアップを目的として，Snowflake をはじめ Azure・AWS・Google Cloud・OCI といった各種クラウドに触れられる検証環境（以後，マルチクラウド検証環境と呼ぶ）を，趣味の範囲で運営している．

　従来は，利用者から都度個別に連絡を受け，申請されてきたユーザについて，アカウントの作成やロールの付与を手動で行っていた．具体的には，Snowflake 側でユーザを作成し，必要なロールを付与し，利用者はユーザ名・パスワードと MFA 認証によってログインする，という運用である．

　この運用は，あくまで趣味の範囲であったため，これまで大きな課題感はなかった．しかしながら，利用する人が増えるにつれて，次のような手間が無視できなくなってきた．

申請のたびに手動でアカウント作成・ロール付与を行うため，運用が煩雑になる．
誰にどの権限を付与したかという管理も煩雑になる．
私自身も一利用者であり，各クラウド環境へのログインがそれぞれ別々で手間である．
手動での払い出しには，どうしてもリードタイム（申請から利用開始までの待ち時間）が発生する．

　これらの課題に対し，まず Entra ID を用いた SSO を導入することでログインの一元化を図った．本記事では，それに加えて，認可（ロール付与）とアカウント払い出しについてもなるべく省力化し，手動によるリードタイムをなくすことを目的として実施した取り組みについて述べる．

2. 用語と前提：認証と認可

　はじめに，本記事で扱う認証（AuthN）と認可（AuthZ）を整理する．

認証（AuthN）：利用者が本人であることを確認する仕組みである．本記事では，IdP である Entra ID を用いた SSO がこれに該当する．
認可（AuthZ）：認証された利用者に，どのような操作を許可するかを定める仕組みである．Snowflake ではロールがこれに該当する．

　本記事の要点は，認可の管理を Snowflake 側で個別に行うのではなく，Entra ID 側のグループを用いて表現することにある．すなわち，あるグループに所属したユーザに対して，対応する Snowflake のロールを割り当てる．ただし後述するとおり，ロールに対する具体的な権限設定（GRANT）は，別途 Snowflake 側で実施する必要がある点に注意が必要である．

3. 全体アーキテクチャ

　全体の流れは次のとおりである．

Forms 投稿
  ↓
Power Automate（途中で承認行為をはさむことも可能）
  ↓
Teams のチーム／チャネルにメンバ追加（＝ Entra ID のグループに追加）
  ↓
Entra ID の SCIM 連携により，Snowflake 側にユーザおよびグループ
（このグループが Snowflake 側ではロールに該当する）を作成
  ↓
利用者は Entra ID の SSO により Snowflake へログイン

　ポイントは次の3点である．

Forms への申請投稿を起点として，Power Automate がユーザを Teams のチーム（＝ Entra ID のグループ） に追加する．
Entra ID のグループは，SCIM 連携によって Snowflake 側のロールとして自動的に連係される．
ユーザアカウントが Snowflake 側に存在しない場合は，SCIM 連携によって自動的にユーザアカウントも作成される．

　なお，ユーザの削除についても同様のアーキテクチャ（グループからの除外 → SCIM 連携でのロール剥奪／無効化）で実装可能であるため，本記事では割愛する．

4. 事前準備：SSO と SCIM の連携

　認可の自動化に入る前に，Snowflake と Entra ID の間で SSO と SCIM を連携させておく必要がある．いずれも Entra ID のギャラリーアプリケーション「Snowflake for Microsoft Entra ID」を用いて構成する．

4.1 SSO（SAML2 セキュリティ統合）

　SSO は，Entra ID を IdP（Identity Provider），Snowflake を SP（Service Provider）とする SAML 認証で構成する．手順の要点は次のとおりである．

Entra ID 側で，エンタープライズアプリケーション「Snowflake for Microsoft Entra ID」を追加する．
そのアプリのシングルサインオン（SAML）を構成し，識別子（エンティティ ID）や応答 URL（ACS URL）を，自身の Snowflake アカウントに合わせて設定する．［要確認：値は環境ごとに異なる］
SAML 署名証明書（Base64）をダウンロードし，あわせてフェデレーションメタデータから発行者（Issuer）URL とログイン URL を控えておく．
Snowflake 側で，ACCOUNTADMIN ロールにより SAML2 のセキュリティ統合を作成する．控えておいた Issuer URL・ログイン URL・証明書を，それぞれ次の SQL に設定する．

USE ROLE ACCOUNTADMIN;

CREATE OR REPLACE SECURITY INTEGRATION microsoft_entra_security_int
  TYPE = SAML2
  ENABLED = TRUE
  SAML2_ISSUER   = 'https://sts.windows.net/<テナントID>/'
  SAML2_SSO_URL  = 'https://login.microsoftonline.com/<テナントID>/saml2'
  SAML2_PROVIDER = 'CUSTOM'
  SAML2_X509_CERT = '<Entra からダウンロードした署名証明書の中身>';

⚠️ <テナントID> や証明書の中身などは，公開時に伏せるべき情報である．実際の値に置き換えて使用すること．

　SSO 用のログイン URL は，https://<アカウントロケータ>.<リージョン>.snowflakecomputing.com/fed/login の形式となる（例：https://<アカウントロケータ>.ap-northeast-1.aws.snowflakecomputing.com/fed/login）．

4.2 SCIM（プロビジョニング）

　続いて，同じエンタープライズアプリケーションのプロビジョニング機能（SCIM）を有効化する．これにより，次の連携が自動的に行われる．

Entra ID のユーザ → Snowflake のユーザ
Entra ID のグループ → Snowflake のロール

　すなわち，SCIM 連携により，Entra ID 側のグループが Snowflake 側でロールとして自動的に連係される．

　ここで重要なのは，SCIM が連係するのはロールという「器」までであるという点である．そのロールに対して実際にどの権限を与えるか（GRANT）は，別途 Snowflake 側で設定する必要がある．したがって，運用上は次の順序で進めることが望ましい．

Snowflake 側でロールを作成し，そのロールに必要な権限を付与しておく（またはこの後 SCIM で作成されたロールに権限を付与する）．
その後で，対応する Entra ID グループ（＝ Teams チーム）にメンバを追加する．

　この順序を守ることで，あとはロールに必要な権限を付与しておけば，Teams チャネルに追加したユーザに対して自動的にそのロールが付与される，という状態を実現できる．

5. 認可の自動化：Entra グループ＝ Snowflake ロール

　前章までで，Entra ID のグループが SCIM 連携により Snowflake のロールとして連係される状態が整った．本章では，この仕組みを認可の自動化としてどう使うかを述べる．

　例として，SnowflakeSCIMRole1 という名前の Teams チーム（＝ Entra ID グループ）を用意する．SCIM 連携により，Snowflake 側にも同名のロール SnowflakeSCIMRole1 が自動的に作成される．あらかじめこのロールに対して必要な権限を GRANT しておけば，以降は次のように動作する．

SnowflakeSCIMRole1 の Teams チームにメンバを追加する．
SCIM 連携により，そのメンバが Snowflake 側で SnowflakeSCIMRole1 ロールを自動的に付与される（ユーザアカウントが無ければ同時に作成される）．

　つまり，「グループにユーザを入れる」という操作が，そのまま「Snowflake のロールを付与する」という認可の操作になる．権限設計はロール単位で一度行えばよく，個々のユーザへの付与は Teams チームへの追加だけで完結する．

　なお，SCIM 連携には更新タイミングによるラグがある点に注意が必要である．メンバを追加しても，SCIM の自動連携が走るまではロールの付与メンバが 0 のままとなることがある．また，連携やログ出力にはラグがあり，SCIM 連携が完了してもログ出力のほうが後になることが多い．即時反映を期待せず，連携タイミングを見込んで運用することが望ましい．

6. Forms + Power Automate + Teams による払い出しフロー

　第5章までで，「Teams チームにユーザを追加すれば認可まで自動化される」状態が整った．最後に，その入口を Microsoft Forms とし，Power Automate でチーム追加までを自動化する．

6.1 Forms

　まず，利用者に Forms からユーザの情報や必要な権限（＝どのロール／どのチームに入りたいか）について入力・投稿してもらう．

6.2 Power Automate

　Power Automate では，Forms の投稿をトリガとするフローを作成する．私の環境では，用途に応じて次の2種類のアクション群を用いている．

（A）アカウント作成が必要な場合の払い出しフロー

　利用者のアカウントを新規に払い出す場合のフローである．おおむね次のステップからなる．

新しい応答が送信されるとき（Microsoft Forms トリガ）
応答の詳細を取得する（Microsoft Forms）
変数を初期化する（初期パスワード用の変数）― 値にはランダムな変数を生成する
ユーザーの作成（Microsoft Entra ID）― UPN・表示名・パスワードプロファイル等を設定する
メールの送信（V2）（Office 365 Outlook）― 払い出したアカウント情報（ログイン名・初期パスワード等）を申請者へ通知する

（B）ロール付与（グループ追加）のフロー

　認可の自動化に相当する部分である．次のステップからなる．

新しい応答が送信されるとき（Microsoft Forms トリガ）
応答の詳細を取得する（Microsoft Forms）
ユーザーをチャット（チーム）に追加（Microsoft Teams）― 申請内容に対応する Teams チーム（＝ Entra ID グループ＝ Snowflake ロール）へユーザを追加する

　この（B）により，ユーザが Teams チームに追加され，その結果として Entra ID グループに所属し，SCIM 連携で Snowflake のロールが付与される．

　用途に応じて，（A）と（B）を1つのフローにまとめてもよいし，「アカウントは既にあるが権限だけ追加したい」場合には（B）のみを用いてもよい．

6.3 承認行為をはさむ場合

　そのユーザをそのグループに入れてよいか（すなわち Snowflake 側で該当ロールを付与してよいか）について，承認行為を行いたい場合がある．例えば，上長による承認や，システム管理者側での承認である．

　この場合は，Power Automate のフローの途中に承認のステップ（メールでの承認依頼や Teams メッセージでの承認依頼など）を追加すればよい．承認された場合のみチーム追加（ロール付与）へ進む，という分岐を組むことで，申請 → 承認 → 認可付与までを一連のフローとして自動化できる．

7. 動作確認

　試しに，SnowflakeSCIMRole1 のチームに新しくメンバを追加してみる．前述のとおり，SCIM の自動連携の更新タイミングまでは，Snowflake 側のロール付与メンバが 0 のままとなる．連携タイミングが来ると，追加したユーザに当該ロールが付与される（ユーザアカウントが無ければ同時に作成される）．その後，ユーザは Entra ID の SSO により Snowflake へログインできる．

　なお，SCIM 連携やログの出力にはラグがあり，SCIM 連携が完了してもログ出力のほうが後になることが多い点は，動作確認の際にあらかじめ理解しておくとよい．

8. 考察（メリットと限界）

　得られたメリットとして，次の点が挙げられる．

手動によるアカウント払い出しのリードタイムがなくなり，申請から利用開始までが短縮される．
アカウント作成・ロール付与の運用が省力化され，管理者の手間が軽減される．
認可をロール（＝ Entra グループ）単位で一度設計すればよく，個々のユーザへの付与は Teams チームへの追加だけで完結する．
利用者は Entra ID の SSO により，各環境へ一元的にログインできる．

　一方で，次のような限界・注意点がある．正直に述べておく．

SCIM 連携には更新タイミングによるラグがあり，即時反映は期待できない．
SCIM が自動化するのはロールという器の連係までであり，ロールへの権限設定（GRANT）は別途 Snowflake 側で実施する必要がある．
本取り組みはあくまで趣味・検証環境を前提としたものである．本番運用では，承認・監査ログ・最小権限の設計などをより厳密に検討する必要があると考えられる．
証明書・初期パスワード・テナントID などの秘匿情報の取り扱いには十分注意が必要である．

　また，認証・認可の連携そのものは Okta のような IdP を用いるとより強力に実現できる一方で，コスト面や，IdP の分離（あるいは Entra ID と Okta の連携が別途必要になること）といった課題がある．既存資産（本記事の場合は Entra ID）をフルに活用したい場合には，本記事で述べたような運用を行うことで，Snowflake についても認証・認可の設定の自動化が可能になると考えられる．

付録：AWS / Google Cloud / OCI でも同様に実装できる

　本記事では Snowflake を中心に述べたが，同じ考え方は他のクラウドにも応用できる．すなわち，Entra ID を IdP とし，各クラウドのエンタープライズアプリケーションで SSO（SAML）と SCIM プロビジョニングを構成し，Entra ID のグループを各クラウド側のロール／グループに対応づけるという構図である．入口の払い出し・グループ追加は，同じく Forms + Power Automate + Teams で自動化できる．

AWS：AWS IAM Identity Center（旧 AWS Single Sign-On）を用いる．Entra ID のエンタープライズアプリケーションで SAML による SSO と SCIM プロビジョニングを構成し，Entra グループを Identity Center のグループへ同期する．そのグループにアクセス許可セット（Permission set）を割り当てることで，AWS アカウント／ロールへのアクセスを制御できる．
Google Cloud：Entra ID から SAML による SSO を構成し，プロビジョニングで Cloud Identity／Google Workspace のユーザ・グループを同期する．同期したグループを IAM のロールバインディングに対応づけることで，認可を制御できる．［要確認：具体的な設定手順］
OCI：OCI IAM（Identity Domains）を用いる．Entra ID のエンタープライズアプリケーションで SAML による SSO と SCIM プロビジョニングを構成し，Entra グループを OCI 側のグループへ同期する．そのグループに対してポリシーを設定することで，認可を制御できる．

　いずれのクラウドでも，「Entra グループ＝権限の単位」という設計と，Forms + Power Automate + Teams による払い出し自動化の組み合わせは共通して有効であると考えられる．

まとめ

　本記事では，Snowflake における認証・認可・アカウント払い出しのオペレーションを，Entra ID の SSO / SCIM と，Forms + Power Automate + Teams を組み合わせて自動化する方法について述べた．認証は SSO と SCIM 連携で，認可は「Entra グループ＝ Snowflake ロール」という対応づけで実現し，入口を Forms とすることで，申請 →（承認）→ 認可付与・払い出しまでを一連のフローとして省力化できた．

　本取り組みは趣味の範囲で運営している検証環境を対象とした，限られた事例に基づくものであり，本番運用への適用にはさらなる検証が必要であると考えられるが，既存の Entra ID 資産を活かしつつ，マルチクラウド環境の認証・認可運用を省力化する1つの実践例として参考になれば幸いである．