Data Connectivity Proxy: Bringen Sie Snowflake Openflow zu privaten Daten

Unternehmensdaten erstrecken sich über Multi-Clouds, Apps und Plattformen, was zu kritischen blinden Flecken für Perimeter-Firewalls führt. Die Sicherung der Netzwerkgrenze reicht nicht mehr aus. Governance und Kontrolle müssen genau dort verankert werden, wo sich die Daten befinden. Ein typisches großes Unternehmen betreibt möglicherweise Oracle-Datenbanken für die Kernfinanzen On-Premises, streamt Echtzeit-Ereignisse über Kafka-Broker innerhalb einer privaten VPC und betreibt Datenbanken, die über mehrere Public Clouds verstreut sind. Das Erreichen dieser privaten Quellen in einer hybriden Umgebung war bisher entweder unmöglich oder erforderte für jede Topologie eine andere Netzwerklösung. Dieses Flickwerk aus VPNs, PrivateLinks und isolierten Agenten wird mit der Zeit zu einem eigenen Infrastrukturproblem.

Heute stellen wir Data Connectivity Proxy (DCP) für Snowflake Openflow vor, um das Problem des Zugriffs auf private Daten zu lösen. Snowflake Openflow ist unser vollständig verwalteter Datenintegrationsdienst, der Daten verbindet, ohne eine benutzerdefinierte ETL-Infrastruktur aufzubauen, und DCP bietet ihm Zugriff auf private Quellen, die zuvor unerreichbar waren. Dies geschieht durch ein konsistentes, von Snowflake bereitgestelltes Agentenmodell, das den Bedarf an topologiebezogenen VPNs, PrivateLinks und Drittanbieter-Agenten reduziert.

Die Übertragung privater Daten in eine verwaltete Pipeline erzwang in der Vergangenheit eine Entscheidung. Teams übernehmen entweder die Betriebskosten einer benutzerdefinierten ETL-Infrastruktur an jeder Netzwerkgrenze oder starten monatelange Projekte, um Genehmigungen zum Öffnen von Inbound-Ports in Umgebungen zu erhalten, in denen dies normalerweise nicht zulässig ist.

Für Unternehmen in den Bereichen Finanzdienstleistungen, Gesundheitswesen und Fertigung ist eine Deny-All-Inbound-Richtlinie oft eine regulatorische Anforderung. Wenn ein Anbieter einer verwalteten Pipeline sagt: „Richten Sie eine private Netzwerkverbindung ein“, erfordert dies in Wirklichkeit die Einbeziehung des Network Engineerings, das Öffnen von Firewall-Regeln und die Freigabe durch ein Change Advisory Board. DCP wurde für Deny-All-Inbound-Netzwerke entwickelt: Der Agent führt nur ausgehendes TLS über Port 443 aus. Eine damit verbundene Einschränkung: Der Agent-Host benötigt direkten ausgehenden Zugriff auf Snowflake über diesen Port. Das Routing des eigenen ausgehenden Datenverkehrs des Agenten über einen vom Unternehmen verwalteten Forward-Proxy (HTTPS_PROXY oder CONNECT-basierte Weiterleitung) wird derzeit nicht unterstützt. 

Dennoch ist die Einrichtung all dessen ein mehrwöchiges Projekt, bevor überhaupt Daten verschoben werden, und bestehende Optionen lösen nur Teile des Problems: 

• CSP-native private Konnektivität (AWS PrivateLink, Azure Private Endpoint und Google Private Service Connect) ist die richtige Wahl, wenn Sie private In-Cloud-Pfade in derselben Cloud benötigen. Sie ist nicht auf On-Premises-Quellen ausgerichtet. DCP deckt diese Fälle mit einem Outbound-Agenten in Ihrem Netzwerk ab.
• VPN, ExpressRoute und VPC-Peering funktionieren, aber jedes ist ein mehrwöchiges Network-Engineering-Projekt, das die Koordination des Infrastrukturteams, Genehmigungen und laufende Wartung erfordert.
• Legacy-Pipeline-Tools lassen dies weitgehend ungelöst. Einige verfügen überhaupt nicht über einen First-Party-Agenten, sodass Kunden selbst ein VPN und dedizierte Netzwerkverbindungen einrichten müssen, bevor die Pipeline etwas tun kann.
• Konnektivitätsagenten von Drittanbietern lösen das technische Problem, fügen jedoch einen weiteren Anbieter, einen weiteren Vertrag und ein weiteres System hinzu, das betrieben und unterstützt werden muss.

DCP entfernt diese Netzwerkabhängigkeiten aus dem Datenintegrationspfad, indem es als leichtgewichtiger Agent bereitgestellt wird, der in der Umgebung ausgeführt wird, in der sich Ihre Daten bereits befinden: einem On-Premises-Rechenzentrum, einer privaten Cloud-Umgebung, einer VPC oder einer anderen Cloud.

Der Agent erstellt eine ausgehende Verbindung über Port 443 zu Snowflake und richtet einen verschlüsselten Tunnel ein. Snowflake leitet dann den Openflow-Datenverkehr durch diesen Tunnel, um die private Quelle zu erreichen.

Das Design kehrt das übliche Modell um. Anstatt dass Snowflake auf Ihr Netzwerk zugreift, greift Ihr Netzwerk auf Snowflake zu. Ihre Firewall sieht immer nur ausgehende TLS-Verbindungen, die von innerhalb Ihres Perimeters initiiert wurden. Es gibt keine eingehenden Firewall-Regeln, die geöffnet, geändert oder genehmigt werden müssen.

