Imagina esto: cinco sitios web comparten un VPS. Un plugin antiguo de WordPress en uno de ellos es vulnerable y un atacante consigue subir un archivo. En ese momento, la pregunta importante deja de ser «¿qué potencia tiene el VPS?» y pasa a ser¿hasta dónde puede desplazarse el atacante desde ese único sitio web?
En un entorno bien diseñado, la respuesta debería ser: no demasiado lejos. En uno mal diseñado, un problema en un sitio puede convertirse rápidamente en un problema para todos los sitios del servidor.
Si estás comparando este escenario con el hosting compartido, nuestro artículo sobreseguridad del hosting compartidoayuda a entender por qué los límites de aislamiento son distintos según el modelo de hosting.
Qué ocurre cuando los cinco sitios comparten un mismo usuario
Si todos los proyectos se ejecutan bajo un único usuario del sistema, con permisos amplios sobre archivos y credenciales compartidas, en la práctica existe muy poco aislamiento. Un proceso comprometido podría leer archivos de configuración vecinos, descubrir credenciales de bases de datos o modificar otros sitios.
Esto no significa que «alojar varios sitios en un VPS sea malo». El problema es la arquitectura, no el hecho de que el VPS sea compartido por tus propios sitios web.
Construye el aislamiento por capas
- Usuarios o suscripciones separados.Cada sitio web debe ejecutarse con sus propios permisos.
- Permisos de archivo mínimos.Un proceso web no debe poder acceder a archivos que no necesita.
- Credenciales de base de datos separadas.La cuenta de base de datos de un sitio no debería tener acceso automático a otras bases de datos.
- Separación de procesos.Configura PHP o los procesos de la aplicación de forma que un proyecto tenga menos capacidad para afectar a otro.
- Una copia de seguridad independiente.Si un atacante puede eliminar la única copia de seguridad desde el mismo VPS, el plan de recuperación aporta muy poca protección.
En entornos WordPress, el aislamiento debe complementarse con detección de malware; nuestraguía sobre Imunify360 y protección contra malwareexplica esa capa.
Cuatro señales de alerta
- se reutiliza la misma contraseña administrativa en sitios web de distintos clientes;
- todos los sitios se encuentran bajo una única cuenta del sistema;
- las actualizaciones del CMS y de los plugins se retrasan durante meses;
- la única copia de seguridad se almacena en el mismo VPS.
Si dos o más de estas situaciones son ciertas, corregiría primero el modelo operativo antes de comprar más CPU o RAM. Para un contexto más amplio de hardening, consulta nuestro artículo sobreSeguridad del servidor.
Si estos sitios pertenecen a clientes distintos y no necesitas flexibilidad a nivel root,Hosting Resellerpuede ser un modelo operativo más natural, con cuentas de cliente separadas y administración centralizada mediante Plesk.
Cuándo un solo VPS deja de ser el límite adecuado
Incluso un buen aislamiento no significa que todas las cargas deban permanecer para siempre en la misma máquina. Un sitio con mucho tráfico, un cliente con requisitos de seguridad más estrictos o una tienda online crítica para los ingresos pueden estar mejor separados en VPS distintos.
La contención de recursos también importa. Un cron mal configurado o un pico de tráfico puede consumir CPU o memoria. Por eso, la monitorización y unos límites de recursos razonables son tan importantes como los permisos de archivo.
Alojar varios sitios web en un único VPS puede ser perfectamente razonable. Pero «mismo servidor» no debería significar «mismo perímetro de seguridad».
Si quieres ayuda con la capa del sistema, unVPS administradopuede reducir el trabajo operativo, mientras que el aislamiento de aplicaciones y la seguridad del código siguen requiriendo un proceso deliberado por separado.
