Control de acceso en Azure Data Lake Storage Gen1

Azure Data Lake Storage Gen1 implementa un modelo de control de acceso que deriva de HDFS, que a su vez deriva del modelo de control de acceso POSIX. En este artículo se resumen los conceptos básicos del modelo de control de acceso para Data Lake Storage Gen1.

Listas de control de acceso en archivos y carpetas

Hay dos tipos de listas de control de acceso (ACL), ACL de acceso y ACL predeterminadas.

• ACL de acceso: controlan el acceso a un objeto . Los archivos y carpetas tanto tienen ACL de acceso.

• ACL predeterminadas: una "plantilla" de ACL asociadas a una carpeta que determinan las ACL de acceso para los elementos secundarios que se crean en esa carpeta. Los archivos no tienen ACL predeterminadas.

Tanto las ACLs de acceso como las ACLs predeterminadas tienen la misma estructura.

Permisos

Los permisos de un objeto de sistema de archivos son Read, Write y Execute, y se pueden usar en archivos y carpetas, como se muestra en la tabla siguiente:

Formas abreviadas de los permisos

RWX se usa para indicar Read + Write + Execute. Existe una forma numérica más condensada en la que Read=4, Write=2 y Execute=1, la suma de la cual representa los permisos. A continuación se muestran algunos ejemplos.

Los permisos no se heredan

En el modelo de estilo POSIX que usa Data Lake Storage Gen1, los permisos de un elemento se almacenan en el propio elemento. Es decir, los permisos de un elemento no se pueden heredar de los elementos primarios.

Escenarios comunes relacionados con los permisos

A continuación se muestran algunos escenarios comunes que le ayudarán a comprender qué permisos son necesarios para realizar determinadas operaciones en una cuenta de Data Lake Storage Gen1.

Usuarios e identidades

Cada archivo y carpeta tiene permisos distintos para estas identidades:

• El usuario propietario
• El grupo propietario
• Usuarios designados
• Grupos designados
• Los restantes usuarios

Las identidades de usuarios y grupos son identidades de Microsoft Entra. Por lo tanto, a menos que se indique lo contrario, un "usuario", en el contexto de Data Lake Storage Gen1, puede significar un usuario de Microsoft Entra o un grupo de seguridad de Microsoft Entra.

El superusuario

Un superusuario tiene los más derechos de todos los usuarios de la cuenta de Data Lake Storage Gen1. Un superusuario:

• Tiene permisos RWX para todos los archivos y carpetas.
• Puede cambiar los permisos de cualquier archivo o carpeta.
• Puede cambiar el usuario propietario o el grupo propietario de cualquier archivo o carpeta.

Todos los usuarios que forman parte del rol Propietarios de una cuenta de Data Lake Storage Gen1 son automáticamente un superusuario.

El usuario propietario

El usuario que creó el elemento es automáticamente el usuario propietario del elemento. Un usuario propietario puede:

• Cambiar los permisos de un archivo que le pertenece.
• Cambiar el grupo propietario de un archivo que le pertenece, siempre que el usuario propietario también sea miembro del grupo de destino.

El grupo propietario

Fondo

En las ACL posix, cada usuario está asociado a un "grupo principal". Por ejemplo, el usuario "alice" podría pertenecer al grupo "finance". Alice también puede pertenecer a varios grupos, pero un grupo siempre se designa como su grupo principal. En POSIX, cuando Alice crea un archivo, el grupo propietario de ese archivo se establece en su grupo principal, que en este caso es "finance". De lo contrario, el grupo propietario se comporta de forma similar a los permisos asignados para otros usuarios o grupos.

Dado que no hay ningún "grupo principal" asociado a los usuarios de Data Lake Storage Gen1, el grupo propietario se asigna como se indica a continuación.

Asignación del grupo propietario para un nuevo archivo o carpeta

• Caso 1: la carpeta raíz "/". Esta carpeta se crea cuando se crea una cuenta de Data Lake Storage Gen1. En este caso, el grupo propietario se establece en un GUID compuesto por ceros. Este valor no permite ningún acceso. Es un marcador de posición hasta que se asigne un grupo.
• Caso 2 (cada otro caso): cuando se crea un nuevo elemento, el grupo propietario se copia de la carpeta primaria.

Cambio del grupo propietario

El grupo propietario se puede cambiar por:

• Cualquier superusuario.
• El usuario propietario, si el usuario propietario también es miembro del grupo de destino.

Algoritmo de comprobación de acceso

El pseudocódigo siguiente representa el algoritmo de comprobación de acceso para las cuentas de 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)

La máscara

Como se muestra en el algoritmo de comprobación de acceso, la máscara limita el acceso para los usuarios con nombre, el grupo propietario y los grupos con nombre.

