Azure Managed Identities suele “arreglar” el problema de credenciales embebidas y secretos rotando tarde. El problema es que, cuando pasas de un par de recursos en un sandbox a docenas de workloads en producción, empiezan a aparecer errores operativos y de seguridad que no son obvios: la identidad correcta no se usa, los permisos se inflan para “desbloquear” despliegues, o se confunden los modelos system-assigned y user-assigned hasta perder trazabilidad.
Lo siguiente está escrito desde la perspectiva de operación real: incidentes de acceso a Key Vault, despliegues que rompen por cambios “inocentes”, y auditorías que no aceptan “pero es managed” como argumento. El objetivo es que puedas detectar el patrón antes de que te explote en producción.
Qué salió mal: la aplicación tenía identidad, pero no era la que creíamos
Un error típico es asumir que “si el recurso tiene una Managed Identity habilitada, ya está”. En producción, el fallo se da cuando el workload termina autenticando con una identidad distinta a la esperada (o con ninguna), y el síntoma se manifiesta como un 403 Forbidden contra Key Vault, Storage o un endpoint interno. El equipo suele reaccionar aumentando permisos “temporalmente” hasta que funcione, y ahí empieza el deterioro.
Esto ocurre mucho en App Service, Function Apps, VMSS o AKS con add-ons: entre la configuración de la plataforma, variables de entorno y SDKs, es fácil que el runtime elija el camino “equivocado” (por ejemplo, usar una identidad system-assigned cuando se pretendía una user-assigned, o viceversa). En empresas con varios equipos, además, el ownership se difumina: alguien habilita una identidad en el recurso, otro asigna roles en un scope incorrecto y un tercero despliega código que asume otra cosa.
Consecuencia real: no solo hay caída del servicio. Muchas organizaciones solucionan el incidente asignando roles amplios en el grupo de recursos “para salir del paso”. Eso queda olvidado y se convierte en un vector lateral: la misma identidad termina con acceso a blobs, colas o secretos que no estaban en el modelo de amenaza original.
Confundir system-assigned y user-assigned: el origen de la deriva y la falta de trazabilidad
La distinción parece académica hasta que haces rotación de recursos, migraciones o blue/green. La system-assigned vive y muere con el recurso; la user-assigned es un objeto reutilizable que puede adjuntarse a múltiples recursos. En producción, el error común es elegir un tipo por “comodidad” y acabar con problemas de ciclo de vida o de trazabilidad.
Con system-assigned, el riesgo operativo típico es el reciclado: recreas un App Service o una Function (o automatizas un reemplazo) y su principal cambia. Si tus asignaciones RBAC o tus políticas en Key Vault estaban amarradas al principal anterior, el servicio vuelve a levantarse pero se queda sin acceso. El incidente se ve como “intermitente” porque depende de despliegues, slots o recreaciones.
Con user-assigned, el riesgo de seguridad suele ser el contrario: reutilización excesiva. Se crea una identidad “común” para varios workloads para reducir trabajo, y de forma silenciosa se mezclan privilegios de aplicaciones distintas. Cuando llega una auditoría o un incidente, no puedes responder con claridad qué servicio usó qué permisos, porque múltiples recursos comparten el mismo principal.
- Señal temprana de system-assigned mal operada: despliegues que “funcionan” pero rompen acceso a secretos después de recrear recursos. En la práctica, se ve en pipelines que destruyen/crean infraestructura o en entornos con autoscaling agresivo.
Si detectas este patrón, el problema no es el SDK: es el acoplamiento entre identidad y ciclo de vida del recurso. La corrección suele requerir revisar cómo se asignan permisos (y si se está asumiendo que el principal es estable).
- Señal temprana de user-assigned sobre-reutilizada: un único principal aparece en demasiados recursos y scopes. A nivel de operaciones, empiezas a ver “cambios” en permisos que afectan a varias apps a la vez, porque comparten identidad.
En ese caso, el impacto real es que pierdes el aislamiento entre servicios. Un fallo de configuración o una brecha en una aplicación puede traducirse en acceso indebido a dependencias de otras aplicaciones que nunca deberían estar relacionadas.
Permisos de más por urgencia: cuando Managed Identity se convierte en “root sin querer”
El error más caro no es técnico, es cultural: ante un 403, se asigna Contributor (o roles amplios) al scope del grupo de recursos o incluso la suscripción “para desbloquear”. En el momento parece razonable: hay presión, el negocio está esperando, el pipeline está rojo. En semanas, nadie recuerda por qué esa identidad tiene permisos tan amplios.
En Azure, el daño se amplifica porque RBAC y los data-plane permissions pueden coexistir según el servicio. Por ejemplo, para Key Vault puedes terminar combinando RBAC amplio a nivel de recurso con permisos de secretos que no están ajustados a lo mínimo. El resultado práctico es que una identidad que solo debía leer un secreto termina pudiendo listar, leer otros secretos o incluso modificar configuraciones dependiendo del rol asignado.
- Patrón que se repite: “poner Contributor y luego acotamos”. En organizaciones grandes, ese “luego” rara vez llega porque no hay dueño claro del recorte y porque el recorte requiere pruebas de regresión.
La consecuencia empresarial no es solo riesgo teórico. Cuando ocurre un incidente, el análisis forense se complica: si el principal tenía permisos amplios, es difícil demostrar qué estaba permitido vs qué fue abuso. Y si hay requisitos de compliance, el hallazgo típico es “privilegios excesivos sin justificación”, que obliga a remediaciones con plazos y reportes.
Cómo hacerlo en la práctica: validar identidad efectiva y ajustar permisos sin romper producción
La forma de evitar los errores anteriores no es “usar Managed Identities mejor” en abstracto, sino introducir verificaciones explícitas en despliegues y operación. La clave es comprobar qué identidad se usa realmente y amarrar permisos a scopes mínimos, con cambios revisables.
Verificar la identidad efectiva (operación): cuando tengas un recurso con Managed Identity, valida el principalId que está autenticando. En incidentes reales, el error es mirar la identidad “configurada” y no la identidad “utilizada”. Esto se vuelve crítico si alternas system-assigned y user-assigned, o si el servicio puede elegir por defecto.
- Acción concreta: listar identidades en el recurso y capturar el principalId esperado como salida del despliegue (por ejemplo, en tu pipeline). Ese identificador es el que debe aparecer en las asignaciones RBAC y en tus revisiones de acceso.
En la práctica, esto reduce el “fantasma” del 403: cuando el incidente aparece, puedes comparar rápidamente “principal usado” vs “principal con permisos” y dejar de reaccionar con permisos excesivos.
- Acción concreta: revisar asignaciones RBAC por identidad y scope antes de promover a producción. Si encuentras roles amplios en un scope mayor del necesario (suscripción o RG), trátalo como defecto de seguridad, no como deuda técnica.
Esto exige disciplina: el recorte de permisos debe ir acompañado de pruebas de acceso (por ejemplo, lectura de un secreto concreto, acceso a un blob concreto, publicación en una cola concreta). Si no hay prueba, el equipo vuelve al rol amplio por miedo a romper.
Evitar el error de confusión entre tipos: documenta (en el repositorio de IaC) cuándo usar system-assigned y cuándo user-assigned, y hazlo verificable. Un criterio operativo sencillo es: si el recurso se recrea con frecuencia (o por diseño) y necesitas estabilidad del principal, la user-assigned suele ser más segura operativamente; si quieres acoplar identidad a un único recurso y reducir riesgo de reutilización, system-assigned suele ser más limpia. El problema es mezclar sin criterio y sin controles.
Recomendaciones para entornos corporativos
Los fallos más comunes con Azure Managed Identities en producción no son “de Azure”: son de asignación, de ciclo de vida y de permisos. Cuando una app “tiene identidad” pero no la correcta, el síntoma se convierte en escalado de permisos. Cuando se confunden system-assigned y user-assigned, aparece deriva: o se rompen accesos tras recreaciones o se reutiliza demasiado un principal y se pierde aislamiento.
Si tienes que quedarte con pocas acciones: valida siempre el principalId efectivo, evita roles amplios para apagar incendios y define una regla corporativa clara para elegir el tipo de identidad. Y, sobre todo, convierte esas reglas en controles repetibles en despliegues y revisiones de acceso, porque en producción lo que no se verifica termina degradándose.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.