Ambiente isolado

A arquitetura do ambiente isolado herda a configuração de referência de conectividade reforçada e adiciona dois requisitos: acesso privado ao espaço de trabalho e um firewall externo obrigatório. O acesso ao espaço de trabalho é controlado por VPN ou por Link Privado de entrada, nunca pela internet pública. Toda a saída de computação clássica flui pelo firewall para inspeção e imposição de políticas.

Essa arquitetura tem:

• Isolamento de rede completo: todo o tráfego flui por meio de conexões privadas.
• Acesso privado ao espaço de trabalho: somente por VPN ou Link Privado de entrada. O workspace é inacessível da Internet pública.
• Inspeção obrigatória de tráfego de saída: inspeção por firewall de todo o tráfego de saída do Classic Compute.
• Prevenção contra exfiltração de dados: os controles de camada de rede bloqueiam a transferência de dados não autorizada.

Use essa arquitetura quando:

• O acesso ao espaço de trabalho deve ser privado, como por meio de uma VPN ou de um Link Privado de entrada.
• Manipulação de dados em setores altamente regulamentados, por exemplo, serviços financeiros, saúde, governo.
• As estruturas de conformidade exigem controles de saída (por exemplo, SOC 2, HIPAA, PCI DSS e FedRAMP).
• Implementando estruturas de segurança de confiança zero da empresa.
• A prevenção contra exfiltração de dados é um requisito.

Pré-requisitos

• Azure Databricks nível Premium com um espaço de trabalho com injeção em VNet.

• Infraestrutura de VPN existente ou conectividade de entrada via Link Privado.
• Firewall ou NVA (solução de virtualização de rede).

Visão geral da arquitetura

A arquitetura de ambiente isolado encaminha todo o tráfego por conexões privadas com inspeção por firewall:

Tipo de tráfego	Caminho
Acesso do usuário	Usuários → VPN ou Link Privado de entrada → Workspace
Computação clássica → controle	Computação → Link Privado clássico → plano de controle do Azure Databricks
Computação clássica → nuvem	Computação → Pontos de extremidade de serviço ou UDRs → Serviços do Azure
Sem servidor → seus recursos	Computação sem servidor → endpoints privados do NCC → Seus recursos do Azure
Computação clássica → saída	Computação → firewall externo (obrigatório) → Internet inspecionada

Componentes necessários

Inbound

O workspace só pode ser acessado por conexões privadas: VPN, Link Privado de entrada ou ambos, dependendo da infraestrutura existente. Os clientes normalmente selecionam um em vez de combiná-los.

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

Este é o controle de restrição que de fato bloqueia o tráfego de entrada público. Sem ele, o espaço de trabalho ainda aceita tráfego da Internet mesmo com o Link Privado configurado. Link Privado se torna um caminho adicional, não o único caminho.

Defina o Acesso à rede pública do espaço de trabalho como Desabilitado no portal do Azure. Isso bloqueia a entrada pública para a interface do usuário e as APIs do workspace.

Controles de entrada do espaço de trabalho

Configure o ingresso do workspace por meio da entrada baseada em contexto (CBI), a estrutura de políticas de ingresso recomendada. As regras do CBI combinam fonte de rede (intervalos de IP), identidade, mecanismo de autenticação e escopo de acesso em um único modelo de permissão/negação, de modo que o atributo de fonte de rede faz o mesmo trabalho que o recurso de lista de acesso IP autônomo, além de mais.

As listas de acesso a IP permanecem com suporte e podem ser configuradas junto com o 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 no nível da conta: Aplicam-se a todos os espaços de trabalho da conta. Consulte Gerenciar políticas de entrada baseadas em contexto.
• Listas de acesso IP em nível de espaço de trabalho: aplicam-se a um único espaço de trabalho. Veja Configuração de listas de acesso IP para áreas de trabalho.
• Listas de acesso IP em nível de conta: Aplicam-se ao console da conta. Consulte Configurar listas de acesso IP para o console da conta.

Práticas recomendadas:

• Inicie amplamente, refinar com base no uso real.
• Documente os intervalos de IP com a finalidade e as datas de expiração.
• Mantenha o acesso de administrador por meio de uma faixa de IP confiável.
• Examine trimestralmente e remova intervalos obsoletos.

Warning

As políticas de ingresso e as listas de acesso IP podem impedir seu acesso ao espaço de trabalho se forem configuradas incorretamente. Sempre mantenha o acesso administrativo por meio de uma faixa de IPs confiável.

