Conectividade aprimorada

A conectividade reforçada se baseia em segurança gerenciada para adicionar controles de entrada e saída em camadas: entrada baseada em contexto (CBI), endpoints VPC, controles de saída serverless e um firewall externo opcional. O acesso ao workspace permanece na internet pública, restrito pela CBI.

Esta arquitetura tem:

• Entrada de workspace com base em contexto : Usuários fazem login pela internet, e as políticas do CBI restringem o acesso ao workspace com base na origem da rede, identidade, mecanismo de autenticação e escopo de acesso. Este é um compromisso de simplicidade em comparação com as arquiteturas protegidas por VPN.
• Acesso a serviços de cloud privada: endpoints de VPC (AWS) ou endpoints de serviço (Azure) mantêm o tráfego de serviços de cloud fora da internet pública.
• Controle de saída serverless: Políticas de rede e endpoints privados NCC governam o tráfego de saída do serverless compute.
• Inspeção de saída opcional : implante um firewall externo para inspecionar e fazer log a saída de compute clássico.
• Nenhuma VPN necessária: acesso simplificado do usuário sem dependência da rede corporativa.

Use esta arquitetura quando:

• A segurança de dados é a principal preocupação, não o controle de acesso ao workspace.
• A complexidade da VPN é uma barreira para a produtividade dos usuários.
• Controles de acesso baseados em IP são suficientes para compliance.
• Sua organização prefere padrões de acesso com prioridade na cloud.

Pré-requisitos

• Databricks Plano Enterprise.

• Lista de intervalos IP para controle de acesso ao workspace.

Visão geral da arquitetura

A arquitetura de conectividade segura protege o tráfego de rede e simplifica o acesso do usuário:

Tipo de tráfego	Caminho
Acesso do usuário	Usuários → Internet → Política CBI → 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 (opcional) → Internet inspecionada

nota

O acesso ao workspace não é privado nesta arquitetura. Usuários se conectam pela Internet pública, restritos por políticas CBI. Se a sua organização exigir acesso privado ao workspace, use a arquitetura de ambiente isolado em vez disso.

Componentes obrigatórios

Entrada

Sem PrivateLink de entrada. O acesso público à internet é restrito por políticas de entrada baseadas em contexto e, opcionalmente, por listas de acesso IP. Siga o IAM padrão para autenticação. Consulte Autenticação e controle de acesso.

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 é diferente de entrada baseada em contexto e listas de acesso IP do workspace. 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).

Saída

A saída serverless é regida por políticas de rede e endpoints privados da NCC. O egresso do compute clássico pode, opcionalmente, passar por um firewall externo para inspeção. Utilize o Unity Catalog para a governança de dados do acesso a dados de saída. Consulte O que é o Unity Catalog?.

Controle de saída serverless

Configurar políticas de rede para controlar o tráfego de saída de serverless compute. Definir destinos permitidos usando intervalos de IP ou FQDNs.

Consulte O que é controle de saída serverless?.

PrivateLink serverless (endpoints privados da NCC)

Fornece conectividade privada de compute serverless para seus recursos através do PrivateLink. O tráfego de dados serverless permanece fora da internet pública.

Consulte Configurar conectividade privada com recursos gerenciados pela AWS para obter informações sobre conectividade privada com buckets do S3 e Configurar conectividade privada com recursos em sua VPC para obter informações sobre conectividade privada com recursos em sua VPC.

Firewall externo para compute clássico (opcional)

A saída de compute clássico deve ser encaminhada por meio de um firewall externo para inspeção, registro em log e aplicação de políticas. Obrigatório em ambiente isolado; opcional aqui.

As opções incluem AWS Network Firewall (serviço gerenciado, integrado com o roteamento da AWS) ou um appliance de terceiros como Palo Alto integrado com o Gateway Load Balancer.

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. See IP addresses and domains for Databricks services and assets for required endpoints.

Linha de base de compute clássico

A linha de base do compute Classic é herdada de Segurança gerenciada. 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.

