Cuando un secreto se filtra: contener, rotar, reconstruir

Ante una credencial filtrada, el primer paso es dejar de aceptarla: desactivar la clave de acceso o el secreto de la aplicación. Se desactiva y no se borra, para conservar la evidencia de qué credencial era y cuándo se usó. Borrar el cambio del repositorio es un paso posterior de limpieza, no una contención, porque la credencial sigue valiendo hasta que se revoca. Y tampoco se programa el borrado de una clave de cifrado: esa clave no se filtró, y borrarla destruye datos de forma irreversible al cumplirse su plazo.

Contener es quitarle el valor a la credencial; limpiar es lo que se hace después.

La credencial filtrada se desactiva y se sustituye por otra. Pero lo que esa credencial pudo leer también debe darse por visto: los secretos que el registro muestra leídos con éxito con ella se rotan, aunque el secreto en sí no se haya publicado. Los intentos que el registro muestra rechazados no obligan a rotar, aunque sí se anotan, porque dicen qué buscaba quien la usó. Se rota lo que el registro prueba que salió, no todo lo que la credencial habría podido tocar en teoría.

El registro decide el alcance de la rotación: lo leído con éxito se rota.

Abre el laboratorio. La empresa sale a internet por una sola dirección, que figura en el aviso del análisis de repositorios. El registro de AWS mezcla eventos de la clave filtrada hechos desde esa dirección habitual con otros desde un origen distinto. Identifica el origen que no es el de la empresa.

Entre los eventos desde el origen ajeno hay varios intentos. Lee la columna de resultado: lo que importa para la rotación no es lo que se intentó, sino lo que se leyó de verdad. Busca el secreto de AWS que se leyó con éxito desde ese origen.

El informe del incidente debe decir cuánto tardó el primer uso ajeno desde que la credencial se hizo pública. El aviso da la hora del cambio que la publicó, y el registro de AWS la del primer evento desde el origen ajeno. Calcula el intervalo en minutos.