Conectividade reforçada

A conectividade reforçada baseia-se na Segurança gerenciada para adicionar controles em camadas de entrada e saída: ingresso baseado em contexto (CBI), pontos de extremidade de VPC, controles de saída para ambiente sem servidor e um firewall externo opcional. O acesso ao espaço de trabalho permanece na internet pública, protegido pelo CBI.

Essa arquitetura tem:

  • Acesso ao workspace com base no contexto: Os usuários fazem login pela internet, e as políticas de CBI restringem o acesso ao workspace por origem da rede, identidade, mecanismo de autenticação e escopo de acesso. Essa é uma troca de simplicidade em comparação com arquiteturas fechadas por VPN.
  • Acesso ao serviço de nuvem privada: pontos de extremidade VPC (AWS) ou pontos de extremidade de serviço (Azure) mantêm o tráfego do serviço de nuvem fora da Internet pública.
  • Controle de saída sem servidor: políticas de rede e pontos de extremidade privados NCC regem o tráfego de saída da computação sem servidor.
  • Inspeção de saída opcional: implante um firewall externo para inspecionar e registrar a saída de computação clássica.
  • Nenhuma VPN necessária: acesso simplificado ao usuário sem dependência de rede corporativa.

Use essa arquitetura quando:

  • A segurança de dados é a principal preocupação, não o controle de acesso do workspace.
  • A complexidade da VPN é uma barreira à produtividade do usuário.
  • Controles de acesso baseados em IP são suficientes para conformidade.
  • Sua organização prefere padrões de acesso na nuvem primeiro.

Pré-requisitos

  • Nível Premium do Azure Databricks com um workspace injetado em uma VNet.
  • Lista de intervalos de IP para controle de acesso ao espaço de trabalho.

Visão geral da arquitetura

A arquitetura de conectividade protegida 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 de CBI → Espaço de trabalho
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 (opcional) → Internet inspecionada

Observação

O acesso ao workspace não é privado nesta arquitetura. Os usuários se conectam pela Internet pública, restritos por políticas do CBI. Se sua organização exigir acesso a um espaço de trabalho privado, use a arquitetura de ambiente isolado.

Componentes necessários

Inbound

Não há Link Privado de entrada. O acesso à Internet pública é restrito por políticas de entrada baseadas em contexto e, opcionalmente, listas de acesso IP. Siga o IAM padrão para autenticação. Consulte Autenticação e controle de acesso.

Ícone de escudo do usuário. Controles de acesso 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:

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.

Ícone de compartilhamento bloqueado. Controle de acesso do destinatário no OpenSharing

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

Consulte Restringir o acesso do destinatário do OpenSharing usando listas de acesso de IP (compartilhamento Databricks-to-Open).

Saída

O tráfego de saída sem servidor é controlado por políticas de rede e pontos de extremidade privados do NCC. Use o Unity Catalog para governança do acesso de saída aos dados. Veja O que é o Catálogo do Unity?.

Ícone de filtro. Controle de saída sem servidor

Configure políticas de rede para controlar o tráfego de saída de computação sem servidor. Defina destinos permitidos usando intervalos de IP ou FQDNs.

Veja O que é o controle de saída sem servidor?.

Ícone de link. Link Privado Serverless (endpoints privados do NCC)

Fornece conectividade privada da computação sem servidor para seus recursos por meio de Link Privado. O tráfego de dados sem servidor fica fora da Internet pública.

Consulte Configuração de conectividade privada para recursos do Azure.

Linha de base de computação clássica

A linha de base de computação clássica é herdada da segurança gerenciada. Nenhum componente de linha de base adicional é necessário, mas opcionalmente você pode adicionar um firewall externo para inspecionar a saída de computação clássica.

A linha de base inclui injeção de VNet, SCC (Conectividade de Cluster Seguro) e Link Privado clássico.

Observação

Essa arquitetura não usa Link Privado de entrada. Os usuários acessam o workspace pela Internet pública, controlado pelas políticas do CBI. Se sua organização exigir acesso a um workspace privado, consulte a arquitetura de ambiente isolado, que adiciona acesso de entrada via Link Privado ou protegido por VPN.

Ícone de link. Link Privado do plano de computação clássico

Fornece conectividade privada entre sua VNet e o plano de controle Azure Databricks. A API REST e o tráfego de retransmissão de SCC entre clusters e o plano de controle permanecem privados em vez de usar a Internet pública.

Consulte Configure a conectividade privada do plano de computação clássico para o Azure Databricks.

Ícone de conexão de setas. Rotas definidas pelo usuário

Configure o roteamento para acesso ao serviço de nuvem para manter o tráfego privado e reduzir os custos.

Configure UDRs usando tags de serviço para os serviços do Azure. Consulte Configurações de rota definidas pelo usuário para o Azure Databricks.

Ícone de escudo. Firewall externo para computação clássica (opcional)

Direcione o tráfego de saída da computação clássica por meio de um firewall externo para inspeção, registro e aplicação de políticas. Necessário no ambiente isolado; opcional aqui.

As opções incluem Firewall do Azure ou uma NVA (solução de virtualização de rede) de terceiros.

Warning

O plano de controle do Azure Databricks e as conexões de retransmissão SCC usam TLS com fixação de certificado. Não habilite a inspeção do TLS (descriptografar e criptografar novamente) no tráfego entre seus clusters e o plano de controle de segurança do Azure Databricks. Fazer isso causa falhas no cluster. Consulte Endereços IP e domínios para serviços e ativos do Azure Databricks para conhecer os pontos de extremidade necessários.

Implementation

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

Fase 1: controle de acesso de entrada

Configurar políticas de entrada baseadas em contexto

