Azure Databricks é uma Plataforma Unificada de Análise de Dados que faz parte da Microsoft Azure Cloud. Construído sobre as bases de Delta Lake, MLFlow, Koalas e Apache Spark, o Azure Databricks é um serviço de primeira parte na nuvem Microsoft Azure que oferece configuração com um clique, integrações nativas com outros serviços Azure, espaço de trabalho interativo e segurança de nível empresarial para potencializar casos de uso de Dados e IA para clientes globais de pequeno a grande porte. A plataforma permite colaboração real entre diferentes personas de dados em qualquer empresa, como Engenheiros de Dados, Cientistas de Dados, Analistas de Dados e SecOps / Engenharia de Nuvem.
Neste blog, o primeiro de uma série de dois, forneceremos uma visão geral da arquitetura do Azure Databricks e como os clientes podem se conectar às suas instâncias de serviços de dados Azure gerenciadas por eles mesmos de forma segura.
O Azure Databricks é um aplicativo gerenciado na nuvem Azure. Em um nível alto, a arquitetura consiste em um plano de controle/gerenciamento e um plano de dados. O plano de controle reside em uma assinatura gerenciada pela Microsoft e abriga serviços como aplicativo web, gerenciador de cluster, serviço de jobs, etc. Na implantação padrão, o plano de dados é um componente totalmente gerenciado na assinatura do cliente que inclui uma VNET, NSG e uma conta de armazenamento raiz conhecida como DBFS.
O plano de dados também pode ser implantado em uma VNET gerenciada pelo cliente, para permitir que as equipes de SecOps e Engenharia de Nuvem construam a arquitetura de segurança e rede para o serviço de acordo com suas políticas de governança corporativa. Essa capacidade é chamada de Bring Your Own VNET ou Injeção de VNET. A imagem mostra uma visão representativa de tal arquitetura de cliente.
Segurança Corporativa é um pilar central na construção de software tanto na Databricks quanto na Microsoft, e, portanto, é considerada um cidadão de primeira classe no Azure Databricks. No contexto deste blog, conectividade segura refere-se a garantir que o tráfego do Azure Databricks para serviços de dados Azure permaneça na rede backbone do Azure, com a capacidade inerente de listar o Azure Databricks como uma fonte permitida. Como uma prática recomendada de segurança, recomendamos algumas opções que os clientes podem usar para estabelecer tal mecanismo de acesso a dados para serviços de dados Azure como Azure Blob Storage, Azure Data Lake Store Gen2, Azure Synapse Data Warehouse, Azure CosmosDB, etc. Leia mais para uma discussão sobre Azure Private Link e Service Endpoints.
A maneira mais segura de acessar serviços de dados Azure do Azure Databricks é configurando o Private Link. De acordo com a documentação Azure - Private Link permite acessar Serviços Azure PaaS (por exemplo, Azure Storage, Azure Cosmos DB e SQL Database) e serviços de clientes/parceiros hospedados no Azure através de um Private Endpoint em sua rede virtual. O tráfego entre sua rede virtual e o serviço atravessa o backbone da rede Microsoft, eliminando a exposição à Internet pública. Você também pode criar seu próprio Private Link Service em sua rede virtual (VNet) e entregá-lo privadamente aos seus clientes. A experiência de configuração e consumo usando Azure Private Link é consistente em todos os serviços Azure PaaS, de propriedade do cliente e compartilhados de parceiros. Para detalhes, consulte este link.
Veja abaixo como o Azure Databricks e o Private Link podem ser usados juntos.
Azure Databricks e Private Endpoints de Serviços de Dados Azure em VNETs separadas
Azure Databricks e Private Endpoints de Serviços de Dados Azure na mesma VNET
Considere o seguinte antes de implementar o private endpoint:
Um exemplo de onde se pode usar o Private Link é quando um cliente usa alguns serviços de dados Azure em produção junto com o Azure Databricks, como Blob Storage, ADLS Gen2, SQL DB, etc. O negócio gostaria que os usuários consultassem os dados agregados mascarados do ADLS Gen2, mas restringi-los de acessar os dados confidenciais não mascarados em outras fontes de dados. Nesse caso, um private endpoint poderia ser estabelecido apenas para o serviço ADLS Gen2 usando qualquer uma das sub-opções discutidas acima.
É assim que tal ambiente poderia ser configurado:
1 - Configurar Private Link para ADLS Gen2
2 - Implantar Azure Databricks em sua VNET
Observe que é possível configurar mais de um Private Link por serviço de dados Azure, o que permite construir uma arquitetura que esteja em conformidade com as necessidades de governança da sua empresa.
De acordo com a documentação Azure, Virtual Network (VNET) service endpoints estendem o espaço de endereço privado da sua rede virtual. Os endpoints também estendem a identidade da sua VNet para os serviços Azure através de uma conexão direta. Os endpoints permitem proteger seus recursos críticos de serviços Azure apenas para suas redes virtuais. O tráfego da sua VNet para o serviço Azure permanece sempre na rede backbone da Microsoft Azure.
Segurança aprimorada para seus recursos de serviço do Azure
O espaço de endereço privado para diferentes redes virtuais pode se sobrepor. Você não pode usar um espaço de rede sobreposto para identificar exclusivamente o tráfego originado de uma VNET específica. Uma vez que os endpoints de serviço são habilitados para as sub-redes em sua VNET, você pode adicionar uma regra de firewall de rede virtual para proteger os serviços de dados do Azure, estendendo a identidade da sua VNET para esses recursos. Tal configuração ajuda a remover o acesso público a esses recursos e permite o tráfego apenas da sua VNET.
Roteamento ideal para tráfego de serviços de dados do Azure a partir da sua rede virtual
Atualmente, todas as rotas em sua VNET usadas para direcionar tráfego com cabeçalho de rede pública através de seus eletrodomésticos virtuais baseados na nuvem/on-premises também são usadas para o tráfego de serviços de dados do Azure. Os endpoints de serviço fornecem roteamento ideal para o tráfego do Azure.
Mantendo o tráfego na rede principal do Azure
Os endpoints de serviço sempre direcionam o tráfego de serviços de dados do Azure diretamente da sua VNET para o recurso na rede principal da Microsoft Azure. Manter o tráfego na rede principal do Azure permite que você continue auditando e monitorando o tráfego de Internet de saída de suas redes virtuais, através de forced-tunneling, sem impactar o tráfego de serviços de dados. Para mais informações sobre rotas definidas pelo usuário e forced-tunneling, consulte roteamento de tráfego de rede virtual do Azure.
Simples de configurar sem sobrecarga de gerenciamento
Você não precisa mais de endereços IP públicos reservados em suas redes virtuais para proteger recursos de serviços de dados do Azure através de firewall de IP. Não há dispositivos de NAT (Network Address Translation) ou gateway necessários para configurar os endpoints de serviço. Você pode configurar endpoints de serviço através de uma configuração simples para uma sub-rede. Não há sobrecarga adicional para manter os endpoints.
Endpoint de Serviço do Azure com Azure Databricks
Por favor, considere o seguinte antes de implementar os endpoints de serviço:
Tomando o mesmo exemplo mencionado acima para Private Link, e como isso poderia parecer com Endpoints de Serviço. Neste caso, o Endpoint de Serviço de Armazenamento do Azure poderia ser configurado nas sub-redes do Azure Databricks e as mesmas sub-redes poderiam então ser incluídas na lista de permissões nas regras de firewall do ADLS Gen2.
É assim que tal ambiente poderia ser configurado:
1 - Configurar Endpoint de Serviço para ADLS Gen2
2 - Implantar Azure Databricks em sua VNET
3 - Configurar regras de firewall de IP no ADLS Gen2
Discutimos algumas opções disponíveis para acessar serviços de dados do Azure de forma segura a partir do seu ambiente Azure Databricks. Com base nas especificidades do seu negócio, você pode usar Azure Private Link ou Virtual Network Service Endpoints. Uma vez que a abordagem de conectividade de rede for finalizada, você poderá utilizar abordagens de autenticação seguras para se conectar a esses recursos:
No próximo blog desta série, vamos nos aprofundar em como configurar um ambiente seguro e bloqueado para prevenir a exfiltração de dados (em outras palavras, implementar uma arquitetura de prevenção contra perda de dados). Ele utilizaria uma mistura das opções discutidas acima e o Azure Firewall. Por favor, entre em contato com suas equipes de conta Microsoft ou Databricks para quaisquer perguntas.
(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original
Assine nosso blog e receba os posts mais recentes diretamente na sua caixa de entrada.