Servicenetzwerke¶

Timeout der eingehenden Verbindung¶

Eingangsendpunkte haben ein Timeout von 90 Sekunden. Wenn 90 Sekunden lang keine Aktivität bei einer Verbindung zu einem Endpunkt stattfindet, bricht Snowflake die Verbindung ab. Wenn Ihre Anwendung eine längere Konnektivität benötigt, verwenden Sie Polling oder WebSockets.

Eingangs-Webbrowser Authentifizierung Abmeldung¶

Wenn Sie eine Webanwendung erstellen, die als Dienst ausgeführt wird, haben Sie die Möglichkeit, Benutzern die Abmeldung von Ihrer Anwendung zu ermöglichen, indem Sie sie an /sfc-endpoint/logout weiterleiten.

Nach der Abmeldung muss sich der Benutzer erneut bei Snowflake authentifizieren, um auf den öffentlichen Endpunkt des Dienstes zuzugreifen.

Sicherheit von Eingangsdatenverkehr und Webanwendungen¶

Sie können einen Snowpark Container Services-Dienst für das Webhosting erstellen, indem Sie die Unterstützung für öffentliche Endpunkte (Netzwerkeingang) nutzen. Für zusätzliche Sicherheit setzt Snowflake einen Proxydienst ein, um eingehende Anforderungen von Clients an Ihren Dienst und ausgehende Antworten von Ihrem Dienst an die Clients zu überwachen. In diesem Abschnitt wird erklärt, was der Proxy tut und wie er sich auf einen Dienst auswirkt, der in Snowpark Container Services bereitgestellt wird.

Beispiel:

• Der Proxy leitet eine eingehende HTTP-Anforderung nicht weiter, wenn die Anforderung eine nicht zulässige HTTP-Methode verwendet.

• Der Proxy sendet eine 403-Antwort an den Client, wenn der Content-Type-Header in der Antwort angibt, dass die Antwort eine ausführbare Datei enthält.

Darüber hinaus kann der Proxy auch neue Kopfzeilen einfügen und bestehende Kopfzeilen in der Anforderung und der Antwort ändern, wobei Ihr Container und Ihre Datensicherheit berücksichtigt werden.

Beispielsweise könnte Ihr Dienst nach Erhalt einer Anforderung in der Antwort HTML-, JavaScript-, CSS- und andere Inhalte für eine Webseite an den Client-Browser senden. Die Webseite im Browser ist Teil Ihres Dienstes und dient als Benutzerschnittstelle. Wenn Ihr Dienst aus Sicherheitsgründen Einschränkungen unterliegt (z. B. bezüglich des Herstellens von Netzwerkverbindungen zu anderen Standorten), möchten Sie vielleicht auch, dass die Webseite Ihres Dienstes denselben Einschränkungen unterliegt.

Standardmäßig haben Dienste nur begeschränkte Berechtigungen für den Zugriff auf das Internet. Der Browser sollte auch verhindern, dass die Clientanwendung auf das Internet zugreift und möglicherweise in den meisten Fällen Daten freigibt. Wenn Sie eine Integration des externen Zugriffs (EAI) eingerichtet haben, um Ihrem Dienst den Zugriff auf example.com zu ermöglichen (siehe Konfigurieren des Netzwerkausgangs), sollte die Webseite für Ihren Dienst auch über Ihren Browser auf example.com zugreifen können.

Der Snowflake-Proxy wendet dieselben Netzwerkbeschränkungen auf den Dienst und die Webseite an, indem er einen CSP-Header (Content-Security-Policy) in die Antwort einfügt. Standardmäßig fügt der Proxy eine Baseline-CSP in die Antwort ein, um Schutz vor allgemeinen Sicherheitsbedrohungen zu bieten. Bei der Browser-Sicherheit geht es darum, ein Gleichgewicht zwischen Funktionalität und Sicherheit zu finden. Es liegt in der gemeinsamen Verantwortung sicherzustellen, dass diese Basis für Ihren Anwendungsfall geeignet ist. Wenn Ihr Dienst so konfiguriert ist, dass eine EAI verwendet wird, wendet der Proxy außerdem dieselben Netzwerkregeln von der EAI auf die CSP der Webseite an. Diese CSP ermöglicht der Webseite im Browser auf dieselben Standorte zuzugreifen, auf die auch der Dienst zugreifen kann.

Snowflake bietet CORS-Unterstützung, die Sie in der Dienstspezifikation konfigurieren.

Der Snowflake-Proxy gibt die in der Dienstspezifikation definierten CORS-Einstellungen zurück. Beachten Sie, dass der Proxy alle vom Dienst zurückgegebenen CORS-Header entfernt.

Die folgenden CORS-Header sind standardmäßig eingestellt:

