Introducción
No todo el análisis forense va de terminales y volcados de memoria. Cuando la evidencia vive en la infraestructura de un tercero —un proveedor cloud— la parte técnica sigue importando, pero deja de ser lo único que decide si una investigación llega a buen puerto. Este ejercicio recoge las consideraciones legales y contractuales que hay que tener resueltas antes de que ocurra un incidente, no durante.
Qué tipo de nube y de servicio hay contratado
Antes de nada, el modelo de despliegue determina cuánto control se tiene sobre la evidencia:
- Nube pública: infraestructura compartida con otros clientes. Poco control directo — cualquier forense hay que solicitarlo al proveedor, y queda condicionado por la legislación del país donde esté el servidor.
- Nube privada: infraestructura propia. Acceso total a los datos, la opción más cara pero la más limpia a nivel forense.
- Nube híbrida: mezcla de ambas — datos sensibles en privada, el resto en pública. Genera escenarios forenses mixtos, con distinto nivel de acceso según dónde esté cada dato.
Y el modelo de servicio determina quién responde de qué:
| Modelo | Responsable de |
|---|---|
| SaaS | El proveedor gestiona contenido y datos del software |
| IaaS | El proveedor es dueño de red y almacenamiento; el cliente sigue siendo parcialmente responsable de la integridad de datos, aplicaciones y SO |
| PaaS | El cliente responde de datos y aplicaciones; no del almacenamiento, red, servidores ni SO |
A esto se suman cuatro preguntas que hay que poder responder desde el minuto cero: dónde está físicamente el servidor (determina la legislación aplicable — en la UE, el RGPD se aplica igual aunque el proveedor sea extranjero), qué normativa rige (RGPD, Directiva NIS, o leyes de terceros países como la CLOUD Act de EEUU), si contractualmente está garantizado el acceso a datos y logs en caso de incidente, y si la evidencia resultante sería admisible en la jurisdicción correspondiente.
Investigar un entorno subcontratado
Frente a un forense tradicional, lo que más cambia no es la parte técnica sino la logística y la legal — sobre todo en la fase de adquisición:
- Propiedad del dato: en una nube pública, la empresa afectada puede no ser la única propietaria de los datos ni de la infraestructura donde viven.
- Solicitud de acceso al proveedor: sujeta a sus políticas internas y a la legislación de su país — puede llevar tiempo que en un incidente real no siempre se tiene.
- Jurisdicción: si el dato está en un país distinto, puede no ser admisible en juicio sin verificar antes qué legislación aplica.
- Riesgo de manipulación: al no controlar la infraestructura en solitario, no se puede garantizar que terceros (el propio proveedor, gobiernos, otros clientes del mismo entorno compartido) no hayan tocado los datos antes de poder extraerlos.
- Elasticidad y volatilidad: las propias características de la nube (recursos que se crean y destruyen, abstracción, recursos compartidos) hacen que la evidencia sea más volátil que en un entorno local.
La conclusión práctica: antes de empezar cualquier forense en cloud hay que tener identificado el tipo de servicio, el proveedor, la localización física del servidor y la legislación vigente — sin eso, la extracción de evidencias corre el riesgo de no valer nada en un juicio.
De quién es la responsabilidad según el RGPD
Contratar cloud no traslada la responsabilidad legal — la reparte, y de forma desigual según el modelo:
- IaaS: el cliente es parcialmente responsable de la integridad de datos, aplicaciones y sistema operativo, aunque el proveedor sea dueño de la red y el almacenamiento.
- PaaS: el cliente responde de los datos y las aplicaciones que corren en la plataforma.
- SaaS: aunque el proveedor gestiona el software, el cliente sigue siendo el responsable del tratamiento de los datos personales de sus usuarios ante la ley.
De forma general, el cliente siempre tiene que: garantizar que el tratamiento cumple el RGPD sin importar dónde estén los datos, firmar un contrato de encargado del tratamiento (DPA) con el proveedor, notificar cualquier brecha a la autoridad competente en un máximo de 72 horas (Art. 33 RGPD), y no transferir datos fuera de la UE sin garantías adecuadas (cláusulas contractuales tipo o una decisión de adecuación).
Proveedor transparente vs. proveedor opaco
Un proveedor transparente da visibilidad real: localización física de los servidores, acceso a logs y auditorías, telemetría (AWS CloudTrail y similares) que permite saber cómo, cuándo y desde dónde se accede a los datos, procedimientos claros de cooperación forense, y cumplimiento demostrable de RGPD/NIS.
Un proveedor opaco deja al cliente sin ninguna de esas cosas, y las consecuencias son concretas: sin acceso directo a logs ni infraestructura no hay forma de reunir evidencias en un incidente; sin eso tampoco se puede garantizar la integridad de lo poco que se consiga (lo que las invalida en juicio); y sin visibilidad, el cliente no puede demostrar que tiene control sobre el tratamiento — un incumplimiento del propio RGPD que se traduce en mayor exposición legal y económica ante cualquier brecha.
Recuperar los datos: portabilidad y Art. 20 RGPD
Antes de firmar, el contrato tiene que dejar claro en qué formato se entregarán los datos si hace falta recuperarlos, con qué plazos máximos, y qué pasa con ellos si se rescinde el contrato (deben devolverse y eliminarse de los sistemas del proveedor). No conviene depender solo del proveedor — hacer copias de seguridad propias periódicas es la red de seguridad real.
Si los datos son personales, entra en juego el Artículo 20 del RGPD: el interesado tiene derecho a recibirlos en un formato estructurado, de uso común y lectura mecánica, y puede pedir que se transmitan directamente a otro responsable cuando sea técnicamente posible — pero solo aplica cuando el tratamiento se basa en consentimiento o contrato y se hace por medios automatizados.
Qué garantías exigir antes de firmar
Para que un forense en cloud sea siquiera viable, el contrato debería incluir: localización clara de los datos, acceso garantizado a logs e infraestructura, cláusulas de cooperación en investigaciones con plazos concretos, un SLA con tiempos de respuesta ante solicitudes de acceso, cumplimiento normativo demostrable, herramientas de telemetría y auditoría (CloudTrail, Cellebrite UFED Cloud Analyzer y similares), garantías de integridad verificables (hashes, registros) y, siempre que se traten datos personales, el DPA correspondiente.
¿Puede el proveedor ser “el responsable de mis datos”?
Aquí el RGPD es tajante y no admite negociación contractual: existen dos roles, el responsable del tratamiento (quien decide para qué y cómo se tratan los datos — normalmente la empresa que contrata el servicio) y el encargado del tratamiento (quien trata los datos siguiendo instrucciones ajenas — el proveedor cloud).
En la práctica, el proveedor siempre actúa como encargado, nunca como responsable — y esto no es una elección contractual, lo determina la propia naturaleza de la actividad. Lo que sí se puede y se debe hacer es firmar un DPA que obligue al proveedor a garantizar confidencialidad, aplicar medidas de seguridad adecuadas, no subcontratar sin autorización, y cooperar con el responsable ante solicitudes de los interesados. Pero la responsabilidad final ante la ley se queda siempre en la empresa cliente — no se puede subcontratar.
Conclusión
El hilo que conecta todo este bloque es el mismo: en cloud, la parte forense se juega antes del incidente, no durante. Para cuando hace falta el acceso a un log o una evidencia, ya es tarde para negociar el contrato — el momento de exigir transparencia, garantías de integridad y cláusulas de cooperación es al firmar, no cuando algo ya ha ido mal.