Listas de control de acceso (ACL) en Azure Data Lake Storage

Azure Data Lake Storage implementa un modelo de control de acceso compatible con el control de acceso basado en rol (RBAC) de Azure y las listas de control de acceso (ACL) tipo POSIX. En este artículo se describen las listas de control de acceso de Data Lake Storage. Para obtener información sobre cómo incorporar Azure RBAC junto con las ACL y cómo el sistema las evalúa para tomar decisiones de autorización, consulte Modelo de control de Acceso en Azure Data Lake Storage.

Acerca de las ACLs (listas de control de acceso)

Puede asociar una entidad de seguridad a un nivel de acceso de archivos y directorios. Cada asociación es una entrada en una lista de control de acceso (ACL). Cada archivo y directorio de la cuenta de almacenamiento tiene una lista de control de acceso. Cuando una entidad de seguridad intenta realizar una operación en un archivo o directorio, una comprobación de ACL determina si esa entidad de seguridad (usuario, grupo, entidad de servicio o identidad administrada) tiene el nivel de permiso adecuado para llevarla a cabo.

Nota:

Las ACL se aplican solo a las entidades de seguridad del mismo inquilino. Las ACL no se aplican a los usuarios que usan la autorización de clave compartida porque no hay ninguna identidad asociada al autor de la llamada y, por tanto, no se puede realizar la autorización basada en permisos de la entidad de seguridad. La misma regla se aplica a los tokens de firma de acceso compartido (SAS), excepto cuando se usa un token de SAS delegado por el usuario. En ese caso, Azure Storage realiza una comprobación de ACL POSIX con el identificador de objeto antes de autorizar la operación siempre que se use el parámetro opcional suoid. Para obtener más información, consulte Construcción de una SAS de delegación de usuarios.

Establecimiento de las ACL

Para establecer permisos en el nivel de archivo y de directorio, consulte cualquiera de los siguientes artículos:

Entorno Artículo
Explorador de Azure Storage Uso del Explorador de Azure Storage para administrar listas de control de acceso en Azure Data Lake Storage
Portal de Azure Uso de Azure Portal para administrar ACL en Azure Data Lake Storage
.NET Uso de .NET para administrar listas de control de acceso (ACL) en Azure Data Lake Storage
Java Uso de Java para administrar listas de control de acceso (ACL) en Azure Data Lake Storage
Pitón Uso de Python para administrar listas de control de acceso (ACL) en Azure Data Lake Storage
JavaScript (Node.js) Uso de JavaScript SDK en Node.js para administrar ACL en Azure Data Lake Storage
PowerShell Uso de PowerShell para administrar listas de control de acceso en Azure Data Lake Storage
CLI de Azure Uso de la CLI de Azure para administrar listas de control de acceso (ACL) en Azure Data Lake Storage
REST API Ruta de acceso: Actualización

Importante

Si la entidad de seguridad es una entidad de servicio , use el identificador de objeto de la entidad de servicio y no el identificador de objeto del registro de aplicación relacionado. Para obtener el identificador de objeto de la entidad de servicio, abra el CLI de Azure y, a continuación, use este comando: az ad sp show --id <Your App ID> --query objectId. Sustituya el marcador de posición <Your App ID> por el id. de aplicación de su registro de aplicaciones. La entidad de servicio se trata como un usuario con nombre. Agregue este identificador a la ACL como haría con cualquier usuario con nombre. Los usuarios con nombre se describen más adelante en este artículo.

Tipos de ACL

Hay dos tipos de listas de control de acceso: ACL de acceso y ACL predeterminadas.

las ACL de acceso controlan el acceso a un objeto. Tanto archivos como directorios tienen ACL de acceso.

Las ACL predeterminadas son plantillas de ACL asociadas con un directorio que determina las ACL de acceso de todos los elementos secundarios que se crean en ese directorio. Los archivos no tienen ACL predeterminadas.

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

Nota:

