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

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

詳細については、 複数のアカウント間にわたる複製とフェールオーバーの概要 をご参照ください。

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

このトピックの内容:

概要

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;
    Copy

  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';
    Copy

  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';
    Copy

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

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

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

    create connection GLOBAL as replica of example.northamericawest.global;
    Copy

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

    create failover group fg
as replica of example.northamericawest.fg;
    Copy

  4. セカンダリフェールオーバーグループを作成すると、最初の更新が自動的に実行されます。

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

    alter failover group fg refresh;
    Copy

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

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

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

    alter connection global primary;
    Copy

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');
    Copy

    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;
    Copy

  5. この時点で、 SCIM のターゲットアカウントのステップ に示すように、オプションでセカンダリフェールオーバーグループを更新して、ソースアカウントの新しいユーザーがターゲットアカウントにあることを確認できます。

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

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

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

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

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

    alter failover group fg refresh;
    Copy

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

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

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

    alter failover group fg primary;
    Copy

    接続:

    alter connection global primary;
    Copy

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;
    Copy

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

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

    alter failover group fg refresh;
    Copy

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

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

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

    alter failover group fg primary;
    Copy

    接続:

    alter connection global primary;
    Copy

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

ネットワークポリシーの複製

ネットワークポリシーをソースアカウントからターゲットアカウントに複製すると、管理者は受信要求の送信元のネットワーク識別子に基づいてターゲットアカウントへのアクセスを制限できます。

ネットワークポリシーの参照と割り当ての複製

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

ネットワークポリシーの参照と割り当ての複製では、参照されるオブジェクトと、ネットワークポリシーが割り当てられているオブジェクトも複製されます。サポートするオブジェクト型を適切に複製しないと、Snowflakeはターゲットアカウントでリフレッシュ操作に失敗します。

参照されるオブジェクトまたはネットワークポリシーが割り当てられているオブジェクトがターゲットアカウントにまだ存在しない場合は、そのオブジェクト型をネットワークポリシーと同じ複製グループまたはフェイルオーバーグループに含めます。以下の例は、サポートするオブジェクトがターゲットアカウントにまだ存在しない場合に必要な設定を示しています。

ネットワークルールを使用するネットワークポリシー

複製グループまたはフェイルオーバーグループは、 network policies および databases を含む必要があります。ネットワークルールはスキーマレベルのオブジェクトであり、それが含まれるデータベースと一緒に複製されます。例:

CREATE FAILOVER GROUP fg
   OBJECT_TYPES = network policies, databases
   ALLOWED_DATABASES = testdb2
   ALLOWED_ACCOUNTS = myorg.myaccount2;
Copy
アカウントに割り当てられたネットワークポリシー

複製グループまたはフェイルオーバーグループは、 network policies および account parameters を含む必要があります。ネットワークポリシーがネットワークルールを使用する場合は、 databases も含める必要があります。例:

CREATE FAILOVER GROUP fg
   OBJECT_TYPES = network policies, account parameters, databases
   ALLOWED_DATABASES = testdb2
   ALLOWED_ACCOUNTS = myorg.myaccount2;
Copy
ユーザーに割り当てられたネットワークポリシー

複製グループまたはフェイルオーバーグループは、 network policies および users を含む必要があります。ネットワークポリシーがネットワークルールを使用する場合は、 databases も含める必要があります。例:

CREATE FAILOVER GROUP fg
   OBJECT_TYPES = network policies, users, databases
   ALLOWED_DATABASES = testdb2
   ALLOWED_ACCOUNTS = myorg.myaccount2;
Copy
セキュリティ統合に割り当てられたネットワークポリシー

ネットワークポリシー複製は、Snowflake OAuth および SCIM セキュリティ統合 で指定されているネットワークポリシーに適用されます。ただし、複製グループまたはフェイルオーバーグループに integrations 、 security integrations および network policies が含まれている場合に限ります。ネットワークポリシーがネットワークルールを使用する場合は、 databases も含める必要があります。

CREATE FAILOVER GROUP fg
   OBJECT_TYPES = network policies, integrations, databases
   ALLOWED_DATABASES = testdb2
   ALLOWED_INTEGRATION_TYPES = security integrations
   ALLOWED_ACCOUNTS = myorg.myaccount2;
Copy

例

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

  • ソースアカウント: 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 と account parameters を含めます。

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

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

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

    alter failover group fg refresh;
    Copy

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

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

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

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

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

    alter failover group fg primary;
    Copy

    接続:

    alter connection global primary;
    Copy

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

ServiceNow 用Snowflakeコネクタの統合とオブジェクトの複製

