Modelo de control de acceso de Azure Data Lake Storage Gen2
Data Lake Storage Gen2 admite los mecanismos de autorización siguientes:
- 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 Gen2.
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.
- 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.
- 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).
- 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.
- 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 debe que agregar o eliminar usuarios y principales de servicio del grupo de seguridad apropiado de Microsoft Entra.
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
LogsWritera la lista de control de acceso del directorio /LogData con permisos derwx. - Agregue el grupo
LogsReadera la lista de control de acceso del directorio /LogData con permisos der-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, consulte 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 Tokens Web JSON (JWT) que proporcionan la información de pertenencia a grupos de una entidad de seguridad 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 Gen2 también admite los métodos de autenticación con clave compartida y SAS. 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 obtener más información sobre las listas de control de acceso, consulte Listas de control de acceso (ACL) en Azure Data Lake Storage Gen2.