Proteja um data lakehouse com o Azure Synapse Analytics

Azure Synapse Analytics

Azure Data Lake Storage

Azure Virtual Network

Power BI

Este artigo descreve o processo de design, os princípios e as opções de tecnologia para usar o Azure Synapse para criar uma solução segura de data lakehouse. Concentramo-nos nas considerações de segurança e nas principais decisões técnicas.

Apache®, Apache Spark® e o logotipo flame são marcas registradas ou marcas comerciais da Apache Software Foundation nos Estados Unidos e/ou em outros países. Nenhum endosso da Apache Software Foundation está implícito no uso dessas marcas.

Arquitetura

O diagrama a seguir mostra a arquitetura da solução data lakehouse. Ele foi projetado para controlar as interações entre os serviços, a fim de mitigar as ameaças à segurança. As soluções variam consoante os requisitos funcionais e de segurança.

Transfira um ficheiro do Visio desta arquitetura.

Fluxo de dados

O fluxo de dados para a solução é mostrado no diagrama a seguir:

Os dados são carregados da fonte de dados para a zona de aterrissagem de dados, seja para o armazenamento de Blob do Azure ou para um compartilhamento de arquivos fornecido pelos Arquivos do Azure. Os dados são carregados por um programa ou sistema batch uploader. Os dados de streaming são capturados e armazenados no Armazenamento de Blob usando o recurso Captura dos Hubs de Eventos do Azure. Pode haver várias fontes de dados. Por exemplo, várias fábricas diferentes podem carregar seus dados de operações. Para obter informações sobre como proteger o acesso ao Armazenamento de Blob, compartilhamentos de arquivos e outros recursos de armazenamento, consulte Recomendações de segurança para Armazenamento de Blob e Planejamento de uma implantação do Azure Files.
A chegada do arquivo de dados aciona o Azure Data Factory para processar os dados e armazená-los no data lake na zona de dados principal. O carregamento de dados para a zona de dados principal no Azure Data Lake protege contra a exfiltração de dados.
O Azure Data Lake armazena os dados brutos obtidos de diferentes fontes. Está protegido por regras de firewall e redes virtuais. Ele bloqueia todas as tentativas de conexão provenientes da Internet pública.
A chegada de dados no data lake aciona o pipeline do Azure Synapse ou um gatilho cronometrado executa um trabalho de processamento de dados. O Apache Spark no Azure Synapse é ativado e executa um trabalho ou bloco de anotações do Spark. Ele também orquestra o fluxo do processo de dados no data lakehouse. Os pipelines do Azure Synapse convertem dados da zona Bronze para a Zona Silver e, em seguida, para a Zona Gold.
Um trabalho ou bloco de anotações do Spark executa o trabalho de processamento de dados. A curadoria de dados ou um trabalho de treinamento de aprendizado de máquina também podem ser executados no Spark. Os dados estruturados na zona ouro são armazenados no formato Delta Lake .
Um pool SQL sem servidor cria tabelas externas que usam os dados armazenados no Delta Lake. O pool SQL sem servidor fornece um mecanismo de consulta SQL poderoso e eficiente e pode suportar contas de usuário SQL tradicionais ou contas de usuário do Microsoft Entra.
O Power BI se conecta ao pool SQL sem servidor para visualizar os dados. Ele cria relatórios ou painéis usando os dados no data lakehouse.
Os analistas de dados ou cientistas podem iniciar sessão no Azure Synapse Studio para:
- Melhore ainda mais os dados.
- Analise para obter insights de negócios.
- Treine o modelo de aprendizado de máquina.
Os aplicativos de negócios se conectam a um pool SQL sem servidor e usam os dados para dar suporte a outros requisitos de operação de negócios.
O Azure Pipelines executa o processo de CI/CD que cria, testa e implanta automaticamente a solução. Ele foi projetado para minimizar a intervenção humana durante o processo de implantação.

Componentes

A seguir estão os principais componentes desta solução data lakehouse:

Alternativas

Se você precisar de processamento de dados em tempo real, você pode, em vez de armazenar arquivos individuais na zona de aterrissagem de dados, usar o Apache Structured Streaming para receber o fluxo de dados dos Hubs de Eventos e processá-lo.
Se os dados tiverem uma estrutura complexa e exigirem consultas SQL complexas, considere armazená-los em um pool SQL dedicado em vez de um pool SQL sem servidor.
Se os dados contiverem muitas estruturas de dados hierárquicas, por exemplo, eles têm uma estrutura JSON grande, convém armazená-los no Azure Synapse Data Explorer.

