Controlo de acesso no Azure Data Lake Storage Gen1

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

Listas de controlo de acesso em ficheiros e pastas

Existem dois tipos de listas de controlo de acesso (ACLs) – ACLs de Acesso e ACLs Predefinidas.

• ACLs de Acesso: controlam o acesso a um objeto. Os ficheiros e as pastas têm ACLs de Acesso.

• ACLs Predefinidas: um "modelo" de ACLs associado a uma pasta que determinam as ACLs de Acesso para todos os itens subordinados que são criados nessa pasta. Os ficheiros não possuem ACLs Predefinidas.

Tanto as ACLs de Acesso como as ACLs Predefinidas têm a mesma estrutura.

Permissões

As permissões num objeto do sistema de ficheiros são Leitura, Escrita e Execução e podem ser utilizadas em ficheiros e pastas conforme mostrado na tabela seguinte:

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.

As permissões não são herdadas

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

Cenários comuns relacionados com as permissões

Seguem-se alguns cenários comuns para o ajudar a compreender que permissões são necessárias para realizar determinadas operações numa conta Data Lake Storage Gen1.

Utilizadores e identidades

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

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

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

O superutilizador

Um superutilizador tem o maior número de direitos de todos os utilizadores 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 de uma conta 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 que é propriedade, desde que o utilizador proprietário também seja membro do grupo de destino.

O grupo proprietário

Fundo

Nas ACLs POSIX, todos os utilizadores estão associados a um "grupo primário". Por exemplo, o utilizador "alice" pode pertencer ao grupo "finanças". A Alice poderá, também, pertencer a vários grupos, mas um dos grupos será sempre o grupo principal dela. No POSIX, quando a Alice cria um ficheiro, o grupo proprietário desse ficheiro é definido como o seu grupo principal, que neste caso é "finanças". Caso contrário, o grupo proprietário comporta-se de forma semelhante às permissões atribuídas a outros utilizadores/grupos.

Uma vez que não existe nenhum "grupo primário" associado aos utilizadores no Data Lake Storage Gen1, o grupo proprietário é atribuído como abaixo.

Atribuir o grupo proprietário a um novo ficheiro ou pasta

• Caso 1: a pasta raiz "/". Esta pasta é criada quando é criada uma conta Data Lake Storage Gen1. Neste caso, o grupo proprietário está definido como um GUID totalmente zero. Este valor não permite qualquer acesso. É um marcador de posição até que um grupo seja atribuído.
• Caso 2 (todos os outros casos): quando é criado um item novo, o grupo proprietário é copiado da pasta principal.

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.

Algoritmo de verificação de acesso

O pseudocódigo seguinte representa o algoritmo de verificação de acesso para contas 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 a utilizadores nomeados, ao grupo proprietário e a grupos nomeados.

O sticky bit

O sticky bit é uma funcionalidade mais avançada de um sistema de ficheiros POSIX. No contexto da Data Lake Storage Gen1, é improvável que o bit pegajoso seja necessário. Em resumo, se o sticky bit estiver ativado numa pasta, um item subordinado só pode ser eliminado ou mudado pelo utilizador proprietário do item subordinado.

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

Permissões predefinidas em novos ficheiros e pastas

Quando um novo ficheiro ou pasta são criados numa pasta existente, a ACL Predefinida na pasta principal determina:

• A ACL Predefinida e a ACL de Acesso da pasta subordinada.
• A ACL de Acesso do ficheiro subordinado (os ficheiros não têm ACLs Predefinidas)

umask

Ao criar um ficheiro ou pasta, é utilizada umask para modificar a forma como as ACLs predefinidas são definidas no item subordinado. umask é um valor de 9 bits nas pastas principais que contém um valor RWX para o utilizador proprietário, o grupo proprietário e outro.

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

O valor de umask utilizado pelo Azure Data Lake Storage Gen1 significa efetivamente que o valor para outros nunca é transmitido por predefinição em crianças novas, independentemente do que a ACL Predefinida indica.

O pseudocódigo seguinte mostra como a umask é aplicada ao criar as ACLs para um item subordinado.

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 controlo de acesso através de ACLs está sempre ativado para uma conta Data Lake Storage Gen1.

Que permissões são necessárias para eliminar recursivamente uma pasta e o respetivo conteúdo?

• A pasta principal tem de ter as permissões de Escrita + Execução.
• A pasta a eliminar, e cada pasta dentro da mesma, requer as permissões de Leitura + Escrita + Execução.

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

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

Que grupo é definido como proprietário de um ficheiro ou pasta durante a criação?

O grupo proprietário é copiado do grupo proprietário da pasta principal sob a qual o novo ficheiro ou pasta é criado.

Sou o utilizador proprietário de um ficheiro, mas não tenho as permissões de RWX necessárias. 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.

Quando vejo as ACLs no portal do Azure, vejo os nomes de utilizador, mas pelas APIs vejo GUIDs. Por que motivo é que isto acontece?

As entradas nas ACLs são armazenadas como GUIDs que correspondem aos utilizadores no Microsoft Entra ID. As APIs devolvem os GUIDs conforme estão. O portal do Azure tenta tornar as ACLs mais fáceis de utilizar, ao traduzir os GUIDs para nomes amigáveis sempre que possível.

Porque é que, por vezes, vejo GUIDs nas ACLs quando utilizo o portal do Azure?

É apresentado um GUID quando o utilizador já não existe no Microsoft Entra. Normalmente, isto acontece quando o utilizador saiu da empresa ou se a conta foi eliminada no Microsoft Entra ID. Além disso, certifique-se de que está a utilizar o ID certo para definir ACLs (detalhes em questão abaixo).

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

No Portal do Azure, aceda a Microsoft Entra ID -> Aplicações empresariais e selecione a sua aplicação. O separador Descrição Geral deve apresentar um ID de Objeto e é isso que deve ser utilizado ao adicionar ACLs para acesso a dados (e não id da aplicação).

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

Não, mas as ACLs Predefinidas podem ser utilizadas para definir ACLs para ficheiros e pastas subordinados criados recentemente na pasta principal.

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

Podem ser definidas 32 ACLs por ficheiro e por diretório. Cada uma das ACLs de acesso e de predefinição tem o seu próprio limite de 32 entradas ACL. Utilize grupos de segurança para atribuições de ACL, se possível. Ao utilizar grupos, é menos provável que exceda o número máximo de entradas da ACL por ficheiro 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

• Descrição geral do Azure Data Lake Storage Gen1