Modelo de controle de acesso no Armazenamento do Azure Data Lake

O Armazenamento Data Lake suporta os seguintes mecanismos de autorização:

• Autorização de chave compartilhada
• Autorização de assinatura de acesso compartilhado (SAS)
• Controle de acesso baseado em função (Azure RBAC)
• Controle de acesso baseado em atributos (Azure ABAC)
• Listas de controlo de acesso (ACL)

A autorização de Chave Compartilhada e SAS concede acesso a um usuário (ou aplicativo) sem exigir que ele tenha uma identidade no Microsoft Entra ID. Com essas duas formas de autenticação, o Azure RBAC, o Azure ABAC e as ACLs não têm efeito.

O RBAC e o ACL do Azure exigem que o utilizador (ou aplicação) tenha uma identidade no Microsoft Entra ID. O RBAC do Azure permite-lhe conceder acesso "genérico" aos dados da conta de armazenamento, tais como acesso de leitura ou escrita a todos os dados numa conta de armazenamento. O Azure ABAC permite refinar as atribuições de função RBAC adicionando condições. Por exemplo, você pode conceder acesso de leitura ou gravação a todos os objetos de dados em uma conta de armazenamento que tenham uma marca específica. As ACLs permitem-lhe conceder acesso "refinado", tais como o acesso de escrita a um diretório ou ficheiro específico.

Este artigo se concentra no RBAC, ABAC e ACLs do Azure e como o sistema os avalia juntos para tomar decisões de autorização para recursos de conta de armazenamento.

Controle de acesso baseado em função (Azure RBAC)

O RBAC do Azure usa atribuições de função para aplicar conjuntos de permissões a entidades de segurança. Uma entidade de segurança é um objeto que representa um usuário, grupo, entidade de serviço ou identidade gerenciada definida na ID do Microsoft Entra. Um conjunto de permissões pode dar a uma entidade de segurança um nível de acesso "grosseiro", como acesso de leitura ou gravação a todos os dados em uma conta de armazenamento ou a todos os dados em um contêiner.

As funções a seguir permitem que uma entidade de segurança acesse dados em uma conta de armazenamento.

Função	Description
Proprietário dos Dados do Armazenamento de Blobs	Acesso total a contêineres e dados de armazenamento de Blob. Esse acesso permite que a entidade de segurança defina um item para o proprietário e modifique as ACLs de todos os itens.
Contribuidor de Dados de Blobs de Armazenamento	Leia, escreva e elimine o acesso a contentores e blobs de armazenamento de Blobs. Esse acesso não permite que a entidade de segurança defina a propriedade de um item, mas pode modificar a ACL de itens que pertencem à entidade de segurança.
Leitor de Dados do Armazenamento de Blobs	Leia e liste contêineres e blobs de armazenamento de Blobs.

Funções como Proprietário, Colaborador, Leitor e Colaborador da Conta de Armazenamento permitem que uma entidade de segurança gerencie uma conta de armazenamento, mas não fornecem acesso aos dados dessa conta. No entanto, essas funções (excluindo o Reader) podem obter acesso às chaves de armazenamento, que podem ser usadas em várias ferramentas de cliente para acessar os dados.

Controle de acesso baseado em atributos (Azure ABAC)

O Azure ABAC baseia-se no Azure RBAC adicionando condições de atribuição de função com base em atributos no contexto de ações específicas. Uma condição de atribuição de função é uma verificação adicional que você pode, opcionalmente, adicionar à sua atribuição de função para fornecer um controle de acesso mais refinado. Não é possível negar explicitamente o acesso a recursos específicos usando condições.

Para obter mais informações sobre como usar o Azure ABAC para controlar o acesso ao Armazenamento do Azure, consulte Autorizar o acesso ao Armazenamento de Blobs do Azure usando as condições de atribuição de função do Azure.

Listas de controlo de acesso (ACL)

As ACLs oferecem a capacidade de aplicar um nível "mais refinado" de acesso a diretórios e arquivos. Uma ACL é uma construção de permissão que contém uma série de entradas de ACL. Cada entrada de ACL associa a entidade de segurança a um nível de acesso. Para saber mais, consulte Listas de controle de acesso (ACLs) no Armazenamento do Azure Data Lake.

Como são avaliadas as permissões

Durante a autorização baseada em entidade de segurança, as permissões são avaliadas conforme mostrado no diagrama a seguir.

1. O Azure determina se existe uma atribuição de função para a entidade de segurança.
   • Se existir uma atribuição de função, as condições de atribuição de função (2) serão avaliadas em seguida.
   • Caso contrário, as LCA (4) são avaliadas em seguida.
2. O Azure determina se existem condições de atribuição de função ABAC.
   • Se não existirem condições, o acesso é concedido.
   • Se existirem condições, são avaliadas para ver se correspondem ao pedido (3).
