Controle de acesso no Azure Data Lake Storage Gen1

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.

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:

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:

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.

Cenários comuns relacionados a permissões

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.

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.

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.

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.

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

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.

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?

• 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

Confira também

• Visão Geral do Azure Data Lake Storage Gen1