Protección DDoS y copias de seguridad: construya dos líneas de defensa distintas
Una red disponible y unos datos recuperables resuelven problemas distintos. HM Bastion incluye la protección DDoS en su infraestructura, mientras que un plan operativo sólido sigue necesitando controles de acceso, mantenimiento de aplicaciones y una copia de recuperación que haya probado.
La conclusión práctica
Utilice la mitigación para reducir el tráfico malicioso, mantenga la aplicación para reducir el riesgo de compromiso y conserve datos recuperables de forma independiente para los fallos que la protección no puede evitar.
Identifique el fallo antes de elegir la defensa
Una inundación de tráfico volumétrica puede consumir la capacidad de red. Una solicitud costosa a la aplicación puede agotar un servicio con mucho menos tráfico. Una credencial de administrador robada puede modificar o eliminar contenido mientras la red sigue sana. Estos eventos tienen causas distintas, por lo que una sola función de protección no puede sustituir a un plan operativo completo.
La mitigación de DDoS busca identificar y reducir el tráfico de ataque permitiendo el paso del tráfico útil. El tratamiento exacto depende del ataque y del servicio protegido. La protección permanente no significa que toda aplicación sea invulnerable, que todos los protocolos se comporten igual ni que se haya creado una garantía de disponibilidad.
Mantenga sana la aplicación que está detrás de la puerta
En un VPS o servidor dedicado, mantenga el acceso administrativo de forma deliberada. Elimine los servicios que no necesite, aplique actualizaciones del sistema operativo y de las aplicaciones, y restrinja el acceso privilegiado a las personas y sistemas que lo requieran. Mantenga los secretos fuera de las carpetas públicas y revise los registros cuando cambie el comportamiento.
En una aplicación web, considere los controles de autenticación, los límites de solicitudes y el comportamiento de la caché junto con la mitigación de red. Los endpoints costosos sin caché merecen atención aunque la red circundante tenga margen. Un pico de tráfico legítimo puede exponer el mismo cuello de botella de la aplicación que las solicitudes abusivas, por lo que la planificación normal de capacidad sigue siendo importante.
Registre los puertos, dominios y protocolos que la aplicación necesita realmente. Cuando abra una solicitud de soporte sobre un incidente, indique el servicio afectado, la hora aproximada, los síntomas visibles y detalles de diagnóstico seguros. Nunca incluya un secreto de monedero, una contraseña de cuenta ni una clave de recuperación privada en un ticket.
Asigne a cada capa de recuperación su propia función
| Capa | Útil para | Tenga en cuenta |
|---|---|---|
| Almacenamiento replicado | Continuidad ante algunos fallos de hardware de almacenamiento | Un cambio de datos no deseado también puede replicarse |
| Instantánea | Volver a un estado del sistema capturado | La retención y la independencia difieren de una copia de seguridad separada |
| Copia de seguridad independiente | Recuperar datos desde una copia separada | Debe incluir los archivos, las bases de datos y los conocimientos de restauración necesarios |
Las especificaciones de la nube de HM Bastion describen almacenamiento replicado Ceph e instantáneas. Las gamas de hosting web publican copias de seguridad diarias con hasta diez puntos de restauración. Lea la función asociada al servicio que contrata; no dé por hecho que existe la misma configuración de copias de seguridad en todas las familias de hosting.
Elija un calendario de recuperación en función de cuánto trabajo reciente puede perder el proyecto y cuánto puede tardar la restauración. Un sitio informativo y una base de datos de pedidos activa tienen necesidades distintas. Mantenga las credenciales de recuperación separadas de la aplicación en funcionamiento y asegúrese de que más de una persona autorizada sepa dónde se guarda el procedimiento.
Pruebe una restauración mientras el sistema está sano
- Identifique los archivos del sitio web, la base de datos, las cargas y la configuración necesarios para reiniciar.
- Cree una copia independiente con acceso limitado a personas autorizadas.
- Restaure en un entorno de prueba seguro en lugar de sobrescribir producción.
- Compruebe el contenido, el acceso a la aplicación y los recorridos de usuario importantes.
- Registre el resultado, el tiempo transcurrido y cualquier elemento que falte en el procedimiento.
Un archivo que existe en el almacenamiento de copias de seguridad es una prueba útil de que hay una copia, pero una restauración correcta es una prueba más sólida de recuperabilidad. Repita la prueba tras un cambio significativo en la aplicación o el almacenamiento. Así, una promesa vaga de recuperar más adelante se convierte en un procedimiento que el equipo puede seguir realmente.
Cuando ocurra un incidente, mantenga la mitigación de red, el diagnóstico de la aplicación y la recuperación de datos como líneas de trabajo separadas, con un responsable claro para cada una. Esa estructura ayuda al equipo a actuar sobre el fallo real en lugar de recurrir siempre a la misma acción de reinicio o reversión.
