複数のアカウントにわたるセキュリティ統合およびネットワークポリシーの複製

このトピックでは、セキュリティ統合を複製する方法と、これらの各オブジェクトでフェールオーバー/フェールバックを使用する方法について説明し、複製と他のアカウントレベルのオブジェクト(例: ユーザー、ロール、ウェアハウス)におけるフェールオーバー/フェールバックに精通していることを前提としています。

詳細については、 アカウント複製およびフェールオーバー をご参照ください。

これらのオブジェクトとサービスは、 リージョンクラウドプラットフォーム でサポートされています。

このトピックの内容:

概要

Snowflakeは、フェデレーション SSO (つまり、 SAML2)、 OAuth、および SCIM のネットワークポリシーとセキュリティ統合の複製をサポートし、各ネットワークポリシーと統合のフェールオーバー/フェールバックを有効にします。

各ネットワークポリシーとセキュリティ統合を使用して、複製とフェールオーバー/フェールバックをテストする一般的なアプローチは次のとおりです。

  1. 複製のソースアカウントとターゲットアカウントを識別し、接続 URL を識別します。

  2. ソースアカウントでステップを完了します。

  3. ターゲットアカウントでステップを完了します。

  4. フェールオーバー/フェールバックをテストします。

ネットワークポリシーとセキュリティ統合には異なるユースケースがあるため、各オブジェクトに関するソースアカウントとターゲットアカウントの正確なステップはわずかに異なることに注意してください。

詳細については、以下をご参照ください。

SAML2 セキュリティ統合

SAML2 セキュリティ統合を複製すると、 SAML2 セキュリティ統合定義で 接続 URL を指定することにより、ソースアカウントとターゲットアカウントがIDプロバイダーにリンクされます。

接続 URL を指定するようにIDプロバイダーを更新し、ユーザーはソースアカウントに存在するようにすることが重要です。これらの更新がないと、ユーザーの確認が行われず、ユーザーがターゲットアカウントにアクセスできなくなります。

現在の制限

SAML SSO からSnowflakeへの場合、接続 URL を指定する SAML2 セキュリティ統合の複製は、現在のプライマリ接続でのみサポートされ、セカンダリ接続ではサポートされません。フェールオーバーの場合、結果により、セカンダリ接続はプライマリ接続として機能するように昇格されます。フェールオーバー後、 SAML SSO は新しいプライマリ接続で機能します。

プライマリ接続とセカンダリ接続の両方に SAML SSO が必要な場合は、両方のSnowflakeアカウントで SAML2 セキュリティ統合を個別に作成および管理します。

この手順では、次を前提としています。

  • ソースアカウント: https://example-northamericawest.snowflakecomputing.com/

  • ターゲットアカウント: https://example-northamericaeast.snowflakecomputing.com/

  • 接続 URL: https://example-global.snowflakecomputing.com

  • セカンダリ接続は、ターゲットアカウントには存在しません。

次のステップは、以下の方法を示す代表的な例です。

  • SAML2 セキュリティ統合をソースアカウントからターゲットアカウントに複製します。

  • フェールオーバーをテストします。

  • ソースアカウントのセカンダリ接続を昇格して、プライマリ接続として機能させます。