El cambio de la ACL predeterminada de un elemento primario no afecta a la ACL de acceso ni a la ACL predeterminada de los elementos secundarios que ya existen.

Niveles de permiso

Los permisos de directorios y archivos de un contenedor son Lectura, Escritura y Ejecución. Puede usar estos permisos en archivos y directorios, como se muestra en la tabla siguiente:

Archivo Directorio
Lectura (R) Puede leer el contenido de un archivo Requiere permisos de lectura y ejecución para enumerar el contenido del directorio.
Escribir (W) Puede escribir o anexar a un archivo Requiere permisos de lectura y ejecución para crear elementos secundarios en un directorio.
Ejecutar (X) No significa nada en el contexto de Data Lake Storage Se requiere para atravesar los elementos secundarios de un directorio.

Nota:

Si concede permisos usando solo ACL (sin Azure RBAC), para conceder a una entidad de seguridad acceso de lectura o escritura a un archivo, debe conceder a la entidad de seguridad permisos Execute a la carpeta raíz del contenedor y a cada carpeta de la jerarquía de carpetas que conducen al archivo.

Formas abreviadas de los permisos

Utilice RWX para mostrar los permisos de lectura + escritura + ejecución. También hay un formato numérico donde Read=4, Write=2 y Execute=1. Agregue estos números para mostrar los permisos. A continuación se incluyen algunos ejemplos:

Formato numérico Formato abreviado Qué significa
7 RWX Lectura + Escritura + Ejecución
5 R-X Lectura + ejecución
4 R-- Lectura
0 --- Sin permisos

Herencia de permisos

En el modelo de estilo de POSIX usado por Data Lake Storage, los permisos de un elemento se almacenan en el propio elemento. En otras palabras, los permisos de un elemento no se pueden heredar de los elementos primarios si los permisos se establecen después de que ya se haya creado el elemento secundario. Los permisos solo se heredan si los permisos predeterminados se han establecido en los elementos primarios antes de crear los secundarios.

En la tabla siguiente se muestran las entradas de ACL necesarias para permitir que una entidad de seguridad realice las operaciones indicadas en la columna Operación.

En esta tabla se muestra una columna que representa cada nivel de una jerarquía de directorios ficticia. Hay una columna para el directorio raíz del contenedor (/), un subdirectorio denominado Oregón, un subdirectorio del directorio Oregón denominado Portland y un archivo de texto en el directorio Portland denominado Data.txt.

Importante

Esta tabla asume que usa solo ACL sin ninguna asignación de roles de Azure. Para consultar una tabla similar que combina RBAC de Azure junto con las ACL, consulte Tabla de permisos: combinación de RBAC de Azure, ABAC y ACL.

Operación / Oregón/ Portland/ Data.txt
Leer el archivo Data.txt --X --X --X R--
Anexar a Data.txt --X --X --X RW-
Eliminar Datos.txt --X --X -WX ---
Eliminar /Oregon/ -WX RWX RWX ---
Eliminar /Oregon/Portland/ --X -WX RWX ---
Crear o actualizar Data.txt --X --X -WX ---
Enumerar / R-X --- --- ---
Enumerar /Oregón/ --X R-X --- ---
Lista /Oregón/Portland/ --X --X R-X ---

Eliminar archivos y directorios

Como se muestra en la tabla anterior, no necesita permisos de escritura en el archivo para eliminarlo siempre y cuando los permisos de directorio se establezcan correctamente. Sin embargo, para eliminar un directorio y todo su contenido, el directorio primario debe tener permisos de escritura y ejecución. Tanto el directorio que se va a eliminar como todos los directorios que contiene requieren permisos de lectura, escritura y ejecución.

Nota:

Nunca puede eliminar el directorio raíz "/".

Usuarios e identidades

Todos los archivos y directorios tienen permisos distintos para estas identidades:

  • El usuario propietario
  • El grupo propietario
  • Usuarios designados
  • Grupos designados
  • Principales de servicio nombrados
  • Identidades administradas designadas
  • Los restantes usuarios

