¿Cuántas copias de seguridad contienen datos personales sin cifrar, accesibles desde un bucket público o un Google Drive compartido? Una copia de seguridad mal configurada puede convertir una medida de protección en un incidente sancionable: pérdida de control sobre datos, notificaciones de brecha y multas. Conviene ejecutar comprobaciones prácticas y pasos operativos aplicables de inmediato para reducir el riesgo legal y operativo.
Errores al configurar copias de seguridad automáticas que rompen GDPR: Muchas empresas configuran backups automáticos sin revisar retención, cifrado o acuerdos con el proveedor, lo que puede vulnerar el RGPD. A continuación se indican cómo identificar y corregir errores concretos: cifrado en repositorios, exclusión o anonimización de datos personales, cláusulas DPA, rotación de claves y procedimientos de supresión segura, más tests de restauración y checklist de retención.
Índice
Anuncio
Resumen del proceso
El proceso reduce riesgo legal y operativo aplicando inventario, cifrado, retención y supresión verificable.
- Auditar destinos y detener copias inseguras.
- Clasificar qué contiene cada backup y localizar PII.
- Configurar cifrado con gestión separada de claves.
- Aplicar reglas de retención y supresión automatizada.
- Probar restores y documentar pruebas.
Paso 1: inventario y clasificación
Hacer un inventario rápido localiza riesgos y límites de acción en menos de 2 horas.
Listar destinos y trabajos programados
Identificar todos los destinos remotos y jobs cron activos.
Usar comandos: "wp cron event list" y revisar plugins de backup en el panel.
Registrar destinos típicos: buckets S3, Google Drive, FTP, servidores del hosting.
Ver qué incluye cada backup
Sacar un dump de prueba para ver contenido real.
Comandos claros: "wp db export dump.sql" y "ls -lh wp-content/uploads".
Verificar si el dump contiene correos, nombres o NIFs.
Detectar PII automáticamente
Escanear dumps con expresiones regulares para correos y NIF/CIF.
Ejemplo de pipeline: "rg -n "[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+.[A-Za-z]{2,}" dump.sql".
Si se detecta PII, marcar backup como "contiene datos personales" y aislarlo.
Anuncio
Paso 2: reconfigurar plugins y repositorios
Reconfigurar el flujo de copia reduce exposición cuando se aplica cifrado y roles mínimos.
Plugins: ajustes seguros por plugin
UpdraftPlus: usar backend S3/GCS con IAM roles.
En la UI activar "Encrypt backups" y evitar cuentas Drive personales.
Jetpack/VaultPress: confirmar cláusula DPA con Automattic y región de almacenaje.
Evitar buckets públicos y keys en código
Comprobar políticas de bucket y ACLs para eliminar acceso público.
Evitar claves en wp-config.php; usar variables de entorno o secretos.
Es habitual encontrar claves AWS en wp-config.php tras migraciones automatizadas.
Configurar S3 con KMS: pasos breves
Crear bucket en región EU (Irlanda o Frankfurt) y activar SSE-KMS.
Asignar key policy limitada a roles necesarios y habilitar rotación anual.
Ejemplo AWS CLI: "aws s3api put-bucket-encryption --bucket mi-bucket --server-side-encryption-configuration file://sse.json".
Además de verificar que el proveedor ofrece un DPA, conviene incorporar cláusulas contractuales concretas que recojan obligaciones operativas: por ejemplo, obligación de actuar como encargado (data processor) solo según instrucciones documentadas del responsable; obligación de permitir auditorías técnicas y de acceso; obligación de entregar prueba de eliminación (logs, request IDs) en un plazo concreto; y compromiso sobre subprocesadores. Un ejemplo sintético de cláusula que puede incluirse en el contrato: "El encargado garantiza que los backups que contengan datos personales serán eliminados, incluidas todas las versiones y réplicas, en un plazo máximo de 30 días tras la solicitud del responsable; facilitará logs de API y un certificado de destrucción resultante de las operaciones efectuadas".
Incluir estas obligaciones en el DPA facilita respuestas a peticiones de supresión y da base contractual para medidas correctoras.
Paso 3: pseudonimización, exclusión y supresión
No incluir PII en backups destinados a terceros es la mejor práctica real y legal.
Excluir tablas y archivos sensibles
Evitar incluir tablas de logs y aquellas con metadatos de usuarios.
Usar WP-CLI para exportar solo tablas necesarias: "wp db export --add-drop-table --tables=wp_posts,wp_options dump.sql".
Pseudonimizar antes del upload
Reemplazar correos por hashes o valores "redacted" antes de subir.
Comando "perl -pe 's/([A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+.[A-Za-z]{2,})/[email protected]/g' dump.sql > dump_sanitized.sql".
Procedimiento de supresión verificable
Localizar objetos relacionados y solicitar borrado con logs.
Pedir al proveedor prueba de destrucción o usar versionado de objetos con eliminación completa.
Un caso habitual: backup subido a Drive personal → imposible localizar versiones antiguas sin intervención del usuario que subió el archivo.
Para cumplir el derecho al olvido es imprescindible un procedimiento operativo reproducible: localizar backups que contengan el identificador (por ejemplo, email o ID cliente), identificar objetos y version-IDs en el bucket, marcar los objetos para eliminación y ejecutar la reversión o eliminación con pruebas. En AWS S3 esto puede implicar listar versiones (aws s3api list-object-versions --bucket mi-bucket --prefix ruta/) y eliminar por versión (aws s3api delete-object --bucket mi-bucket --key ruta/archivo.sql --version-id
Si el proveedor solo ofrece retención y no eliminación inmediata, documentar la respuesta, exigir cronograma y, como medida técnica, aplicar eliminación cifrada (rotación o destrucción de la clave de cifrado para provocar borrado criptográfico) cuando proceda, siempre complementado con evidencias exportadas del proveedor y entradas en el registro de actividades del tratamiento.
Gestión de cifrado y rotación de claves
Separar la gestión de claves del almacenamiento reduce el riesgo de exposición por co-localización.
Modelos de claves y recomendaciones
Preferir claves gestionadas por el cliente (BYOK) cuando sea posible.
Si se usa KMS, activar rotación anual y limitar permisos por roles.
La mayoría de guías afirma que cifrar basta; lo que omiten es rotar claves y auditar accesos.
Almacenamiento seguro de secretos
No guardar secretos en repositorios públicos ni en wp-config.php.
Usar soluciones como HashiCorp Vault, AWS Secrets Manager o parámetros de entorno con permisos restringidos.
Habilitar registros de acceso a claves con CloudTrail o equivalente.
La rotación de claves en entornos con backups automatizados requiere un flujo claro:
- definir si se usa envelope encryption (claves de datos cifradas por una CMK/KMS) y decidir si se re-encriptan objetos históricos o se confía en el control de acceso al CMK. Nota técnica: rotar una CMK de KMS no re-encripta automáticamente las claves de datos que ya están en los objetos
- KMS seguirá siendo capaz de descifrarlos si conserva permisos. Si el objetivo es invalidar accesos antiguos, hay que re-encriptar objetos (copiar el objeto y forzar SSE-KMS con la nueva key) o destruir las claves antiguas y asegurarse de que no hay copias de las claves de datos en ubicaciones accesibles. Un ejemplo operativo para S3: copiar el objeto sobre sí mismo con la nueva key (aws s3 cp s3://mi-bucket/obj s3://mi-bucket/obj --metadata-directive REPLACE --sse aws:kms --sse-kms-key-id
) y verificar que las nuevas versiones usan la nueva key - automatizar este proceso en pipelines para backups antiguos y documentar cada re-encriptación en el registro de cambios
Anuncio
Supresión y retención automatizada
Definir periodos de retención en función del tipo de datos y justificar cada periodo.
Políticas prácticas de retención
Ejemplo de mapeo:
- logs 30 días
- copias con PII 90 días
- backups de dev 7 días
Registrar la justificación documental para cada periodo en el registro de actividades.
Implementar lifecycle rules en cloud
Crear reglas que expiren objetos tras X días y que eliminen versiones antiguas.
Ejemplo JSON de regla de expiración aplicable a S3 y GCS en el artículo final.
Flujo de corrección de backups
Listar destinos y contenido; detectar PII.
Pausar jobs inseguros y limitar acceso.
Cifrar con KMS, excluir/anonimizar PII.
Probar restores y supresión; conservar logs.
Tabla comparativa de proveedores
| Proveedor | Ubicación de datacenters | DPA disponible | Cifrado por defecto |
|---|---|---|---|
| Amazon S3 (AWS) | Regiones EU (Irlanda, Frankfurt) | Sí, DPA estándar AWS | SSE-S3 y SSE-KMS |
| Google Drive / GCS | Regiones EU y global | Sí, DPA Google Cloud | Cifrado en reposo; claves gestionadas |
| Microsoft Azure | Regiones EU | Sí, DPA Microsoft | SSE y Azure Key Vault |
| Google Drive personal | Indefinido, depende del usuario | No aplicable | Cifrado en tránsito y en reposo gestionado por Google; el usuario no controla las claves por defecto. Google Drive cifra los datos en reposo y en tránsito, pero en el caso de cuentas personales el control de las claves recae en el proveedor (no BYOK), por lo que no existe gestión de claves por parte del responsable y no se pueden exigir las mismas garantías técnicas que con un KMS gestionado por el cliente. |
Para referencias legales, consultar la guía de la AEPD sobre copias de seguridad y transferencias internacionales.
Anuncio
Errores que arruinan el resultado
Los errores repetidos son negligencia operativa y contractual con impacto legal inmediato.
Subir backups sin DPA ni cifrado
Subir a un proveedor sin DPA aumenta riesgo de transferencia internacional ilícita.
Si los datos se transfieren fuera del Espacio Económico Europeo debe existir una base jurídica adecuada (decisión de adecuación, cláusulas contractuales tipo/SCCs con medidas complementarias, o, en casos muy concretos y documentados, consentimiento explícito). Además, tras la doctrina Schrems II las SCC pueden requerir medidas suplementarias técnicas u organizativas para garantizar un nivel de protección esencialmente equivalente, por lo que la elección del mecanismo debe ir acompañada de una evaluación de riesgos y de las medidas complementarias aplicadas.
Retención indefinida y versiones
Mantener retenciones largas multiplica la superficie de riesgo.
La política por defecto de muchos plugins guarda copias meses o años.
Esto funciona bien en teoría, pero en la práctica la retención larga impide cumplir el derecho al olvido.
No probar restores ni supresión
Los restores no probados pueden revelar que los procedimientos de supresión no funcionan.
Un proveedor puede tardar semanas en eliminar versiones si no hay cláusula DPA específica.
Cuándo no funciona este método y alternativas
Si la auditoría detectó una brecha, pausar las sincronizaciones y documentar la exposición.
Alternativa: usar backups locales cifrados y replicar solo metadatos a la nube.
Si la auditoría exige correcciones inmediatas, solicitar una revisión técnica y legal urgente y negociar la DPA con el proveedor para acelerar la remediación.
Preguntas frecuentes
¿Me conviene usar backups automáticos en la nube?
Sí, con condiciones contractuales y técnicas claras.
La nube aporta redundancia y recuperación rápida, pero solo si existe un DPA firmado, cifrado en reposo y en tránsito, y control de claves. Se debe justificar la necesidad y limitar la retención. Sin esas garantías, la nube puede convertir copias inofensivas en riesgos legales.
¿Plugins de backup cumplen el RGPD por sí mismos?
No, un plugin no garantiza cumplimiento legal.
El plugin facilita la copia técnica, pero el responsable debe configurar backend seguro, gestión de claves y políticas de retención. Además, se necesita DPA con el proveedor de almacenamiento para que haya garantías contractuales frente a solicitudes de supresión.
¿Qué retención debo aplicar para cumplir el RGPD?
Aplicar retenciones justificadas según el tipo de dato.
Una regla práctica: logs 30 días, datos personales operativos 90 días, entornos de desarrollo 7 días. Registrar la justificación en el registro de actividades. Ajustar los plazos según obligaciones legales o necesidades comerciales concretas.
¿Basta cifrar backups para estar conforme?
No basta si las claves están junto a los datos.
El cifrado exige separación de claves, rotación y registros de acceso. Si la clave se guarda en el mismo bucket o en el servidor sin controles, el cifrado no protege frente a acceso indebido. Usar KMS o soluciones BYOK para mayor control.
¿Cómo demostrar que se ha suprimido un dato de un backup?
Solicitar prueba de eliminación y conservar logs de la acción.
El procedimiento operativo debe localizar identificadores, eliminar objetos/versiones y generar evidencia: logs de API, confirmación del proveedor y captura de estado posterior. Incluir esta prueba en la respuesta al interesado que ejerce el derecho al olvido.
¿Qué hacer si el proveedor se niega a borrar?
Documentar la negativa y activar alternativas legales.
Si el proveedor no ofrece supresión verificable, es necesario buscar remedios contractuales, elevar la reclamación al DPO o AEPD y considerar migrar a un proveedor que acepte DPA con cláusula de supresión. Mantener evidencias y comunicaciones.
¿Cómo probar que el restore no reintroduce datos?
Hacer restores en entorno aislado y verificar datos con scripts.
Programar pruebas periódicas: restaurar backup en entorno de staging, ejecutar búsquedas de identificadores y confirmar que los datos supuestamente eliminados no aparecen. Conservar resultados de la prueba y timestamps.
Anuncio
Fuentes y cierre
La obligación de notificar brechas aparece en el Reglamento (UE) 2016/679 y exige acción en 72 horas.
La AEPD y ENISA han publicado directrices útiles sobre copias de seguridad y gestión de incidentes, respectivamente.
- Tu backup puede exponerte a multas por el RGPD
- Tus backups normales pueden exponer datos de WordPress
Josu Barrios
Somos especialistas en mantenimiento WordPress para empresas, profesionales y tiendas online. Contamos con experiencia en seguridad web, optimización de rendimiento, actualizaciones, copias de seguridad y resolución de incidencias técnicas, ayudando a que cada sitio funcione de forma rápida, estable y protegida. Nuestro enfoque combina soporte técnico profesional, buenas prácticas de seguridad y seguimiento continuo para ofrecer un servicio fiable, transparente y orientado a resultados reales.