Gerenciamento de identidade e de acesso
Este artigo examina as considerações de design e as recomendações para o gerenciamento de identidade e de acesso. Ele ressalta a implantação de uma plataforma de análise em escala de nuvem no Microsoft Azure. Como a análise em escala de nuvem é um elemento crítico, as diretrizes sobre as áreas de design da zona de destino do Azure também devem ser incluídas no seu design.
Este artigo se baseia em considerações e recomendações sobre as zonas de destino do Azure. Para saber mais, confira Gerenciamento de identidade e acesso.
Design de zona de destino de dados
A análise em escala de nuvem oferece suporte a um modelo de controle de acesso usando identidades do Microsoft Entra. O modelo usa o RBAC (controle de acesso baseado em função) do Azure e as ACLs (listas de controle de acesso).
Revise as atividades de administração e gerenciamento do Azure que suas equipes executam. Considere sua análise em escala de nuvem no Azure. Determine a melhor distribuição possível de responsabilidades em sua organização.
Atribuições de função
Para desenvolver, entregar e servir produtos de dados de forma autônoma na plataforma de dados, as equipes de aplicativos de dados exigem poucos direitos de acesso no ambiente do Azure. Antes de passar pelos respectivos requisitos de RBAC, é necessário destacar que diferentes modelos de acesso precisam ser usados para o desenvolvimento e ambientes mais elevados. Além disso, os grupos de segurança devem ser usados sempre que possível para reduzir o número de atribuições de função e simplificar o processo de gerenciamento e revisão dos direitos do RBAC. Isso é fundamental, devido ao número limitado de atribuições de função que podem ser criadas por assinatura.
O ambiente de desenvolvimento deve ter permissão para ser acessado pela equipe de desenvolvimento e as respectivas identidades de usuário a fim de permitir que elas iterem mais rapidamente, saibam mais sobre determinadas funcionalidades nos serviços do Azure e solucionem os problemas com eficiência. O acesso a um ambiente de desenvolvimento ajudará no desenvolvimento ou no aprimoramento da IaC (infraestrutura como código) e de outros artefatos de código. Depois que uma implementação no ambiente de desenvolvimento funcionar conforme o esperado, ela poderá ser distribuída continuamente para os ambientes mais elevados. Os ambientes mais elevados, como teste e produção, devem ser bloqueados para a equipe do aplicativo de dados. Somente uma entidade de serviço precisa ter acesso a esses ambientes e, portanto, todas as implantações precisam ser executadas por meio da identidade da entidade de serviço usando pipelines de CI/CD. Para resumir, os direitos de acesso ao ambiente de desenvolvimento devem ser fornecidos às identidades de entidade de serviço E de usuário e, em ambientes mais elevados, os direitos de acesso devem ser fornecidos apenas a uma identidade de entidade de serviço.
Para criar recursos e atribuições de função entre os recursos dentro dos grupos de recursos do aplicativo, os direitos Contributor e User Access Administrator precisam ser fornecidos. Isso permitirá que as equipes criem e controlem serviços no ambiente dentro dos limites do Azure Policy. A análise em escala de nuvem recomenda o uso de pontos de extremidade privados para superar o risco de exfiltração dos dados e, como outras opções de conectividade devem ser bloqueadas pela equipe da plataforma Azure por meio de políticas, as equipes de aplicativos de dados exigirão direitos de acesso à rede virtual compartilhada de uma zona de destino de dados para configurar com sucesso a conectividade de rede necessária para os serviços que pretendem usar. Para seguir o princípio de privilégios mínimos, superar os conflitos entre diferentes equipes de aplicativos de dados e ter uma separação clara das equipes, a análise em escala de nuvem propõe criar uma sub-rede dedicada por equipe de aplicativo de dados e criar uma atribuição de função Network Contributor para essa sub-rede (escopo do recurso filho). Essa atribuição de função permite que as equipes ingressem na sub-rede usando pontos de extremidade privados.
Essas duas primeiras atribuições de função habilitarão a implantação de serviços de autoatendimento de serviços de dados nesses ambientes. Para resolver a preocupação de gerenciamento de custos, as organizações devem adicionar uma marca de centro de custo aos grupos de recursos para habilitar a cobrança cruzada e a propriedade de custo distribuído. Isso conscientiza as equipes e as obriga a tomar as decisões certas em relação aos SKUs e às camadas de serviço necessárias.
Para também habilitar o uso por autoatendimento de outros recursos compartilhados na zona de destino de dados, algumas atribuições de função extras são necessárias. Se o acesso a um ambiente Databricks for necessário, as organizações devem usar o SCIM Synch da ID do Microsoft Entra para fornecer acesso. Isso é importante, pois esse mecanismo sincroniza automaticamente usuários e grupos do Microsoft Entra ID para o plano de dados do Databricks e também remove automaticamente os direitos de acesso quando um indivíduo deixa a organização ou a empresa. Esse não poderá ser o caso se forem usadas contas de usuário separadas no Azure Databricks. As equipes de aplicativos de dados devem ser adicionadas ao espaço de trabalho Databricks no shared-product-rg e no shared-integration-rg. No Azure Databricks, as equipes de aplicativos de dados devem receber direitos de acesso Can Restart em um cluster predefinido para executar cargas de trabalho no workspace.
As equipes individuais exigirão acesso à conta central do Purview para descobrir os ativos de dados dentro das respectivas zonas de destino de dados. Portanto, as equipes terão que ser adicionadas como Data Reader à coleção de nível superior do Purview. Além disso, as equipes exigirão, na maioria dos casos, a opção de editar ativos de dados catalogados dos quais são proprietários para fornecer detalhes extras, como detalhes de contato de proprietários de dados e especialistas, bem como detalhes mais granulares sobre as colunas de um conjunto de dados que descrevem e as informações que estão sendo incluídas.
Resumo dos requisitos de controle de acesso baseado em função
Para fins de automação da implantação de zonas de destino de dados, você precisa dessas funções:
Nome da função
Descrição
Escopo
Implante todas as zonas DNS privadas para todos os serviços de dados em uma única assinatura e grupo de recursos. A entidade de serviço precisa estar Private DNS Zone Contributor no grupo de recursos DNS global criado durante a implantação da zona de destino do gerenciamento de dados. Essa função é necessária para implantar registros A para os pontos de extremidade privados.
(Escopo do grupo de recursos) /subscriptions/{{dataManagement}subscriptionId}/resourceGroups/{resourceGroupName}
Para configurar o emparelhamento de rede virtual entre a rede da zona de destino de dados e a rede da zona de destino de gerenciamento de dados, a entidade de serviço precisa de direitos de acesso Network Contributor no grupo de recursos da rede virtual remota.
(Escopo do grupo de recursos) /subscriptions/{{dataManagement}subscriptionId}/resourceGroups/{resourceGroupName}
Essa permissão é necessária para compartilhar o runtime de integração auto-hospedado que é implantado no grupo de recursos integration-rg com outros data factories. Também é necessário atribuir o acesso de identidades gerenciadas do Azure Data Factory e do Azure Synapse Analytics aos respectivos sistemas de arquivos da conta de armazenamento.
(Escopo do recurso) /subscriptions/{{dataLandingZone}subscriptionId}
Observação
O número de atribuições de função pode ser reduzido em um cenário de produção. A atribuição de função Network Contributor só é necessária para configurar o emparelhamento de rede virtual entre a zona de destino de gerenciamento de dados e a zona de destino de dados. Sem essa consideração, a resolução de DNS não funciona. O tráfego de entrada e de saída é descartado porque não há nenhuma linha de visão para o Firewall do Azure.
O Private DNS Zone Contributor também não será necessário se a implantação de registros A do DNS dos pontos de extremidade privados for automatizada por meio de políticas do Azure com o efeito deployIfNotExists. O mesmo vale para User Access Administrator, pois a implantação pode ser automatizada usando políticas deployIfNotExists.
Atribuições de função para produtos de dados
As seguintes atribuições de função são necessárias para implantar um produto de dados em uma zona de destino de dados:
Nome da função
Descrição
Escopo
Implante todas as zonas DNS privadas para todos os serviços de dados em uma única assinatura e grupo de recursos. A entidade de serviço precisa estar Private DNS Zone Contributor no grupo de recursos DNS global criado durante a implantação da zona de destino do gerenciamento de dados. Essa função é necessária para implantar registros A nos respectivos pontos de extremidade privados.
(Escopo do grupo de recursos) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}
Implante todos os serviços de streaming de integração de dados em um único grupo de recursos dentro da assinatura da zona de destino de dados. A entidade de serviço exige uma atribuição de função Contributor nesse grupo de recursos.
(Escopo do grupo de recursos) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}
Para implantar pontos de extremidade privados na sub-rede de Link Privado especificada, criada durante a implantação da zona de destino de dados, a entidade de serviço Network Contributor exige acesso nessa sub-rede.
(Escopo do recurso filho) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName} /providers/Microsoft.Network/virtualNetworks/{virtualNetworkName}/subnets/{subnetName}"
Acesso a outros recursos
Fora do Azure, as equipes de Integração de Dados e de Produto de Dados também exigirão acesso a um repositório para armazenar artefatos de código, colaborar com eficiência e distribuir atualizações e alterações de maneira consistente por meio de CI/CD em ambientes mais elevados. Além disso, um quadro de projetos deve ser fornecido para permitir o desenvolvimento Agile, o planejamento de sprints, o acompanhamento de tarefas, bem como os comentários do usuário e as solicitações de recursos.
Por fim, a automação de CI/CD exigirá a configuração de uma conexão com o Azure, que é feita na maioria dos serviços por meio de entidades de serviço. Portanto, as equipes precisarão ter acesso a uma entidade de serviço para obter automação no projeto.
Gerenciamento do acesso aos dados
O gerenciamento do acesso aos dados deve ser feito usando grupos do Microsoft Entra. Adicione nomes de princípio de usuário ou nomes de entidade de serviço aos grupos do Microsoft Entra. Adicione os grupos aos serviços e conceda permissões ao grupo. Essa abordagem permite o controle de acesso refinado.
Para os produtos de dados nos data lakes do Azure, considere o uso de ACLs (listas de controle de acesso). Para saber mais, confira Modelo de controle de acesso no Azure Data Lake Storage Gen2. O uso da passagem do Microsoft Entra com listas de controle de acesso é suportado pela maioria dos serviços nativos do Azure, incluindo o Azure Machine Learning, o Azure Synapse, o SQL Serverless, o Apache Spark para Azure Synapse e o Azure Databricks.
É provável que outro armazenamento poliglota seja usado na análise em escala de nuvem. Entre os exemplos estão o Banco de Dados do Azure para PostgreSQL, o Banco de Dados do Azure para MySQL, o Banco de Dados SQL do Azure, a Instância Gerenciada de SQL e pools dedicados do SQL do Azure Synapse. Eles podem ser usados por equipes de aplicativos de dados para armazenar produtos de dados.
- Usar a ID do Microsoft Entra para autenticação com o Banco de Dados do Azure para PostgreSQL
- Usar a autenticação do Microsoft Entra com o Banco de Dados SQL do Azure, a Instância Gerenciada do SQL e o Azure Synapse Analytics
- Usar a ID do Microsoft Entra para autenticação com o Banco de Dados do Azure para MySQL
Recomendamos que você use grupos do Microsoft Entra para proteger objetos de banco de dados em vez de contas de usuário individuais do Microsoft Entra. Esses grupos do Microsoft Entra são usados para autenticar usuários e ajudar a proteger objetos de banco de dados. Semelhante ao padrão data lake, você pode usar sua integração de domínio ou produtos de dados para criar esses grupos em seu serviço Microsoft Entra.
Essa abordagem também fornece um único local de gerenciamento e permite a revisão dos direitos de acesso dentro do Azure Graph.
Para obter mais informações sobre como promover a segurança das zonas de destino de gerenciamento de dados e zonas de destino de dados que gerenciam seu patrimônio de dados, confira Provisionar a segurança para a análise em escala de nuvem no Azure.