Cumplimiento del RGPD en almacenamiento en la nube: mejores prácticas
Mejores prácticas para almacenamiento en la nube conforme al RGPD: cifrado, controles de acceso, ubicación de datos y criterios de evaluación de proveedores.
El almacenamiento en la nube conforme al RGPD requiere cinco controles en capas: (1) cifrado en reposo con AES-256 y en tránsito con TLS 1.3, idealmente complementado por cifrado del lado del cliente para datos sensibles; (2) un Acuerdo de Tratamiento de Datos con el proveedor que cumpla el artículo 28(3); (3) residencia de datos documentada — normalmente en la UE/EEE para datos personales europeos — con transparencia sobre los subencargados del tratamiento; (4) controles de acceso granulares con MFA, permisos basados en roles y registros de auditoría conservados durante al menos seis meses; (5) detección de brechas capaz de cumplir la ventana de notificación de 72 horas del artículo 33. Si falta alguna capa, el nivel de almacenamiento se convierte en el punto más débil de tu arquitectura de cumplimiento.
Elegir un proveedor conforme al artículo 28
El mercado europeo de ATD clasifica a los proveedores en niveles claros. Los hiperscaladores (AWS, Azure, Google Cloud) ofrecen ATD completos y regiones en la UE, pero están expuestos al Cloud Act. Los proveedores soberanos europeos (OVHcloud, Scaleway, Infomaniak, Hetzner, IONOS) evitan la jurisdicción de EE. UU. y suelen disponer de certificaciones C5, SecNumCloud o ISO 27001. Los proveedores especializados en privacidad (Tresorit, Proton Drive, Internxt, Nextcloud alojado) añaden arquitectura de conocimiento cero. Elige en función de la sensibilidad de los datos: los historiales médicos y los datos de defensa necesitan proveedores soberanos o de conocimiento cero; los archivos empresariales generales funcionan en hiperscaladores con la configuración correcta.
Cifrado en el servidor frente a cifrado del lado del cliente
El cifrado en el servidor — AWS S3 SSE-KMS, Azure Storage Service Encryption, claves gestionadas por el cliente de Google Cloud — protege contra el robo físico de discos, pero no contra los empleados del proveedor con acceso a las claves ni contra la compulsión legal del proveedor. El cifrado del lado del cliente con claves que el proveedor nunca ve (XChaCha20-Poly1305 en Tresorit, AES-256-GCM con derivación de clave PBKDF2-SHA-256 en HexaTransfer) ofrece protección de conocimiento cero. Para datos de alta sensibilidad bajo el artículo 9 (salud, biometría, opiniones políticas), el cifrado del lado del cliente es el estándar de cumplimiento por defecto; el cifrado en el servidor por sí solo es marginal.
Configurar AWS S3 para el RGPD
S3 no es conforme de serie. Para datos personales de la UE, establece la región del bucket en eu-central-1 (Frankfurt), eu-west-1 (Irlanda), eu-west-3 (París) o eu-south-1 (Milán). Activa el cifrado por defecto con SSE-KMS usando una CMK gestionada por el cliente con rotación de claves. Bloquea el acceso público a nivel de cuenta. Activa Object Lock para el almacenamiento de cumplimiento inmutable donde la retención sea legalmente obligatoria. Activa los registros de acceso de S3 y AWS CloudTrail para auditoría. Usa endpoints de VPC para que el tráfico nunca transite por Internet pública. Desactiva S3 Transfer Acceleration a menos que puedas demostrar que los cachés de borde de CloudFront permanecen en la UE.
Equivalentes de Azure y Google Cloud
Azure: elige Europa Occidental (Ámsterdam) o Europa del Norte (Dublín), activa el cifrado del servicio de almacenamiento con claves gestionadas por el cliente a través de Key Vault, configura Private Endpoints, establece Azure Policy para denegar despliegues fuera de la UE y activa Microsoft Defender para Storage. Google Cloud: elige europe-west1 (Bélgica), europe-west3 (Frankfurt) o europe-west9 (París), activa las claves de cifrado gestionadas por el cliente a través de Cloud KMS, usa VPC Service Controls para prevenir la exfiltración y activa Cloud Audit Logs. Ambos hiperscaladores publican guías de configuración específicas para el RGPD; síguelas literalmente, no improvises.
Controles de acceso en virtud del artículo 32(1)(b)
El acceso basado en roles es el punto de partida. Cada identidad — humana o de servicio — debe tener privilegios mínimos limitados a un bucket, prefijo o carpeta específicos. El MFA es obligatorio para el acceso a la consola y recomendado para las claves de API mediante tokens de sesión. Los flujos de trabajo de incorporación, cambio y salida integrados con tu proveedor de identidad (Okta, Azure AD, Google Workspace) previenen los accesos obsoletos. Las revisiones de acceso trimestrales detectan la acumulación de permisos. Para archivos muy sensibles, el acceso de emergencia con doble aprobación y expiración automática de privilegios elevados tras 4-8 horas limita el daño de las cuentas de administrador comprometidas.
Políticas de retención ajustadas a la finalidad
El artículo 5(1)(e) (limitación del plazo de conservación) te obliga a eliminar los datos cuando caduca la finalidad del tratamiento. El almacenamiento en la nube hace tentadora la retención indefinida — el almacenamiento es barato. Crea políticas de ciclo de vida que apliquen la retención vinculada a la finalidad: 30 días para las zonas de transferencia temporal, 13 meses para los archivos adjuntos de atención al cliente, 7 años para las facturas (ley fiscal), 10 años para los historiales médicos en algunas jurisdicciones. Las reglas de ciclo de vida de S3, la gestión del ciclo de vida de Azure Blob y el ciclo de vida de objetos de GCS automatizan esto. Combínalos con Object Lock para el cumplimiento WORM donde la retención sea legalmente obligatoria.
Gestión de claves de cifrado
Las claves son el centro de gravedad. Quien tiene la clave tiene los datos. Bajo el RGPD, la custodia de las claves determina si el proveedor de almacenamiento es un encargado del tratamiento (puede descifrar) o simplemente un conducto de datos (retiene texto cifrado). Usa almacenes de claves respaldados por HSM (AWS KMS, Azure Key Vault Managed HSM, Google Cloud HSM) para escenarios gestionados por el servidor. Para conocimiento cero, deriva las claves en el navegador mediante PBKDF2 o Argon2id de la Web Crypto API (crypto_pwhash de libsodium) y nunca las transmitas. Rota las claves anualmente o cuando salga personal con acceso. Documenta la custodia de claves en tu Registro de Actividades de Tratamiento bajo el artículo 30.
Cifrado y residencia de las copias de seguridad
Las copias de seguridad a menudo rompen la residencia y la cadena de cifrado. Un bucket en eu-central-1 con una regla de replicación cross-region a us-east-1 para "resiliencia" acaba de trasladar cada archivo a EE. UU. sin actualizar el ATD. Comprueba las configuraciones de CRR y establece los destinos dentro del EEE — eu-west-1 (Irlanda) y eu-central-1 (Frankfurt) hacen buen par natural. Cifra las copias de seguridad con una clave separada del almacenamiento primario para que el compromiso de una clave no revele ambas copias. Prueba la restauración trimestralmente; una copia de seguridad no restaurable es peor que ninguna copia de seguridad a efectos de recuperación ante desastres.
Detección de brechas para cumplir las 72 horas
El plazo de 72 horas del artículo 33 empieza cuando el responsable "tiene conocimiento". Las herramientas de detección acortan el intervalo entre la brecha y el conocimiento. CloudTrail + GuardDuty en AWS, Microsoft Defender for Cloud en Azure y Security Command Center Premium en GCP señalan patrones de acceso inusuales — descargas masivas, acceso desde nuevas ubicaciones geográficas, claves usadas fuera del horario laboral. Dirige las alertas a un SOC disponible 24/7 o al menos a una guardia rotativa. Para organizaciones más pequeñas, los servicios gestionados de detección y respuesta (Arctic Wolf, Red Canary) llenan ese hueco. Documenta el procedimiento: quién notifica a la autoridad de control, quién redacta el formulario del artículo 33, quién comunica a los interesados en virtud del artículo 34.
Lista de verificación para evaluar proveedores
Antes de firmar un contrato de almacenamiento en la nube, exige: (1) ATD conforme al artículo 28 que cubra los ocho asuntos; (2) certificado ISO 27001 con declaración de alcance; (3) informe SOC 2 Tipo 2 (el Tipo 1 es insuficiente — prueba el diseño, no la operación); (4) compromiso de residencia de datos en la UE con centros de datos nombrados; (5) registro de subencargados con jurisdicciones; (6) plazo de notificación de brechas publicado (≤24 horas es preferible); (7) documentación de cifrado incluyendo gestión de claves; (8) derechos de auditoría en virtud del artículo 28(3)(h). HexaTransfer publica los ocho puntos en su página de confianza; las alternativas de reputación (Tresorit, Proton, Infomaniak) hacen lo mismo.
Trata la página de confianza del proveedor como un contrato — si está ausente, el proveedor no se toma esto en serio. Pruébalo en hexatransfer.com — gratis, sin cuenta, hasta 10 GB.
Envía archivos grandes de forma segura con cifrado de extremo a extremo
Transfiere archivos de hasta 10 GB gratis con cifrado de extremo a extremo. Sin necesidad de cuenta. Tus archivos se cifran en tu navegador antes de subirlos: nadie más puede leerlos.
Enviar un archivo