Revocación y rotación de secretos expuestos

Una vez confirmada la filtración de una credencial, la rapidez es importante, pero también lo es el orden. Desactivar una clave de forma abrupta puede interrumpir producción si antes no comprende qué depende de ella.

El objetivo es cortar el acceso del atacante y mantener en funcionamiento las cargas de trabajo legítimas, idealmente mediante una única secuencia ensayada.

La primera medida ante una clave de acceso filtrada es desactivarla, no eliminarla. Establecer el estado de la clave como Inactive impide inmediatamente que siga funcionando.

Conservarla (inactiva) por ahora permite correlacionarla con los datos forenses de CloudTrail. Elimínela solo después de completar la investigación.

Para los usos legítimos, la rotación consiste en emitir una clave de acceso nueva, actualizar todos los lugares que utilizaban la anterior y, después, desactivar la clave comprometida.

Seguir ese orden evita una interrupción: la credencial nueva está activa antes de desactivar la antigua. Compruebe siempre primero que la aplicación funciona con la clave nueva.

Desactivar una clave de larga duración no invalida las credenciales temporales que esta pudiera haber generado ya. Para los roles, utilice la función de IAM revoke sessions, que asocia una política de denegación basada en una hora límite de emisión del token.

Esto invalida todas las sesiones activas anteriores a ese momento y cierra de golpe el acceso a las credenciales que ya están en manos del atacante.

Antes de rotar la clave, averigüe dónde se encuentra el secreto. CloudTrail muestra qué servicios y direcciones IP utilizaron la clave.

Un secreto incluido directamente en el código en muchos lugares demuestra precisamente por qué esa práctica es peligrosa. Identificar todos los consumidores garantiza que la rotación no deje un sistema olvidado averiado ni una copia del secreto todavía en uso.

AWS Secrets Manager almacena secretos, como contraseñas de bases de datos y claves de API, y puede rotarlos automáticamente según una programación mediante una función de Lambda.

La rotación automática hace que un secreto filtrado tenga una vida útil breve y permite que las aplicaciones obtengan el valor actual en tiempo de ejecución, en lugar de conservar una copia obsoleta incluida directamente en el código.

Una credencial filtrada suele desbloquear otras. Si un atacante utilizó una clave para leer una base de datos, es posible que las contraseñas de esa base de datos también estén comprometidas.

Rote también los secretos posteriores. Analice toda la cadena: debe considerar expuesto y reemplazar cada secreto al que el atacante pudiera haber accedido.

Si AWS detecta una exposición, puede asociar AWSCompromisedKeyQuarantineV2 al usuario, denegando las acciones de alto riesgo y permitiéndole investigar.

No se limite a desasociarla y seguir adelante. Considérela una señal de que aún debe completar la corrección real: desactivación, rotación y revisión.

La rotación detiene los abusos futuros, pero no deshace los daños anteriores. Utilice CloudTrail para enumerar todas las acciones realizadas por la credencial comprometida.

Revierta los cambios maliciosos: elimine los usuarios de IAM no autorizados, quite las claves de puerta trasera y desmonte los recursos creados por el atacante. La contención y la limpieza son pasos distintos y necesarios.

Después de la recuperación, reduzca el riesgo futuro. Sustituya las claves de larga duración por credenciales temporales basadas en roles, habilite la rotación automática de secretos y añada el análisis de secretos a su canalización de CI/CD.

La solución más sólida es arquitectónica: si no existe ningún secreto estático que se pueda filtrar, el atacante no tendrá nada que encontrar.

La corrección no termina hasta que queda registrada. Documente qué credenciales se rotaron, qué hizo el atacante y qué cambios se revirtieron.

Notifique a las partes interesadas que figuran en su runbook y, si se expusieron datos regulados, cumpla sus obligaciones de notificación de vulneraciones. Un registro claro convierte el incidente en una lección y facilita las auditorías posteriores.

Elija la primera acción correcta.

Para remediar una credencial filtrada, desactive la clave de acceso (conservándola para el análisis forense), rótela por una clave nueva sin interrupciones y revoque las sesiones activas de los roles para invalidar las credenciales temporales ya emitidas. Identifique primero a todos los consumidores, rote los secretos posteriores a los que el atacante podría haber accedido y revierta los cambios maliciosos registrados en CloudTrail. Use Secrets Manager para la rotación automática y adopte credenciales temporales basadas en roles para evitar que vuelva a ocurrir.