14 de set. de 2026/Leitura: 8 minData Engineering
Apresentando o Data Connectivity Proxy: leve o Snowflake Openflow para os dados privados
Os dados corporativos se espalham por ambientes multinuvem, apps e plataformas, criando pontos críticos de vulnerabilidade para firewalls de perímetro. Proteger o limite da rede não é mais o suficiente. A governança e o controle precisam estar integrados exatamente onde os dados residem. Uma organização grande típica pode executar bancos de dados Oracle no local para as principais operações financeiras, transmitir eventos em tempo real por meio de brokers Kafka dentro de uma VPC privada e operar bancos de dados distribuídos em várias nuvens públicas. Até agora, acessar essas fontes privadas em um ambiente híbrido era impossível ou exigia uma solução de rede diferente para cada topologia. Essa colcha de retalhos de VPNs, Private Links e agentes pontuais se torna, com o tempo, um problema de infraestrutura por si só.
Hoje, para resolver o problema de acesso a dados privados, anunciamos o Data Connectivity Proxy (DCP) para Snowflake Openflow. O Snowflake Openflow é nosso serviço de integração de dados totalmente gerenciado que conecta dados sem a necessidade de criar infraestrutura de ETL personalizada, e o DCP dá a ele acesso a fontes privadas que antes eram inacessíveis. Isso é feito por meio de um modelo de agente consistente, fornecido pela Snowflake, que reduz a necessidade de VPNs, Private Links e agentes de terceiros específicos para cada topologia.
Conectividade de dados privados: um projeto de rede
Levar dados privados a um pipeline gerenciado historicamente exigia escolher entre dois caminhos: assumir o custo operacional de uma infraestrutura de ETL personalizada em cada fronteira de rede, ou embarcar em projetos de meses só para conseguir aprovação e abrir portas de entrada em ambientes onde isso normalmente não é permitido.
Para empresas dos setores de serviços financeiros, saúde e indústria, uma política de bloqueio total de tráfego de entrada costuma ser uma exigência regulatória. Quando um fornecedor de pipeline gerenciado diz "estabeleça uma conexão de rede privada", o que isso realmente exige é fazer um loop com a equipe de engenharia de rede, abrir regras de firewall e obter aprovação de um comitê de gestão de mudanças. O DCP foi criado para redes com bloqueio total de tráfego de entrada: o agente faz apenas conexões TLS de saída na porta 443. Uma restrição relacionada: o host do agente precisa de acesso direto de saída à Snowflake nessa porta. Rotear o tráfego de saída do próprio agente por um proxy de encaminhamento gerenciado pela empresa (HTTPS_PROXY ou encaminhamento baseado em CONNECT) não é compatível no momento.
Ainda assim, configurar tudo isso é um projeto de várias semanas antes que qualquer dado seja movido, e as opções existentes resolvem apenas partes do problema:
- A conectividade privada nativa do CSP (AWS Private Link, Azure Private Endpoint e Google Private Service Connect) é a opção certa quando você precisa de caminhos privados na mesma nuvem. Ela não é indicada para fontes locais. O DCP cobre esses casos com um agente de saída na sua rede.
- VPN, ExpressRoute e VPC peering funcionam, mas cada um é um projeto de engenharia de rede de várias semanas que exige coordenação com a equipe de infraestrutura, aprovações e manutenção contínua.
- Ferramentas de pipeline tradicionais deixam, em grande parte, esse problema sem solução. Algumas não têm nenhum agente nativo, então os clientes precisam configurar, por conta própria, uma VPN e conexões de rede dedicadas antes que o pipeline possa fazer qualquer coisa.
- Os agentes de conectividade de terceiros resolvem o problema técnico, mas adicionam mais um fornecedor, mais um contrato e mais um sistema para operar e oferecer suporte.
Como funciona o Data Connectivity Proxy
O DCP remove essas dependências de rede do caminho de integração de dados, sendo fornecido como um agente leve que é executado dentro do ambiente onde seus dados já residem: um data center local, um ambiente de nuvem privada, uma VPC ou outra nuvem.
O agente cria uma conexão de saída na porta 443 com a plataforma Snowflake e estabelece um túnel criptografado. Em seguida, a Snowflake roteia o tráfego do Openflow por esse túnel para ter acesso à fonte privada.
O design inverte o modelo tradicional. Em vez de a Snowflake acessar sua rede, é a sua rede que se conecta à Snowflake. Seu firewall só vê as conexões TLS de saída, iniciadas de dentro do seu perímetro. Não há regras de firewall de entrada para abrir, alterar ou aprovar.
O tráfego entre o agente e a plataforma Snowflake é protegido com TLS mútuo (mTLS), o que significa que ambos os lados verificam a identidade um do outro usando certificados. A configuração começa com um token de bootstrap único; depois disso, o agente se autentica de modo automático usando seu par de certificados, que a Snowflake rotaciona em segundo plano. O agente opera no nível TCP: ele encaminha o tráfego sem inspecionar, analisar ou armazenar os dados que passam por ele.
Por que escolher DCP com Openflow para acessar fontes de dados privadas
Segurança. O DCP foi criado para uma rede com bloqueio total de tráfego de entrada. O agente nunca aceita conexões de entrada, então você não precisa solicitar uma exceção de firewall nem adicionar um novo listener de entrada. Seu firewall vê apenas uma classe de tráfego: TLS de saída na porta 443.
A identidade é explícita e auditável. Você gera um token web JSON (JWT) de bootstrap na Snowflake e o coloca no host do agente. O agente apresenta esse token uma vez ao painel de controle do DCP e recebe um certificado mTLS vinculado a esse cliente DCP. Depois disso, túneis, pulsações (heartbeats) e atualizações de roteamento usam mTLS. Ambos os lados verificam certificados em cada conexão. O token de bootstrap não é usado novamente até a próxima rotação de certificado.
O agente funciona em modo de passagem direta (pass-through) para TCP. Ele não inspeciona, analisa nem armazena os bytes no túnel. As credenciais de origem permanecem na Snowflake; elas nunca chegam ao agente. Os destinos são incluídos em uma lista de permissões na Snowflake: uma regra de rede define o host e a porta privados, uma integração de acesso externo permite essa regra, e você vincula a integração ao objeto do DCP. Opcionalmente, uma política de rede no objeto pode restringir que IPs de origem podem se comunicar com o painel de controle do DCP. Ao desativar ou remover o objeto, o certificado do agente deixa de funcionar, mesmo que ele ainda não tenha expirado.
Cobertura. O DCP cobre as falhas deixadas por pontos de extremidade privados na mesma nuvem e conectores SaaS públicos:
- Bancos de dados locais atrás de um firewall corporativo, incluindo Oracle, SQL Server, PostgreSQL e MySQL.
- Brokers Kafka privados em uma VPC ou data center.
- Fontes cross-cloud, como dados na AWS enquanto a conta Snowflake está no Azure.
- Ambientes híbridos com várias dessas topologias ao mesmo tempo.
O agente precisa apenas da porta de saída 443, então o mesmo padrão funciona de modo independente de seus dados e da sua conta Snowflake estarem na AWS, no Azure, no Google Cloud ou armazenados no local. Se você tem integrado ferramentas de terceiros para resolver esse problema, o DCP substitui essa colcha de retalhos por um caminho nativo do Openflow.
Simplicidade. O agente é distribuído como uma imagem Docker, sendo executado em qualquer host Linux com Docker ou outro runtime compatível com OCI. O Kubernetes não é necessário. O agente se reconecta se o túnel cair, e a Snowflake rotaciona o certificado do agente em segundo plano sem encerrar conexões ativas.
Como começar a usar o DCP hoje
O DCP está disponível em GA hoje na AWS, no Azure e no GCP para clientes Snowflake nas edições Standard, Enterprise e Business-Critical. Organizações com necessidades de conectividade a fontes privadas, de uma fabricante de médio porte com servidor Oracle local a um banco regional que opera PostgreSQL atrás do firewall, podem começar a usar uma capacidade nativa do Openflow sem precisar migrar para uma edição superior da Snowflake primeiro.
Se você tem bancos de dados locais, brokers Kafka privados ou fontes cross-cloud que não conseguiu conectar ao Snowflake Openflow, teste o DCP com o Openflow hoje mesmo para conectá-los sem abrir portas de entrada no firewall ou redesenhar sua rede.
Guia rápido
-- 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;Documentação
- Visão geral do Data Connectivity Proxy (EN): arquitetura, quando usar o DCP, comparação com o Private Link e IPs de saída estáveis
- Configurar o Data Connectivity Proxy (EN): guia de implementação passo a passo
- Modelo de segurança (EN): mTLS, gestão de certificados e revogação de acesso
- Monitorar o Data Connectivity Proxy (EN):
DESCRIBE DATA CONNECTIVITY PROXY, histórico de eventos, métricas do Prometheus - Usando o Snowflake Openflow com o Data Connectivity Proxy (EN)
