SnowflakeとAzure SCIM の統合

Snowflakeは、 SCIM IDプロバイダーとしてMicrosoft Azure Active Directoryをサポートしています。

このガイドでは、SnowflakeのAzure AD ユーザーおよびグループのプロビジョニング(Azure AD内)を構成するために必要な手順を説明します。ガイドには次のセクションが含まれています。

機能

  • Snowflakeへの自動Azure AD ユーザープロビジョニング。

  • Snowflakeへの自動Azure AD グループプロビジョニング。

  • Azure AD ユーザーおよびグループのSnowflakeへの同期。

  • Azure AD が SAML SSO からSnowflake に対して構成されている場合、SnowflakeにプロビジョニングされたAzure AD ユーザーは SAML SSO 使用してSnowflakeにアクセスできます。

    注釈

    デフォルトでは、 SCIM を使用してSnowflakeにプロビジョニングされたAzure AD ユーザーには、Snowflakeでパスワードが割り当てられていません。つまり、 SAML SSO がAzure ADで構成されている場合、ユーザーは SSOを使用してSnowflakeに対して認証を行います。

    SCIM を使用してAzure AD からSnowflakeにユーザーとグループをプロビジョニングする場合、SAML SSO は必須ではありません。その他のオプションについては、 Azure AD シングルサインオンの構成 をご参照ください。

制限事項

  • Snowflakeは、SCIMエンドポイント(例えば、 /Users エンドポイント、 /Groups エンドポイント)ごとに、アカウントにつき最大500の同時リクエストをサポートします。アカウントがこのしきい値を超えると、Snowflakeは 429 HTTP ステータスコード(つまり、リクエストが多すぎる)を返します。このリクエスト制限は通常、ユーザーまたはグループをプロビジョニングするために比較的多数のリクエスト(つまり、1万以上)が発生する初期プロビジョニング中にのみ発生することに注意してください。

サポート対象外

  • AWS PrivateLink および Google Cloud Private Service Connect。パブリックインターネットを経由せずにMicrosoft Azure AD からSnowflakeにユーザーおよびグループをプロビジョニングする場合は、Microsoft AzureにSnowflakeアカウントが必要です。

  • Azure Private Linkを使用してSnowflakeにアクセスしている場合は、統合設定でAzure Private Link URLを使用していないことを確認してください。パブリックエンドポイント(つまり、 .privatelink なし)を入力し、ネットワークポリシーが 前提条件 セクション(このトピック内)に表示されているAzure IPアドレスからのアクセスを許可していることを確認してください。さもなければ、この統合を使用することはできません。

  • 既存のユーザーとロールの所有権を譲渡します。Azure AD は、ユーザーとグループの信頼できるソースです。グループメンバーシップはAzure ADで更新できます。ただし、Snowflakeの既存のユーザーとグループをMicrosoft Azure AD に転送することはできません。

  • Microsoft Azure AD は現在、 ネストされたグループ の読み取りまたはプロビジョニングをサポートしていません。したがって、Snowflake Azure SCIM 統合を使用して、Snowflakeのネストされたグループをプロビジョニングまたは管理することはできません。ネストされたグループのサポートのリクエストは、Microsoftにお問い合わせください。

  • Microsoft Azure AD からSnowflakeへのパスワード同期の有効化または無効化。

    Snowflakeセキュリティ統合で SYNC_PASSWORD プロパティを設定しても、ユーザーパスワードはMicrosoft Azure AD からSnowflakeに同期されません。これはMicrosoft Azure AD の制限です。サポートをリクエストするには、Microsoft Azureにお問い合わせください。

前提条件

SCIM を使用してAzure AD ユーザーとグループをSnowflakeにプロビジョニングする前に、次のことを確認してください。

  1. 既存のAzure AD テナント

  2. 既存のSnowflakeテナント

    • Microsoftでの構成プロセス中に、Snowflake SCIM エンドポイントの URL (つまり、Microsoft Azure Active Directory SCIM 構成ガイドの Tenant URL)を入力する必要があります。Snowflake SCIM エンドポイントは、 /scim/v2/ が追加されたSnowflakeアカウント URL で構成されます。たとえば、アカウント名 URL 形式を使用する場合、 SCIM エンドポイントは https://myorg-myaccount.snowflakecomputing.com/scim/v2/ です。Snowflakeアカウント URL でサポートされている形式のリストについては、 URL での接続 を参照してください。

  3. ACCOUNTADMIN ロールを持つSnowflakeの少なくとも1人のユーザー

  4. ユーザーまたはグループをプロビジョニングする前に、アカウントに関連するため、Snowflakeの ネットワークポリシー が、 パブリッククラウド または US 政府クラウド のAzure AD IP アドレス すべて からのアクセスを許可していることを確認してください。現在、Azure SCIM ネットワークポリシーを作成するには、Azure AD IP アドレスすべてが必要です。詳細については、 SCIM ネットワークポリシーの管理 をご参照ください。

