Rotación de Secretos de App Registration en Entra: Detección y Remediación

Qué es la higiene de credenciales de App Registration en Entra

Los secretos de rotación de credenciales de Entra App Registration son los client secrets, certificados y credenciales federadas que sus aplicaciones usan para autenticarse, y son uno de los rincones más pasados por alto de la superficie de ataque de identidad en un tenant. Cada App Registration que se autentica como sí misma, ya sea un daemon, un pipeline CI/CD o una integración de API, necesita una credencial para demostrar que es quien dice ser. Esa credencial es un passwordCredential (un client secret), un keyCredential (una clave pública de certificado cargada), o una credencial federada (una relación de confianza con un proveedor de identidad externo, sin ningún material secreto). Olvidar rotar cualquiera de estas es cómo una credencial rutinaria se convierte silenciosamente en una puerta trasera permanente, sin solicitud de MFA y a menudo sin ningún propietario vigilándola.

Esto importa porque la credencial de una App Registration otorga todo lo que los permisos de esa aplicación permiten: scopes de Microsoft Graph, permisos delegados o de aplicación, a veces acceso de lectura/escritura a nivel de todo el directorio. La guía de Microsoft es explícita: los client secrets son menos seguros que las credenciales por certificado o federadas y no deberían usarse en producción; con la federación de identidad de carga de trabajo, se elimina la carga de mantenimiento de gestionar credenciales manualmente y el riesgo de filtrar secretos o dejar caducar certificados. Un tenant que nunca inventaría las credenciales de sus aplicaciones no tiene forma de distinguir un secreto rutinario de uno que ha sobrevivido silenciosamente a todos los administradores que sabían para qué servía.

Este es un ángulo distinto al de las App Registrations con exceso de privilegios (tratado en Azure App Registrations: Over-Privileged Tenant Apps) — ese artículo trata sobre qué puede hacer una aplicación; este trata sobre cuánto tiempo siguen siendo válidas sus llaves de la puerta, y sobre si alguien está vigilando la cerradura. Un secreto de larga duración filtrado se explota igual que un token OAuth suplantado en OAuth Consent Phishing: cómo las aplicaciones maliciosas evitan el robo de contraseñas: en silencio, con los permisos propios de la aplicación, hasta que alguien nota que la actividad no coincide con el comportamiento normal de la aplicación.

Cómo funciona: secretos, certificados y por qué se salta la rotación

Cada objeto application y servicePrincipal en Microsoft Graph expone dos colecciones de credenciales:

• passwordCredentials — client secrets, cada uno con un keyId, un startDateTime y un endDateTime. Según la referencia del recurso passwordCredential, endDateTime es la marca de tiempo ISO 8601 UTC tras la cual el secreto deja de funcionar.
• keyCredentials — claves públicas de certificados cargadas, usadas para la autenticación basada en certificado (CBA), cada una con su propia caducidad.

Los client secrets creados desde el portal tienen un límite máximo de vida de 24 meses, y Microsoft recomienda explícitamente fijar una caducidad inferior a 12 meses en lugar de usar por defecto el máximo. En la práctica, los equipos suelen hacer lo contrario: eligen la caducidad más larga ofrecida para que nada se rompa de forma inesperada, y luego dejan la aplicación en paz. Dos años después, la persona que la configuró ya se ha ido, el secreto sigue siendo válido, y nadie recuerda de qué pipeline o script depende.

Un problema relacionado pero distinto es la proliferación de credenciales (credential sprawl): una aplicación que va acumulando varios secretos activos con el tiempo porque la rotación se hizo añadiendo un secreto nuevo en lugar de reemplazar el antiguo. Cada secreto activo adicional es una vía de entrada más que hay que rastrear, revocar y auditar — y los secretos antiguos de una rotación que "funcionó" prácticamente nunca se limpian. Es habitual encontrar App Registrations de varios años de antigüedad con tres o cuatro secretos activos, cada uno creado por un administrador distinto durante un incidente distinto, ninguno de ellos revocado jamás.