ソースアカウントのステップ(IdP のステップを含む):

  1. ソースアカウントがすでに データベースフェールオーバー/フェールバックおよびクライアントリダイレクト 用に構成されている場合は、次のステップにスキップします。

    それ以外の場合は、 ALTER CONNECTION コマンドを使用してフェールオーバーを有効にします。

    alter connection global
    enable failover to accounts example.northamericaeast;
    
  2. IDプロバイダーの代表的な例としてOktaを使用して、接続 URL を指定する SnowflakeアプリケーションをOktaに に作成します。Oktaフィールドを次のように更新します。

    • Label: Snowflake

    • Subdomain: example-global

    • Browser plugin auto-submit: ユーザーがログインページにアクセスしたときの自動ログインを有効にするには、チェックボックスをオンにします。

  3. ソースアカウントで、 SAML2 セキュリティ統合を更新して、 saml2_snowflake_issuer_url および saml2_snowflake_acs_url セキュリティ統合プロパティの接続 URL を指定します。

    create or replace security integration my_idp
      type = saml2
      enabled = true
      saml2_issuer = 'http://www.okta.com/exk6e8mmrgJPj68PH4x7'
      saml2_sso_url = 'https://example.okta.com/app/snowflake/exk6e8mmrgJPj68PH4x7/sso/saml'
      saml2_provider = 'OKTA'
      saml2_x509_cert='MIIDp...'
      saml2_sp_initiated_login_page_label = 'OKTA'
      saml2_enable_sp_initiated = true
      saml2_snowflake_issuer_url = 'https://example-global.snowflakecomputing.com'
      saml2_snowflake_acs_url = 'https://example-global.snowflakecomputing.com/fed/login';
    
  4. Oktaで、Snowflakeアプリケーションをユーザーに割り当てます。詳細については、 ユーザーにアプリ統合を割り当てる をご参照ください。

  5. ソースアカウントへの SSO が、OktaのSnowflakeアプリケーションで指定されているユーザーとソースアカウントのユーザーに対して機能することを確認します。

    SSO は、 IdP によって開始されるフローとSnowflakeによって開始される SSO フローの両方で機能する必要があることに注意してください。詳細については、 サポートされている SSO ワークフロー をご参照ください。

  6. ソースアカウントで、フェールオーバーグループがまだ存在しない場合は、フェールオーバーグループを 作成 して、セキュリティ統合を含めます。この例は代表的なものであり、複製する必要がある場合とない場合がある他のアカウントオブジェクトが含まれていることに注意してください。

    フェールオーバーグループがすでに存在する場合は、フェールオーバーグループを 変更 して統合を含めます。

    create failover group FG
      object_types = users, roles, warehouses, resource monitors, integrations
      allowed_integration_types = security integrations
      allowed_accounts = example.northamericaeast
      replication_schedule = '10 MINUTE';
    

ターゲットアカウントのステップ:

  1. 複製の前に、それぞれ SHOW USERS コマンドと SHOW INTEGRATIONS コマンドを実行して、ターゲットアカウントに存在するユーザー数とセキュリティ統合を確認します。

  2. セカンダリ接続を作成します。詳細については、 CREATE CONNECTION をご参照ください。

    create connection GLOBAL as replica of example.northamericawest.global;
    
  3. ターゲットアカウントにセカンダリフェールオーバーグループを作成します。詳細については、 CREATE FAILOVER GROUP をご参照ください。

    create failover group fg
    as replica of example.northamericawest.fg;
    
  4. セカンダリフェールオーバーグループを作成すると、最初の更新が自動的に実行されます。

    ターゲットアカウントのセカンダリフェールオーバーグループを手動で更新するには、次のステートメントを実行します。詳細については、 ALTER FAILOVER GROUP コマンドをご参照ください。

    alter failover group fg refresh;
    
  5. 更新操作が成功した場合、ターゲットアカウントには、以前はターゲットアカウントに存在していなかった、ソースアカウントに追加された新しいユーザーが含まれているはずです。同様に、ターゲットアカウントには、接続 URL を指定する SAML2 セキュリティ統合が含まれているはずです。

    次のコマンドを実行して、更新操作が成功したことを確認します。

  6. ターゲットアカウントのセカンダリ接続を昇格して、プライマリ接続として機能させます。次のコマンドを実行した後、ユーザーは SAML SSO を使用して新しいターゲットアカウントへの認証を行うことができます。

    alter connection global primary;
    

SCIM セキュリティ統合

SCIM セキュリティ統合を複製すると、ターゲットアカウントを更新した後、ソースアカウントに対して行われた SCIM 更新(例: 新しいユーザーの追加、新しいロールの追加)をターゲットアカウントに組み込むことができるようになります。

