Replikation von Sicherheitsintegrationen und Netzwerkrichtlinien über mehrere Konten hinweg¶

Übersicht¶

Snowflake unterstützt die Replikation von Netzwerkrichtlinien und Sicherheitsintegrationen für Verbund-SSO (d. h. SAML2), OAuth und SCIM sowie die Aktivierung von Failover/Failback für jede Netzwerkrichtlinie und Integration.

Der allgemeine Ansatz zum Testen von Replikation und Failover/Failback mit jeder Netzwerkrichtlinie und Sicherheitsintegration ist wie folgt:

1. Geben Sie das Quellkonto und das Zielkonto für die Replikation an, und identifizieren Sie die Verbindungs-URL.

2. Führen Sie die erforderlichen Schritte im Quellkonto aus.

3. Führen Sie die erforderlichen Schritte im Zielkonto ab.

4. Testen Sie Failover/Failback.

Beachten Sie, dass die genauen Schritte für Quellkonto und Zielkonto hinsichtlich der jeweiligen Objekte leicht voneinander abweichen, da Netzwerkrichtlinien und Sicherheitsintegrationen zu unterschiedlichen Zwecken eingesetzt werden.

Weitere Details dazu finden Sie unter:

• Replizieren von SAML2-Sicherheitsintegrationen

• Replizieren von SCIM-Sicherheitsintegrationen

• Replizieren von OAuth-Sicherheitsintegrationen

• Replizieren von Netzwerkrichtlinien

• Replizieren von Integrationen und Objekten für den Snowflake-Konnektor für ServiceNow

Replizieren von SAML2-Sicherheitsintegrationen¶

Beim Replizieren einer SAML2-Sicherheitsintegration werden Quellkonto und Zielkonto mit dem Identitätsanbieter verknüpft, indem die Verbindungs-URL in der Definition der SAML2-Sicherheitsintegration angegeben wird.

Es ist wichtig, den Identitätsanbieter zu aktualisieren, um die Verbindungs-URL sowie das Vorhandensein von Benutzern im Quellkonto anzugeben. Ohne diese Aktualisierungen kann die Benutzerüberprüfung nicht stattfinden, was dazu führt, dass der Benutzer nicht auf das Zielkonto zugreifen kann.

Aktuelle Einschränkungen:

Für SAML-SSO zu Snowflake wird das Replizieren einer SAML2-Sicherheitsintegration, die die Verbindungs-URL angibt, nur für die aktuelle Primärverbindung und nicht für die Sekundärverbindung unterstützt. Beachten Sie, dass im Ergebnis des Failovers eine Sekundärverbindung zur Verwendung als Primärverbindung heraufgestuft wird. Nach dem Failover wird SAML-SSO über die neue Primärverbindung ausgeführt.

Wenn SAML-SSO sowohl für Primär- als auch für Sekundärverbindungen benötigt wird, erstellen und verwalten Sie SAML2-Sicherheitsintegrationen unabhängig in beiden Snowflake-Konten.

Gehen Sie bei diesem Verfahren von folgenden Annahmen aus:

• Quellkonto: https://example-northamericawest.snowflakecomputing.com/

• Zielkonto: https://example-northamericaeast.snowflakecomputing.com/

• Verbindungs-URL: https://example-global.snowflakecomputing.com

• Im Zielkonto ist keine Sekundärverbindung vorhanden.

Das folgende Verfahren ist ein repräsentatives Beispiel, um Folgendes zu tun:

• Replizieren Sie eine SAML2-Sicherheitsintegration vom Quellkonto in das Zielkonto.

• Testes Sie das Failover.

• Stufen Sie die Sekundärverbindung im Quellkonto zur Primärverbindung herauf.

Schritte für Quellkonto (enthält IdP-Schritte):

1. Wenn das Quellkonto bereits für Datenbank-Failover/Failback und Clientumleitung konfiguriert ist, fahren Sie mit dem nächsten Schritt fort.

   Andernfalls aktivieren Sie das Failover mit einem ALTER CONNECTION-Befehl:

   alter connection global
   enable failover to accounts example.northamericaeast;
   

   Copy