設定

Snowflakeの構成プロセスでは、SCIM のセキュリティ統合を作成して、Azure AD で作成されたユーザーとロールをSnowflakeの AAD_PROVISIONER SCIM ロールが所有できるようにし、SCIM API リクエストで使用するアクセストークンを作成します。アクセストークン(つまり、Microsoft Azure Active Directory SCIM構成ガイドの Secret Token )は6か月間有効です。有効期限が切れたら、以下に示すように手動で SYSTEM$GENERATE_SCIM_ACCESS_TOKEN を使用して、新しいアクセストークンを作成します。

注釈

SCIM 統合の既存のアクセストークンを無効にするには、 DROP INTEGRATION ステートメントを実行します。

Snowflakeで SCIM を引き続き使用するには、 SCIM 統合を CREATE SECURITY INTEGRATION ステートメントで再作成し、 SYSTEM$GENERATE_SCIM_ACCESS_TOKEN を使用して新しいアクセストークンを生成します。

Azure Active Directoryの構成

Microsoft Azure Active Directoryを SCIM IDプロバイダーとして使用するには、 Microsoftドキュメント の手順に従います。これらのステップを実行している間は、Azure AD で既存のエンタープライズアプリケーションを再利用 しない でください。プロビジョニング用の新しいエンタープライズアプリケーションの作成に失敗すると、予期しない動作が発生する可能性があります。

注釈

カスタム属性を作成していて、Snowflakeユーザーの name フィールドと login_name フィールドに異なる値を設定したい場合は、 Snowflakeサポート に連絡して、カスタム属性を作成する前にアカウントの個別のマッピングを有効にしてください。

Snowflakeの構成

Snowflakeの構成を容易にするために、以下の SQL をコピーして最初の ステップ で使用します。次の各ステートメントについて、以下で説明します。

use role accountadmin;
create role if not exists 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');
Copy

重要

例の SQL ステートメントは ACCOUNTADMIN システムロールを使用し、 AAD_PROVISIONER カスタムロールが ACCOUNTADMIN ロールに付与されます。

権限の少ないロールを優先するために、 ACCOUNTADMIN ロールを使用しないようにすることもできます。権限の少ないロールを使用すると、最小権限のアクセスに関連するコンプライアンスの懸念に対処するのに役立ちますが、 SCIM の構成および管理プロセス中に予期しないエラーが発生する可能性があります。

これらのエラーは、ロールの作成方法と結果のロール階層が理由で、権限の少ないロールが SCIM までのすべてのロールを管理するための十分な権限を持っていないことに起因している可能性があります。したがって、構成および管理プロセスのエラーを回避するために、次のいずれかのオプションを選択してください。

  1. SQL ステートメントの例に示されているように ACCOUNTADMIN ロールを使用。

  2. グローバル MANAGE GRANTS 権限を持つロールを使用。

  3. 最初にある2つのオプションのいずれも望ましくない場合は、 SCIM を使用して管理されるすべてのロールに対して OWNERSHIP 権限を持つ、カスタムロールを使用してください。

  1. 管理者としてSnowflakeにログインし、Snowflakeワークシートインターフェイスまたは SnowSQL から次を実行します。

  2. ACCOUNTADMIN ロールを使用します。

    use role accountadmin;
    
    Copy
  3. カスタムロール AAD_PROVISIONER を作成します。Azure AD によって作成されたSnowflakeのすべてのユーザーとロールは、スコープが絞られた AAD_PROVISIONER ロールによって所有されます。

    create role if not exists aad_provisioner;
    grant create user on account to role aad_provisioner;
    grant create role on account to role aad_provisioner;
    
    Copy
  4. AAD_PROVISIONER カスタムロールを使用して、 ACCOUNTADMIN ロールによるセキュリティ統合の作成を許可します。詳細については、 CREATE SECURITY INTEGRATION をご参照ください。

    grant role aad_provisioner to role accountadmin;
    create or replace security integration aad_provisioning
        type=scim
        scim_client='azure'
        run_as_role='AAD_PROVISIONER';
    
    Copy
  5. 認証トークンを作成してクリップボードにコピーし、後で使用できるように安全に保存します。SCIM REST API リクエストごとにこのトークンを使用し、リクエストヘッダーに配置します。アクセストークンは6か月後に期限が切れます。このステートメントを使用して新しいアクセストークンを生成できます。

    select system$generate_scim_access_token('AAD_PROVISIONING');
    
    Copy

