El diseño de autorización en AZ-305 gira en torno al principio de menor privilegio: elegir el rol más restrictivo posible, en el ámbito más pequeño posible, asignado a grupos. Y cuando ningún rol integrado encaja, diseñar un rol personalizado.
Contenido
🔑RBAC — herencia de roles por scope
El usuario John tiene Reader asignado en la Subscription y Contributor en RG-Frontend. Los roles fluyen hacia abajo. Pasa el cursor sobre cada nodo para ver el acceso efectivo.
Acceso efectivo — John
Subscription
RG-Frontend
RG-Backend
VM web-01
Regla clave
Los permisos son aditivos. El rol más permisivo gana. Solo un Deny Assignment rompe esta regla.
⬇️ Herencia hacia abajo
Un rol en Subscription aplica a todos los RGs y recursos de esa Subscription. Un rol en RG aplica solo a los recursos de ese RG.
➕ RBAC es aditivo
Múltiples asignaciones se suman (union). Reader en Sub + Contributor en RG = Contributor efectivo en ese RG. El más permisivo gana.
🚫 No herencia hacia arriba
Contributor en RG-Frontend no da ningún acceso en RG-Backend ni en la Subscription. Los permisos solo fluyen de arriba hacia abajo.
Una asignación RBAC = security principal (usuario, grupo, service principal, managed identity) + role definition (lista de actions permitidas) + scope (management group, suscripción, RG o recurso). Las asignaciones se heredan hacia abajo y son aditivas.
Reglas de evaluación
Buenas prácticas de diseño
| Rol | Permite | NO permite |
|---|---|---|
| Owner | Todo, incluida la gestión de RBAC | — |
| Contributor | Crear/gestionar todos los recursos | Asignar roles, gestionar locks de forma fiable |
| Reader | Ver todos los recursos | Cualquier cambio; no lee secretos/datos |
| User Access Administrator | Gestionar acceso (asignar roles) | Gestionar recursos |
| Role Based Access Control Administrator | Asignar roles con condiciones (más restringido que UAA) | Gestionar recursos |
| Storage Blob Data Contributor | Leer/escribir/borrar blobs (data plane) | Gestionar la storage account |
| Key Vault Administrator | Todo el data plane de Key Vault (RBAC mode) | Gestionar el recurso Key Vault (control plane) |
| Network Contributor | Gestionar redes (VNets, NSGs...) | Otros tipos de recursos |
| Virtual Machine Contributor | Gestionar VMs | Acceder a la VNet ni iniciar sesión en la VM |
Trampa clásica
Contributor NO puede asignar roles. Si el escenario pide que alguien gestione recursos Y dé acceso a otros, necesita Owner o Contributor + User Access Administrator (mejor: RBAC Administrator con condiciones, menor privilegio).
Crear un rol personalizado solo cuando ningún rol integrado cumple el menor privilegio. Ejemplo clásico: "los operadores deben poder reiniciar VMs pero no crearlas ni eliminarlas" — ningún rol integrado da exactamente eso.
Anatomía de un rol personalizado
{
"Name": "VM Operator",
"Description": "Reiniciar y ver VMs",
"Actions": [
"Microsoft.Compute/virtualMachines/read",
"Microsoft.Compute/virtualMachines/restart/action",
"Microsoft.Compute/virtualMachines/start/action"
],
"NotActions": [],
"DataActions": [],
"AssignableScopes": [
"/providers/Microsoft.Management/
managementGroups/produccion"
]
}Reglas de diseño
Roles de Entra ID (directorio)
Azure RBAC (recursos)
| Requisito | Diseño |
|---|---|
| Devs gestionan recursos de su RG pero no dan acceso a otros | Contributor en el resource group |
| App lee blobs sin claves de cuenta | Managed identity + Storage Blob Data Reader (DataAction) |
| Operadores solo reinician/arrancan VMs | Rol personalizado (read + start/restart actions) |
| Reutilizar un rol personalizado en 20 suscripciones | AssignableScopes = management group padre |
| Helpdesk resetea contraseñas de usuarios | Rol de Entra ID: Helpdesk/User Administrator (no RBAC) |
| Gestionar quién accede sin poder tocar recursos | User Access Administrator (o RBAC Administrator con condiciones) |
| Acceso de administrador solo durante incidentes | PIM con asignación eligible |
| 1000 usuarios con el mismo acceso | Asignación a un grupo de seguridad, nunca individual |
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
El equipo de operaciones debe poder iniciar, detener y reiniciar las VMs de producción en 15 suscripciones, sin poder crearlas, eliminarlas ni modificar su configuración. Quieres mínimo esfuerzo administrativo. ¿Qué diseñas?
Inicia sesión para llevar tu progreso.