La autenticación basada en certificado es, en general, el tipo de credencial más seguro de los dos — la clave privada de un certificado nunca tiene que transmitirse ni pegarse en un archivo de configuración como sí ocurre con el valor de un secreto. Pero un certificado CBA activo sigue siendo una credencial viva, con una caducidad y un radio de impacto si la clave privada se ve comprometida, y Microsoft recomienda que los certificados se emitan desde una CA de confianza, con una política que exija emisores de confianza en lugar de certificados autofirmados con confianza indefinida.

Detectar secretos de rotación de Entra App Registration caducados o dispersos

Empiece por un inventario, no por una comprobación puntual — no puede rotar lo que no ha contado.

Inventariar cada credencial vía Microsoft Graph

Consulte directamente las credenciales de cada aplicación:

GET https://graph.microsoft.com/v1.0/applications
    ?$select=id,displayName,passwordCredentials,keyCredentials

La respuesta incluye endDateTime para cada secreto y certificado, lo que permite marcar cualquiera que ya haya caducado o esté a punto de hacerlo.

Automatizarlo en todo el tenant con PowerShell

El SDK de Microsoft Graph PowerShell facilita ejecutar esto en todo el tenant en lugar de aplicación por aplicación:

# Requires: Connect-MgGraph -Scopes "Application.Read.All"
Get-MgApplication -All -Property Id, DisplayName, PasswordCredentials, KeyCredentials |
  ForEach-Object {
    $app = $_
    $app.PasswordCredentials | ForEach-Object {
      [PSCustomObject]@{
        App        = $app.DisplayName
        Type       = "Secret"
        KeyId      = $_.KeyId
        Expires    = $_.EndDateTime
        DaysLeft   = ($_.EndDateTime - (Get-Date)).Days
      }
    }
    $app.KeyCredentials | ForEach-Object {
      [PSCustomObject]@{
        App        = $app.DisplayName
        Type       = "Certificate"
        KeyId      = $_.KeyId
        Expires    = $_.EndDateTime
        DaysLeft   = ($_.EndDateTime - (Get-Date)).Days
      }
    }
  } | Sort-Object DaysLeft

Leer las señales que importan

A partir de ese inventario, relacione los hallazgos con un riesgo concreto:

Confirmar el uso real en los logs de inicio de sesión

Verifique cómo se usan realmente las credenciales, no solo qué existe, mediante los logs de inicio de sesión de service principals. Cada evento de inicio de sesión lleva un campo ClientCredentialType: un valor client secret indica autenticación basada en contraseña, mientras que la autenticación por certificado aparece como client assertion, junto con un ClientCredentialKeyID que puede cotejar con el keyId concreto en la lista de credenciales de la aplicación. Ese cruce le dice qué credencial está realmente viva en producción frente a cuáles son peso muerto que nadie eliminó — una distinción que el inventario de credenciales por sí solo no puede darle. Si una credencial aparece marcada en una detección de riesgo en lugar de en un inicio de sesión rutinario, trátela como recomienda Azure Identity Protection: Políticas de Riesgo para cualquier otra señal de credencial filtrada.

Rastrear los cambios de credenciales en el log de auditoría

Para el seguimiento histórico de cambios, filtre el log de auditoría de Entra por Categoría = ApplicationManagement: las adiciones y eliminaciones de credenciales de aplicaciones y service principals se registran como cambios de propiedad modificada en el recurso objetivo, revisables por aplicación — vea la referencia de actividades del log de auditoría de Microsoft Entra. Expórtelos a un SIEM o a un workspace de Log Analytics si necesita una retención mayor que la ventana por defecto del centro de administración, según la descripción general de los logs de auditoría.

Remediación: rotar, restringir y abandonar los secretos

Inventariar primero, rotar después