Der Datenverkehr zwischen dem Agenten und Snowflake ist durch Mutual TLS (mTLS) geschützt, was bedeutet, dass beide Seiten die Identität der jeweils anderen mithilfe von Zertifikaten überprüfen. Die Einrichtung beginnt mit einem einmaligen Bootstrap-Token. Danach authentifiziert sich der Agent automatisch mit seinem Zertifikatspaar, das Snowflake im Hintergrund rotiert. Der Agent arbeitet auf der TCP-Ebene: Er leitet den Datenverkehr weiter, ohne die durchlaufenden Daten zu überprüfen, zu parsen oder zu speichern.

Sicherheit. DCP wurde für ein Deny-All-Inbound-Netzwerk entwickelt. Der Agent akzeptiert niemals eingehende Verbindungen, sodass Sie keine Firewall-Ausnahme anfordern und keinen neuen Inbound-Listener hinzufügen müssen. Ihre Firewall sieht eine Klasse von Datenverkehr: ausgehendes TLS über Port 443.

Die Identität ist explizit und überprüfbar. Sie erstellen ein Bootstrap-JSON-Web-Token (JWT) in Snowflake und legen es auf dem Agent-Host ab. Der Agent präsentiert dieses Token einmal der DCP-Control-Plane und erhält ein mTLS-Zertifikat, das an diesen DCP-Client gebunden ist. Danach verwenden Tunnel, Heartbeats und Routing-Updates mTLS. Beide Seiten überprüfen Zertifikate bei jeder Verbindung. Das Bootstrap-Token wird erst bei der nächsten Zertifikatsrotation wieder verwendet.

Der Agent ist ein TCP-Pass-Through. Er überprüft, parst oder speichert die Bytes im Tunnel nicht. Quell-Anmeldeinformationen verbleiben in Snowflake; sie landen niemals auf dem Agenten. Ziele werden in Snowflake auf die Allowlist gesetzt: Eine Netzwerkregel benennt den privaten Host und Port, eine externe Zugriffsintegration lässt diese Regel zu, und Sie binden die Integration an das DCP-Objekt. Optional kann eine Netzwerkrichtlinie für das Objekt einschränken, welche Quell-IPs mit der DCP-Control-Plane kommunizieren dürfen. Wenn Sie das Objekt deaktivieren oder löschen, funktioniert das Zertifikat des Agenten nicht mehr, selbst wenn das Zertifikat noch nicht abgelaufen ist.

Erreichbarkeit. DCP schließt die Lücken, die Same-Cloud-Private-Endpoints und öffentliche SaaS-Konnektoren offen lassen:

• On-Premises-Datenbanken hinter einer Unternehmens-Firewall, einschließlich Oracle, SQL Server, PostgreSQL und MySQL
• Private Kafka-Broker in einer VPC oder einem Rechenzentrum
• Cloudübergreifende Quellen wie Daten auf AWS, während sich das Snowflake-Konto auf Azure befindet
• Hybride Umgebungen mit mehreren dieser Topologien gleichzeitig

Der Agent benötigt nur den ausgehenden Port 443, sodass dasselbe Muster funktioniert, unabhängig davon, ob sich Ihre Daten und Ihr Snowflake-Konto auf AWS, Azure, Google Cloud oder On-Premises befinden. Wenn Sie Drittanbieter-Tools zusammengefügt haben, um diese Lücken zu schließen, ersetzt DCP dieses Flickwerk durch einen First-Party-Pfad, der nativ für Openflow ist.

Einfachheit. Der Agent wird als Docker-Image ausgeliefert und läuft auf jedem Linux-Host mit Docker oder einer anderen OCI-kompatiblen Laufzeitumgebung. Kubernetes ist nicht erforderlich. Der Agent stellt die Verbindung wieder her, wenn der Tunnel abbricht, und Snowflake rotiert das Agentenzertifikat im Hintergrund, ohne aktive Verbindungen zu trennen.

DCP ist heute allgemein auf AWS, Azure und GCP für Snowflake-Kunden der Editionen Standard, Enterprise und Business Critical verfügbar. Unternehmen mit Konnektivitätsanforderungen für private Quellen, von einem mittelständischen Fertigungsunternehmen mit Oracle On-Premises bis hin zu einer regionalen Bank, die PostgreSQL hinter ihrer Firewall betreibt, können mit einer First-Party-Openflow-Funktion beginnen, ohne zuvor auf eine höhere Snowflake-Edition umsteigen zu müssen.

Wenn Sie über On-Premises-Datenbanken, private Kafka-Broker oder cloudübergreifende Quellen verfügen, die Sie bisher nicht mit Snowflake Openflow verbinden konnten, probieren Sie DCP mit Openflow noch heute aus, um sie zu verbinden, ohne eingehenden Firewall-Zugriff zu öffnen oder Ihr Netzwerk neu zu gestalten.

Schnellstart

Dokumentation

• Übersicht über Data Connectivity Proxy: Architektur, wann DCP verwendet werden sollte, Vergleich mit PrivateLink und stabilen Egress-IPs
• Data Connectivity Proxy einrichten: Schritt-für-Schritt-Bereitstellungsleitfaden
• Sicherheitsmodell: mTLS, Zertifikatsverwaltung und Zugriffswiderruf
• Data Connectivity Proxy überwachen: DESCRIBE DATA CONNECTIVITY PROXY, Ereignisverlauf, Prometheus-Metriken
• Verwendung von Snowflake Openflow mit Data Connectivity Proxy