Ambiente isolado

A arquitetura de ambiente isolado herda a linha de base de conectividade protegida e adiciona dois requisitos: acesso privado ao workspace e um firewall externo obrigatório. O acesso ao workspace é restrito por VPN ou PrivateLink de entrada, nunca pela Internet pública. Todo o egresso de compute clássico passa pelo firewall para inspeção e aplicação de políticas.

Esta arquitetura tem:

• Isolamento de rede completo : todo o tráfego flui por conexões privadas.
• Acesso privado ao workspace : somente VPN ou PrivateLink de entrada. O workspace está inacessível da internet pública.
• Inspeção de saída exigida : inspeção de firewall de todo o tráfego de saída do compute clássico.
• Prevenção de exfiltração de dados: Controles da camada de rede bloqueiam a transferência de dados não autorizada.

Quando usar esta arquitetura:

• O acesso ao workspace deve ser privado, como via VPN ou PrivateLink de entrada.
• Gerenciamento de dados em indústrias altamente regulamentadas, por exemplo, serviços financeiros, saúde, governo.
• Estruturas de compliance exigem controles de saída (por exemplo, SOC 2, HIPAA, PCI DSS e FedRAMP).
• Implementando estruturas de segurança corporativas de confiança zero.
• Prevenção de exfiltração de dados é um requisito.

Pré-requisitos

• Databricks Plano Enterprise.

• Infraestrutura VPN existente ou conectividade PrivateLink de entrada.

• Firewall ou dispositivo virtual de rede (NVA).

Visão geral da arquitetura

A arquitetura do ambiente isolado roteia todo o tráfego por meio de conexões privadas com inspeção de firewall.

Tipo de tráfego	Caminho
Acesso do usuário	Usuários → VPN ou PrivateLink de entrada → Workspace
Compute clássico → controle	Compute → PrivateLink Clássico → plano de controle do Databricks
Compute clássico → cloud	Compute → endpoints de VPC → serviços da AWS (S3, STS, Kinesis)
Serverless para seus recursos	Serverless compute → Endpoints privados da NCC → Buckets S3 ou VPC
Compute clássico para egresso	Compute → Firewall externo (obrigatório) → Internet inspecionada

Componentes obrigatórios

Entrada

O workspace é acessível somente por meio de conexões privadas: VPN, PrivateLink de entrada ou ambos, dependendo da sua infraestrutura existente. Clientes geralmente escolhem um em vez de acumulá-los.

Configurações de acesso privado (desativar acesso público)

Este é o controle de restrição que de fato bloqueia o ingresso público. Sem ele, o workspace ainda aceita tráfego da internet mesmo com o PrivateLink configurado. PrivateLink passa a ser um caminho adicional, não o único caminho.

Crie um objeto de configurações de acesso privado com **Acesso público ativado** definido como **Falso** e anexe-o ao workspace. Quando o acesso público é desativado, nenhum tráfego público pode chegar ao workspace.

Controles de entrada do workspace

Configurar entrada do workspace através de entrada baseada em contexto (CBI), a estrutura de política de entrada recomendada. As regras CBI combinam a origem da rede (intervalos de IP), identidade, mecanismo de autenticação e escopo de acesso em um modelo único de permitir/negar, de modo que o atributo de origem da rede cumpre a mesma função que o recurso de lista de acesso IP autônomo, e mais.

Listas de acesso IP continuam sendo suportadas e podem ser configuradas junto com CBI. Quando ambos estão configurados, uma solicitação deve ser permitida por ambos os controles.

Níveis de configuração :

• Políticas de CBI de nível da conta : aplicam-se a todos os workspaces na conta. Veja Gerenciar políticas de entrada baseadas em contexto.
• Listas de acesso IP do workspace : Aplicam-se a um único workspace. Consulte Configurar listas de acesso IP para workspaces.
• Listas de acesso IP no nível da conta : aplicam-se ao console da conta. Consulte Configurar listas de acesso IP para o console da account.

Práticas recomendadas :

• Comece de forma ampla, aperfeiçoe com base no uso real.
• Documentar intervalos de endereços IP com a finalidade e datas de validade.
• Manter o acesso do administrador através de um intervalo de IP confiável.
• Revisar trimestralmente e remover intervalos obsoletos.

atenção

Ingress policies and IP access lists can lock you out of your workspace if misconfigured. Always maintain administrator access through a known-good IP range.

controle de acesso do destinatário do Compartilhamento aberto

