¿Por qué usar Service Principals en Entra ID y no Contraseñas de Aplicación?

¿Por qué usar Service Principals en Entra ID y no Contraseñas de Aplicación?

7/03/2025

Las contraseñas de aplicación (app passwords) en Microsoft Entra ID son credenciales estáticas y de larga vigencia que se asocian directamente con la cuenta de un usuario. Esto implica riesgos altos: no soportan expiración forzada, no pueden ser rotadas automáticamente, y si se filtran, un atacante mantiene acceso indefinido. En cambio, los Service Principals ofrecen identidades separadas de usuario, con control granular de permisos (por ejemplo, a nivel de rol y recurso), permiten el uso de certificados o secretos con caducidad configurada, y se integran con prácticas de seguridad modernas (rotación de credenciales, auditoría y MFA para acceso privilegiado). Por todo esto, los Service Principals son la opción recomendada para escenarios de autenticación de aplicaciones.

1. Riesgos de usar contraseñas de aplicación

1.1 Naturaleza estática y de larga duración

Las app passwords son cadenas estáticas asociadas al usuario y no están pensadas para expirar o rotarse automáticamente. Si un atacante las obtiene, puede acceder a recursos mientras sigan vigentes. 

1.2 Falta de control de acceso granular

Estas contraseñas heredan todos los permisos del usuario propietario, lo que viola el principio de menor privilegio. Un proceso o script que use esa contraseña tendrá acceso excesivo. 

1.3 Dificultad para auditar y rotar

No hay mecanismos nativos en Entra ID para forzar la rotación periódica de app passwords ni para monitorear su uso diferenciado: están incluidas en los registros como “inicio de sesión del usuario”, sin distinguir la fuente. 

2. Ventajas de Service Principals

2.1 Identidad separada y aislada

Un Service Principal es la representación local de una aplicación en tu tenant, con su propio ObjectID y ApplicationID  . Esto permite aislar completamente los accesos de la aplicación de los del usuario humano.

2.2 Control granular de permisos

Puedes asignar roles específicos (RBAC) al Service Principal, limitando el alcance a recursos concretos (por ejemplo, solo lectura en un Storage Account). Así garantizas mínimo privilegio. 

2.3 Credenciales manejables y rotables

Los Service Principals pueden usar certificados (más seguros) o secretos con fecha de expiración configurable. Además, su rotación se puede automatizar en pipelines CI/CD. 

2.4 Mejor auditoría y monitoreo

Las operaciones realizadas con Service Principals quedan claramente identificadas en los logs de Microsoft Entra ID y Azure AD, facilitando la detección de anomalías y cumplimiento.