Controle de acesso do destinatário do Delta Sharing

O Delta Sharing usa suas próprias listas de acesso IP configuradas em objetos de destinatário. Isso é separado das listas de acesso IP do espaço de trabalho e não é abrangido pelo ingresso baseado em contexto. Aplica-se apenas ao compartilhamento aberto (destinatários que não usam o Azure Databricks).

Confira Restringir o acesso do destinatário do Delta Sharing usando listas de acesso IP (compartilhamento aberto).

Conectividade de entrada

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

Consulte Configurar Link Privado de Entrada.

DNS personalizado

Configure o DNS privado para que resolva os pontos de extremidade do Azure Databricks para endereços IP privados.

Azure cria automaticamente zonas DNS privadas ao criar pontos de extremidade privados.

Saída

Controles de saída sem servidor (políticas de rede e pontos de extremidade privados NCC) são herdados da linha de base de conectividade endurecida . Essa arquitetura torna o firewall externo, opcional em Hardened, necessário para inspeção completa de saída de computação clássica.

Firewall externo (obrigatório)

Rotear todo o tráfego de saída por meio de um firewall para inspeção, registro em log e imposição de políticas. As opções incluem:

• Firewall do Azure ou NVAs (dispositivos virtuais de rede) de terceiros.

Dica

Use políticas de ponto de extremidade de serviço para o armazenamento de artefatos do Azure Databricks para contornar o firewall, reduzindo os custos de transferência de dados. O armazenamento de artefatos, sozinho, pode representar até 11 GB baixados por nó do cluster.

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

Dica

Para o bloqueio máximo, considere hospedar um repositório de pacote privado (como JFrog Artifactory ou Sonatype Nexus) para pacotes Python, R e Maven. Isso elimina a necessidade de regras de firewall que permitem acesso a índices de pacotes públicos, como PyPI.

Warning

O plano de controle do Azure Databricks e as conexões de retransmissão SCC usam TLS com fixação de certificados. Não habilite a inspeção do TLS (descriptografar e criptografar novamente) no tráfego entre seus clusters e o plano de controle Azure Databricks. Fazer isso causa falhas no cluster. Configure regras de firewall para permitir essas conexões por FQDN de destino ou IP sem interceptação TLS. Consulte endereços IP e domínios para serviços e ativos do Azure Databricks para os pontos de extremidade necessários.

Importante

As regras de firewall configuradas incorretamente podem interromper Azure Databricks funcionalidades. Teste minuciosamente em um ambiente de não produção.

Proteção contra exfiltração de dados

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

• Controle de saída sem servidor por meio de políticas de rede.
• Tráfego de saída da computação clássica via firewall/NVA.
• Regras de endpoint privado para destinos de dados aprovados.

Consulte a proteção contra exfiltração de dados para obter diretrizes de implementação.

Linha de base de computação clássica

A linha de base clássica de computação é herdada de Segurança gerenciada, e os pontos de extremidade do serviço de nuvem são herdados de Conectividade reforçada. Nenhum componente de computação clássico adicional é necessário para essa arquitetura.

A linha de base inclui injeção de VNet, SCC (Conectividade de Cluster Seguro) e Link Privado clássico. Os pontos de extremidade de serviço de nuvem incluem UDRs (rotas definidas pelo usuário), pontos de extremidade de serviço e pontos de extremidade privados para contas de armazenamento gerenciadas pelo cliente.

Abordagens de saída para acesso a dados

Há duas abordagens para lidar com o acesso a dados de saída de recursos de computação:

• Gateway de NAT com firewall: implante um gateway NAT para conectividade de saída e rote o tráfego por meio de um firewall para inspeção. Essa abordagem permite o acesso controlado a repositórios de pacotes externos e APIs e mantém a visibilidade dos padrões de tráfego. Use essa abordagem quando precisar acessar recursos externos, mas exigir inspeção e registro em log.

• Sem gateway NAT (totalmente privado): Remova o gateway NAT por completo para eliminar toda a comunicação pública proveniente dos recursos de computação. Todo o acesso aos dados ocorre exclusivamente por meio de private endpoints e VPC endpoints. Essa abordagem tem o nível mais alto de segurança removendo 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 com a Internet pública a partir de recursos de computação.

Implementation

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

Fase 1: controles de entrada

