Snowflakeとのカスタム SCIM 統合¶

カスタム SCIM 統合により、ユーザーは独自のアプリケーションを構築して、IDプロバイダーと結合し、Snowflakeにユーザーとロールをプロビジョニング、マッピング、管理できます。

現在、OktaでもMicrosoft Azure AD でもないIDプロバイダーでは、カスタム SCIM 統合がサポートされています。

SCIM アプリケーションを作成したら、以下の手順に従ってSnowflake セキュリティ統合を作成し、 SCIM API 認証トークンを生成します。 SCIM API リクエストの実行で説明されているように、認証トークンを保存し、 SCIM API リクエストヘッダーに含めます。

制限事項¶

Snowflakeは、SCIMエンドポイント（例えば、 /Users エンドポイント、 /Groups エンドポイント）ごとに、アカウントにつき最大500の同時リクエストをサポートします。アカウントがこのしきい値を超えると、Snowflakeは 429 HTTP ステータスコード（つまり、リクエストが多すぎる）を返します。このリクエスト制限は通常、ユーザーまたはグループをプロビジョニングするために比較的多数のリクエスト（つまり、1万以上）が発生する、初期プロビジョニング中にのみ発生します。
Snowflake アカウント URL の作成時にアンダースコアが含まれていた場合は、アンダースコアまたはハイフンを含むアカウント URL でSnowflakeアカウントにアクセスできます。

SCIM プロバイダーが SAML SSO と SCIM の両方に同じアカウント URLs を再利用する場合、アンダースコアを含む URL はサポートされません。そのため、ハイフンを含むアカウント URL を使用して SCIM を構成します。

アンダースコアを含まないSnowflakeアカウント URLs は、この制限による制約を受けません。
カスタム SCIM 統合では、ネストされたグループのプロビジョニングと管理が許可される場合と許可されない場合があります。カスタム SCIM 統合を使用してSnowflakeでネストされたグループをプロビジョニングする前に、IDプロバイダーに連絡して、ネストされたグループを SCIM 統合で使用できるかどうかを確認してください。
Snowflakeサービスへのプライベート接続を使用してSnowflakeにアクセスしている場合は、統合設定に URLs を入力していないことを確認してください。パブリックエンドポイント（つまり、 .privatelink なし）を入力し、ネットワークポリシーがIdP IPアドレスからのアクセスを許可していることを確認してください。さもなければ、この統合を使用することはできません。
- IdPアカウントとSnowflakeアカウントの両方がMicrosoft Azureでホストされている場合、Snowflakeのネットワークポリシーがパブリッククラウドまたは US Government Cloud のためのすべてのAzure AD IPアドレスからのアクセスを許可する必要があることに注意してください。現在、ネットワークポリシーにはすべてのAzure AD IPアドレスが必要です。詳細については、 SCIM ネットワークポリシーの管理をご参照ください。
カスタムIDプロバイダーからSnowflakeへのパスワードの同期を有効または無効にします。

Snowflakeセキュリティ統合での SYNC_PASSWORD プロパティの設定は、Okta SCIM 統合でのみサポートされています。

前提条件¶

ユーザーまたはグループをプロビジョニングする前に、Snowflakeのネットワークポリシーが組織に対応する IP 範囲からのアクセスを許可していることを確認します。詳細については、 SCIM ネットワークポリシーの管理をご参照ください。

カスタム SCIM セキュリティ統合と API トークンの作成¶

Snowflakeの構成プロセスでは、 SCIM のセキュリティ統合を作成して、IDプロバイダーで作成されたユーザーとロールをSnowflakeの GENERIC_SCIM_PROVISIONER SCIM ロールが所有できるようにし、 SCIM API リクエストで使用するアクセストークンを作成します。アクセストークンは6か月間有効です。有効期限が切れたら、以下に示すように手動で SYSTEM$GENERATE_SCIM_ACCESS_TOKEN を使用して、新しいアクセストークンを作成します。

注釈

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

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

優先するSnowflakeクライアントで、次の SQL ステートメントを実行します。次の各ステートメントについて、以下で説明します。

use role accountadmin;
create role if not exists generic_scim_provisioner;
grant create user on account to role generic_scim_provisioner;
grant create role on account to role generic_scim_provisioner;
grant role generic_scim_provisioner to role accountadmin;
create or replace security integration generic_scim_provisioning
    type=scim
    scim_client='generic'
    run_as_role='GENERIC_SCIM_PROVISIONER';
select system$generate_scim_access_token('GENERIC_SCIM_PROVISIONING');

Copy

重要

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

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

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

SQL ステートメントの例に示されているように ACCOUNTADMIN ロールを使用。
グローバル MANAGE GRANTS 権限を持つロールを使用。
最初にある2つのオプションのいずれも望ましくない場合は、 SCIM を使用して管理されるすべてのロールに対して OWNERSHIP 権限を持つ、カスタムロールを使用してください。

ACCOUNTADMIN ロールを使用します。
use role accountadmin;
Copy
カスタムロール GENERIC_SCIM_PROVISIONER を作成します。IdP によって作成されたSnowflakeのすべてのユーザーとロールは、スコープが絞られた GENERIC_SCIM_PROVISIONER ロールによって所有されます。
create role if not exists generic_scim_provisioner; grant create user on account to role generic_scim_provisioner; grant create role on account to role generic_scim_provisioner;
Copy

GENERIC_SCIM_PROVISIONER カスタムロールを使用して、 ACCOUNTADMIN ロールによるセキュリティ統合の作成を許可します。詳細については、 CREATE SECURITY INTEGRATION をご参照ください。

grant role generic_scim_provisioner to role accountadmin;
create or replace security integration generic_scim_provisioning
    type = scim
    scim_client = 'generic'
    run_as_role = 'GENERIC_SCIM_PROVISIONER';

Copy

認証トークンを作成して保存し、後で使用できるように安全に保存します。SCIM REST API リクエストごとにこのトークンを使用し、リクエストヘッダーに配置します。アクセストークンは6か月後に期限が切れます。このステートメントを使用して新しいアクセストークンを生成できます。
select system$generate_scim_access_token('GENERIC_SCIM_PROVISIONING');
Copy

Snowflake起動 SSO の有効化¶

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

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

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

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

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

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

alter security integration generic_scim_provisioning set network_policy = <scim_network_policy>;

Copy

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

alter security integration generic_scim_provisioning unset network_policy;

Copy

条件:

generic_scim_provisioning: カスタムSCIMセキュリティ統合の名前を指定します。
scim_network_policy: SnowflakeのカスタムSCIMネットワークポリシーを指定します。

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

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

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

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

カスタム SCIM セキュリティ統合の複製¶

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

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

次のトピック：

SCIM API リクエストの実行