Modelo de controle de acesso no Azure Data Lake Storage Gen2

O Data Lake Storage Gen2 dá suporte aos seguintes mecanismos de autorização:

  • Autorização de chave compartilhada
  • Autorização de SAS (Assinatura de Acesso Compartilhado)
  • RBAC (controle de acesso baseado em função) do Azure
  • ACL (listas de controle de acesso)

A autorização de SAS e Chave Compartilhada concede acesso a um usuário (ou aplicativo) sem exigir que eles tenham uma identidade no Azure AD (Azure Active Directory). Com essas duas formas de autenticação, o RBAC do Azure e as ACLs não têm nenhum efeito.

O RBAC do Azure e a ACL exigem que o usuário (ou aplicativo) tenha uma identidade no Azure AD. Com o RBAC do Azure, você permite acesso de "alta granularidade" aos dados da conta de armazenamento, como acesso de leitura ou gravação a todos os dados em uma conta de armazenamento, enquanto as ACLs permitem que você conceda acesso "fino", como acesso de gravação a um diretório ou arquivo específico.

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

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

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, um grupo, uma entidade de serviço ou uma identidade gerenciada definida no AD (Azure Active Directory). Um conjunto de permissões pode dar a uma entidade de segurança um nível de acesso de "alta granularidade", como acesso de leitura ou gravação a todos os dados em uma conta de armazenamento ou 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 Descrição
Proprietário de Dados do Blob de Armazenamento Acesso completo aos contêineres e dados do Armazenamento de Blobs. Esse acesso permite que a entidade de segurança defina um item do proprietário e modifique as ACLs de todos os itens.
Colaborador de dados de blob de armazenamento Acesso de leitura, gravação e exclusão aos contêineres e blobs do 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 Blob de Armazenamento Ler e listar contêineres de blobs do 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 dentro dessa conta. No entanto, essas funções (excluindo Leitor) podem obter acesso às chaves de armazenamento, que podem ser usadas em várias ferramentas de cliente para acessar os dados.

ACLs (listas de controle de acesso)

As ACLs oferecem a capacidade de aplicar o nível de acesso de "maior granularidade" 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 obter mais informações, confira ACLS (listas de controle de acesso) no Azure Data Lake Storage Gen2.

Como as permissões são avaliadas

Durante a autorização baseada em entidade de segurança, as permissões são avaliadas na ordem a seguir.

1️⃣ as atribuições de função do Azure são avaliadas primeiro e têm prioridade sobre atribuições de ACL.

:2️⃣ se a operação estiver completamente autorizada com base na atribuição de função do Azure, então as ACLs não serão avaliadas.

3️⃣ se a operação não estiver completamente autorizada, as ACLs serão avaliadas.

data lake storage permission flow

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

O seguinte diagrama 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.

data lake storage permission flow example

Tabela de permissões: combinando o RBAC do Azure e a ACL

A tabela a seguir mostra como combinar funções do Azure e entradas de ACL 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ório 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 Portlande um arquivo de texto no diretório Portland chamado Data.txt. A exibição dessas colunas é uma pequena representação abreviada da entrada de ACL necessária para conceder permissões. N/A (não aplicável) aparece na coluna se uma entrada de ACL não for necessária para executar a operação.

Operação Função do Azure atribuída / Oregon/ Portland/ Data.txt
Read Data.txt Proprietário de Dados do Blob de Armazenamento N/D N/D N/D N/D
Colaborador de dados de blob de armazenamento N/D N/D N/D N/D
Leitor de Dados do Blob de Armazenamento N/D N/D N/D N/D
Não --X --X --X R--
Append to Data.txt Proprietário de Dados do Blob de Armazenamento N/D N/D N/D N/D
Colaborador de dados de blob de armazenamento N/D N/D N/D N/D
Leitor de Dados do Blob de Armazenamento --X --X --X -W-
Não --X --X --X RW-
Delete Data.txt Proprietário de Dados do Blob de Armazenamento N/D N/D N/D N/D
Colaborador de dados de blob de armazenamento N/D N/D N/D N/D
Leitor de Dados do Blob de Armazenamento --X --X -WX N/D
Nenhum --X --X -WX N/D
Create Data.txt Proprietário de Dados do Blob de Armazenamento N/D N/D N/D N/D
Colaborador de dados de blob de armazenamento N/D N/D N/D N/D
Leitor de Dados do Blob de Armazenamento --X --X -WX N/D
Nenhum --X --X -WX N/D
List / Proprietário de Dados do Blob de Armazenamento N/D N/D N/D N/D
Colaborador de dados de blob de armazenamento N/D N/D N/D N/D
Leitor de Dados do Blob de Armazenamento N/D N/D N/D N/D
Nenhum R-X N/D N/D N/D
Lista /Oregon/ Proprietário de Dados do Blob de Armazenamento N/D N/D N/D N/D
Colaborador de dados de blob de armazenamento N/D N/D N/D N/D
Leitor de Dados do Blob de Armazenamento N/D N/D N/D N/D
Nenhum --X R-X N/D N/D
Lista /Oregon/Portland/ Proprietário de Dados do Blob de Armazenamento N/D N/D N/D N/D
Colaborador de dados de blob de armazenamento N/D N/D N/D N/D
Leitor de Dados do Blob de Armazenamento N/D N/D N/D N/D
Nenhum --X --X R-X N/D

