NTT DATA TECH
👨‍💻

Entra ID（Azure AD）× Snowflake を SCIM 連携するためのネットワーク構築ガイド

Satoki Mori
に公開
Network
Snowflake
SCIM
Entra ID
tech

1. はじめに

本記事では、Entra ID（旧 Azure AD）と Snowflake を SCIM で連携する際のネットワーク設計および構築手順を解説します。

Snowflake のユーザ／ロール管理を手動で運用している企業は少なくありません。しかし以下のような課題が顕在化します。

  • 入退社・異動対応の運用負荷が高い
  • ロール付与ミスによるセキュリティリスク
  • 監査対応の証跡管理が煩雑

これらは SCIM（System for Cross-domain Identity Management）連携によって解決可能です。

一方で、実際の導入では次の点がボトルネックになります。

  • SCIM API 通信をどこからどこへ許可するべきか
  • PrivateLinkを使う場合の制約
  • Entra ID 側が Microsoft 管理ネットワーク上で動作する点の理解不足

本記事の読み方

本記事の結論は以下です。

  • SCIM通信はMicrosoftクラウドから来る
  • PrivateLinkだけでは成立しない
  • 実務上は「SCIMはPublic／ユーザはPrivate」が最適

この3点を前提に読み進めてください。

本記事では、次の流れで解説します。

  1. 仕組みの理解
  2. 通信の実態
  3. 設計パターン
  4. 実装手順

2. そもそも「SCIM」とは？

SCIM（System for Cross-domain Identity Management）は、クラウドサービス間でユーザ／グループ情報を自動同期する標準プロトコルです。

Snowflake（SCIM 2.0対応）と Entra ID を連携すると、以下が自動化されます。

  • ユーザ作成／無効化
  • 属性更新（氏名・メール等）
  • Entra ID グループ → Snowflake ロール同期
  • 退職者の即時アクセス停止

特に「退職即時無効化」が監査観点で重要です。

3. Entra ID と Snowflake の SCIM 連携アーキテクチャ

基本構成

重要ポイント

  • SCIM通信は Entra ID プロビジョニングサービスから発信
  • 通信元は 企業VNet内ではない
  • PrivateLink設計時に注意が必要

つまり何が起きるか

設計を間違えると「正しく設定しているのに通信できない」状態になります。

よくある設計：

SnowflakeはPrivateLinkだけ許可すれば安全

しかし実際は：

Entra IDはそのネットワークに入れない

結果：SCIM通信が失敗する

4. なぜ設計で迷うのか

多くの現場で混乱が起きる理由は、「通信の種類が混在している」ことにあります。

❌ よくある誤解

  • SCIM通信も社内から来ると思っている
  • PrivateLinkですべて閉じられると思っている

✔ 実際の構造

通信 内容
ユーザ接続 社内ネットワークから
SCIM通信 Microsoftクラウドから

Snowflakeに対する通信は大きく2種類存在します。一つは、ユーザやアプリケーションが利用する通常の接続です。これは企業のネットワーク内から発生します。もう一つがSCIM通信で、こちらはMicrosoftのクラウド環境から発生します。

この2つは見た目は同じ「Snowflakeへの通信」ですが、実際には通信元も性質もまったく異なります。

そのため、両者を同じ前提で設計してしまうと、どこかで矛盾が発生します。

設計のポイント

ここでの設計のポイントは明確です。

ユーザ接続とSCIM通信は分けて設計する必要がある

この考え方を持つだけで、設計の見通しが大きく改善します。

5. PrivateLink構成時の重要ポイント

誤解ポイント

Entra ID の SCIM プロビジョニングは以下の要素が含まれます：

  • Microsoft 管理のクラウド基盤上で動作
  • 企業の VNet 内から発信されない

つまり：

PrivateLinkは「VNet内リソースからのプライベート接続」を前提とした仕組みです。
一方、Entra IDのプロビジョニングサービスはMicrosoft管理のSaaSであり、
ユーザVNet内に配置されることはありません。

そのため、PrivateLink単体では通信経路が成立しません。

では、どうやってSCIM連携用のネットワークを構築すべきなのか？
前章までの内容を踏まえると、設計は「SCIM通信をどう扱うか」によって整理できます。ここでは代表的な3つのパターンを紹介します。

取りうる構成パターン（メリット・デメリット詳細）

