Cómo aislar de forma segura a los usuarios de hosting en Linux

Publicado el 12 de noviembre de 2026

Un servidor compartido puede funcionar perfectamente durante meses, hasta que un sitio web comprometido lee un archivo que nunca debería poder ver. Por eso los equipos deben aislar de forma segura a los usuarios de hosting: no como un lujo reservado a las grandes empresas de hosting, sino como una regla básica para cualquier servidor que aloje más de un sitio, cliente o proyecto.

El aislamiento de usuarios limita los daños cuando una aplicación tiene un complemento vulnerable, una contraseña débil o un archivo subido que resulta ser malicioso. También evita que una cuenta muy ocupada ralentice los sitios web de los demás. El objetivo es sencillo: cada cliente debe tener el control suficiente para administrar sus propios sitios web, mientras el servidor mantiene límites claros con respecto a todo lo demás.

Qué significa realmente el aislamiento de usuarios de hosting

El aislamiento no se consigue con un único ajuste. Es un conjunto de capas que funcionan en conjunto. Como mínimo, una cuenta de hosting necesita su propio usuario de Linux, directorio personal, permisos de archivos, credenciales de base de datos, proceso de PHP y reglas de acceso. Un fallo en un sitio web no debería dar acceso automáticamente a todos los sitios del servidor.

Imagina un servidor compartido como un edificio de apartamentos. Un usuario de Linux independiente es la puerta del apartamento. Los permisos de archivo correctos son la cerradura. Los pools independientes de PHP-FPM, los usuarios de base de datos y los límites de recursos son las paredes, los servicios y los disyuntores. Una capa ayuda, pero confiar solo en una es lo que convierte pequeños incidentes en largas noches de trabajo.

El nivel adecuado de aislamiento depende de lo que alojes. Unos cuantos sitios internos con un administrador de confianza tienen necesidades distintas de las de un servidor de agencia con 80 cuentas de clientes. Para clientes sin relación entre sí, una separación más estricta compensa la configuración adicional y el mayor consumo de memoria.

Empieza con un usuario de Linux por cada cuenta de hosting

No ejecutes todos los sitios web bajo la misma cuenta del sistema. Si todos los archivos web pertenecen a un usuario web genérico, como `www-data`, cualquier script vulnerable que pueda escribir archivos también podría modificar el sitio de otro cliente.

Crea un usuario de Linux dedicado para cada cuenta de hosting y haz que ese usuario sea el propietario de su propia raíz de documentos, registros, archivos temporales y archivos de la aplicación. Evita, siempre que sea posible, los directorios compartidos con permisos de escritura. Un directorio en el que todas las cuentas pueden escribir acaba convirtiéndose en un lugar propicio para los problemas.

Establece permisos restrictivos de forma predeterminada. Los directorios de sitios web suelen necesitar `755`, mientras que los archivos normales pueden usar `644`. Los archivos de configuración que contienen secretos deben tener permisos más restrictivos, a menudo `600` o `640`, según la cuenta de servicio que deba leerlos. No recurras a `777` porque esté fallando una carpeta de carga. Eso soluciona el síntoma quitando la cerradura de la puerta.

La propiedad importa tanto como los permisos numéricos. Por ejemplo, un sitio de WordPress puede necesitar permiso de escritura en `wp-content/uploads`, pero el servicio web no debería necesitar permiso para reescribir toda la aplicación. Concede permisos de escritura solo a los directorios que realmente los necesiten.

Mantén los límites entre cuentas fuera de las rutas compartidas

Es tentador almacenar copias de seguridad, sesiones, cachés o archivos de implementación en una ubicación común. Puede resultar práctico hasta que cambien los permisos o una tarea de limpieza elimine los archivos equivocados. Guarda los datos de las aplicaciones de cada usuario en el directorio personal de esa cuenta o en otra ubicación cuyo propietario sea específicamente esa cuenta.

Si no queda más remedio que usar un servicio compartido, especifica explícitamente el acceso. Usa un grupo dedicado con los permisos mínimos necesarios, documenta por qué existe y revísalo después de los cambios. El acceso compartido «temporal» suele acabar siendo permanente.