nota

Esta arquitetura não usa PrivateLink de entrada. Os usuários acessam o workspace pela internet pública, controlado por políticas de CBI. Se a sua organização exige acesso privado ao workspace, consulte a arquitetura de ambiente isolado, que adiciona PrivateLink de entrada ou acesso restrito por VPN.

Plano de compute clássico PrivateLink

Fornece conectividade privada entre sua VPC e o plano de controle do Databricks. O tráfego de retransmissão da API REST e do SCC entre os clusters e o plano de controle permanece privado em vez de usar a internet pública.

Consulte Configurar conectividade privada clássica ao Databricks.

Endpoints VPC

Configure o roteamento para acesso ao serviço de cloud para manter o tráfego privado e reduzir os custos. Endpoints de gateway da VPC do S3 fornecem acesso ao armazenamento na mesma região sem atravessar a internet pública.

Crie VPC endpoints para S3 (gateway), STS e Kinesis. Consulte Passo 5: Adicionar endpoints de VPC para outros serviços da AWS.

Políticas de endpoint da VPC

Restringir quais buckets S3 seus endpoints de VPC podem acessar. Sem uma política, o endpoint de gateway S3 permite conexões a qualquer bucket S3 em qualquer conta AWS, incluindo buckets externos ou controlados por invasores. Uma política de endpoint de VPC limita o endpoint apenas aos seus buckets aprovados, bloqueando um caminho chave de exfiltração de dados do S3.

Consulte Configurar uma VPC gerenciada pelo cliente para exemplos de políticas em funcionamento e o acesso necessário ao bucket do Databricks.

Políticas de bucket S3

Aplique políticas de bucket para restringir o acesso aos seus buckets S3 do Databricks por VPC de origem ou VPC endpoint. Isso impede o acesso aos seus dados de fora dos seus caminhos de rede aprovados, mesmo que as credenciais sejam comprometidas.

Consulte Configurar uma VPC gerenciada pelo cliente para obter requisitos, exemplos de políticas de trabalho e orientações sobre como emparelhar políticas de bucket com políticas de endpoint da VPC.

Implementação

Comece com uma linha de base de Segurança gerenciada implantada. As fases a seguir adicionam os controles de entrada e saída que definem esta arquitetura.

Fase 1: Controle de Acesso de Entrada

1. Configure políticas de entrada com base no contexto (CBI) no nível da account para restringir o acesso ao workspace por origem de rede, identidade, mecanismo de autenticação e escopo de acesso. Consulte controle de entrada baseado em contexto e gerencie políticas de entrada baseadas em contexto.
2. Opcionalmente, configure listas de acesso IP no nível do workspace juntamente com o CBI para compatibilidade retroativa ou substituições por workspace. Quando ambos são configurados, ambos devem permitir a solicitação. Consulte Configurar listas de acesso IP para workspaces.
3. Configure account-level IP access lists to control access to the account console. Consulte Configurar listas de acesso IP para o console da account.
4. Se você usa o compartilhamento Databricks-to-Open do OpenSharing, configure listas de acesso IP de nível de destinatário em cada destinatário de compartilhamento. Consulte Restringir o acesso do destinatário do OpenSharing usando listas de acesso IP (Databricks para compartilhamento aberto).
5. Documentar cada intervalo de IP configurado com o proprietário, a finalidade e a data de revisão/expiração no seu sistema de gerenciamento de mudanças ou documentação.
6. Teste o acesso de endereços IP permitidos e bloqueados (por exemplo, redes de escritório, VPN e domésticas) para verificar se as políticas de entrada se comportam como esperado.

Fase 2: endpoints de serviço de cloud

