Proteger un sitio web no consiste solo en instalar un certificado ni en contratar un alojamiento. El riesgo puede aparecer en una contraseña reutilizada, un plugin sin actualizar, un permiso excesivo, una aplicación vulnerable o una copia que nunca se ha restaurado. La mejor práctica es separar capas y responsabilidades.
La aplicación también forma parte de la seguridad
El CMS, los plugins, los temas y el código propio deben mantenerse dentro de versiones compatibles y razonablemente actualizadas. Antes de cambiar componentes conviene disponer de una copia, comprobar la compatibilidad y tener una forma de revertir el cambio. El mantenimiento no termina al publicar la web.
Las cuentas administrativas necesitan contraseñas únicas y, cuando la plataforma lo permite, autenticación multifactor. También es recomendable limitar quién tiene permisos de administración y revisar las cuentas antiguas que ya no se utilizan.
HTTPS protege la comunicación, no toda la web
HTTPS utiliza TLS para proteger la comunicación entre el navegador y el servidor frente a la observación o modificación durante el tránsito, siempre que la conexión y la configuración sean correctas. El certificado SSL/TLS ayuda a establecer esa conexión y a validar el dominio según el tipo de certificado.
HTTPS no corrige una vulnerabilidad del CMS, no elimina malware y no garantiza que una contraseña sea segura. También hay que revisar redirecciones, contenido mixto, cookies, cabeceras y la configuración de la aplicación.
Servidor, permisos y accesos
El servidor debe ejecutar solo los servicios necesarios y mantenerse actualizado según el modelo de administración contratado. En un VPS o servidor dedicado, el responsable técnico debe revisar usuarios, permisos de archivos, acceso SSH, firewall, logs y tareas programadas. En un alojamiento gestionado por panel, conviene saber qué controles están disponibles y qué parte corresponde al proveedor.
Los permisos deben permitir que la aplicación funcione sin conceder más acceso del necesario. Las credenciales de bases de datos, correo y servicios externos no deberían quedar expuestas en archivos públicos ni compartirse entre aplicaciones sin motivo.
Copias de seguridad y restauración
Una copia de seguridad reduce el impacto de un borrado, una corrupción o un incidente, pero no evita que ocurra. Debe incluir los elementos necesarios para reconstruir el servicio: archivos, base de datos, configuración y, cuando proceda, claves o certificados gestionados correctamente.
Define una frecuencia y una retención según el ritmo de cambios. Mantener copias en una ubicación separada ayuda frente a errores que afecten al almacenamiento principal. Sobre todo, prueba la restauración: el objetivo no es acumular archivos, sino recuperar una versión utilizable dentro de un plazo razonable.
Detección y respuesta
Los logs del servidor y de la aplicación pueden mostrar accesos inesperados, errores repetidos, cambios de permisos o intentos de explotación. Las alertas deben centrarse en señales que el equipo pueda revisar. Una monitorización que genera avisos imposibles de atender termina ocultando los importantes.
Si se detecta malware o una cuenta comprometida, conserva evidencias, limita el acceso afectado, revisa credenciales, identifica el alcance y restaura desde una copia conocida. No basta con borrar el archivo visible si no se entiende cómo se produjo la intrusión.
Responsabilidades compartidas
El proveedor mantiene las capas que forman parte del servicio contratado, como la infraestructura o determinados componentes de plataforma. El cliente sigue siendo responsable del contenido, las cuentas, la configuración de la aplicación y las credenciales que controla. El alcance exacto debe confirmarse en las condiciones del servicio.
Para reforzar una web, revisa las opciones de complementos de hosting que sean relevantes, el alojamiento web y la configuración del servicio de certificados SSL. La utilidad depende de lo que realmente esté incluido y de cómo se administre.