SCIM連携のネットワーク設計では、
「ユーザ接続経路」と「SCIMプロビジョニング経路」を分離して考えることが重要です。

パターン①：ネットワーク制御中心（シンプル運用）

概要
  • SCIM通信は Snowflake Public Endpoint を利用
  • ユーザ／アプリ接続は Snowflake PrivateLink を利用
  • Network Policy で Microsoft IP のみ許可

この構成では、SCIM通信はSnowflakeのPublic Endpointを利用し、ユーザやアプリケーションからの接続はPrivateLinkを利用します。
Entra IDの通信元がPublicインターネット側にあるためです。
SCIM通信をPublic経由で許可しつつ、ユーザ接続はPrivateLinkで閉域化することで、セキュリティと実装容易性のバランスが取れます。さらに、Network Policyを使ってMicrosoftのIPレンジのみに通信を制限することで、Public経由であっても実質的には限定的なアクセスに抑えることが可能です。

メリット（具体）
  • 最も実装が容易
    • DNS分離設計がシンプル
  • 障害切り分けが容易
    • SCIMとユーザ接続の経路が明確に分離
  • Microsoft公式構成と整合
    • サポート観点でトラブル対応がしやすい
  • Network Policyで実質的に閉域に近い制御が可能
    • Microsoft公開IPレンジのみ許可可能
  • 監査対応がしやすい
    • SCIM通信ログをPublic経路に限定できる
デメリット（具体）
  • SCIM通信はインターネット経由
    • 完全閉域要件には適合しない
  • Microsoft IPレンジ管理が必要
    • IP変更時の更新漏れリスク
  • Public URLが存在することへの心理的抵抗
    • セキュリティレビューで指摘されやすい

パターン②：認証・監査強化中心（高統制運用）

概要
  • SCIMはPublic Endpoint
  • Network Policy＋追加統制で制御強化
  • Token管理・監査ログ強化

この構成では、SCIM通信はPublicのまま利用しつつ、IP制限やトークン管理、ログ監査などを強化します。考え方としては、「ネットワークで閉じる」のではなく、「認証と監査で守る」というアプローチです。ただし、IPレンジの管理やトークンローテーションなど、運用面での負荷は高くなるため、体制が整っていることが前提になります。

メリット（具体）
  • Publicでも高セキュリティ水準を実現
    • IP制限＋トークン管理＋監査ログ監視
  • ゼロトラスト設計と整合
    • ネットワークよりも認証・認可中心の設計
  • 監査証跡が明確
    • SCIM操作ログを細かく追跡可能
  • 金融／公共要件にも対応可能
デメリット（具体）
  • IPレンジ管理の運用負荷
    • Microsoft公開IPは定期更新される
  • トークン漏洩リスク管理が必要
    • ローテーション運用が必須
  • 誤設定時の影響範囲が大きい
    • IP誤削除＝SCIM停止

パターン③：ハイブリッドDNS設計

概要
  • 社内DNS → privatelink.snowflakecomputing.com に解決
  • 外部DNS → 通常のSnowflake Public Endpointに解決

この構成では、ユーザー・EntraIDは同じFQDNを用いますが、内部・外部DNSでの解決結果を分けて通信経路を分離します。社内からのアクセスはPrivateLinkに解決し、外部（Microsoft側）からのアクセスはPublic Endpointに解決させます。これにより、ユーザ通信は完全に閉域化しつつ、SCIM通信も成立させることができます。ただし、この構成はDNS設計の難易度が高く、設定ミスがそのまま障害につながります。トラブルシュートも難しくなるため、十分な設計・検証が必要です。

メリット（具体）
  • ユーザ通信は完全Private
  • SCIMはPublicだが外部からは見えにくい
  • エンタープライズ要件への適合性が高い
  • ネットワークとID設計を分離可能
デメリット（具体）
  • DNS設計難易度が高い
  • 条件付きフォワーダの誤設定リスク
  • 名前解決ミス＝SCIM停止
  • 運用担当のスキル依存度が高い
  • トラブルシュートが困難

総合推奨

ここまでの内容を踏まえると、実務上の最適解は次の通りです。

SCIMはPublic、ユーザ接続はPrivateLinkで分離する

この構成は、実装の容易さ、運用性、セキュリティのバランスが最も良く、多くの現場で採用されています。

6. Snowflake 側設定

