Azure (no Entra):

RBAC de recursos, Key Vault y Defender for Cloud

Seguridad en la nube  |  unfantasmaenelsistema.com

Mucha gente que trabaja con Azure usa «Azure AD» y «Azure» como si fueran lo mismo, y ahí empieza la confusión de permisos. Entra ID (el antiguo Azure AD) es el directorio de identidades: quién eres, a qué grupos perteneces, qué aplicaciones puedes usar. Azure RBAC es otra cosa: controla qué puedes hacer sobre los recursos — una máquina virtual, una cuenta de almacenamiento, una base de datos — dentro de una suscripción. Son dos sistemas de autorización distintos, con roles distintos, y un administrador de Entra no es automáticamente administrador de los recursos.

Este artículo se centra en la mitad «recursos»: cómo funciona Azure RBAC y sus ámbitos, qué roles concentran poder, cómo se guardan los secretos en Key Vault sin repetir los errores clásicos, qué son las Managed Identities, y cómo Defender for Cloud y Azure Policy te dan una foto continua de lo que está mal. El enfoque es defensivo y sobre tu propia suscripción. Es el complemento del artículo sobre Entra ID, donde cubrimos la parte de identidad.

1. Dos sistemas de permisos, no uno

En Azure conviven dos planos de autorización que se evalúan por separado:

• Roles de Entra ID (directory roles): Global Administrator, User Administrator, Privileged Role Administrator, etc. Gobiernan el directorio: usuarios, grupos, registros de aplicación, políticas de acceso condicional. No dan, por sí mismos, acceso a una VM
• Roles de Azure RBAC: Owner, Contributor, Reader y varios cientos de roles específicos por servicio. Gobiernan las operaciones sobre recursos a través del proveedor de recursos de Azure (el plano de gestión, `management.azure.com`)

Hay un punto de cruce importante: el Global Administrator de Entra puede, con un solo clic («elevación de acceso»), concederse el rol User Access Administrator en la raíz de todas las suscripciones del tenant. Es decir, quien controla el directorio puede tomar el control de los recursos. Por eso el número de Global Admins y su protección con MFA y PIM es una cuestión de seguridad de toda la plataforma, no solo del directorio.

2. Azure RBAC: ámbitos, definiciones y asignaciones

Una asignación de rol en RBAC son tres cosas: un principal (usuario, grupo, service principal o managed identity), una definición de rol (el conjunto de acciones permitidas) y un ámbito (dónde aplica). El ámbito es jerárquico y la asignación se hereda hacia abajo.

Complementos que acotan el poder de RBAC: los deny assignments (los crean Azure Blueprints y los Managed Applications, no se editan a mano), las condiciones ABAC sobre algunas acciones de almacenamiento, y los resource locks (`CanNotDelete`, `ReadOnly`), que frenan borrados accidentales aunque no son un control de seguridad frente a un atacante con permisos.

3. Key Vault: dónde viven los secretos

Azure Key Vault guarda tres tipos de objeto: secretos (cadenas: contraseñas, cadenas de conexión), claves (criptográficas, con opción de respaldo en HSM) y certificados. El punto delicado no es el almacén en sí, sino quién puede leer de él y qué pasa cuando alguien borra algo.

3.1 Dos modelos de autorización

• Access policies (el modelo antiguo): una lista por vault donde cada principal recibe permisos sobre secretos, claves y certificados. No es granular por objeto y no se integra con PIM ni con las herramientas de gobierno de RBAC
• Azure RBAC para Key Vault (el modelo recomendado): usa roles como `Key Vault Secrets User`, `Key Vault Crypto Officer`, `Key Vault Reader`. Se audita y se gestiona igual que el resto de RBAC, admite ámbito por secreto individual y se lleva bien con PIM

3.2 Soft-delete y purge protection

Soft-delete conserva los objetos borrados (y el propio vault) durante un periodo de retención, de modo que se puedan recuperar. Está activado de forma obligatoria. Purge protection va un paso más allá: impide el borrado definitivo antes de que expire la retención, incluso para un administrador. Sin purge protection, alguien con permisos de gestión puede borrar un vault y purgarlo de inmediato, destruyendo claves de las que dependen discos cifrados o bases de datos. Actívala en todo vault que guarde claves de cifrado.

4. Managed Identities: sin contraseñas para las cargas de trabajo

Una Managed Identity es un service principal en Entra ID cuyo ciclo de vida gestiona Azure por ti. La carga de trabajo (una VM, una App Service, una Function, un contenedor) obtiene tokens de Entra a través del endpoint local de identidad, sin que haya ninguna credencial almacenada en el código ni en la configuración.

• Asignada por el sistema: ligada a un recurso concreto; se crea y se borra con él. Ideal para relaciones uno a uno
• Asignada por el usuario: un recurso independiente que puedes adjuntar a varias cargas. Útil cuando varias aplicaciones comparten el mismo conjunto de permisos
• El patrón correcto: la App Service tiene una managed identity con el rol `Key Vault Secrets User` solo sobre su vault, y lee de él la cadena de conexión a la base de datos. Cero secretos en variables de entorno

5. Defender for Cloud y Azure Policy: la foto continua

Saber que la configuración es correcta el día del despliegue no sirve de nada si nadie vuelve a mirar. Azure ofrece dos herramientas complementarias para vigilar la deriva.

El flujo sano: Defender for Cloud te muestra qué está mal (puertos de gestión abiertos, almacenamiento sin «secure transfer», SQL sin auditoría, VMs sin cifrado de disco); resuelves lo prioritario; y para lo que no debe repetirse, creas una Azure Policy con efecto `deny` asignada a nivel de grupo de administración para que nadie pueda volver a crearlo mal.

6. Auditar tu suscripción

Todo lo siguiente es de solo lectura sobre tu propia suscripción.

# Todas las asignaciones de Owner en la suscripcion, con el principal y el ambito
az role assignment list --all --role Owner \
    --query "[].{quien:principalName, ambito:scope, tipo:principalType}" -o table
 
# Resource Graph: recursos con IP publica asociada
az graph query -q "Resources | where type =~ 'microsoft.network/publicipaddresses'
  | where isnotempty(properties.ipConfiguration) | project name, resourceGroup, location"
 
# Activity Log: cambios de asignaciones de rol en los ultimos 7 dias
az monitor activity-log list --offset 7d \
    --query "[?contains(operationName.value, 'roleAssignments/write')]" -o table

7. Lo mínimo que debería estar hecho

• Poquísimos Global Admins en Entra y poquísimos Owner en cada ámbito de Azure, todos nominales, todos con MFA y bajo PIM (activación temporal, no permanente)
• Asignar RBAC a grupos y en el ámbito de grupo de recursos, no a personas ni en la suscripción entera
• Key Vault en modelo RBAC, con purge protection y acceso de red restringido
• Cargas de trabajo con Managed Identity de permiso mínimo; ningún secreto en configuración ni en el repositorio
• Defender for Cloud activo, Secure Score vigilado, y las reglas que no deben romperse convertidas en Azure Policy con efecto deny a nivel de grupo de administración
• Activity Log y los registros de diagnóstico de Key Vault exportados a Log Analytics; revisión trimestral de asignaciones privilegiadas

Conclusión

La mayoría de los sustos en Azure no vienen de un fallo de la plataforma, sino de mezclar los dos planos de permisos y de conceder de más: un Owner en la suscripción «para ir rápido», un Key Vault compartido sin purge protection, una managed identity con Contributor sobre todo el entorno. El modelo tiene sus asimetrías — el Global Admin que puede elevarse a los recursos, el Contributor que no toca RBAC pero sí crea identidades — y conviene tenerlas presentes.

La defensa es conocida: ámbitos estrechos, roles a grupos, PIM para lo privilegiado, secretos solo en Key Vault con managed identities, y Defender for Cloud más Azure Policy para que la configuración correcta de hoy siga siéndolo dentro de seis meses. Ninguna de esas piezas es cara y todas se revisan en una tarde.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)