Un backup no auditable puede invalidar una certificación PCI‑DSS y dejar la tienda offline tras una incidencia. Responsables técnicos de PYMEs con WordPress suelen subestimar controles en hosting compartido o cloud: cifrado de reposo y tránsito, gestión de accesos, registro de operaciones y pruebas de restauración frecuentemente faltan o no quedan documentados.
Backups con cumplimiento PCI-DSS: factores decisivos
La decisión principal es si el servidor guarda CHD*; si guarda CHD, los controles PCI aplican en su totalidad. En entornos donde la pasarela no deja PAN en el servidor (tokenización o redirección), bastan controles del proveedor y evidencias.
Requisitos PCI que impactan backups
El requisito 3 exige protección de datos almacenados y se aplica a copias. El requisito 7/8 obliga a controles de acceso y autenticación para quien maneja backups. El requisito 10 pide registros de acceso y trazabilidad sobre operaciones de backup y restore.
Controles técnicos imprescindibles
Usar cifrado en reposo y en tránsito con algoritmos FIPS 140‑2 compatibles. Gestionar claves con HSM o KMS del cliente, con rotación y separación de roles. Activar registro inmutable (CloudTrail/Azure Monitor) y conservar evidencias de cada prueba.
Evidencias requeridas en auditoría
Política de backups firmada con RTO/RPO definidos, logs de ejecución, captura de pantalla o salida de scripts tras pruebas, y un AOC del proveedor cuando aplique. "La evidencia mínima es: política, registro de prueba y logs que demuestren quién y cuándo."
Para facilitar la preparación de evidencias frente a un QSA, es útil un mapeo directo entre requisitos PCI‑DSS y controles de backups.
- Por Requisito 3 (protección de datos almacenados) → aplicar cifrado en reposo con CMK gestionada por el cliente (SSE‑KMS / Key Vault), excluir o tokenizar columnas PAN en los dumps y emplear envelope encryption para objetos grandes
- Requisito 7/8 (control de accesos) → políticas IAM/RBAC de mínimo privilegio, roles separados para administración de claves y ejecución de backup, y uso obligatorio de MFA para accesos privilegiados
- Requisito 10 (registro y trazabilidad) → CloudTrail/Azure Monitor con retención inmutable y almacenamiento WORM para logs de operaciones de backup y restore
- Requisito 11/12 → programa de pruebas (semanales/parciales y trimestrales/completas), revisión documentada y política firmada con RTO/RPO
Este mapeo convierte requisitos normativos en controles operativos verificables durante la auditoría.
La gestión de claves requiere precisión operativa:
- utilizar CMK de cliente (AWS KMS, Azure Key Vault) con rotación automática habilitada y, para claves raíz o de mayor criticidad, HSM (CloudHSM o un HSM on‑premise) como raíz de confianza. Implementar envelope encryption: cifrar objetos con claves de datos (DEK) y proteger los DEK con la CMK
- registrar cada uso de la CMK en CloudTrail/Key Vault diagnostics para auditar acceso y grants
- definir políticas de grants que limiten operaciones (encrypt/decrypt/grant) por rol y por tiempo, y prohibir almacenamiento de claves en el servidor de WordPress
Documentar el ciclo de vida (creación, rotación, revocación, destrucción) y probar la recuperación de claves en un entorno aislado. Estas decisiones técnicas reducen el riesgo de que el "cifrado" declarado no sea suficiente ante un auditor.
Perfil: WordPress que almacena datos de tarjeta en servidor
Si el sitio guarda PAN o datos sensibles, el alcance PCI abarca backups y replicación. El responsable de cumplimiento debe coordinar con el administrador del hosting y el DBA para adaptar los controles. La política debe prohibir incluir PAN en dumps sin enmascarado o tokenización.
Qué excluir de los dumps
Excluir columnas que contengan PAN y datos CI/CAA al crear volcado de base de datos. Emplear queries selectivas o herramientas que hagan dump con exclusiones. Registrar el proceso y quién autoriza la inclusión de cualquier dato sensible.
Cómo cifrar y dónde guardar
Enviar backups a S3 o Azure Blob con claves controladas por cliente. Configurar SSE‑KMS (AWS) o Key Vault (Azure) y prohibir almacenamiento público. Mantener versionado y lifecycle rules para retenciones auditables.
Para reducir el alcance PCI y proteger CHD en backups es imprescindible la segmentación técnica y la tokenización a nivel de campo. Separar las cuentas de almacenamiento (por ejemplo, un storage account o bucket dedicado para backups con políticas de red que acepten solo VPC/SVC endpoints y denegar acceso público), aislar las bases de datos que contienen CHD en subredes privadas con reglas estrictas de firewall y egress, y aplicar field‑level masking o tokenización antes de cualquier volcado.
Desde el punto legal, documentar la ubicación geográfica de réplicas (ej.: UE/EEA si aplica GDPR) y conservar AOC o contratos que definan la responsabilidad compartida entre proveedor y cliente. Estas medidas facilitan demostrar al auditor la mitigación del riesgo y la reducción del alcance a elementos claramente controlados.
Perfil: WordPress con pagos externalizados
Si la pasarela redirige al PSP y no queda CHD en el servidor, el alcance PCI para backups es limitado. En ese caso se deben documentar las evidencias del proveedor y mantener controles mínimos en el sitio para evitar fuga accidental.
Qué revisar del proveedor
Solicitar AOC/attestation y confirmar qué controles cubre. Verificar ubicación de datos en la UE si exige la regulación local. Registrar el alcance en la política de backups.
Controles locales mínimos
Mantener cifrado de backups por si se almacenan incidentales, controlar accesos con MFA y registrar todos los envíos hacia el PSP. Conservar logs que demuestren que no se almacenó PAN en el sitio.
La configuración mínima auditable: SSE‑KMS con CMK del cliente, políticas IAM que deniegan acceso por defecto y pruebas de restauración trimestrales con registros (fecha, responsable, hash del fichero).
Errores frecuentes que fallan en auditoría
El error más frecuente en este punto es asumir que "cifrar" por el plugin basta cuando las claves quedan en el propio servidor. Sin separación de funciones y gestión de claves auditable, el cifrado no cumple PCI.
Dumps completos sin enmascarar
Hacer dumps completos y subirlos tal cual a un bucket vulnera el requisito 3 si contienen PAN. Evitar incluir tablas sensibles y aplicar tokenización o enmascarado antes de la copia. Documentar qué tablas se excluyen y por qué.
Plugins que anuncian cifrado
La mayoría de guías dicen que activar "cifrado" en el plugin es suficiente. Lo que no mencionan es dónde guarda el plugin la clave y quién la controla. Elegir plugins que permitan envío a S3/Azure y gestionar claves fuera del servidor.
Falta de pruebas y registros
Un backup que nunca se restaura no es evidencia válida en auditoría. Registrar restauraciones y conservar outputs, timestamps y responsables. Un caso habitual: un backup subido a S3 pero sin prueba de restore → resultado: no conformidad en auditoría.
Implementación práctica en WordPress
La implementación efectiva combina acciones en plugin, base de datos y cloud. Cada capa debe producir registros y artefactos que presente el responsable de cumplimiento. A continuación, pasos reproducibles.
Configuración de plugin segura
Configurar el plugin para enviar objetos a S3/Azure, no usar cifrado local del plugin. Guardar logs de ejecución con UID y timestamp. Programar retención y versionado desde el almacenamiento cloud.
Excluir datos sensibles en MySQL
Generar dumps con script que excluya columnas sensibles o ejecutar SELECT INTO OUTFILE con columnas permitidas. Restaurar en entorno aislado y verificar hashes. Registrar autorización del DBA para cualquier dump que incluya datos sensibles.
S3: ejemplo mínimo de configuración
Crear CMK en KMS, habilitar SSE‑KMS en el bucket y aplicar bucket policy que exige uso de KMS. Denegar acceso público y configurar VPC endpoint para transferencias internas. Habilitar CloudTrail y AWS Config.
flujo de backup seguro
WordPress + WP‑CLI / Plugin
→
Transporte TLS 1.2+
→
S3/Azure (SSE‑KMS / Key Vault)
Controles añadidos:
- IAM restrictivo y separación de roles
- CloudTrail / Audit Logs activados
- Pruebas de restauración periódicas documentadas
Configuración cloud detallada
La configuración cliente de KMS/Key Vault marca la diferencia entre cumplimiento y no conformidad. El proveedor puede ofrecer AOC, pero el auditor comprobará la configuración que el cliente aplica sobre su tenant o cuenta.
AWS: pasos mínimos
Crear CMK administrada por cliente, limitar administradores KMS y otorgar grants al rol de backup. Aplicar bucket policy que exija kms:Encrypt y deniegue acceso público. Activar CloudTrail con logs inmutables.
Azure: pasos mínimos
Usar Key Vault con soft‑delete y purge protection, asignar roles con RBAC, y configurar storage account con network rules y diagnósticos. Habilitar Azure Monitor y retener logs en un workspace con retención acorde a política.
Políticas IAM/RBAC recomendadas
Aplicar principio de mínimo privilegio para cuentas que realizan backup/restore. Separar roles de administración de claves y ejecución de backup. Requerir MFA para accesos privilegiados.
Retención, pruebas y métricas para auditoría
La política de retención debe justificar períodos y enlazarse a RTO/RPO definidos. Ejecutar pruebas con frecuencia y conservar registros que permitan reproducir tiempos y resultados.
Política de retención ejemplo
Retención operativa:
- 30 días
- Retención media: 90 días
- Archivo legal: 7 años si se requiere justificar transacciones
Registrar la justificación legal o comercial en la política.
Programa de pruebas
Realizar pruebas parciales semanales y restauración completa trimestral. Cada prueba debe generar: salida del script, hashes, tiempo de restauración, y responsable firmado. Conservar estas evidencias al menos durante 3 años.
Métricas RTO/RPO medibles
Definir RPO en minutos u horas y RTO en horas; medir en cada prueba y anotar desviaciones. Un objetivo típico: RPO 1 hora para datos transaccionales y RTO 4 horas para restauración completa en entorno controlado.
Plantillas y scripts incluidos
A continuación se ofrece un conjunto práctico de artefactos que debe adaptarse al entorno. Copiar y pegar, rellenar campos y subir a repositorio de evidencias.
Ejemplo de política de backups
Política de copias de seguridad - [Nombre de la entidad]
Alcance: servidores web y base de datos que procesan tarjetas. Responsables:
- Administrador de sistemas, DBA, Responsable de cumplimiento. RTO: 4 horas. RPO: 1 hora. Corrección: Retención operativa (copias accesibles para restauración rápida): 30 días
- Retención de evidencias operativas y registros de ejecución (outputs de scripts, hashes, logs de restauración): 90 días
- Registros de auditoría y resultados de pruebas archivadas para auditoría: 3 años
- Archivo legal de transacciones cuando la normativa lo exija: hasta 7 años
Dejar esta distinción explícita evita la contradicción entre la política de backups y las exigencias de conservación de evidencias. Cifrado: SSE‑KMS (AWS) / Key Vault (Azure) Gestión de claves: CMK con roles separados, rotación anual. Pruebas: Restauración completa trimestral, parciales semanales. Registros: CloudTrail / Azure Monitor con retención 3 años. Autorizaciones: cualquier inclusión de datos sensibles requiere registro y aprobación del DBA
Script de restore ejemplo
set -e
BUCKET=my-backups-bucket
OBJECT=site-db-$(date +%F).sql.gz
TMP=/tmp/restore
mkdir -p $TMP
aws s3 cp s3://$BUCKET/$OBJECT $TMP/
gunzip -c $TMP/$OBJECT | mysql -u restore_user -p"$RESTORE_PASS" restore_db
sha256sum $TMP/$OBJECT > $TMP/restore.sha256
echo "RESTORE_DONE $(date +%FT%T)" >> /var/log/backup_restore.log
Excepciones de aplicación
Si el sitio no procesa ni almacena datos de tarjeta (pagos redirigidos y tokenizados) o si un proveedor acreditado gestiona y audita las copias entregando un AOC que cubre estos servicios, entonces el alcance PCI sobre los backups se reduce y bastan controles de proveedor y evidencias. En esos casos incluir el AOC en la carpeta de evidencias y documentar la delegación de responsabilidades.
Si se desea soporte técnico para auditar configuración KMS, políticas IAM y pruebas de restauración, puede solicitarse revisión técnica y la elaboración del paquete de evidencias para auditoría.
Preguntas frecuentes
¿Cómo cifrar backups para cumplir PCI?
Cifrar con KMS/HSM gestionado por el cliente y usar TLS para transporte. Configurar CMK (AWS) o Key Vault (Azure) y restringir acceso mediante roles. Conservar registros de uso de clave para auditoría.
¿Cuánto tiempo conservar los backups según PCI?
Conservar evidencias operativas al menos 90 días y registros de pruebas 3 años. La retención de datos transaccionales puede justificarse hasta 7 años si la normativa lo exige. Documentar la justificación en la política.
¿Es suficiente un plugin que cifra localmente?
No, no basta si el plugin guarda la clave en el mismo servidor. La gestión de claves debe ser auditable y separar administración de ejecución. Preferir soluciones que usen KMS/Key Vault bajo control del cliente.
¿Cómo demostrar una restauración en auditoría?
Mostrar como resultado visible la salida del script, el hash y una captura de pantalla. Guardar el log con timestamp, responsable y resultado; adjuntar evidencia en el checklist.
¿Qué evidencias pedir al proveedor cloud?
Solicitar AOC/PA‑AOC, detalles de ubicación de datos y acceso a logs (CloudTrail/Azure Monitor) cuando proceda. Verificar que el AOC cubre cifrado en reposo y separación de funciones.
¿Qué pruebas de restauración son obligatorias?
Registrar una restauración completa trimestral y pruebas parciales semanales. Cada prueba debe producir hashes, tiempos y responsables que se archivan como evidencia.
¿Qué ocurre si uso un hosting compartido?
Si el hosting es compartido, es probable que el proveedor gestione backups; solicitar AOC y revisar si el proveedor permite gestión de claves por cliente. Si no es posible, migrar a entorno segregado o proveedor que permita CMK.
Qué hacer ahora
Definir el alcance: confirmar si el sitio almacena CHD y documentarlo. Crear o actualizar la política de backups con RTO/RPO y retenciones justificadas.
Aplicar configuración: activar SSE‑KMS o Key Vault, bloquear acceso público y establecer roles. Ejecutar una restauración de prueba completa y conservar las evidencias en el repositorio de cumplimiento.
Solicitar al auditor PCI (QSA) o al proveedor cloud el AOC y presentar la carpeta de evidencias: política, logs, scripts y resultados de pruebas.
PCI SSC
AWS KMS docs
