La gestión de sitios de clientes a gran escala requiere pensar en la seguridad de la infraestructura más allá de la simple instalación de plugins de seguridad o la imposición de contraseñas seguras.
Cuando alojas decenas o cientos de sitios WordPress, la arquitectura de alojamiento se convierte en un factor de seguridad que puede proteger o poner en riesgo todo tu portfolio.
El alojamiento compartido tradicional mantiene los costes bajos, pero también significa que los sitios comparten el mismo sistema de archivos, espacio de proceso y stack de red. Por lo tanto, cuando un sitio de un servidor compartido se ve comprometido, el malware puede propagarse a otros sitios.
Los riesgos de seguridad ocultos de los entornos de alojamiento compartido
Cada sitio de un servidor de alojamiento compartido utiliza una parte de la CPU, RAM y almacenamiento del servidor. Esto tiene sentido para los proveedores de alojamiento desde el punto de vista de los costes y mantiene accesibles los precios para los clientes.
Sin embargo, desde el punto de vista de la seguridad, existen vulnerabilidades que aumentan con el número de sitios que gestionas. El problema principal se centra en el uso compartido de recursos. Los permisos de archivos y el aislamiento de usuarios pueden proporcionar cierta protección, pero se trata de controles a nivel de software que pueden ser objeto de explotación. Al fin y al cabo, los ataques de phishing, el malware y el ransomware siguen siendo las principales amenazas para cualquier sitio web.
Comprender la «propagación lateral» y la «contaminación cruzada» puede ayudar a aclarar los riesgos:
- La propagación lateral se refiere al malware que se desplaza de un sistema comprometido a otros sistemas dentro de la misma red o entorno.
- La contaminación cruzada se produce cuando un problema de seguridad que afecta a un sitio se propaga a otros sitios que comparten la misma infraestructura.
Si gestionas carteras de clientes, ahorrar dinero utilizando alojamiento compartido puede resultar atractivo. Sin embargo, un plugin obsoleto o una contraseña débil de un solo cliente pueden suponer una amenaza para toda tu configuración de alojamiento.
Si se tiene en cuenta el tiempo dedicado a monitorizar las amenazas y a recuperarse de incidentes de seguridad en múltiples sitios, el valor disminuye.
Cómo se propaga el malware entre sitios en servidores compartidos
La naturaleza exacta de cualquier contaminación entre sitios depende de cómo el proveedor de alojamiento implemente la separación de usuarios y los permisos de los archivos. Aun así, el problema fundamental sigue siendo el mismo en la mayoría de las configuraciones de alojamiento compartido: estos entornos crean superficies de ataque en las que las cuentas comprometidas pueden acceder a los archivos de otros usuarios a través de permisos mal configurados o scripts vulnerables.
Las vías de infección entre sitios incluyen:
- Los scripts PHP leen archivos de directorios de otros usuarios cuando los permisos están configurados incorrectamente.
- Los directorios temporales compartidos permiten que el malware se propague entre sitios.
- Las vulnerabilidades a nivel de servidor permiten que los procesos de un sitio afecten a otros.
- Las cuentas de usuario comprometidas obtienen acceso a los directorios vecinos a través de grupos de recursos compartidos.
Bookswarm, cliente de Kinsta, descubrió este problema mientras gestionaba cientos de sitios de clientes en una plataforma de alojamiento compartido. Se dieron cuenta de que la configuración mixta de servidores creaba dolores de cabeza en materia de seguridad, además de cualquier compromiso individual de un sitio. La arquitectura significaba que «un ataque a uno era un ataque a todos»
Esto también supone una carga operativa, ya que es necesario realizar un seguimiento constante para detectar las vulnerabilidades antes de que se propaguen. Si un sitio muestra signos de infección, hay que comprobar todos los demás sitios del mismo servidor. La respuesta a incidentes se convierte en una tarea que abarca todo el portfolio, en lugar de una solución aislada.
El problema de la contaminación de las listas negras
Las direcciones IP compartidas crean otra capa de riesgo en el alojamiento compartido tradicional. Cuando varios sitios comparten la misma IP, también comparten la misma reputación a los ojos de los proveedores de correo electrónico, los motores de búsqueda y los servicios de seguridad.
Debido a que una sola vulnerabilidad puede provocar que toda la dirección IP entre en una lista negra (blacklist), cada sitio alojado bajo esa misma IP sufre una serie de problemas en cascada:
- La capacidad de entrega del correo electrónico disminuye en todo tu portfolio cuando un sitio comprometido activa filtros de spam como Spamhaus.
- Los motores de búsqueda marcan la IP compartida como sospechosa, lo que afecta negativamente al posicionamiento de todos los sitios asociados.
- Los servicios de seguridad y los cortafuegos bloquean las peticiones procedentes de la IP, interrumpiendo la funcionalidad de los sitios no relacionados con el compromiso original.
- Los sitios de clientes pierden indicadores de confianza cuando las herramientas de seguridad asocian la IP compartida con una actividad maliciosa.
El proceso de recuperación tras ser incluido en una lista negra de IP requiere un esfuerzo coordinado con tu proveedor de alojamiento. Debes identificar qué sitio causó el problema, limpiarlo y, a continuación, solicitar su eliminación de varias listas negras. Durante este proceso, todos los sitios que comparten la IP seguirán sufriendo las consecuencias.
Mientras tanto, tienes que explicar a tus clientes por qué su correo electrónico ha dejado de funcionar o por qué su sitio web ha sido marcado, a pesar de que han seguido las prácticas óptimas de seguridad de WordPress. La causa principal se remonta a decisiones de infraestructura sobre las que los propietarios de los sitios web individuales no tienen ningún control. Todo este mantenimiento continuo quita tiempo al trabajo con los clientes y a los proyectos de desarrollo.
Aislamiento a nivel de contenedor en el alojamiento para WordPress
El aislamiento de sitios aborda muchos de los problemas fundamentales del alojamiento compartido. Por ejemplo, Kinsta ejecuta cada sitio en su propio contenedor aislado con recursos dedicados. Esto significa que cada sitio de WordPress tiene su propio contenedor que incluye todo lo necesario para funcionar: Linux, NGINX, PHP y MySQL.
El aislamiento se produce a nivel del sistema operativo a través de dos mecanismos básicos:
- Los Namespaces (espacios de nombres) proporcionan a cada contenedor su propia visión de los recursos del sistema. Un proceso que se ejecuta en un contenedor no puede ver ni interactuar con los procesos de otro contenedor.
- Los Control groups («cgroups«, grupos de control) imponen límites de recursos y garantizan que cada contenedor tenga acceso a su asignación dedicada de CPU y RAM.
Es más, los hilos PHP de tu sitio de WordPress no pueden ver ni interactuar con procesos de otros sitios. Esta separación a nivel de núcleo evita situaciones en las que el proceso comprometido de un sitio intenta acceder a recursos pertenecientes a otros sitios.
Los stacks de red también funcionan de forma independiente dentro de cada contenedor. Cada sitio tiene su propia interfaz de red y gestión de IP. Este aislamiento se extiende a todo el stack y elimina el problema de los vecinos ruidosos que afecta al alojamiento compartido.
Cuando un sitio experimenta un pico de tráfico o ejecuta operaciones que consumen muchos recursos, sólo afecta al contenedor de ese sitio. La asignación de recursos dedicada significa que otros sitios siguen funcionando con su asignación completa, independientemente de lo que ocurra en otros lugares de la infraestructura.
Cómo el aislamiento de contenedores evita la propagación lateral de malware
Cuando un sitio se ve comprometido en un entorno de contenedores, el malware permanece confinado dentro de ese contenedor. Esta separación impide que los procesos comprometidos accedan a otros contenedores mediante varios mecanismos:
- Los sistemas de archivos permanecen aislados, por lo que el malware no puede propagarse aprovechando los directorios compartidos o los archivos temporales.
- Los namespaces de procesos evitan que el código malicioso escanee o interactúe con procesos en otros contenedores.
- El aislamiento de la red limita la capacidad de los sitios comprometidos para escanear o atacar sitios vecinos.
- Los espacios de memoria permanecen completamente separados, lo que evita que los ataques de desbordamiento del búfer crucen los límites del contenedor.
Si el sitio está alojado en Kinsta, nuestros sistemas de monitorización pueden detectar inmediatamente el contenedor comprometido y responder mientras otros sitios de tu portfolio siguen funcionando.
Verificar el aislamiento real frente a las afirmaciones de marketing
No todos los proveedores de alojamiento implementan el aislamiento de contenedores de la misma manera. Algunos utilizan el término «aislado» para describir límites flexibles en el uso de recursos mientras siguen ejecutando múltiples sitios en entornos compartidos. Entender lo que constituye un verdadero aislamiento a nivel de contenedor te ayuda a evaluar tus opciones de alojamiento y a evitar los riesgos de seguridad que conlleva el marketing engañoso.
El verdadero aislamiento de contenedores significa que cada sitio se ejecuta en su propio namespace del sistema operativo con recursos dedicados a los que no pueden acceder otros sitios. Si estás buscando un nuevo proveedor de alojamiento, hay algunos puntos en los que debes centrarte:
- ¿Obtiene cada sitio su propio contenedor con asignaciones dedicadas de CPU y RAM a las que otros sitios no pueden acceder?
- ¿Están los sistemas de archivos completamente separados a nivel de núcleo utilizando namespaces en lugar de sólo permisos a nivel de usuario?
- ¿Qué ocurre con los demás sitios cuando un contenedor se ve comprometido o experimenta un pico de tráfico?
- ¿Qué tecnología de contenedores utiliza el host (LXC, LXD, Docker) y cómo aplica el aislamiento?
- ¿Puede el host proporcionar documentación técnica sobre sus mecanismos y arquitectura de aislamiento?
La diferencia entre los límites flexibles y el aislamiento estricto es importante tanto para la seguridad como para el rendimiento. Los límites flexibles pueden restringir la cantidad de CPU que puede utilizar un sitio, pero funcionan dentro de un entorno compartido en el que los procesos de un sitio pueden seguir interactuando con los demás. El aislamiento estricto con recursos dedicados significa que cada sitio funciona en un entorno completamente independiente, en el que los sitios vecinos no pueden acceder a sus recursos ni verse afectados por sus actividades.
Métodos de verificación técnica
Buscar especificaciones técnicas que detallen la tecnología de contenedores puede ayudarte a comprender hasta qué punto un proveedor conoce la arquitectura subyacente. Por ejemplo, los proveedores que utilicen LXC, LXD, Docker o tecnologías similares deben poder describir los mecanismos específicos de aislamiento que implementan.
Las certificaciones de cumplimiento, como SOC 2 Tipo II e ISO 27001, indican que las prácticas de seguridad han sido auditadas por terceros independientes. Estas certificaciones requieren controles de seguridad documentados y pruebas periódicas, lo que proporciona más garantías que las simples afirmaciones de marketing. Kinsta mantiene ambas certificaciones y se somete a auditorías periódicas para verificar que los mecanismos de aislamiento funcionan según lo anunciado.
Si tienes la oportunidad de utilizar el alojamiento durante un periodo de prueba, también puedes comprobar cómo funciona su aislamiento de varias maneras, por ejemplo, monitorizando el consumo de recursos en varios sitios del mismo servidor o observando lo que ocurre durante las operaciones que requieren un uso intensivo de la CPU en un sitio concreto.
Con Kinsta, este tipo de validación práctica es posible durante tu primer mes sin ningún coste.
Entender qué significa el aislamiento de sitios para tu estrategia de alojamiento
Pasar de un alojamiento compartido a una arquitectura de contenedores aislados puede mejorar considerablemente la seguridad fundamental de todo tu portfolio de WordPress, e incluso tu forma de abordar la gestión de infraestructuras a gran escala.
En los sitios de varios clientes con alojamiento compartido, la probabilidad de que al menos un sitio experimente un incidente de seguridad es casi segura. La verdadera cuestión es si ese incidente se limita a un solo sitio o crea problemas en cascada en toda tu portfolio.
Para las agencias y equipos que gestionan muchos sitios de WordPress, el alojamiento es, en última instancia, una decisión de riesgo a nivel de portfolio. Si estás buscando una infraestructura diseñada específicamente para gestionar sitios a gran escala, Kinsta ofrece soluciones adaptadas a las agencias y a los entornos de WordPress de gran volumen.
