Objetivo
Responder incidentes sin perder evidencia ni continuidad
Enfoque
Preparación, triage, contención, evidencia y recuperación
Resultado
Reducir impacto y mejorar controles después del incidente
22.1 Introducción
Los incidentes cloud native pueden involucrar identidades, buckets, bases, clusters Kubernetes, imágenes, pipelines, secretos, runners, funciones serverless o configuraciones de red. La respuesta debe considerar que muchos recursos son efímeros y altamente automatizados.
Una respuesta improvisada puede empeorar el incidente: borrar pods, destruir instancias o rotar credenciales sin capturar evidencia puede impedir entender alcance y causa raíz.
La respuesta efectiva combina preparación previa, detección, triage, contención, erradicación, recuperación y aprendizaje.
22.2 Fases de respuesta
Un proceso de respuesta ordenado ayuda a priorizar acciones y coordinar equipos.
| Fase |
Objetivo |
Ejemplos |
| Preparación |
Tener accesos, logs y runbooks listos |
Cuentas forenses, playbooks, backups probados |
| Identificación |
Confirmar si hay incidente |
Analizar alerta, alcance y severidad |
| Contención |
Limitar daño y propagación |
Aislar workload, revocar token, bloquear acceso |
| Erradicación |
Eliminar causa y persistencia |
Corregir configuración, retirar imagen maliciosa |
| Recuperación |
Restaurar operación confiable |
Redesplegar desde artefactos firmados, restaurar backups |
| Lecciones aprendidas |
Evitar repetición |
Actualizar controles, detecciones y procesos |
22.3 Preparación
La preparación define si el equipo podrá responder bajo presión. Debe existir antes del incidente.
- Logs de auditoría habilitados y centralizados.
- Acceso de emergencia controlado.
- Runbooks para escenarios frecuentes.
- Backups probados y protegidos.
- Procedimientos para rotación de secretos.
- Inventario de cuentas, clusters, workloads y dueños.
- Canales de comunicación y escalamiento.
- Ambiente o cuenta forense para análisis seguro.
En un incidente no hay tiempo para descubrir dónde están los logs, quién aprueba contención o cómo restaurar un backup.
22.4 Triage inicial
El triage determina si la alerta representa un incidente real y qué severidad tiene. Debe ser rápido, pero basado en evidencia.
Preguntas iniciales:
- ¿Qué activo está afectado?
- ¿Qué identidad o workload participó?
- ¿Qué datos o permisos están en riesgo?
- ¿El evento sigue activo?
- ¿Hay propagación a otros recursos?
- ¿Qué logs y evidencias existen?
- ¿Qué acciones de contención son seguras?
22.5 Preservación de evidencia
Antes de destruir o modificar recursos, conviene capturar evidencia. En cloud, muchas evidencias pueden desaparecer por rotación, escalado o eliminación automática.
Evidencia útil:
- Logs de auditoría cloud y Kubernetes.
- Eventos de CI/CD y despliegue.
- Snapshots de discos o volúmenes.
- Metadatos de instancias, pods, imágenes y nodos.
- Reglas IAM, políticas de red y configuraciones afectadas.
- Artefactos, digest de imágenes y SBOM.
- Capturas de memoria o procesos si el entorno lo permite.
22.6 Contención en cloud
La contención busca limitar impacto sin perder control del caso. En cloud puede realizarse modificando identidades, redes, políticas o recursos.
| Escenario |
Contención posible |
Cuidado |
| Clave cloud filtrada |
Revocar clave, bloquear rol, revisar uso |
Preservar logs antes de limpieza amplia |
| Instancia comprometida |
Aislar red, snapshot, detener o reemplazar |
No destruir disco antes de capturar evidencia |
| Bucket expuesto |
Bloquear acceso público y revisar descargas |
Conservar logs de acceso |
| Rol IAM abusado |
Reducir permisos o deshabilitar confianza |
Evaluar impacto operativo |
22.7 Contención en Kubernetes
En Kubernetes, la contención debe considerar pods efímeros, nodos compartidos, service accounts y secretos montados.
Acciones posibles:
- Aislar namespace mediante network policies.
- Escalar deployment a cero si se confirma abuso.
- Eliminar permisos de la service account afectada.
- Revocar o rotar secretos usados por el workload.
- Cordon y drain de nodos sospechosos si el host está comprometido.
- Capturar manifiestos, eventos, logs y descripción del pod antes de borrarlo.
- Bloquear imágenes comprometidas en admission control.
Borrar un pod puede detener actividad maliciosa, pero también puede borrar evidencia efímera. Primero captura lo necesario si la situación lo permite.
22.8 Contención en CI/CD
Si el incidente involucra pipelines, artefactos o runners, la contención debe proteger la cadena de entrega.
- Deshabilitar workflows sospechosos.
- Revocar tokens y secretos del proyecto.
- Aislar o destruir runners comprometidos.
- Bloquear artefactos publicados durante la ventana afectada.
- Suspender despliegues automáticos a producción.
- Revisar cambios en archivos de pipeline y permisos.
- Verificar firmas, digest y procedencia de artefactos recientes.
22.9 Rotación de credenciales
La rotación de credenciales es frecuente durante incidentes, pero debe ejecutarse con orden para no romper recuperación ni dejar accesos activos.
Priorizar:
- Credenciales confirmadas como filtradas.
- Tokens usados por workloads comprometidos.
- Claves con permisos administrativos.
- Secretos en repositorios, logs o imágenes.
- Certificados o llaves de firma potencialmente expuestos.
- Credenciales compartidas entre ambientes.
22.10 Erradicación
Erradicar implica eliminar la causa del incidente y cualquier persistencia. No alcanza con contener síntomas.
Ejemplos:
- Corregir política IAM excesiva.
- Retirar imagen maliciosa del registry.
- Actualizar dependencia vulnerable.
- Eliminar backdoors, tokens o usuarios creados por el atacante.
- Corregir plantilla IaC que generó exposición.
- Actualizar regla de admission control para bloquear repetición.
- Parchear host, runtime o componente afectado.
22.11 Recuperación
Recuperar significa volver a operar desde un estado confiable. En cloud native suele ser mejor reconstruir que reparar manualmente.
| Recurso |
Recuperación recomendada |
Validación |
| Workload |
Redeploy desde imagen firmada y escaneada |
Digest, firma, configuración y logs |
| Infraestructura |
Reaplicar IaC corregido |
Plan revisado y policy as code |
| Datos |
Restaurar backup limpio si hubo alteración |
Integridad, consistencia y permisos |
| Credenciales |
Rotar y validar uso nuevo |
Logs sin uso de credenciales antiguas |
22.12 Comunicación
La comunicación evita confusión durante incidentes. Debe definir audiencias, frecuencia y contenido.
Considerar:
- Equipo técnico de respuesta.
- Dueños de aplicación y negocio.
- Legal, privacidad y cumplimiento.
- Proveedores cloud o terceros afectados.
- Clientes o usuarios si corresponde.
- Dirección y responsables ejecutivos.
La comunicación debe diferenciar hechos confirmados, hipótesis y acciones en curso.
22.13 Postmortem y mejora
Después del incidente, el equipo debe analizar causas y mejoras sin centrarse en culpas individuales. El objetivo es fortalecer sistema y proceso.
Preguntas útiles:
- ¿Cómo se detectó el incidente?
- ¿Qué señales faltaron?
- ¿Qué control preventivo falló o no existía?
- ¿La contención fue rápida y segura?
- ¿La evidencia fue suficiente?
- ¿Qué runbooks deben actualizarse?
- ¿Qué cambios de arquitectura o pipeline previenen repetición?
22.14 Errores frecuentes
- Destruir recursos antes de preservar evidencia.
- Rotar solo una credencial y no revisar tokens derivados.
- Contener sin entender alcance.
- No revisar pipelines y artefactos cuando el incidente parece solo de runtime.
- Restaurar desde backups sin validar integridad.
- Comunicar hipótesis como hechos confirmados.
- No actualizar detecciones después del incidente.
- Hacer postmortem sin acciones concretas ni responsables.
La respuesta madura no termina cuando vuelve el servicio. Termina cuando se entiende la causa, se reduce la probabilidad de repetición y se mejora la detección.
22.15 Lista de verificación
- ¿Existen runbooks para credenciales filtradas, bucket público, pod comprometido y pipeline comprometido?
- ¿Los logs críticos están centralizados y protegidos?
- ¿Hay procedimientos para snapshots, evidencia y cadena de custodia?
- ¿Se pueden aislar workloads, namespaces, cuentas o redes rápidamente?
- ¿La rotación de secretos está probada?
- ¿Los backups se restauran y verifican regularmente?
- ¿Los artefactos confiables están firmados y trazados?
- ¿Los postmortems generan acciones con responsables y fechas?
22.16 Qué debes recordar de este tema
- Cloud native requiere responder sin destruir evidencia efímera.
- La contención puede actuar sobre identidad, red, workload, pipeline o artefacto.
- Las credenciales deben rotarse con alcance y orden.
- Recuperar desde artefactos e IaC confiables suele ser mejor que reparar manualmente.
- El aprendizaje posterior debe actualizar controles, detecciones y runbooks.
22.17 Conclusión
La respuesta a incidentes en cloud y contenedores exige preparación técnica, visibilidad, contención precisa y recuperación confiable. La velocidad importa, pero no debe destruir evidencia ni generar cambios imposibles de auditar.
En el próximo tema estudiaremos cumplimiento, gobierno y gestión de riesgos en plataformas cloud nativas.