O OpenSharing usa suas próprias listas de acesso IP configuradas em objetos de destinatário. Isso é separado das listas de acesso IP do workspace e não é coberto por entrada baseada em contexto. Aplica-se apenas ao compartilhamento Databricks-para-Open (para destinatários não-Databricks).

Consulte Restringir o acesso do destinatário do OpenSharing usando listas de acesso IP (Databricks para compartilhamento aberto).

Conectividade de entrada

Estabelece conectividade privada para acesso de usuário à UI e API do workspace. Os usuários acessam o workspace por VPN ou PrivateLink de entrada, nunca pela Internet pública.

Consulte Configurar o PrivateLink de Entrada.

DNS Personalizado

Configure o DNS privado para resolver endpoints do Databricks para endereços IP privados.

Consulte Configurar DNS para PrivateLink de entrada da AWS.

Saída

Os controles de saída serverless (políticas de rede e endpoints privados NCC) são herdados da linha de base de conectividade reforçada. Esta arquitetura torna o firewall externo, opcional em Hardened, obrigatório para inspeção total de egresso do classic compute.

Firewall externo (obrigatório)

Encaminhe todo o tráfego de saída através de um firewall para inspeção, registro e aplicação de políticas. Opções incluem:

• AWS Network Firewall, um serviço gerenciado com menor sobrecarga operacional e integração com o roteamento AWS.
• Dispositivo de firewall de terceiros (como Palo Alto) integrado com o Gateway Load Balancer para mais recursos de inspeção. Preferencialmente escolhida por organizações que já possuem investimento em Palo Alto.

Consulte Endereços IP e domínios para serviços e ativos do Databricks para os endpoints necessários do Databricks que as regras de firewall devem permitir.

dica

For maximum lockdown, consider hosting a private package repository (such as JFrog Artifactory or Sonatype Nexus) for Python, R, and Maven packages. This eliminates the need for firewall rules allowing access to public package indexes like PyPI.

atenção

Databricks control plane and SCC relay connections use TLS with certificate pinning. Do not enable TLS inspection (decrypt and re-encrypt) on traffic between your clusters and the Databricks control plane. Doing so causes cluster failures. Configure firewall rules to allow these connections by destination FQDN or IP without TLS interception. See IP addresses and domains for Databricks services and assets for required endpoints.

importante

Incorrectly configured firewall rules can break Databricks capabilities. Test thoroughly in a non-production environment.

Proteção de exfiltração de dados

Configure políticas de rede e controles de firewall para impedir a exfiltração de dados não autorizada:

• Controle de saída serverless por meio de políticas de rede.
• Egresso da compute clássica via firewall/NVA.
• Regras de endpoints privados para destinos de dados aprovados.

Consulte proteção de exfiltração de dados para obter orientações de implementação.

Linha de base de compute clássico

A linha de base de compute clássica é herdada de Segurança Gerenciada, e os endpoints de serviço de cloud são herdados de Conectividade Reforçada. Nenhum componente de compute clássico adicional é necessário para esta arquitetura.

A linha de base inclui VPC gerenciada pelo cliente, Conectividade Segura de Cluster (SCC) e PrivateLink clássico. Endpoints de serviço de cloud incluem endpoints de VPC, políticas de endpoint de VPC e políticas de bucket do S3.

Abordagens de saída para acesso a dados

Existem duas abordagens para gerenciar o acesso a dados de saída de recursos de compute:

• Gateway NAT com firewall : Implante um gateway NAT para conectividade de saída e direcione o tráfego por meio de um firewall para inspeção. Esta abordagem permite acesso controlado a repositórios de pacotes externos e APIs e mantém a visibilidade dos padrões de tráfego. Utilize esta abordagem quando precisar acessar recursos externos, mas que exijam inspeção e registro.

• Sem gateway NAT (totalmente privado) : Remove o gateway NAT inteiramente para eliminar toda a comunicação pública dos recursos de compute. Todo o acesso a dados ocorre somente por meio de endpoints privados e endpoints de VPC. Essa abordagem oferece o mais alto nível de segurança ao remover a possibilidade de exfiltração de dados por meio de caminhos de saída públicos. Use esta abordagem quando sua organização proíbe qualquer comunicação de internet pública de recursos de compute.

Implementação

Comece a partir de uma linha de base de conectividade reforçada implantada. As fases a seguir adicionam o acesso privado ao workspace e o firewall externo necessário que definem esta arquitetura.

Fase 1: Controles de entrada

