Private Azure-Endpunkte für interne Stagingbereiche¶

Übersicht¶

Private Azure-Endpunkte und Azure Private Link können kombiniert werden, um eine sichere Konnektivität zu Snowflake-internen Stagingbereichen bereitzustellen. Diese Einrichtung stellt sicher, dass die Operationen zum Laden von Daten in interne Snowflake-Stagingbereiche und das Entladen von Daten aus internen Snowflake-Stagingbereichen das interne Azure-Netzwerk verwenden und nicht über das öffentliche Internet erfolgen.

Bevor Microsoft private Endpunkte für den Zugriff auf den internen Stagingbereiche unterstützt hat, war es notwendig, eine Proxy-Farm innerhalb von Azure VNet zu erstellen, um den sicheren Zugriff auf interne Snowflake-Stagingbereich zu ermöglichen. Mit der zusätzlichen Unterstützung von privaten Endpunkten für interne Snowflake-Stagingbereiche können Benutzer und Clientanwendungen jetzt über das private Azure-Netzwerk auf interne Snowflake-Stagingbereiche zugreifen. Die folgende Abbildung fasst diese neue Funktion zusammen:

Beachten Sie Folgendes in Bezug auf die Zahlen in der Abbildung für BEFORE:

• Benutzer haben zwei Optionen, um eine Verbindung zu einem internen Snowflake-Stagingbereich herzustellen:

  • Option A ermöglicht eine direkte lokale (On-premises) Verbindung mit dem internen Stagingbereich, was mit Nummer 1 gekennzeichnet ist.

  • Option B ermöglicht eine Verbindung zum internen Stagingbereich über eine Proxy-Farm, was mit den Nummern 2 und 3 gekennzeichnet ist.

• Wenn Sie die Proxy-Farm verwenden, können Benutzer auch direkt eine Verbindung zu Snowflake herstellen, was mit Nummer 4 gekennzeichnet ist.

Beachten Sie Folgendes in Bezug auf die Zahlen in der Abbildung für AFTER:

• Zur Verdeutlichung zeigt die Abbildung einen einzelnen privaten Endpunkt von einem Azure VNet, der auf einen einzelnen internen Snowflake-Stagingbereich (6 und 7) zeigt.

  Beachten Sie, dass es möglich ist, mehrere private Endpunkte zu konfigurieren, die jeweils innerhalb eines anderen VNet auf denselben internen Snowflake-Stagingbereich verweisen.

• Durch die Aktualisierungen an diesem Feature ist es nicht mehr erforderlich, für die Verbindung zu Snowflake oder zu einem internen Snowflake-Stagingbereich eine Proxy-Farm zu verwenden.

• Ein lokaler Benutzer kann eine direkte Verbindung zu Snowflake herstellen, was mit Nummer 5 gekennzeichnet ist.

• Um eine Verbindung zu einem internen Snowflake-Stagingbereich herzustellen, verbindet sich der lokale Benutzer mit einem privaten Endpunkt, Nummer 6, und verwendet dann Azure Private Link, um sich mit dem internen Snowflake-Stagingbereich zu verbinden, wie durch Nummer 7 gekennzeichnet.

In Azure hat jedes Snowflake-Konto ein dediziertes Speicherkonto, das als interner Stagingbereich verwendet wird. Die URIs der Speicherkonten sind unterschiedlich, je nachdem, ob die Verbindung zum Speicherkonto private Konnektivität (d. h. Azure Private Link) verwendet. Die URL für die private Konnektivität enthält ein privatelink-Segment.

URI für öffentliches Speicherkonto

<Name_des_Speicherkontos>.blob.core.windows.net

URI für Speicherkonto mit privater Konnektivität

<Name_des_Speicherkontos>.privatelink.blob.core.windows.net

Vorteile¶

Die Implementierung von privaten Endpunkten für den Zugriff auf interne Snowflake-Stagingbereiche bietet die folgenden Vorteile:

• Daten in internen Stagingbereichen werden nicht über das öffentliche Internet übertragen.

• Client- und SaaS-Anwendungen, wie Microsoft PowerBI, die außerhalb von Azure VNet ausgeführt werden, können sich sicher mit Snowflake verbinden.

• Administratoren müssen keine Änderung an den Firewall-Einstellungen vornehmen, um auf die Daten in den internen Stagingbereichen zugreifen zu können.

• Administratoren können konsistente Sicherheit und Überwachung hinsichtlich der Art und Weise implementieren, wie sich Benutzer mit Speicherkonten verbinden.

Einschränkungen¶

Microsoft Azure definiert, wie ein privater Endpunkt mit Snowflake interagieren kann:

• Ein einzelner privater Endpunkt kann mit einem einzelnen Snowflake-Dienstendpunkt kommunizieren. Sie können mehrere 1:1-Konfigurationen haben, die mit demselben internen Snowflake-Stagingbereich verbunden sind.

• Die maximale Anzahl der privaten Endpunkte in Ihrem Speicherkonto, die eine Verbindung zu einem internen Snowflake-Stagingbereich herstellen können, ist fest definiert. Weitere Informationen dazu finden Sie unter Begrenzungen beim Standard-Speicherkonto.