1. Crie um gateway de endpoint VPC para S3 e endpoints de interface VPC para STS e Kinesis para que o tráfego de clusters para esses serviços permaneça na rede da AWS. Consulte Passo 5: Adicionar VPC endpoints para outros serviços da AWS.
2. Aplique políticas de endpoint da VPC para restringir quais buckets S3 o endpoint do gateway pode acessar. Consulte Configurar uma VPC gerenciada pelo cliente.
3. Aplique políticas de bucket do S3 para restringir o acesso aos seus buckets S3 do Databricks por VPC de origem ou endpoint de VPC.

Fase 3: controles de saída serverless

1. Configurar políticas de rede serverless para restringir o tráfego de saída do compute serverless a destinos aprovados usando intervalos de IP ou FQDNs. Consulte O que é controle de saída serverless?.
2. Configure os endpoints privados da NCC para conectividade privada de compute serverless para seus buckets S3 e recursos em sua VPC. Consulte Configurar conectividade privada para recursos gerenciados pela AWS e Configurar conectividade privada para recursos na sua VPC.
3. Teste se as cargas de trabalho serverless podem alcançar os destinos aprovados e são bloqueadas dos não aprovados.

Fase 4 (opcional): Firewall externo para compute clássico

1. Implante o AWS Firewall de Rede ou um dispositivo de terceiros e integre-o com sua VPC do workspace.
2. Configure as tabelas de roteamento para enviar 0.0.0.0/0 para o firewall, mantendo o tráfego do endpoint de VPC e do PrivateLink em rotas diretas.
3. Configure as regras de firewall para permitir os endpoints do Databricks necessários (consulte Endereços IP e domínios para serviços e ativos do Databricks) sem intercepção de TLS no plano de controle e no tráfego de retransmissão do SCC.

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

Validação

Após a implantação da arquitetura, execute as seguintes verificações para confirmar que o tráfego do plano de compute clássico permanece privado e que sua lista de acesso IP restringe o acesso ao workspace conforme configurado.

Verificar	Resultado esperado
Workspace acessível por IPs permitidos	Sim
Workspace bloqueado de IPs não autorizados	Sim
Os clusters são iniciados com SCC	Sim, nenhum IP público
Acesso a dados por meio de conexões privadas	Sim
Instalação de pacotes de repositórios de artefatos privados	Sim

Solução de problemas

Se uma verificação de validação falhar ou uma carga de trabalho se comportar inesperadamente, utilize a tabela a seguir para diagnosticar problemas comuns.

Problema	Causa	Resolução
Não é possível acessar o workspace	IP não consta na lista de acesso	Adicionar IP na lista do workspace
Cluster falha ao começar	Configuração incorreta de roteamento ou de endpoint	Verifique as tabelas de roteamento e a conectividade do endpoint privado
Falha no acesso S3/ADLS	VPC endpoint ou problema de roteamento	Verificar a configuração do endpoint e os grupos de segurança
A instalação do pacote falha	Repositório de artefatos privado inacessível	Verifique a configuração de endpoint da VPC e a resolução de DNS para seu repositório de artefatos
Problemas de acesso intermitente	Endereços IP dinâmicos	Usar VPN com IP estático de saída ou expandir os intervalos de IP

Manutenção contínua

• Gerenciamento de listas de acesso IP : Revisar mensalmente, adicionar novos locais, remover intervalos obsoletos.
• Monitoramento de Endpoints : Acompanhe a integridade de endpoints privados e os custos de transferência de dados.
• Gerenciamento de repositórios de artefatos : Manter espelhos de pacotes privados e monitorar a disponibilidade.
• Suporte ao usuário : Manter um processo para problemas de acesso de IP.

Passos anteriores e seguintes

• • Segurança gerenciada
  • Passo anterior. Se os controles de acesso baseados em IP, os endpoints da VPC e os controles de saída serverless forem mais do que suas cargas de trabalho exigem. A linha de base inclui VPC gerenciada pelo cliente e SCC, com PrivateLink clássico opcional.
• • Ambiente isolado
  • Próximo passo. Se o controle de acesso baseado em IP se mostrar insuficiente, as regulamentações exigem acesso privado ao workspace, ou o compliance exigir a prevenção da exfiltração de dados.