ACLs (Listas de controle de acesso) no Azure Data Lake Storage Gen2
O Azure Data Lake Storage Gen2 implementa um modelo de controle de acesso que oferece suporte ao controle de acesso baseado em função do Azure (Azure RBAC) e listas de controle de acesso (ACLs) do tipo POSIX. Este artigo descreve as listas de controle de acesso no Data Lake Storage Gen2. Para saber mais sobre como incorporar o RBAC do Azure junto com ACLs e como o sistema os 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 ACL (lista de controle de acesso) . Cada arquivo e diretório na sua conta de armazenamento tem uma lista de controle de acesso. Quando uma entidade de segurança tenta executar uma operação em um arquivo ou diretório, uma verificação ACL determina se a 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.
Observação
As ACLs se aplicam somente a entidades de segurança no mesmo locatário e não se aplicam a usuários que usam a autenticação de token de chave compartilhada ou de assinatura de acesso compartilhado (SAS). Isso porque nenhuma identidade está associada ao chamador e, portanto, a autorização baseada em permissão de entidade de segurança não pode ser executada.
Como definir ACLs
Para definir permissões de nível de arquivo e diretório, consulte qualquer um dos seguintes artigos:
Importante
Se a entidade de segurança for uma entidade de serviço, é importante usar a ID de objeto da entidade de serviço e não a ID de objeto do registro do aplicativo relacionado. Para obter a ID de objeto da entidade de serviço, abra o CLI do Azure e, em seguida, use este comando: az ad sp show --id <Your App ID> --query objectId. Certifique-se de substituir o espaço reservado <Your App ID> pelo ID do aplicativo do registro do aplicativo. A entidade de serviço é tratada como um usuário nomeado. Você adicionará esse ID à ACL como faria com qualquer usuário nomeado. Os usuários nomeados são descritos posteriormente neste artigo.
Tipos de ACLs
Há dois tipos de listas de controle de acesso: ACLs de Acesso e ACLs Padrão.
ACLs de acesso controlam o acesso a um objeto. Arquivos e diretórios têm ambos ACLs de acesso.
ACLs padrão são modelos de ACLs associados a um diretório que determina as ACLs de acesso para todos os itens filho criados nesse diretório. Arquivos não têm ACLs padrão.
As ACLs de Acesso e as ACLs Padrão têm a mesma estrutura.
Observação
Alterar a ACL Padrão em um pai não afeta o a ACL de Acesso ou a ACL Padrão de itens filhos já existentes.
Níveis de permissão
As permissões em diretórios e arquivos em um contêiner são de Leitura, Gravação, e Execução e podem ser usadas em arquivos e diretórios, conforme mostrado na seguinte tabela:
| Arquivo | Diretório | |
|---|---|---|
| Ler (R) | Pode ler o conteúdo de um arquivo | Requer Ler e Executar para listar o conteúdo do diretório |
| Gravar (W) | Pode gravar ou anexar a um arquivo | Requer Gravar e Executar para criar itens filhos em um diretório |
| Executar (X) | Não significa nada no contexto do Azure Data Lake Storage Gen2 | Necessário para percorrer os itens filhos de um diretório |
Observação
Se você estiver concedendo permissões usando somente ACLs (sem Azure RBAC), para conceder a uma entidade de segurança acesso de leitura ou de gravação a um arquivo, você precisará fornecer à entidade de segurança permissões de execução para a pasta raiz do contêiner e para cada pasta na hierarquia de pastas que levam ao arquivo.
Formatos abreviados para permissões
RWXé usado para indicar Ler + Gravar + Executar. Existe um formato numérico mais condensado na qual Ler = 4, Gravar = 2 e Executar = 1 e sua soma representa as permissões. Estes são alguns exemplos:
| Formato numérico | Formato curto | O que significa |
|---|---|---|
| 7 | RWX |
Ler + Gravar + Executar |
| 5 | R-X |
Ler + Executar |
| 4 | R-- |
Ler |
| 0 | --- |
Nenhuma permissão |
Herança de permissões
No modelo de estilo POSIX usado pelo Data Lake Storage Gen2, as permissões para um item são armazenadas no próprio item. Em outras palavras, as permissões para um item não podem ser herdadas dos itens pai se as permissões são definidas depois que o item filho já foi criado. As permissões são herdadas somente se as permissões padrão tiverem sido definidas nos itens pai antes dos itens filho terem sido criados.
Cenários comuns relacionados a permissões ACL
A tabela a seguir mostra as entradas de ACL necessárias para habilitar uma entidade de segurança para 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.
Importante
Esta tabela pressupõe que você está usando somente ACLs sem nenhuma atribuição de função do Azure. Para ver uma tabela semelhante que combina o Azure RBAC com ACLs, confira Tabela de permissões: combinando o Azure RBAC, ABAC e ACLs.
| Operação | / | Oregon/ | Portland/ | Data.txt |
|---|---|---|---|---|
| Read Data.txt | --X |
--X |
--X |
R-- |
| Append to Data.txt | --X |
--X |
--X |
RW- |
| Delete Data.txt | --X |
--X |
-WX |
--- |
| Excluir /Oregon/ | -WX |
RWX |
RWX |
RWX |
| Excluir /Oregon/Portland/ | --X |
-WX |
RWX |
RWX |
| Create Data.txt | --X |
--X |
-WX |
--- |
| List / | R-X |
--- |
--- |
--- |
| Lista /Oregon/ | --X |
R-X |
--- |
--- |
| Lista /Oregon/Portland/ | --X |
--X |
R-X |
--- |
Excluindo arquivos e diretórios
Conforme mostrado na tabela anterior, 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. No entanto, para excluir um diretório e todo o seu conteúdo, o diretório pai deve ter permissões Gravar + Executar. O diretório a ser excluído, e todas as pastas nela, exige permissões Ler + Gravar + Executar.
Observação
O diretório raiz "/" nunca pode ser excluído.
Usuários e identidades
Todos os arquivos e diretórios têm permissões diferentes para estas identidades:
- O usuário proprietário
- O grupo proprietário
- Usuários nomeados
- Grupos nomeados
- Todas as entidades de serviço
- Identidades gerenciadas nomeadas
- Todos os outros usuários
As identidades de usuários e grupos são identidades do Microsoft Entra. Portanto, a menos que indicado o contrário, um usuário, no contexto do Azure 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 superusuário
Um superusuário tem a maioria dos direitos de todos os usuários. Um superusuário:
Tem Permissões RWX para todos os arquivos e pastas.
Pode alterar as permissões em qualquer arquivo ou pasta.
Pode alterar o usuário proprietário ou o grupo proprietário de qualquer arquivo ou pasta.
Se um contêiner, arquivo ou diretório for criado usando a chave compartilhada, um SAS de conta ou um SAS de serviço, o proprietário e o grupo proprietário serão definidos como $superuser.
O usuário proprietário
O usuário que criou o item é automaticamente o usuário proprietário do item. Um usuário proprietário pode:
- Altere as permissões de um arquivo pertencente.
- Alterar o grupo proprietário de um arquivo pertencente, contanto que o usuário proprietário também seja membro do grupo de destino.
Observação
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 do POSIX, cada usuário está associado a um grupo primário. Por exemplo, o usuário "Alice" pode pertencer ao grupo "finanças". Alice pode pertencer também a vários grupos, mas um grupo será sempre designado como o grupo primário dela. No POSIX, quando Alice cria um arquivo, o grupo de propriedade desse arquivo é definido como seu grupo principal, que, nesse caso, é "finanças". Caso contrário, o grupo de propriedade se comporta de forma semelhante às permissões atribuídas a outros usuários/grupos.
Atribuindo o grupo proprietário de um novo arquivo ou diretório
- Caso 1: o diretório raiz
/. Esse diretório é criado quando um contêiner do Azure Data Lake Storage Gen2 é criado. Nesse caso, o grupo proprietário é definido para o usuário que criou o contêiner se tivesse sido feito usando o OAuth. Se o contêiner é criado usando a chave compartilhada, uma Conta SAS, ou Serviço SAS, então o proprietário ou grupo de proprietário são definidos para o$superuser. - Caso 2 (Todos os outros casos): quando um item é criado, o grupo proprietário é copiado da pasta pai.
Alterando o grupo proprietário
O grupo proprietário pode ser alterado por:
- Todos os superusuários.
- O usuário proprietário, se o usuário proprietário também for membro do grupo de destino.
Observação
O usuário proprietário não pode alterar as ACLs de um arquivo ou um diretório. Embora o grupo proprietário esteja definido para o usuário que criou a conta no caso do diretório raiz, Caso 1 acima, uma conta de usuário individual não é válida para fornecer permissões através do grupo proprietário. Você pode atribuir essa permissão a um grupo de usuários válido, se for aplicável.
Como as permissões são avaliadas
As identidades são avaliadas na seguinte ordem:
- Superusuário
- Usuário proprietário
- Usuário, entidade de serviço ou identidade gerenciada
- Grupo de propriedade ou grupo nomeado
- Todos os outros usuários
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.
Grupos nomeados são todos considerados juntos. 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 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 das contas para contas de armazenamento. Esse algoritmo mostra a ordem na qual 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 para usuários nomeados, o grupo proprietário e grupos nomeados.
Para um contêiner do Data Lake Storage Gen2, o padrão de máscara de acesso ACL do diretório raiz ("/") é 750 para diretórios e 640 para arquivos. A tabela a seguir mostra a notação simbólica desses níveis de permissão.
| Entidade | Diretórios | Arquivos |
|---|---|---|
| Usuário proprietário | rwx |
rw- |
| Grupo proprietário | r-x |
r-- |
| Outro | --- |
--- |
Arquivos não recebem o bit X uma vez que é irrelevante para arquivos em um sistema de armazenamento somente.
A máscara pode ser especificada em uma base por chamada. Isso permite que diferentes sistemas de consumo, como clusters, ter diferentes máscaras eficazes para suas operações de arquivo. Se uma máscara for especificada em uma determinada solicitação, ela substitui completamente a máscara padrão.
O sticky bit
O sticky bit é um recurso mais avançado de um contêiner POSIX. No contexto do Azure Data Lake Storage Gen2, é improvável que o sticky bit seja necessário. Em resumo, se o sticky bit estiver ativado em um diretório, um item filho somente poderá ser excluído ou renomeado pelo usuário proprietário do item filho, pelo proprietário do diretório ou pelo superusuário ($superusuário).
O sticky bit não é mostrado no Portal do Azure.
Permissões padrão em novos arquivos e diretórios
Quando um novo arquivo ou pasta é criado em um diretório existente, a ACL Padrão no diretório pai determina:
- ACL Padrão e ACL de Acesso de um diretório filho.
- ACL de Acesso de um arquivo filho (os arquivos não têm uma ACL Padrão).
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 nas pastas pai que contém um valor de RWX para o usuário proprietário, o grupo proprietário e outros.
O umask do Azure Data Lake Storage Gen2 é um valor constante definido como 007. Esse valor é convertido 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 de padrão do filho |
| umask.owning_group | 0 | --- |
Para o grupo proprietário, copie a ACL de acesso do pai para a ACL padrão do filho |
| umask.other | 7 | RWX |
Para outros, remova todas as permissões na ACL de Acesso do filho |
Perguntas frequentes
É necessário habilitar o suporte para ACLs?
Não. O controle de acesso via ACLs está habilitado para uma conta de armazenamento assim que o recurso do Namespace hierárquico (HNS) é ativado.
Se 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 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 Microsoft Entra.
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
LogsWritergrupo à ACL do diretório /LogData comrwxpermissões. - Adicione o
LogsReadergrupo à ACL do diretório /LogData comr-xpermissõ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.
Para criar um grupo e adicionar membros, confira Criar um grupo básico e adicionar membros usando o Microsoft Entra ID.
Importante
O Azure Data Lake Storage Gen2 depende do Microsoft Entra ID 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 para menos de 200. Essa recomendação ocorre devido a uma limitação de JWT (Tokens Web JSON) que fornecem informações de associação de grupo de uma entidade de segurança em aplicativos do Microsoft Entra. Exceder esse limite poderá resultar em problemas de desempenho inesperado com o Data Lake Storage Gen2. Para saber mais, confira Configurar declarações de grupo para aplicativos usando o Microsoft Entra ID.
Como as permissões de RBAC e ACL do Azure são avaliadas?
Para saber como o sistema avalia o RBAC e as ACLs do Azure juntos 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 as atribuições de função do Azure e as entradas de ACL?
A tabela a seguir fornece uma exibição resumida dos limites a serem considerados ao usar o Azure RBAC para gerenciar permissões "de alta granularidade" (permissões que se aplicam a contêineres ou contas de armazenamento) e usando ACLs para gerenciar permissões "refinadas" (permissões que se aplicam a arquivos e diretórios). Use grupos de segurança para atribuições 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.
| 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. |
4.000 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 |
O Azure Data Lake Storage Gen2 dá suporte à herança de Azure RBAC?
Herda as atribuições de função do Azure. Atribuições fluem de assinatura, grupo de recursos e recursos da conta de armazenamento até o recurso de contêiner.
O Azure Data Lake Storage Gen2 dá suporte à herança de ACLs?
As ACLs padrão podem ser usadas para definir as ACLs de 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ório desejada. Para obter diretrizes, consulte a seção como definir ACLs deste artigo.
Quais são as permissões necessárias para excluir recursivamente um diretório e seu conteúdo?
- O chamador tem permissões de “superusuário”,
Ou
- A pasta diretório deve ter permissões Gravar + Executar.
- O diretório a ser excluído, e todas as pastas nela, exige permissões Ler + Gravar + Executar.
Observação
Você não precisa de permissões de gravação para excluir arquivos em diretórios. Além disso, a pasta raiz "/" nunca poderá ser excluída.
Quem é o proprietário de um arquivo ou diretório?
O criador de um arquivo ou diretório se torna o proprietário. No caso do diretório raiz, esta é a identidade do usuário que criou o contêiner.
Qual grupo é definido como grupo proprietário de um arquivo ou diretório na criação?
O grupo pertencente é copiado do grupo proprietário do diretório pai na qual o novo arquivo ou diretório é criado.
Eu sou o usuário proprietário de um arquivo, mas não tenho as permissões RWX de que necessito. O que devo fazer?
O usuário proprietário pode alterar as permissões do arquivo para atribuir a sim mesmo quaisquer permissões RWX necessárias.
Por que, às vezes, vejo GUIDs nas ACLs?
Um GUID será mostrado se a entrada representa um usuário e esse usuário não existir mais no Microsoft Entra. Geralmente isso acontece se o usuário tiver deixado a empresa ou se sua conta tiver sido excluída no Microsoft Entra ID. Além disso, as entidades de serviço e grupos de segurança não tem um nome Principal de Usuário (UPN) para identificá-lo e então, são representados por seu atributo de identificação de objeto (um guid). Para limpar as ACLs, exclua manualmente essas entradas GUID.
Como fazer definir ACLs corretamente para uma entidade de serviço?
Quando você define ACLs para entidades de serviço, é importante usar a ID de objeto (OID) da entidade de serviço para o registro do 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 uma OID que é visível no portal do Azure, mas a entidade de serviço tem outra OID (diferente).
Artigo Para obter o OID para a entidade de serviço que corresponde a um registro de aplicativo, você pode usar o comando az ad sp show. Especifique a ID do aplicativo como o parâmetro. Veja um exemplo de como obter a OID para a entidade de serviço que corresponde a um registro de aplicativo com ID do aplicativo = 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
A OID será exibida.
Quando você tiver a OID correta para a entidade de serviço, vá para a página Gerenciador de Armazenamento Gerenciar acesso para adicionar a OID e atribuir as permissões apropriadas para a OID. Escolha 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á nomeado my-container/.
A API REST do armazenamento do Azure contém uma operação denominada 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. É recomendável exigir autorização para todas as solicitações para dados de blob. Para obter mais informações, consulte Visão geral: Corrigir o acesso de leitura anônimo para dados de blob.
Onde posso saber mais sobre o modelo de controle de acesso do POSIX?
- Listas de controle de acesso POSIX no Linux
- Guia de permissão do HDFS
- PERGUNTAS FREQUENTES SOBRE O POSIX
- POSIX 1003.1 2008
- POSIX 1003.1 2013
- POSIX 1003.1 2016
- POSIX ACL no Ubuntu