2. Erstellen Sie mit Okta als repräsentativem Beispiel für einen Identitätsanbieter eine Snowflake-Anwendung in Okta, die die Verbindungs-URL angibt. Aktualisieren Sie die Okta-Felder wie folgt:

   • Label: Snowflake

   • Subdomain: example-global

   • Browser plugin auto-submit: Aktivieren Sie dieses Kontrollkästchen, um das automatische Anmelden zu aktivieren, wenn ein Benutzer auf die Anmeldeseite wechselt.

3. Aktualisieren Sie im Quellkonto die SAML2-Sicherheitsintegration, um die Verbindungs-URL für die Eigenschaften saml2_snowflake_issuer_url und saml2_snowflake_acs_url der Sicherheitsintegration anzugeben.

   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. Weisen Sie in Okta den Benutzern die Snowflake-Anwendung zu. Weitere Informationen dazu finden Sie unter Benutzern eine App-Integration zuweisen.

5. Überprüfen Sie, ob SSO zum Quellkonto für die Benutzer funktioniert, die in der Snowflake-Anwendung in Okta angegeben sind, sowie für die Benutzer, die im Quellkonto angegeben sind.

   Beachten Sie, dass SSO sowohl für IdP-initiierte als auch für Snowflake-initiierte SSO-Abläufe funktionieren muss. Weitere Details dazu finden Sie unter Unterstützte SSO-Workflows.

6. Wenn im Quellkonto noch keine Failover-Gruppe vorhanden ist, erstellen Sie eine Failover-Gruppe, um Sicherheitsintegrationen einzufügen. Beachten Sie, dass dieses Beispiel repräsentativ ist und auch andere Kontoobjekte enthält, die für eine Replikation erforderlich sein können oder auch nicht.

   Wenn bereits eine Failover-Gruppe vorhanden ist, ändern Sie die Failover-Gruppe, um Integrationen einzufügen.

   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

Schritte im Zielkonto:

1. Überprüfen Sie vor der Replikation die Anzahl der Benutzer und Sicherheitsintegrationen, die im Zielkonto vorhanden sind, indem Sie die Befehle SHOW USERS bzw. SHOW INTEGRATIONS ausführen.

2. Erstellen Sie eine Sekundärverbindung. Weitere Details dazu finden Sie unter CREATE CONNECTION.

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

   Copy

3. Erstellen Sie eine sekundäre Failover-Gruppe im Zielkonto. Weitere Details dazu finden Sie unter CREATE FAILOVER GROUP.

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

   Copy

4. Beim Erstellen einer sekundären Failover-Gruppe wird automatisch eine erste Aktualisierung ausgeführt.

   Führen Sie die folgende Anweisung aus, um eine sekundäre Failover-Gruppe im Zielkonto manuell zu aktualisieren. Weitere Informationen dazu finden Sie unter dem Befehl ALTER FAILOVER GROUP.

   alter failover group fg refresh;
   

   Copy

5. Wenn die Aktualisierungsoperation erfolgreich war, sollte das Zielkonto neue Benutzer enthalten, die dem Quellkonto hinzugefügt wurden und vorher nicht im Zielkonto vorhanden waren. In ähnlicher Weise sollte das Zielkonto die SAML2-Sicherheitsintegration enthalten, die die Verbindungs-URL spezifiziert.

   Überprüfen Sie, ob die Aktualisierungsoperation erfolgreich war, indem Sie die folgenden Befehle ausführen:

   • SHOW INTEGRATIONS (sollte 1 neue Integration enthalten)

   • SHOW USERS (sollte die Anzahl der neu hinzugefügten Benutzer enthalten)

   • DESCRIBE INTEGRATION (für die Integration myidp)

6. Stufen Sie die Sekundärverbindung im Zielkonto herauf, damit diese als Primärverbindung dient. Nach Ausführung des folgenden Befehls können sich die Benutzer beim neuen Zielkonto mit SAML-SSO authentifizieren.

   alter connection global primary;
   

   Copy

Replizieren von SCIM-Sicherheitsintegrationen¶

