Se filtró una API key: qué hacer en la primera hora (guía de respuesta)
Apareció una key en un repo público, en un canal de Slack equivocado, o en el pastebin de un tercero. La reacción instintiva — borrarla de donde apareció y seguir — es exactamente la incorrecta: el borrado no des-expone nada, y el tiempo que gastás en él es tiempo en que la key sigue válida. Esta es la secuencia correcta, en orden, con el razonamiento detrás de cada paso.
Paso 0 — Asumí compromiso, no evalúes probabilidad
La primera decisión es mental: una key expuesta se trata como comprometida, punto. No importa si el repo era poco visitado, si el canal era interno o si "estuvo pocas horas". La evaluación de "¿la habrá visto alguien?" es incontestable por diseño — no tenés visibilidad de quién accedió — y cada minuto de deliberación es exposición. En repos públicos además la pregunta ya tiene respuesta: el escaneo automatizado de credenciales es continuo y la ventana entre exposición y primer intento de uso puede ser de minutos. La política que elimina la deliberación es la correcta: expuesta = comprometida = se rota. Siempre.
Paso 1 — Rotá primero, investigá después
La rotación es el único paso que corta el riesgo, así que va primero: generá la credencial nueva, actualizá los sistemas que la consumen, y revocá la vieja. En ese orden si el servicio lo permite (para evitar downtime), o revocación inmediata si la key tiene permisos peligrosos y el downtime es el mal menor — esa es una decisión de severidad que conviene tener pre-decidida por tipo de key, no improvisar a las 2 AM. Si no sabés rápidamente qué sistemas consumen la key, ese es un hallazgo en sí mismo: el inventario de secretos (qué key, qué servicio, qué permisos, quién es el dueño) es el prerequisito que hace que este paso tome minutos en lugar de horas.
Paso 2 — Medí qué podía hacer la key
Con la key ya rotada, la pregunta pasa a ser cuánto daño pudo hacerse mientras estuvo expuesta. Eso lo define su alcance: ¿era de lectura o de escritura? ¿De un ambiente de prueba o de producción? ¿Accedía a datos personales, a facturación, a infraestructura? El alcance determina la profundidad del paso siguiente: una key de solo lectura de un ambiente de staging sin datos reales termina el incidente acá, con registro y lección aprendida. Una key de producción con acceso a datos de clientes escala a revisión formal de impacto — y si hubo acceso efectivo a datos personales, entran en juego las obligaciones de notificación de la regulación aplicable, con sus plazos.
Paso 3 — Revisá los logs del período de exposición
Los logs del proveedor o servicio son los que responden si la key se usó: buscá actividad desde orígenes desconocidos (IPs, user agents), en horarios anómalos, o con patrones de uso distintos a los de tus sistemas, durante toda la ventana de exposición — desde que la key llegó al lugar inseguro, no desde que la descubriste ahí. Si el servicio no ofrece logs de uso por credencial, anotalo: es un criterio para la próxima evaluación de ese proveedor. Uso malicioso confirmado convierte el evento en incidente formal, con preservación de evidencia y las obligaciones del paso anterior; ausencia de uso anómalo permite cerrar con severidad baja — pero la rotación del paso 1 no se revierte ni se lamenta, porque era correcta con cualquier resultado.
Paso 4 — Cerrá el canal, no solo el caso
El último paso es el que evita la repetición: ¿por dónde llegó la key al lugar inseguro? Si fue un commit, el control es técnico — hooks o escaneo de secretos antes del push, y variables de entorno en lugar de valores en el código. Si fue un chat, un correo o un documento, el control es de circuito: el equipo necesita un canal designado para compartir secretos que sea más cómodo que el chat, más una búsqueda del stock histórico de credenciales en esos canales para rotar lo que aparezca. Un incidente cuya remediación termina en "rotamos la key" está resuelto a medias: la misma persona, con la misma necesidad y las mismas herramientas, va a producir el mismo evento. La remediación completa cambia el camino fácil.
La versión corta, para imprimir
Expuesta = comprometida, sin deliberar. Rotar primero: nueva key, actualizar consumidores, revocar la vieja. Después medir: permisos y ambiente de la key definen la severidad. Después verificar: logs de uso durante toda la ventana de exposición, con escalamiento formal si hubo actividad anómala. Y al final, cerrar el canal de fuga con un control técnico o de circuito, más rotación del stock histórico si el canal era chat o correo. El equipo que tiene esta secuencia escrita y un inventario de sus keys resuelve en una hora lo que a los demás les toma un fin de semana — y la diferencia entre ambos no es presupuesto, es haberlo decidido antes.
El mejor incidente es el que no ocurre
La mayoría de las keys filtradas salieron por un chat, un correo o un documento. ShaSafSec reemplaza ese canal: compartí secretos de forma segura y sacale al próximo incidente su punto de partida.
Probar ShaSafSec →