Ejecute la consulta de Graph anterior en todas las aplicaciones antes de tocar nada — necesita saber qué secretos están realmente referenciados por una carga de trabajo en ejecución antes de revocarlos. Rotar o eliminar un secreto que todavía se usa rompe la carga de trabajo que depende de él, así que este paso no es opcional.

Reemplazar, no añadir

Al rotar, cree el nuevo secreto o certificado, actualice la carga de trabajo consumidora, verifique que se autentica correctamente, y entonces elimine la credencial antigua. Añadir una nueva y dejar la antigua "por si acaso" es exactamente cómo se origina la proliferación de múltiples secretos.

Pasar a certificados o credenciales federadas

Microsoft recomienda certificados en lugar de client secrets antes de que una aplicación llegue a producción, y credenciales federadas donde la plataforma de la carga de trabajo lo permita — eliminando el problema de rotación de raíz en lugar de gestionarlo mejor.

Aplicar el estándar en todo el tenant

En lugar de confiar en que cada propietario de aplicación se autorregule, imponga estándares de credenciales con una Application Management Policy. Las políticas se configuran mediante Microsoft Graph o Graph PowerShell (sin interfaz en el portal) y pueden limitar la vida útil de los certificados y bloquear directamente las nuevas credenciales de contraseña:

# Requires: Connect-MgGraph -Scopes "Policy.ReadWrite.ApplicationConfiguration"
$policy = @{
  displayName    = "Enforce credential standards"
  isEnabled      = $true
  applications   = @{
    keyCredentials = @(
      @{
        restrictionType = "asymmetricKeyLifetime"
        maxLifetime     = "P180D"
        state           = "enforced"
      }
    )
    passwordCredentials = @(
      @{
        restrictionType = "passwordAddition"
        state           = "enforced"
      }
    )
  }
}
New-MgPolicyAppManagementPolicy -BodyParameter $policy

Consulte el tutorial sobre cómo aplicar estándares de secretos y certificados y la configuración de restricciones de la política de gestión de aplicaciones para ver la lista completa de tipos de restricción disponibles, incluyendo cómo limitar el alcance de una política a aplicaciones concretas o a todo el tenant.

Asignar un propietario y revisar con una cadencia fija

Una credencial que nadie posee es una credencial que nadie rota ni revoca cuando debería. Combine la propiedad con una revisión recurrente de la consulta de inventario anterior — como mínimo mensual para las aplicaciones con permisos privilegiados de Graph.

Verificar la confianza del certificado, no solo su caducidad

Para CBA específicamente, confirme que los certificados activos provienen de una CA de confianza según sus mejores prácticas de seguridad para las propiedades de App Registration, y no de un certificado autofirmado que nadie recuerda haber emitido.

Lectura relacionada: Certificado de firma SAML Entra expirado: por qué falla el inicio de sesión federado cubre lo que ocurre cuando se deja caducar sin supervisión un tipo distinto de certificado — la firma SAML —, y Cómo auditar la seguridad de Microsoft Entra ID (Azure AD): guía práctica recorre la revisión de permisos de aplicaciones como parte de una auditoría de tenant más amplia.

Cómo lo detecta EtcSec

La auditoría de Entra de EtcSec verifica las credenciales de aplicaciones y service principals directamente contra Microsoft Graph en cada escaneo. APP_NO_CREDENTIAL_ROTATION marca las aplicaciones cuyas credenciales han quedado obsoletas sin actividad de reemplazo; APP_SECRET_LONG_EXPIRY y APP_SECRET_EXPIRED detectan secretos configurados con una vida útil excesiva o que ya han superado su endDateTime; APP_MULTIPLE_SECRETS revela la proliferación de credenciales por rotación aditiva; SP_STALE_CREDENTIAL extiende la misma comprobación a los service principals; y CBA_CERTIFICATES_ACTIVE inventaría cada aplicación que actualmente depende de la autenticación basada en certificado, para que pueda verificar la confianza y la caducidad de forma deliberada en lugar de descubrirlo cuando falle.