Azure RBAC es el tema que más aparece en nuestro banco de preguntas de AZ-104. Pero el examen casi nunca se queda en "¿qué es Contributor?". Lo habitual es que muestre una tabla de asignaciones de roles que mezcla usuarios, grupos y ámbitos, y pregunte cosas como "¿Puede User1 reiniciar VM2?" o "¿Qué rol, en qué ámbito, da a este equipo acceso con privilegios mínimos?". El temario oficial incluso enumera por separado "administrar roles integrados de Azure", "asignar roles en distintos ámbitos" e "interpretar asignaciones de acceso".
Este artículo se centra en leer e interpretar asignaciones de roles. Veremos las tres partes de toda asignación de roles, los roles integrados que hay que saber distinguir, el ámbito y la herencia, la diferencia entre asignaciones de denegación y NotActions, la frontera entre los roles de Microsoft Entra y los roles de Azure, y cómo confirmar los permisos reales con Comprobar acceso en la página Control de acceso (IAM). Los conceptos básicos de RBAC se explican primero en Identidad y Gobernanza.
---
Toda Asignación de Roles Tiene Tres Partes
Piensa en la tarjeta de acceso de una oficina. Indica de quién es (la persona), qué nivel tiene (visitante, empleado o administrador) y qué plantas abre (la zona). Si cambias cualquiera de las tres, tienes una tarjeta completamente distinta. Una asignación de roles de Azure es exactamente esa combinación.
| Parte | Pregunta | Valores posibles | |------|------|------| | Entidad de seguridad | ¿Quién? | Usuario, grupo, entidad de servicio, identidad administrada | | Definición de rol | ¿Qué? | Lista de operaciones permitidas (Actions, DataActions) | | Ámbito | ¿Dónde? | Grupo de administración, suscripción, grupo de recursos, recurso |
!Una asignación de roles combina una entidad de seguridad, una definición de rol y un ámbito
Asignar roles a grupos es más fácil de mantener que asignarlos a personas una por una. Cuando asignas un rol a un grupo, quien entra en el grupo obtiene el acceso automáticamente y lo pierde automáticamente al salir. Cuando un recurso como una VM o una aplicación de App Service necesita llegar a otro recurso, activas una identidad administrada y asignas el rol a esa identidad. La identidad administrada asignada por el sistema se crea y se elimina junto con su recurso; la asignada por el usuario es un recurso independiente que varios recursos pueden compartir.
Consejo para el examen: "Permitir que una VM acceda al almacenamiento sin guardar credenciales en el código ni en archivos de configuración" significa asignar un rol de datos de almacenamiento a la identidad administrada de la VM.
---
Roles Integrados que Debes Saber Distinguir
Azure tiene cientos de roles integrados, pero los que aparecen una y otra vez en las preguntas de AZ-104 son pocos. Memoriza también lo que cada rol no puede hacer, porque así es como se descartan las respuestas incorrectas.
| Rol | Puede | No puede | |------|------|------| | Owner (Propietario) | Administrar todos los recursos + asignar roles | Acceder al plano de datos con una cuenta de Entra (necesita un rol de datos aparte) | | Contributor (Colaborador) | Administrar todos los recursos | Asignar roles, administrar asignaciones de Blueprints, compartir galerías de imágenes | | Reader (Lector) | Ver todos los recursos | Hacer cambios | | User Access Administrator (Administrador de acceso de usuario) | Administrar el acceso de usuarios (asignar roles) | Crear o modificar los recursos en sí | | Role Based Access Control Administrator | Asignar roles con Azure RBAC, con la opción de limitarlo mediante condiciones | Administrar el acceso de otras formas, como Azure Policy | | Virtual Machine Contributor | Crear y administrar VM, administrar discos | Administrar la VNet o la cuenta de almacenamiento que usa la VM, asignar roles | | Network Contributor | Administrar redes | Implementar o administrar VM | | Storage Account Contributor | Administrar cuentas de almacenamiento + acceder a las claves de cuenta | Asignar roles | | Storage Blob Data Contributor | Leer, escribir y eliminar contenedores y blobs | Administrar la configuración de la cuenta de almacenamiento | | Tag Contributor | Administrar etiquetas | Acceder a los recursos en sí |
Plano de Control y Plano de Datos
Los permisos de un rol se reparten en dos columnas. Actions son operaciones del plano de control, como crear un recurso o cambiar su configuración. DataActions son operaciones del plano de datos, como leer o escribir el contenido de un blob. Owner y Contributor tienen un comodín (*) en Actions, pero su lista de DataActions está vacía, así que leer datos de blobs con una cuenta de Microsoft Entra requiere un rol adicional.
Hay una trampa. Contributor y Storage Account Contributor incluyen la operación que enumera las claves de cuenta (listkeys), y cuando la tienes, el portal usa la clave de cuenta para mostrarte los datos de los blobs. En sentido contrario, si solo tienes un rol de datos y ningún rol del plano de control de al menos Reader, ni siquiera puedes navegar hasta la cuenta de almacenamiento en el portal.
Consejo para el examen: "Que los usuarios solo puedan leer blobs en el portal con su cuenta de Microsoft Entra" es Reader más Storage Blob Data Reader en el ámbito de la cuenta de almacenamiento. Storage Blob Data Reader por sí solo no permite navegar en el portal.
---
Ámbito y Herencia: el Acceso Fluye Hacia Abajo
Quien tiene la llave maestra del edificio puede abrir todas las salas de todas las plantas. Azure funciona igual: un rol asignado en un ámbito superior lo heredan todos los ámbitos inferiores. De más amplio a más estrecho, los cuatro niveles son grupo de administración → suscripción → grupo de recursos → recurso.
El segundo principio que debes recordar es que Azure RBAC es un modelo aditivo. Cuando varias asignaciones de roles se superponen para una misma persona, sus permisos efectivos son la suma de todas ellas. Asignar un rol más bajo en un ámbito inferior nunca quita un rol más alto heredado desde arriba.
| Situación | Acceso efectivo | |------|------| | Contributor en la suscripción, Reader en RG1 | También Contributor en RG1 (suma) | | Contributor en RG1, Reader en VM1 | También Contributor en VM1 (herencia + suma) | | El grupo tiene Contributor en RG1, el usuario tiene Reader en la suscripción | Administra RG1, solo ve los demás grupos de recursos | | Owner en RG1 | Puede asignar roles a otros dentro de RG1, sin acceso a RG2 |
Consejo para el examen: Cuando un requisito reduce el ámbito, como "administrar solo las VM de RG2 y nada más", elige la respuesta que asigna Virtual Machine Contributor en el ámbito de RG2, no en la suscripción. Si ya existe un rol más alto en el ámbito de la suscripción, el acceso no se reduce hasta que se elimina esa asignación.
---
Dos Formas de Restar Acceso: NotActions y Asignaciones de Denegación
Estas dos "restas" suenan parecido, pero se comportan de forma totalmente distinta, y el examen las mezcla a propósito.
| Elemento | NotActions | Asignación de denegación | |------|------|------| | Dónde está | Dentro de una definición de rol | Un objeto aparte, al mismo nivel que una asignación de roles | | Significado | Operaciones quitadas de un comodín en Actions | Bloquea explícitamente las operaciones indicadas | | Si otro rol permite la misma operación | Se permite (no es una regla de denegación) | Sigue bloqueada | | Quién la crea | El administrador que escribe un rol personalizado | Azure la crea y la administra (no puedes crearla directamente) | | Ejemplo | Contributor excluye las operaciones de asignación de roles | Protección contra eliminación de aplicaciones administradas y pilas de implementación |
Conocer el orden en que Azure Resource Manager evalúa una solicitud también acelera las preguntas de tabla.
Reúne todas las asignaciones de roles y de denegación que se aplican a la operación solicitada Si se aplica una asignación de denegación, bloquea de inmediato Si la suma de asignaciones de roles no incluye la operación, bloquea Si la asignación de roles tiene condiciones, las evalúa antes de decidir
Consejo para el examen: "Un rol personalizado pone la operación de eliminar en NotActions y aun así el usuario puede eliminar" significa que otra asignación de roles concede la eliminación. Para impedir por completo que se elimine un recurso concreto, considera un bloqueo de recursos (CanNotDelete).
---
Los Roles de Entra y los Roles de Azure Viven en Mundos Distintos
Dos "administradores" pueden encargarse de cosas totalmente diferentes. Recursos Humanos gestiona el directorio de empleados; Mantenimiento gestiona el edificio y los equipos. Ser jefe de Recursos Humanos no te da la llave de la sala de servidores.
| Elemento | Roles de Microsoft Entra | Roles de Azure (Azure RBAC) | |------|------|------| | Qué administran | Objetos de directorio como usuarios, grupos, licencias y dominios | Recursos de Azure como VM, almacenamiento y VNet | | Roles típicos | Global Administrator, User Administrator, Billing Administrator | Owner, Contributor, Reader, User Access Administrator | | Ámbito de asignación | Todo el inquilino o una unidad administrativa | Grupo de administración, suscripción, grupo de recursos, recurso | | Dónde se asignan | Roles y administradores en el Centro de administración de Entra | Control de acceso (IAM) en cada ámbito |
De forma predeterminada, ningún mundo entra en el otro. La excepción es la elevación de acceso de un Global Administrator. Al poner "Administración del acceso para los recursos de Azure" en Sí en las propiedades de Entra ID, esa persona recibe User Access Administrator en el ámbito raíz (/), lo que le permite asignar roles en todas las suscripciones y grupos de administración del inquilino. Vuelve a ponerlo en No cuando termines.
Los roles clásicos de administrador de suscripciones que mencionan los materiales antiguos, Account Administrator, Service Administrator