Azure IAM: RBAC, identidades y errores comunes

La gestión de identidades en Azure es el sistema por el cual Microsoft Azure controla quién puede acceder a qué recursos de nube, en qué nivel de la jerarquía organizacional, y con qué permisos específicos. Está construida sobre cuatro capas: Management Groups, suscripciones, grupos de recursos y recursos individuales, con roles asignables en cualquier nivel.

Microsoft es una corporación de tecnología fundada en 1975 por Bill Gates y Paul Allen, que desarrolla sistemas operativos, software y servicios en la nube. Proporciona soluciones de computación para empresas y usuarios finales, incluyendo Windows, Office y Azure.

El problema de compartir credenciales: por qué una contraseña maestra es un desastre

Ponele que acabás de contratar 200 personas. Desarrolladores, managers, pasantes, y tal vez algunos sistemas automatizados corriendo de noche. Necesitás darles acceso a los recursos de nube lo antes posible. ¿Qué hace alguien desesperado? Un usuario, una contraseña compartida, y dejar que cada uno se arregle.

Eso exactamente hizo Richard, el fundador ficticio de Richard Inc., una startup de delivery de comida en Nigeria que describe este caso en Dev.to. Tres días después de dar acceso master a sus 200 empleados, un pasante sobreexcitado, convencido de que estaba en el entorno de pruebas, eliminó la base de datos de producción un viernes a las 16:55, justo antes del rush del fin de semana.

No es un ejemplo inventado para asustar. Es el patrón más común en empresas que crecen rápido y no tienen tiempo (o ganas) de configurar el acceso correctamente desde el principio.

El problema con una credencial compartida no es solo el incidente puntual. Es que no podés saber quién hizo qué, no podés revocar el acceso a una sola persona sin cambiar la contraseña para todos, y si el pasante se va, su acceso sigue activo porque nadie sabe qué credenciales usaba exactamente. La auditoría es imposible, la revocación parcial también.

Arquitectura jerárquica de Azure: cómo se organiza el acceso

Azure tiene una estructura de árbol con cuatro niveles. Entender esta jerarquía es la base de todo lo demás. Ya lo cubrimos antes en ecosistema integrado de Microsoft.

Management Groups: el nivel más alto

Los Management Groups de Azure son contenedores que agrupan suscripciones. Pensalos como las divisiones de negocio de una empresa: una para el área de entregas, otra para compras, otra para logística. Las políticas que se aplican en este nivel se heredan hacia abajo en toda la jerarquía. Si querés que ninguna suscripción pueda crear recursos en regiones fuera de Latinoamérica, lo definís una vez acá, y listo.

Suscripciones y grupos de recursos

Las suscripciones son la unidad de facturación y el límite de aislamiento entre proyectos o equipos grandes. Dentro de cada suscripción, los grupos de recursos agrupan los recursos relacionados de un proyecto concreto: una web app, su base de datos, su cuenta de almacenamiento. Los recursos individuales son el nivel más granular: una VM específica, un Key Vault, una función serverless.

Lo importante: los permisos se pueden asignar en cualquiera de los cuatro niveles, y se heredan hacia abajo. Si le das a alguien el rol de Contributor en una suscripción, tiene ese permiso en todos los grupos de recursos y recursos dentro de ella.

Control de acceso basado en rol (RBAC): qué es y cómo funciona

La gestión de identidades en Azure se apoya sobre RBAC como mecanismo central. Según la documentación oficial de Microsoft, RBAC permite asignar permisos específicos a identidades (usuarios, grupos, aplicaciones) en cualquier nivel de la jerarquía, sin dar más acceso del necesario.

Los roles predefinidos más comunes:

• Reader: puede ver recursos, no modificarlos. Ideal para auditores o stakeholders.
• Contributor: puede crear y modificar recursos, pero no puede cambiar permisos de acceso.
• Owner: acceso completo, incluyendo gestión de permisos. Usalo con moderación.
• User Access Administrator: solo puede gestionar accesos, sin tocar los recursos en sí.

¿Y qué pasó cuando alguien le dio Owner a todo el equipo de desarrollo para “ahorrar tiempo”? Exacto: el primer deploy con un bug borró configuraciones de seguridad que nadie supo restablecer porque tampoco había documentación.

El principio de privilegios mínimos acá es simple: dar el nivel mínimo de acceso que necesita una persona para hacer su trabajo. Nada más. Si un dev solo necesita deployar en un grupo de recursos de desarrollo, dale Contributor en ese grupo de recursos, no en toda la suscripción.

Identidades administradas vs identidades de usuario: la diferencia que importa

Las aplicaciones también necesitan acceder a recursos de Azure. Una app en Azure App Service que lee secretos de Key Vault, por ejemplo. La solución clásica y terrible: poner las credenciales hardcodeadas en el código, o en un archivo de configuración que termina en el repositorio. Más contexto en automatización de pipelines en Azure.

