Sin Política de Respaldos
Sin respaldos regulares y probados, un ataque de ransomware, eliminación accidental o corrupción de base de datos puede resultar en pérdida permanente de datos.
Cómo Funciona
Los grupos de ransomware apuntan específicamente a bases de datos y almacenamiento en la nube. Sin respaldos — o con respaldos almacenados en la misma cuenta que los datos primarios — un solo compromiso puede cifrar o borrar todo. Incluso sin un ataque, la corrupción de bases de datos y las eliminaciones accidentales ocurren.
// MAL: sin configuración de respaldo — proyecto Supabase sin Point-in-Time Recovery
// o base de datos con dumps manuales que nunca se probaron realmente
// o respaldos almacenados en la misma cuenta AWS que los datos de producción// BIEN: respaldos automatizados con procedimientos de restauración probados
// Para Supabase: habilita Point-in-Time Recovery (plan Pro)
// Para Postgres self-hosted: pg_dump a bucket S3 separado en cuenta diferente
// .github/workflows/backup.yml — programado diariamente
// Verifica restauraciones mensualmente: restaura a un entorno de prueba y confirma integridad de datosEjemplo Real
El incidente de GitLab en 2017: un sysadmin accidentalmente eliminó el directorio de base de datos incorrecto durante un procedimiento de failover. Se perdieron seis horas de datos de producción porque ninguno de los cinco métodos de respaldo funcionaba correctamente en ese momento.
Cómo Prevenirlo
- Habilita respaldos diarios automatizados para tu base de datos — Supabase Pro, respaldos automatizados de RDS o un pg_dump basado en cron
- Guarda los respaldos en una cuenta o proveedor de nube separado de tus datos de producción
- Prueba tu proceso de restauración trimestralmente — un respaldo que nunca has restaurado no es un respaldo
- Establece un Recovery Time Objective (RTO) y Recovery Point Objective (RPO) y verifica que tus respaldos los cumplan
Tecnologías Afectadas
Data Hogo detecta esta vulnerabilidad automáticamente.
Escanea Tu Repo GratisVulnerabilidades Relacionadas
NODE_ENV No Configurado como Production
mediumCorrer Node.js sin NODE_ENV=production habilita mensajes de error detallados, deshabilita optimizaciones de caché y puede activar middleware solo para desarrollo.
Modo Debug Activo en Producción
mediumEl modo debug habilitado en producción expone estado interno, habilita logging detallado y a veces activa endpoints de debugging interactivos que los atacantes pueden explotar.
Sin Endpoint de Health Check
lowSin un endpoint /health, los load balancers y orquestadores no pueden verificar que tu aplicación realmente funciona antes de enrutar tráfico hacia ella.
Sin Monitoreo de Errores
lowSin monitoreo de errores, los errores de producción son invisibles hasta que un usuario los reporta — lo cual la mayoría nunca hace.