Detalhes do cenário

O Azure Synapse Analytics é uma plataforma de dados versátil que suporta armazenamento de dados corporativos, análise de dados em tempo real, pipelines, processamento de dados de séries cronológicas, aprendizado de máquina e governança de dados. Para suportar estas capacidades integra várias tecnologias diferentes, tais como:

Armazenamento de dados empresariais
Conjuntos de SQL sem servidor
Apache Spark
Pipelines
Data Explorer
Recursos de aprendizado de máquina
Governança de dados unificada do Microsoft Purview

Diagrama que mostra o Azure Synapse Analytics e seus componentes, recursos e aplicativos.

Esses recursos abrem muitas possibilidades, mas há muitas escolhas técnicas a serem feitas para configurar com segurança a infraestrutura para uso seguro.

O objetivo é fornecer orientação sobre a construção de uma plataforma de data lakehouse segura e econômica para uso corporativo e sobre como fazer com que as tecnologias trabalhem juntas de forma transparente e segura.

Potenciais casos de utilização

Um data lakehouse é uma arquitetura moderna de gerenciamento de dados que combina os recursos de custo-benefício, escala e flexibilidade de um data lake com os recursos de gerenciamento de dados e transações de um data warehouse. Um data lakehouse pode lidar com uma grande quantidade de dados e suportar cenários de business intelligence e machine learning. Também pode processar dados de diversas estruturas de dados e fontes de dados. Para obter mais informações, consulte O que é o Databricks Lakehouse?.

Alguns casos de uso comuns para a solução descrita aqui são:

Análise da telemetria da Internet das Coisas (IoT)
Automação de fábricas inteligentes (para manufatura)
Acompanhamento das atividades e do comportamento do consumidor (para o varejo)
Gerir incidentes e eventos de segurança
Monitorando logs de aplicativos e o comportamento de aplicativos
Processamento e análise de negócios de dados semi-estruturados

Design de alto nível

Esta solução concentra-se no design de segurança e práticas de implementação na arquitetura. Pool SQL sem servidor, Apache Spark no Azure Synapse, pipelines do Azure Synapse, Armazenamento Data Lake e Power BI são os principais serviços usados para implementar o padrão data lakehouse.

Aqui está a arquitetura de design de solução de alto nível:

Diagrama que mostra a arquitetura de projeto da solução data lakehouse de alto nível.

Escolha o foco de segurança

Iniciamos o design de segurança usando a ferramenta de modelagem de ameaças. A ferramenta ajudou-nos a:

Comunique-se com as partes interessadas do sistema sobre riscos potenciais.
Defina o limite de confiança no sistema.

Com base nos resultados da modelagem de ameaças, fizemos das seguintes áreas de segurança nossas principais prioridades:

Controlo de Identidade e Acesso
Proteção de rede
Segurança do DevOps

Concebemos as funcionalidades de segurança e as alterações na infraestrutura para proteger o sistema, atenuando os principais riscos de segurança identificados com estas prioridades máximas.

Para mais informações sobre o que deve ser verificado e considerado, consulte:

Plano de proteção de redes e ativos

Um dos principais princípios de segurança no Cloud Adoption Framework é o princípio Zero Trust: ao projetar a segurança para qualquer componente ou sistema, reduza o risco de invasores expandirem seu acesso assumindo que outros recursos na organização estão comprometidos.

Com base no resultado da modelagem de ameaças, a solução adota a recomendação de implantação de microssegmentação em confiança zero e define vários limites de segurança. A Rede Virtual do Azure e a proteção de exfiltração de dados do Azure Synapse são as principais tecnologias usadas para implementar o limite de segurança para proteger ativos de dados e componentes críticos.

Como o Azure Synapse é composto por várias tecnologias diferentes, precisamos:

Identificar os componentes do Synapse e serviços relacionados que são usados no projeto.

O Azure Synapse é uma plataforma de dados versátil que pode lidar com muitas necessidades diferentes de processamento de dados. Primeiro, precisamos decidir quais componentes no Azure Synapse são usados no projeto para que possamos planejar como protegê-los. Também precisamos determinar quais outros serviços se comunicam com esses componentes do Azure Synapse.

Na arquitetura data lakehouse, os principais componentes são:
- Azure Synapse serverless SQL
- Apache Spark no Azure Synapse
- Pipelines do Azure Synapse
- Data Lake Storage
- Azure DevOps
Definir os comportamentos de comunicação legal entre os componentes.

