Parte: 9 — Forense digital y respuesta a incidentes · Fuente: NIST IR 8006 — Cloud Computing Forensic Science Challenges y documentación de AWS/Azure/GCP ⏱️ Duración estimada: 120 min · Nivel: Avanzado
Entender cómo cambia la forense cuando la evidencia vive en la nube: modelo de responsabilidad compartida, logs de plataforma (CloudTrail, Azure Activity Log, GCP Audit), snapshots de discos, y adquisición de instancias efímeras. Al terminar sabrás qué evidencia pedir, cómo preservarla y cómo investigar un compromiso de identidad en la nube.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | Responsabilidad compartida | Define a qué evidencia accedes |
| 2 | CloudTrail y logs de control | Historial de acciones de API |
| 3 | Azure Activity/Sign-in Logs | Equivalente en Azure |
| 4 | GCP Audit Logs | Equivalente en GCP |
| 5 | Snapshots de disco | Adquisición de volúmenes |
| 6 | Instancias efímeras y contenedores | Evidencia que se evapora |
| 7 | Compromiso de identidad (IAM) | Relacionar principal, sesión, permisos y acciones |
| 8 | Preservación y aislamiento | Reducir cambios y conservar fuentes accesibles |
En nube, gran parte de la evidencia no es un disco bajo control del investigador: son registros de control plane, snapshots, objetos versionados e información entregada por el proveedor. Responsabilidad compartida determina qué puede adquirir el cliente y qué debe solicitar formalmente.
Primero se protege el acceso investigativo y se evita destruir recursos al revocar credenciales. Logs pueden estar deshabilitados, tener demora o vivir en otra cuenta/región. Snapshot no equivale a imagen física y una API puede cambiar metadatos. Se conserva respuesta original, request ID, cuenta, región, comando, hora y mecanismo de exportación. La retención se prepara antes del incidente.
El plano de control registra cambios administrativos: crear una instancia, modificar una política o deshabilitar un registro. El plano de datos registra operaciones sobre contenido, como leer un objeto, y con frecuencia requiere habilitación o configuración adicional. Los logs de identidad agregan inicios de sesión, emisión de tokens, MFA y riesgo. Investigar solo uno de estos planos puede ocultar la secuencia entre acceso, escalado y uso de datos.
Los nombres cambian por proveedor y servicio. CloudTrail, Azure Activity Log y Cloud Audit Logs no son equivalentes fila por fila ni garantizan la misma cobertura. Para cada fuente se documentan eventos incluidos, cuenta o tenant, región, retención, latencia, identidad representada y campos que pueden ser proporcionados por el cliente.
Revocar una credencial comprometida limita daño, pero puede invalidar la sesión que el equipo necesita para exportar evidencia. La preparación crea roles de emergencia de solo lectura, destino de logging separado y retención protegida. Durante el incidente se registra cada consulta y respuesta, incluidos request ID y paginación; una captura de consola no sustituye la exportación original.
Un snapshot captura el estado que el servicio expone para un volumen en un momento, no RAM, hipervisor ni necesariamente consistencia de aplicación. Para cargas críticas se coordina congelación o mecanismos nativos cuando sea viable. Contenedores y funciones efímeras exigen preservar logs, configuración, imagen, digest, variables y plano de orquestación antes de que el ciclo de vida los elimine.
Una clave, rol o token no equivale automáticamente a una persona. Se siguen principal, rol asumido, sesión, cadena de federación, IP, agente, región y permisos efectivos. Después se consulta qué recursos tocó y qué cambios alteraron la visibilidad. Un evento ausente puede significar fuente deshabilitada, región equivocada, latencia o una operación no cubierta; no se convierte inmediatamente en prueba de borrado.
La integridad también debe demostrarse. En AWS, la validación de archivos de CloudTrail usa digest y firmas cuando fue habilitada; en otros casos se conservan hashes, exportación, controles del almacenamiento y trazabilidad operativa sin afirmar capacidades que el proveedor no ofrece.
Una alerta muestra creación de claves en una región poco usada. El evento identifica un rol asumido, no la credencial humana original. El analista sigue el ARN de sesión hasta el proveedor de identidad, conserva logs de autenticación y luego busca el mismo accessKeyId, principal y ventana en todas las regiones. Descubre enumeración de secretos, modificación de una política y acceso a un bucket cuyos eventos de datos sí estaban habilitados.
Antes de revocar, exporta los eventos con un rol de investigación separado y registra comandos, páginas, request ID y hashes. Después revoca la sesión, preserva la política anterior y crea snapshots de volúmenes afectados. El informe no llama al snapshot «imagen física» y deja explícito que un servicio sin data events habilitados mantiene un vacío de visibilidad.
Dominas la clase cuando diferencias control, datos e identidad; enumeras cobertura y retención por proveedor; preservas respuestas API reproducibles; explicas los límites de snapshots; y reconstruyes una cadena de sesión IAM a través de cuentas y regiones sin atribuir el principal técnico directamente a una persona.
aws cloudtrail lookup-events, snapshots EBS, herramientas como Prowler para revisar configuración.gcloud logging read.Usa tu propia cuenta de nube en nivel gratuito. Simula el "incidente" tú mismo.
bash
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=RunInstances
bash
aws cloudtrail lookup-events --lookup-attributes AttributeKey=Username,AttributeValue=usuario-prueba
bash
aws ec2 create-snapshot --volume-id vol-0123456789 --description "Evidencia CASO-2026-01"
kql
SigninLogs | where ResultType != 0 | project TimeGenerated, UserPrincipalName, IPAddress, ResultDescription
bash
gcloud logging read 'logName:"cloudaudit.googleapis.com"' --limit 50 --format json
En tu cuenta de nube, simula un compromiso de credenciales (una clave IAM que "un atacante" usa desde otra sesión) y reconstruye, solo desde los logs de la plataforma, qué hizo, cuándo y desde dónde, preservando la evidencia de forma inmutable.
Criterio de aceptación: entregas un informe con la credencial comprometida, la línea de tiempo de sus acciones (con marcas UTC), la IP de origen, los recursos afectados y la prueba de que los logs de evidencia quedaron con retención/inmutabilidad.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
| CloudTrail no tiene el evento | Trail no configurado para esa región/servicio. Habilita un trail multi-región. |
| Data Access logs vacíos en GCP | Desactivados por costo. Actívalos antes del incidente. |
| Snapshot no monta | Falta adjuntarlo a una instancia forense. Crea un volumen desde el snapshot. |
| Apagaste la instancia y perdiste RAM | Aísla por red, no por apagado, si quieres la memoria. |
| Logs alterables | Sin retención/inmutabilidad. Usa object lock o cuenta de logging separada. |
❓ ¿Qué evidencia no tengo en la nube? El hipervisor, el hardware y la red física del proveedor. Trabajas con lo que las APIs y logs exponen.
❓ ¿Cómo capturo una instancia efímera? Antes de que se destruya: snapshot del disco y, si puedes, volcado de memoria vía agente. Automatiza la captura ante alerta.
❓ ¿CloudTrail lo registra todo? Registra llamadas a la API (plano de control). Data events (S3, Lambda) y logs de aplicación requieren configuración adicional.
❓ ¿Cómo preservo logs para que no se borren? Exporta a almacenamiento con retención/immutabilidad (object lock) o a una cuenta/proyecto de logging aislado.