Identidades administradas frente a registros de aplicaciones en Azure: diferencias clave y buenas prácticas

By Mirko Peters · 2026-04-28

Si hoy en día estás creando o protegiendo algo serio en Azure, entender las identidades administradas y los registros de aplicaciones no es opcional: es lo mínimo imprescindible.

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

Si hoy en día estás creando o protegiendo algo serio en Azure, entender las identidades administradas y los registros de aplicaciones no es opcional; es lo mínimo imprescindible. Ambos desempeñan un papel fundamental en la gestión de identidades y accesos de tus aplicaciones, automatizaciones y servicios. Pero si confundes qué modelo encaja en cada caso, acabarás con dolores de cabeza innecesarios, brechas de seguridad o demasiada gestión de secretos.

Esta guía explica qué son las identidades administradas y los registros de aplicaciones, cómo se integran con Entra ID (antes Azure AD) y por qué elegir el enfoque adecuado es importante para tu postura de seguridad y tus operaciones diarias. Encontrarás definiciones directas, escenarios prácticos, consejos para migrar y eliminar secretos, y recomendaciones concretas para la solución de problemas y la gobernanza. El objetivo: ayudarte a operar una nube de Microsoft más ajustada, segura y eficiente, especialmente a medida que los ataques crecen y las buenas prácticas de Entra ID evolucionan.

Descripción de las identidades administradas y los registros de aplicaciones

Empecemos por entender con claridad qué hacen realmente las identidades administradas y los registros de aplicaciones en Azure y Entra ID. Ambos son formas de que actores no humanos, como aplicaciones, scripts o automatizaciones, se autentiquen y accedan a recursos en la nube de Microsoft. Pero la forma en que lo hacen y los problemas cotidianos que resuelven (o que causan) son bastante distintos.

Las identidades administradas son la respuesta de Azure a la autenticación sin secretos. En lugar de gestionar contraseñas de aplicaciones y certificados, puedes dar a un recurso de Azure (una máquina virtual, App Service o Logic App, por ejemplo) su propia identidad en Entra ID. Azure se encarga automáticamente de esta identidad: se crea cuando se crea el recurso, se elimina si borras el recurso y, lo más importante, nunca te obliga a intercambiar secretos tradicionales. Hay dos tipos: asignadas por el sistema (una por recurso, muy restringida) y asignadas por el usuario (reutilizables en varios recursos).

Los registros de aplicaciones son el enfoque clásico. Registrar una aplicación en Entra ID crea un objeto de aplicación y te proporciona un identificador de cliente (client ID), con secretos o certificados opcionales para la autenticación. Si tu aplicación necesita iniciar sesión en servicios de Microsoft, acceder a la API de Graph o funcionar fuera de Azure (o en más de un recurso), probablemente usarás un registro de aplicación. Eso sí, tú eres responsable de gestionar sus secretos, su seguridad y su ciclo de vida, lo que conlleva algunas contrapartidas.

Elegir una herramienta no es solo una decisión técnica. Es un cálculo de riesgo de seguridad: los secretos son objetivos muy atractivos para los atacantes, mientras que las identidades administradas sin secretos eliminan clases enteras de vulnerabilidades. Si quieres ver por qué esto importa, consulta este análisis en profundidad sobre el abuso del consentimiento OAuth en Entra ID. Los atacantes saben cómo persistir en entornos que descuidan lo básico, así que acertar con la identidad es el primer paso.

Diferencias principales: ciclo de vida, seguridad e integración con Azure

Aquí es donde la teoría se encuentra con la realidad. Las identidades administradas y los registros de aplicaciones dan a las aplicaciones o scripts sus "etiquetas de identidad" digitales para acceder a los recursos. Pero la forma de obtener esa etiqueta, mantenerla y limpiarla después varía bastante.

Las identidades administradas son lo más parecido a "configurar y olvidar" que ofrece la nube. Crea un recurso de Azure, solicita una identidad administrada y listo: Azure crea la identidad por ti, la integra en Entra ID y mantiene sincronizada la parte de back-end. Si eliminas el recurso, la identidad también desaparece. No hay ninguna gestión de secretos, ni rotaciones de contraseñas, y los equipos de seguridad duermen mejor.

Los registros de aplicaciones requieren un esfuerzo mucho mayor. Tienes que crear manualmente el registro de la aplicación en Entra ID, hacer un seguimiento de su client ID y generar secretos o certificados para la autenticación. Con el tiempo, esos secretos caducan (o pueden filtrarse), y te corresponde a ti auditar qué aplicaciones los utilizan. Rotar secretos, controlar las credenciales que están por caducar y limpiar los registros huérfanos es un trabajo en sí mismo, por eso los equipos de seguridad siempre preguntan por la automatización del ciclo de vida.

En materia de seguridad, el contraste es claro: las identidades administradas usan autenticación sin secretos vinculada a los recursos de Azure, mientras que los registros de aplicaciones dependen de secretos estáticos o certificados. Por eso las identidades administradas son la opción preferida siempre que los secretos supongan un riesgo o cuando la automatización es prioritaria.