SCIM セキュリティ統合を複製した後、両方のSnowflakeアカウントはIDプロバイダーから SCIM 更新を受信することができます。ただし、Snowflakeでは、 プライマリ (つまり、ソース)アカウントとして指定できるアカウントは1つだけであり、IDプロバイダーから SCIM の更新を受信するのはプライマリアカウントです。

オプションで、 SCIM 統合を複製した後に、 SCIM 更新を受信するプライマリアカウントとして別のアカウントを指定できます。ターゲットアカウントは、ターゲットアカウントを更新した後にのみ、ソースアカウントから SCIM の更新を受信できることに注意してください。

この手順では、次を前提としています。

  • ソースアカウント: https://example-northamericawest.snowflakecomputing.com/

  • ターゲットアカウント: https://example-northamericaeast.snowflakecomputing.com/

  • 接続 URL: https://example-global.snowflakecomputing.com

  • セカンダリ接続は、ターゲットアカウントに存在します(つまり、更新操作のみが必要です)。

次のステップは、以下の方法を示す代表的な例です。

  • SCIM セキュリティ統合をソースアカウントからターゲットアカウントに複製します。

  • Oktaに新しいユーザーを追加し、新しいユーザーをソースアカウントにプッシュして、新しいユーザーをターゲットアカウントに複製します。

  • フェールオーバーグループを更新します。

  • ターゲットアカウントのセカンダリ接続を昇格して、プライマリ接続として機能させます。

ソースアカウントのステップ:

  1. SHOW CONNECTIONS を実行して、ソースアカウントの接続がプライマリ接続であることを確認します。プライマリ接続でない場合は、 ALTER CONNECTION コマンドを使用して、ソースアカウントの接続をプライマリ接続として機能するように昇格します。

  2. Okta SCIM セキュリティ統合がソースアカウントですでに構成されている場合は、次のステップにスキップします。

    それ以外の場合は、ソースアカウントで Okta SCIM セキュリティ統合を構成します。

    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 accountadmin;
    create or replace security integration okta_provisioning
       type = scim
       scim_client = 'okta'
       run_as_role = 'OKTA_PROVISIONER';
    
    select system$generate_scim_access_token('OKTA_PROVISIONING');
    

    SnowflakeのOkta SCIM アプリケーションは必ず更新してください。詳細については、 Oktaの構成 をご参照ください。

  3. Oktaで、SnowflakeのOktaアプリケーションに 新しいユーザーを作成 します。

    Snowflakeで SHOW USERS コマンドを実行して、ユーザーがSnowflakeにプッシュされていることを確認します。

  4. フェールオーバーグループがすでに security integrations を指定している場合は、次のステップにスキップします。これは、 ターゲットアカウント内の SAML SSO (このトピック内)のためにフェールオーバーグループをすでに構成している場合に当てはまります。

    それ以外の場合は、 ALTER FAILOVER GROUP コマンドを使用して既存のフェールオーバーグループを変更し、 security integrations を指定します。

    alter failover group fG set
      object_types = users, roles, warehouses, resource monitors, integrations
      allowed_integration_types = security integrations;
    
  5. この時点で、 SCIM のターゲットアカウントのステップ に示すように、オプションでセカンダリフェールオーバーグループを更新して、ソースアカウントの新しいユーザーがターゲットアカウントにあることを確認できます。

    セカンダリフェールオーバーグループの更新を選択すると、ソースアカウントへの変更、この順序での新しいユーザーの追加がターゲットアカウントに表示されることを簡単に確認できるようになりました。

    ただし、他のユーザーの変更やロールの割り当ての更新など、IDプロバイダーで追加の作業が必要な場合や、作業を希望する場合は、今その作業を続行し、1回の操作後にセカンダリフェールオーバーグループを更新できます。

