Backups cifrados WordPress: guía AES-256 2026

Si administrás un WordPress con datos sensibles —clientes, pagos, historiales médicos— y tus backups viajan sin cifrado a un Google Drive compartido, tengo malas noticias: estás a una filtración de distancia de un quilombo legal y económico. Los backups cifrados en WordPress dejaron de ser un lujo corporativo en 2026 para convertirse en la única estrategia que separa un contratiempo recuperable de un desastre del que no volvés. Y la buena noticia es que implementarlo hoy lleva menos de una hora.

El cifrado AES-256 aplicado a copias de seguridad de WordPress es un mecanismo que transforma los datos del backup en texto ilegible sin una clave, protegiéndolos tanto durante la transferencia al almacenamiento externo como en repositorios off-site. Herramientas como Duplicator Pro, NAKIVO Backup & Replication y servicios cloud como AWS Backup ya integran este tipo de cifrado en origen, tránsito y destino, permitiendo que cualquier administrador —no hace falta ser ingeniero en seguridad— pueda blindar las copias contra accesos no autorizados y ataques de ransomware.

¿Por qué es necesario cifrar los backups de WordPress?

Ponele que tenés una tienda WooCommerce con 3.000 clientes, direcciones, teléfonos, historial de compras. Todos los días a las 3 AM un plugin larga un backup comprimido a una carpeta de Google Drive. Ese .zip está ahí, sin contraseña, sin cifrado, compartido con un link que algún ex empleado todavía tiene guardado en su historial de Chrome. ¿Sabés cuánto tarda un atacante en encontrar ese archivo si compromete la cuenta de Google? Menos de lo que tardás en tomar un café.

Según datos de 2025 recopilados por Windows Noticias, se registran más de 90.000 intentos de ataque por minuto contra sitios WordPress. El ransomware no pide permiso: si un backup está en texto plano, el atacante lo secuestra, lo cifra él mismo y te pide rescate doble —por el sitio y por la copia que supuestamente iba a salvarte—. Según el RGPD vigente a junio de 2026, las multas por filtración arrancan en €20 millones o el 4% de la facturación anual, lo que sea mayor. Con eso solo ya debería alcanzar para que el cifrado deje de ser opcional.

El hardening de WordPress en 2026, como detalla Seguridad en WordPress, incluye el cifrado de backups entre los 15 pasos fundamentales para blindar una instalación. No es un extra: es parte del perímetro de seguridad básico.

¿Qué tipos de cifrado existen para backups y cuál elegir?

Acá la cosa se divide en dos grandes ramas: cifrado simétrico y asimétrico. El simétrico usa la misma clave para cifrar y descifrar —rápido, eficiente, ideal para grandes volúmenes de datos—. El asimétrico usa un par de claves pública/privada —más seguro en teoría, más lento en la práctica—. Para backups de WordPress, la respuesta es casi siempre AES-256, que es cifrado simétrico con una longitud de clave de 256 bits.

¿Por qué AES-256? Porque es el estándar que usa el gobierno de EE.UU. para información clasificada, porque todos los proveedores serios lo implementan y porque romperlo por fuerza bruta tomaría más tiempo del que le queda al universo. No es teoría: NAKIVO Backup & Replication incorpora AES-256 en todos sus flujos, y Duplicator Pro cifra las copias de WordPress con ese mismo algoritmo desde origen, antes de que los datos salgan del servidor.

El punto es que no alcanza con «usar AES-256» así en abstracto. Lo que importa es dónde se aplica ese cifrado. Y ahí entran los tres niveles que nadie te explica cuando recién arrancás. Lo explicamos a fondo en comparativa de detección de malware.

¿Cuáles son los niveles de cifrado recomendados: origen, tránsito y repositorio?

Si alguna vez configuraste un sitio en WordPress desde cero, sabés que el backup típico hace esto: empaqueta archivos y base de datos, los comprime, y los manda por FTP/SFTP a algún lado. El problema es que en cada etapa de ese recorrido los datos pueden estar expuestos si no cifrás en los tres frentes.

