Controle de acesso no Azure Data Lake Storage Gen1

Artigo
03/26/2018

O Azure Data Lake Storage Gen1 implementa um modelo de controle de acesso que deriva do HDFS que, por sua vez, deriva do modelo de controle de acesso do POSIX. Este artigo resume as noções básicas do modelo de controle de acesso para o Data Lake Storage Gen1.

Listas de controle de acesso em arquivos e pastas

Há dois tipos de listas de controle de acesso (ACLs), ACLs de Acesso e ACLs Padrão.

ACLs de Acesso: controlam o acesso a um objeto. Os arquivos e as pastas têm ACLs de Acesso.
ACLs Padrão: um "modelo" de ACLs associadas a uma pasta que determinam as ACLs de Acesso para todos os itens filhos criados nessa pasta. Os 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.

Permissões

As permissões em um objeto do sistema de arquivos são Ler, Gravar e Executar e podem ser usadas em arquivos e em pastas como mostrado na seguinte tabela:

	Arquivo	Pasta
Ler (R)	Pode ler o conteúdo de um arquivo	Requer Ler e Executar para listar o conteúdo da pasta
Gravar (W)	Pode gravar ou anexar a um arquivo	Requer Gravar e Executar para criar itens filhos em uma pasta
Executar (X)	Não significa nada no contexto do Data Lake Storage Gen1	Necessário para percorrer os itens filhos de uma pasta

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

Não herdam permissões

No modelo de estilo POSIX usado pelo Data Lake Storage Gen1, 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 pais.

A seguir estão alguns cenários comuns para ajudá-lo a compreender quais permissões são necessárias para executar determinadas operações em uma conta do Data Lake Storage Gen1.

Operação	Objeto	/	Seattle/	Portland/	Data.txt
Ler	Data.txt	`--X`	`--X`	`--X`	`R--`
Acrescentar a	Data.txt	`--X`	`--X`	`--X`	`-W-`
Excluir	Data.txt	`--X`	`--X`	`-WX`	`---`
Criar	Data.txt	`--X`	`--X`	`-WX`	`---`
Lista	/	`R-X`	`---`	`---`	`---`
Lista	/Seattle/	`--X`	`R-X`	`---`	`---`
Lista	/Seattle/Portland/	`--X`	`--X`	`R-X`	`---`

Observação

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

Usuários e identidades

Todos os arquivos e pastas têm permissões diferentes para estas identidades:

O usuário proprietário
O grupo proprietário
Usuários nomeados
Grupos nomeados
Todos os outros usuários

As identidades de usuários e grupos são Microsoft Entra identidades. Portanto, a menos que indicado de outra forma, um "usuário", no contexto de Data Lake Storage Gen1, pode significar um usuário Microsoft Entra ou um grupo de segurança Microsoft Entra.

O superusuário

Um superusuário é aquele que tem mais direitos que todos os usuários na conta do Data Lake Storage Gen1. 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.

Todos os usuários que fazem parte da função Proprietários de uma conta do Data Lake Storage Gen1 são automaticamente superusuários.

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 uma pasta. Somente superusuários podem alterar o usuário proprietário de um arquivo ou pasta.

O grupo proprietário

Tela de fundo

Nas ACLs de POSIX, cada usuário é associado a um "grupo primário". Por exemplo, o usuário "Alice" pode pertencer ao grupo "Finance". 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.

Como não há "grupo primário" associado a usuários no Data Lake Storage Gen1, o grupo proprietário é atribuído conforme mostrado abaixo.

Atribuindo o grupo proprietário de um novo arquivo ou pasta

Caso 1: a pasta raiz "/". Essa pasta é criada quando uma conta do Data Lake Storage Gen1 é criada. Nesse caso, o grupo proprietário é definido como um GUID de zeros. Este valor não permite acesso. Ele será um espaço reservado até ao momento em que um grupo for atribuído.
Caso 2 (todos os outros casos): quando um novo 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 uma pasta.

Para contas criadas em ou antes de setembro de 2018, o grupo proprietário foi definido para o usuário que criou a conta no caso da pasta raiz do Caso 1, acima. Uma única conta de usuário não é válida para fornecer permissões por meio do grupo proprietário, portanto, nenhuma permissão é concedida por essa configuração padrão. Você pode atribuir essa permissão a um grupo de usuários válido.

Algoritmo de verificação de acesso

O pseudocódigo a seguir representa o algoritmo de verificação de acesso das contas do Data Lake Storage Gen1.

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 folder
  # Note: the "sticky bit" is not illustrated in this algorithm
  
# Handle super users.
  if (is_superuser(user)) :
    return True

  # Handle the owning user. Note that mask IS NOT 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.permmissions & mask) == desired_perms)

  # Handle named groups and owning group
  member_count = 0
  perms = 0
  entries = get_acl_entries( path, NAMED_GROUP | OWNING_GROUP )
  for entry in entries:
    if (user_is_member_of_group(user, entry.identity)) :
      member_count += 1
      perms | =  entry.permissions
  if (member_count>0) :
    return ((desired_perms & perms & mask ) == desired_perms)
 
  # 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.

Observação

Para uma nova conta do Data Lake Storage Gen1, a mask da ACL de Acesso da pasta raiz ("/") tem RWX como padrão.

O sticky bit

O sticky bit é um recurso mais avançado de um sistema de arquivos POSIX. No contexto do Data Lake Storage Gen1, é improvável que o sticky bit seja necessário. Em resumo, se o sticky bit estiver habilitado em uma pasta, um item filho apenas poderá ser excluído ou renomeado pelo usuário proprietário do item filho.

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

Permissões padrão em novos arquivos e pastas