Las identidades administradas existen para eliminar ese problema. Son identidades creadas automáticamente por Azure, asociadas a un recurso (una VM, una función, una app service), y Azure rota las credenciales sin que vos tengas que hacer nada. No hay contraseñas que administrar ni secretos que guardar.

Característica	Identidad administrada	Identidad de usuario
Para quién	Aplicaciones y servicios	Personas
Gestión de credenciales	Azure la maneja automáticamente	El usuario (con MFA obligatoria)
Rotación de secretos	Automática	Manual o con políticas
Riesgo de credencial filtrada	Muy bajo	Medio (depende de prácticas)
Uso típico	App Service accediendo a Key Vault, Storage, SQL	Desarrolladores, admins, operadores
Requiere MFA	No aplica	Sí, obligatoria desde oct 2025

Hay dos tipos: las identidades administradas asignadas por el sistema (mueren con el recurso) y las asignadas por el usuario (las podés reutilizar en varios recursos). Para un caso de uso simple como una única app accediendo a Key Vault, la asignada por el sistema es suficiente. Para escenarios más complejos donde varios servicios comparten el mismo perfil de acceso, la asignada por el usuario tiene más sentido.

Mejores prácticas de seguridad: lo que hacen los equipos que no se llevan sustos

Más allá de RBAC y las identidades administradas, hay algunas prácticas que Microsoft lista en su guía de mejores prácticas y que la mayoría de los equipos ignora hasta que algo se rompe.

Privileged Identity Management (PIM) es una de las más importantes. En vez de dar acceso permanente a roles privilegiados como Owner o Security Administrator, PIM permite acceso just-in-time: la persona solicita el rol, lo tiene por un tiempo limitado (una hora, cuatro horas), y después se revoca automáticamente. La “innovación” acá no es nueva, pero la adopción sigue siendo baja en equipos que piensan que es mucho overhead.

Revisiones de acceso periódicas. Cada tres o seis meses, auditá quién tiene acceso a qué. Los ex-empleados cuyas cuentas no se desactivaron a tiempo, los proveedores externos que siguen teniendo acceso de Contributor a un grupo de recursos que ya no usan, los invitados de proyectos que terminaron hace ocho meses. Esto pasa más seguido de lo que parece.

MFA obligatoria. Desde octubre de 2025, Microsoft impuso MFA para todas las cuentas que acceden al portal de Azure. Si todavía tenés cuentas de servicio que se autentican solo con usuario y contraseña porque “esa automatización vieja no soporta MFA”, es el momento de migrarlas a identidades administradas. Complementá con herramientas de despliegue automático.

Cómo implementar una estrategia de IAM desde cero

Si arrancás de cero (o si heredaste un ambiente que creció sin orden), el camino es más o menos este:

• Paso 1: Diseñá la jerarquía de Management Groups antes de crear recursos. Organizalos por función (producción, desarrollo, pruebas) o por equipo, según cómo trabaje tu empresa.
• Paso 2: Creá grupos de seguridad en Microsoft Entra ID. Los roles se asignan a grupos, no a usuarios individuales. Así, cuando alguien entra o sale, alcanza con agregarlo o quitarlo del grupo.
• Paso 3: Asigná roles a grupos en los niveles apropiados. El grupo “DevOps-Engineers” tiene Contributor en el grupo de recursos de desarrollo. El grupo “Managers-Finance” tiene Reader en la suscripción de producción para ver métricas, nada más.
• Paso 4: Todas las aplicaciones y servicios usan identidades administradas. Sin credenciales hardcodeadas, sin archivos .env con secretos de Azure en el repositorio.
• Paso 5: Configurá auditoría en Azure Monitor y revisá los logs de acceso cada semana las primeras dos o tres semanas, después mensualmente.

Dicho esto, el orden importa. No arranques asignando roles antes de tener la jerarquía definida. Los permisos mal asignados en niveles altos son difíciles de encontrar después.

Errores comunes que destruyen la seguridad en Azure

Over-provisioning. El clásico: dar Owner porque es más fácil que pensar qué rol exacto necesita alguien. Después ese usuario tiene permisos para modificar políticas de acceso, crear recursos en cualquier región, y básicamente hacer lo que quiera. El principio de privilegios mínimos no es burocracia, es lo que evita que un error humano se convierta en incidente de seguridad.

No usar Management Groups. Sin Management Groups, cada suscripción es un silo. Las políticas de seguridad hay que aplicarlas en cada una por separado, la consistencia es imposible a escala, y la auditoría se vuelve un desastre. A diez suscripciones el problema es manejable con mucho esfuerzo manual; a cincuenta, es inmanejable.

Acceso permanente a roles privilegiados. Si tu cuenta de administrador de seguridad tiene el rol activo las 24 horas, los 7 días, esa cuenta es un objetivo permanente. PIM existe exactamente para esto: el acceso solo cuando se necesita, con aprobación y log de quién lo solicitó y por qué. Cubrimos ese tema en detalle en gestionar aplicaciones en múltiples regiones.

