Monitorización de caducidad de credenciales en app registrations de Entra ID
Un tenant de Entra ID de cualquier tamaño acumula app registrations: integraciones, herramientas internas, conectores de proveedores, cosas que alguien configuró en 2019 y dejó ahí. Cada una tiene un secreto de cliente o un certificado, y cada uno de ellos tiene una fecha de caducidad. Cuando pasa, la integración se para. Unos días después llega un ticket, y la primera hora se va en averiguar quién es el responsable de la aplicación y para qué servía.
En este tenant había cerca de mil.
¿De quién es esto?
Entra ID no obliga a que una aplicación tenga responsable, y una buena parte de estas no tenía ninguno registrado, o tenía uno que se había ido hacía años. Un aviso sin destinatario no vale nada, así que la mitad del proyecto fue establecer un contacto responsable por aplicación, a partir del equipo que la usaba, el rastro de auditoría del directorio y quien la configuró, y escribirlo de vuelta en el registro para que el siguiente aviso lo encuentre sin que nadie pregunte.
Solo lo que se usa
El segundo filtro era igual de importante. Antes de avisar a nadie necesitaba saber qué se usaba de verdad. Un script de PowerShell lee todas las aplicaciones y todas las credenciales a través de Microsoft Graph y cruza cada credencial con cerca de mil registros de inicio de sesión de los últimos meses. Eso separa «en uso» de «olvidada», y la diferencia importa: una credencial a punto de caducar en una integración muerta es una tarea de limpieza, no una alarma.
Los avisos salen solo para credenciales con actividad de inicio de sesión reciente; un secreto olvidado junto a un certificado activo no dispara ninguna alarma. La misma pasada encontró unas 60 credenciales que ya habían caducado, algunas hacía años. Un script complementario las retira, con dry run por defecto y una copia de seguridad de cada objeto antes de tocar nada.
El aviso, y quién lo lee
Una Logic App escribe al responsable de la aplicación 30 y 7 días antes de la caducidad. Los responsables son en su mayoría product owners, no ingenieros. Si el correo dijera «su credencial keyId 3f2a… con el permiso Directory.Read.All y URI de redirección https://… caduca el día 14», lo reenviarían a IT y el ticket llegaría igual.
Por eso el aviso incluye un resumen breve y en lenguaje llano: qué parece hacer esta aplicación y qué deja de funcionar si la credencial caduca. Ese resumen lo genera Azure OpenAI a partir de los metadatos de configuración de la aplicación: nombres de permisos traducidos a algo legible, dominios de redirección, audiencia de inicio de sesión, si la credencial muestra uso reciente. Nunca se envían secretos ni tokens. Las banderas deterministas (si implica inicio de sesión de usuario, si expone una API) se calculan antes en PowerShell, y el modelo devuelve JSON estricto con una puntuación de confianza, de modo que los resúmenes con poca confianza pasan por una revisión humana antes de salir.
Resultado
Los responsables reciben ahora un mensaje sobre el que pueden actuar sin abrir un ticket: renovar, o confirmar que la aplicación puede retirarse. Las integraciones dejaron de romperse un lunes por la mañana, y la lista de limpieza se acorta un poco cada mes.