Las identidades de usuarios y grupos son identidades de Microsoft Entra. Así que a menos que se indique lo contrario, un usuario, en el contexto de Data Lake Storage, puede referirse a un usuario de Microsoft Entra, entidad de servicio, identidad administrada o grupo de seguridad.

El superusuario

Un superusuario es el usuario con más derechos. 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.

Si crea un contenedor, archivo o directorio mediante clave compartida, una SAS de cuenta o una SAS de servicio, el propietario y el grupo propietario se establecen en $superuser.

El usuario propietario

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

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

Nota:

El usuario propietario no puede cambiar el usuario propietario de un archivo o directorio. Solo los superusuarios pueden cambiar el usuario propietario de un archivo o directorio.

El grupo propietario

En las ACL de POSIX, todos los usuarios están asociados a un grupo principal. Por ejemplo, el usuario "Alice" puede pertenecer al grupo "finance". Alice puede pertenecer a varios grupos, pero uno de ellos 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 y grupos.

Asignar el grupo propietario de un nuevo archivo o directorio

  • Caso 1: El directorio raíz /. Este directorio se crea cuando se crea un contenedor de Data Lake Storage. En este caso, el grupo propietario se establece en el usuario que creó el contenedor si usa OAuth. Si el usuario crea el contenedor con una clave compartida, una SAS de cuenta o una SAS de servicio, el propietario y el grupo propietario se establecen en $superuser.
  • Caso 2 (cada dos casos): cuando se crea un elemento, se copia el grupo propietario del directorio primario.

Cambiar el 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.

Nota:

El grupo propietario no puede cambiar las ACL de un archivo o directorio. Aunque el grupo propietario se establece en el usuario que creó la cuenta en el caso del directorio raíz, el caso 1 anterior, una cuenta de usuario única no es válida para proporcionar permisos a través del grupo propietario. Puede asignar este permiso a un grupo de usuarios válidos si es aplicable.

Evaluación de los permisos

El sistema evalúa las identidades en el orden siguiente:

  1. Superusuario
  2. usuario propietario
  3. Usuario con nombre, entidad de servicio o identidad administrada
  4. Grupo propietario o grupo con nombre
  5. Los restantes usuarios

Si más de una de estas identidades corresponde a un principal de seguridad, el sistema concede el nivel de permisos asociado a la primera identidad. Por ejemplo, si un principal de seguridad es a la vez el usuario propietario y un usuario identificado, se aplica el nivel de permiso asociado al usuario propietario.

El sistema considera todos los grupos identificados por nombre en conjunto. Si un principal de seguridad pertenece a más de un grupo nombrado, el sistema evalúa cada grupo hasta encontrar el permiso deseado. Si ninguno de los grupos con nombre proporciona el permiso deseado, el sistema pasa a evaluar una solicitud con respecto al permiso asociado a todos los demás usuarios.

El siguiente seudocódigo representa el algoritmo de comprobación de acceso de las cuentas de almacenamiento. Este algoritmo muestra el orden en el que se evalúan las identidades.

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 directory
  # Note: the "sticky bit" isn't illustrated in this algorithm

  # Handle super users.
  if (is_superuser(user)) :
    return True

  # Handle the owning user. Note that mask isn't 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.permissions & mask) == desired_perms)

  # Handle named groups and owning group
  member_count = 0
  perms = 0
  entries = get_acl_entries( path, NAMED_GROUP | OWNING_GROUP )
  mask = get_mask( path )
  for entry in entries:
    if (user_is_member_of_group(user, entry.identity)) :
        if ((desired_perms & entry.permissions & mask) == desired_perms)
            return True

  # Handle other
  perms = get_perms_for_other(path)
  mask = get_mask( path )
  return ( (desired_perms & perms & mask ) == desired_perms)

La máscara