ServiceNow 用Snowflakeコネクタ により、Snowflakeは ServiceNow からデータを取り込むことができます。コネクタには、Snowflakeアカウントに次のオブジェクトが必要です。

  • シークレット。

  • type = api_authentication のセキュリティの統合。

  • API 統合。

  • インジェストされたデータを格納するデータベース。

  • 使用するコネクタのウェアハウス。

  • これらのオブジェクトへのアクセスを管理するためのアカウントロール。

コネクタをインストールする前にこれらのオブジェクトを作成し、これらのオブジェクトをターゲットアカウントに複製できます。これらのオブジェクトを複製した後、ターゲットアカウントにコネクタをインストールできます。インストールはSnowflakeが提供する共有に依存するため、コネクタはターゲットアカウントにインストールする必要があります。コネクタのインストール中に共有からデータベースを作成する必要があり、共有から作成されたデータベースを複製することはできません。

アカウントオブジェクトの複製をどのように管理するかに応じて、1つ以上の複製またはフェールオーバーグループを持つことができます。単一の複製グループは、オブジェクトの複製管理を一元化し、一部のオブジェクトが複製され、他のオブジェクトが複製されないというシナリオを回避します。それ以外の場合は、複製操作を慎重に調整して、すべてのオブジェクトがターゲットアカウントに複製されるようにする必要があります。

たとえば、データベースのレプリケーショングループを作成できます。この複製グループ（例: rg1）は、シークレットを含むデータベースと ServiceNow データを格納するデータベースを指定します。もう一方の複製グループ（rg2 など）は、ユーザー、ロール、統合オブジェクト、およびこれらのロールのユーザーへの付与を指定します。このシナリオでは、最初に統合を複製してから、ターゲットアカウントを更新してシークレットデータベース、ユーザー、およびロールを含めることにした場合、複製の更新操作は成功します。

しかし、統合を複製する前に、ユーザーとロール、およびグループ内のシークレットを含むデータベースを複製すると、セキュリティ統合が複製されるまでプレースホルダシークレットが使用されます。プレースホルダーシークレットはダングリング参照を防ぎます。セキュリティ統合が複製されると、プレースホルダーシークレットは実際のシークレットに置き換えられます。

このプロシージャは、以下を実行するための代表例です。

  • シークレットデータとインジェストされたデータを含む統合とデータベースを複製します。

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

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

  • 複製後にコネクタをインストールして使用します。

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

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

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

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

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

  • アクセスを制限するための認証およびネットワークポリシーのためのその他のセキュリティ統合は、既に複製されています。

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

  1. これらの各オブジェクトタイプに対して SHOW コマンドを実行して、コネクタのオブジェクトがソースSnowflakeアカウントに存在することを確認します。

    show secrets in database secretsdb;
show security integrations;
show api integrations;
show tables in database destdb;
show warehouses;
show roles;
    Copy

    secretsdb はシークレットを含むデータベースの名前であり、 destdb は ServiceNow からインジェストされたデータを含むデータベースの名前であることに注意してください。

  2. ALTER FAILOVER GROUP コマンドを使用して、フェイルオーバーグループを更新して、API 統合と、シークレットおよびインジェストされたデータを含むデータベースを含めます。

    alter failover group fg set
  object_types = databases, users, roles, warehouses, resource monitors, integrations, network policies, account parameters
  allowed_databases = secretsdb, destdb
  allowed_integration_types = security integrations, api integrations;
    Copy

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

  1. セカンダリフェールオーバーグループを更新して、統合とデータベースをターゲットアカウントに複製します。

    alter failover group fg refresh;
    Copy

  2. 次の SHOW コマンドを使用して、複製されたオブジェクトが存在することを確認します。

    show secrets;
show security integrations;
show api integrations;
show database;
show tables in database destdb;
show roles;
    Copy

  3. 選択したメソッド（ブラウザ、SnowSQL など）を使用して、各Snowflakeアカウントに接続していることを確認します。

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

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

    alter failover group fg primary;
    Copy

    接続:

    alter connection global primary;
    Copy

  5. 前のステップを完了した場合は、各Snowflakeアカウントに接続できることを再確認します。

    この時点で、ターゲットアカウントには複製されたオブジェクトが含まれており、ユーザーはログインできます。ただし、ターゲットアカウントでコネクタを使用するための追加の手順があります。

  6. Snowflakeアカウントをホストするクラウドプラットフォームで API 統合に関連付けられたリモートサービスを更新します。

    詳細については、 API 統合のリモートサービスの更新 をご参照ください。

  7. コネクターを手動で、またはSnowsightを使用してインストールします。詳細については、次をご参照ください。

  8. Snowflakeでの ServiceNow データへのアクセス。

言語: 日本語