Durch das Replizieren einer SCIM-Sicherheitsintegration kann das Zielkonto SCIM-Aktualisierungen übernehmen, die am Quellkonto vorgenommen werden (z. B. Hinzufügen neuer Benutzer, Hinzufügen neuer Rollen), nachdem das Zielkonto aktualisiert wurde.

Nach der Replikation der SCIM-Sicherheitsintegration sind beide Snowflake-Konten in der Lage, SCIM-Aktualisierungen vom Identitätsanbieter zu erhalten. Allerdings erlaubt Snowflake nur die Angabe eines Kontos als Primärkonto (d. h. Quellkonto), und es ist das Primärkonto, das SCIM-Aktualisierungen vom Identitätsanbieter erhält.

Sie können optional ein anderes Konto als Primärkonto bestimmen, das nach der Replikation der SCIM-Integration die SCIM-Aktualisierungen erhält. Beachten Sie, dass das Zielkonto SCIM-Aktualisierungen vom Quellkonto erst nach der Aktualisierung des Zielkontos erhalten kann.

Gehen Sie bei diesem Verfahren von folgenden Annahmen aus:

• Quellkonto: https://example-northamericawest.snowflakecomputing.com/

• Zielkonto: https://example-northamericaeast.snowflakecomputing.com/

• Verbindungs-URL: https://example-global.snowflakecomputing.com

• Im Zielkonto ist eine Sekundärverbindung vorhanden (d. h. es sind nur Aktualisierungsoperationen erforderlich).

Das folgende Verfahren ist ein repräsentatives Beispiel, um Folgendes zu tun:

• Replizieren Sie eine SCIM-Sicherheitsintegration vom Quellkonto in das Zielkonto.

• Fügen Sie einen neuen Benutzer in Okta hinzu, verschieben Sie den neuen Benutzer in das Quellkonto, und replizieren Sie den neuen Benutzer in das Zielkonto.

• Aktualisieren Sie die Failover-Gruppe.

• Stufen Sie die Sekundärverbindung im Zielkonto herauf, damit diese als Primärverbindung dient.

Schritte für Quellkonto:

1. Führen Sie SHOW CONNECTIONS aus, um zu überprüfen, ob die Verbindung im Quellkonto die Primärverbindung ist. Wenn es sich nicht um die Primärverbindung handelt, verwenden Sie den Befehl ALTER CONNECTION, um die Verbindung im Quellkonto zur Primärverbindung heraufzustufen.

2. Wenn im Quellkonto bereits eine Okta-SCIM-Sicherheitsintegration konfiguriert ist, fahren Sie mit dem nächsten Schritt fort.

   Andernfalls konfigurieren Sie eine Okta-SCIM-Sicherheitsintegration im Quellkonto.

   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

   Stellen Sie sicher, dass Sie die Okta-SCIM-Anwendung für Snowflake aktualisieren. Weitere Details dazu finden Sie unter Okta-Konfiguration.

3. Erstellen Sie in Okta einen neuen Benutzer in der Okta-Anwendung für Snowflake.

   Vergewissern Sie sich, dass der Benutzer zu Snowflake verschoben wurde, indem Sie in Snowflake den Befehl SHOW USERS ausführen.

4. Wenn in der Failover-Gruppe bereits security integrations angegeben ist, fahren Sie mit dem nächsten Schritt fort. Dies wäre der Fall, wenn Sie die Failover-Gruppe bereits für SAML-SSO im Zielkonto (unter diesem Thema) konfiguriert haben.

   Andernfalls ändern Sie die bestehende Failover-Gruppe mit einem ALTER FAILOVER GROUP-Befehl, um security integrations anzugeben.

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

   Copy