Snowflake起動 SSO の有効化

SCIMプロビジョニングプロセスは、シングルサインオン(SSO)を自動的に有効にしません。

SCIM プロビジョニングプロセスの完了後に SSO を使用するには、 Snowflakeにより開始される SSO を有効にします。

SCIM ネットワークポリシーの管理

ネットワークポリシーを SCIM セキュリティ統合に適用することで、 SCIM ネットワークポリシーをSnowflakeアカウント全体に適用されるネットワークポリシーと区別できます。これにより、 SCIM プロバイダーは IP アドレスを通常のユーザーのアクセスを制御するネットワークポリシーに追加することなく、ユーザーとグループをプロビジョニングできます。

SCIM 統合に適用されるネットワークポリシーは、Snowflakeアカウント全体に適用されるネットワークポリシーよりも優先されますが、ユーザーに割り当てられるネットワークポリシーのほうが優先されます。

SCIMセキュリティ統合を作成したら、次のコマンドを使用してSCIMネットワークポリシーを作成します。

alter security integration aad_provisioning set network_policy = <scim_network_policy>;
Copy

SCIM ネットワークポリシーを設定解除するには、次のコマンドを使用します。

alter security integration aad_provisioning unset network_policy;
Copy

条件:

aad_provisioning

Azure AD SCIMセキュリティ統合の名前を指定します。

scim_network_policy

SnowflakeのAzure AD SCIMネットワークポリシーを指定します。

詳細については、 ネットワークポリシーを使用したネットワークトラフィックの制御 および ALTER SECURITY INTEGRATION をご参照ください。

SCIM でのセカンダリロールの使用

Snowflakeは、 SCIM で ユーザー プロパティ DEFAULT_SECONDARY_ROLES'ALL' に設定して、ユーザーがSnowflakeセッションで セカンダリロール を使用できるようにすることをサポートしています。

代表的な例については、 PUT scim/v2/Users/{ID} をご参照ください。

Azure SCIM セキュリティ統合の複製

Snowflakeは、 SCIM セキュリティ統合により、ソースアカウントからターゲットアカウントへの複製とフェールオーバー/フェールバックをサポートします。

詳細については、 複数のアカウントにわたるセキュリティ統合とネットワークポリシーの複製 をご参照ください。

トラブルシューティング

  • Azure AD がSnowflakeに更新を送信していることを確認するには、SnowflakeアプリケーションのAzure AD のログイベントとSnowflakeの SCIM 監査ログを確認して、SnowflakeがAzure ADから更新を受信していることを確認します。次の SQL を使用して、Snowflake SCIM 監査ログをクエリします。ここで、 demo_db はデータベースの名前です。

    use role accountadmin;
    use database demo_db;
    use schema information_schema;
    select * from table(rest_event_history('scim'));
    select *
        from table(rest_event_history(
            'scim',
            dateadd('minutes',-5,current_timestamp()),
            current_timestamp(),
            200))
        order by event_timestamp;
    
    Copy
  • ユーザーの更新が失敗した場合は、Snowflakeでユーザーの所有権を確認してください。 aad_provisioner ロール(またはSnowflakeでセキュリティ統合を作成するときに run_as_role パラメーターで設定されたロール)が所有していない場合は、更新に失敗します。Snowflakeで次の SQL ステートメントを実行して所有権を譲渡し、再試行してください。

    grant ownership on user <username> to role AAD_PROVISIONER;
    
    Copy
  • 最初の SCIM プロビジョニングの後に、Azure AD の UPN 属性値 に変更がある場合、その後のユーザーの更新は機能しません。 UPN 属性値を変更すると、Azure AD ユーザーオブジェクトとSnowflakeユーザーオブジェクト間のリンクが壊れます。UPN 属性値に変更が発生した場合、正しい UPN 属性値でユーザーを再プロビジョニングします。

次のトピック: