AZ-104
Deep Dive
El sistema de autorización de Azure. El AZ-104 evalúa asignación de roles, scope, herencia, roles personalizados y principio de mínimo privilegio.
Contenido
RBAC (Role-Based Access Control) controla quién puede hacer qué sobre qué recursos en Azure. Una asignación de rol = Security Principal + Role Definition + Scope.
Security Principal
¿A quién se asigna el rol?
Role Definition
¿Qué puede hacer?
Scope
¿Sobre qué recursos?
Los roles se heredan hacia abajo. Asignar en un scope superior = afecta todos los recursos hijos.
Management Group
/providers/Microsoft.Management/managementGroups/{id}
↳ Afecta todas las suscripciones del grupo y sus recursos
Subscription
/subscriptions/{subscriptionId}
↳ Afecta todos los RGs y recursos de esa suscripción
Resource Group
/subscriptions/{id}/resourceGroups/{name}
↳ Afecta todos los recursos dentro del RG
Resource
/subscriptions/{id}/resourceGroups/{rg}/providers/{type}/{name}
↳ Solo ese recurso específico
Herencia: Un rol asignado en Subscription level → el usuario tiene ese rol en TODOS los RGs y recursos de esa sub. Los permisos fluyen de arriba hacia abajo, nunca al revés.
Azure tiene +300 roles integrados. El AZ-104 evalúa los fundamentales y cuándo usar cada uno.
| Rol | Puede | No puede | Caso típico |
|---|---|---|---|
| Owner | Todo, incluyendo asignar roles | — | Lider técnico de subscripción |
| Contributor | Crear, modificar, eliminar recursos | Asignar roles RBAC ni Azure Policies | Desarrolladores senior, DevOps |
| Reader | Ver todos los recursos y configs | Nada de escritura | Auditores, management, soporte L1 |
| User Access Administrator | Gestionar asignaciones de roles RBAC | Crear/modificar recursos | Admin que gestiona permisos sin tocar recursos |
| Virtual Machine Contributor | Crear y gestionar VMs | Acceder a VNet/Storage donde residen, ni asignar roles | Equipo de operaciones de VMs |
| Storage Blob Data Contributor | Leer/escribir/borrar datos en blobs | Gestionar la storage account en sí (claves, configs) | Apps que leen/escriben blobs |
| Key Vault Administrator | Todas las ops en Key Vault (secrets, keys, certs) | Gestionar el recurso Key Vault en ARM | Equipo de seguridad gestionando secretos |
Control vs Data plane — distinción crítica
Control plane (ARM)
Gestionar el RECURSO: crear, configurar, eliminar. Ej: crear un blob container, cambiar el tier de Storage. Controlado por actions/notActions.
Data plane
Acceder a los DATOS dentro del recurso: leer/escribir blobs, leer secrets de Key Vault. Controlado por dataActions/notDataActions. Requiere roles específicos de datos.
Cuando ningún rol integrado se ajusta exactamente a tus necesidades. Requiere Entra ID P1 o superior.
Anatomía de un Custom Role (JSON)
{
"Name": "VM Operator - Read Only + Start/Stop",
"Description": "Puede ver VMs y iniciar/detener",
"Actions": [
"Microsoft.Compute/virtualMachines/read",
"Microsoft.Compute/virtualMachines/start/action",
"Microsoft.Compute/virtualMachines/deallocate/action"
],
"NotActions": [],
"DataActions": [],
"AssignableScopes": [
"/subscriptions/{subscriptionId}"
]
}Crear un Custom Role — opciones
Azure Portal
Entra ID → Roles and administrators → New custom role (solo para Entra roles) ó Subscription → Access control (IAM) → Add custom role → Start from scratch / clone
PowerShell
New-AzRoleDefinition -InputFile "role.json" — acepta el JSON con la definición completa.
Azure CLI
az role definition create --role-definition role.json
ARM/Bicep
Recurso de tipo Microsoft.Authorization/roleDefinitions — para IaC.
Límites
Reglas de herencia
Deny Assignments
Bloquean acciones específicas aunque haya un Allow en otro rol. Los crean Azure Blueprints y Azure Managed Applications — los usuarios no pueden crear Deny Assignments directamente.
Acceso justo-a-tiempo (JIT) a roles privilegiados. Reduce la superficie de ataque eliminando permisos permanentes. Requiere Entra ID P2.
Eligible vs Active
Permanent Active
El rol está asignado permanentemente — el usuario SIEMPRE tiene el acceso, sin ninguna acción.
Alto — si la cuenta es comprometida, el atacante tiene acceso inmediato
Eligible (PIM)
El usuario es "elegible" para el rol pero debe activarlo explícitamente. La activación puede requerir justificación, MFA, aprobación de otro admin.
Bajo — ventana de acceso limitada, auditable, aprobable
Flujo de activación PIM
PIM también cubre: Roles de Entra ID (Global Admin, etc.) además de roles de Azure RBAC. Y permite Access Reviews para limpiar asignaciones obsoletas.
Cuando un usuario dice "no tengo acceso" o "tengo demasiado acceso", estas son las herramientas para diagnosticar.
Herramientas de diagnóstico
Access control (IAM) → Check access
En cualquier recurso/RG/Subscription: busca un usuario/SP y muestra todos los roles que tiene en ese scope (incluyendo heredados).
Portal: Resource → IAM → Check access → búsqueda por usuarioMy Access portal
El usuario puede ver sus propios accesos, solicitar acceso a paquetes (Entitlement Management) y revisar sus asignaciones activas.
aka.ms/myaccessaz role assignment list
Lista todas las asignaciones de rol para un principal o scope específico.
az role assignment list --assignee user@contoso.com --allGet-AzRoleAssignment
PowerShell equivalente. Útil para scripts de auditoría.
Get-AzRoleAssignment -SignInName user@contoso.comActivity Log
Registra cambios de role assignments: quién asignó qué rol a quién, cuándo. Retención 90 días.
Monitor → Activity Log → filtrar por "Create role assignment"Problemas frecuentes y causas
Usuario tiene acceso que no debería
Causa: Herencia desde un scope superior (Subscription o MG). Verificar con "Check access" en scope más alto.
Solución: Revocar la asignación en el scope correcto
"Acción no autorizada" aunque el rol lo permite
Causa: El recurso específico podría tener un Resource Lock o la acción es dataAction que requiere otro rol.
Solución: Verificar locks y si la operación es de control plane o data plane
Cambio de rol no tiene efecto inmediato
Causa: Los tokens de acceso tienen vigencia de hasta 1 hora. El cambio aplica en el siguiente token.
Solución: Esperar max 1 hora o el usuario cierra sesión y vuelve a entrar
Deny Assignment bloquea acción permitida
Causa: Un Azure Blueprint o Managed App creó un Deny Assignment con prioridad sobre todos los roles.
Solución: Identificar el Deny Assignment en IAM → Deny assignments y contactar al dueño del Blueprint
Límites de RBAC en Azure
Crítico para tenants grandes — usa grupos en vez de usuarios individuales
Menos frecuente pero hay que tenerlo en cuenta
Normalmente no es un problema
Migrar a RBAC moderno — las cuentas classic tienen Owner efectivo
Gestión escalable de RBAC
Usar grupos, no usuarios individuales
Asignar roles a grupos de seguridad. Gestionar membresía del grupo. 1 role assignment para 100 personas = usa solo 1 de los 2.000 límite.
Principio de mínimo privilegio
Siempre asignar el rol más restrictivo que permite hacer el trabajo. Revisar periódicamente con Access Reviews (P2).
Scope más específico posible
Asignar en Resource Group, no Subscription, si el acceso solo es para recursos en ese RG. Reduce blast radius.
Time-bound assignments
En IAM → Add role assignment → hay opción de fecha de expiración. Sin PIM, los RBAC assignments pueden ser time-limited nativamente.
El AZ-104 evalúa la diferencia. Mucha gente los confunde porque ambos "controlan" cosas en Azure.
RBAC responde: ¿Quién puede hacer qué?
Controla las operaciones que puede realizar un security principal. "El usuario X puede crear VMs en este RG."
Azure Policy responde: ¿Qué estado debe tener el recurso?
Controla las propiedades y configuración de los recursos. "Todas las VMs deben tener tags. Todo Storage debe estar encriptado."
| Aspecto | Azure RBAC | Azure Policy |
|---|---|---|
| Objetivo | Controlar quién puede ejecutar operaciones (CRUD) | Controlar el estado/configuración de los recursos |
| Pregunta que responde | ¿Puedo crear esta VM? | ¿Esta VM cumple las reglas de la organización? |
| Efecto de denegación | La operación no se puede ejecutar (no está autorizado) | El recurso no se puede crear si viola la policy (Deny effect) |
| Scope | MG > Subscription > RG > Recurso | MG > Subscription > RG (no a recurso individual) |
| Granularidad | Por operación (ej: solo leer VMs de un RG) | Por propiedad del recurso (ej: tag obligatorio, región permitida) |
| Retroactivo | No — solo aplica a operaciones futuras | Sí — Audit puede marcar recursos existentes no conformes |
| Se usa para | IAM — quién gestiona infraestructura | Compliance — qué configuraciones son aceptables |
Ejemplo combinado
RBAC: Developer tiene Contributor en RG-Dev
Puede crear VMs, modificar storage, desplegar apps en ese RG.
Policy: "VMs solo en East US, sin SKU premium"
Aunque el dev PUEDE crear VMs (RBAC), si intenta crear una en West Europe o con un SKU premium, la Policy la rechaza.
RBAC controla la capacidad. Policy controla las reglas. Necesitas ambos.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Un auditor externo necesita revisar todos los recursos de una suscripción de Azure sin poder modificar nada. ¿Qué rol RBAC debe asignarle?