Por qué el peritaje cloud es diferente al forense tradicional
En un peritaje informático tradicional, el perito trabaja con hardware físico: discos duros, ordenadores, móviles. Puede clonar un disco bit a bit, calcular su hash y tener la certeza de que posee una copia exacta de la evidencia. En el peritaje cloud, esa premisa desaparece por completo. No hay acceso físico al hardware: los servidores pertenecen a AWS, Microsoft o Google y están distribuidos en centros de datos repartidos por el mundo.
El modelo de responsabilidad compartida añade complejidad. El proveedor cloud gestiona la infraestructura física y el hipervisor; el cliente controla el sistema operativo, las aplicaciones y los datos. Esto implica que un perito informático judicial necesita entender qué registros genera cada capa y quién tiene acceso a ellos. No es lo mismo peritar una instancia EC2 (donde el cliente controla el sistema operativo) que una función Lambda (donde el cliente solo controla el código).
Los recursos efímeros complican aún más la situación. Un contenedor Docker puede existir durante segundos, una función serverless se ejecuta y desaparece, un autoescalado puede destruir instancias antes de que nadie revise sus logs. En el forense tradicional la evidencia es estática; en cloud, la evidencia es dinámica y potencialmente volátil.
La buena noticia es que los proveedores cloud registran obsesivamente toda actividad a nivel de API. Cada creación de recurso, cada cambio de permisos, cada acceso a un bucket de almacenamiento queda registrado con identidad, timestamp y dirección IP de origen. El trabajo del perito cloud no es clonar discos, sino saber qué exports pedir, cómo preservarlos y cómo presentarlos ante un tribunal. La distribución multi-región de los datos obliga además a verificar en qué jurisdicción se encontraban los recursos en el momento de los hechos, un aspecto procesal que puede afectar a la competencia del juzgado.
AWS: los exports que un perito necesita
Amazon Web Services es la plataforma cloud con mayor cuota de mercado y, por tanto, la que un perito AWS encuentra con más frecuencia en procedimientos judiciales. Los exports fundamentales son:
CloudTrail — Actividad de API
Registra todas las llamadas a la API de AWS: quién hizo qué, desde qué IP, a qué hora y con qué resultado. Es la fuente de evidencia más importante en AWS. Se exporta configurando un trail hacia un bucket S3, donde los archivos JSON se entregan con firma digital y digest files que permiten verificar la integridad. El perito debe exportar todas las regiones, no solo la principal, y verificar que el trail cubra tanto eventos de gestión como eventos de datos.
VPC Flow Logs — Tráfico de red
Capturan el tráfico de red a nivel de interfaz de red (ENI): IPs de origen y destino, puertos, protocolo, bytes transferidos y si la conexión fue aceptada o rechazada. Imprescindibles para detectar exfiltración de datos o conexiones a servidores externos sospechosos. Se publican en CloudWatch Logs o S3 y pueden filtrarse por intervalo temporal.
GuardDuty Findings — Detecciones de seguridad
Si estaba activado, GuardDuty genera findings que identifican actividades sospechosas: acceso desde IPs maliciosas, uso de credenciales comprometidas, comportamiento anómalo de instancias EC2 o minería de criptomonedas. Estos findings se exportan vía API o desde la consola y aportan contexto de amenaza al análisis pericial.
S3 Access Logs e IAM Credential Reports
Los S3 Access Logs registran cada operación (GET, PUT, DELETE) sobre los objetos de un bucket, incluyendo quién la realizó y desde dónde. Los IAM Credential Reports detallan el estado de todas las credenciales de la cuenta: cuándo se usaron por última vez, si tienen MFA, qué permisos tienen. Juntos permiten reconstruir quién tenía acceso a qué datos y si ese acceso se materializó.
RDS/Aurora Audit Logs y EC2 Instance Metadata
Los logs de auditoría de bases de datos RDS y Aurora registran conexiones, consultas ejecutadas y cambios de permisos a nivel de base de datos. La metadata de instancias EC2 proporciona información sobre configuración, AMI de origen, security groups y role IAM asociado. Ambos se exportan desde CloudWatch Logs o mediante snapshots del volumen EBS para un análisis forense más profundo.
Azure: logs de auditoría y evidencia disponible
Microsoft Azure tiene su propio ecosistema de registros de auditoría. Aunque los conceptos son similares a AWS, la nomenclatura y las herramientas de exportación difieren sustancialmente.
Activity Log — Operaciones sobre recursos
El Activity Log de Azure registra todas las operaciones del plano de control: creación, modificación y eliminación de recursos, asignaciones de roles, despliegues. Se retiene 90 días por defecto. Para preservación judicial, debe exportarse a una cuenta de Storage Account o a Log Analytics Workspace antes de que expire el periodo de retención.
Azure AD / Entra ID Sign-in Logs
Registran cada intento de autenticación: usuario, aplicación, IP de origen, dispositivo, ubicación geográfica aproximada, resultado (éxito, fallo, MFA requerido) y la política de acceso condicional aplicada. Son la fuente principal para determinar quién accedió al entorno, cuándo y desde dónde. Requieren licencia Azure AD Premium para retención superior a 7 días.
NSG Flow Logs — Tráfico de red
Los Network Security Group Flow Logs capturan el tráfico de red a nivel de grupo de seguridad: IPs, puertos, protocolo, bytes y decisión (allow/deny). Se almacenan en una cuenta de Storage Account en formato JSON. La versión 2 incluye información de estado de la conexión (new, established, terminated) que facilita la reconstrucción de sesiones.
Storage Analytics, SQL Auditing y Key Vault Logs
Storage Analytics registra las operaciones sobre blobs, colas y tablas. SQL Database Auditing captura consultas, conexiones y cambios de permisos en bases de datos SQL de Azure. Key Vault Logs registran cada acceso a secretos, claves y certificados, información crítica si se investiga el uso indebido de credenciales criptográficas. Todos se centralizan a través de Diagnostic Settings hacia Log Analytics o Storage Account.
Una particularidad de Azure es que muchos logs requieren configuración explícita de Diagnostic Settings para su retención. Si no se configuraron antes del incidente, los logs pueden haberse perdido al expirar los periodos por defecto. El perito debe verificar en primer lugar la configuración de diagnósticos para saber qué datos están disponibles y cuáles no.
GCP: Cloud Audit Logs y más allá
Google Cloud Platform estructura sus logs de auditoría en categorías claramente diferenciadas, lo que facilita el trabajo del perito una vez se comprende la taxonomía.
Admin Activity Logs — Operaciones administrativas
Registran toda operación que modifica la configuración o los metadatos de un recurso: crear una VM, cambiar una política IAM, modificar un firewall. Se retienen 400 días, no pueden desactivarse ni eliminarse por el usuario y no tienen coste adicional. Son la fuente de evidencia más fiable de GCP porque su inmutabilidad está garantizada por el propio proveedor.
Data Access Logs — Acceso a datos
Registran las operaciones de lectura y escritura sobre los datos almacenados en los servicios de GCP: lectura de objetos en Cloud Storage, consultas en BigQuery, accesos a datos en Firestore. A diferencia de los Admin Activity Logs, los Data Access Logs deben habilitarse explícitamente por servicio y se retienen solo 30 días por defecto. Si no estaban habilitados, no habrá registro de quién leyó qué.
VPC Flow Logs y Cloud SQL Logs
Los VPC Flow Logs de GCP capturan el tráfico de red a nivel de subred o interfaz: IPs, puertos, bytes y latencia. Cloud SQL Logs registran las conexiones y consultas a bases de datos gestionadas (MySQL, PostgreSQL, SQL Server). Ambos se exportan desde Cloud Logging hacia BigQuery, Cloud Storage o Pub/Sub para su análisis y preservación a largo plazo.
IAM Policy Analyzer y BigQuery Audit Logs
El IAM Policy Analyzer permite consultar qué identidades tienen acceso efectivo a qué recursos, considerando herencias, grupos y condiciones. Los BigQuery Audit Logs registran cada consulta ejecutada, los datasets accedidos y los bytes procesados. En investigaciones que involucran acceso a grandes volúmenes de datos, BigQuery es frecuentemente el servicio donde se materializó la exfiltración.
Para la exportación pericial de logs de GCP, el mecanismo estándar es crear un sink en Cloud Logging que envíe los registros relevantes a un bucket de Cloud Storage con retención configurada. El perito debe calcular el hash SHA-256 de cada archivo exportado y documentar la configuración del sink para garantizar la trazabilidad desde el log original hasta la copia pericial.
Preservación de evidencia cloud: errores que destruyen la prueba
La evidencia cloud tiene una particularidad que la hace especialmente frágil: si no se preserva activamente, desaparece por diseño. En un disco duro físico, los datos borrados permanecen en el espacio no asignado hasta que se sobrescriben. En cloud, cuando un log expira o un recurso se destruye, la información se elimina de forma irrecuperable de los sistemas del proveedor.
Periodos de retención que expiran silenciosamente
CloudTrail retiene 90 días en su historial gratuito. Si el incidente ocurrió hace 4 meses y no había un trail configurado hacia S3, los eventos más antiguos ya no existen. El perito debe verificar inmediatamente la ventana temporal disponible y exportar antes de que se pierdan más datos.
Snapshots y recursos eliminados por automatización
Las lifecycle policies de S3, las reglas de limpieza de Azure y los TTL de GCP pueden destruir automáticamente snapshots, backups y versiones antiguas de objetos. Si la empresa tiene automatización de limpieza configurada, la evidencia puede estar destruyéndose mientras se debate si iniciar o no el procedimiento.
Cambios de IAM que destruyen la pista de auditoría
Si alguien elimina usuarios IAM, rota credenciales o modifica políticas de acceso después del incidente, se pierde la capacidad de vincular acciones registradas en los logs con identidades concretas. Los cambios de IAM posteriores al incidente deben congelarse hasta que el perito haya documentado el estado de permisos.
No solicitar un legal hold al proveedor
AWS, Azure y GCP ofrecen mecanismos de retención legal (Object Lock en S3, Immutable Blob Storage en Azure, Bucket Lock en GCS) que impiden la eliminación de datos incluso por administradores. No activar estos mecanismos es uno de los errores más graves en la preservación de evidencia cloud. La cadena de custodia digital comienza con la preservación activa de la fuente.
Cómo presenta un perito la evidencia cloud ante un juez
El reto más grande del peritaje cloud no es técnico sino comunicativo. Un juez necesita entender qué ocurrió en una infraestructura que nunca ha visto y cuyo funcionamiento le resulta completamente ajeno. Conceptos como «rol IAM asumido mediante STS», «política de bucket S3 con condición de IP» o «invocación asíncrona de Lambda» no significan nada para un no-técnico.
El perito informático judicial debe traducir estos conceptos a un lenguaje comprensible sin perder rigor. Por ejemplo: «El registro de auditoría demuestra que el usuario jgarcia, identificado con su correo corporativo, accedió al almacén de archivos confidenciales de la empresa el día 15 de marzo a las 23:47 desde una dirección IP que geolocaliza en Palma de Mallorca, y descargó 847 archivos en un periodo de 12 minutos.»
La representación visual es fundamental. Los patrones de acceso se presentan como diagramas temporales (timelines) que muestran la secuencia de acciones del investigado. Los flujos de red se traducen en esquemas que muestran de forma gráfica qué servidores se comunicaron con qué destinos externos y cuántos datos se transfirieron. Las relaciones entre identidades y recursos se representan como grafos de permisos que el juez puede seguir intuitivamente.
La construcción de la timeline a partir de logs de API es el pilar del informe. Cada entrada de CloudTrail, Activity Log o Audit Log lleva un timestamp preciso y una identidad vinculada. Correlacionando estas entradas, el perito construye una narrativa factual: primero el investigado cambió los permisos del bucket, después descargó los archivos, después eliminó los logs de acceso (acción que, irónicamente, queda registrada en CloudTrail).
La cadena de custodia para exports digitales de cloud se documenta con: hash SHA-256 de cada archivo exportado, captura de pantalla de la configuración de la cuenta (región, servicios activos, políticas de retención), acta de la sesión de adquisición con fecha, hora e identidad del perito que realizó la exportación, y verificación de que los digest files de CloudTrail confirman la integridad de los logs no manipulados. Todo ello constituye un informe que un juez puede valorar con confianza y que resiste cualquier escrutinio técnico en un contra-peritaje.
¿Necesitas un peritaje de infraestructura cloud?
Exporto, preservo y analizo la evidencia de AWS, Azure y GCP con rigor forense para que sea válida ante cualquier tribunal.
Preguntas frecuentes
El perito no accede por su cuenta: necesita que la empresa o el juzgado le otorguen acceso con credenciales de solo lectura (ReadOnly) a los servicios relevantes. Lo habitual es crear un rol IAM temporal con permisos mínimos (Security Audit o equivalente) que permita consultar logs y configuraciones sin modificar nada. Todo acceso queda registrado en los propios logs de auditoría del proveedor, lo que garantiza trazabilidad completa de la actuación pericial.
Varía según el servicio y la configuración. AWS CloudTrail conserva los últimos 90 días de eventos de gestión en el historial gratuito; para retención más larga hay que configurar un trail hacia S3. Azure Activity Log retiene 90 días por defecto. GCP Admin Activity Logs se conservan 400 días y los Data Access Logs 30 días. Estos periodos son por defecto: si no se configuró retención extendida antes del incidente, los logs pueden haberse purgado automáticamente.
Sí, las exportaciones de CloudTrail son válidas como prueba en procedimientos judiciales españoles, siempre que se preserven correctamente: exportación íntegra (no filtrada), cálculo de hash SHA-256 en el momento de la descarga, documentación de la cuenta, región y rango temporal exportados, y mantenimiento de la cadena de custodia. AWS además firma digitalmente los archivos de log de CloudTrail cuando se entregan a S3, lo que proporciona una capa adicional de integridad verificable.
Depende de qué logs se borraron y cómo. Los Admin Activity Logs de GCP y ciertos eventos de CloudTrail no pueden ser borrados ni desactivados por el usuario. Si se desactivó un trail de CloudTrail o se eliminaron logs de un bucket S3, esa misma acción queda registrada como evento de auditoría. El perito puede documentar la desactivación o el borrado, lo que en un procedimiento judicial puede generar presunciones desfavorables contra quien lo hizo.
Sí, aunque presenta desafíos específicos. Las funciones serverless no dejan rastro en un disco duro convencional, pero toda invocación genera logs en CloudWatch (AWS), Azure Monitor o Cloud Logging (GCP). Se pueden analizar las invocaciones, los parámetros de entrada, los errores y las conexiones a otros servicios. Lo crítico es que los logs de ejecución tengan retención suficiente, porque por defecto pueden tener periodos de expiración cortos.
No se necesitan permisos del proveedor (AWS, Microsoft, Google) sino del titular de la cuenta. El perito trabaja con los datos que la cuenta del cliente ya registra internamente. Solo en casos excepcionales —como un requerimiento judicial para obtener datos que el titular no puede proporcionar— se solicita información directamente al proveedor, habitualmente mediante comisión rogatoria internacional si los servidores están fuera de España.
El coste depende de la complejidad del entorno (número de cuentas, servicios utilizados, volumen de logs) y del alcance del análisis (un solo incidente vs. auditoría completa). Un peritaje cloud suele requerir más horas de análisis que uno de dispositivo físico porque implica múltiples fuentes de datos distribuidas. La evaluación inicial permite dimensionar el trabajo y proporcionar un presupuesto cerrado antes de empezar.
Sí, siempre que los logs adecuados estuvieran activados. CloudTrail, Azure Activity Log y GCP Audit Logs registran la identidad (usuario IAM, rol, cuenta de servicio), la acción realizada, el recurso afectado, la IP de origen y la marca temporal. Si además estaban habilitados los Data Access Logs (acceso a nivel de objeto en S3, Storage o GCS), se puede determinar con precisión quién leyó, descargó o modificó cada archivo.