Listas de controle de acesso (ACLs) no Azure Data Lake Storage Gen2

  • Artigo

O Azure Data Lake Storage Gen2 implementa um modelo de controle de acesso que dá suporte ao controle de acesso baseado em função do Azure (Azure RBAC) e às ACLs (listas de controle de acesso) semelhantes ao POSIX. Este artigo descreve as listas de controle de acesso no Data Lake Storage Gen2. Para saber como incorporar o RBAC do Azure junto com ACLs e como o sistema as avalia para tomar decisões de autorização, consulte Modelo de controle de acesso no Azure Data Lake Storage Gen2.

Sobre ACLs

Você pode associar uma entidade de segurança a um nível de acesso para arquivos e diretórios. Cada associação é capturada como uma entrada em uma lista de controle de acesso (ACL). Cada arquivo e diretório em sua conta de armazenamento tem uma lista de controle de acesso. Quando uma entidade de segurança tenta uma operação em um arquivo ou diretório, uma verificação de ACL determina se essa entidade de segurança (usuário, grupo, entidade de serviço ou identidade gerenciada) tem o nível de permissão correto para executar a operação.

Nota

As ACLs aplicam-se apenas a entidades de segurança no mesmo inquilino e não se aplicam a utilizadores que utilizam a autenticação de token de Chave Partilhada ou de assinatura de acesso partilhado (SAS). Isso ocorre porque 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.

Como definir ACLs

Para definir ao nível do ficheiro e do diretório, consulte qualquer um dos artigos seguintes:

Ambiente Artigo
Explorador de Armazenamento do Azure Usar o Gerenciador de Armazenamento do Azure para gerenciar ACLs no Azure Data Lake Storage Gen2
Portal do Azure Usar o portal do Azure para gerenciar ACLs no Azure Data Lake Storage Gen2
.NET Usar o .NET para gerenciar ACLs no Azure Data Lake Storage Gen2
Java Usar Java para gerenciar ACLs no Azure Data Lake Storage Gen2
Python Usar Python para gerenciar ACLs no Azure Data Lake Storage Gen2
JavaScript (Node.js) Use o SDK JavaScript no Node.js para gerenciar ACLs no Azure Data Lake Storage Gen2
PowerShell Usar o PowerShell para gerenciar ACLs no Azure Data Lake Storage Gen2
CLI do Azure Usar a CLI do Azure para gerenciar ACLs no Azure Data Lake Storage Gen2
API REST Caminho - Atualização

Importante

Se a entidade de segurança for uma entidade de serviço, é importante usar a ID do objeto da entidade de serviço e não a ID do objeto do registro do aplicativo relacionado. Para obter a ID do objeto da entidade de serviço, abra a CLI do Azure e use este comando: az ad sp show --id <Your App ID> --query objectId. Certifique-se de substituir o espaço reservado <Your App ID> pela ID do aplicativo do registro do aplicativo. A entidade de serviço é tratada como um usuário nomeado. Você adicionará essa ID à ACL como faria com qualquer usuário nomeado. Os usuários nomeados são descritos posteriormente neste artigo.

Tipos de ACLs

Existem dois tipos de listas de controle de acesso: ACLs de acesso e ACLs padrão.

As ACLs de acesso controlam o acesso a um objeto. Arquivos e diretórios têm ACLs de acesso.

As ACLs padrão são modelos de ACLs associadas a um diretório que determinam as ACLs de acesso para quaisquer itens filho criados nesse diretório. Os arquivos não têm ACLs padrão.

Tanto as ACLs de acesso quanto as ACLs padrão têm a mesma estrutura.

Nota

Alterar a ACL predefinida num item principal não afeta a ACL de acesso ou a ACL predefinida de itens subordinados que já existem.

Níveis de permissão

As permissões em diretórios e arquivos em um contêiner são Leitura, Gravação e Execução, e podem ser usadas em arquivos e diretórios, conforme mostrado na tabela a seguir:

Ficheiro Diretório
Leitura (R) Pode editar o conteúdo de um ficheiro Requer Ler e Executar para listar o conteúdo do diretório
Escrita (W) Pode escrever ou acrescentar a um ficheiro Requer Write and Execute para criar itens filho em um diretório
Execução (X) Não significa nada no contexto do Data Lake Storage Gen2 Necessário para percorrer os itens filho de um diretório

Nota

Se você estiver concedendo permissões usando apenas ACLs (sem RBAC do Azure), para conceder a uma entidade de segurança acesso de leitura ou gravação a um arquivo, será necessário conceder à entidade de segurança permissões Executar para a pasta raiz do contêiner e para cada pasta na hierarquia de pastas que levam ao arquivo.

Formatos curtos para as permissões

O RWX é utilizado para indicar Leitura + Escrita + Execução. Existe um formato numérico mais condensado, em que Leitura=4, Escrita=2 e Execução=1, cuja respetiva soma representa as permissões. Abaixo, encontram-se alguns exemplos.

Formato numérico Formato curto O que significa
7 RWX Leitura + Escrita + Execução
5 R-X Leitura + Execução
4 R-- Lida
0 --- Sem permissões

Herança de permissões

No modelo de estilo POSIX utilizado pelo Data Lake Storage Gen2, as permissões para um item são armazenadas no próprio item. Por outras palavras, as permissões para um item não podem ser herdadas dos itens principais se as permissões forem definidas depois de o item subordinado já ter sido criado. As permissões apenas são herdadas se as permissões predefinidas tiverem sido definidas nos itens principais antes de os itens subordinados terem sido criados.

A tabela a seguir mostra as entradas de ACL necessárias para permitir que uma entidade de segurança execute 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.

Importante

Esta tabela pressupõe que você esteja usando apenas ACLs sem nenhuma atribuição de função do Azure. Para ver uma tabela semelhante que combina o RBAC do Azure com ACLs, consulte Tabela de permissões: combinando RBAC do Azure, ABAC e ACLs.

Operação / Oregon/ Portland/ Dados.txt
Leia os dados.txt --X --X --X R--
Anexar aos dados.txt --X --X --X RW-
Excluir dados.txt --X --X -WX ---
Criar dados.txt --X --X -WX ---
Lista / R-X --- --- ---
Lista /Oregon/ --X R-X --- ---
Lista /Oregon/Portland/ --X --X R-X ---

Nota

As permissões de gravação no arquivo não são necessárias para excluí-lo, desde que as duas condições anteriores sejam verdadeiras.

Utilizadores e identidades

Cada arquivo e diretório tem permissões distintas para essas identidades:

  • O utilizador proprietário
  • O grupo proprietário
  • Utilizadores nomeados
  • Grupos nomeados
  • Entidades de serviço nomeadas
  • Identidades gerenciadas nomeadas
  • Todos os outros utilizadores

As identidades de usuários e grupos são identidades do Microsoft Entra. Portanto, a menos que indicado de outra forma, um usuário, no contexto do Data Lake Storage Gen2, pode se referir a um usuário do Microsoft Entra, entidade de serviço, identidade gerenciada ou grupo de segurança.

O superutilizador

Um superutilizador tem o maior número de direitos de todos os utilizadores. O superutilizador:

  • Tem permissões de RWX para todos os ficheiros e pastas.

  • Pode alterar as permissões em qualquer ficheiro ou pasta.

  • Pode alterar o utilizador proprietário ou grupo proprietário de qualquer ficheiro ou pasta.

Se um contêiner, arquivo ou diretório for criado usando a Chave Compartilhada, uma SAS de Conta ou uma SAS de Serviço, o proprietário e o grupo proprietário serão definidos como $superuser.

O utilizador proprietário

O utilizador que criou o item é automaticamente o utilizador proprietário do item. Um utilizador proprietário pode:

  • Alterar as permissões de um ficheiro que é propriedade.
  • Alterar o grupo proprietário de um ficheiro que é propriedade, desde que o utilizador proprietário também seja membro do grupo de destino.

Nota

O usuário proprietário não pode alterar o usuário proprietário de um arquivo ou diretório. Somente superusuários podem alterar o usuário proprietário de um arquivo ou diretório.

O grupo proprietário