Quando um novo arquivo ou pasta é criado em uma pasta existente, a ACL Padrão na pasta pai determina:

ACL Padrão e ACL de Acesso de uma pasta filho.
ACL de Acesso de um arquivo filho (os arquivos não têm uma ACL Padrão).

umask

Ao criar um arquivo ou uma pasta, o umask é usado para modificar como as ACLs padrão são definidas no item filho. O umask é um valor de 9 bits nas pastas pai que contém um valor RWX para o usuário proprietário, o grupo proprietário e outros.

O umask do Azure Data Lake Storage Gen1 é 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, copia a ACL Padrão do pai para a ACL de Acesso do filho
umask.owning_group	0	`---`	Para o grupo proprietário, copia a ACL Padrão do pai para a ACL de Acesso do filho
umask.other	7	`RWX`	Para outros, remova todas as permissões na ACL de Acesso do filho

O valor de umask usado pelo Azure Data Lake Storage Gen1 significa efetivamente que o valor dos outros nunca é transmitido por padrão em novos filhos, independentemente do que a ACL Padrão indica.

O pseudocódigo a seguir mostra como o umask é aplicado ao criar as ACLs de um item filho.

def set_default_acls_for_new_child(parent, child):
    child.acls = []
    for entry in parent.acls :
        new_entry = None
        if (entry.type == OWNING_USER) :
            new_entry = entry.clone(perms = entry.perms & (~umask.owning_user))
        elif (entry.type == OWNING_GROUP) :
            new_entry = entry.clone(perms = entry.perms & (~umask.owning_group))
        elif (entry.type == OTHER) :
            new_entry = entry.clone(perms = entry.perms & (~umask.other))
        else :
            new_entry = entry.clone(perms = entry.perms )
        child_acls.add( new_entry )

Perguntas comuns sobre ACLs no Data Lake Storage Gen1

É necessário habilitar o suporte para ACLs?

Não. O controle de acesso via ACLs está sempre ativado para uma conta do Data Lake Storage Gen1.

Quais são as permissões necessárias para excluir recursivamente uma pasta e seu conteúdo?

A pasta pai deve ter permissões Gravar + Executar.
A pasta a ser excluída, 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 pastas. Além disso, a pasta raiz "/" nunca poderá ser excluída.

Quem é o proprietário de um arquivo ou pasta?

O criador de um arquivo ou pasta se torna o proprietário.

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

O grupo pertencente é copiado do grupo proprietário da pasta pai na qual o novo arquivo ou pasta é 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.

Quando examino as ACLs no portal do Azure eu vejo nomes de usuário, mas por meio de APIs eu vejo GUIDs, por quê?

As entradas nas ACLs são armazenadas como GUIDs que correspondem aos usuários no Microsoft Entra ID. As APIs retornam os GUIDs como estão. O portal do Azure tenta tornar as ACLs mais fáceis de usar, convertendo os GUIDs em nomes amigáveis quando possível.

Por que, às vezes, vejo GUIDs nas ACLs ao usar o portal do Azure?

Um GUID é mostrado quando o usuário não existe mais no Microsoft Entra. Normalmente, isso acontece quando o usuário saiu da empresa ou se sua conta foi excluída no Microsoft Entra ID. Além disso, verifique se você está usando a ID correta para definir ACLs (detalhes na pergunta abaixo).

Ao usar a entidade de serviço, qual ID devo usar para definir ACLs?

No Portal do Azure, acesse Microsoft Entra ID –> Aplicativos empresariais e selecione seu aplicativo. A guia Visão geral deve exibir uma ID de objeto, que você precisa usar ao adicionar ACLs para acessar dados (não use a ID do aplicativo).

O Data Lake Storage Gen1 dá suporte à herança de ACLs?

Não, mas ACLs padrão pode ser usado para definir as ACLs de arquivos filho e recentemente criado na pasta pai da pasta.

Quais são os limites de entradas de ACL em arquivos e pastas?

Você pode definir 32 ACLs por arquivo e diretório. As ACLs de acesso e padrão têm seu próprio limite de entrada de ACL 32. Use grupos de segurança para atribuições de ACL, se possível. Ao usar grupos, você diminui a chance de exceder o número máximo de entradas de ACL por arquivo ou diretório.

Onde posso saber mais sobre o modelo de controle de acesso do POSIX?

Confira também

Visão Geral do Azure Data Lake Storage Gen1

Controle de acesso no Azure Data Lake Storage Gen1

Listas de controle de acesso em arquivos e pastas

Permissões

Formatos abreviados para permissões

Não herdam permissões

Cenários comuns relacionados a permissões

Usuários e identidades

O superusuário

O usuário proprietário

O grupo proprietário

Algoritmo de verificação de acesso

A máscara

O sticky bit

Permissões padrão em novos arquivos e pastas

umask

Perguntas comuns sobre ACLs no Data Lake Storage Gen1

É necessário habilitar o suporte para ACLs?

Quais são as permissões necessárias para excluir recursivamente uma pasta e seu conteúdo?

Quem é o proprietário de um arquivo ou pasta?

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

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?

Quando examino as ACLs no portal do Azure eu vejo nomes de usuário, mas por meio de APIs eu vejo GUIDs, por quê?

Por que, às vezes, vejo GUIDs nas ACLs ao usar o portal do Azure?

Ao usar a entidade de serviço, qual ID devo usar para definir ACLs?

O Data Lake Storage Gen1 dá suporte à herança de ACLs?

Quais são os limites de entradas de ACL em arquivos e pastas?

Onde posso saber mais sobre o modelo de controle de acesso do POSIX?

Confira também

Recursos adicionais