Observação

Para ver o conteúdo de um contêiner no Gerenciador de Armazenamento do Azure, as entidades de segurança precisam entrar no Gerenciador de Armazenamento usando o Azure AD, e (no mínimo) ter acesso de leitura (R--) à pasta raiz (\) de um contêiner. Esse nível de permissão dá a eles a capacidade de listar o conteúdo da pasta raiz. Se você não quiser que o conteúdo da pasta raiz fique visível, poderá atribuir a eles a função 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 permitir acesso a diretórios e arquivos específicos usando ACLs.

Grupos de segurança

Sempre use os grupos de segurança do Azure AD como a entidade atribuída em uma entrada de ACL. Resista a oportunidade de atribuir diretamente a usuários individuais ou entidades de serviço. Usar essa estrutura permitirá que você adicione e remova usuários ou entidades de serviço sem a necessidade de reaplicar as ACLs para uma estrutura de diretório inteiro. Em vez disso, você pode apenas adicionar ou remover usuários e entidades de serviço do grupo de segurança apropriado do Azure AD.

Existem muitas maneiras diferentes de configurar grupos. Por exemplo, imagine que você tenha um diretório chamado /LogData que contém dados de log gerados pelo servidor. O ADF (Azure Data Factory) ingere dados para essa 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 do Databricks analisarão os logs dessa pasta.

Para habilitar essas atividades, você pode criar um grupo LogsWriter e um grupo LogsReader. 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 de entidade de serviço ou MSI (Identidade de Serviço Gerenciado) do ADF ao grupo LogsWriters.
  • Adicione usuários na equipe de engenharia de serviço ao grupo LogsWriter.
  • Adicione o objeto de entidade de serviço ou MSI para Databricks ao grupo LogsReader.

Se um usuário na equipe de engenharia de serviço sair da empresa, você poderá removê-lo do grupo LogsWriter. Se você não adicionasse esse usuário a um grupo, mas, em vez disso, adicionasse uma entrada ACL dedicada para esse usuário, você precisaria remover essa entrada ACL do diretório /LogData. Você também precisaria remover a entrada de todos os subdiretórios e arquivos na hierarquia de diretório inteira do diretório /LogData.

Se você precisar criar um grupo, confira Criar um grupo básico e adicionar membros usando o Azure Active Directory.

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

Usando grupos, você tem menor probabilidade de exceder o número máximo de atribuições de função por assinatura e o número máximo de entradas de ACL por arquivo ou diretório. A tabela a seguir descreve esses limites.

Mecanismo Escopo Limites Nível de permissão com suporte
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.
2000 atribuições de função do Azure em uma assinatura Funções do Azure (internas ou personalizadas)
ACL Diretório, arquivo 32 entradas de ACL (efetivamente 28 entradas de ACL) por arquivo e por diretório. As ACLs de acesso e padrão têm seu próprio limite de entrada de ACL 32. Permissão de ACL

A autorização de Chave Compartilhada e SAS (Assinatura de Acesso Compartilhado)

O Azure Data Lake Storage Gen2 também é compatível com os métodos Chave Compartilhada e SAS para autenticação. Uma característica desses métodos de autenticação é que nenhuma identidade é associada ao chamador e, portanto, a autorização baseada em permissão do usuário não pode ser executada.

No caso de Chave Compartilhada, o chamador obtém efetivamente acesso de “superusuário”, o que significa acesso completo a todas as operações em todos os recursos, incluindo a definição de proprietário e alteração de ACLs.

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

Próximas etapas

Para saber mais sobre as listas de controle de acesso, confira Gerenciar ACLs (listas de controle de acesso) no Azure Data Lake Storage Gen2.