5. Zu diesem Zeitpunkt können Sie optional die sekundäre Failover-Gruppe aktualisieren, wie unter Schritte im Zielkonto für SCIM gezeigt wurde, um sicherzustellen, dass der neue Benutzer des Quellkontos auch im Zielkonto vorhanden ist.

   Wenn Sie die sekundäre Failover-Gruppe aktualisieren möchten, können Sie jetzt auf einfache Weise überprüfen, ob die Änderung des Quellkontos (Hinzufügen eines neuen Benutzers in dieser Sequenz) im Zielkonto sichtbar ist.

   Wenn Sie jedoch zusätzliche Aktivitäten bezüglich des Identitätsanbieters ausführen müssen oder möchten, wie z. B. das Ändern anderer Benutzer oder das Aktualisieren von Rollenzuweisungen, können Sie die jetzt tun und die sekundäre Failover-Gruppe später mit einer einzigen Operation aktualisieren.

Schritte im Zielkonto:

1. Überprüfen Sie vor der Replikation die Anzahl der Benutzer und Sicherheitsintegrationen, die im Zielkonto vorhanden sind, indem Sie die Befehle SHOW USERS bzw. SHOW INTEGRATIONS ausführen.

2. Aktualisieren Sie die sekundäre Failover-Gruppe, um das Zielkonto zu aktualisieren und den neuen Benutzer (sowie alle anderen Änderungen, die in Okta und im Quellkonto vorgenommen wurden) zu übernehmen.

   alter failover group fg refresh;
   

   Copy

3. Überprüfen Sie, ob der neue Benutzer dem Zielkonto hinzugefügt wurde, indem Sie einen SHOW USERS-Befehl ausführen.

4. Optional können Sie die sekundäre Failover-Gruppe und die Sekundärverbindung im Zielkonto zu primären Elementen heraufstufen. Dadurch wird das Zielkonto zum neuen Quellkonto heraufgestuft.

   Failover-Gruppe:

   alter failover group fg primary;
   

   Copy

   Verbindung:

   alter connection global primary;
   

   Copy

Replizieren von OAuth-Sicherheitsintegrationen¶

Die Replikation von OAuth-Sicherheitsintegrationen umfasst sowohl Snowflake OAuth-Sicherheitsintegrationen als auch External OAuth-Sicherheitsintegrationen.

Beachten Sie Folgendes:

Snowflake OAuth:

Nach der Replikation und der Konfiguration von Failover/Failback muss sich ein Benutzer, der über einen OAuth-Client eine Verbindung zum Quellkonto oder zum Zielkonto herstellt, nicht erneut beim Zielkonto authentifizieren.

External OAuth:

Nach der Replikation und der Konfiguration von Failover/Failback muss sich ein Benutzer, der über einen OAuth-Client eine Verbindung zum Quellkonto oder zum Zielkonto herstellt, möglicherweise erneut beim Zielkonto authentifizieren.

Eine erneute Authentifizierung ist wahrscheinlich erforderlich, wenn der OAuth-Autorisierungsserver nicht so konfiguriert ist, dass er ein Aktualisierungstoken ausstellt. Stellen Sie daher sicher, dass der OAuth-Autorisierungsserver Aktualisierungstoken ausgibt, sodass der OAuth-Client eine Verbindung zum Quell- und zum Zielkonto in Snowflake herstellen kann.

Gehen Sie bei diesem Verfahren von folgenden Annahmen aus:

• Quellkonto: https://example-northamericawest.snowflakecomputing.com/

• Zielkonto: https://example-northamericaeast.snowflakecomputing.com/

• Verbindungs-URL: https://example-global.snowflakecomputing.com

• Im Zielkonto ist eine Sekundärverbindung vorhanden (d. h. es sind nur Aktualisierungsoperationen erforderlich).

• Die Snowflake OAuth- oder External OAuth-Sicherheitsintegration ist im Quellkonto bereits vorhanden.

Das folgende Verfahren ist ein repräsentatives Beispiel, um Folgendes zu tun:

• Replizieren Sie eine OAuth-Sicherheitsintegration.

• Aktualisieren Sie die Failover-Gruppe.

• Stufen Sie die Sekundärverbindung im Zielkonto herauf, damit diese als Primärverbindung dient.

Schritte für Quellkonto:

1. Wenn in der Failover-Gruppe bereits security integrations angegeben ist, fahren Sie mit dem nächsten Schritt fort. Dies wäre der Fall, wenn Sie die Failover-Gruppe bereits für SAML-SSO im Zielkonto (unter diesem Thema) oder SCIM (ebenfalls unter diesem Thema) konfiguriert haben.

   Andernfalls ändern Sie die bestehende Failover-Gruppe mit einem ALTER FAILOVER GROUP-Befehl, um security integrations anzugeben.

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

   Copy

Schritte im Zielkonto:

1. Aktualisieren Sie die sekundäre Failover-Gruppe, um das Zielkonto zu aktualisieren und die OAuth-Sicherheitsintegrationsobjekte einzufügen.

   alter failover group fg refresh;
   

   Copy

2. Vergewissern Sie sich, dass die Verbindung zu jedem Snowflake-Konto mit dem OAuth-Client Ihrer Wahl hergestellt wurde.

3. Optional können Sie die sekundäre Failover-Gruppe und die Sekundärverbindung im Zielkonto zu primären Elementen heraufstufen. Dadurch wird das Zielkonto zum neuen Quellkonto heraufgestuft.

   Failover-Gruppe:

   alter failover group fg primary;
   

   Copy

   Verbindung:

   alter connection global primary;
   

   Copy

4. Wenn Sie den vorherigen Schritt abgeschlossen haben, stellen Sie sicher, dass Sie mit dem OAuth-Client Ihrer Wahl eine Verbindung zu jedem Snowflake-Konto herstellen können.

Replizieren von Netzwerkrichtlinien¶

Durch die Replikation einer Netzwerkrichtlinie vom Quellkonto in das Zielkonto können Administratoren den Zugriff auf das Zielkonto anhand der Netzwerk-ID des Ursprungs der eingehenden Anforderung einschränken.

Replizieren von Integrationen und Objekten für den Snowflake-Konnektor für ServiceNow¶

Der Snowflake-Konnektor für ServiceNow ermöglicht es Snowflake, Daten von ServiceNow zu erfassen. Für den Konnektor sind folgende Objekte in Ihrem Snowflake-Konto erforderlich:

• Geheimnis

• Sicherheitsintegration mit type = api_authentication

• API-Integration

• Datenbank zum Speichern der erfassten Daten

• Warehouse für den zu verwendenden Konnektor

• Kontorollen zum Verwalten des Zugriffs auf diese Objekte

Sie erstellen diese Objekte vor dem Installieren des Konnektors und können diese Objekte in das Zielkonto replizieren. Nachdem Sie diese Objekte repliziert haben, können Sie den Konnektor im Zielkonto installieren. Der Konnektor muss im Zielkonto installiert werden, da die Installation von einer Freigabe abhängt, die von Snowflake bereitgestellt wird. Während der Installation des Konnektors müssen Sie eine Datenbank aus der Freigabe erstellen, wobei Sie Datenbanken, die aus einer Freigabe erstellt wurden, nicht replizieren können.

Je nachdem, wie Sie die Replikation von Kontoobjekten verwalten möchten, können Sie über eine oder mehrere Replikations- oder Failover-Gruppen verfügen. Eine einzelne Replikationsgruppe zentralisiert die Replikationsverwaltung der Objekte und vermeidet Szenarios, in denen einige Objekte repliziert und andere Objekte nicht repliziert werden. Andernfalls müssen Sie die Replikationsoperation sorgfältig koordinieren, um sicherzustellen, dass alle Objekte in das Zielkonto repliziert werden.

Beispielsweise können Sie eine Replikationsgruppe für Datenbanken haben. Diese Replikationsgruppe (z. B. rg1) gibt die Datenbank an, die das Geheimnis enthält, und die Datenbank, die zum Speichern der ServiceNow-Daten dient. Die andere Replikationsgruppe (z. B. rg2) gibt den Benutzer, die Rolle und die Integrationsobjekte sowie die Zuweisungen dieser Rollen zu Benutzern an. Wenn Sie in diesem Szenario zuerst die Integrationen replizieren und sich dann entscheiden, das Zielkonto zu aktualisieren, um die Geheimnisdatenbank sowie die Benutzer und Rollen einzubeziehen, ist die Aktualisierungsoperation der Replikation erfolgreich.