ターゲットアカウントのステップ:

  1. 複製の前に、それぞれ SHOW USERS コマンドと SHOW INTEGRATIONS コマンドを実行して、ターゲットアカウントに存在するユーザー数とセキュリティ統合を確認します。

  2. セカンダリフェールオーバーグループを更新して、ターゲットアカウントを更新し、新しいユーザー(および、Oktaとソースアカウントで行われたその他の変更)を含めます。

    alter failover group fg refresh;
    
  3. SHOW USERS コマンドを実行して、新しいユーザーがターゲットアカウントに追加されていることを確認します。

  4. 必要に応じて、ターゲットアカウントのセカンダリフェールオーバーグループとセカンダリ接続をプライマリに昇格させます。これにより、ターゲットアカウントが昇格され、新しいソースアカウントとして機能するようになります。

    フェールオーバーグループ:

    alter failover group fg primary;
    

    接続:

    alter connection global primary;
    

OAuth セキュリティ統合

OAuth セキュリティ統合の複製には、Snowflake OAuth セキュリティ統合と外部 OAuth セキュリティ統合の両方が含まれます。

次の点に注意してください。

Snowflake OAuth

複製とフェールオーバー/フェールバックの構成後、 OAuth クライアントを介してソースアカウントまたはターゲットアカウントのいずれかに接続するユーザーには、ターゲットアカウントへの再認証は必要ありません。

外部 OAuth

複製とフェールオーバー/フェールバックの構成後、 OAuth クライアントを介してソースアカウントまたはターゲットアカウントのいずれかに接続するユーザーには、ターゲットアカウントへの再認証が必要になる 可能性があります

OAuth 認証サーバーが 更新トークン を発行するように構成されていない場合は、再認証が必要になる可能性があります。したがって、 OAuth クライアントがソースおよびターゲットのSnowflakeアカウントに接続できるように、 OAuth 認証サーバーが更新トークンを発行することを確認してください。

この手順では、次を前提としています。

  • ソースアカウント: https://example-northamericawest.snowflakecomputing.com/

  • ターゲットアカウント: https://example-northamericaeast.snowflakecomputing.com/

  • 接続 URL: https://example-global.snowflakecomputing.com

  • セカンダリ接続は、ターゲットアカウントに存在します(つまり、更新操作のみが必要です)。

  • Snowflake OAuth または外部 OAuth のセキュリティ統合は、ソースアカウントにすでに存在しています。

次のステップは、以下の方法を示す代表的な例です。

  • OAuth セキュリティ統合を複製します。

  • フェールオーバーグループを更新します。

  • ターゲットアカウントのセカンダリ接続を昇格して、プライマリ接続として機能させます。

ソースアカウントのステップ:

  1. フェールオーバーグループがすでに security integrations を指定している場合は、次のステップにスキップします。これは、 ターゲットアカウント内の SAML SSO (このトピック内)または SCIM (同じくこのトピック内)のためにフェールオーバーグループをすでに構成している場合に当てはまります。

    それ以外の場合は、 ALTER FAILOVER GROUP コマンドを使用して既存のフェールオーバーグループを変更し、 security integrations を指定します。

    alter failover group fG set
      object_types = users, roles, warehouses, resource monitors, integrations
      allowed_integration_types = security integrations;
    

ターゲットアカウントのステップ:

  1. セカンダリフェールオーバーグループを更新して、ターゲットアカウントを更新し、 OAuth セキュリティ統合オブジェクトを含めます。

    alter failover group fg refresh;
    
  2. 選択した OAuth クライアントを使用して、各Snowflakeアカウントに接続していることを確認します。

  3. 必要に応じて、ターゲットアカウントのセカンダリフェールオーバーグループとセカンダリ接続をプライマリに昇格させます。これにより、ターゲットアカウントが昇格され、新しいソースアカウントとして機能するようになります。

    フェールオーバーグループ:

    alter failover group fg primary;
    

    接続:

    alter connection global primary;
    
  4. 前のステップを完了した場合は、選択した OAuth クライアントを使用して各Snowflakeアカウントに接続できることを再確認します。

ネットワークポリシー

ネットワークポリシーをソースアカウントからターゲットアカウントに複製すると、管理者はSnowflakeに接続するときに、ユーザー IP アドレスに基づいてターゲットアカウントへのアクセスを制限できます。