1. Configure o Link Privado de entrada para que o acesso do usuário à interface do usuário e às APIs do Azure Azure Databricks seja encaminhado de forma privada, em vez de passar por IPs públicos. Consulte Configurar Link Privado de Entrada.
2. Defina o Acesso à rede pública do espaço de trabalho como Desabilitado no portal do Azure. Isso é o que realmente bloqueia a entrada pública. Sem ele, o workspace ainda aceita tráfego da internet mesmo com o Link Privado de entrada configurado.
3. Teste o acesso do usuário via VPN ou Link Privado para confirmar que os usuários autenticados podem acessar o workspace somente por meio do caminho de rede privada e que o acesso público está bloqueado.

Fase 2: Firewall externo (obrigatório)

1. Implante Firewall do Azure ou uma NVA (solução de virtualização de rede) de terceiros em uma VNet do hub e conecte a VNet do workspace usando o emparelhamento VNet ou um hub virtual.
2. Configure UDRs (rotas definidas pelo usuário) nas sub-redes do espaço de trabalho com uma rota padrão para o firewall, para que o tráfego de saída dos recursos de computação do Azure Databricks passe pelo firewall do hub. Consulte Configurações de rota definidas pelo usuário para o Azure Databricks.
3. Configure as regras de aplicativo e de rede do Firewall do Azure para permitir apenas os pontos de extremidade necessários do Azure Databricks (consulte endereços IP e domínios dos serviços e ativos do Azure Databricks) sem interceptação de TLS no tráfego do plano de controle e de retransmissão SCC.

Fase 3: Validação

1. Verifique o controle de tráfego de saída analisando os logs e diagnósticos do Firewall do Azure para confirmar se o tráfego do Azure Databricks está sendo inspecionado e limitado de acordo com a política.
2. Confirme se nenhum endereço IP público esteja atribuído aos nós do cluster ou a outros recursos de computação gerenciados pelo Azure Databricks na VNet do workspace.
3. Valide se todo o controle, os dados e o tráfego de entrada fluem por meio dos pontos de extremidade Link Privado configurados e do firewall do hub, conforme projetado.

O Azure Databricks Terraform SRA fornece modelos de infraestrutura como código como ponto de partida para esse padrão de implantação.

Validação

Depois de implantar a arquitetura, execute as verificações a seguir para confirmar se o isolamento de rede completo, a conectividade privada e os controles de saída funcionam conforme configurado.

Verificação	Resultado esperado
Workspace acessível via VPN	Yes
Espaço de trabalho acessível sem VPN	No
Clusters são iniciados usando SCC	Sim, sem IPs públicos
Acesso a dados por meio de conexões privadas	Yes
Saída bloqueada sem aprovação de firewall	Yes
O DNS é resolvido para IPs privados	Yes

Troubleshooting

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

Issue	Cause	Resolução
O cluster não inicia	Firewall bloqueando os endpoints necessários ou endpoints privados mal configurados para o SCC, o plano de controle do Azure Databricks ou as contas de armazenamento (regras de NSG, roteamento)	Revise os logs do firewall e adicione as regras de infraestrutura do Azure Databricks; verifique se as regras de NSG do endpoint privado permitem tráfego proveniente das sub-redes do cluster; verifique as UDRs
Falha na resolução de DNS	DNS privado configurado incorretamente	Verificar zonas DNS privadas e links de VNet
Falha no acesso ao armazenamento	Problema de ponto de extremidade privado ou de roteamento	Verificar a configuração do ponto de extremidade privado e as tabelas de rotas
Falha na instalação do pacote	PyPI bloqueado pelo firewall	Adicionar o PyPI à lista de permissões do firewall

Manutenção contínua

• Regras de firewall: examine e atualize listas de permissões de saída regularmente.
• Gerenciamento de DNS: atualize os registros ao adicionar workspaces.
• Monitoramento de endpoint: acompanhe a integridade do endpoint privado e os custos de transferência de dados.
• Políticas de rede: Adicionar endpoints privados para novas fontes de dados aprovadas.
• Remover firewall: se a sobrecarga operacional do firewall for muito alta ou os requisitos de conformidade relaxarem, você poderá remover o componente de firewall e manter a conectividade privada e o acesso à VPN.
• Fazer downgrade para conectividade reforçada: Se o acesso ao espaço de trabalho privado passar a ser um obstáculo à produtividade.

Próximas Etapas 

Recurso	Description
Proteção contra exfiltração de dados	Arquitetura de referência detalhada para combinar controles de rede e do Catálogo do Unity para impedir a exfiltração de dados.
Relacionamento em Rede	Opções e conceitos de rede para Azure Databricks.