Identidades administradas de Azure asignadas por el sistema frente a las asignadas por el usuario: ¿cuál deberías elegir?

By Mirko Peters · 2026-10-26

Compara las identidades administradas de Azure asignadas por el sistema y por el usuario. Descubre qué tipo de identidad elegir para reducir la carga administrativa y escalar de forma segura.

Automatically translated with AI from the original post. Read the English original

Elegir entre identidades administradas asignadas por el sistema y asignadas por el usuario en Azure es una de las decisiones arquitectónicas más críticas para la seguridad en la nube y la carga administrativa. Mientras que las identidades asignadas por el sistema están ligadas directamente al ciclo de vida de un único recurso de Azure, las identidades asignadas por el usuario funcionan como entidades independientes que pueden compartirse entre varios recursos, lo que reduce drásticamente las asignaciones de roles redundantes y evita los cuellos de botella por límites de tokens en entornos automatizados.

Puntos clave

• Las identidades asignadas por el sistema se crean, gestionan y eliminan automáticamente junto con el recurso de Azure al que pertenecen.
• Las identidades asignadas por el usuario existen de forma independiente como recursos de Azure autónomos, por lo que pueden compartirse entre varias máquinas virtuales, aplicaciones y funciones.
• Microsoft recomienda las identidades asignadas por el usuario para la mayoría de los escenarios con varios recursos, con el fin de minimizar el mantenimiento y las asignaciones de roles complejas.
• Usar identidades asignadas por el sistema en entornos de prueba de escalado rápido o de corta duración puede hacer que las identidades se acumulen y provocar la activación de los límites de frecuencia de Azure.
• Un único recurso de Azure puede alojar una identidad asignada por el sistema para registros aislados y una o más identidades asignadas por el usuario para cargas de trabajo compartidas.

Comprender las diferencias principales

Cuando empiezas a diseñar aplicaciones en la nube seguras sin secretos codificados ni cadenas de conexión, debes decidir cómo se autenticarán tus cargas de trabajo en Microsoft Entra ID. Azure ofrece dos variantes distintas de identidades administradas: asignadas por el sistema y asignadas por el usuario. Entender cómo funcionan internamente te ahorrará incontables horas de resolución de problemas y mantenimiento administrativo a tu equipo de ingeniería.

Cómo funcionan las identidades asignadas por el sistema

Una identidad administrada asignada por el sistema se activa directamente dentro de un recurso de Azure específico, como una máquina virtual de Azure, un App Service o una aplicación de funciones. Piénsalo como si naciera con el recurso y muriera con él. Cuando habilitas una identidad asignada por el sistema en una máquina virtual, Azure crea en Microsoft Entra ID una identidad que lleva exactamente el nombre de ese recurso.

La principal ventaja de este enfoque es la simplicidad y el acoplamiento del ciclo de vida. Como la identidad está vinculada al recurso, nunca tendrás que preocuparte por identidades huérfanas que permanezcan en tu directorio después de dar de baja una máquina virtual. Si eliminas el recurso, Azure elimina automáticamente la identidad por ti. Sin embargo, este acoplamiento estricto crea limitaciones arquitectónicas si tienes varios recursos que necesitan exactamente los mismos permisos de acceso.

Cómo funcionan las identidades asignadas por el usuario

Una identidad administrada asignada por el usuario, en cambio, se crea primero como un recurso de Azure independiente. Le asignas un nombre personalizado, la gestionas de forma independiente dentro de tus grupos de recursos y la asocias explícitamente a uno o más servicios de Azure que necesiten acceso. Como no está ligada al ciclo de vida de ninguna máquina virtual o App Service concreto, persiste incluso si se eliminan todos los recursos asociados a ella.

Esta naturaleza independiente transforma la forma en que los arquitectos de la nube gestionan el acceso a escala. En lugar de tratar la autenticación como una relación uno a uno entre un único servidor y una base de datos, las identidades asignadas por el usuario permiten construir modelos de autenticación muchos a uno, en los que grupos de microservicios comparten un único contexto de seguridad bien gobernado.

Sobrecarga administrativa y asignaciones de roles

Las diferencias prácticas entre estos dos tipos de identidad se hacen dolorosamente evidentes cuando observas la gestión del control de acceso basado en roles (RBAC) en entornos grandes. Cada vez que concedes a una identidad acceso a una cuenta de almacenamiento, un almacén de claves o una base de datos, tienes que crear una asignación de rol de Azure.

