Modelo de controlo de acesso em Azure Data Lake Storage Gen2

Data Lake Storage Gen2 suporta os seguintes mecanismos de autorização:

  • Autorização de Chave Partilhada
  • Autorização de assinatura de acesso partilhado (SAS)
  • Controlo de acesso baseado em funções (Azure RBAC)
  • Listas de controlo de acesso (ACL)

A autorização da Shared Key e da SAS concede acesso a um utilizador (ou aplicação) sem que os exija ter uma identidade no Azure Ative Directory (Azure AD). Com estas duas formas de autenticação, os RBAC e acLs Azure não têm qualquer efeito.

A Azure RBAC e ACL exigem que o utilizador (ou aplicação) tenha uma identidade em Azure AD. O Azure RBAC permite-lhe conceder acesso "grosso a dados da conta de armazenamento", tais como ler ou escrever acesso a todos os dados numa conta de armazenamento, enquanto os ACLs permitem conceder acesso "fino", como escrever acesso a um diretório ou ficheiro específico.

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

Controlo de acesso baseado em funções (Azure RBAC)

A Azure RBAC utiliza atribuições de funções para aplicar conjuntos de permissões aos princípios de segurança. Um principal de segurança é um objeto que representa um utilizador, grupo, diretor de serviço ou identidade gerida que é definido no Azure Ative Directy (AD). Um conjunto de permissões pode dar a um diretor de segurança um nível de acesso "grosso",, como ler ou escrever acesso a todos os dados numa conta de armazenamento ou a todos os dados num recipiente.

As seguintes funções permitem a um diretor de segurança aceder aos dados numa conta de armazenamento.

Função Description
Proprietário dos Dados do Armazenamento de Blobs Acesso total a recipientes e dados de armazenamento Blob. Este acesso permite ao titular de segurança definir um item ao proprietário e modificar os ACLs de todos os itens.
Contribuinte de Dados do Armazenamento de Blobs Leia, escreva e elimine o acesso a recipientes de armazenamento Blob e bolhas. Este acesso não permite ao diretor de segurança definir a propriedade de um item, mas pode modificar a ACL de itens que são propriedade do responsável pela segurança.
Leitor de Dados do Armazenamento de Blobs Leia e enuncie os recipientes de armazenamento Blob e as bolhas.

Funções como Proprietário, Contribuinte, Leitore Contribuinte de Conta de Armazenamento permitem a um responsável de segurança gerir uma conta de armazenamento, mas não fornecem acesso aos dados dentro dessa conta. No entanto, estas funções (excluindo o Leitor) podem obter acesso às chaves de armazenamento, que podem ser usadas em várias ferramentas do cliente para aceder aos dados.

Listas de controlo de acesso (ACL)

Os ACLs dão-lhe a capacidade de aplicar o nível de acesso "mais fino" a diretórios e ficheiros. Um ACL é uma construção de permissão que contém uma série de entradas ACL. Cada entrada da ACL associa o principal de segurança a um nível de acesso. Para saber mais, consulte as listas de controlo de acesso (ACLs) em Azure Data Lake Storage Gen2.

Como as permissões são avaliadas

Durante a autorização principal de segurança, as permissões são avaliadas na seguinte ordem.

:um:     As atribuições de funções Azure são avaliadas em primeiro lugar e têm prioridade sobre quaisquer atribuições da ACL.

:2:     Se a operação for totalmente autorizada com base na atribuição de funções Azure, então os ACLs não são avaliados de todo.

:três:     Se a operação não estiver totalmente autorizada, então os ACLs são avaliados.

fluxo de permissão de armazenamento de lago de dados

Devido à forma como as permissões de acesso são avaliadas pelo sistema, não é possível utilizar um ACL para restringir o acesso que já foi concedido por uma atribuição de funções. Isto porque o sistema avalia primeiro as atribuições de funções do Azure, e se a atribuição conceder permissão de acesso suficiente, os ACLs são ignorados.

O diagrama a seguir mostra o fluxo de permissão para três operações comuns: listar conteúdos de diretórios, ler um ficheiro e escrever um ficheiro.

exemplo de fluxo de permissão de armazenamento de lago de dados

Tabela de permissões: Combinação de Azure RBAC e ACL

A tabela que se segue mostra-lhe como combinar funções Azure e entradas ACL para que um diretor 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 fictícia do diretório. Há uma coluna para o diretório de raiz do contentor , / um subdiretório chamado Oregon, um subdiretório do diretório do Oregon chamado Portland, e um ficheiro de texto no diretório de Portland chamado Data.txt. Aparecendo nessas colunas são representações de forma curta da entrada ACL necessárias para conceder permissões. N/A (Não aplicável) aparece na coluna se não for necessária uma entrada ACL para realizar a operação.