3. O Azure determina se todas as condições de atribuição de função ABAC correspondem aos atributos da solicitação.
   • Se todos corresponderem, o acesso é concedido.
   • Se pelo menos um deles não corresponder, as LCA (4) são avaliadas em seguida.
4. Se o acesso não tiver sido explicitamente concedido após a avaliação das atribuições e condições de função, as ACLs serão avaliadas.
   • Se as ACLs permitirem o nível de acesso solicitado, o acesso será concedido.
   • Caso contrário, o acesso é negado.

Importante

Devido à maneira como as permissões de acesso são avaliadas pelo sistema, não é possível usar uma ACL para restringir o acesso que já foi concedido por uma atribuição de função e suas condições. Isso ocorre porque o sistema avalia as atribuições e condições de função do Azure primeiro e, se a atribuição conceder permissão de acesso suficiente, as ACLs serão ignoradas.

O diagrama a seguir mostra o fluxo de permissão para três operações comuns: listar o conteúdo do diretório, ler um arquivo e gravar um arquivo.

Tabela de permissões: combinando RBAC, ABAC e ACLs do Azure

A tabela a seguir mostra como combinar funções, condições e entradas de ACL do Azure para que uma entidade de segurança possa executar as operações listadas na coluna Operação . Esta tabela mostra uma coluna que representa cada nível de uma hierarquia de diretórios fictícia. Há uma coluna para o diretório raiz do contêiner (/), um subdiretório chamado Oregon, um subdiretório do diretório Oregon chamado Portland e um arquivo de texto no diretório Portland chamado Data.txt. Aparecem nessas colunas representações de forma curta da entrada ACL necessária para conceder permissões. N/D (Não aplicável) aparece na coluna se uma entrada ACL não for necessária para executar a operação.

Operação	Função do Azure atribuída (com ou sem condições)	/	Oregon/	Portland/	Data.txt
Ler Data.txt	Proprietário de Dados de Blobs de Armazenamento	N/A	N/D	N/D	N/A
	Contribuidor de Dados de Blobs de Armazenamento	N/A	N/D	N/D	N/A
	Leitor de Dados de Blobs de Armazenamento	N/A	N/D	N/D	N/A
	Nenhuma	--X	--X	--X	R--
Anexar a Data.txt	Proprietário de Dados de Blobs de Armazenamento	N/A	N/D	N/D	N/A
	Contribuidor de Dados de Blobs de Armazenamento	N/A	N/D	N/D	N/A
	Leitor de Dados de Blobs de Armazenamento	--X	--X	--X	-W-
	Nenhuma	--X	--X	--X	RW-
Excluir Data.txt	Proprietário de Dados de Blobs de Armazenamento	N/A	N/D	N/D	N/A
	Contribuidor de Dados de Blobs de Armazenamento	N/A	N/D	N/D	N/A
	Leitor de Dados de Blobs de Armazenamento	--X	--X	-WX	N/A
	Nenhuma	--X	--X	-WX	N/A
Criar Data.txt	Proprietário de Dados de Blobs de Armazenamento	N/A	N/D	N/D	N/A
	Contribuidor de Dados de Blobs de Armazenamento	N/A	N/D	N/D	N/A
	Leitor de Dados de Blobs de Armazenamento	--X	--X	-WX	N/A
	Nenhuma	--X	--X	-WX	N/A
Lista /	Proprietário de Dados de Blobs de Armazenamento	N/A	N/D	N/D	N/A
	Contribuidor de Dados de Blobs de Armazenamento	N/A	N/D	N/D	N/A
	Leitor de Dados de Blobs de Armazenamento	N/A	N/D	N/D	N/A
	Nenhuma	R-X	N/A	N/D	N/A
Lista /Oregon/	Proprietário de Dados de Blobs de Armazenamento	N/A	N/D	N/D	N/A
	Contribuidor de Dados de Blobs de Armazenamento	N/A	N/D	N/D	N/A
	Leitor de Dados de Blobs de Armazenamento	N/A	N/D	N/D	N/A
	Nenhuma	--X	R-X	N/A	N/A
Lista /Oregon/Portland/	Proprietário de Dados de Blobs de Armazenamento	N/A	N/D	N/D	N/A
	Contribuidor de Dados de Blobs de Armazenamento	N/A	N/D	N/D	N/A
	Leitor de Dados de Blobs de Armazenamento	N/A	N/D	N/D	N/A
	Nenhuma	--X	--X	R-X	N/A

Nota

Para exibir o conteúdo de um contêiner no Gerenciador de Armazenamento do Azure, as entidades de segurança devem entrar no Gerenciador de Armazenamento usando a ID do Microsoft Entra e (no mínimo) ter acesso de leitura (R--) à pasta raiz (\) de um contêiner. Este nível de permissão dá-lhes a capacidade de listar o conteúdo da pasta raiz. Se não quiser que o conteúdo da pasta raiz fique visível, pode atribuir-lhes a função de Leitor . Com essa função, eles poderão listar os contêineres na conta, mas não o conteúdo do contêiner. Em seguida, você pode conceder acesso a diretórios e arquivos específicos usando ACLs.