• Cifrado en origen: los datos se cifran antes de salir del servidor WordPress. Esto significa que ni siquiera durante la generación del archivo de backup queda un rastro en texto plano. Duplicator Pro hace exactamente esto: el .zip que genera ya viaja cifrado con AES-256, no es que lo cifra después de crearlo.
• Cifrado en tránsito: es el TLS/SSL que protege la transferencia entre tu servidor y el destino. Si usás SFTP o HTTPS para mandar el backup a AWS S3 o Google Drive, ya estás cifrando en tránsito. Pero ojo: esto solo protege el viaje, no el archivo en destino.
• Cifrado en repositorio: el archivo queda almacenado cifrado en el destino final. Acá entran servicios como AWS Backup —que aplica su propio cifrado independiente del recurso original usando AWS KMS— y Azure Backup, que soporta claves administradas por el cliente (CMK) en Azure Key Vault. NAKIVO permite encadenar los tres niveles en un solo flujo.

La pregunta es: ¿alcanza con cifrar solo en repositorio? No. Porque si el archivo se genera en texto plano en tu servidor y un atacante tiene acceso al filesystem, lo copia antes de que el cifrado del bucket de AWS haga lo suyo. El cifrado en origen es el que cierra la cadena completa.

¿Cómo gestionar las claves de cifrado de forma segura?

Este es el punto donde la mayoría se manda una cagada monumental: configuran cifrado AES-256, todo hermoso, y después guardan la clave en el wp-config.php. O en un .txt en el escritorio. O —esto lo vi más veces de las que quisiera— en un post-it pegado al monitor.

Tenés dos modelos para gestionar claves. El primero es PMK (Platform Managed Key): el proveedor cloud genera, almacena y rota las claves por vos. Cómodo, pero vos no controlás nada. El segundo es CMK (Customer Managed Key): vos generás las claves, vos decidís cuándo rotarlas, vos las almacenás en un servicio como Azure Key Vault o AWS KMS. La comodidad baja, el control sube. Para un WordPress que maneja datos sensibles —clientes, pagos, información médica— CMK es el camino, aunque duela un poco más configurarlo.

Reglas de oro según las guías de hardening vigentes en 2026: rotar claves cada 90 días como mínimo, no compartir claves entre entornos (desarrollo y producción usan claves distintas, siempre), y nunca, nunca almacenar la clave en el mismo repositorio donde está el backup (sí, hay gente que lo hace). Relacionado: protección avanzada para plugins.

¿Qué herramientas de backup cifrado funcionan con WordPress?

No todas las soluciones de backup cifrado son iguales, ni todas están pensadas para WordPress. Algunas son excesivas para un sitio chico —pagar USD 200 por licencia para proteger un blog personal es un sinsentido— y otras se quedan cortas para una instalación compleja con múltiples subsitios. Acá va lo que hay en 2026, con nombre, apellido y caso de uso.

Duplicator Pro: la opción nativa para WordPress

Duplicator Pro cifra backups con AES-256 en origen, los almacena en destinos off-site —Google Drive, AWS S3, Dropbox, FTP externo— y permite restaurar con un solo clic desde el panel de WordPress. La programación automática deja configurar backups cada 6, 12 o 24 horas según el tráfico del sitio. Para quien administra varios sitios, el versionado de 14 a 30 copias evita que un backup corrupto te deje sin red. Es la opción más directa si vivís dentro del ecosistema WordPress y no querés lidiar con infraestructura externa.

NAKIVO Backup & Replication: para setups híbridos

NAKIVO no es exclusivo de WordPress —protege VMs, bases de datos, servidores físicos— pero si tu WordPress corre sobre una VM en un entorno más corporativo, entra como anillo al dedo. Cifrado AES-256 en origen, tránsito y repositorio, con integración directa a Azure Key Vault y AWS KMS para gestión de claves. La contra es que no es un plugin que instalás desde el repositorio de WordPress: requiere su propia instalación y tiene curva de aprendizaje.

