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 (VPC) 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 Serviço Connect garantem 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 o serviço privado Connect 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 do espaço de trabalho em VPCs isoladas.
• Filtragem de saída : Utilize firewalls de rede para controlar o tráfego de saída.
• Conectividade privada : Utilize o serviço Connect privado para evitar a exposição da sua conexão à 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 serviço privado Connect 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.

Design Private serviço Connect estratégia

O serviço privado Connect permite a conectividade privada entre as redes virtuais e on-premises dos provedores cloud e o serviço do provedor cloud , evitando assim a exposição à internet pública.

Serviço privado Conectar arquitetura

• Serviço privado de front-end Connect : Conectividade privada com a interface do usuário e APIs workspace .
• Conexão de serviço privado de back-end : Conectividade privada do compute ao serviço de plano de controle.

O serviço privado Connect 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 conexão de serviço privado

• Utilize o serviço privado Connect para espaços de trabalho com dados altamente sensíveis.
• Habilite o serviço privado Connect tanto no front-end quanto no back-end para obter o máximo isolamento.
• Planeje a configuração de DNS para o endpoint Connect do serviço privado.
• Teste a conectividade do serviço privado Connect 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

• IDs de projeto estáveis : Para VPC Service Controls.

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.

nota

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 do GCP

Cada nó cluster utiliza dois IPs da sub-rede: um para a comunicação interna cluster e outro para a comunicação externa (em direção ao plano de controle/fonte de dados).

Dimensionamento de sub-rede

O espaço de endereçamento precisa ser de pelo menos /26, e a tabela a seguir resume o tamanho de rede necessário com base no número previsto de nós no workspace:

Tamanho da sub-rede dos nós	Número máximo de nós Databricks por workspace
/25	60
/20	2.000
/19	4.000

configuração da zona de computação

A zona de computação e/ou a alta disponibilidade podem ser configuradas como uma configuração cluster . A configuração 'automática' indica uma alocação automática para uma zona decidida dinamicamente pelo GCP.

Acesso privado ao Google

O acesso compute clássico e sem servidor aos serviços integrados do Google ocorre por meio do Acesso Privado do Google (PGA). Na compute clássica, isso exige que APIs da PGA sejam acessíveis (e estejam na lista de permissões do firewall) dentro da sub-rede do nó.

NATGateway

O acesso à internet é estabelecido através da instalação de um gateway NAT, geralmente em uma sub-rede separada. 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 de Internet default anexado à VPC. Isso é necessário para a comunicação com o plano de controle, a menos que o serviço Private Connect (PSC) seja utilizado.

VPC compartilhada

A implantação em uma VPC compartilhada é suportada. Os nós residem dentro do projeto de serviço, enquanto os artefatos de rede (NAT e roteador ou endpoint PSC, dependendo do modo de implantação) residem dentro do projeto host.

VPC Service Controls

Determinadas implementações seguras GCP utilizam VPC Service Controls (VPC-SC). Databricks pode ser executado dentro de seu próprio perímetro de serviço ou compartilhar um com outro recurso, que pode diferir do perímetro da fonte de dados. O princípio de implantação é que o plano de controle gerencia o plano compute , e identidades de ambos os planos precisam gerenciar os dados. Consequentemente, os controles VPC-SC necessários variam de acordo com a implementação e podem mudar ao longo do tempo. Embora uma configuração fixa de "privilégio mínimo" com SLA ainda não esteja disponível, um guia de configuração é fornecido.

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 serviço privado Connect 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 ( VPC de gerenciamento de clientes).
• 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 conexão de serviço 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.