Imagina un escenario empresarial habitual: tienes cuatro máquinas virtuales que necesitan leer datos de dos cuentas de Azure Storage distintas. Si dependes exclusivamente de identidades asignadas por el sistema, cada máquina virtual necesita su propia identidad dedicada. Para conceder el acceso, tienes que configurar ocho asignaciones de rol independientes: una por cada máquina en cada cuenta de almacenamiento. Si escalas a veinte máquinas virtuales, el número de asignaciones de rol crece de forma exponencial, lo que se convierte en una auténtica pesadilla administrativa.

En cambio, si esas mismas cuatro máquinas virtuales comparten una única identidad administrada asignada por el usuario, solo necesitas crear dos asignaciones de rol en total. Obtienes exactamente el mismo control de acceso granular con una fracción del esfuerzo de gestión. Cuando los miembros del equipo se marchan o la infraestructura se reconstruye, mantener un directorio limpio resulta mucho más sencillo.

Riesgos de arquitectura y casos límite

Aunque las identidades asignadas por el usuario suelen ser más eficientes, elegir el tipo incorrecto puede introducir fricciones operativas ocultas. Un riesgo importante afecta a los recursos de cómputo de vida corta o a los entornos con escalado automático.

Si aprovisionas y eliminas entornos de desarrollo, pruebas o contenedores de forma rápida a lo largo del día usando identidades asignadas por el sistema, esas identidades se acumularán en Microsoft Entra ID antes de que se ejecuten las rutinas de limpieza. Con el tiempo, las organizaciones pueden alcanzar los límites de frecuencia del directorio de Azure, lo que provoca que la plataforma rechace por completo las nuevas solicitudes de creación de recursos. Compartir una identidad asignada por el usuario entre estas cargas de trabajo efímeras evita por completo esta trampa.

Por el contrario, las identidades asignadas por el sistema brillan en dos escenarios concretos:

• Auditoría y no repudio: si tus registros de seguridad deben demostrar de forma concluyente qué máquina virtual exacta realizó una acción determinada, las identidades asignadas por el sistema aportan esa atribución a nivel micro, porque cada recurso mantiene su propio objeto de directorio único.
• Limpieza estricta del ciclo de vida: si los requisitos de cumplimiento exigen que todos los permisos de acceso desaparezcan en el instante exacto en que se termina un recurso, las identidades asignadas por el sistema lo gestionan automáticamente, sin intervención humana.

Recuerda que no estás obligado a elegir una opción binaria absoluta. Un único recurso de Azure puede tener tanto una identidad asignada por el sistema para operaciones privadas y sensibles como una o más identidades asignadas por el usuario para flujos de trabajo corporativos compartidos.

Conclusión

La gestión de identidades en la nube de Microsoft exige equilibrar la eficiencia operativa con límites de seguridad estrictos. Si comprendes las diferencias operativas entre las identidades asignadas por el sistema y las asignadas por el usuario, podrás diseñar arquitecturas robustas y escalables que eliminen los secretos codificados sin generar una sobrecarga administrativa.

Para profundizar en cómo se emiten los tokens, cómo Azure Key Vault se integra sin contraseñas y los errores de seguridad comunes que conviene evitar, no olvides escuchar el episodio completo del podcast, con información de expertos y estrategias prácticas.

Preguntas frecuentes

¿Puede un único recurso de Azure usar tanto identidades administradas asignadas por el sistema como asignadas por el usuario?

Sí. Un recurso de Azure como una máquina virtual o Azure App Service puede tener una identidad asignada por el sistema y una o más identidades asignadas por el usuario habilitadas al mismo tiempo, lo que te permite combinar estrategias de autenticación dedicadas y compartidas.

¿Qué ocurre con una identidad asignada por el usuario cuando se elimina el recurso de Azure al que está asociada?

A diferencia de las identidades asignadas por el sistema, que se eliminan automáticamente cuando se borra su recurso principal, las identidades asignadas por el usuario persisten como objetos independientes en Azure hasta que un administrador las elimina explícitamente.

¿Por qué recomienda Microsoft las identidades asignadas por el usuario para la mayoría de los escenarios con varios recursos?

Microsoft recomienda las identidades asignadas por el usuario principalmente para reducir la sobrecarga administrativa y la proliferación de asignaciones de roles. Compartir una única identidad entre varios recursos de cómputo reduce drásticamente el número de asignaciones de RBAC que hay que crear y mantener.

¿Las identidades administradas tienen algún coste en Azure?

No, tanto las identidades administradas asignadas por el sistema como las asignadas por el usuario son funciones sin costo incluidas con Microsoft Entra ID para recursos de Azure, aunque es posible que se apliquen los costos habituales de los servicios de proceso o almacenamiento a los que accedas.