Nas ACLs POSIX, cada usuário está associado a um grupo primário. Por exemplo, o usuário "Alice" pode pertencer ao grupo "finanças". Alice também pode pertencer a vários grupos, mas um grupo é sempre designado como seu grupo principal. No POSIX, quando Alice cria um arquivo, o grupo proprietário desse arquivo é definido como seu grupo principal, que neste caso é "finanças". Caso contrário, o grupo proprietário se comporta de forma semelhante às permissões atribuídas para outros usuários/grupos.

Atribuindo o grupo proprietário para um novo arquivo ou diretório

  • Caso 1: O diretório /raiz . Esse diretório é criado quando um contêiner Data Lake Storage Gen2 é criado. Nesse caso, o grupo proprietário é definido como o usuário que criou o contêiner se ele foi feito usando OAuth. Se o contêiner for criado usando a Chave Compartilhada, uma SAS de Conta ou uma SAS de Serviço, o proprietário e o grupo proprietário serão definidos como $superuser.
  • Caso 2 (todos os outros casos): Quando um novo item é criado, o grupo proprietário é copiado do diretório pai.

Alterar o grupo proprietário

O grupo proprietário pode ser alterado por:

  • Qualquer superutilizador.
  • Pelo utilizador proprietário, se o utilizador proprietário também for membro do grupo de destino.

Nota

O grupo proprietário não pode alterar as ACLs de um arquivo ou diretório. Embora o grupo proprietário seja definido como o usuário que criou a conta no caso do diretório raiz, Caso 1 acima, uma única conta de usuário não é válida para fornecer permissões por meio do grupo proprietário. Pode atribuir esta permissão a um grupo de utilizadores válido, se aplicável.

Como são avaliadas as permissões

As identidades são avaliadas na seguinte ordem:

  1. Superutilizador
  2. Utilizador proprietário
  3. Usuário nomeado, entidade de serviço ou identidade gerenciada
  4. Proprietário de grupo ou grupo nomeado
  5. Todos os outros utilizadores

Se mais de uma dessas identidades se aplicar a uma entidade de segurança, o nível de permissão associado à primeira identidade será concedido. Por exemplo, se uma entidade de segurança for o usuário proprietário e um usuário nomeado, o nível de permissão associado ao usuário proprietário será aplicado.

Os grupos nomeados são todos considerados em conjunto. Se uma entidade de segurança for membro de mais de um grupo nomeado, o sistema avaliará cada grupo até que a permissão desejada seja concedida. Se nenhum dos grupos nomeados fornecer a permissão desejada, o sistema passará a avaliar uma solicitação em relação à permissão associada a todos os outros usuários.

O pseudocódigo a seguir representa o algoritmo de verificação de acesso para contas de armazenamento. Este algoritmo mostra a ordem em que as identidades são avaliadas.

def access_check( user, desired_perms, path ) :
  # access_check returns true if user has the desired permissions on the path, false otherwise
  # user is the identity that wants to perform an operation on path
  # desired_perms is a simple integer with values from 0 to 7 ( R=4, W=2, X=1). User desires these permissions
  # path is the file or directory
  # Note: the "sticky bit" isn't illustrated in this algorithm

  # Handle super users.
  if (is_superuser(user)) :
    return True

  # Handle the owning user. Note that mask isn't used.
  entry = get_acl_entry( path, OWNER )
  if (user == entry.identity)
      return ( (desired_perms & entry.permissions) == desired_perms )

  # Handle the named users. Note that mask IS used.
  entries = get_acl_entries( path, NAMED_USER )
  for entry in entries:
      if (user == entry.identity ) :
          mask = get_mask( path )
          return ( (desired_perms & entry.permissions & mask) == desired_perms)

  # Handle named groups and owning group
  member_count = 0
  perms = 0
  entries = get_acl_entries( path, NAMED_GROUP | OWNING_GROUP )
  mask = get_mask( path )
  for entry in entries:
    if (user_is_member_of_group(user, entry.identity)) :
        if ((desired_perms & entry.permissions & mask) == desired_perms)
            return True

  # Handle other
  perms = get_perms_for_other(path)
  mask = get_mask( path )
  return ( (desired_perms & perms & mask ) == desired_perms)