La máscara solo se aplica a la entrada ACL de un usuario específico, un grupo específico y el grupo propietario. La máscara especifica cuáles de los permisos de la entrada de ACL se usan para autorizar el acceso. Estos permisos aplicados se denominan permisos efectivos de la entrada de ACL. El sistema omite todos los demás permisos de la entrada de ACL. Mediante el uso de la máscara, es posible establecer un límite superior en los niveles de permisos.

Puede especificar la máscara para cada llamada. Esta flexibilidad permite que diferentes sistemas de consumo, como los clústeres, tengan diferentes máscaras eficaces para sus operaciones de archivo. Si especifica una máscara en una solicitud determinada, invalida completamente la máscara predeterminada.

El bit persistente

El bit pegajoso es una característica más avanzada de un contenedor POSIX. En el contexto de Data Lake Storage, es improbable que necesita el bit persistente. En resumen, si habilita el bit pegajoso en un directorio, solo el usuario propietario del elemento secundario, el propietario del directorio o el Superusuario ($superuser) pueden eliminar o cambiar el nombre de un elemento secundario.

Azure Portal no muestra el bit persistente. Para obtener más información sobre el bit pegajoso y cómo establecerlo, consulte ¿Qué es el bit pegajoso en Data Lake Storage?

Permisos predeterminados del directorio raíz

En un nuevo contenedor de Data Lake Storage, el valor predeterminado de la ACL de acceso del directorio raíz ("/") es 750 para los directorios y 640 para los archivos. En la tabla siguiente se muestra la notación simbólica de estos niveles de permisos.

Entidad Directorios Archivos
usuario propietario rwx rw-
grupo propietario r-x r--
Otros --- ---

Los archivos no reciben el bit X, ya que este es irrelevante en un sistema de solo almacenamiento.

Permisos predeterminados en archivos y directorios nuevos

Al crear un nuevo archivo o directorio en un directorio existente, la ACL predeterminada en el directorio primario determina:

  • Una ACL de acceso y una ACL predeterminada del directorio secundario.
  • Una ACL de acceso de un archivo secundario (los archivos no tienen ninguna ACL predeterminada).

umask

Al crear una ACL predeterminada, el sistema aplica el umask a la ACL de acceso para determinar los permisos iniciales de la ACL predeterminada. Si define una ACL predeterminada en el directorio primario, el sistema omite el umask y usa la ACL predeterminada del directorio primario para establecer los valores iniciales.

umask es un valor de 9 bits en los directorios principales que contiene un valor RWX para usuario propietario, grupo propietario y otro.

El umask para Azure Data Lake Storage es un valor constante establecido en 007. Este valor se convierte en:

componente umask Formato numérico Formato abreviado Significado
umask.owning_user 0 --- En el caso del usuario propietario, copie la ACL de acceso del elemento principal en la ACL predeterminada del elemento secundario.
umask.owning_group 0 --- En el caso del grupo propietario, copie la ACL de acceso del elemento principal en la ACL predeterminada del elemento secundario.
umask.other 7 RWX En el caso de otro, quite todos los permisos en la ACL de acceso del elemento secundario.

Preguntas más frecuentes

¿Es preciso habilitar la compatibilidad con las ACL?

No. Siempre que la característica Espacio de nombres jerárquico (HNS) esté activada, el control de acceso a través de ACL está habilitado para una cuenta de almacenamiento.

Si HNS está desactivado, todavía se aplican las reglas de autorización de RBAC de Azure.

¿Cuál es la mejor manera de aplicar las ACL?

Use siempre grupos de seguridad de Microsoft Entra como entidad de seguridad asignada en una entrada de ACL. Ofrece la oportunidad de asignar directamente usuarios individuales o entidades de servicio. Con esta estructura, podrá agregar y quitar usuarios o entidades de servicio sin necesidad de volver a aplicar las ACL en una estructura de directorios completa. En su lugar, puede agregar o quitar usuarios y entidades de servicio del grupo de seguridad de Microsoft Entra adecuado.

