Modelo de control de acceso de Azure Data Lake Storage

Data Lake Storage admite los siguientes mecanismos de autorización:

• Autorización de clave compartida
• Autorización de firma de acceso compartido (SAS)
• Control de acceso basado en roles (RBAC de Azure)
• Control de acceso basado en atributos (Azure ABAC)
• Listas de control de acceso (ACL)

La clave compartida y la autorización SAS conceden acceso a un usuario (o aplicación) sin necesidad de que tenga una identidad en Microsoft Entra ID. Con estas dos formas de autenticación, Azure RBAC y las listas de control de acceso no tienen ningún efecto.

Tanto Azure RBAC como ACL requieren que el usuario (o aplicación) tenga una identidad en Microsoft Entra ID. Azure RBAC le permite conceder acceso de "grano grueso" a los datos de la cuenta de almacenamiento, como el acceso de lectura o escritura a todos los datos de una cuenta de almacenamiento. Azure ABAC permite refinar las asignaciones de roles RBAC añadiendo condiciones. Por ejemplo, puede conceder acceso de lectura o escritura a todos los objetos de datos de una cuenta de almacenamiento que tengan una etiqueta específica. Las listas de control de acceso permiten conceder acceso de "grano fino", como el acceso de escritura a un directorio o archivo específico.

Este artículo se centra en Azure RBAC, ABAC y las listas de control de acceso y en cómo el sistema los evalúa en conjunto para tomar decisiones relacionadas con la autorización para los recursos de las cuentas de almacenamiento.

Control de acceso basado en roles (RBAC de Azure)

RBAC de Azure usa las asignaciones de roles para aplicar conjuntos de permisos a entidades de seguridad. Una entidad de seguridad es un objeto que representa a un usuario, grupo, entidad de servicio o identidad administrada que se define en Microsoft Entra ID. Un conjunto de permisos puede dar a una entidad de seguridad un nivel de acceso más "general", como acceso de lectura o escritura a todos los datos de una cuenta de almacenamiento o a todos los datos de un contenedor.

Los roles siguientes permiten que una entidad de seguridad acceda a los datos de una cuenta de almacenamiento.

Rol	Descripción
Propietario de datos de blobs de almacenamiento	Acceso total a datos y contenedores de Blob Storage. Este acceso permite que la entidad de seguridad establezca el propietario de un elemento y modifique las listas de control de acceso de todos los elementos.
Colaborador de datos de blobs de almacenamiento	Acceso de lectura, escritura y eliminación a blobs y contenedores de Blob Storage. Este acceso no permite que la entidad de seguridad establezca la propiedad de un elemento, pero puede modificar la lista de control de acceso de los elementos que pertenecen a la entidad de seguridad.
Lector de datos de blobs de almacenamiento	Lee y enumera blobs y contenedores de Blob Storage.

Los roles como Propietario, Colaborador, Lector y Colaborador de la cuenta de almacenamiento permiten que una entidad de seguridad administre una cuenta de almacenamiento, pero no proporcionan acceso a los datos dentro de esa cuenta. Sin embargo, estos roles (excepto el rol Lector) pueden obtener acceso a claves de almacenamiento que se pueden usar en diversas herramientas de cliente para acceder a los datos.

Control de acceso basado en atributos (Azure ABAC)

Azure ABAC se basa en Azure RBAC con la adición de condiciones de asignación de roles basadas en atributos en el contexto de acciones específicas. Una condición de asignación de roles es una comprobación adicional que puede agregar opcionalmente a la asignación de roles para proporcionar un control de acceso más preciso. No se puede denegar explícitamente el acceso a recursos específicos mediante condiciones.

Para obtener más información sobre el uso de Azure ABAC para controlar el acceso a Azure Storage, consulte Autorización del acceso a Azure Blob Storage mediante las condiciones de asignación de roles de Azure.

Listas de control de acceso (ACL)

Las ACL le ofrecen la posibilidad de aplicar un nivel de acceso más "específico" a los directorios y archivos. Una ACL es una construcción de permisos que contiene una serie de entradas de ACL. Cada entrada de ACL asocia una entidad de seguridad a un nivel de acceso. Para más información, consulte Listas de control de acceso (ACL) en Azure Data Lake Storage.

Evaluación de los permisos

Durante la autorización basada en la entidad de seguridad, los permisos se evalúan como se muestra en el siguiente diagrama.

1. Azure determina si existe una asignación de roles para la entidad de seguridad.
   • Si existe una asignación de roles, las condiciones de asignación de roles (2) se evalúan a continuación.
   • Si no es así, las listas de control de acceso (4) se evalúan a continuación.
2. Azure determina si existen condiciones de asignación de roles de ABAC.
   • Si no existen condiciones, se concede el acceso.
   • Si existieran condiciones, se evaluarán para ver si coinciden con la solicitud (3).
3. Azure determinará si todas las condiciones de asignación de roles ABAC coinciden con los atributos de la solicitud.
   • Si todos ellos coincidieran, se concederá el acceso.
   • Si al menos uno de ellos no coincidiera, las ACL (4) se evaluarán a continuación.
4. Si el acceso no se ha concedido explícitamente después de evaluar las asignaciones de roles y las condiciones, se evalúan las listas de control de acceso.
   • Si las listas de control de acceso permiten el nivel de acceso solicitado, se concede el acceso.
   • Si no es así, se deniega el acceso.

Importante

Debido a la manera en que el sistema evalúa los permisos de acceso, no es posible usar una lista de control de acceso para restringir un acceso ya concedido por una asignación de roles y sus condiciones. Esto se debe a que el sistema evalúa primero las asignaciones de roles y condiciones de Azure y si la asignación concede permisos de acceso suficientes, las listas de control de acceso se omiten.