AWS Backup y Azure Backup: cifrado cloud nativo

Si tu WordPress ya está montado sobre infraestructura AWS o Azure, usar los servicios de backup nativos tiene sentido. AWS Backup cifra independientemente del recurso original usando KMS con claves que vos podés gestionar. Azure Backup soporta CMK en Azure Key Vault y aplica cifrado AES-256 por defecto. La ventaja: cero configuración adicional de plugins, todo se maneja desde la consola cloud. La desventaja: si tu WordPress está en un hosting compartido que no te da acceso a la capa de infraestructura, olvidate. Para esos casos, si estás en Argentina o la región, un hosting como donweb.com te da acceso a backups desde el panel de control sin necesidad de tocar la nube.

¿Cómo programar backups automáticos y almacenarlos off-site?

De nada sirve tener el mejor cifrado del mundo si los backups corren cuando alguien se acuerda de dispararlos manualmente. La automatización es la diferencia entre volver a la versión de ayer y volver a la versión de hace tres meses —que en internet es una eternidad—.

La frecuencia depende del ritmo de cambios del sitio. Para una tienda WooCommerce con transacciones diarias, backups cada 6 horas es lo recomendado. Para un blog con publicaciones semanales, un backup diario sobra. Lo que no podés hacer es programar el backup y olvidarte: configurá un Activity Log que monitoree cambios en la base de datos y gatille backups incrementales cuando detecte actividad anómala. Duplicator Pro tiene ganchos para esto, y combinado con un plugin como WP Activity Log podés cerrar el circuito sin tocar una línea de código. Ya lo cubrimos antes en análisis de seguridad para 2026.

El almacenamiento off-site es no negociable. La regla 3-2-1 sigue vigente en 2026: tres copias, en dos medios distintos, una fuera del sitio. Google Drive, AWS S3, un FTP externo con SFTP —lo que sea, pero que no esté en el mismo servidor que el WordPress—. El versionado también importa: entre 14 y 30 versiones según espacio disponible, así podés retroceder si un backup reciente ya estaba contaminado cuando lo generaste (el ransomware duerme a veces semanas antes de activarse).

¿El cifrado de backups te protege del ransomware?

Respuesta corta: sí, pero no solo. Respuesta larga: el cifrado evita que el atacante lea tus backups, pero no evita que los borre, los sobrescriba o los cifre él mismo con su propia clave si tiene acceso de escritura al repositorio. Por eso el cifrado sin control de acceso es como ponerle candado a una puerta que dejás abierta.

La protección real contra ransomware combina: cifrado en los tres niveles (origen, tránsito, repositorio), almacenamiento off-site con permisos de solo escritura desde el servidor WordPress (que el servidor pueda subir backups pero no modificar ni borrar los existentes), y versionado con retención mínima de 14 días. Si el ransomware duerme dos semanas antes de ejecutarse, tus backups más viejos están limpios y fuera de su alcance. ¿Alguien verificó esto de forma independiente? La mayoría de los fabricantes de soluciones de backup publican sus propios benchmarks de protección anti-ransomware —tomalo con pinzas— pero el consenso de la industria en 2026 es que el combo cifrado + inmutabilidad + off-site baja el riesgo a niveles aceptables para la mayoría de los negocios.

Errores comunes al cifrar backups de WordPress

Cifrar y nunca probar la restauración

Lo veo todo el tiempo: backups cifrados que se generan religiosamente todas las noches, pero nadie jamás probó restaurar uno. Cuando llega el desastre, la clave no funciona, el archivo está corrupto o la restauración falla a medio camino porque cambió la versión de PHP. Probá la restauración al menos una vez por mes en un entorno de staging. No toma más de 20 minutos y te ahorra la sensación de estómago revuelto cuando todo depende de ese backup y no sabés si sirve.

Usar la misma clave para todo

