Aislamiento por sitio
El aislamiento es la diferencia entre un incidente y una interrupción. Cada sitio que alojamos se ejecuta dentro de una jaula LVE de CloudLinux a nivel de núcleo con sus propios límites de CPU, RAM, E/S y procesos, su propia vista de sistema de archivos CageFS, su propia versión de PHP y su propio límite de base de datos. Un sitio que es atacado, vulnerado o que simplemente ejecuta una consulta exigente queda contenido en su lugar, y la línea base de aislamiento se incluye en cada plan, sin cobrarse como una mejora. Disponibilidad: la limitación de bases de datos por sitio y las estadísticas de recursos por sitio están en desarrollo activo y aún no están disponibles. Todo lo demás descrito aquí está activo hoy en día.
La flota de trabajadores ejecuta CloudLinux OS, que traslada la multitenencia al núcleo del sistema operativo. Cada sitio web cuenta con un entorno virtual ligero (Lightweight Virtual Environment), o LVE, que constituye un límite estricto en lugar de una mera convención de cortesía. Nada de lo que un sitio haga dentro de su jaula puede consumir recursos del presupuesto de otro.
LVE limita la CPU, RAM, IO, IOPS, los procesos y los procesos de entrada para cada sitio de forma independiente. Cuando un sitio supera su límite, se ralentiza dentro de su propia jaula; el error se registra para ese sitio y los sitios a ambos lados continúan sin verse afectados.
Un plugin atrapado en un bucle, una tarea cron mal escrita o un rastreador saturando un endpoint alcanzan primero los límites de procesos y de procesos de entrada propios del sitio. Un solo sitio no puede simplemente acaparar la máquina.
Como los procesos de entrada están limitados por jaula, una inundación dirigida a un sitio no puede abrir trabajo ilimitado en el host. La limitación de conexiones y solicitudes de LiteSpeed y el firewall de red de Imunify360 se sitúan delante de esto, por lo que el ataque sigue siendo un problema del objetivo.
Cada fallo de LVE se registra por sitio y se integra en el motor de políticas de la plataforma, que puede endurecer o relajar los límites automáticamente. Puedes ver por qué se limitó un sitio y cuándo: de forma gradual, reversible y registrada.
El aislamiento de recursos evita que un sitio haga ruido. El aislamiento del sistema de archivos evita que sea indiscreto. CageFS ofrece a cada inquilino una vista privada y restringida de la máquina.
Bajo CageFS, cada inquilino ve sus propios archivos y un conjunto mínimo y saneado de binarios del sistema, y no puede ver a otros inquilinos, los sitios de otros inquilinos ni archivos confidenciales del sistema. El fallo habitual del alojamiento compartido, en el que una cuenta comprometida se convierte en una posición de lectura sobre todas las demás cuentas del servidor, se bloquea a nivel de kernel.
Esto es lo que más importa el día en que algo sale mal. Si un sitio web resulta comprometido —a través de un plugin obsoleto, una credencial robada, un tema vulnerable—, CageFS es lo que mantiene el radio de la explosión limitado a esa única jaula. Nuestra especificación de seguridad es deliberada en cuanto a las palabras: CageFS contiene las brechas. La contención es la afirmación honesta, y es la que decide si un incidente se reduce a la limpieza de un solo sitio o a la de toda la flota.
Las copias de seguridad refuerzan el mismo límite. Las copias de seguridad por sitio son inmutables, externas y están aisladas del parque en ejecución, con restauraciones probadas, de modo que incluso una brecha en el peor de los casos en un sitio tiene una ruta de recuperación limpia e independiente que no depende del estado de la máquina en la que se estaba ejecutando.
El aislamiento de la capa web es solo la mitad del problema. En un entorno de WordPress, lo que con más frecuencia hace que un servidor parezca lento son las consultas de un sitio, no el tráfico de un sitio. Eso se gestiona de forma explícita.
CloudLinux MySQL Governor limita el uso de bases de datos por sitio, por lo que las consultas pesadas de un sitio no pueden ralentizar el servidor para los demás. Es el control antilentitud y funciona tanto si el sitio ruidoso nota que está siendo limitado como si no.
La infraestructura ejecuta MariaDB (o Percona), elegida para cargas de trabajo de WordPress en lugar de heredada por defecto, con Governor situado por encima como la capa de equidad por inquilino.
Un objeto caché de Redis por sitio absorbe las lecturas repetidas antes de que lleguen a la base de datos, lo que reduce la presión que Governor debe arbitrar en primer lugar. La caché y el aislamiento funcionan como un solo sistema.
CloudLinux alt-PHP ofrece a cada sitio su propio selector de versión de PHP, sus propias extensiones (imagick, gd, redis y el resto) y su propia configuración reforzada, con trabajadores LSAPI limitados por los topes LVE de ese sitio, de modo que la concurrencia de PHP forma parte de la jaula en lugar de ser un escape de ella.
El aislamiento decide hasta dónde se propaga un problema. La aplicación decide qué sucede a continuación. Sustituimos la abrupta suspensión de activación/desactivación por una máquina de estados, impulsada por flujos de trabajo duraderos y aplicada en el trabajador a través de LiteSpeed, LVE e Imunify.
El aislamiento no es una función del plan que aparece tres niveles más arriba. Es una propiedad de la infraestructura, por lo que es idéntica tanto si ejecutas una tienda WooCommerce como dos mil sitios en red.
Las redes masivas y PBN funcionan sobre el mismo sustrato de LVE y CageFS, junto con la rotación de cuentas de CDN con detección de huellas y la entrega de HTML estático. El aislamiento es lo que hace que la densidad sea segura: los sitios comparten una flota sin compartir destino.
Los sitios de Managed WordPress, WooCommerce, PHP, estáticos y de Node obtienen los mismos entornos aislados junto con autogestión completa: tu propia versión de PHP y extensiones, caché de objetos Redis, entornos de prueba (staging) y despliegue a producción (push-to-live).
Para cargas de trabajo que necesitan un límite más fuerte que el valor predeterminado optimizado para la densidad, se ofrece un aislamiento completo de contenedor por sitio como una variante del controlador de aprovisionamiento: mismo motor, mismo plano de control, diferente ubicación, con mayor sobrecarga.
El aislamiento mediante LVE y CageFS, el WAF proactivo y el análisis de malware se incluyen para todos los clientes, porque un sitio infectado o fuera de control amenaza a sus vecinos y nuestra reputación de IP. La limpieza de malware con un solo clic y los niveles de protección avanzados son complementos de pago, la base no.
La tentación comercial en el sector del alojamiento web es vender seguridad por niveles: colocar a los clientes de bajo coste en un servidor compartido con límites flexibles, y cobrar a los que se preocupan por tener un aislamiento. Nosotros no lo hacemos, porque el cliente que no pagó por el aislamiento es precisamente aquel cuyo sitio web comprometido se convierte en el incidente de todos los demás.
Alojamos más de 650 000 sitios en todo el mundo, en una infraestructura donde la densidad es toda la propuesta económica. Eso solo funciona si el aislamiento subyacente es incondicional. Los contenedores a nivel de kernel, una vista de sistema de archivos privada, la limitación de bases de datos por sitio y PHP por sitio son el precio de operar a esa escala sin un destino compartido, por lo que están activados para todos, en cada plan, desde el primer sitio que implemente.
El resultado es una plataforma que se comporta de forma predecible ante los malos días de los demás. Detrás de ella se encuentra una garantía de tiempo de actividad del 99,99 %, copias de seguridad externas e inmutables por sitio con restauraciones probadas y un registro de auditoría completo de cada acción de cumplimiento aplicada en sus sitios.
El aislamiento está diseñado específicamente para evitar eso. LVE limita la CPU, la RAM, el IO, los IOPS y los procesos por sitio, MySQL Governor regula el uso de bases de datos por sitio y los trabajadores de LSAPI están confinados dentro de la propia jaula del sitio, por lo que el aumento de tráfico o la carga de consultas pesadas de un vecino se limita en función de su propio límite, no del tuyo. Cada fallo se registra por sitio, y el motor de políticas puede reducir automáticamente los límites de un sitio problemático.
La respuesta sincera es el aislamiento más que una garantía. CageFS ofrece a cada inquilino una vista de sistema de archivos aislada —un inquilino comprometido no puede ver a otros inquilinos, sus sitios ni archivos sensibles del sistema—, y un caso confirmado de malware o phishing traslada ese sitio a cuarentena: desconectado, archivos bloqueados, sin ejecución y aislado para análisis forense. Eso es lo que limita el radio de impacto. Junto a esto, ejecutamos análisis de malware y un WAF proactivo en cada sitio, además de copias de seguridad externas e inmutables por sitio con restauraciones probadas, de modo que la recuperación nunca dependa del estado de la máquina en cuestión.
Se incluye en todos los planes. El aislamiento con LVE y CageFS, el WAF proactivo y el análisis de malware son la base para cada cliente, ya que un sitio infectado o fuera de control amenaza a sus vecinos y nuestra reputación de IP; no podemos dejarlo como opcional de manera sensata. Lo que se vende como complemento es la limpieza y remediación de malware con un solo clic, y niveles de protección avanzados como reglas de WAF mejoradas, análisis prioritario, gestión de bots y niveles de DDoS superiores.
Está limitada dentro de su propia jaula en lugar de estar desactivada. Limitada significa límites LVE más estrictos y limitación de tasa con el sitio aún activo y funcionando, y se recupera automáticamente una vez que desaparece la causa. Se le notifica con el motivo, la transición se registra con su evidencia y se puede apelar. Si la carga es un crecimiento genuino en lugar de un fallo, la solución es un plan superior, no una limitación permanente.
No — un sitio suspendido muestra una página de retención personalizada y específica para cada motivo (facturación, mantenimiento o abuso) para que parezca intencional en lugar de roto. La suspensión se revierte con el pago, la corrección o una apelación. La cuarentena es más estricta y funciona de otra manera: se revierte únicamente después de la limpieza y revisión, nunca de forma automática.
En Zinn® Managed WordPress, sí — CloudLinux alt-PHP ofrece a cada sitio su propio selector de versión de PHP, sus propias extensiones como imagick, gd y redis, y su propia configuración endurecida, todo limitado por los límites de LVE de ese sitio. Footprint-Free Hosting ejecuta deliberadamente una configuración por sitio más estandarizada y bloqueada, porque la variedad de configuraciones es en sí misma una huella.
Sí. CloudLinux LVE y CageFS es el valor predeterminado optimizado para la densidad en ambas líneas de productos. Para cargas de trabajo que necesitan un límite más estricto, se ofrece un aislamiento completo de contenedor por sitio como una variante del controlador de aprovisionamiento: el mismo motor y plano de control con diferente ubicación, cambiando sobrecarga por una separación más fuerte.
Sí. El alojamiento Footprint-Free comienza con una prueba de 14 días sin tarjeta que cubre hasta cinco sitios, sin datos de pago ni compromiso. Despliegue algunos sitios, genere algo de carga en ellos y compruebe cómo se comportan los contenedores antes de decidirse.
Inicia una prueba de 14 días sin tarjeta en Footprint-Free Hosting: hasta cinco sitios, sin datos de pago y sin compromiso. El aislamiento a nivel de kernel, el WAF proactivo y el análisis de malware están incluidos desde el primer despliegue.
Empieza gratis