Precisamos definir os comportamentos de comunicação permitidos entre os componentes. Por exemplo, queremos que o mecanismo Spark se comunique diretamente com a instância SQL dedicada ou queremos que ele se comunique por meio de um proxy, como o pipeline de Integração de Dados do Azure Synapse ou o Armazenamento Data Lake?

Com base no princípio Zero Trust, bloqueamos a comunicação se não houver necessidade comercial para a interação. Por exemplo, impedimos que um mecanismo Spark que esteja em um locatário desconhecido se comunique diretamente com o armazenamento do Data Lake.
Escolha a solução de segurança adequada para impor os comportamentos de comunicação definidos.

No Azure, várias tecnologias de segurança podem impor os comportamentos de comunicação de serviço definidos. Por exemplo, no Armazenamento Data Lake, você pode usar uma lista de permissões de endereço IP para controlar o acesso a um data lake, mas também pode escolher quais redes virtuais, serviços do Azure e instâncias de recursos são permitidos. Cada método de proteção fornece proteção de segurança diferente. Escolha com base nas necessidades do negócio e limitações ambientais. A configuração usada nesta solução é descrita na próxima seção.
Implemente a deteção de ameaças e defesas avançadas para recursos críticos.

Para recursos críticos, é melhor implementar a deteção de ameaças e defesas avançadas. Os serviços ajudam a identificar ameaças e disparar alertas, para que o sistema possa notificar os usuários sobre violações de segurança.

Considere as seguintes técnicas para proteger melhor as redes e os ativos:

Implantar redes de perímetro para fornecer zonas de segurança para pipelines de dados

Quando uma carga de trabalho de pipeline de dados requer acesso a dados externos e à zona de aterrissagem de dados, é melhor implementar uma rede de perímetro e separá-la com um pipeline de extração, transformação, carga (ETL).
Ativar o Defender for Cloud para todas as contas de armazenamento

O Defender for Cloud aciona alertas de segurança quando deteta tentativas incomuns e potencialmente prejudiciais de acessar ou explorar contas de armazenamento. Para obter mais informações, consulte Configurar o Microsoft Defender para armazenamento.
Bloquear uma conta de armazenamento para evitar exclusões maliciosas ou alterações de configuração

Para obter mais informações, consulte Aplicar um bloqueio do Azure Resource Manager a uma conta de armazenamento.

Arquitetura com proteção de rede e ativos

A tabela a seguir descreve os comportamentos de comunicação definidos e as tecnologias de segurança escolhidas para esta solução. As escolhas foram baseadas nos métodos discutidos no plano de proteção de redes e ativos.

De (Cliente)	Para (Serviço)	Comportamento	Configuração	Notas
Internet	Data Lake Storage	Negar tudo	Regra de firewall - Negação padrão	Padrão: 'Negar'	Regra de firewall - Negar padrão
Azure Synapse Pipeline/Spark	Data Lake Storage	Permitir (instância)	Rede virtual - Ponto de extremidade privado gerenciado (armazenamento Data Lake)
SQL do Synapse	Data Lake Storage	Permitir (instância)	Regra de firewall - instâncias de recursos (Synapse SQL)	O Synapse SQL precisa acessar o Data Lake Storage usando identidades gerenciadas
Agente do Azure Pipelines	Data Lake Storage	Permitir (instância)	Regra de firewall - Redes virtuais selecionadas Ponto de extremidade de serviço - Armazenamento	Para testes de integração bypass: 'AzureServices' (regra de firewall)
Internet	Área de trabalho do Azure Synapse	Negar tudo	Regra de firewall
Agente do Azure Pipelines	Área de trabalho do Azure Synapse	Permitir (instância)	Rede virtual - ponto de extremidade privado	Requer três pontos de extremidade privados (Dev, serverless SQL e SQL dedicado)
Rede virtual gerenciada pela Sinapse	Internet ou locatário não autorizado do Azure	Negar tudo	Rede virtual - Synapse proteção contra exfiltração de dados
Sinapse pipeline/Faísca	Key Vault	Permitir (instância)	Rede virtual - Ponto de extremidade privado gerenciado (Cofre da chave)	Padrão: 'Negar'
Agente do Azure Pipelines	Key Vault	Permitir (instância)	Regra de firewall - Redes virtuais selecionadas * Ponto final de serviço - Key Vault	bypass: 'AzureServices' (regra de firewall)
Funções do Azure	Synapse SQL sem servidor	Permitir (instância)	Rede virtual - Ponto de extremidade privado (Synapse serverless SQL)
Sinapse pipeline/Faísca	Azure Monitor	Permitir (instância)	Rede virtual - Ponto de extremidade privado (Azure Monitor)

