Cuando un proveedor comprometido almacenaba claves de API: contención, sustitución y revisión de la facturación

Objetivo

Estado a 25 de octubre de 2026. Contener la exposición potencial de claves de API almacenadas por un servicio y después restablecer el acceso autorizado y conciliar el uso. Volver a comprobar el aviso más reciente de ese servicio y la documentación de cada emisor sobre revocación, rotación y facturación. Este protocolo no establece que haya ocurrido una brecha concreta.

Requisitos previos

Utilizar un entorno de administración de confianza con controles de credenciales en el emisor, los identificadores de los proyectos afectados, los responsables de las aplicaciones y acceso a los registros de auditoría y facturación. Registrar la revisión del aviso y el período de exposición, incluida la zona horaria; si se desconoce el inicio, dejarlo indicado. Mantener los valores de las credenciales fuera del ticket del incidente.

Pasos

1. Determinar el alcance de la exposición. Identificar qué claves almacenaba el proveedor y todos los consumidores legítimos que las compartían. Registrar identificadores, permisos y responsables. Para Google Cloud, el comando de inventario documentado es gcloud services api-keys list --project=PROJECT_ID; sustituir el marcador por el identificador del proyecto. Un inventario de claves identifica posibles claves afectadas, no demuestra su robo. Referencia de la CLI.

2. Contener antes de restablecer. Suspender la integración afectada y revocar las claves expuestas en su emisor. Eliminar una copia guardada no equivale a revocarlas en el emisor. El procedimiento de incidentes de OWASP prioriza la revocación inmediata, seguida de la sustitución y la limpieza. Aceptar una interrupción controlada en lugar de seguir utilizando una credencial expuesta. Impedir que el servicio afectado reciba secretos de reemplazo hasta que se haya confirmado su recuperación. Respuesta de OWASP ante la exposición de secretos.

3. Sustituir por vías de confianza. Emitir las claves de reemplazo y actualizar cada consumidor autorizado. Google Cloud también documenta la rotación de claves de API por etapas: crear la clave de reemplazo, actualizar las aplicaciones y después eliminar la anterior. Si se utiliza ese solapamiento para mantener la disponibilidad, tener en cuenta explícitamente el período durante el cual la clave expuesta sigue siendo utilizable. No asumir de forma implícita que crear una clave nueva revoca la anterior. Procedimiento del emisor.

4. Investigar la cuenta. Examinar los registros de auditoría disponibles desde el primer momento plausible de exposición hasta la contención. Buscar llamadas inesperadas, credenciales e identidades nuevas y cambios en los recursos; Google Cloud remite esta investigación a Cloud Logging y Security Command Center. Conservar las evidencias pertinentes antes de eliminar el acceso no autorizado. Comparar por separado el uso y la facturación con las cargas de trabajo previstas, y enviar los identificadores de las solicitudes disputadas, las marcas de tiempo y los registros de cargos a través del soporte autenticado. No dar por supuesto el reembolso. Orientaciones para la investigación.

5. Restringir el acceso futuro. Separar las integraciones y los entornos, conceder solo los permisos necesarios y preferir credenciales de corta duración cuando se admitan. Google Cloud recomienda restricciones de API y de aplicación para reducir el uso indebido de claves. Ajustar las restricciones al consumidor legítimo y verificar que siga funcionando. Restricciones de claves, ciclo de vida de los secretos.

6. Establecer y distinguir los controles de costos. Configurar topes de gasto o cuotas que el emisor haga cumplir cuando estén disponibles, además de alertas enviadas a un canal supervisado. Confirmar qué ajustes detienen realmente las solicitudes. AWS Budgets advierte expresamente de que los retrasos en la facturación y las notificaciones pueden permitir que el gasto supere el umbral de alerta. Probar la entrega de alertas sin generar deliberadamente cargos excesivos. Limitaciones de los presupuestos.

7. Verificar el cierre. Comprobar la invalidación en el emisor, el uso autorizado satisfactorio de las claves de reemplazo y la continuidad de la revisión del uso conforme se actualiza la facturación. Registrar las lagunas de los registros que sigan sin resolverse y los cambios sospechosos en la cuenta. Ante evidencias de que un host está comprometido, abrir una investigación de recuperación independiente antes de reinstalar credenciales en él.

Resultado esperado

Las credenciales expuestas quedan invalidadas, los consumidores legítimos utilizan claves de reemplazo restringidas y la revisión del uso, respaldada por evidencias, tiene un responsable y hallazgos registrados.

Límites y base de verificación

Esta es una síntesis operativa propuesta, no una recuperación probada. La falta de registros no demuestra la ausencia de abuso. Google Cloud advierte de que los tokens de cuentas de servicio ya emitidos tienen períodos de validez independientes: investigar el acceso derivado en lugar de suponer que sustituir la clave de origen lo invalida. No se afirma que haya una versión de software afectada ni una versión corregida.