La mayoría de empresas “tienen” un plan de respuesta a incidentes, pero cuando el incidente ocurre en cloud en producción, lo que marca la diferencia no es el documento: es la capacidad de ejecutar decisiones difíciles en minutos sin romper el negocio. El playbook mínimo no busca cubrir todos los escenarios, sino asegurar que ante tres eventos frecuentes (cuenta comprometida, fuga de secretos, escalada de privilegios) el equipo puede contener, preservar evidencias y restaurar control con el menor impacto posible.
Este artículo está pensado para equipos que ya operan cargas en producción y necesitan un guion accionable para las primeras 24 horas. No entraremos en teoría de IR ni en frameworks generales: aquí va el “qué hacemos ya”, con trade-offs reales y validaciones concretas en AWS/Azure/GCP.
Qué salió mal (y cómo se manifiesta) en incidentes cloud de producción
En cloud, los incidentes raramente empiezan con “nos han cifrado todo”. Suelen empezar con señales pequeñas: una API key usada desde una geografía anómala, un rol que de pronto asume sesiones con duración extraña, o un secret que aparece en un repo o en logs. El problema es que en producción hay ruido: pipelines que rotan credenciales, cuentas de servicio que escalan por autoscaling y equipos que despliegan 20 veces al día. Ese ruido es el refugio perfecto para el atacante.
Los tres escenarios que más se repiten en empresas operando en serio comparten un patrón: pérdida de control sobre identidad y permisos. Una cuenta comprometida (humana o de servicio) permite persistencia; una fuga de secretos habilita acceso “legítimo” sin explotar nada; una escalada de privilegios convierte un fallo limitado en un incidente transversal (red, datos, backups, CI/CD). En todos los casos, el coste real en empresa suele venir después: cambios de permisos a ciegas que rompen producción, rotaciones masivas sin coordinar que tumba integraciones, o “apagar” logs que eran la única evidencia.
La primera decisión importante es aceptar que la contención en cloud casi siempre compite con continuidad de negocio. Si cortas demasiado, paras ingresos; si cortas poco, el atacante se mueve. El playbook mínimo propone contenciones reversibles y verificables, priorizando cortar rutas de acceso antes que tocar datos o infra.
Las primeras 24 horas: priorización y decisiones que no se pueden posponer
En las primeras horas, el objetivo no es “arreglarlo todo”, sino recuperar control operativo: saber qué identidad está comprometida, por dónde entra, qué permisos tiene y si hay persistencia. Si el equipo empieza por “rotar todos los secretos” sin identificar el vector, suele provocar dos daños: se rompen dependencias críticas (pagos, SSO, integraciones B2B) y se pierden pistas (sesiones activas, correlación de eventos) porque se cambia el estado del sistema sin necesidad.
Una priorización que funciona en empresas con producción activa es: (1) parar accesos actuales del actor, (2) preservar visibilidad y evidencias, (3) bloquear persistencia, (4) restaurar accesos legítimos y (5) recién ahí, rotar de forma planificada. Esto evita el patrón corporativo típico de “cambio masivo por correo” que termina en un freeze de despliegues y en equipos saltándose controles para recuperar servicio.
Checklist operativo para las primeras 24 horas
- Congelar el perímetro de identidad afectado sin romper todo: deshabilitar usuario/credencial concreta, revocar sesiones/tokens cuando sea posible y aplicar restricciones temporales (por IP, por condiciones, por duración de sesión) antes de tocar políticas globales.
- Asegurar logging y retención: verificar que los logs de auditoría (CloudTrail/Azure Activity Logs/GCP Audit Logs) están habilitados, con retención y destino fuera de la cuenta/proyecto afectado si existe. Evita “limpiar” recursos porque puede destruir evidencia y complicar cumplimiento.
- Identificar acciones recientes con mayor impacto: creación/modificación de roles, trust policies, claves nuevas, cambios en IdP/SSO, reglas de firewall/SG/NSG, y exfiltración desde storage o bases de datos. En empresa, los atacantes suelen priorizar credenciales y acceso persistente antes que “tocar” workloads.
Cada punto anterior es deliberadamente reversible: busca minimizar impacto y mantener la capacidad de investigar. Si se necesita un corte más agresivo, que sea un escalado consciente (con comunicación a negocio) y no una reacción impulsiva.
Contención mínima viable: cortar acceso sin perder visibilidad ni control
Contener en cloud no es “apagar servidores”; es cortar caminos de identidad y red de forma selectiva. Lo mínimo viable suele ser: revocar sesiones, deshabilitar credenciales concretas, limitar asunción de roles y bloquear egress o accesos a datos sensibles si hay evidencia de exfiltración. La contención debe tener dos propiedades: ser rápida de ejecutar y fácil de validar.
En incidentes reales, el error más caro es aplicar un “deny all” global o tocar políticas base sin un plan de rollback. Ese tipo de respuesta suele tumbar pipelines, detonar rotaciones improvisadas y abrir la puerta a bypass (equipos creando credenciales fuera del control central para “volver a desplegar”). Mejor una contención por capas: primero identidad comprometida, luego roles críticos, luego rutas de red y, por último, servicios de datos específicos.
Cómo hacerlo en la práctica
- AWS (IAM/STS): desactiva access keys del usuario afectado, fuerza el cierre de sesiones (revocando credenciales y rotando claves del usuario/role comprometido), y restringe la asunción de roles críticos mediante condiciones. Si sospechas de un role comprometido, revisa de inmediato su trust policy y sesiones recientes en CloudTrail (eventos
AssumeRole,AssumeRoleWithSAML,AssumeRoleWithWebIdentity). - Azure (Entra ID/ARM): bloquea el usuario o cuenta de servicio, revoca sesiones (sign-in sessions) y revisa asignaciones recientes de roles en Azure RBAC y cambios en aplicaciones/consentimientos. Un incidente típico es el abuso de una app registrada con permisos excesivos.
- GCP (IAM/OAuth): deshabilita o rota claves de service accounts, revisa bindings IAM recientes y tokens OAuth emitidos. En GCP, los cambios de IAM a nivel proyecto/organización son el punto de inflexión: prioriza auditar eso antes que tocar workloads.
Validación rápida tras la contención: intenta reproducir el acceso del atacante de forma controlada (por ejemplo, simulando la asunción de rol con el principal sospechoso) y confirma en los logs que los intentos fallan. Si no puedes validar, la contención es una hipótesis, no un control.
Fuga de secretos y escalada de privilegios: rotación y “blast radius” con disciplina
Cuando hay fuga de secretos (tokens, keys, passwords, kubeconfig, credenciales de CI/CD), el impulso natural es rotar todo. En una empresa, eso puede romper integraciones con clientes, proveedores o sistemas legados donde cambiar un secreto implica tickets, ventanas y validaciones. El playbook mínimo recomienda rotar por riesgo: primero lo que da acceso a identidad (IdP, CI/CD, cuentas cloud), luego lo que da acceso a datos (DB/storage), y por último credenciales de servicios periféricos.
Para escalada de privilegios, el foco no es “quitar permisos a todo el mundo”, sino identificar el mecanismo: role chaining, trust policies abiertas, permisos de administración de IAM, o rutas indirectas (por ejemplo, un principal con permiso para actualizar una función/serverless que luego ejecuta con role privilegiado). En incidentes reales, el atacante raramente inventa magia: explota un permiso existente mal acotado y lo convierte en persistencia.
Bloque técnico: ejemplo de control concreto y cómo validarlo (AWS)
Si detectas que un rol crítico puede ser asumido por principals no esperados, corrige la trust policy para limitar el principal y añadir condiciones. Ejemplo (simplificado) para permitir asunción solo desde un rol específico y exigir MFA cuando aplica:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::123456789012:role/ci-deploy"},
"Action": "sts:AssumeRole",
"Condition": {
"Bool": {"aws:MultiFactorAuthPresent": "true"}
}
}
]
}
Validación en AWS: revisa en CloudTrail que los eventos AssumeRole solo provienen del principal permitido; busca fallos AccessDenied para intentos fuera de la condición; y verifica en IAM Access Analyzer si el rol queda expuesto a entidades externas. Si el rol está asociado a workloads (EC2/ECS/Lambda), confirma que esos servicios no dependían de esa asunción interactiva (para no romper producción).
La rotación de secretos debe ir acompañada de inventario y prueba de funcionamiento. Un secreto rotado sin “smoke test” real termina en caídas diferidas (por ejemplo, a las 2 horas cuando expira el token cacheado) y hace que el incidente parezca “intermitente”, complicando el diagnóstico.
Checklist por proveedor para investigación y verificación sin perder el control
Investigar en cloud es correlación: identidad → acción → recurso → datos. El mínimo viable es tener una lista de “lugares” donde mirar primero, porque el tiempo se va en exploración. En empresa, la investigación suele estar bloqueada por permisos insuficientes del equipo de respuesta o por logs dispersos en cuentas/proyectos distintos; por eso el checklist se centra en evidencias de alto valor y en verificar que sigues viendo lo que pasa.
Puntos de verificación iniciales
- AWS: CloudTrail (incluyendo management events), cambios en IAM (usuarios, roles, policies, access keys), eventos STS (
AssumeRole*), cambios en KMS (key policies/grants), y accesos a S3 (data events si están habilitados). En incidentes reales, descubrir una access key nueva creada minutos antes del primer acceso externo suele explicar la persistencia. - Azure: Entra ID sign-in logs, audit logs (cambios de apps, consentimientos, role assignments), Activity Logs de suscripción, y cambios en Key Vault (accesos y modificaciones). Un patrón común es el abuso de permisos delegados/consentidos para operar “como si fuera legítimo”.
- GCP: Cloud Audit Logs (Admin Activity y Data Access si aplica), cambios en IAM a nivel proyecto/folder/org, service account keys creadas recientemente y uso de tokens. En empresas con múltiples proyectos, el atacante intenta moverse lateralmente via IAM a nivel organización.
Tras revisar, decide si el incidente es “identidad sola” (sin evidencia de acceso a datos) o si hay indicios de exfiltración. Esa decisión cambia el siguiente paso: si hay exfiltración probable, prioriza bloquear rutas de salida y accesos a datasets concretos; si no la hay, prioriza cerrar persistencia y limpiar permisos. En ambos casos, documenta cada cambio operativo con timestamp y responsable: más tarde te salvará en auditorías y en postmortems internos.
Recomendaciones para entornos corporativos
El playbook mínimo para respuesta a incidentes cloud en producción debe optimizar por ejecución: contenciones reversibles, verificación inmediata y preservación de evidencias. En las primeras 24 horas, lo crítico es recuperar control de identidad (usuarios, cuentas de servicio, roles y trust), mantener logging y evitar cambios globales que rompan el negocio sin bloquear al atacante.
Si tu equipo solo implementa tres cosas, que sean: (1) un checklist operativo por proveedor para contención e investigación, (2) mecanismos de validación tras cada cambio (logs y pruebas controladas), y (3) una rotación de secretos por prioridad y con pruebas, no “a ciegas”. Eso es lo que separa una respuesta madura de una respuesta ruidosa que agrava el impacto en producción.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.