設計方針が決まったら、具体的な設定を行います。まずSnowflake側でSCIM連携を有効化します。SCIM 利用には SECURITY INTEGRATION を作成します。

必要権限

  • SECURITYADMIN または ORGADMIN
  • ユーザ／ロール管理権限

構築用SQL

CREATE SECURITY INTEGRATION entra_scim
  TYPE = SCIM
  SCIM_CLIENT = 'AZURE'
  ENABLED = TRUE;

この設定により、以下の2点が発行されます。

  • SCIM Base URL
  • Secret Token

それぞれの取得手順は以下です。

  • SCIM Base URL

Snowflake のアカウントURL（例：https://xy12345.ap-northeast-1.aws.snowflakecomputing.com）の末尾に /scim/v2/ を付加したものです

  • Secret Token

以下のSQLを実行して取得します。

SELECT SYSTEM$GENERATE_SCIM_ACCESS_TOKEN('ENTRA_SCIM');

7. Entra ID 側設定

次に、Entra ID側でSnowflakeアプリを追加し、プロビジョニング設定を行います。この際、先ほど取得したURLとトークンを設定します。また、同期対象として「Users and Groups」を選択することで、ユーザとグループの両方を同期できます。

① Snowflake 用 SCIM アプリを追加

Microsoft Entra 管理センター（旧 Azure Portal） → Enterprise Applications → “Snowflake” を選択

② プロビジョニング設定

項目 入力内容
Tenant URL Snowflakeの組織名・アカウント名を含む形式 の SCIM Base URL
Secret Token Snowflake で生成した Token
Scope Users and Groups

③ グループ／ユーザの割り当て

ロール設計については、SnowflakeのロールとEntra IDのグループを1対1で対応させるのが一般的です。この構成にすることで、権限管理が非常にシンプルになります。

ロール構成イメージ：

④ 初回同期

  • 約40分
  • プロビジョニングログで詳細確認可能

8. 動作確認・テスト

設定が完了したら、テストユーザを作成し、実際に同期されるかを確認します。

テストSQL

SHOW USERS LIKE 'test_user';
SHOW ROLES;
SHOW GRANTS TO USER test_user;

ユーザが作成され、適切なロールが付与されていれば成功です。

9. よくあるトラブルと実戦Tips

SCIM連携で多いトラブルの多くは、ネットワーク設計と設定の不整合に起因します。
たとえば、PrivateLinkのみを許可している場合、Entra IDからの通信が到達できず、同期が失敗します。
403エラーが発生する場合は、トークンの設定ミスや、PublicとPrivateのURLが混在しているケースが多く見られます。
これらの問題は、「通信元がどこか」を正しく理解していれば、多くの場合スムーズに解決できます。

  • 403エラー
    → Token不一致／URL誤り／Network Policy拒否

  • 同期されない
    → ProvisioningがOFF／割当未設定

  • ユーザは作られるがロールが付かない
    → グループマッピング不備

10. （参考）設計チェックリスト

設計時のチェックリストを以下にまとめました。設計時の参考に利用いただければと思います。

  • SCIM通信の送信元を理解しているか（Microsoftクラウド）
  • PrivateLinkのみで閉じていないか
  • Public Endpointの制御方法を決めているか
  • Network PolicyにIP制限を設定しているか
  • SCIMトークンの管理方法を定義しているか
  • DNS分離の有無を決定しているか

11. まとめ

本記事のポイントは次の通りです。

SCIM通信は、企業ネットワークではなくMicrosoftのクラウドから発生するという点が最も重要です。この前提を理解することで、ネットワーク設計の方向性が明確になります。

そのうえで、ユーザ接続とSCIM通信を分離して設計することが重要です。そして実務的には、SCIMはPublic経由、ユーザ接続はPrivateLinkとする構成が最もバランスの良い選択となります。

これらを踏まえて設計を行うことで、安全かつ効率的なSnowflakeのユーザ管理基盤を構築することができます。

本記事が、Snowflake 導入企業におけるセキュアな ID 管理の一助となれば幸いです。

NTT DATA TECH
NTT DATA TECH

NTT DATA公式アカウントです。 技術を愛するNTT DATAの技術者が、気軽に楽しく発信していきます。 当社のサービスなどについてのお問い合わせは、 お問い合わせフォーム nttdata.com/jp/ja/contact-us/ へお願いします。

設定によりコメント欄が無効化されています