14 settembre 2026/Lettura: 7 minData engineering
Presentiamo Data Connectivity Proxy: portare Snowflake Openflow vicino ai dati privati
I dati aziendali si estendono su più cloud, applicazioni e piattaforme, creando punti ciechi critici per i firewall perimetrali. Proteggere il confine della rete non basta più. Governance e controllo devono essere integrati esattamente dove risiedono i dati. Una tipica grande organizzazione può eseguire database Oracle on-premise per i sistemi finanziari principali, trasmettere eventi in tempo reale tramite broker Kafka all’interno di una VPC privata e gestire database distribuiti su più cloud pubblici. Finora, raggiungere queste fonti private in un ambiente ibrido è stato impossibile oppure ha richiesto una soluzione di rete diversa per ogni topologia. Questo insieme disomogeneo di VPN, PrivateLink e agenti sviluppati ad hoc diventa con il tempo un problema di infrastruttura a sé stante.
Oggi presentiamo Data Connectivity Proxy (DCP) per Snowflake Openflow, per risolvere il problema dell’accesso ai dati privati. Snowflake Openflow è il nostro servizio di data integration completamente gestito che collega i dati senza dover creare un’infrastruttura ETL personalizzata, e DCP gli dà accesso a fonti private prima irraggiungibili. Lo fa attraverso un modello di agente coerente, fornito da Snowflake, che riduce la necessità di VPN, PrivateLink e agenti di terze parti per ogni topologia.
La connettività ai dati privati è stata finora un progetto di rete
Portare i dati privati in una pipeline gestita ha storicamente imposto una scelta. I team si assumono il costo operativo di un’infrastruttura ETL personalizzata a ogni confine di rete oppure avviano progetti lunghi mesi per ottenere le autorizzazioni ad aprire porte inbound in ambienti dove di norma non è consentito.
Per le aziende dei servizi finanziari, della sanità e del settore manifatturiero, una policy deny-all-inbound è spesso un requisito normativo. Quando un fornitore di pipeline gestite dice “configura una connessione di rete privata”, ciò che serve in realtà è coinvolgere il team di network engineering, aprire regole firewall e ottenere il via libera da un change advisory board. DCP è progettato per reti deny-all-inbound: l’agente stabilisce solo connessioni TLS in uscita sulla porta 443. Un vincolo correlato: l’host dell’agente necessita di accesso diretto in uscita a Snowflake su quella porta. L’instradamento del traffico in uscita dell’agente attraverso un forward proxy gestito dall’azienda (HTTPS_PROXY o forwarding basato su CONNECT) non è attualmente supportato.
Configurare tutto questo richiede comunque settimane di lavoro prima che i dati inizino a muoversi, e le opzioni esistenti risolvono solo una parte del problema:
- La connettività privata nativa dei CSP (AWS PrivateLink, Azure Private Endpoint e Google Private Service Connect) è la scelta giusta quando servono percorsi privati all’interno dello stesso cloud. Non è pensata per le fonti on-premise. DCP copre questi casi con un agente in uscita nella tua rete.
- VPN, ExpressRoute e VPC peering funzionano, ma ognuno è un progetto di network engineering di diverse settimane che richiede coordinamento con il team infrastruttura, approvazioni e manutenzione continua.
- I tool legacy per le pipeline lasciano in gran parte irrisolto il problema. Alcuni di questi strumenti non dispongono di un proprio agente, quindi i clienti devono predisporre da sé una VPN e connessioni di rete dedicate prima che la pipeline possa fare qualsiasi cosa.
- Gli agenti di connettività di terze parti risolvono il problema tecnico, ma aggiungono un altro fornitore, un altro contratto e un altro sistema da gestire e supportare.
Come funziona Data Connectivity Proxy
DCP elimina queste dipendenze di rete dal percorso di data integration perché viene distribuito come agente leggero che gira all’interno dell’ambiente in cui i dati già risiedono: un data center on-premise, un ambiente di cloud privato, una VPC o un altro cloud.
L’agente crea una connessione in uscita sulla porta 443 verso Snowflake e stabilisce un tunnel crittografato. Snowflake instrada quindi il traffico Openflow attraverso quel tunnel per raggiungere la fonte privata.
Il design ribalta il modello consueto. Invece che Snowflake entri nella tua rete, è la tua rete a raggiungere Snowflake. Il tuo firewall vede soltanto connessioni TLS in uscita avviate dall’interno del perimetro. Non ci sono regole firewall inbound da aprire, modificare o approvare.
Il traffico tra l’agente e Snowflake è protetto con mutual TLS (mTLS): entrambe le parti verificano l’identità reciproca tramite certificati. La configurazione parte da un token di bootstrap monouso; da quel momento l’agente si autentica automaticamente con la propria coppia di certificati, che Snowflake ruota in background. L’agente opera a livello TCP: inoltra il traffico senza ispezionare, analizzare o memorizzare i dati che lo attraversano.
Perché scegliere DCP con Openflow per raggiungere le fonti di dati privati
Sicurezza. DCP è progettato per una rete deny-all-inbound. L’agente non accetta mai connessioni inbound: non devi richiedere un’eccezione al firewall né aggiungere un nuovo listener inbound. Il tuo firewall vede una sola classe di traffico: TLS in uscita sulla porta 443.
L’identità è esplicita e verificabile. Generi un JSON web token (JWT) di bootstrap in Snowflake e lo inserisci sull’host dell’agente. L’agente presenta quel token una sola volta al control plane DCP e riceve un certificato mTLS associato a quel client DCP. Da quel momento, tunnel, heartbeat e aggiornamenti di routing usano mTLS. Entrambe le parti verificano i certificati a ogni connessione. Il token di bootstrap non viene più utilizzato fino alla successiva rotazione del certificato.
L’agente è un pass-through TCP. Non ispeziona, analizza né memorizza i byte nel tunnel. Le credenziali delle fonti restano in Snowflake e non arrivano mai sull’agente. Le destinazioni sono inserite in una allowlist in Snowflake: una network rule indica host e porta privati, un’external access integration consente quella regola e tu associ l’integrazione all’oggetto DCP. Facoltativamente, una network policy sull’oggetto può limitare quali IP di origine possono comunicare con il control plane DCP. Disabilitando o eliminando l’oggetto, il certificato dell’agente smette di funzionare, anche se non è scaduto.
Copertura. DCP colma le lacune lasciate aperte dagli endpoint privati nello stesso cloud e dai connettori SaaS pubblici:
- Database on-premise dietro un firewall aziendale, tra cui Oracle, SQL Server, PostgreSQL e MySQL
- Broker Kafka privati in una VPC o in un data center
- Fonti cross-cloud, come dati su AWS con account Snowflake su Azure
- Ambienti ibridi con più di queste topologie contemporaneamente
All’agente serve solo la porta 443 in uscita, quindi lo stesso schema funziona sia che i dati e l’account Snowflake si trovino su AWS, Azure, Google Cloud o on-premise. Se finora hai combinato strumenti di terze parti per colmare quelle lacune, DCP sostituisce questo insieme disomogeneo con un percorso nativo di Openflow fornito direttamente da Snowflake.
Semplicità. L’agente è distribuito come immagine Docker e gira su qualsiasi host Linux con Docker o un altro runtime compatibile con OCI. Kubernetes non è necessario. L’agente si riconnette se il tunnel cade e Snowflake ruota il certificato dell’agente in background senza interrompere le connessioni attive.
Come iniziare a usare DCP oggi
DCP è in GA su AWS, Azure e GCP per i clienti Snowflake con edizione Standard, Enterprise e Business-Critical. Le organizzazioni che necessitano di connettività a fonti private, da un’azienda manifatturiera di medie dimensioni con Oracle on-premise a una banca regionale che gestisce PostgreSQL dietro il proprio firewall, possono iniziare a usare una funzionalità Openflow fornita direttamente da Snowflake senza dover prima passare a un’edizione Snowflake superiore.
Se hai database on-premise, broker Kafka privati o fonti cross-cloud che non hai potuto collegare a Snowflake Openflow, prova subito DCP con Openflow per collegarli senza aprire accessi inbound sul firewall né riprogettare la rete.
Guida rapida
-- Step 1: Create the DCP object
CREATE DATA CONNECTIVITY PROXY my_dcp_client;
-- Step 2: Generate a bootstrap token (valid for 7 days)
SELECT SYSTEM$GENERATE_DATA_CONNECTIVITY_PROXY_BOOTSTRAP_TOKEN('my_dcp_client', 7);# Step 3: Deploy the agent
docker run -d \
--name dcp-agent \
--restart unless-stopped \
-v /etc/dcp/credentials:/credentials:ro \
snowflake/dcp-agent:latest \
--dcp-client-name my_dcp_client \
--credentials-file /credentials \
--snowflake-account <your-account>-- Step 4: Verify
DESCRIBE DATA CONNECTIVITY PROXY my_dcp_client;Documentazione
- Panoramica di Data Connectivity Proxy: architettura, quando usare DCP, confronto con PrivateLink e IP di egress statici
- Configurare Data Connectivity Proxy: guida al deployment passo per passo
- Modello di sicurezza: mTLS, gestione dei certificati e revoca degli accessi
- Monitorare Data Connectivity Proxy:
DESCRIBE DATA CONNECTIVITY PROXY, cronologia degli eventi, metriche Prometheus - Utilizzo di Snowflake Openflow con Data Connectivity Proxy