ネットワークポリシーを複製すると、ネットワークポリシーオブジェクト および ネットワークポリシーの参照/割り当てが複製されます。たとえば、ネットワークポリシーがユーザーに割り当てられており、ユーザーがソースアカウントとターゲットアカウントの両方に存在する場合、ネットワークポリシーを複製すると、ネットワークポリシーがターゲットアカウントのユーザーに割り当てられます。

ネットワークポリシー複製は、Snowflake OAuth および SCIM セキュリティ統合 で指定されているネットワークポリシーにも適用されます。ただし、複製操作でセキュリティ統合とネットワークポリシーが指定されている場合に限ります。ネットワークポリシーとネットワークポリシーを指定するセキュリティ統合を複製した後、ターゲットアカウントのセキュリティ統合は同じネットワークポリシーを指定します。

この手順では、次を前提としています。

  • ソースアカウント: https://example-northamericawest.snowflakecomputing.com/

  • ターゲットアカウント: https://example-northamericaeast.snowflakecomputing.com/

  • 接続 URL: https://example-global.snowflakecomputing.com

  • セカンダリ接続は、ターゲットアカウントに存在します(つまり、更新操作のみが必要です)。

  • ネットワークポリシーはソースアカウントに存在します。

  • Snowflake OAuth および/または SCIM セキュリティ統合はソースアカウントにすでに存在し、統合はネットワークポリシーを指定します。

次の手順は、以下を実行するための代表的な例です。

  • ネットワークポリシーと、ネットワークポリシーを指定するセキュリティ統合を複製します。

  • フェールオーバーグループを更新します。

  • ネットワークポリシーのアクティブ化を確認します。

  • ソースアカウントのセカンダリ接続を昇格して、プライマリ接続として機能させます。

ソースアカウントのステップ:

  1. SHOW NETWORK POLICIES コマンドを実行して、ソースSnowflakeアカウントにネットワークポリシーが存在することを確認します。

  2. Snowflake OAuth および/または SCIM セキュリティ統合にネットワークポリシーが含まれていることを確認するには、 SHOW INTEGRATIONS コマンドを実行してセキュリティ統合を識別してから、Snowflake OAuth セキュリティ統合で DESCRIBE INTEGRATION コマンドを実行します。

  3. ALTER FAILOVER GROUP コマンドを使用してフェールオーバーグループを更新し、 network policies を含めます。

    alter failover group fG set
      object_types = users, roles, warehouses, resource monitors, integrations, network policies
      allowed_integration_types = security integrations;
    

ターゲットアカウントのステップ:

  1. セカンダリフェールオーバーグループを更新して、ターゲットアカウントを更新し、ネットワークポリシーオブジェクトと、ネットワークポリシーを指定するSnowflake OAuth セキュリティ統合を含めます。

    alter failover group fg refresh;
    
  2. SHOW NETWORK POLICIES コマンドを実行してネットワークポリシーオブジェクトが存在することを確認し、セキュリティ統合で DESCRIBE SECURITY INTEGRATION コマンドを実行して、Snowflake OAuth セキュリティ統合が複製されたネットワークポリシーを指定していることを確認します。

  3. アカウントまたはユーザーレベルでアクティブ化されたネットワークポリシーの特定 に示すように、ネットワークポリシーのアクティブ化を確認します。

  4. 選択したSnowflake OAuth クライアントを使用して、各Snowflakeアカウントに接続していることを確認します。

  5. 必要に応じて、ターゲットアカウントのセカンダリフェールオーバーグループとセカンダリ接続をプライマリに昇格させます。これにより、ターゲットアカウントが昇格され、新しいソースアカウントとして機能するようになります。

    フェールオーバーグループ:

    alter failover group fg primary;
    

    接続:

    alter connection global primary;
    
  6. 前のステップを完了した場合は、選択したSnowflake OAuth クライアントを使用して各Snowflakeアカウントに接続できることを再確認します。

最上部に戻る