Ambiente isolado

A arquitetura de ambiente isolado herda a base de conectividade reforçada e acrescenta dois requisitos: acesso ao espaço de trabalho privado e um firewall externo obrigatório. O acesso ao espaço de trabalho é bloqueado por VPN ou Private Link de entrada, nunca pela internet pública. Toda a saída de computação clássica passa através do firewall para inspeção e aplicação de políticas.

Esta arquitetura tem:

• Isolamento total da rede: Todo o tráfego passa por ligações privadas.
• Acesso ao espaço de trabalho privado: apenas VPN ou Private Link de entrada. O espaço de trabalho está inacessível a partir da internet pública.
• Inspeção obrigatória de saída: Inspeção de firewall de todo o tráfego de saída de computação clássica.
• Prevenção da exfiltração de dados: Os controlos da camada de rede bloqueiam a transferência não autorizada de dados.

Use esta arquitetura quando:

• O acesso ao espaço de trabalho deve ser privado, como via VPN ou Private Link de entrada.
• Gestão de dados em indústrias altamente reguladas, por exemplo serviços financeiros, saúde, governo.
• Os frameworks de conformidade exigem controlos de saída (por exemplo, SOC 2, HIPAA, PCI DSS e FedRAMP).
• Implementação de estruturas empresariais de segurança zero-trust.
• A prevenção da exfiltração de dados é um requisito.

Pré-requisitos

• Azure Azure Databricks nível Premium com um espaço de trabalho injetado por VNet.

• Infraestrutura VPN existente ou conectividade de entrada do Private Link.
• Firewall ou appliance virtual de rede (NVA).

Descrição geral da arquitetura

A arquitetura do ambiente isolado encaminha todo o tráfego através de ligações privadas com inspeção do firewall:

Componentes necessários

Inbound

O Workspace só é acessível através de ligações privadas: VPN, Private Link de entrada, ou ambos, dependendo da tua infraestrutura existente. Normalmente, os clientes escolhem apenas um em vez de os combinarem.

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

Este é o controlo de acesso que efetivamente bloqueia o acesso público. Sem isso, o espaço de trabalho ainda aceita tráfego da internet mesmo com o Private Link configurado. Private Link torna-se um caminho adicional, não o único.

Defina o Acesso à Rede Pública do workspace para Desabilitado no portal Azure. Isto bloqueia o acesso público à interface e APIs do workspace.

Controlos de entrada do espaço de trabalho

Configure o acesso de entrada da área de trabalho através do acesso de entrada baseado no contexto (CBI), a estrutura de políticas de acesso de entrada recomendada. As regras CBI combinam a fonte da rede (intervalos de IP), identidade, mecanismo de autenticação e âmbito de acesso num único modelo de permitir/negar, de modo que o atributo fonte de rede cumpre o mesmo papel da funcionalidade autónoma de lista de acesso IP, e mais.

As listas de acesso IP continuam a ser suportadas e podem ser configuradas juntamente com o CBI. Quando ambos estão configurados, uma solicitação tem de ser autorizada por ambos os controlos.

Níveis de configuração:

• Políticas CBI ao nível da conta: Aplicam-se a todos os espaços de trabalho da conta. Veja Gerir políticas de entrada com base no contexto.
• Listas de acesso IP ao nível do espaço de trabalho: Candidate-se a um único espaço de trabalho. Consulte Configurar listas de acesso IP para espaços de trabalho.
• Listas de acesso IP da conta: Aplicam-se à consola da conta. Consulte Configurar listas de acesso IP para o console da conta.

Melhores práticas:

• Começa de forma geral, refina com base no uso real.
• Documente os intervalos de IP com finalidade e datas de validade.
• Manter o acesso de administrador através de um intervalo de IP conhecido como bom.
• Revise trimestralmente e remova os intervalos obsoletos.

Advertência

Políticas de entrada e listas de acesso IP podem bloqueá-lo do seu espaço de trabalho se estiverem mal configurados. Mantenha sempre o acesso de administrador através de um intervalo de IP conhecido como bom.

Controlo de acesso dos destinatários do OpenSharing

O OpenSharing utiliza as suas próprias listas de acesso IP configuradas em objetos destinatários. Isto é separado das listas de acesso IP ao workspace e não é coberto pela entrada baseada no contexto. Aplica-se apenas à partilha Databricks-to-Open (destinatários que não sejam do Azure Databricks).

Veja Restringir o acesso do destinatário do Open Sharing através de listas de acesso IP (Databricks-to-Open Sharing).

Conectividade de entrada

Estabelece conectividade privada para o acesso dos utilizadores à interface e API do espaço de trabalho. Os utilizadores acedem ao espaço de trabalho via VPN ou Private Link de entrada, nunca pela internet pública.

Veja Configurar Ligação Privada de Entrada.

DNS personalizado

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

O Azure cria automaticamente zonas DNS privadas ao criar endpoints privados.

Outbound

Os controlos de saída sem servidor (políticas de rede e endpoints privados NCC) são herdados da referência conectividade reforçada. Esta arquitetura torna o firewall externo, opcional no Harddened, necessário para a inspeção clássica completa de saída de computação.

Firewall externo (obrigatório)

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

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

Tip

Utilize políticas de ponto final de serviço no armazenamento de artefactos do Azure Databricks para contornar a firewall, reduzindo os custos de transferência de dados. O armazenamento de artefactos por si só pode contabilizar até 11 GB descarregados por nó do cluster.

Consulte Endereços IP e domínios dos serviços e ativos do Azure Databricks para conhecer os pontos finais necessários do Azure Databricks que as regras de firewall têm de permitir.