Por exemplo, no plano queremos:

Crie um espaço de trabalho do Azure Synapse com uma rede virtual gerenciada.
Proteja a saída de dados dos espaços de trabalho do Azure Synapse usando os espaços de trabalho do Azure Synapse Proteção contra exfiltração de dados.
Gerencie a lista de locatários aprovados do Microsoft Entra para o espaço de trabalho Synapse do Azure.
Configure regras de rede para conceder tráfego à conta de armazenamento a partir de redes virtuais selecionadas, acessar somente e desabilitar o acesso à rede pública.
Use Pontos de Extremidade Privados Gerenciados para conectar a rede virtual gerenciada pela Sinapse do Azure ao data lake.
Use a Instância de Recursos para conectar com segurança o Azure Synapse SQL ao data lake.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que você pode usar para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Segurança

Para obter informações sobre o pilar de segurança do Well-Architected Framework, consulte Segurança.

Identidade e controlo de acesso

Existem vários componentes no sistema. Cada um requer uma configuração diferente de gerenciamento de identidade e acesso (IAM). Essas configurações precisam colaborar para fornecer uma experiência de usuário simplificada. Portanto, usamos as seguintes diretrizes de design quando implementamos o controle de identidade e acesso.

Escolha uma solução de identidade para diferentes camadas de controle de acesso
- Existem quatro soluções de identidade diferentes no sistema.
  - Conta SQL (SQL Server)
  - Entidade de serviço (Microsoft Entra ID)
  - Identidade gerenciada (Microsoft Entra ID)
  - Conta de Utilizador (Microsoft Entra ID)
- Existem quatro camadas diferentes de controle de acesso no sistema.
  - A camada de acesso ao aplicativo: escolha a solução de identidade para Funções AP.
  - A camada de acesso de banco de dados/tabela do Azure Synapse: escolha a solução de identidade para funções em bancos de dados.
  - Azure Synapse acessar camada de recursos externos: escolha a solução de identidade para acessar recursos externos.
  - Camada de acesso do Armazenamento Data Lake: escolha a solução de identidade para controlar o acesso a arquivos no armazenamento.
Uma parte crucial do controle de identidade e acesso é escolher a solução de identidade certa para cada camada de controle de acesso. Os princípios de design de segurança do Azure Well-Architected Framework sugerem o uso de controles nativos e simplicidade de condução. Portanto, essa solução usa a conta de usuário do Microsoft Entra do usuário final nas camadas de acesso do aplicativo e do banco de dados do Azure Synapse. Ele usa as soluções nativas do IAM de primeira parte e fornece controle de acesso refinado. A camada de recursos externos de acesso do Azure Synapse e a camada de acesso do Data Lake usam a identidade gerenciada no Azure Synapse para simplificar o processo de autorização.
Considere o acesso menos privilegiado

Um princípio orientador do Zero Trust sugere fornecer acesso just-in-time e suficiente a recursos críticos. Consulte Microsoft Entra Privileged Identity Management (PIM) para melhorar a segurança no futuro.
Proteger o serviço vinculado

Os serviços vinculados definem as informações de conexão necessárias para que um serviço se conecte a recursos externos. É importante proteger as configurações de serviços vinculados.
- Crie um serviço vinculado do Azure Data Lake com o Private Link.
- Use a identidade gerenciada como o método de autenticação em serviços vinculados.
- Use o Azure Key Vault para proteger as credenciais de acesso ao serviço vinculado.

Avaliação da pontuação de segurança e deteção de ameaças

Para entender o status de segurança do sistema, a solução usa o Microsoft Defender for Cloud para avaliar a segurança da infraestrutura e detetar problemas de segurança. O Microsoft Defender for Cloud é uma ferramenta para segurança, postura, gestão e proteção contra ameaças. Ele pode proteger cargas de trabalho em execução no Azure, híbridas e outras plataformas de nuvem.

Diagrama que mostra o Azure Synapse e seus recursos.

Você habilita automaticamente o plano gratuito do Defender for Cloud em todas as suas assinaturas do Azure quando visita pela primeira vez as páginas do Defender for Cloud no portal do Azure. Recomendamos vivamente que o ative para obter a sua avaliação e sugestões de postura de segurança na nuvem. O Microsoft Defender for Cloud fornecerá sua pontuação de segurança e algumas diretrizes de proteção de segurança para suas assinaturas.