Configure políticas de entrada baseadas em contexto (CBI) no nível da conta para restringir o acesso ao workspace por fonte de rede, identidade, mecanismo de autenticação e escopo de acesso. Consulte o controle de entrada baseado em contexto e gerencie políticas de entrada baseadas em contexto.

Configurar listas de acesso IP no nível do workspace (opcional)

Opcionalmente, configure listas de acesso IP no nível do workspace em conjunto com o CBI para compatibilidade com versões anteriores ou substituições no nível do workspace. Quando ambos estão configurados, uma solicitação deve ser permitida por ambos. Veja Configuração de listas de acesso IP para áreas de trabalho.

Configurar listas de acesso IP no nível da conta

Configure listas de acesso IP no nível da conta para controlar o acesso ao console da conta. Consulte Configurar listas de acesso IP para o console da conta.

Configurar listas de acesso IP no nível do destinatário

Se você usar o compartilhamento Databricks-to-Open do OpenSharing, configure listas de acesso por IP no nível do destinatário para cada destinatário do compartilhamento. Consulte Restringir o acesso do destinatário do OpenSharing usando listas de acesso de IP (compartilhamento Databricks-to-Open).

Documentar faixas de IP configuradas

Mantenha a documentação de todos os intervalos de IP configurados, incluindo justificativa, tíquetes vinculados e datas de revisão planejadas.

Verificar o comportamento de acesso

Verifique o comportamento de acesso testando a entrada de intervalos de IP aprovados e confirmando que as conexões de intervalos de IP não aprovados estão bloqueadas.

Fase 2: pontos de acesso do serviço de nuvem

Configurar rotas definidas pelo usuário

Configure UDRs (rotas definidas pelo usuário) usando tags de serviço do Azure para que o tráfego para os serviços do Azure siga pelos caminhos de saída privados ou controlados desejados. Consulte Configurações de rota definidas pelo usuário para o Azure Databricks.

Configure endpoints de serviço ou privados para armazenamento

Configure pontos de extremidade de serviço ou pontos de extremidade privados para contas de armazenamento Azure gerenciadas pelo cliente, conforme necessário.

Fase 3: Controles de saída sem servidor

Configurar políticas de rede sem servidor

Configure políticas de rede sem servidor para restringir o tráfego de saída de computação sem servidor para destinos aprovados usando intervalos de IP ou FQDNs. Veja O que é o controle de saída sem servidor?.

Configurar endpoints privados do NCC

Configure pontos de extremidade privados do NCC para conectividade privada da computação sem servidor para seus recursos de Azure. Consulte Configuração de conectividade privada para recursos do Azure.

Testar saída sem servidor

Teste se as cargas de trabalho sem servidor conseguem acessar destinos aprovados e são impedidas de acessar destinos não aprovados.

Fase 4 (opcional): firewall externo para computação clássica

Implantar um firewall externo

Implante o Firewall do Azure ou uma NVA (solução de virtualização de rede) de terceiros em uma VNet do hub e emparelhe-a com a VNet do workspace.

Encaminhar o tráfego de saída pelo firewall usando UDRs

Configure UDRs nas sub-redes do workspace com uma rota padrão para o firewall.

Configurar regras de firewall sem interceptação de TLS

Configure as regras de firewall para permitir os pontos de extremidade necessários do Azure Databricks sem interceptação de TLS no tráfego do plano de controle de segurança e de retransmissão do SCC.

O Azure Databricks Terraform SRA fornece modelos de Infraestrutura como Código que automatizam essa implantação.

Validação

Depois de implantar a arquitetura, execute as verificações a seguir para confirmar se o tráfego de plano de computação clássico permanece privado e que sua lista de acesso ip restringe o acesso ao workspace conforme configurado.

Verificação Resultado esperado
Espaço de trabalho acessível a partir de IPs permitidos Yes
Espaço de trabalho bloqueado para IPs não autorizados Yes
Clusters são iniciados usando SCC Sim, sem IPs públicos
Acesso a dados por meio de conexões privadas Yes
Instalação de pacotes de repositórios privados de artefatos Yes

Troubleshooting

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

Problema Cause Resolução
Não é possível acessar o workspace IP não está na lista de acesso Adicionar IP à lista de workspaces
O cluster não inicia Configuração incorreta de roteamento ou ponto de extremidade Verificar tabelas de rotas e a conectividade do endpoint privado
Falha no acesso ao S3/ADLS Problema de endpoint da VPC ou de roteamento Verificar a configuração do endpoint e os grupos de segurança
Falha na instalação do pacote Repositório de artefato privado inacessível Verificar a configuração do ponto de extremidade da VNet e a resolução DNS do repositório de artefatos
Problemas de acesso intermitente Endereços IP dinâmicos Usar VPN com IP de saída estático ou ampliar intervalos de IP

Manutenção contínua

  • Gerenciamento de lista de acesso ip: examine mensalmente, adicione novos locais, remova intervalos obsoletos.
  • Monitoramento de endpoint: acompanhe a integridade do endpoint privado e os custos de transferência de dados.
  • Gerenciamento de repositório de artefatos: mantenha espelhos de pacote privados e monitore a disponibilidade.
  • Suporte ao usuário: manter o processo para problemas de acesso IP.

Etapas anteriores e próximas

Architecture Quando escolher
Segurança gerenciada Etapa anterior. Se controles de acesso baseados em IP, pontos de extremidade de VPC e controles de saída para ambientes sem servidor forem mais do que suas cargas de trabalho precisam. A linha de base inclui VNet e SCC gerenciados pelo cliente, com Link Privado clássico opcional.
Ambiente isolado Próxima etapa. Se o controle de acesso baseado em IP for insuficiente, os regulamentos exigirão acesso ao workspace privado ou a conformidade exigirá a prevenção de exfiltração de dados.
  • Last updated on