Control de caducidad de credenciales en las app registrations de Entra ID

Si administras un tenant de Entra ID, ya sabes cómo va esto. Con los años se acumulan app registrations igual que se acumulan cables en un cajón: integraciones, herramientas internas, conectores de proveedores, algo que alguien montó en 2019 y ahí sigue. Cada una lleva un secreto o un certificado. Cada uno de ellos tiene fecha de caducidad. El día que vence, la integración se para. Dos o tres días después llega un ticket, y la primera hora se va en averiguar de quién es la aplicación y para qué servía.

En nuestro caso eran más de las que había contadas de forma fiable; visto con perspectiva, eso ya era parte del problema.

Lo primero que apetece hacer es preguntarle a Graph qué credenciales caducan pronto y mandar el listado a algún buzón, y de hecho el propio portal de Entra ya filtra las app registrations por credenciales a punto de caducar, así que esa parte nunca fue el problema. Lo que te da es una alerta que no se acciona, y antes de que el primer aviso valiera de algo había dos preguntas que responder.

• ¿De quién es? Un responsable por aplicación, escrito en el propio objeto.

• ¿Se usa? Solo las credenciales con inicios de sesión recientes merecen un aviso.

• Y entonces, el aviso. 30 y 7 días antes, en palabras que el responsable pueda accionar.

Primera pregunta: ¿de quién es esto?

Aquí está la trampa: Entra ID no obliga a que una aplicación tenga responsable, y te deja crear una sin nombrar a nadie. El resultado era previsible. Buena parte de las nuestras no tenía responsable, o tenía a alguien que se había ido hacía años.

Un aviso sin destinatario no sirve para nada, así que la mitad del proyecto fue poner nombre a cada aplicación. Las fuentes que de verdad funcionan, más o menos por orden de fiabilidad: el equipo que consume la integración, el rastro de auditoría del directorio (quién la creó y quién la tocó por última vez) y quien sea dueño de la suscripción o del recurso con el que habla.

Y lo que marca la diferencia a largo plazo: dejarlo escrito en el propio registro. Un responsable que averiguas y guardas en un Excel caduca antes de un año. Un responsable escrito en el objeto lo encuentra el siguiente aviso sin que nadie tenga que volver a preguntar.

Segunda pregunta: ¿esta credencial se usa?

El segundo filtro es igual de importante, y es el que casi todo el mundo se salta.

Un script de PowerShell lee todas las aplicaciones y todas sus credenciales a través de Graph y las cruza con la actividad de inicio de sesión de los service principals de los últimos meses. Eso separa lo que está «en uso» de lo que está «olvidado», y esa diferencia cambia lo que significa la alerta: una credencial a punto de caducar en una integración muerta es limpieza, no un incidente esperando su turno.

Por eso los avisos solo salen para credenciales con actividad reciente. Un secreto olvidado al lado de un certificado que sí se usa no dispara nada. De paso, esa misma pasada sacó a la luz decenas de credenciales que ya habían caducado, algunas desde hacía años; que nadie se hubiera enterado es, precisamente, la prueba de que no las usaba nadie. Otro script las retira, con simulación por defecto y copia de seguridad de cada objeto antes de tocar nada.

El aviso, y quién lo lee

Una Logic App escribe al responsable 30 y 7 días antes de la caducidad. Conviene recordar quién suele ser ese responsable: un product owner o un contacto de negocio, no un ingeniero.

Si le mandas un correo que dice «su credencial keyId 3f2a… con el permiso Directory.Read.All caduca el día 14», lo reenvía a IT y el ticket llega igual. Has automatizado el descubrimiento y te has quedado con todo el trabajo.