• Access-Control-Expose-Headers-Header meldet immer die folgenden Header-Namen, zusätzlich zu den in der Dienstspezifikation für den Endpunkt konfigurierten Headern.

  • X-Frame-Options

  • Cross-Origin-Opener-Policy

  • Cross-Origin-Resource-Policy

  • X-Content-Type-Options

  • Cross-Origin-Embedder-Policy

  • Content-Security-Policy-Report-Only

  • Content-Security-Policy

• Access-Control-Max-Age ist auf zwei Stunden eingestellt.

• Access-Control-Allow-Credentials auf „true“ gesetzt ist.

Außerdem setzt Snowflake den Header Vary mit dem Wert Origin, um dem Browser anzuzeigen, dass der Wert für Access-Control-Allow-Origin je nach dem Wert von Origin unterschiedlich sein kann.

Der Header Authorization ist erforderlich, um die CORS-Anforderung zu erstellen. Sie können ein programmgesteuertes Zugriffstoken angeben (PAT) – in diesem Header (Authorization: "Snowflake Token=\"${patToken}\""). Informationen zum Generieren eines programmgesteuerten Zugriffstokens finden Sie unter Verwenden von programmatische Zugriffstoken für die Authentifizierung.

In den folgenden Abschnitten wird erläutert, wie der Snowflake-Proxy eingehende Anforderungen für Ihren Dienst verarbeitet und die ausgehenden Antworten Ihres Dienstes an die Clients modifiziert.

Überlegungen zum Zugriff und CORS¶

Standardmäßig verhindern Browser, dass Webanwendungen, die auf einem Server gehostet werden, Anfragen an einen anderen Server mit einem anderen Hostnamen senden. Wenn Sie beispielsweise eine Webanwendung außerhalb von Snowpark Container Services hosten, die mit einem in Snowpark Container Services bereitgestellten Backend-Dienst interagieren muss, gilt diese Einschränkung.

CORS (Cross-Origin Resource Sharing) ermöglicht es einem Snowpark Container Services-Dienst, den Browsern mitzuteilen, dass er Anfragen von Webanwendungen zulässt, die außerhalb seiner Umgebung gehostet werden. Sie können jeden öffentlichen Endpunkt konfigurieren, um festzulegen, wie er sowohl auf CORS Preflight-Anfragen als auch auf Standard-Anfragen reagiert.

Snowflake-Proxy setzt die folgenden Antwort-Header immer außer Kraft:

• Access-Control-Allow-Origin

• Access-Control-Allow-Methods

• Access-Control-Allow-Headers

• Access-Control-Expose-Headers

• Access-Control-Max-Age

• Access-Control-Allow-Credentials

Der Snowflake-Proxy nimmt keinen dieser CORS-Header in die Antwort auf, wenn einer der folgenden Punkte zutrifft:

• CORS ist nicht für den Dienstendpunkt konfiguriert. Das heißt, es gibt kein corsSettings in der Dienstspezifikation

• CORS ist für den Dienstendpunkt konfiguriert, aber der Origin-Header in der Anfrage stimmt nicht mit dem angegebenen Feld Access-Control-Allow-Origin in der Dienstspezifikation überein

In der Dienstspezifikation können Sie CORS-Einstellungen für jeden öffentlichen Endpunkt konfigurieren. Wenn der origin-Header in der Anfrage mit dem Feld Access-Control-Allow-Origin übereinstimmt, das in der Spezifikation für den Endpunkt angegeben ist, fügt der Proxy in die Antwort die in der Spezifikation definierten CORS-Header mit den folgenden Anpassungen ein:

• Access-Control-Allow-Origin: Gibt den Origin-Header der Anfrage zurück.

• Access-Control-Expose-Headers: Fügt die Liste der erlaubten Header, die Sie konfiguriert haben, mit diesen immer sichtbaren Headern zusammen: X-Frame-Options, Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy, X-Content-Type-Options, Cross-Origin-Embedder-Policy, Content-Security-Policy-Report-Only, Content-Security-Policy.

• Access-Control-Max-Age: Ist auf zwei Stunden eingestellt.

• Access-Control-Allow-Credentials: Ist auf „true“ gesetzt.

Überlegungen zum Zugriff und SSO¶

Wenn Sie vom Internet aus auf den öffentlichen Endpunkt zugreifen, kann es sein, dass die Authentifizierung mit Benutzername und Kennwort funktioniert, aber SSO zu einer leeren Seite oder dem Fehler führt: „OAuth Clientintegration mit der angegebenen Client-ID wurde nicht gefunden.“