Operação Papel Azure atribuído / Oregon/ Portland/ Data.txt
Leia Data.txt Proprietário dos Dados do Armazenamento de Blobs N/D N/D N/D N/D
Contribuinte de Dados do Armazenamento de Blobs N/D N/D N/D N/D
Leitor de Dados do Armazenamento de Blobs N/D N/D N/D N/D
Nenhum --X --X --X R--
Apêndice a Data.txt Proprietário dos Dados do Armazenamento de Blobs N/D N/D N/D N/D
Contribuinte de Dados do Armazenamento de Blobs N/D N/D N/D N/D
Leitor de Dados do Armazenamento de Blobs --X --X --X -W-
Nenhum --X --X --X RW-
Apagar Data.txt Proprietário dos Dados do Armazenamento de Blobs N/D N/D N/D N/D
Contribuinte de Dados do Armazenamento de Blobs N/D N/D N/D N/D
Leitor de Dados do Armazenamento de Blobs --X --X -WX N/D
Nenhum --X --X -WX N/D
Criar Data.txt Proprietário dos Dados do Armazenamento de Blobs N/D N/D N/D N/D
Contribuinte de Dados do Armazenamento de Blobs N/D N/D N/D N/D
Leitor de Dados do Armazenamento de Blobs --X --X -WX N/D
Nenhum --X --X -WX N/D
Lista / Proprietário dos Dados do Armazenamento de Blobs N/D N/D N/D N/D
Contribuinte de Dados do Armazenamento de Blobs N/D N/D N/D N/D
Leitor de Dados do Armazenamento de Blobs N/D N/D N/D N/D
Nenhum R-X N/D N/D N/D
Lista /Oregon/ Proprietário dos Dados do Armazenamento de Blobs N/D N/D N/D N/D
Contribuinte de Dados do Armazenamento de Blobs N/D N/D N/D N/D
Leitor de Dados do Armazenamento de Blobs N/D N/D N/D N/D
Nenhum --X R-X N/D N/D
Lista /Oregon/Portland/ Proprietário dos Dados do Armazenamento de Blobs N/D N/D N/D N/D
Contribuinte de Dados do Armazenamento de Blobs N/D N/D N/D N/D
Leitor de Dados do Armazenamento de Blobs N/D N/D N/D N/D
Nenhum --X --X R-X N/D

Nota

Para visualizar o conteúdo de um contentor no Azure Storage Explorer, os princípios de segurança devem inscrever-se no Storage Explorer utilizando a Azure AD, e (no mínimo) ler o acesso (R--) à pasta raiz ( \ ) de um recipiente. 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 seja visível, pode atribuir-lhes o papel de Leitor. Com esse papel, poderão listar os contentores na conta, mas não o conteúdo do contentor. Em seguida, pode conceder acesso a diretórios e ficheiros específicos utilizando ACLs.

Grupos de segurança

Utilize sempre os grupos de segurança Azure AD como o principal designado numa entrada ACL. Resista à oportunidade de atribuir diretamente aos utilizadores individuais ou aos principais de serviço. A utilização desta estrutura permitir-lhe-á adicionar e remover utilizadores ou diretores de serviço sem a necessidade de reaplicar ACLs a toda uma estrutura de diretório. Em vez disso, pode apenas adicionar ou remover utilizadores e principais de serviço do grupo de segurança Azure AD apropriado.

Há muitas maneiras diferentes de criar grupos. Por exemplo, imagine que tem um diretório chamado /LogData que contém dados de registo que são gerados pelo seu servidor. A Azure Data Factory (ADF) ingere dados nessa pasta. Utilizadores específicos da equipa de engenharia de serviços irão carregar registos e gerir outros utilizadores desta pasta, e vários clusters databricks irão analisar registos dessa pasta.

Para ativar estas atividades, pode criar um LogsWriter grupo e um LogsReader grupo. Em seguida, pode atribuir permissões da seguinte forma:

  • 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 identidade de serviço gerido (MSI) para ADF ao LogsWriters grupo.
  • Adicione os utilizadores na equipa de engenharia de serviços ao LogsWriter grupo.
  • Adicione o objeto principal de serviço ou MSI para databricks ao LogsReader grupo.

Se um utilizador da equipa de engenharia de serviços deixar a empresa, pode simplesmente removê-los do LogsWriter grupo. Se não adicionou esse utilizador a um grupo, mas em vez disso, adicionou uma entrada ACL dedicada para esse utilizador, teria de remover essa entrada ACL do diretório /LogData. Também teria de remover a entrada de todas as subdireções e ficheiros em toda a hierarquia do diretório do diretório /LogData.

Para criar um grupo e adicionar membros, consulte criar um grupo básico e adicionar membros usando o Azure Ative Directory.

Limites nas atribuições de funções Azure e entradas da 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 estes limites.

Mecanismo Âmbito Limites Nível de permissão suportado
RBAC do Azure Contas de armazenamento, contentores.
Designação de funções de recurso cross azure a nível de subscrição ou grupo de recursos.
Atribuições de funções Azure 2000 numa subscrição Funções Azure (incorporado ou personalizado)
ACL Diretório, arquivo 32 entradas ACL (efetivamente 28 entradas ACL) por ficheiro e por diretório. Os ACLs de acesso e padrão têm cada um o seu próprio limite de entrada de 32 ACL. Permissão ACL

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

A Azure Data Lake Storage Gen2 também suporta métodos de chave partilhada e SAS para a autenticação. Uma característica destes métodos de autenticação é que nenhuma identidade está associada ao chamador e, portanto, a autorização baseada na autorização principal de segurança não pode ser realizada.

No caso da Chave Partilhada, o chamador obtém efetivamente acesso a 'super-utilizador', o que significa acesso total a todas as operações em todos os recursos, incluindo dados, definição do 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 SAS são efetivamente aplicadas a todas as decisões de autorização, mas não são realizados controlos adicionais da ACL.

Passos seguintes

Para saber mais sobre as listas de controlo de acesso, consulte as listas de controlo de acesso (ACLs) em Azure Data Lake Storage Gen2.