Ignorar los accesos de invitados y externos. Los proveedores, consultores y partners que accedieron a tu tenant de Azure para un proyecto hace nueve meses y siguen ahí con acceso de Contributor porque nadie los dio de baja. Según Compass Security, las identidades externas no revisadas son uno de los cinco vectores de ataque más frecuentes en entornos Azure.

No auditar los service principals. Las aplicaciones registradas en Entra ID acumulan permisos a lo largo del tiempo. Una app que empezó con permisos mínimos fue escalando a medida que crecieron sus funcionalidades, y nadie revisó si esos permisos siguen siendo necesarios. Revisá los service principals con la misma frecuencia que revisás los usuarios.

Preguntas Frecuentes

¿Qué son los Azure Management Groups y para qué sirven?

Los Management Groups son contenedores que agrupan múltiples suscripciones de Azure bajo una jerarquía organizacional. Permiten aplicar políticas de seguridad, compliance y acceso una sola vez en el nivel de grupo, y esas políticas se heredan automáticamente a todas las suscripciones, grupos de recursos y recursos dentro de él. Son especialmente útiles cuando una organización tiene decenas o cientos de suscripciones y necesita consistencia sin gestión manual de cada una.

¿Cómo funciona el control de acceso basado en rol en Azure?

RBAC en Azure asocia una identidad (usuario, grupo, aplicación o servicio) con un rol (Reader, Contributor, Owner, u otro personalizado) en un ámbito específico (Management Group, suscripción, grupo de recursos, o recurso individual). Los permisos se heredan hacia abajo pero no hacia arriba. Si asignás Contributor a un grupo de recursos, esa persona puede crear recursos dentro de ese grupo pero no puede tocar otros grupos de recursos en la misma suscripción.

¿Cuál es la diferencia entre identidades administradas e identidades de usuario en Azure?

Las identidades administradas son para aplicaciones y servicios, no para personas. Azure crea y rota las credenciales automáticamente, sin que el equipo tenga que gestionar contraseñas o secretos. Las identidades de usuario son para personas que interactúan con el portal o las APIs de Azure, y requieren MFA (obligatoria desde octubre de 2025). Para cualquier escenario donde una app necesita acceder a otro servicio de Azure, la identidad administrada es siempre la opción correcta.

¿Por qué no debo compartir una única contraseña en Azure?

Con una credencial compartida, perdés auditoría (no sabés quién hizo qué), perdés capacidad de revocar acceso individual (cambiar la contraseña afecta a todos), y si esa credencial se filtra, todos los recursos quedan expuestos sin posibilidad de contención parcial. Además, Azure no puede aplicar políticas de acceso condicional ni MFA si todos comparten el mismo usuario. RBAC con cuentas individuales resuelve todos estos problemas a la vez.

¿Cuáles son los errores más comunes al configurar acceso en Azure?

El más frecuente es el over-provisioning: dar el rol Owner o Contributor a toda una suscripción cuando la persona solo necesita acceso a un grupo de recursos. El segundo es no usar Management Groups en ambientes con múltiples suscripciones, lo que genera inconsistencias de políticas. El tercero es no revisar los accesos de usuarios invitados externos, que suelen quedar activos mucho después de que terminó el proyecto para el que fueron invitados.

Conclusión

La gestión de identidades en Azure no es una configuración que se hace una vez y se olvida. Es un proceso continuo de diseñar bien la jerarquía desde el inicio, asignar el mínimo acceso necesario, usar identidades administradas para todo lo que no sea una persona, y revisar periódicamente quién tiene acceso a qué.

El caso de Richard Inc. parece exagerado, pero versiones más sutiles del mismo problema aparecen en equipos de todos los tamaños: el pasante que tiene más permisos de los que debería, el proveedor externo que sigue con acceso de Contributor tres meses después de entregar el proyecto, la app que tiene Owner porque nadie supo qué rol exacto necesitaba.

Si tu empresa corre en Azure y nunca revisó la estructura de acceso, empezá por los Management Groups y la asignación de roles. Si tenés infraestructura de hosting y nube en Argentina y buscás un proveedor con soporte local, donweb.com tiene opciones de cloud para proyectos de la región. El overhead de configurar IAM correctamente desde el principio es mínimo comparado con el costo de tener que reconstruir una base de datos de producción un viernes a las cinco de la tarde.

Fuentes

• Dev.to – Azure Architecture e Identity Access Management (caso Richard Inc.)
• Microsoft Learn – Introducción a Azure Management Groups
• Microsoft Learn – Control de acceso basado en rol de Azure (RBAC)
• Microsoft Learn – Mejores prácticas de seguridad de identidades en Azure
• Compass Security – 5 riesgos de seguridad en Azure IAM y Entra ID