A máscara

Conforme ilustrado no Algoritmo de Verificação de Acesso, a máscara limita o acesso de usuários nomeados, do grupo proprietário e dos grupos nomeados.

Para um novo contêiner do Data Lake Storage Gen2, a máscara para a ACL de acesso do diretório raiz ("/") tem como padrão 750 para diretórios e 640 para arquivos. A tabela a seguir mostra a notação simbólica desses níveis de permissão.

Entity Directories Files
Utilizador proprietário rwx rw-
Grupo proprietário r-x r--
Outro --- ---

Os arquivos não recebem o bit X, pois é irrelevante para os arquivos em um sistema somente de armazenamento.

A máscara pode ser especificada por chamada. Isso permite que diferentes sistemas consumidores, como clusters, tenham diferentes máscaras eficazes para suas operações de arquivo. Se uma máscara for especificada em uma determinada solicitação, ela substituirá completamente a máscara padrão.

O sticky bit

O bit pegajoso é um recurso mais avançado de um contêiner POSIX. No contexto do Data Lake Storage Gen2, é improvável que o bit adesivo seja necessário. Em resumo, se o bit adesivo estiver habilitado em um diretório, um item filho só poderá ser excluído ou renomeado pelo usuário proprietário do item filho, pelo proprietário do diretório ou pelo Superusuário ($superuser).

O bit adesivo não é mostrado no portal do Azure.

Permissões padrão em novos arquivos e diretórios

Quando um novo ficheiro ou diretório são criados num diretório existente, a ACL predefinida no diretório principal determina:

  • A ACL predefinida e a ACL de acesso do diretório subordinado.
  • A ACL de acesso do ficheiro subordinado (os ficheiros não têm ACLs predefinidas).

umask

Ao criar uma ACL padrão, o umask é aplicado à ACL de acesso para determinar as permissões iniciais de uma ACL padrão. Se uma ACL padrão for definida no diretório pai, o umask será efetivamente ignorado e a ACL padrão do diretório pai será usada para definir esses valores iniciais.

O umask é um valor de 9 bits em diretórios pai que contém um valor RWX para proprietário de usuário, grupo proprietário e outros.

O umask para Azure Data Lake Storage Gen2 um valor constante que é definido como 007. Este valor traduz-se em:

componente umask Formato numérico Formato curto Significado
umask.owning_user 0 --- Para o usuário proprietário, copie a ACL de acesso do pai para a ACL padrão da criança
umask.owning_group 0 --- Para o grupo proprietário, copie a ACL de acesso do pai para a ACL padrão da criança
umask.outro 7 RWX Por outro lado, remova todas as permissões na ACL de acesso da criança

FAQ

É necessário ativar o suporte para as ACLs?

Não O controle de acesso via ACLs está habilitado para uma conta de armazenamento, desde que o recurso Namespace Hierárquico (HNS) esteja ativado.

Se o HNS estiver desativado, as regras de autorização do RBAC do Azure ainda se aplicam.

Qual é a melhor maneira de aplicar ACLs?

Sempre use 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 grupo e um LogsWriterLogsReader 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, você teria que 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.

Como as permissões de RBAC e ACL do Azure são avaliadas?

Para saber como o sistema avalia o RBAC do Azure e as ACLs juntas para tomar decisões de autorização para recursos de conta de armazenamento, consulte Como as permissões são avaliadas.

Quais são os limites para atribuições de função do Azure e entradas de ACL?

A tabela a seguir fornece uma exibição resumida dos limites a serem considerados ao usar o RBAC do Azure para gerenciar permissões "de grão grosso" (permissões que se aplicam a contas de armazenamento ou contêineres) e ao usar ACLs para gerenciar permissões "refinadas" (permissões que se aplicam a arquivos e diretórios). Utilize grupos de segurança para atribuições 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.

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 de ACL

O Data Lake Storage Gen2 dá suporte à herança do Azure RBAC?

As atribuições de função do Azure herdam. As atribuições fluem de recursos de assinatura, grupo de recursos e conta de armazenamento até o recurso de contêiner.

O Data Lake Storage Gen2 suporta herança de ACLs?

