Fase 4: Projetar a arquitetura de rede
Nesta fase, você projeta a infraestrutura de rede para o espaço de trabalho Databricks , incluindo padrões de arquitetura, opções de conectividade e controles de segurança.
Entenda a rede Databricks
A arquitetura de rede no Databricks rege três caminhos de comunicação distintos:
- Conectividade de entrada (front-end) : Acesso do usuário ao console de administração e ao espaço de trabalho por meio da interface do usuário e APIs.
- Conectividade de saída (serverless) : Conexões de carga de trabalho do ambiente compute serverless do Databricks para o recurso do seu cliente.
- Conectividade clássica (back-end) : Garante conexões seguras do plano compute clássico para o plano de controle.
A forma como a segurança da rede é aplicada depende diretamente do modelo compute :
- computeclássica : Execução de cargas de trabalho em redes cloud gerenciadas pelo cliente, portanto, a postura da rede é implementada principalmente por meio de segmentação gerenciada pelo cliente, roteamento, conectividade privada e controles de saída.
- computesem servidor : a execução de cargas de trabalho ocorre em um plano compute Databricks-gerenciar, permitindo que os administradores dependam mais dos controles da plataforma e das configurações em nível accountpara governar a conectividade, principalmente o acesso de saída, mantendo o alinhamento com o mesmo modelo de risco e os requisitos da rede corporativa.
Os administradores devem view esses controles de rede como complementares aos limites workspace e às proteções em nível workspace . Os controles do espaço de trabalho definem as operações do usuário e os padrões de execução permitidos, enquanto os controles de rede restringem a acessibilidade e os caminhos de movimentação de dados. Ao utilizar ambas as camadas de proteção, as organizações podem reduzir o impacto de um ataque de segurança e evitar a dependência excessiva de uma única camada de controle.
Projetar configuração de rede privada virtual
Databricks oferece opções de rede flexíveis para se adequar à postura de segurança e compliance da sua organização, tanto em arquiteturas compute clássicas quanto em arquiteturas serverless .
Gerenciar cloud privada virtual para espaço de trabalho clássico
Os espaços de trabalho clássicos Databricks são implantados em uma cloud privada virtual ( cloud) em seu ambiente cloud . Para obter o máximo controle, Databricks recomenda o uso de redes virtuais gerenciadas pelo cliente para seu espaço de trabalho clássico. Este modelo proporciona o maior controle sobre a topologia da rede, intervalos de sub-redes e grupos de segurança, o que é essencial para atender aos rigorosos requisitos de segurança e compliance .
compute sem servidor (Conectividade Databricks-gerenciar)
Para recursos compute serverless (como um data warehouse SQL serverless ), Databricks gerencia a rede do plano compute , oferecendo simplicidade operacional e redução da sobrecarga administrativa. No entanto, esse modelo ainda oferece um controle robusto sobre a segurança e o acesso ao plano de dados:
- Acesso seguro (entrada/saída) : recursos como conectividade segura cluster e Private Link garantem a comunicação privada entre seu workspace, compute e fonte de dados, independentemente do modelo compute .
- Conectividade privada sem servidor : As Configurações de Conectividade de Rede (NCC) permitem definir regras de saída para compute serverless Databricks , oferecendo controle granular sobre para onde o tráfego do seu plano compute é direcionado.
Essa abordagem em camadas permite selecionar o equilíbrio ideal entre simplicidade operacional e controle granular da rede para diversas cargas de trabalho dentro da sua arquitetura lakehouse.
Conectividade segura de cluster (SCC)
A conectividade segura cluster (SCC) tornou-se a recomendação default e é o modo de implantação default para o espaço de trabalho. O SCC inverte a chamada do plano de controle para o plano compute :
Cada cluster inicia uma conexão com o relay SCC no plano de controle, estabelecendo um túnel de comunicação seguro. O plano de controle então envia a tarefa de administração cluster de volta para o cluster através desse túnel. Consequentemente, não são necessárias portas abertas nem endereços IP públicos nos nós do plano compute clássico. Toda a comunicação do plano compute clássico para o plano de controle é de saída.
Benefícios da arquitetura SCC
- Não são necessários endereços IP públicos nos nós compute .
- Não são necessárias portas de entrada nos grupos de segurança compute .
- Postura de segurança de rede simplificada.
- Superfície de ataque reduzida para recursos compute .
Melhores práticas para SCC
- Ativar SCC para todos os novos espaços de trabalho (default).
- Utilize o SCC como postura de segurança básica.
- O SCC é compatível com Private Link e outros recursos avançados de rede.
Projetar estratégia de controle de acesso IP
Configure listas de acesso IP para restringir os endereços IP que podem se conectar ao Databricks, verificando se o usuário ou cliente da API está vindo de um intervalo de endereços IP "bons" conhecidos, como uma VPN ou rede corporativa. As sessões de usuário estabelecidas não funcionam se o usuário mudar para um endereço IP "ruim", como ao se desconectar da VPN.
níveis da lista de acesso IP
- Listas de acesso IP em nível de espaço de trabalho : Aplicadas a espaços de trabalho individuais.
- Listas de acesso IP em nível de conta : Aplicadas a todos os espaços de trabalho da account e ao acesso ao console account .
padrões de lista de acesso IP
- VPN corporativa : Permitir acesso somente a partir de intervalos de IP da VPN corporativa.
- Redes de escritório : Permitem o acesso a partir de locais específicos do escritório.
- Redes de provedores de nuvem : Permitem o acesso a partir de regiões cloud ou VPCs específicas.
- Abordagem híbrida : Combinar vários intervalos de IP para diferentes tipos de usuários.
Melhores práticas para listas de acesso IP
- Comece com listas de acesso IP em nível accountpara garantir a aplicação consistente das regras.
- Utilize listas de nível workspacepara requisitos específicos workspace .
- Documente os intervalos de IP e suas finalidades.
- Planeje cenários de trabalho remoto (requisitos de VPN).
- Testar as listas de acesso IP antes da implementação completa.
Projetar proteção contra exfiltração de dados
A proteção contra exfiltração de dados no espaço de trabalho pode ser configurada protegendo a rede, restringindo o roteamento e adicionando um firewall de rede para restringir o acesso de saída do espaço de trabalho.
Padrões de proteção contra exfiltração de dados
- Segmentação de rede : implantação de espaço de trabalho em clouds privadas virtuais isoladas.
- Filtragem de saída : Utilize firewalls de rede para controlar o tráfego de saída.
- Conectividade privada : Use o link privado para evitar a exposição na internet.
- Recurso do espaço de trabalho : Desative recursos que possam vazar dados (por exemplo, exportação de Notebook, botões download de dados).
Melhores práticas para proteção contra exfiltração de dados
- Avalie as proteções contra exfiltração de dados com base na sensibilidade dos dados.
- Utilize o Link Privado para ambientes altamente sensíveis.
- Configure os firewalls de rede para permitir apenas os destinos necessários.
- Desative o recurso workspace que possa permitir a exfiltração de dados.
Para obter orientações detalhadas sobre a configuração da exfiltração de dados, consulte a seção Rede.
Estratégia de Design de Link Privado
O Private Link permite a conectividade privada entre as redes virtuais e on-premises dos provedores cloud e o serviço desses cloud , evitando assim a exposição à internet pública.
Arquitetura de link privado
- Link privado de front-end : Conectividade privada com a interface do usuário e APIs workspace .
- Link privado de back-end : Conectividade privada do compute ao serviço do plano de controle.
O recurso Private Link só é compatível com o nível workspace . As listas de acesso IP podem continuar a proteger o serviço em nível account .
Melhores práticas para links privados
- Utilize o Link Privado para espaços de trabalho com dados altamente sensíveis.
- Habilite o Private Link tanto no front-end quanto no back-end para obter o máximo isolamento.
- Planeje a configuração de DNS para o endpoint do Private Link.
- Teste a conectividade do link privado antes de utilizá-lo em produção.
Projetar conectividade serverless (NCC)
execução de recurso compute sem servidor no plano compute serverless , que é gerenciado pelo Databricks. Os administradores de contas podem configurar a conectividade segura entre o plano compute serverless e seus recursos usando as Configurações de Conectividade de Rede (NCC).
Capacidades do NCC
- IPs estáveis : Para inclusão na lista de permissões do firewall.
Arquitetura NCC
Os administradores de contas criam NCCs no console account , e cada NCC pode ser associado a um ou mais espaços de trabalho. Quando um NCC é conectado a um workspace, compute serverless nesse workspace utiliza a configuração de rede do NCC para estabelecer conexões de saída seguras com os recursos do cliente. O mecanismo específico depende do provedor cloud , conforme descrito nas funcionalidades acima.
O NCC não afeta a conectividade de entrada para recursos serverless .
Melhores práticas para NCC
- Crie NCCs separados para diferentes ambientes (por exemplo, desenvolvimento, teste e produção).
- Crie NCCs separados para diferentes unidades de negócios quando o isolamento for necessário.
- Utilize NCCs para controlar a saída de dados serverless para recursos do cliente.
- Adicione à lista de permissões os intervalos de IP da NCC nos firewalls de armazenamento e nos bancos de dados.
Arquitetura de rede da AWS
Configuração básica da VPC
Para uma implantação clássica AWS com recursos compute implantados em uma VPC na account AWS do cliente, a arquitetura principal requer:
Requisitos de sub-rede
- Pelo menos duas sub-redes, cada uma definida em uma zona de disponibilidade (AZ) diferente dentro da região cloud AWS .
- Dedique sub-redes para a implantação de instâncias EC2 de clusters Spark e SQL Server Warehouse.
- O Databricks atribui dois endereços IP por nó (instância EC2):
- Uma delas é utilizada para o tráfego de gerenciamento: orquestração, monitoramento e comunicações do plano de controle.
- Uma utilizada pelo contêiner Spark para tráfego de aplicativos dentro do cluster.
Dimensionamento de sub-rede
Databricks não limita as máscaras de rede para a VPC workspace , mas cada sub-rede workspace deve ter uma máscara de rede entre /17 e /26. O número total de instâncias para cada sub-rede é igual à metade do número de endereços IP disponíveis, após a remoção dos cinco endereços IP reservados em uma sub-rede.
Tamanho do VPC (CIDR) | Tamanho da sub-rede (CIDR) | Máximo de nós de cluster do Databricks por sub-rede/AZ |
|---|---|---|
| /17 | 16.381 (= (32.768-5) // 2) |
| /21 | 2.045 (= (4.096-5) // 2) |
| /26 | 29 (= (64-5) // 2) |
Configuração da tabela de rotas
As tabelas de roteamento associadas a essas sub-redes devem conter rotas para:
- ServiçoS3 : Instale o endpoint VPC do Gateway S3 na VPC e especifique as sub-redes durante a instalação.
- Acesso à Internet : Direcione para 0.0.0.0/0 com o gateway NAT (ou firewall de rede) como destino.
Tipo de interface: endpoint VPC
Instale um endpoint VPC do tipo interface (baseado em PrivateLink) para acessar de forma privada os serviços STS e Kinesis da AWS em uma sub-rede separada e menor (uma por zona de disponibilidade). Os grupos de segurança associados a esses endpoints devem permitir o acesso de entrada dos grupos de segurança associados aos clusters Databricks .
Caso seja estritamente necessário o acesso privado ao serviço S3 , também será preciso instalar uma interface do tipo endpoint VPC S3 . No entanto, isso tem um custo elevado, pois os endpoints VPC do tipo interface cobram pela quantidade de dados que trafegam por eles. A menos que seja estritamente necessário por motivos compliance , prefira o endpoint de gateway S3 VPC , que é gratuito.
Configuração do Gateway NAT
Estabeleça o acesso à internet instalando um gateway NAT em uma sub-rede separada. Para acesso à internet de alta disponibilidade, implante um gateway NAT (e sub-rede) em cada zona de disponibilidade usada pelas sub-redes das instâncias compute do Databricks . A tabela de roteamento para essas sub-redes deve incluir uma entrada para 0.0.0.0/0, direcionando o tráfego para o Gateway da Internet conectado à VPC.
Firewall de rede (opcional)
Se você precisar de um firewall de rede para proteção contra exfiltração de dados, instale-o em sub-redes dedicadas (uma por zona de disponibilidade). Configure as tabelas de roteamento para:
- Tabelas de roteamento para sub-redes de gateway NAT: Direcionam o tráfego para a internet (0.0.0.0/0) para o gateway NAT.
- Tabelas de roteamento para sub-redes compute Databricks : Direcionam o tráfego da internet para o ponto de extremidade do firewall de rede.
- Tabelas de roteamento para sub-rede do gateway NAT: Direcione o tráfego para os clusters Databricks através do endpoint do firewall de rede.
compartilhar recurso de rede por múltiplos espaços de trabalho
Você pode compartilhar uma única VPC entre vários espaços de trabalho. Nesse caso, você pode compartilhar as sub-redes para o gateway NAT, o firewall de rede e o endpoint VPC . No entanto, você precisa criar sub-redes diferentes para a implantação do cluster Databricks (um conjunto diferente para cada workspace).
Arquitetura em estrela
Você pode usar uma arquitetura VPC em estrela (hub-and-spoke), onde todos os endpoints VPC , gateways NAT, firewalls e assim por diante são instalados na VPC central (hub). Cada workspace está associado a sub-redes (para iniciar clusters Databricks ) em uma VPC diferente, dentro da mesma account AWS ou em uma conta diferente. As VPCs periféricas estão conectadas à VPC central usando um Gateway de Trânsito.
Controles de segurança de rede por risco
Clientes com dados e cargas de trabalho que apresentam diferentes níveis de risco podem combinar controles workspace e de rede para estabelecer limites operacionais claros, reutilizando a governança compartilhada e os serviços da plataforma. Um limite workspace é uma maneira eficaz de separar domínios e ambientes (como Desenvolvimento vs. Produção) e de aplicar controles com escopo workspace . Os controles de rede fornecem, então, uma camada de aplicação independente que restringe onde as cargas de trabalho podem ser executadas e quais destinos elas podem alcançar, incluindo o acesso a serviços internos e à internet pública.
Exemplo de modelo workspace em camadas
Cargas de trabalho de maior risco são colocadas em ambientes de conectividade mais restritivos. Os espaços de trabalho alinhados a classificações de risco restritas são implantados em configurações VPC/VNet mais rigorosas e limitados a destinos de saída aprovados, como repositórios privados e serviços internos. Cargas de trabalho de menor risco podem operar em ambientes de rede menos restritivos, preservando a velocidade de desenvolvimento e um acesso mais amplo aos pacotes.
Este modelo permite que os administradores ajustem os controles em várias camadas:
- Controles em nível de espaço de trabalho : Defina "quem pode fazer o quê" dentro do workspace (restrições de acesso e execução).
- Controles em nível de rede : Defina "onde as cargas de trabalho podem se conectar" (restrições de VPC/VNet e controles de saída).
O objetivo do projeto não é "escolher a camada certa", mas sim aplicar controles complementares. Utilize o espaço de trabalho para criar limites administrativos claros e reduzir o impacto entre ambientes. Utilize segmentação de rede e controles de saída para impor restrições de conectividade que permaneçam eficazes mesmo quando os usuários têm amplas capacidades dentro de um workspace.
Para espaços de trabalho serverless , o mesmo princípio se aplica, mas a superfície de controle passa de construções de rede gerenciadas pelo cliente para controles de plataforma, como políticas de controle de saída serverless .
Recomendações de arquitetura de rede
Recomendado
- implantou espaço de trabalho em redes virtuais gerenciadas pelo cliente para máximo controle.
- As sub-redes devem ter pelo menos /26, mas a maioria dos casos de uso exige pelo menos /23 (consulte os detalhes de dimensionamento acima).
- Alinhe o NCC serverless às configurações de VNet/VPC gerenciadas pelo cliente.
- Utilize listas de acesso IP para restringir o acesso a intervalos de IP conhecidos.
- Utilize uma arquitetura em estrela (hub-and-spoke) para recursos de rede compartilhados em vários espaços de trabalho.
- Planeje alta disponibilidade implantando recursos em múltiplas zonas de disponibilidade.
Avaliar com base nos requisitos
- Para clientes com políticas rigorosas de segurança de rede:
- Avalie proteções adicionais contra a exfiltração de dados.
- Considere usar o Private Link para cargas de trabalho altamente sensíveis.
- Configure os firewalls de rede para controlar o tráfego de saída.
Resultados da Fase 4
Após concluir a Fase 4, você deverá ter:
- Arquitetura de rede projetada para espaço de trabalho ( cloud privada virtual gerenciada pelo cliente).
- Estratégia de conectividade segura de cluster (SCC) definida.
- Estratégia de controle de acesso IP projetada.
- Avaliação da proteção contra exfiltração de dados (para cargas de trabalho sensíveis).
- Estratégia de link privado definida (se necessário para compliance).
- Conectividade sem servidor (NCC) projetada para cargas de trabalho serverless .
- Arquitetura de rede específica para nuvem (AWS/Azure/GCP).
- Arquitetura de rede em estrela avaliada.
- Controles de segurança de rede alinhados aos níveis de risco.
- O dimensionamento da sub-rede foi calculado com base nos tamanhos esperados cluster .
Próxima fase : Fase 5: Projetar a arquitetura de armazenamento
Orientações de implementação : Para obter instruções passo a passo sobre como implementar seu projeto de rede, consulte Redes.