Hay muchas maneras diferentes de configurar grupos. Por ejemplo, Imagine que tiene un directorio denominado /LogData que contiene los datos de registro generados por su servidor. Azure Data Factory (ADF) ingiere los datos en esa carpeta. Usuarios específicos del equipo de ingeniería de servicios cargarán los registros y administrarán a otros usuarios de esta carpeta, y varios clústeres de Databricks analizarán los registros de esa carpeta.

Para habilitar estas actividades, puede crear un grupo LogsWriter y un grupo LogsReader. Luego, puede asignar permisos como se indica a continuación:

  • Agregue el grupo LogsWriter a la lista de control de acceso del directorio /LogData con permisos de rwx.
  • Agregue el grupo LogsReader a la lista de control de acceso del directorio /LogData con permisos de r-x.
  • Agregue el objeto principal de servicio o Identidad de Servicio Administrada (MSI) para ADF al grupo LogsWriters.
  • Agregue los usuarios del equipo de ingeniería de servicios al grupo LogsWriter.
  • Agregue el objeto de entidad de servicio o MSI para Databricks al grupo LogsReader.

Si un usuario del equipo de ingeniería de servicios deja la empresa, puedes eliminarlo del grupo LogsWriter. Si no agregó dicho usuario a un grupo, sino que en su lugar agregó una entrada de ACL dedicada para ese usuario, tendrá que quitar esa entrada del directorio /LogData. También tendría que quitar la entrada de todos los subdirectorios y archivos de toda la jerarquía de directorios del directorio /LogData.

Para crear un grupo y agregar miembros, vea Crear un grupo básico y agregar miembros mediante Microsoft Entra ID.

Importante

Azure Data Lake Storage Gen2 depende de Microsoft Entra ID para administrar los grupos de seguridad. Microsoft Entra ID recomienda limitar a menos de 200 el número de miembros de un grupo para una entidad de seguridad determinada. Esta recomendación se debe a una limitación de los JSON Web Tokens (JWT) que proporcionan información sobre la pertenencia a grupos de un principal de seguridad en las aplicaciones de Microsoft Entra. Si se superase este límite, se podrían producir problemas de rendimiento inesperados con Data Lake Storage Gen2. Para obtener más información, vea Configurar notificaciones de grupo para aplicaciones mediante Microsoft Entra ID.

¿Cómo se evalúan los permisos de RBAC de Azure y ACL?

Para obtener información sobre cómo el sistema evalúa Azure RBAC y las ACLs en conjunto para tomar decisiones de autorización para los recursos de cuentas de almacenamiento, consulte Evaluación de los permisos.

¿Cuáles son los límites de las asignaciones de roles de Azure y las entradas de ACL?

En la tabla siguiente se proporciona una vista resumida de los límites que se deben tener en cuenta al usar RBAC de Azure para administrar los permisos "generales" (permisos que se aplican a las cuentas de almacenamiento o los contenedores) y usar ACL para administrar permisos "específicos" (permisos que se aplican a archivos y directorios). Utilice grupos de seguridad para las asignaciones de ACL. Mediante el uso de los grupos, es menos probable que supere el número máximo de asignaciones de roles por suscripción y el número máximo de entradas de ACL por archivo o directorio.

Mecanismo Ámbito Límites Nivel de permiso soportado
Azure RBAC Cuentas de almacenamiento, contenedores.
Asignaciones de roles de Azure entre recursos en el nivel de suscripción o de grupo de recursos.		 4000 asignaciones de roles de Azure en una suscripción Roles de Azure (integrados o personalizados)
ACL Directorio, archivo 32 entradas de ACL (realmente 28 entradas de ACL) por archivo y por directorio. Las ACL de acceso y las predeterminadas tienen su propio límite de 32 entradas. Permiso de ACL

¿Admite Data Lake Storage la herencia de RBAC de Azure?