Ejecuta PHP por separado para cada cuenta

En los sitios web PHP, el modelo de ejecución es una de las decisiones más importantes que tomarás. Ejecutar PHP mediante un proceso compartido significa que un sitio vulnerable podría heredar permisos que van mucho más allá de sus propios archivos. Usar un pool de PHP-FPM independiente para cada usuario de hosting crea un límite más claro: el proceso de PHP se ejecuta con el usuario de Linux de esa cuenta, con sus propios ajustes y límites de proceso.

Un pool de PHP-FPM por usuario también facilita la resolución de problemas. Si la aplicación de un cliente empieza a consumir procesos o memoria, puedes identificar el pool responsable en vez de tratar el servidor como un gran misterio. Establece límites a nivel del pool, como el número máximo de procesos secundarios y los tiempos de espera de las solicitudes, según el plan de la cuenta y las necesidades reales de la aplicación.

Hay una contrapartida. Más pools de PHP-FPM consumen más memoria que un único pool compartido, especialmente en un servidor virtual pequeño. Si el servidor solo tiene unos pocos sitios con poco tráfico, elige límites razonables en lugar de crear pools demasiado grandes. Pero no sacrifiques la separación de cuentas solo para ahorrar una cantidad modesta de RAM. Aumenta la capacidad antes de convertir a todos los inquilinos en una única zona de seguridad.

Aplica el mismo principio a las aplicaciones que no sean PHP. Ejecuta Node.js, Python, Ruby o servicios personalizados con usuarios dedicados. Usa servicios del sistema y archivos de entorno independientes, en lugar de una única cuenta compartida de aplicación con acceso a todos los proyectos.

Separa las bases de datos, las credenciales y los secretos

A menudo, el servidor de bases de datos es donde el aislamiento se debilita sin que nadie lo note. Dar a todas las aplicaciones el mismo inicio de sesión de administrador de la base de datos es práctico durante la configuración, pero supone un riesgo constante a partir de entonces. Cada sitio debe tener su propia base de datos y usuario de base de datos, con permisos limitados a esa base de datos.

No concedas privilegios globales a los usuarios de las aplicaciones ni permisos para crear usuarios nuevos o acceder a todos los esquemas, salvo que haya una razón operativa específica. Si se ven comprometidas las credenciales del CMS, deberían quedar expuestos los datos de una aplicación, no los registros de todos los clientes del servidor.

Trata los secretos con el mismo cuidado. Guarda las contraseñas de bases de datos, las claves de API y las credenciales de correo en archivos de configuración propiedad de cada cuenta. No los guardes en directorios web públicos, carpetas de control de versiones ni ubicaciones compartidas de copias de seguridad. Cuando un empleado, contratista o cliente ya no necesite acceso, elimínalo en lugar de suponer que las credenciales antiguas seguirán siendo inofensivas.

Controla el acceso al shell, SSH y las tareas programadas

No todos los usuarios de hosting necesitan SSH. Para un cliente que solo administra un sitio web básico, puede bastar con gestionar archivos desde el panel o mediante SFTP. Para desarrolladores y agencias, SSH puede ser muy útil para implementaciones, Composer, WP-CLI y la revisión de registros. La solución práctica no es bloquearlo en todas partes, sino concederlo deliberadamente.

Siempre que sea posible, usa claves SSH en lugar de contraseñas. Desactiva el inicio de sesión directo como root, evita las cuentas de administrador compartidas y proporciona cuentas independientes con nombre al personal para poder rastrear las acciones. Si un usuario solo necesita transferir archivos, considera restringir la cuenta a SFTP. Si necesita un shell, asegúrate de que no pueda leer los directorios personales de otros usuarios ni aprovechar vías peligrosas de escalada de privilegios.

Las tareas de cron requieren la misma atención. Ejecuta cada tarea programada con el usuario propietario, no como root ni bajo una cuenta web compartida. Una tarea de cron defectuosa puede llenar un disco, enviar miles de correos electrónicos o ejecutar repetidamente un script que consume muchos recursos. Establece límites claros y revisa las tareas que llevan mucho tiempo sin modificarse.