As ACLs padrão podem ser usadas para definir ACLs para novos subdiretórios filho e arquivos criados no diretório pai. Para atualizar ACLs para itens filho existentes, você precisará adicionar, atualizar ou remover ACLs recursivamente para a hierarquia de diretórios desejada. Para obter orientações, consulte a seção Como definir ACLs deste artigo.

Quais permissões são necessárias para excluir recursivamente um diretório e seu conteúdo?

  • O chamador tem permissões de 'superusuário',

Ou

  • O diretório pai deve ter permissões Write + Execute.
  • O diretório a ser excluído, e cada diretório dentro dele, requer permissões de Leitura + Gravação + Execução.

Nota

Você não precisa de permissões de gravação para excluir arquivos em diretórios. Além disso, o diretório raiz "/" nunca pode ser excluído.

Quem é o proprietário de um arquivo ou diretório?

O criador de um arquivo ou diretório torna-se o proprietário. No caso do diretório raiz, essa é a identidade do usuário que criou o contêiner.

Qual grupo é definido como o grupo proprietário de um arquivo ou diretório na criação?

O grupo proprietário é copiado do grupo proprietário do diretório pai sob o qual o novo arquivo ou diretório é criado.

Sou o utilizador proprietário de um ficheiro, mas não tenho as permissões RWX de que necessito. O que posso fazer?

O utilizador proprietário pode alterar as permissões do ficheiro para atribuir as permissões de RWX necessárias a ele próprio.

Por que às vezes vejo GUIDs em ACLs?

Um GUID é mostrado se a entrada representa um usuário e esse usuário não existe mais no Microsoft Entra. Normalmente, isso acontece quando o usuário deixou a empresa ou se sua conta foi excluída no Microsoft Entra ID. Além disso, entidades de serviço e grupos de segurança não têm um nome principal de usuário (UPN) para identificá-los e, portanto, eles são representados por seu atributo OID (um guid). Para limpar as ACLs, exclua manualmente essas entradas GUID.

Como devo proceder para configurar ACLs corretamente para um principal de serviço?

Ao definir ACLs para entidades de serviço, é importante usar a ID de objeto (OID) da entidade de serviço para o registro de aplicativo que você criou. É importante observar que os aplicativos registrados têm uma entidade de serviço separada no locatário específico do Microsoft Entra. Os aplicativos registrados têm um OID visível no portal do Azure, mas a entidade de serviço tem outro OID (diferente). Artigo Para obter o OID para a entidade de serviço que corresponde a um registro de aplicativo, você pode usar o az ad sp show comando. Especifique o ID da aplicação como o parâmetro. Segue-se um exemplo de obtenção do OID para o principal de serviço que corresponde ao registo de uma aplicação com ID de Aplicação = 18218b12-1895-43e9-ad80-6e8fc1ea88ce. Execute o seguinte comando na CLI do Azure:

az ad sp show --id 18218b12-1895-43e9-ad80-6e8fc1ea88ce --query objectId

O OID será apresentado.

Quando você tiver o OID correto para a entidade de serviço, vá para a página Storage Explorer Manage Access para adicionar o OID e atribuir permissões apropriadas para o OID. Certifique-se de selecionar Salvar

Posso definir a ACL de um contêiner?

Não Um contêiner não tem uma ACL. No entanto, você pode definir a ACL do diretório raiz do contêiner. Cada contêiner tem um diretório raiz e compartilha o mesmo nome que o contêiner. Por exemplo, se o contêiner for nomeado my-container, o diretório raiz será chamado my-container/.

A API REST do Armazenamento do Azure contém uma operação chamada Definir ACL de Contêiner, mas essa operação não pode ser usada para definir a ACL de um contêiner ou o diretório raiz de um contêiner. Em vez disso, essa operação é usada para indicar se os blobs em um contêiner podem ser acessados com uma solicitação anônima. Recomendamos exigir autorização para todas as solicitações de dados de blob. Para obter mais informações, consulte Visão geral: corrigindo o acesso de leitura anônimo para dados de blob.

Onde posso obter mais informações sobre o modelo de controlo de acesso POSIX?

Consulte também