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 POSIX. Este artigo resume os conceitos básicos 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 ACLs (listas de controle de acesso), ACLs de acesso e ACLs padrão.

• ACLs de acesso: controlam o acesso a um objeto. Arquivos e pastas têm ACLs de acesso.

• ACLs padrão: Um "modelo" de ACLs associadas a uma pasta que determinam as ACLs de acesso para quaisquer itens filho 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 de sistema de arquivos são Read, Writee Execute, e podem ser usadas em arquivos e pastas, conforme mostrado na tabela a seguir:

Formatos curtos para as permissões

Utiliza-se RWX 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.

As permissões não herdam

No modelo 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 pai.

Cenários comuns relacionados a permissões

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

Utilizadores e identidades

Cada arquivo e pasta tem permissões distintas para essas identidades:

• O utilizador proprietário
• O grupo proprietário
• Utilizadores nomeados
• Grupos nomeados
• Todos os outros utilizadores

As identidades de usuários e grupos são identidades do Microsoft Entra. Portanto, salvo indicação em contrário, um "usuário", no contexto do Data Lake Storage Gen1, pode significar um usuário do Microsoft Entra ou um grupo de segurança do Microsoft Entra.

O superutilizador

Um superusuário tem o maior número de direitos de todos os usuários na conta Data Lake Storage Gen1. 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.

Todos os utilizadores que fazem parte da função Proprietários para uma conta do Data Lake Storage Gen1 são automaticamente um superutilizador.

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, desde que o utilizador que o possui também seja membro do grupo de destino.

O grupo proprietário

Contexto

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.

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

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

• Caso 1: O diretório root "/". Esta pasta é criada quando uma conta do Data Lake Storage Gen1 é criada. Nesse caso, o grupo proprietário é definido como um GUID composto apenas por zeros. Este valor não permite qualquer acesso. É um elemento de reserva até que um grupo seja designado.
• Caso 2 (Todos os outros casos): Quando um novo item é criado, o grupo proprietário é copiado da pasta principal.

Alterar o grupo proprietário

O grupo proprietário pode ser alterado por:

• Algum superutilizador?
• O utilizador proprietário, se o utilizador 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 para 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 designados, o grupo proprietário e os grupos nomeados.

O bit pegajoso

O bit pegajoso é um recurso mais avançado no sistema de arquivos POSIX. No contexto do Data Lake Storage Gen1, é pouco provável que o "sticky bit" precise ser usado. Em resumo, se o bit adesivo estiver ativado numa pasta, um item filho só poderá ser apagado ou renomeado pelo utilizador proprietário do item filho.

O bit adesivo 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 filha.
• ACL de acesso de um arquivo filho (os arquivos não têm uma ACL padrão).

umask

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

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

O valor umask usado pelo Azure Data Lake Storage Gen1 efetivamente significa que o valor para 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 para um elemento 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 ativar o suporte para as ACLs?

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

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

• A pasta pai deve ter permissões Write + Execute.
• A pasta a ser excluída, e cada pasta dentro dela, requer permissões Ler + Gravar + Executar.

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

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

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

O grupo de proprietários é copiado do grupo de proprietários da pasta mãe onde o novo arquivo ou pasta é criado.

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

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

Quando olho para ACLs no portal do Azure, vejo nomes de usuário, mas por meio de APIs, vejo GUIDs, por que isso?

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, traduzindo os GUIDs em nomes amigáveis quando possível.

Por que às vezes vejo GUIDs nas ACLs quando estou usando o portal do Azure?

Um GUID é apresentado quando um utilizador já não existe 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, certifique-se de que você está usando a ID correta para definir ACLs (detalhes em questão abaixo).

Ao usar um principal de serviço, que ID devo utilizar para definir as ACLs?

No Portal do Azure, vá para Microsoft Entra ID -> Enterprise applications e selecione seu aplicativo. A guia Overview deve exibir uma ID de objeto e é isso que deve ser usado ao adicionar ACLs para acesso a dados (e não ID de aplicativo).

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

Não, mas as ACLs padrão podem ser usadas para definir ACLs para arquivos filho e pasta recém-criada na pasta pai.

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

32 ACLs podem ser definidas 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. Use grupos de segurança para atribuições de ACL, se possível. Ao usar grupos, é menos provável que você exceda o número máximo de entradas da ACL por arquivo ou diretório.

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

• POSIX Access Control Lists on Linux (Listas de Controlo de Acesso POSIX no Linux)
• HDFS permission guide (Guia de permissões do HDFS)
• FAQ DO POSIX
• POSIX 1003.1 2008
• POSIX 1003.1 2013
• POSIX 1003.1 2016
• POSIX ACL no Ubuntu

Ver também

• Visão geral do Azure Data Lake Storage Gen1