Establece límites de recursos para cada cuenta

La seguridad y la estabilidad convergen en el control de recursos. Una cuenta puede afectar a todas las demás sin acceder a sus archivos, simplemente agotando la CPU, la memoria, los procesos, el espacio en disco o los inodos. Los límites de recursos mantienen dentro de la cuenta que los provoca los picos de tráfico, las consultas defectuosas y los bucles accidentales.

Usa los controles compatibles con tu entorno Linux, como los límites de procesos, los ajustes de los pools de PHP-FPM, las cuotas de disco y los cgroups a nivel del sistema. Supervisa el uso real antes de establecer valores. Un límite demasiado bajo puede interrumpir el tráfico legítimo de comercio electrónico, las importaciones en segundo plano o las copias de seguridad. Un límite demasiado alto no sirve de mucho.

Como mínimo, realiza un seguimiento, siempre que sea posible, de la carga de CPU, la presión de memoria, el uso de disco, el uso de inodos, el número de procesos, los inicios de sesión fallidos y el volumen de correo saliente de cada cuenta. La supervisión en tiempo real transforma «el servidor parece lento» en una respuesta útil: qué usuario, qué proceso y cuándo empezó.

Añade mecanismos de contención, pero no los confundas con una solución definitiva

Los entornos chroot, los contenedores y la virtualización pueden establecer límites más estrictos entre usuarios. Los contenedores son especialmente útiles cuando los clientes necesitan entornos de ejecución personalizados, dependencias o control a nivel de servicio que, de otro modo, entrarían en conflicto en un mismo sistema operativo. Las máquinas virtuales ofrecen una separación aún más estricta, con un mayor coste operativo.

Estas herramientas ayudan, pero no sustituyen los permisos, la aplicación de parches ni el uso seguro de credenciales. Un contenedor que se ejecuta como root y tiene un montaje del host con permisos de escritura no establece un límite seguro entre inquilinos. Del mismo modo, una jaula chroot puede reducir el acceso visible al sistema de archivos, pero quizá no contenga todos los problemas a nivel de aplicación. Elige la capa que corresponda al riesgo y configúrala con cuidado.

Lista práctica de comprobación del aislamiento

Antes de añadir una cuenta de hosting, comprueba estos aspectos esenciales:

• La cuenta tiene su propio usuario de Linux, directorio personal, archivos del sitio web, registros y rutas temporales.
• PHP u otro entorno de ejecución de aplicaciones se ejecuta con ese usuario, no con una identidad de servicio compartida.
• La cuenta tiene credenciales de base de datos independientes con acceso únicamente a su propia base de datos.
• La propiedad y los permisos de los archivos impiden las lecturas y escrituras entre cuentas.
• El acceso a SSH, SFTP, las tareas de cron, las copias de seguridad y los límites de recursos se concede y configura para esa cuenta específica.

Un panel de control debería mostrar claramente estos límites en lugar de ocultarlos tras la jerga del servidor. FASTPANEL ayuda a los administradores a gestionar cuentas, dominios, bases de datos y actividad del servidor independientes desde un espacio de trabajo claro, lo que facilita mantener un buen aislamiento a medida que crece el servidor.

Sigue comprobándolo después de la configuración

El aislamiento no es una tarea que se completa una vez y se olvida. Los complementos nuevos, los scripts de migración, los cambios manuales de permisos y las correcciones urgentes de soporte pueden debilitarlo con el tiempo. Revisa la propiedad de las cuentas después de migrar sitios, busca archivos con permisos de escritura para todo el mundo, elimina los usuarios inactivos, aplica actualizaciones de seguridad y prueba las copias de seguridad sin conceder a los procesos de copia de seguridad acceso innecesario a todas las cuentas.

La mejor configuración es aquella que tu equipo puede entender y mantener bajo presión. Establece límites claros para cada usuario, documenta las excepciones y haz que sean poco frecuentes; así, el servidor podrá evitar discretamente que el mal día de un sitio web se convierta en un problema para todos.