Aislamiento por sitio
El aislamiento es la diferencia entre un incidente y una caída del servicio. Cada sitio que alojamos se ejecuta dentro de un entorno CloudLinux LVE a nivel de kernel con sus propios límites de CPU, RAM, E/S y procesos, su propia vista del sistema de archivos CageFS, su propia versión de PHP y su propia limitación de base de datos. Un sitio que sufre un ataque, se ve comprometido o simplemente ejecuta una consulta pesada queda contenido en su espacio — y el aislamiento base está incluido en todos los planes, no se le vende como una mejora adicional. Disponibilidad: la limitación de base de datos por sitio y las estadísticas de recursos por sitio están en desarrollo activo y aún no se encuentran disponibles. Todo lo demás descrito aquí está operativo hoy mismo.
La flota de trabajadores ejecuta CloudLinux OS, lo que traslada el multiarrendamiento al núcleo del sistema. Cada sitio recibe un Entorno Virtual Ligero —un LVE— que constituye un límite estricto y no una mera convención de cortesía. Nada de lo que un sitio haga dentro de su jaula se puede descontar del presupuesto de otra persona.
LVE limita la CPU, la RAM, la IO, las IOPS, los procesos y los procesos de entrada de 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 adyacentes continúan funcionando sin verse afectados.
Un plugin atascado en un bucle, una tarea cron mal escrita o un rastreador que sobrecarga un endpoint alcanzan primero los límites de procesos y de procesos de entrada del propio sitio. Un solo sitio no puede simplemente consumir toda la máquina.
Debido a que los procesos de entrada están limitados por jaula, un aluvión dirigido a un solo sitio no puede abrir procesos ilimitados en el host. La limitación de conexiones y solicitudes de LiteSpeed y el cortafuegos de red Imunify360 se sitúan por delante de eso, por lo que el ataque sigue siendo un problema únicamente del objetivo.
Cada fallo de LVE se registra por sitio y se envía al motor de directivas de la plataforma, que puede restringir o flexibilizar los límites automáticamente. Podrá ver por qué se limitó un sitio y cuándo: de forma gradual, reversible y registrada.
El aislamiento de recursos evita que un sitio sobrecargue el sistema. El aislamiento del sistema de archivos evita que sea indiscreto. CageFS proporciona a cada inquilino una vista privada y restringida de la máquina.
Bajo CageFS, un usuario solo ve sus propios archivos y un conjunto mínimo y saneado de binarios del sistema, y no puede ver a otros usuarios, los sitios de otros usuarios ni archivos confidenciales del sistema. El fallo habitual del alojamiento compartido, en el que una cuenta comprometida se convierte en un punto de lectura sobre todas las demás cuentas del servidor, queda bloqueado a nivel del kernel.
Esto importa sobre todo el día en que algo sale mal. Si un sitio se ve comprometido —a través de un plugin obsoleto, una credencial robada, un tema vulnerable—, CageFS es lo que mantiene el radio de impacto en esa única jaula. Nuestra especificación de seguridad es deliberada en su redacción: CageFS contiene las brechas. La contención es la afirmación honesta, y es la que decide si un incidente es una limpieza de un solo sitio o de toda la flota.
Las copias de seguridad refuerzan el mismo límite. Las copias de seguridad por sitio son inmutables, externas y aisladas de la infraestructura en ejecución, con restauraciones probadas, de modo que incluso el peor escenario de vulneración en un sitio dispone de una vía 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 de la historia. En una flota de WordPress, lo que con mayor frecuencia hace que un servidor se sienta lento son las consultas de un sitio, no su tráfico. Esto se gestiona de forma explícita.
CloudLinux MySQL Governor modera el uso de la base de datos por sitio, de modo que las consultas pesadas de un solo sitio no puedan ralentizar el servidor para los demás. Es el control antidesaceleración y funciona tanto si el sitio ruidoso se percata de que está siendo restringido como si no.
La flota ejecuta MariaDB (o Percona), seleccionada específicamente para cargas de trabajo de WordPress en lugar de heredarse de forma predeterminada, con Governor encima de ella como la capa de equidad por inquilino.
Una caché de objetos Redis por sitio absorbe las lecturas repetidas antes de que lleguen a la base de datos, lo que reduce desde el principio la presión que Governor debe arbitrar. El almacenamiento en caché y el aislamiento funcionan como un único sistema.
CloudLinux alt-PHP proporciona a cada sitio su propio selector de versión de PHP, sus propias extensiones (imagick, gd, redis y las demás) y su propia configuración reforzada, con procesos de trabajo LSAPI limitados por los límites LVE de ese sitio, de modo que la concurrencia de PHP forma parte de la jaula en lugar de ser una forma de escapar de ella.
El aislamiento determina hasta dónde se propaga un problema. La aplicación de medidas determina qué sucede a continuación. Hemos sustituido la suspensión drástica de encendido/apagado por una máquina de estados, impulsada por flujos de trabajo duraderos y aplicada en el worker 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 del sustrato, por lo que es idéntico ya sea que usted gestione una sola tienda WooCommerce o dos mil sitios de red.
Las redes masivas y de PBN se ejecutan sobre el mismo sustrato de LVE y CageFS, junto con una rotación de cuentas de CDN consciente de la huella digital y entrega de HTML estático. El aislamiento es lo que hace que la densidad sea segura: los sitios comparten una flota sin compartir el mismo destino.
Los sitios administrados de WordPress, WooCommerce, PHP, estáticos y Node obtienen los mismos entornos aislados más un autoservicio completo: su propia versión y extensiones de PHP, caché de objetos Redis, entornos de prueba (staging) y publicación en producción.
Para cargas de trabajo que requieren un límite más estricto que el predeterminado optimizado para la densidad, se ofrece un aislamiento completo de contenedor por sitio como variante del controlador de aprovisionamiento: el mismo motor, el mismo plano de control, diferente ubicación y una mayor sobrecarga.
El aislamiento de LVE y CageFS, el WAF proactivo y el análisis de malware están incluidos para cada cliente, ya que un sitio infectado o fuera de control amenaza a sus vecinos y a nuestra reputación de IP. La limpieza de malware con un solo clic y los niveles de protección avanzada son complementos de pago; la protección básica no lo es.
La tentación comercial en el alojamiento web es vender la seguridad por niveles: colocar a los clientes económicos en un servidor compartido con límites flexibles y cobrar a quienes se preocupan por tener un límite estricto. Nosotros no lo hacemos, porque el cliente que no pagó por el aislamiento es precisamente aquel cuyo sitio comprometido se convierte en un incidente para todos los demás.
Alojamos más de 700 000 sitios en todo el mundo, en una flota donde la densidad es toda la propuesta económica. Eso solo funciona si el aislamiento subyacente es incondicional. Jaulas a nivel de kernel, una vista privada del sistema de archivos, limitación de base de datos por sitio y PHP por sitio son el precio de operar a esa escala sin un destino compartido; por lo tanto, están activos para todos, en cada plan, desde el primer sitio que implemente.
El resultado es una plataforma que se comporta de manera predecible incluso en los peores días de los demás. Detrás de ella se encuentra una garantía de disponibilidad del 99.99%, copias de seguridad externas inmutables por sitio con restauraciones probadas y un registro de auditoría completo de cada medida de cumplimiento adoptada en sus sitios.
El aislamiento está diseñado específicamente para evitar eso. LVE limita CPU, RAM, IO, IOPS y procesos por sitio, MySQL Governor regula el uso de la base de datos por sitio y los procesos de trabajo de LSAPI están delimitados por el cage propio del sitio — de modo que un pico de tráfico o una carga pesada de consultas de un vecino se limita contra su propio techo, no el de usted. Cada fallo se registra por sitio, y el motor de directivas puede ajustar automáticamente los límites de un sitio ruidoso.
La respuesta sincera es contención antes que una garantía. CageFS proporciona a cada cliente una vista aislada del sistema de archivos —un cliente comprometido no puede ver a otros clientes, sus sitios ni los archivos confidenciales del sistema— y un caso confirmado de malware o phishing traslada ese sitio a cuarentena: fuera de línea, archivos bloqueados, sin ejecución y aislado para análisis forense. Eso es lo que limita el radio de impacto. Junto con 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 del equipo afectado.
Está incluido en todos los planes. El aislamiento de LVE y CageFS, el WAF proactivo y el escaneo de malware son la base para cada cliente, ya que un sitio infectado o descontrolado amenaza a sus vecinos y a nuestra reputación de IP; no podemos dejarlo como opcional de manera sensata. Lo que se vende como complemento es la limpieza y solución de malware con un solo clic, así como niveles de protección avanzados como reglas de WAF mejoradas, escaneo prioritario, gestión de bots y niveles superiores de DDoS.
Se aplica una limitación (throttle) dentro de su propia jaula en lugar de desactivarse. La limitación implica límites de LVE más estrictos y limitación de tasa (rate limiting) mientras el sitio sigue activo y prestando servicio, y se recupera automáticamente en cuanto desaparece la causa. Se le notificará el motivo, la transición queda registrada con sus pruebas y es apelable. Si la carga se debe a un crecimiento real y no a un fallo, la solución es un plan superior, no una limitación permanente.
No: un sitio suspendido muestra una página de espera con la marca y el motivo específico (facturación, mantenimiento o abuso) para que se interprete como algo intencionado y no como un error. La suspensión se revierte tras el pago, la subsanación o una apelación. La cuarentena es más estricta y funciona de forma diferente: solo se revierte tras la limpieza y revisión, nunca automáticamente.
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 constituyen la opción predeterminada optimizada para la densidad en ambas líneas de productos. Para las cargas de trabajo que requieren 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 una ubicación diferente, intercambiando sobrecarga por una separación más sólida.
Sí. El alojamiento Footprint-Free comienza con una prueba de 14 días sin tarjeta que cubre hasta cinco sitios: sin datos de pago y sin compromiso. Implemente algunos sitios, envíeles algo de carga y compruebe cómo se comportan las jaulas 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.
Empiece gratis