La misma clave AES para cinco sitios distintos, el mismo bucket de AWS, el mismo login. Si un sitio se compromete y la clave vuela, volaron todos. Cada sitio tiene que tener su propia clave, y rotarla cada 90 días. ¿Da paja? Sí. Pero menos paja que explicarle a cinco clientes que perdiste los datos de todos por ahorrarte una hora de configuración. Sobre eso hablamos en diferencias entre firewalls y microsegmentación.

Dejar los backups cifrados en el mismo servidor

El backup está cifrado con AES-256, impecable. Pero está en /wp-content/backups/, accesible vía web si el directory listing está habilitado o si adivinaron la URL. El cifrado protege el contenido, pero no la disponibilidad del archivo. Un atacante lo borra y listo —no necesita leerlo para hacer daño—. Off-site, siempre off-site. El cifrado es una capa, no un permiso para aflojar con el resto.

Confiar ciegamente en el cifrado del proveedor cloud

AWS, Azure y Google Cloud cifran por defecto en repositorio, sí. Pero con claves que ellos administran (PMK). Si querés control real, configurá CMK. Si el proveedor recibe una orden judicial para entregar tus datos, con PMK ellos pueden descifrarlos. Con CMK, la clave la tenés vos —y la responsabilidad de no perderla también—.

Preguntas Frecuentes

¿Cómo cifrar las copias de seguridad de WordPress?

Usando un plugin como Duplicator Pro que aplica cifrado AES-256 en origen antes de que el archivo salga del servidor, o configurando una herramienta como NAKIVO Backup & Replication si estás en un entorno con VMs. En ambos casos, el cifrado se configura desde el panel de administración sin necesidad de código.

¿Qué es el cifrado AES-256 y cómo se aplica a backups?

AES-256 (Advanced Encryption Standard con clave de 256 bits) es un algoritmo de cifrado simétrico que transforma los datos del backup en texto cifrado ilegible sin la clave correcta. Se aplica en backups de WordPress mediante plugins o servicios cloud que incorporan este algoritmo en el flujo de generación y almacenamiento de las copias.

¿Dónde almacenar backups cifrados fuera del sitio?

Google Drive, AWS S3, Azure Blob Storage, Dropbox o un servidor FTP externo con SFTP. La clave es que el destino esté físicamente separado del servidor que aloja WordPress y que tenga permisos de escritura restrictivos para evitar que un atacante que comprometa el sitio pueda borrar los backups.

¿Cada cuánto probar la restauración de un backup cifrado?

Una vez por mes como mínimo, en un entorno de staging. Probar la restauración verifica que la clave funciona, que el archivo no está corrupto y que el proceso completo de recuperación es viable. Una restauración no probada no es un backup —es una esperanza—.

¿El cifrado de backups me protege del ransomware?

Parcialmente. El cifrado evita que el atacante lea los datos, pero no impide que los borre o los vuelva a cifrar si tiene acceso de escritura al repositorio. Para protección completa, combiná cifrado con almacenamiento off-site de solo escritura y versionado de al menos 14 días.

Conclusión

El cifrado de backups en WordPress en 2026 ya no es un debate técnico entre administradores de sistemas —es una obligación legal, práctica y de sentido común—. Con AES-256 como estándar, herramientas como Duplicator Pro para el ecosistema WordPress y servicios cloud como NAKIVO, AWS Backup o Azure Backup para entornos más complejos, implementar cifrado en origen, tránsito y repositorio se resolvió técnicamente hace rato. Lo que falta es que deje de ser ese ítem que todos marcan como «pendiente» en el plan de hardening.

Tres cosas para hacer apenas termines de leer esto: revisá si tus backups actuales viajan cifrados desde origen (no solo en tránsito), programá una restauración de prueba para el viernes, y asegurate de que las claves estén almacenadas fuera del servidor WordPress. El backup cifrado no es el backup que hiciste —es el backup que ya probaste que funciona—.

Fuentes

• Windows Noticias – Backups cifrados: estrategias prácticas y herramientas recomendadas
• Seguridad en WordPress – Hardening WordPress 2026: 15 pasos
• Duplicator – Cómo proteger una base de datos de WordPress