Tip

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

Advertência

O plano de controlo do Azure Databricks e as ligações de relé SCC usam TLS com associação de certificados. Não ative a inspeção TLS (desencriptação e reencriptação) no tráfego entre os seus clusters e o plano de controlo do Azure Databricks. Fazer isso provoca falhas no cluster. Configure regras de firewall para permitir estas ligações por destino, FQDN ou IP sem interceção TLS. Consulte Endereços IP e domínios dos serviços e ativos do Azure Databricks para conhecer os pontos finais necessários.

Importante

Regras de firewall incorretamente configuradas podem quebrar as capacidades do Azure Databricks. Teste cuidadosamente num ambiente sem produção.

Proteção contra exfiltração de dados

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

• Controlo de tráfego de saída sem servidor através de políticas de rede.
• Saída clássica via firewall/NVA.
• Regras de ponto final privado para destinos de dados aprovados.

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

Linha base clássica de computação

A linha base clássica de computação é herdada da segurança gerida, e os endpoints de serviços cloud são herdados da conectividade reforçada. Não são necessários componentes de computação clássicos adicionais para esta arquitetura.

A base inclui injeção de VNet, Secure Cluster Connectivity (SCC) e o clássico Private Link. Os endpoints de serviço cloud incluem rotas definidas pelo utilizador (UDRs), endpoints de serviço e endpoints privados para contas de armazenamento geridas pelo cliente.

Abordagens de saída para acesso a dados

Existem duas abordagens para gerir o acesso a dados de saída a partir de recursos de computação:

• Gateway NAT com firewall: Implante um gateway NAT para conectividade de saída e encaminhe o tráfego através de um firewall para inspeção. Esta abordagem permite o acesso controlado a repositórios externos de pacotes e APIs e mantém a visibilidade dos padrões de tráfego. Utilize esta abordagem quando tiver de aceder a recursos externos, mas necessitar de inspeção e registo.

• Sem gateway NAT (totalmente privado): Remova completamente o gateway NAT para eliminar toda a comunicação pública dos recursos de computação. Todo o acesso aos dados ocorre apenas através de endpoints privados e endpoints VPC. Esta abordagem tem o mais elevado nível de segurança ao eliminar a possibilidade de exfiltração de dados por caminhos públicos de saída. Use esta abordagem quando a sua organização proibir qualquer comunicação pública na internet através de recursos computacionais.

Implementation

Comece com base numa configuração de base de conectividade reforçada implementada. As fases seguintes adicionam o acesso ao espaço de trabalho privado e o firewall externo necessário que definem esta arquitetura.

Fase 1: Controlos de entrada

1. Configure o Private Link de entrada para que o acesso dos utilizadores à interface do utilizador e às APIs do Azure Azure Databricks seja encaminhado através de uma ligação privada, em vez de através de IPs públicos. Veja Configurar Ligação Privada de Entrada.
2. Defina o Acesso à Rede Pública do workspace para Desabilitado no portal Azure. É isto que realmente bloqueia a entrada pública. Sem isso, o espaço de trabalho ainda aceita tráfego da internet mesmo com o Private Link de entrada configurado.
3. Teste o acesso dos utilizadores via VPN ou Private Link para confirmar que os utilizadores autenticados só conseguem aceder ao espaço de trabalho pelo caminho da rede privada, e que o acesso público está bloqueado.

Fase 2: Firewall externo (obrigatório)

1. Implemente o Azure Firewall ou um dispositivo virtual de rede de terceiros (NVA) num hub VNet e conecte o VNet do espaço de trabalho usando peering VNet ou um hub virtual.
2. Configure rotas definidas pelo utilizador (UDRs) nas subredes do workspace com uma rota padrão para o firewall, para que o tráfego de saída dos recursos de computação do Azure Databricks flua através do firewall do hub. Consulte Configurações de rota definidas pelo usuário para o Azure Databricks.
3. Configurar as regras de aplicação e de rede do Azure Firewall para permitir apenas os pontos finais do Azure Databricks necessários (consulte os endereços IP e domínios dos serviços e recursos do Azure Databricks) sem interceção TLS no tráfego do plano de controlo nem no tráfego de retransmissão SCC.

Fase 3: Validação

1. Verifique o controlo de saída revisando os logs e diagnósticos do Azure Firewall para verificar se o tráfego do Azure Databricks é inspecionado e limitado de acordo com a política.
2. Confirme se não foram atribuídos endereços IP públicos nem aos nós do cluster nem a outros recursos de computação geridos pelo Azure Databricks na VNet da área de trabalho.
3. Verifique que todo o tráfego de controlo, de dados e de entrada passa pelos pontos finais do Private Link configurados e pela firewall do hub, conforme previsto.

O Azure Databricks Terraform SRA fornece modelos de Infraestrutura como Código como ponto de partida para este padrão de implementação.

Validation

Depois de implementar a arquitetura, execute as verificações seguintes para confirmar que o isolamento total da rede, a conectividade privada e os controlos de saída funcionam conforme configurados.

Troubleshooting

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

Manutenção contínua

• Regras de firewall: Revê e atualiza regularmente as listas de permissão de saída.
• Gestão DNS: Atualize registos quando adiciona espaços de trabalho.
• Monitorização de pontos finais: Acompanhar o estado de funcionamento dos pontos finais privados 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 demasiado elevada ou os requisitos de conformidade relaxarem, pode remover o componente do firewall e manter a conectividade privada e o acesso VPN.
• Rebaixe para conectividade reforçada: Se o acesso a espaços de trabalho privados se tornar uma barreira de produtividade.

Passos seguintes