Diagrama que mostra o Azure Synapse e seus recursos.

Se a solução precisar de recursos avançados de gerenciamento de segurança e deteção de ameaças, como deteção e alerta de atividades suspeitas, você poderá habilitar a proteção da carga de trabalho na nuvem individualmente para diferentes recursos.

Otimização de custos

Para obter informações sobre o pilar de otimização de custos do Well-Architected Framework, consulte Otimização de custos.

Um dos principais benefícios da solução data lakehouse é sua arquitetura escalável e econômica. A maioria dos componentes da solução usa faturamento baseado no consumo e será dimensionada automaticamente. Nesta solução, todos os dados são armazenados no Armazenamento Data Lake. Você só paga para armazenar os dados se não executar consultas ou processar dados.

O preço desta solução depende da utilização dos seguintes recursos principais:

Azure Synapse Serverless SQL: use a cobrança baseada no consumo, pague apenas pelo que usar.
Apache Spark no Azure Synapse: use a cobrança baseada no consumo, pague apenas pelo que usar.
Azure Synapse Pipelines: use a cobrança baseada no consumo, pague apenas pelo que usar.
Azure Data Lakes: utilize a faturação baseada no consumo, pague apenas pelo que utilizar.
Power BI: o custo é baseado na licença que você compra.
Link privado: use a cobrança baseada no consumo, pague apenas pelo que usar.

Diferentes soluções de proteção de segurança têm diferentes modos de custo. Você deve escolher a solução de segurança com base em suas necessidades de negócios e custos de solução.

Você pode usar a Calculadora de Preços do Azure para estimar o custo da solução.

Excelência operacional

Para obter informações sobre o pilar de excelência operacional do Well-Architected Framework, consulte Excelência operacional.

Usar um agente de pipeline auto-hospedado habilitado para rede virtual para serviços de CI/CD

O agente de pipeline padrão do Azure DevOps não dá suporte à comunicação de rede virtual porque usa um intervalo de endereços IP muito amplo. Esta solução implementa um agente auto-hospedado do Azure DevOps na rede virtual para que os processos de DevOps possam se comunicar sem problemas com os outros serviços da solução. As cadeias de conexão e os segredos para executar os serviços CI/CD são armazenados em um Cofre de Chaves independente. Durante o processo de implantação, o agente auto-hospedado acessa o cofre de chaves na zona de dados principal para atualizar as configurações e os segredos dos recursos. Para obter mais informações, consulte o documento Usar cofres de chaves separados . Essa solução também usa conjuntos de dimensionamento de VM para garantir que o mecanismo de DevOps possa ser dimensionado automaticamente para cima e para baixo com base na carga de trabalho.

Implementar varredura de segurança de infraestrutura e testes de fumaça de segurança no pipeline de CI/CD

Uma ferramenta de análise estática para digitalizar arquivos de infraestrutura como código (IaC) pode ajudar a detetar e evitar configurações incorretas que podem levar a problemas de segurança ou conformidade. O teste de fumaça de segurança garante que as medidas vitais de segurança do sistema sejam habilitadas com sucesso, protegendo contra falhas de implantação.

Use uma ferramenta de análise estática para verificar a infraestrutura como modelos de código (IaC) para detetar e evitar configurações incorretas que podem levar a problemas de segurança ou conformidade. Use ferramentas como Checkov ou Terrascan para detetar e prevenir riscos de segurança.
Verifique se o pipeline de CD lida corretamente com falhas de implantação. Qualquer falha de implantação relacionada a recursos de segurança deve ser tratada como uma falha crítica. O pipeline deve tentar novamente a ação com falha ou manter a implantação.
Valide as medidas de segurança no pipeline de implantação executando testes de fumaça de segurança. O teste de fumaça de segurança, como validar o status de configuração de recursos implantados ou casos de teste que examinam cenários críticos de segurança, pode garantir que o design de segurança esteja funcionando conforme o esperado.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

Herman Wu - Brasil | Engenheiro de Software Sênior

Outros contribuidores:

Ian Chen - Brasil | Engenheiro de Software Principal Líder
Jose Contreras - Brasil | Engenharia de Software Principal
Roy Chan - Brasil | Gerente Principal de Engenharia de Software

Partilhar via

Proteja um data lakehouse com o Azure Synapse Analytics