En el diagrama siguiente se muestra el flujo de permisos para tres operaciones comunes: enumerar el contenido de un directorio, leer un archivo y escribir un archivo.

Tabla de permisos: combinación de Azure RBAC, ABAC y ACL

En la siguiente tabla se muestra cómo combinar roles de Azure y entradas de lista de control de acceso para que una entidad de seguridad pueda realizar las operaciones que se muestran 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. En esas columnas se muestran representaciones abreviadas de la entrada de ACL que se necesita para conceder permisos. En la columna aparece N/A (No aplicable) si no se necesita ninguna entrada de ACL para realizar la operación.

Operación	Rol de Azure asignado (con o sin condiciones)	/	Oregón/	Portland/	Data.txt
Leer Data.txt	Propietario de datos de blobs de almacenamiento	N/D	N/D	N/D	N/D
	Colaborador de datos de blobs de almacenamiento	N/D	N/D	N/D	N/D
	Lector de datos de blobs de almacenamiento	N/D	N/D	N/D	N/D
	None	--X	--X	--X	R--
Anexar a Data.txt	Propietario de datos de blobs de almacenamiento	N/D	N/D	N/D	N/D
	Colaborador de datos de blobs de almacenamiento	N/D	N/D	N/D	N/D
	Lector de datos de blobs de almacenamiento	--X	--X	--X	-W-
	Ninguno	--X	--X	--X	RW-
Eliminar Data.txt	Propietario de datos de blobs de almacenamiento	N/D	N/D	N/D	N/D
	Colaborador de datos de blobs de almacenamiento	N/D	N/D	N/D	N/D
	Lector de datos de blobs de almacenamiento	--X	--X	-WX	N/D
	None	--X	--X	-WX	N/D
Crear Data.txt	Propietario de datos de blobs de almacenamiento	N/D	N/D	N/D	N/D
	Colaborador de datos de blobs de almacenamiento	N/D	N/D	N/D	N/D
	Lector de datos de blobs de almacenamiento	--X	--X	-WX	N/D
	None	--X	--X	-WX	N/D
Enumerar /	Propietario de datos de blobs de almacenamiento	N/D	N/D	N/D	N/D
	Colaborador de datos de blobs de almacenamiento	N/D	N/D	N/D	N/D
	Lector de datos de blobs de almacenamiento	N/D	N/D	N/D	N/D
	None	R-X	N/D	N/D	N/D
Enumerar /Oregón/	Propietario de datos de blobs de almacenamiento	N/D	N/D	N/D	N/D
	Colaborador de datos de blobs de almacenamiento	N/D	N/D	N/D	N/D
	Lector de datos de blobs de almacenamiento	N/D	N/D	N/D	N/D
	None	--X	R-X	N/D	N/D
Enumerar /Oregón/Portland/	Propietario de datos de blobs de almacenamiento	N/D	N/D	N/D	N/D
	Colaborador de datos de blobs de almacenamiento	N/D	N/D	N/D	N/D
	Lector de datos de blobs de almacenamiento	N/D	N/D	N/D	N/D
	None	--X	--X	R-X	N/D

Nota:

Para ver el contenido de un contenedor en Azure Storage Explorer, los responsables de seguridad deben iniciar sesión en el Explorador de almacenamiento utilizando Microsoft Entra ID, y (como mínimo) tener acceso de lectura (R--) a la carpeta raíz (\) de un contenedor. Este nivel de permiso les permite mostrar el contenido de la carpeta raíz. Si no quiere que el contenido de la carpeta raíz esté visible, puede asignarles el rol Lector. Con ese rol, podrán enumerar los contenedores de la cuenta, pero no el contenido de cada contenedor. Después, puede conceder acceso a directorios y archivos específicos mediante las listas de control de acceso.

Grupos de seguridad

Utilice siempre grupos de seguridad de Microsoft Entra como entidad de seguridad asignada en una entrada 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, solo 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 concretos 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 de archivos 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 de entidad de servicio o Managed Service Identity (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, puede quitarle 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 la información de pertenencia a grupos de una entidad de seguridad principal dentro de las aplicaciones 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, consulte Configuración de reclamaciones de grupo para aplicaciones mediante Microsoft Entra ID.

Límites en las asignación de roles de Azure y entradas 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. En la siguiente tabla se describen estos límites.

Mechanism	Ámbito	Límites	Nivel de permiso admitido
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 predeterminadas tienen su propio límite de 32 entradas de ACL.	Permiso de ACL

Autorización con clave compartida y firma de acceso compartido (SAS)

Azure Data Lake Storage también admite los métodos de clave compartida y SAS para la autenticación. Una característica de estos métodos de autenticación es que no se asocia ninguna identidad con el autor de la llamada y, en consecuencia, no se puede realizar la autorización basada en permisos de la entidad de seguridad.

En el caso de la clave compartida, el autor de la llamada obtiene acceso de "superusuario" de forma eficaz, lo que significa que puede acceder plenamente a todas las operaciones en todos los recursos, lo que incluye los datos, la configuración del propietario y el cambio de las ACL.

Los tokens de SAS incluyen permisos permitidos como parte del token. Los permisos incluidos en el token de SAS se aplican con eficacia a todas las decisiones de autorización, pero no se realizan comprobaciones de ACL adicionales.

Pasos siguientes

Para más información sobre las listas de control de acceso, consulte Listas de control de acceso (ACL) en Azure Data Lake Storage.