1. Configure o PrivateLink de entrada para que o acesso do usuário ao aplicativo Web do Databricks e às APIs REST flua através do PrivateLink em vez de IPs públicos. Consulte Configurar o PrivateLink de Entrada.
2. Crie um objeto de configurações de acesso privado com **Acesso público ativado** definido como **Falso** e anexe-o ao workspace. É isso que realmente bloqueia a entrada pública. Sem ele, o workspace ainda aceita tráfego de internet mesmo com o PrivateLink de entrada configurado.
3. Teste o acesso do usuário pela VPN corporativa ou pelo caminho do PrivateLink para verificar se o tráfego para o workspace é roteado pela rede privada conforme o esperado e se o acesso público está bloqueado.

Fase 2: Firewall externo (obrigatório)

1. Implante um dispositivo de firewall de terceiros (como Palo Alto) em uma VPC de hub e integre-o à VPC do workspace usando roteamento apropriado (por exemplo, Transit Gateway ou emparelhamento de VPC), ou use o AWS Network Firewall.
2. Configure tabelas de rotas para enviar 0.0.0.0/0 para o firewall. As regras de firewall devem permitir os endpoints Databricks necessários (consulte Endereços IP e domínios para serviços e ativos do Databricks), endpoints de serviço de cloud e serviços externos aprovados.
3. Configurar regras de firewall sem interceptação TLS no plano de controle e tráfego do relé SCC.

Fase 3: Validação

1. Verifique o controle de saída ao revisar os logs do firewall para verificar se o tráfego dos clusters e serverless somente alcança endpoints externos ou internos aprovados.
2. Confirme que não há endereços IP públicos em nós de cluster ou outros recursos de compute gerenciados pelo Databricks.
3. Valide que todo o tráfego de controle, dados e de entrada flua através dos endpoints do PrivateLink e dos caminhos de firewall configurados.

O SRA do Databricks Terraform fornece padrões de Infrastructure-as-Code que automatizam este padrão de implantação.

Validação

Após implantar a arquitetura, execute as seguintes verificações para confirmar que o isolamento de rede completo, a conectividade privada e os controles de saída funcionam conforme configurado.

Verificar	Resultado esperado
Workspace acessível via VPN	Sim
Workspace acessível sem VPN	Não
Os clusters são iniciados com SCC	Sim, nenhum IP público
Acesso a dados por meio de conexões privadas	Sim
Saída bloqueada sem aprovação do firewall	Sim
O DNS resolve para IPs privados	Sim

Solução de problemas

Se uma verificação de validação falhar ou uma carga de trabalho não conseguir se conectar a um endpoint necessário, use a tabela específica da nuvem a seguir para diagnosticar problemas comuns.

Problema	Causa	Resolução
Cluster falha ao começar	Firewall bloqueando endpoints necessários ou endpoints da VPC mal configurados para SCC, plano de controle do Databricks, S3, Kinesis ou STS (grupos de segurança, roteamento)	Revise os logs de firewall e adicione regras de infraestrutura do Databricks; verifique se os grupos de segurança do endpoint de VPC permitem o tráfego das sub-redes de cluster; verifique as tabelas de rotas.
A resolução de DNS falha	DNS privado configurado incorretamente	Verifique as zonas privadas hospedadas do Route 53 e as associações de VPC
Falha no acesso S3	VPC endpoint ou problema de roteamento	Verifique a configuração do endpoint do gateway S3 e as tabelas de rotas.
A instalação do pacote falha	PyPI bloqueado pelo firewall	Adicionar PyPI à lista de permissões do firewall

Manutenção contínua

• Regras de Firewall: Revisar e atualizar regularmente as listas de permissão de saída.
• Gerenciamento de DNS : atualize os registros ao adicionar workspaces.
• Monitoramento de Endpoints : Acompanhe a integridade de endpoints privados e os custos de transferência de dados.
• Políticas de rede: Adicione endpoints privados para novas fontes de dados aprovadas.
• Remover firewall : Se a sobrecarga operacional do firewall for muito alta ou os requisitos de compliance relaxarem, é possível remover o componente de firewall e manter a conectividade privada e o acesso VPN.
• Fazer downgrade para conectividade reforçada : se o acesso privado ao workspace se tornar uma barreira de produtividade.

Passos seguintes

• • proteção contra exfiltração de dados
  • Arquitetura de referência detalhada para combinar controles de rede e do Unity Catalog para evitar a exfiltração de dados.
• • Rede
  • Opções de rede e conceitos para Databricks.