Konfigurieren von privaten Endpunkten für den Zugriff auf interne Snowflake-Stagingbereiche¶

Um private Endpunkte für den Zugriff auf interne Snowflake-Stagingbereiche zu konfigurieren, ist die Unterstützung der folgenden drei Rollen in Ihrer Organisation erforderlich:

1. Snowflake-Kontoadministrator (d. h. ein Benutzer mit der Snowflake-Systemrolle ACCOUNTADMIN)

2. Microsoft Azure-Administrator

3. Netzwerkadministrator

Abhängig von der Organisation kann es notwendig sein, den Konfigurationsaufwand mit mehr als einer Person oder einem Team zu koordinieren, um die folgenden Konfigurationsschritte zu implementieren.

Führen Sie die folgenden Schritte aus, um den sicheren Zugriff auf interne Snowflake-Stagingbereiche über private Azure-Endpunkte zu konfigurieren und zu implementieren:

1. Überprüfen Sie, ob Ihr Azure-Abonnement beim Azure Storage-Ressourcenmanager registriert ist. Mit diesem Schritt können Sie von einem privaten Endpunkt aus eine Verbindung zum internen Stagingbereich herstellen.

2. Führen Sie als Snowflake-Kontoadministrator die folgenden Anweisungen in Ihrem Snowflake-Konto aus, und notieren Sie sich die ResourceID des Speicherkontos im internen Stagingbereich, die durch den Schlüssel privatelink_internal_stage definiert ist. Weitere Informationen dazu finden Sie unter ENABLE_INTERNAL_STAGES_PRIVATELINK und SYSTEM$GET_PRIVATELINK_CONFIG.

   use role accountadmin;
   alter account set ENABLE_INTERNAL_STAGES_PRIVATELINK = true;
   select key, value from table(flatten(input=>parse_json(system$get_privatelink_config())));
   

   Copy

3. Erstellen Sie als Azure-Administrator einen privaten Endpunkt über das Azure-Portal.

   Zeigen Sie die Eigenschaften des privaten Endpunkts an, und notieren Sie sich den ID-Wert der Ressource. Dieser Wert wird im nächsten Schritt der Wert für privateEndpointResourceID sein.

   Überprüfen Sie, ob der Wert Target sub-resource auf blob gesetzt ist.

   Weitere Informationen dazu finden Sie in der Dokumentation zu Microsoft Azure Private Link.

4. Rufen Sie als Snowflake-Administrator die Funktion SYSTEM$AUTHORIZE_STAGE_PRIVATELINK_ACCESS auf, und verwenden Sie dabei den privateEndpointResourceID-Wert als Funktionsargument. Durch diesen Schritt wird der Zugriff auf den internen Snowflake-Stagingbereich über den privaten Endpunkt autorisiert.

   use role accountadmin;
   select system$authorize_stage_privatelink_access('<privateEndpointResourceID>');
   

   Copy

   Führen Sie bei Bedarf diese Schritte aus, um den Zugriff auf den internen Stagingbereich wieder zu entziehen.

5. Ändern Sie als Netzwerkadministrator die DNS-Einstellungen wie folgt, um die URLs aufzulösen:

   <Name_des_Speicherkontos>.blob.core.windows.net in <Name_des_Speicherkontos>.privatelink.blob.core.windows.net

   Wenn Sie eine private DNS-Zone in einem Azure VNet verwenden, erstellen Sie den Alias-Eintrag für <Name_des_Speicherkontos>.privatelink.blob.core.windows.net.

   Weitere Informationen dazu finden Sie unter DNS-Konfiguration für private Azure-Endpunkte.

   Tipp

   • Verwenden Sie zum Testen des Features ein separates Snowflake-Konto, und konfigurieren Sie eine private DNS-Zone in einer Test-VNet, damit die Tests isoliert sind und sich nicht auf Ihre anderen Workloads auswirken.

   • Wenn die Verwendung eines separaten Snowflake-Kontos nicht möglich ist, verwenden Sie einen Testbenutzer für den Zugriff auf Snowflake von einer Test-VPC aus, in der die DNS-Änderungen vorgenommen werden.

   • Um von lokalen Anwendungen aus zu testen, verwenden Sie die DNS-Weiterleitung, um Anforderung an das private Azure-DNS in VNet weiterzuleiten, in dem die DNS-Einstellungen vorgenommen werden. Führen Sie den folgenden Befehl auf dem Clientcomputer aus, um zu überprüfen, ob die zurückgegebene IP-Adresse die private IP-Adresse des Speicherkontos ist:

     dig <storage_account_name>.blob.core.windows.net
     

     Copy

Blockieren des öffentlichen Zugriffs (optional)¶

Sobald Sie private Endpunkte für den Zugriff auf den internen Stagingbereich über Azure Private Link konfiguriert haben, können Sie optional Anforderungen von öffentlichen IP-Adressen an den internen Stagingbereich blockieren. Sobald der öffentliche Zugriff blockiert ist, muss der gesamte Datenverkehr über den privaten Endpunkt verlaufen.