Grupos de segurança

Use sempre os grupos de segurança do Microsoft Entra como a entidade de segurança atribuída em uma entrada ACL. Resista à oportunidade de atribuir diretamente utilizadores individuais ou principais de serviço. A utilização desta estrutura irá permitir-lhe adicionar e remover utilizadores ou principais de serviço sem a necessidade de aplicar novamente ACLs a uma estrutura completa do diretório. Em vez disso, você pode simplesmente adicionar ou remover usuários e entidades de serviço do grupo de segurança apropriado do Microsoft Entra.

Existem muitas maneiras diferentes de criar grupos. Por exemplo, imagine que você tenha um diretório chamado /LogData que contém dados de log gerados pelo servidor. O Azure Data Factory (ADF) ingere dados nessa pasta. Usuários específicos da equipe de engenharia de serviço carregarão logs e gerenciarão outros usuários dessa pasta, e vários clusters Databricks analisarão logs dessa pasta.

Para habilitar essas atividades, você pode criar um LogsWriter grupo e um LogsReader grupo. Em seguida, você pode atribuir permissões da seguinte maneira:

• Adicione o LogsWriter grupo à ACL do diretório /LogData com rwx permissões.
• Adicione o LogsReader grupo à ACL do diretório /LogData com r-x permissões.
• Adicione o objeto principal de serviço ou a Identidade de Serviço Gerenciado (MSI) do ADF ao LogsWriters grupo.
• Adicione usuários da equipe de engenharia de serviço ao LogsWriter grupo.
• Adicione o objeto principal de serviço ou MSI para Databricks ao LogsReader grupo.

Se um usuário da equipe de engenharia de serviço deixar a empresa, você pode simplesmente removê-lo do LogsWriter grupo. Se você não adicionou esse usuário a um grupo, mas em vez disso, adicionou uma entrada ACL dedicada para esse usuário, será necessário remover essa entrada ACL do diretório /LogData . Você também teria que remover a entrada de todos os subdiretórios e arquivos em toda a hierarquia de diretórios do diretório /LogData .

Para criar um grupo e adicionar membros, consulte Criar um grupo básico e adicionar membros usando a ID do Microsoft Entra.

Importante

O Azure Data Lake Storage Gen2 depende da ID do Microsoft Entra para gerenciar grupos de segurança. O Microsoft Entra ID recomenda que você limite a associação de grupo para uma determinada entidade de segurança a menos de 200. Esta recomendação deve-se a uma limitação de JSON Web Tokens (JWT) que fornecem informações de associação de grupo de uma entidade de segurança em aplicativos Microsoft Entra. Exceder esse limite pode levar a problemas de desempenho inesperados com o Data Lake Storage Gen2. Para saber mais, consulte Configurar declarações de grupo para aplicativos usando a ID do Microsoft Entra.

Limites nas atribuições de função do Azure e entradas de ACL

Ao utilizar grupos, é menos provável que exceda o número máximo de atribuições de funções por subscrição e o número máximo de entradas ACL por ficheiro ou diretório. A tabela a seguir descreve esses limites.

Mecanismo	Âmbito	Limites	Nível de permissão suportado
RBAC do Azure	Contas de armazenamento, contêineres. Atribuições de função do Azure entre recursos no nível de assinatura ou grupo de recursos.	4000 atribuições de função do Azure em uma assinatura	Funções do Azure (internas ou personalizadas)
ACL	Diretório, arquivo	32 entradas ACL (efetivamente 28 entradas ACL) por arquivo e por diretório. Cada uma das ACLs de acesso e de predefinição tem o seu próprio limite de 32 entradas ACL.	Permissão ACL

Autorização de Chave Partilhada e Assinatura de Acesso Partilhado (SAS)

O Armazenamento Azure Data Lake também dá suporte aos métodos de Chave Compartilhada e SAS para autenticação. Uma característica desses métodos de autenticação é que nenhuma identidade está associada ao chamador e, portanto, a autorização baseada em permissão da entidade de segurança não pode ser executada.

No caso da Chave Compartilhada, o chamador efetivamente ganha acesso de "superusuário", o que significa acesso total a todas as operações em todos os recursos, incluindo dados, proprietário da configuração e alteração de ACLs.

Os tokens SAS incluem permissões permitidas como parte do token. As permissões incluídas no token SAS são efetivamente aplicadas a todas as decisões de autorização, mas nenhuma verificação adicional de ACL é executada.

Próximos passos

Para saber mais sobre listas de controle de acesso, consulte Listas de controle de acesso (ACLs) no Armazenamento do Azure Data Lake.