Claves API de Google siguen activas 23 minutos después de ser eliminadas
Claves API de Google siguen funcionando hasta 23 minutos después de ser eliminadas por sus propietarios, según una investigación de Aikido publicada esta semana. Además, lo más llamativo es que Google considera este retraso como un comportamiento intencionado y ha confirmado que no piensa modificarlo. En consecuencia, cualquier respuesta a incidentes que dependa de la rotación inmediata de credenciales tiene, en la práctica, una ventana ciega que un atacante puede explotar.
Cómo descubrieron el fallo en las claves API de Google
De hecho, el equipo de Aikido detectó el comportamiento durante una prueba rutinaria de respuesta a incidentes. Por su parte, los investigadores eliminaron una clave desde la consola de Google Cloud y, sin embargo, las llamadas API siguieron autenticándose con éxito durante casi media hora después de la supuesta revocación.
Asimismo, el problema afecta a múltiples servicios dentro del ecosistema Google Cloud y no solo a un endpoint aislado. Aun así, la ventana exacta varía entre regiones y servicios, lo que dificulta planificar una respuesta predecible cuando la urgencia aprieta.
Por qué Google no piensa corregirlo
Por otro lado, la respuesta oficial de Google fue inesperada: la compañía calificó el retraso como un comportamiento intencionado y necesario para la consistencia eventual de su infraestructura distribuida. En este sentido, su sistema de autorización propaga las invalidaciones de forma asincrónica para evitar caídas en cascada en otros servicios.
No obstante, esta justificación choca de frente con el modelo mental que la mayoría de equipos de seguridad asume al revocar una clave comprometida. Como resultado, los runbooks de respuesta a incidentes basados en la premisa de que «borrar» equivale a «invalidar» quedan desactualizados frente a la realidad operativa de Google Cloud.
Qué hacer con tus claves API de Google a partir de ahora
Por lo tanto, la recomendación inmediata es asumir esa ventana de 23 minutos como parte del modelo de amenazas y diseñar la respuesta en consecuencia. Asimismo, conviene combinar la eliminación con restricciones adicionales a nivel de IAM, revocación de tokens federados y monitoreo intensivo de logs durante el intervalo. Para profundizar en estrategias de respuesta a incidentes en la nube, puedes explorar más artículos sobre seguridad cloud en nuestro blog.
Finalmente, este caso refuerza una lección incómoda: las garantías técnicas que damos por sentadas en proveedores cloud rara vez están documentadas con la precisión que requiere la seguridad. En la práctica, validar el comportamiento real con pruebas controladas debería ser parte del onboarding de cualquier servicio crítico, no algo que descubrimos cuando ya es tarde.
Recuerda que estaremos publicando constantemente en nuestro blog más contenido sobre tecnología.
Puedes encontrarnos en LinkedIn para más contenido relacionado con seguridad en internet y muchos temas más.
Fuentes: The Register, TLDR Information Security.