Wenn Sie jedoch die Benutzer und Rollen sowie die Datenbank, die das Geheimnis enthält, in einer Gruppe replizieren, bevor Sie die Integration replizieren, wird so lange ein Platzhaltergeheimnis verwendet, bis die Sicherheitsintegration repliziert ist. Das Platzhaltergeheimnis verhindert verwaiste Referenzen. Sobald die Sicherheitsintegration repliziert ist, wird das Platzhaltergeheimnis durch das tatsächliche Geheimnis ersetzt.

Das folgende Verfahren ist ein repräsentatives Beispiel, um Folgendes zu tun:

• Replizieren Sie die Integrationen und die Datenbanken, die das Geheimnis und die erfassten Daten enthalten.

• Aktualisieren Sie die Failover-Gruppe.

• Stufen Sie die Sekundärverbindung im Quellkonto zur Primärverbindung herauf.

• Installieren und verwenden Sie den Konnektor nach der Replikation.

Gehen Sie bei diesem Verfahren von folgenden Annahmen aus:

• Quellkonto: https://example-northamericawest.snowflakecomputing.com/

• Zielkonto: https://example-northamericaeast.snowflakecomputing.com/

• Verbindungs-URL: https://example-global.snowflakecomputing.com

• Im Zielkonto ist eine Sekundärverbindung vorhanden (d. h. es sind nur Aktualisierungsoperationen erforderlich).

• Weitere Sicherheitsintegrationen zur Authentifizierung und Netzwerkrichtlinien zur Zugriffsbeschränkung sind bereits repliziert.

Schritte für Quellkonto:

1. Überprüfen Sie, ob die Objekte für den Konnektor im Snowflake-Quellkonto vorhanden sind, indem Sie SHOW-Befehle für jeden dieser Objekttypen ausführen.

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

   Copy

   Beachten Sie, dass secretsdb der Name der Datenbank ist, die das Geheimnis enthält, und destdb der Name der Datenbank ist, die die erfassten Daten von ServiceNow enthält.

2. Aktualisieren Sie die Failover-Gruppe mit einem ALTER FAILOVER GROUP-Befehl, um die API-Integrationen und die Datenbanken hinzuzufügen, die das Geheimnis und die erfassten Daten enthalten.

   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

Schritte im Zielkonto:

1. Aktualisieren Sie die sekundäre Failover-Gruppe, um die Integrationen und Datenbanken in das Zielkonto zu replizieren.

   alter failover group fg refresh;
   

   Copy

2. Überprüfen Sie mit den folgenden SHOW-Befehlen, ob die replizierten Objekte vorhanden sind.

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

   Copy

3. Vergewissern Sie sich, dass die Verbindung zu jedem Snowflake-Konto mit der Methode Ihrer Wahl (z. B. Browser, SnowSQL) hergestellt wurde.

4. Optional können Sie die sekundäre Failover-Gruppe und die Sekundärverbindung im Zielkonto zu einer Primärverbindung heraufstufen. Dadurch wird das Zielkonto zum neuen Quellkonto heraufgestuft.

   Failover-Gruppe:

   alter failover group fg primary;
   

   Copy

   Verbindung:

   alter connection global primary;
   

   Copy

5. Wenn Sie den vorherigen Schritt abgeschlossen haben, prüfen Sie erneut, ob Sie eine Verbindung zu jedem Snowflake-Konto herstellen können.

   An diesem Punkt enthält das Zielkonto die replizierten Objekte und Benutzer können sich anmelden. Es gibt jedoch weitere Schritte im Zielkonto erforderlich, um den Konnektor verwenden zu können.

6. Aktualisieren Sie auf der Cloudplattform, die Ihr Snowflake-Konto hostet, den mit der API-Integration verknüpften Remotedienst.

   Weitere Informationen dazu finden Sie unter Aktualisieren des Remotedienstes für API-Integrationen.

7. Installieren Sie den Konnektor manuell oder mit Snowsight. Weitere Informationen dazu finden Sie unter:

   • Konnektor manuell installieren

   • Konnektor mit Snowsight installieren

8. Auf ServiceNow-Daten in Snowflake zugreifen