現代のデータスタックにおいて、Snowflakeは最も重要な要素です。しかし、組織がスケールするにつれて、誰が何にアクセスできるかを管理し、さらに重要なこととして、そのアクセス権が確実に取り消されるようにすることは、コンプライアンスにおけるリスクの高い課題となります。Oktaの標準（OOTB）SCIMコネクターのみを利用してきた場合、それだけでは不十分であることにおそらくお気付きでしょう。ユーザーを作成することはできても、Snowflakeのロールの複雑なライフサイクル管理やライセンスの再利用で課題を抱えています。
本ガイドでは、Okta Identity Governance（OIG）とOkta Workflowsを使用した高度な「3層フロー」アーキテクチャについて解説します（2026年4月更新）。このアーキテクチャにより、Snowflake管理の「ラストワンマイル」を自動化できます。
課題：Oktaの統合コネクターでは不十分な理由
OktaとSnowflakeの標準的な統合は、通常、ユーザーのプロビジョニングに重点を置いています。これにより、「この人物はユーザーか？」という問いには対応できるものの、次の2つの重要な問題点が残ります。
- きめ細かい役割管理：Snowflakeへのアクセスは、役割（
SYSADMIN, DATA_ENGINEERなど）によって定義されます。標準のコネクターは、OIGのアクセスリクエストに応じて、ロール固有のSQLコマンドをネイティブにトリガーしません。 - エンタイトルメントのクリーンアップ：OIGリクエストの有効期限が切れたり、ユーザーがアプリから割り当て解除されたりしても、ユーザーレコードは、多くの場合、Snowflakeに残ります。この結果、ライセンスを消費し、セキュリティの攻撃対象領域を拡大する「ゾンビ」アカウントが生まれます。
この解決策は、Okta Workflowsをオーケストレーションエンジンとして使用することで、OIGのイベントをリッスンし、Snowflakeの言語で通信することです。
設定要件セットアップガイド
提案するOkta OIGとWorkflowsのソリューションに進む前に、ワークフローパッケージ（Snowflakeの委任フロー、エンタイトルメント割り当て解除、割り当て解除ユーザーのクリーンアップ）を使用するため、Snowflake、OIG、およびSlackでいくつかの構成変更を行う必要があります。4つのプラットフォームすべてで、この設定手順を完了させなければなりません。以下は、基本要件を設定するための包括的なガイドです。
Snowflakeの要件
Snowflakeは、ロールとユーザーを管理するためのターゲットシステムとして機能します。
- プロビジョナーロールの作成：Oktaがアクションを実行するために使用する専用のロール（例：
OKTA_PROVISIONER）を作成します。
USE ROLE SECURITYADMIN;
CREATE ROLE IF NOT EXISTS OKTA_PROVISIONER;
GRANT CREATE USER ON ACCOUNT TO ROLE OKTA_PROVISIONER;
GRANT CREATE ROLE ON ACCOUNT TO ROLE OKTA_PROVISIONER;
GRANT ROLE OKTA_PROVISIONER TO ROLE SECURITYADMIN;
- SCIM統合の構成：SCIMセキュリティ統合を作成して、OktaがSnowflakeと通信できるようにします。
USE ROLE ACCOUNTADMIN;
CREATE OR REPLACE SECURITY INTEGRATION OKTA_PROVISIONING
TYPE = SCIM
SCIM_CLIENT = 'OKTA'
RUN_AS_ROLE = 'OKTA_PROVISIONER';
- SCIMトークンの生成：Oktaに貼り付ける認可トークンを生成します。
SELECT SYSTEM$GENERATE_SCIM_ACCESS_TOKEN('SCIMToken');
- ネットワークポリシー：Snowflakeのネットワークポリシーで、OktaのIPアドレスからの受信トラフィックを許可するようにしてください。
-- ステップ1：OktaのIPアドレスを使用してネットワークルールを作成する
CREATE OR REPLACE NETWORK RULE MY_DB.PUBLIC.OKTA_INGRESS_RULE
TYPE = IPV4
MODE = INGRESS
VALUE_LIST = ( -- ここにIPアドレスのリストを挿入 )
COMMENT = 'インバウンドアクセス用のOktaのIPアドレス';
-- ステップ2：ルールを使用してネットワークポリシーを作成する
CREATE NETWORK POLICY okta_access_policy
ALLOWED_NETWORK_RULE_LIST = ('MY_DB.PUBLIC.OKTA_INGRESS_RULE');
-- ステップ3：ポリシーを有効にする（アカウントレベル）
ALTER ACCOUNT SET NETWORK_POLICY = okta_access_policy;
Oktaの要件（コアおよびワークフロー）
Oktaは中心的なアイデンティティプロバイダーであり、自動化を推進するエンジンです。
SnowflakeアプリのSCIM統合
- Okta Integration NetworkからSnowflakeアプリを追加します。
- 「プロビジョニング」タブでAPI連携を有効にし、SnowflakeのSCIMトークンを貼り付けます。
- ユーザーの作成、ユーザー属性の更新、ユーザーの非アクティブ化を有効にします。
Workflowsコネクターの認可とインポート
このシステムの中核は、Okta Access RequestsとOkta Workflowsという2つの主要なコンポーネントで構成されています。Okta Workflowsは、手動プロビジョニング、通知の送信、サポートチケットの作成といった特定の業務機能を構築するために使用されます。これらのワークフローはDelegated Flowsとして構成されており、Okta Access Requestsで利用できます。以下の手順で、これらのワークフローを有効にしてください。
1. アクセスを認可する
- Snowflakeアプリケーションのアクセストークンを使用して、WorkflowsコンソールでSnowflakeコネクターを承認します。SnowflakeアプリケーションへのAPI呼び出しを行う際に役立ちます。
- Oktaコネクター：接続が認可されていることを確認してください。
- Oktaの管理コンソールで、Okta Workflows OAuthアプリに
okta.governance.entitlements.manageスコープを付与します（「アプリケーション」>「Okta Workflows OAuthアプリ」）。
2. ワークフローパックをインポートする
注：このステップを完了するには、このワークフローパックファイルをダウンロードする必要があります。
「管理コンソール」->「Workflows」->「フロー：Snowflakeエンタイトルメント管理- Okta Workflows」で添付のワークフローパッケージをインポートします。
- 「Snowflakeエンタイトルメント管理」という名前の新しいフォルダを作成し、ドロップダウンメニューから「インポート」を選択します。
主なワークフローは、「Snowflakeの委任フロー（割り当て）」、「エンタイトルメントの割り当て解除」、「Snowflakeからのユーザー割り当て解除」の3つです。各ワークフローの機能については、次のセクションで詳しく説明します。
3つの各フローで、これらのアプリケーション接続を有効にします（例：「エンタイトルメントの割り当て解除」フローのSnowflakeカード）。
3. 委任されたフローを設定する
Snowflakeの委任フローを利用するには、まずAccess Requests内でOkta Workflowsを有効にする必要があります。これにより、Snowflakeアプリケーションへのアクセスリクエストが承認されると、Snowflakeの委任フローがAPIリクエストをトリガーしてエンタイトルメントを割り当てます。
「設定」→「機能」→「Access Requests」のOkta Workflowsアクションで有効にします
- Access Requestsが利用可能なワークフローを表示および実行できるように、カスタムロールとリソースを作成します。
- リソースセットを作成し、Workflowsを割り当てます。
- 委任されたリソースセットに戻り、管理者権限を割り当てます。
- 「Identity Governance」で、「Access Requests」->「設定」->「リソース」->「Workflows」の順に移動し、委任ワークフローがアクセスリクエストから実行できるように設定されていることを確認します。すべてが正常に実行されると、「委任ワークフロー」と表示されます。
4. イベントフックを作成する
OIGイベントが発生したときに、委任フローのAPIエンドポイントにOktaからイベントデータを送信するイベントフックを設定します。
「Workflows」の下にある「イベントフック」タブに移動して、新しいイベントフックを作成します。
次に、システムログが「updated user’s entitlements in a resource」OIGイベントを検出し、APIエンドポイントカードに送信するように設定します。そのためには、エンタイトルメント割り当て解除ワークフローの呼び出しURLを「エンドポイントURL」フィールドに割り当て、イベントフックでそのイベントを選択します。
- 「エンタイトルメントの割り当て解除」ワークフローからエンドポイント設定に移動します。
- エンドポイントのURLをコピーし、新しいイベントフックの「Endpoint URL」に貼り付けます。
- イベントフックで、「Updated user's entitlements in a resource」を選択します。
- イベントフックを設定すると、「プレビュー」タブでイベントフックをテストできるようになります。
Okta Identity Governance（OIG）の要件
OIGは、同期フローで使用されるきめ細かいエンタイトルメントレイヤーを提供します。
- ガバナンスエンジンを有効にする：組織でOkta Identity Governanceエンジンが有効になっていることを確認します。
- エンタイトルメント管理を有効にする：OktaでSnowflakeアプリに移動し、［Governance］タブに移動して［enable entitlement management］をクリックします。エンタイトルメント管理を有効または無効にする前に、まずプロビジョニングを無効にする必要があります。
- Snowflakeアプリの［Governance］でカスタムのエンタイトルメントを設定します。前述のとおり、Oktaのコネクターを使用しても、Snowflakeのエンタイトルメントは自動的に入力されません。そのため、カスタムのロールとエンタイトルメントを設定する必要があります。
Snowflakeアプリケーションに存在するロールは次のとおりです。
Okta platformでこれらのロールを一致させる必要があります。一致すると、これらのロール（ORGADMINやSYSADMINなど）は「リクエスト可能」なオブジェクトに変換され、ユーザーはアクセスリクエストカタログで表示できるようになります。
- ［ガバナンス］タブに移動します。
- エンタイトルメントを追加します。
- 「ROLES」というエンタイトルメントを追加します。
- アクセスリクエストで使用するユーザーロールを追加します。
作成すると、次のように表示されます。
- ロールごとにバンドルを作成します。
バンドルの作成が完了すると、次のように表示されます。
- これらのバンドルを使用して、Snowflakeアプリの各ロールのアクセスリクエストを［Access Requests］タブで作成します。
- 一番下までスクロールし、「Approval Sequence」->「Select Sequence」を選択します。
- 「Business Justification」シーケンスを編集します。
- 「Approval for Requester’s manager」ステップのすぐ下にある「+」をクリックして、シーケンスに新しいワークフローのステップを追加します。
- ワークフローのステップを追加し、ワークフローパックからインポートした委任ワークフローを選択します。
- 追加したら、シーケンスの名前を「Snowflake Approval Sequence」に変更して保存します。
- 先ほど保存した「Snowflake Approval Sequence」を選択して、アクセスリクエストの処理中にSnowflakeの委任フローを呼び出します。
- 各ロールのアクセスリクエストを有効にします。
- エンドユーザーのダッシュボードに移動し、「アクセスをリクエスト」→「Snowflake」を選択して、ユーザーがこれらのロールをリクエストできることを最終確認します。
- ユーザーがリクエストできるすべてのロールが一覧表示されます。
Slackの要件
Slackはワークフローの通知レイヤーを提供します。
- スコープと権限：Okta WorkflowsでSlackコネクターを承認するユーザーは、ワークスペースにアプリを追加する許可を持っている必要があります。
- アプリの認可：SlackワークスペースでOkta Workflowsアプリを認可します。
- チャネルID：ワークフローがメッセージを投稿するSlackチャネルID（例：
#security-alertsや#it-ops）を指定します。
これで基本要件を満たしたので、次にワークフローパッケージの展開と、アーキテクチャの設定について詳しく説明します。
アーキテクチャ：3つのワークフローソリューションの詳しい解説
このセクションでは、3つの主要なワークフローそれぞれの機能について詳しく説明します。
- Snowflake Delegatedフロー（割り当て）
- エンタイトルメントの割り当て解除
- Snowflakeからのユーザー割り当て解除
動画：OIGとWorkflowsを使用してSnowflakeのロールを管理する方法
この動画では、従来の統合コネクターの制限を受けることなく、OIGとWorkflowsを使用してSnowflakeのロールを大規模に管理する方法を解説します。この統合によって、タスクの自動化、データのセキュリティ確保、ガバナンスギャップの解消を実現し、ヒューマンエラーのリスクを低減する方法をご覧ください。
1. 委任された割り当てフロー：「玄関」
このフローは管理の委任に対応しており、管理者はWorkflowsコンソールにアクセスすることなく、ロールの割り当てをトリガーできます。
- ロジックと安全性のゲート：フローは、
userEmailとrequestedRoleを取得することから始まります。アクションを実行する前に、OktaでreadUserチェックとgetAssignedUserForApplicationチェックを実行して、ユーザーの現在の状態を検証します。 - 「プロビジョニング済み」の要件：「Continue If」カードはゲートキーパーとして機能し、Snowflakeアプリにおけるユーザーのステータスが「PROVISIONED」であることを確認します。
- 競合状態の防止：5秒間の「Wait」カードを実装しました。テストの際、SnowflakeがGRANT ROLEコマンドを受け付けるまでに、新しいユーザーを登録するために数秒かかる場合があることが判明しました。
- 実行：検証後、Snowflakeの「Grant Role to User」カードを使用して、Slackチャネル経由でチームに通知します。
委任フロー：ユーザーロール割り当てカード
START：委任フローイベント
入力：
requestedRole、userEmail、AccessLevelName。
Okta - ユーザーの読み取り
指定されたメールを使用して、ユーザープロファイルの詳細（名、姓）を取得します。
文字列 - 連結
記録管理のためにユーザー名を結合します。
制御 - 待機
アップストリームのプロビジョニングが安定するまで、フローを5秒間一時停止します。
Okta - アプリケーションに割り当てられたユーザーの取得
特定のユーザーのSnowflakeアプリケーションへの割り当てステータスを確認します。
制御 - 条件付きで続行
条件：ステータスが「PROVISIONED」の場合にのみ続行します。
Else：「ユーザーにロールを付与できませんでした」というエラーを表示して停止します。
Snowflake - ユーザーへのロールの付与
Snowflakeでロールの割り当てを実行します。
文字列 - 連結
Slackの成功メッセージを作成します。
END：Slack - チャンネルにメッセージを送信
確認メッセージ「[User]に[Role]のロールが正常に割り当てられました」を投稿します。
2. エンタイトルメントの割り当て解除：OIG API連携
これがオペレーションの「頭脳」です。OIGの権限付与が拒否されたり失効したりした場合に、特定のロールを取り消すという複雑なタスクを処理します。
- 「ゴールデンスレッド」（grantId）：OIGが失効をトリガーすると、このフローのAPIエンドポイントにWebhookが送信されます。「Object Pick」カードを使用して、JSONの深い階層にある
grantId（data.events.0.debugContext.debugData.grantId）を抽出します。 - OIG APIコールバック：最初のWebhookには、特定のロール名が含まれていないことがよくあります。このフローでは、カスタムAPIアクションを使用してOIG API（
/governance/api/v1/grants/{{grantId}}?include=full_entitlements）を呼び出します。 - ネストされたエンタイトルメントの解析：「At」カードと「Get」カードを使用して、フローは返されたリストをナビゲートし、values.0.nameにある正確なロール名を見つけます。
- 「DENY」ロジックゲート：「Continue If」カードは、承認サイクル中の意図しない取り消しを防ぐために、OIGのアクションが「DENY」であることを確認します。
エンタイトルメントの割り当て解除フローカード
START：APIエンドポイント（Webhook）
権限付与とターゲットの情報を含むボディデータを受信します。
オブジェクト - 複数取得（選択）
イベントデータから
grantIdとtargetオブジェクトを抽出します。
オブジェクト - 取得
ターゲットオブジェクトから
Alternate ID（ユーザーID）を抽出します。
Okta - ユーザーの読み取り
指定されたユーザーの完全なプロファイルを取得します。
文字列 - 連結
IGA APIの相対URLを構築します：
/governance/api/v1/grants/[grantId]?include=full_entitlements。
Okta IGA - カスタムAPIアクション
GETリクエストを実行して、特定のグラントの詳細を取得します。
制御 - 条件付きで続行
条件：
actionが「DENY」（削除リクエストを示す）の場合にのみ続行します。
リスト - 指定位置
返されたリストから特定のエンタイトルメントを取得します。
オブジェクト - 取得
エンタイトルメントオブジェクトからロール名を抽出します。
連結 - 名 + 姓
ユーザーの姓名からユーザー名を作成し、Snowflakeにマッピングします。
Snowflake - ユーザーからのロール取り消し
Snowflakeのユーザーからロールを削除します。
連結 - Slack出力
Slackに出力するメッセージを作成します。
END：Slack - チャンネルにメッセージを送信
確認メッセージ「[User]は[Role]のロールへの割り当てが正常に解除されました」を投稿します。
3. オフボーディングの完了：ユーザーの削除
OktaでユーザーをSnowflakeアプリケーションから完全に削除する場合、ロールを取り消すだけでは不十分です。ライセンスを取り戻すには、ユーザー自体を削除する必要があります。
- トリガー：OktaでユーザーがSnowflakeアプリケーションインスタンスから割り当て解除されると、フローが開始されます。
- 非同期処理：Async Eachループを使用して割り当て解除を処理し、削除されたすべてのユーザーに対してヘルパーフローを呼び出します。
- 最終ステップ：ヘルパーフローがSnowflakeで
Drop Userコマンドを実行します。これにより、ユーザーはSnowflake環境から完全にパージされ、通常は手動でのSQL介入が必要なタスクが自動化されます。
オフボーディングフローカード
親フロー
START：Okta - アプリケーションからのユーザー割り当て解除
Snowflakeアプリの
application.user_membership.removeイベントを監視します。
リスト - For Each（Async Each）
未割り当ての各ユーザーをヘルパーフローに送信して処理します。
ヘルパーフロー
START：呼び出し可能なイベント
親フローからユーザーデータを受信します。
オブジェクト - 展開
Alternate ID（通常はユーザー名）を抽出します。
Snowflake - ユーザーの削除
Snowflake内のユーザーアカウントを削除します。
END：Slack - チャンネルにメッセージを送信
Snowflakeユーザーが削除されたことをチームに通知します。
OIGとWorkflowsの設定テスト
「アクセスリクエストからロール」のテスト
アクセスリクエスト（ユーザーアクション）
- 標準テストユーザーとしてログインします。Oktaエンドユーザーダッシュボードに移動し、［Request access（アクセスをリクエスト）］を選択します。
- 「Snowflakeロール」リクエストタイプのリクエストを送信します。特定のロール（例：
USERADMIN）を選択します。 - アクセスリクエストの履歴を確認し、リクエストが作成され、正しい承認者（マネージャー）が割り当てられていることを確認します。
承認とプロビジョニング（管理者/マネージャーによるアクション）
- 承認者管理者としてログインし、「承認」をクリックします。
- ロールをSnowflakeにプッシュ：
OIG承認→Oktaがユーザーにエンタイトルメントを割り当て→Okta SCIM。 - Oktaで、ユーザーのプロファイル >「アプリケーション」>「Snowflake」に移動し、そのロールが「エンタイトルメント」の下に表示されることを確認します。
- Snowflakeで同様のチェックを実行し、ユーザーに適切なロールが付与されていることを確認します。
ユーザーはSnowflakeにログインして、割り当てられたロールを確認できるようになります。
エンタイトルメントの取り消しテスト
エンタイトルメントの取り消し（ガバナンスアクション）
Snowflakeのロールエンタイトルメントを取り消すには、2つの方法があります。
- ［Identity Governance］>［Access Certifications］（またはユーザーのプロファイル）に移動します。
- 「アプリケーション」>「Snowflake」>「割り当て」に移動し、「Test_user」>「エンタイトルメントの管理」の順にクリックします。
実行フロー
- OIGイベントが
Unassign EntitlementsAPI Webhookをトリガーします。 - ワークフローの開始：フローは
grantIdとtarget（ユーザー）を受け取ります。 - IGA API呼び出し：ワークフローは
/governance/api/v1/grants/[id]を呼び出し、actionがDENYであることを確認します。 - Snowflakeの取り消し：ワークフローは、Snowflakeで
Revoke Role from the Userカードを実行します。 - Slack監査：ITチャンネルにメッセージが送信されます。
検証および成功基準
- Workflowsの履歴：Unassign Entitlementsフローの履歴を開きます。
- Success Check：すべてのカード（Object Pick、IGA API、Snowflake Revoke）に緑色のチェックマークが付いている必要があります。
- Snowflakeで、
SHOW GRANTS TO USER "TEST_USER";を実行します。ロールは取り消されているはずです。 - Slackで「
[User] was successfully unassigned from the role [Role]」というメッセージを確認します。
オフボーディング時の「ユーザー削除」クリーンアップのテスト
- Oktaで、テストユーザーをSnowflakeアプリケーション全体から割り当て解除します。
- 実行フロー：
Okta Unassignment→Parent Flow: User Unassigned→Helper Flow: Drop User。 - Oktaで、ユーザーがSnowflakeアプリの割り当てリストに存在しないことを確認します。
- Snowflakeで、
SHOW USERS LIKE 'TEST_USER%';を実行します。ユーザーは検索結果に表示されないようにする必要があります（削除済み）。 - Slackで「Snowflakeのユーザーが削除されました」という通知を確認します。
OIG Workflowsの自動化から得られた教訓
この自動化を構築する過程で、OIGとSnowflakeの通信方法におけるいくつかの重要な差異が明らかになりました。
ステータスとアクションのマッピング
最も頻繁に発生したエラーの1つは、ガバナンスライフサイクルの誤った段階でフローがトリガーされるというものでした。そこで、Continue Ifゲートに対して厳密なマッピングを確立しました。
ライフサイクルステージ | OIGによるアクション | OIGステータス | 期待される成果 |
新しい権限付与 | 許可 | アクティブ | Snowflakeロールが付与されました |
失効/有効期限切れ | 拒否 | 非アクティブ | Snowflakeのロールの取り消し |
Snowflakeの文字列の書式設定
Snowflakeでは大文字と小文字が区別され、特定のユーザー名形式が要求されることがよくあります。例えば、OktaのfirstNameとlastNameを結合してSnowflakeのuser_nameの要件（例：JOHNDOE）に正確に一致させるために、Concatenateカードを使用しました。
待機状態
Waitカードがない場合、ユーザーが作成された直後であっても、Snowflakeから「User Not Found」エラーが返され、「委任割り当て」フローが断続的に失敗することがありました。5秒の遅延により、こうした競合状態による失敗が100%解消されました。
真のアイデンティティガバナンスの実現
標準的なコネクターの枠を超え、Okta Identity Governance APIとWorkflowsを組み合わせて利用することで、クローズドループシステムを構築できます。これにより、アイデンティティガバナンスにおける重要なメリットがもたらされます。
- セキュリティ：権限付与の有効期限が切れると、ロールは即座に取り消されます。
- コスト効率：不要になったSnowflakeユーザーは削除され、ライセンスは自動的に回収されます。
- コンプライアンス：OIGリクエストからSnowflakeのSQLコマンドに至るまで、すべてのアクションがワークフローの実行履歴に記録され、監査可能です。
無料トライアル：Okta Identity GovernanceとWorkflowsで、複雑なアイデンティティプロセスを大規模に自動化するメリットを実感してください。30日間の無料トライアルを始める。