Las asignaciones de roles de Azure se heredan. Las asignaciones fluyen desde la suscripción, el grupo de recursos y los recursos de la cuenta de almacenamiento hasta el recurso del contenedor.

¿Admite Data Lake Storage la herencia de ACL?

Las ACL predeterminadas pueden usarse para establecer las ACL de nuevos subdirectorios y archivos secundarios creados en el directorio principal. Para actualizar las ACL de los elementos secundarios existentes, es necesario agregar, actualizar o eliminar las ACL de forma recursiva en la jerarquía de directorios deseada. Para obtener instrucciones, consulte la sección Establecimiento de las ACL de este artículo.

¿Qué permisos son necesarios para eliminar de forma recursiva un directorio y su contenido?

  • El autor de la llamada tiene permisos de superusuario,

Or

  • El directorio primario tiene permisos de escritura y ejecución.
  • El directorio que se va a eliminar y todos los directorios que contiene requieren permisos de lectura, escritura y ejecución.

Nota:

No necesita permisos de escritura para eliminar archivos en directorios. Además, el directorio raíz "/" nunca se puede eliminar.

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

El creador de un archivo o directorio se convierte en el propietario. En el caso del directorio raíz, esta identidad es el usuario que creó el contenedor.

¿Qué grupo se establece como grupo propietario de un archivo o directorio al crearlo?

El grupo propietario se copia del grupo propietario del directorio principal bajo el cual se crea el nuevo archivo o directorio.

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

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

¿Por qué a veces encuentro GUIDs en ACLs?

Se muestra un GUID si la entrada representa a un usuario y ese 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, las entidades de servicio y los grupos de seguridad no tienen un nombre principal de usuario (UPN) para identificarlos y, por tanto, se representan mediante su atributo OID (un GUID). Para limpiar las ACL, elimine manualmente estas entradas de GUID.

¿Cómo configuro correctamente las listas de control de acceso para un principal de servicio?

Cuando defina las ACL para entidades de servicio, es importante que utilice el identificador de objeto (OID) de la entidad de servicio para el registro de aplicación que creó. Es importante tener en cuenta que las aplicaciones registradas tienen una entidad de servicio independiente en el inquilino específico de Microsoft Entra. Las aplicaciones registradas tienen un OID que es visible en Azure Portal, pero la entidad de servicio tiene otro OID diferente. Artículo: para obtener el OID de la entidad de servicio que corresponde a un registro de aplicación, puede usar el comando az ad sp show. Especifique el identificador de aplicación como parámetro. Este es un ejemplo de cómo obtener el OID del principal del servicio que corresponde a un registro de aplicación con el ID de aplicación = 00001111-aaaa-2222-bbbb-3333cccc4444. Ejecute el siguiente comando en la CLI de Azure:

az ad sp show --id 00001111-aaaa-2222-bbbb-3333cccc4444 --query objectId

Se mostrará OID.

Cuando tenga el OID correcto de la entidad de servicio, vaya a la página Administrar acceso del Explorador de Azure Storage para agregar el OID y asignar los permisos adecuados para este. No olvide seleccionar Guardar.

¿Se puede establecer la ACL de un contenedor?

No. Un contenedor no tiene una ACL. Pero puede establecer la ACL del directorio raíz del contenedor. Cada contenedor tiene un directorio raíz, que comparte el mismo nombre que el contenedor. Por ejemplo, si el nombre del contenedor es my-container, el del directorio raíz será my-container/.

La API REST de Azure Storage contiene una operación denominada Set Container ACL (Establecer ACL del contenedor), pero esa operación no se puede usar para establecer la ACL de un contenedor ni del directorio raíz de un contenedor; En su lugar, dicha operación se utiliza para indicar si se puede acceder a los blobs dentro de un contenedor con una solicitud anónima. Se recomienda exigir autorización para todas las solicitudes a los datos de blobs. Para obtener más información, vea Información general: Corrección del acceso de lectura anónimo para los datos de blobs.

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

Consulte también

  • Last updated on