Dies passiert, wenn Sie die alte Methode der föderierten Authentifizierung (SSO) mit Snowflake anstelle der neueren Version der Sicherheitsintegration verwenden, wie unter Konfigurieren von Snowflake für die Verwendung der Verbundauthentifizierung beschrieben. Gehen Sie wie folgt vor, um dies zu überprüfen:

1. Führen Sie die folgende Abfrage aus:

   SHOW PARAMETERS LIKE 'SAML_IDENTITY_PROVIDER' IN ACCOUNT;
   

   Copy

   Wenn Sie diesen Parameter gesetzt haben, haben Sie zu irgendeinem Zeitpunkt die alte föderierte Authentifizierung verwendet.

2. Wenn der obige Parameter gesetzt wurde, führen Sie die folgende Abfrage aus, um festzustellen, ob Sie über eine SAML-Sicherheitsintegration verfügen:

   SHOW INTEGRATIONS
     ->> SELECT * FROM $1 WHERE "type" = 'SAML2';
   

   Copy

   Wenn Sie keine Integrationen des Typs SAML2 haben, dann verwenden Sie die alte Methode der föderierten Authentifizierung.

In diesem Fall besteht die Lösung darin, von der alten Methode der föderierten Authentifizierung auf die neue, integrative Methode der föderierten Authentifizierung umzusteigen. Weitere Informationen dazu finden Sie unter Migration zu einer SAML2-Sicherheitsintegration.

Netzwerkausgang über private Konnektivität¶

Anstatt den Netzwerkausgag über das öffentliche Internet zu routen, können Sie sich dafür entscheiden, den Ausgangverkehr Ihres Dienstes über einen privaten Konnektivitätsendpunkt zu leiten.

Zunächst müssen Sie den privaten Konnektivitätsendpunkt in Ihrem Snowflake-Konto erstellen. Konfigurieren Sie dann eine Netzwerkregel, um den ausgehenden Datenverkehr über die private Konnektivität zuzulassen. Der Prozess zur Einrichtung einer External Access Integration (EAI) bleibt derselbe wie im vorangegangenen Abschnitt beschrieben.

Wenn Sie zum Beispiel den ausgehenden Internetzugang Ihres Dienstes zu einem Amazon S3-Bucket über private Konnektivität aktivieren möchten, gehen Sie wie folgt vor:

1. Aktivieren Sie die private Link-Konnektivität für den selbstverwalteten Endpunktdienst (Amazon S3). Eine Schritt-für-Schritt-Anleitung finden Sie unter AWS Private Link for Amazon S3.

2. Rufen Sie die Systemfunktion SYSTEM$PROVISION_PRIVATELINK_ENDPOINT auf, um einen privaten Konnektivitätsendpunkt in Ihrem Snowflake-VNet bereitzustellen. Dadurch kann Snowflake über private Konnektivität eine Verbindung zum externen Dienst (in diesem Beispiel Amazon S3) herstellen.

   USE ROLE ACCOUNTADMIN;
   
   SELECT SYSTEM$PROVISION_PRIVATELINK_ENDPOINT(
     'com.amazonaws.us-west-2.s3',
     '*.s3.us-west-2.amazonaws.com'
   );
   

   Copy

3. Genehmigen Sie den Endpunkt im Konto des Cloudanbieters. In diesem Beispiel für Amazon AWS, siehe Verbindungsanfragen annehmen oder ablehnen in der AWS-Dokumentation. Um den Endpunkt in Azure zu genehmigen, lesen Sie auch die Azure-Dokumentation.

4. Verwenden Sie den Befehl CREATE NETWORK RULE, um eine Netzwerkegel für den ausgehenden Datenverkehr zu erstellen, in der Sie die externen Ziele angeben, für die Sie den Zugriff erlauben möchten.

   CREATE OR REPLACE NETWORK RULE private_link_network_rule
     MODE = EGRESS
     TYPE = PRIVATE_HOST_PORT
     VALUE_LIST = ('<bucket-name>.s3.us-west-2.amazonaws.com');
   

   Copy

   Der Parameters TYPE ist auf PRIVATE_HOST_PORT eingestellt. Er zeigt an, dass die Netzwerkregel den ausgehenden Datenverkehr über die private Konnektivität zulässt.

5. Die übrigen Schritte zur Erstellung eines EAI und dessen Verwendung zur Erstellung eines Dienstes sind die gleichen wie im vorangegangenen Abschnitt (siehe Konfigurieren des Netzwerkausgangs) erklärt.

Weitere Informationen zur Arbeit mit privaten Konnektivitätsendpunkten finden Sie unter:

• Verwalten Sie private Konnektivitätsendpunkte: AWS

• Private Konnektivitätsendpunkte verwalten: Azure

• Verwalten Sie private Konnektivitätsendpunkte: Google Cloud