El bit persistente

El bit pegajoso es una característica más avanzada de un sistema de archivos POSIX. En el contexto de Data Lake Storage Gen1, es poco probable que se necesite el bit pegajoso. En resumen, si el bit "sticky" está habilitado en una carpeta, solo el usuario propietario del elemento secundario puede eliminarlo o cambiarle el nombre.

El bit pegajoso no se muestra en Azure Portal.

Permisos predeterminados en archivos y carpetas nuevos

Cuando se crea un nuevo archivo o carpeta en una carpeta existente, la ACL predeterminada de la carpeta primaria determina:

• ACL predeterminada de una carpeta secundaria y ACL de acceso.
• ACL de acceso de un archivo hijo (los archivos no tienen una ACL por defecto).

umask

Al crear un archivo o carpeta, se usa umask para modificar cómo se establecen las ACL predeterminadas en el elemento secundario. umask es un valor de 9 bits en las carpetas primarias que contiene un valor RWX para el usuario propietario, el grupo propietario y otro.

La umask para Azure Data Lake Storage Gen1 es un valor constante fijado en 007. Este valor se traduce en

El valor de umask usado por Azure Data Lake Storage Gen1 significa eficazmente que el valor de otros nunca se transmite de forma predeterminada en nuevos elementos secundarios, independientemente de lo que indique la ACL predeterminada.

El pseudocódigo siguiente muestra cómo se aplica el umask al crear las ACL para un elemento secundario.

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 )

Preguntas comunes sobre las ACL en Data Lake Storage Gen1

¿Es preciso habilitar la compatibilidad con las ACL?

No. El control de acceso a través de ACL siempre está activado para una cuenta de Data Lake Storage Gen1.

¿Qué permisos son necesarios para eliminar recursivamente una carpeta y su contenido?

• La carpeta primaria debe tener permisos de escritura y ejecución .
• La carpeta que se va a eliminar y cada carpeta dentro de ella requiere permisos de lectura y escritura y ejecución .

¿Quién es el propietario de un archivo o carpeta?

El creador de un archivo o carpeta se convierte en el propietario.

¿Qué grupo se establece como el grupo propietario de un archivo o carpeta en la creación?

El grupo propietario se copia del grupo propietario de la carpeta primaria en la que se crea el nuevo archivo o carpeta.

Soy el usuario propietario de un archivo, pero no tengo los permisos RWX que necesito. ¿Qué hago?

El usuario propietario puede cambiar los permisos del archivo y concederse los permisos de RWX que necesite.

Al examinar las ACL en Azure Portal veo nombres de usuario, pero a través de las API, veo GUID, ¿por qué es eso?

Las entradas de las ACL se almacenan como GUID que corresponden a los usuarios de Microsoft Entra ID. Las API devuelven los GUID tal como están. Azure Portal intenta facilitar el uso de las ACL mediante la traducción de los GUID a nombres descriptivos siempre que sea posible.

¿Por qué a veces veo GUID en las ACL cuando uso Azure Portal?

Se muestra un GUID cuando el usuario ya no existe en Microsoft Entra. Normalmente esto ocurre cuando el usuario ha dejado la empresa o si su cuenta ha sido eliminada en Microsoft Entra ID. Además, asegúrese de que usa el identificador adecuado para establecer ACL (detalles en cuestión a continuación).

Al usar un principal de servicio, ¿qué identificador debo usar para establecer las ACL?

En Azure Portal, vaya a Microsoft Entra ID -> Aplicaciones empresariales y seleccione la aplicación. La pestaña Información general debe mostrar un identificador de objeto y esto es lo que se debe usar al agregar ACL para el acceso a datos (y no el identificador de aplicación).

¿Admite Data Lake Storage Gen1 la herencia de ACL?

No, pero las ACL predeterminadas se pueden usar para establecer ACL para archivos secundarios y carpetas recién creados en la carpeta primaria.

¿Cuáles son los límites de las entradas de ACL en archivos y carpetas?

Se pueden establecer 32 ACL por archivo y por directorio. Las ACL de acceso y predeterminadas tienen su propio límite de 32 entradas de ACL. Use grupos de seguridad para las asignaciones de ACL si es posible. Al usar grupos, es menos probable que supere el número máximo de entradas de ACL por archivo o directorio.

¿Dónde puedo obtener más información sobre el modelo de control de acceso POSIX?

• Listas de control de acceso POSIX en Linux
• Guía de permisos de HDFS
• Preguntas más frecuentes sobre POSIX
• POSIX 1003.1 2008
• POSIX 1003.1 2013
• POSIX 1003.1 2016
• POSIX ACL en Ubuntu

Consulte también

• Introducción a Azure Data Lake Storage Gen1