Estos contrastes de ciclo de vida y seguridad tienen grandes implicaciones para la automatización, el cumplimiento y la protección de los entornos en la nube. Si quieres ver cómo las directivas de gobernanza y los controles influyen en la proliferación de identidades y en la deriva de seguridad, echa un vistazo a esta guía sobre estrategia de gobernanza de Azure. Es una lectura imprescindible para cualquiera que sea responsable de entornos de Azure grandes y en crecimiento.

Entidades de servicio, roles de RBAC y permisos de Microsoft Graph

Ahora vamos a descorrer un poco el telón. Bajo el capó, tanto las identidades administradas como los registros de aplicaciones utilizan entidades de servicio en Entra ID. Piensa en una entidad de servicio como la identidad real y operativa que Entra ID conoce. Ya provenga de una identidad administrada o de un registro de aplicación, es este objeto el que recibe permisos y acceso en tu inquilino.

En el caso de los registros de aplicaciones, cuando registras una nueva aplicación, Entra crea una entidad de servicio correspondiente para cada inquilino al que la asignas. Esta es la identidad que usarás para asignar roles de RBAC de Azure, como Colaborador o Lector, y para conceder permisos de la API de Graph, ya sean delegados o de nivel de aplicación.

Las identidades administradas son ligeramente distintas, pero se basan en la misma estructura. Al habilitar una identidad administrada para un recurso de Azure, Entra crea una entidad de servicio de propósito especial que existe mientras exista el recurso y desaparece con él. Después asignas roles de RBAC (como Lector de Key Vault) directamente a esta identidad, y el recurso obtiene acceso mediante tokens de forma transparente: sin cambios en el código y sin secretos dando vueltas por ahí.

Conceder permisos es donde la teoría se pone a prueba. Ambos modelos usan RBAC de Azure para el acceso a nivel de recurso, pero la forma de conceder permisos de Graph es distinta. Los registros de aplicaciones permiten aprobar el acceso a la API de Graph mediante consentimiento explícito o aprobación del administrador. Las identidades administradas, en cambio, pueden recibir permisos de aplicación para Graph sin inicio de sesión interactivo, lo que las hace ideales para la automatización que necesita obtener datos de usuarios, auditar la seguridad o desencadenar flujos de trabajo.

Sin embargo, asignar acceso y supervisar el cumplimiento de estas identidades no es exactamente "configurar y olvidar". Una asignación estricta de roles de RBAC, auditorías periódicas y herramientas como Microsoft Defender for Cloud te ayudan a controlar quién hace qué, detectar configuraciones incorrectas y mantener la deriva al mínimo. ¿Quieres profundizar en la gobernanza de identidades? No te pierdas esta guía sobre gobernanza empresarial de Azure ni esta explicación sobre monitorización del cumplimiento en Microsoft Defender for Cloud, con consejos prácticos para la seguridad continua.

Elegir el modelo adecuado: escenarios, migración y gobernanza

Todo este contexto es importante, pero lo que la mayoría de los equipos quiere saber es: ¿cuándo usar identidades administradas frente a registros de aplicaciones? Y ¿cómo migrar o gobernar estas identidades para que nada se complique a medida que escalas?

Las identidades administradas brillan en cargas de trabajo que se ejecutan directamente dentro de Azure y solo necesitan acceso dentro del mismo inquilino. Piensa en máquinas virtuales que ejecutan scripts, App Services que se comunican con Key Vault o flujos de Logic Apps que consultan Microsoft Graph. La seguridad es mejor, la configuración es más rápida y hay menos gestión de secretos de la que preocuparse. Pero si ejecutas SaaS, soluciones multiinquilino o entornos híbridos (como aplicaciones locales que se conectan a API en la nube), los registros de aplicaciones siguen siendo la opción habitual por su flexibilidad y su mayor compatibilidad.

La migración de registros de aplicaciones a identidades administradas es un tema candente. El proceso comienza con una evaluación de preparación: ¿qué cargas de trabajo pueden realmente hacer el cambio y qué dependencias o limitaciones existen? En el caso de las aplicaciones ya creadas con registros de aplicaciones, conviene introducir los cambios de forma gradual, probar a fondo y tener planes de contingencia para evitar tiempos de inactividad o sorpresas de autenticación.

Los entornos híbridos y multinube exigen un poco de creatividad. A veces tienes que usar ambos modelos juntos, una práctica llamada identidad híbrida. El truco está en minimizar los secretos, limitar los permisos y documentar con claridad qué identidad hace qué. Y sí, las auditorías periódicas son imprescindibles para detectar identidades obsoletas o huérfanas que generan riesgos ocultos.

Las directivas de gobernanza sólidas dan coherencia a toda la estrategia. Usar Azure Policy, Privileged Identity Management y comprobaciones de cumplimiento periódicas te asegura que aplicas el principio de mínimo privilegio, detectas las desviaciones y te alineas con el modelo de confianza cero. Si quieres una visión realista sobre las cuentas de servicio frente a las verdaderas identidades de carga de trabajo (y por qué los enfoques tradicionales se quedan cortos), consulta este análisis sobre el riesgo de identidades no humanas y Microsoft Entra Workload Identities. ¿Quieres los fundamentos generales de gobernanza? El recurso sobre estrategia de gobernanza empresarial reúne numerosas buenas prácticas.