Die Steuerung des öffentlichen Zugriffs auf einen internen Azure-Stagingbereich unterscheidet sich von der Steuerung des öffentlichen Zugriffs auf den Snowflake-Dienst. Sie verwenden die Funktion SYSTEM$BLOCK_INTERNAL_STAGES_PUBLIC_ACCESS anstelle einer Netzwerkrichtlinie, um Anforderungen an den internen Stagingbereich zu blockieren. Im Gegensatz zu Netzwerkrichtlinien kann diese Funktion nicht einige IP-Adressen blockieren und andere zulassen. Wenn Sie SYSTEM$BLOCK_INTERNAL_STAGES_PUBLIC_ACCESS aufrufen, werden alle öffentlichen IP-Adressen blockiert.

Die Funktion SYSTEM$BLOCK_INTERNAL_STAGES_PUBLIC_ACCESS erzwingt ihre Einschränkungen, indem sie die Einstellungen Networking des Azure-Speicherkontos ändert, in dem sich der interne Stagingbereich befindet. Diese Azure-Einstellungen werden allgemein als „Firewall-Einstellungen von Speicherkonten“ bezeichnet. Das Ausführen der Snowflake-Funktion bewirkt Folgendes in Azure:

• Setzt das Feld Public network access auf Enabled from selected virtual networks and IP addresses.

• Fügt Snowflake-VNet-Subnetz-IDs zum Abschnitt Virtual Networks hinzu.

• Löscht alle IP-Adressen aus dem Bereich Firewall.

Um den gesamten Datenverkehr von öffentlichen IP-Adressen zum internen Stagingbereich zu blockieren, führen Sie Folgendes aus:

SELECT SYSTEM$BLOCK_INTERNAL_STAGES_PUBLIC_ACCESS();

Es kann einige Minuten dauern, bis diese Funktion ausgeführt wurde.

Entziehen des Zugriffs auf interne Snowflake-Stagingbereiche über private Endpunkte¶

Führen Sie die folgenden Schritte aus, um den Zugriff auf interne Snowflake-Stagingbereiche über private Microsoft Azure-Endpunkte zu entziehen:

1. Setzen Sie als Snowflake-Administrator den Parameter ENABLE_INTERNAL_STAGES_PRIVATELINK auf FALSE, und rufen Sie die Funktion SYSTEM$REVOKE_STAGE_PRIVATELINK_ACCESS auf, um den Zugriff über den privaten Endpunkt zu entziehen, wobei Sie denselben privateEndpointResourceID-Wert verwenden, mit dem Sie ursprünglich den Zugriff über den privaten Endpunkt autorisiert haben.

   use role accountadmin;
   alter account set enable_internal_stages_privatelink = false;
   select system$revoke_stage_privatelink_access('<privateEndpointResourceID>');
   

   Copy

2. Als Azure-Administrator löschen Sie den privaten Endpunkt über das Azure-Portal.

3. Entfernen Sie als Netzwerkadministrator die DNS- und Alias-Datensätze, die zum Auflösen der Speicherkonto-URLs verwendet wurden.

An diesem Punkt ist der Zugriff über den privaten Endpunkt nun entzogen, und das Abfrageergebnis bei Aufruf der Funktion SYSTEM$GET_PRIVATELINK_CONFIG sollte nicht mehr den Schlüssel privatelink_internal_stage und seinen Wert zurückgeben.

Problembehandlung¶

Azure-Anwendungen, die über das öffentliche Internet auf Snowflake-Stagingbereiche zugreifen und außerdem einen privaten DNS-Dienst zur Auflösung von Dienst-Hostnamen verwenden, können nicht auf Snowflake-Stagingbereiche zugreifen, wenn eine private Endpunktverbindung zu dem Stagingbereich hergestellt wird, wie unter diesem Thema beschrieben.

Sobald eine private Endpunktverbindung erstellt ist, erstellt Microsoft Azure automatisch einen CNAME-Datensatz im öffentlichen DNS-Dienst, der den Speicherkonto-Host auf sein Azure Private Link-Gegenstück (d. h. .privatelink.blob.core.windows.net) verweist. Wenn eine Anwendung eine private DNS-Region für dieselbe Domäne konfiguriert hat, versucht Microsoft Azure, den Speicherkonto-Host durch Abfragen des privaten DNS-Dienstes aufzulösen. Wenn der Eintrag für das Speicherkonto nicht im privaten DNS-Dienst gefunden wird, tritt ein Verbindungsfehler auf.

Es gibt zwei Möglichkeiten, dieses Problem zu lösen:

1. Entfernen oder trennen Sie den privaten DNS-Bereich von der Anwendung.

2. Erstellen Sie einen CNAME-Datensatz für den privaten Hostnamen des Speicherkontos (d. h. <Speicherkontoname>.privatelink.blob.core.windows.net) im privaten DNS-Dienst, und verweisen Sie ihn auf den Hostnamen, der durch die Ausgabe dieses Befehls angegeben wird:

   dig CNAME <storage_account_name>.privatelink.blob.core.windows.net
   

   Copy