Controlo de acesso no Azure Data Lake Storage Gen1

  • Artigo

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.

Nota

Alterar a ACL Predefinida num componente principal não afeta a ACL de Acesso ou a ACL Predefinida de itens subordinados que já existem.

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:

Ficheiro Pasta
Leitura (R) Pode editar o conteúdo de um ficheiro Requer Leitura e Execução para listar os conteúdos da pasta
Escrita (W) Pode escrever ou acrescentar a um ficheiro Requer Escrita e Execução para criar itens subordinados numa pasta
Execução (X) Não significa nada no contexto de Data Lake Storage Gen1 É necessário para atravessar os itens subordinados de uma pasta

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.

Formato numérico Formato curto O que representa
7 RWX Leitura + Escrita + Execução
5 R-X Leitura + Execução
4 R-- Leitura
0 --- Sem permissões

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.

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.

Operação Objeto / Seattle/ Portland/ Data.txt
Leitura Data.txt --X --X --X R--
Acrescentar a Data.txt --X --X --X -W-
Eliminar 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 ---

Nota

As permissões de Escrita no ficheiro não são necessárias para o eliminar, desde que as duas condições anteriores sejam verdadeiras.

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.

Nota

O utilizador proprietário não pode alterar o utilizador proprietário de um ficheiro ou pasta. Apenas os superutilizadores podem alterar o utilizador proprietário de um ficheiro ou pasta.

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.

Nota

O grupo proprietário não pode alterar as ACLs de um ficheiro ou pasta.

Para contas criadas em ou antes de setembro de 2018, o grupo proprietário foi definido para o utilizador que criou a conta no caso da pasta raiz para o Caso 1, acima. Uma única conta de utilizador não é válida para fornecer permissões através do grupo proprietário, pelo que não são concedidas permissões por esta predefinição. Pode atribuir esta permissão a um grupo de utilizadores válido.

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.

Nota

Para uma nova conta Data Lake Storage Gen1, a máscara da ACL de Acesso da pasta raiz ("/") é predefinida para RWX.

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

componente umask Formato numérico Formato curto Significado
umask.owning_user 0 --- Para o utilizador proprietário, copie a ACL Predefinida do encarregado de educação para a ACL de Acesso do menor
umask.owning_group 0 --- Para o grupo proprietário, copie a ACL Predefinida do encarregado de educação para a ACL de Acesso do menor
umask.other 7 RWX Para outros, remova todas as permissões na ACL de Acesso do menor

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.

Nota

Não precisa das permissões de Escrita para eliminar ficheiros em pastas. Além disso, a pasta raiz "/" nunca pode ser eliminada.

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?

Ver também