Servidor dedicado frente a alojamiento compartido gestionado: ¿quién controla tu configuración de seguridad?

En el alojamiento compartido gestionado, el proveedor de alojamiento se encarga de la configuración del servidor.

Ellos deciden qué versiones de TLS se admiten, cómo se aplican los encabezados de seguridad, cuándo se actualiza el software y qué puedes modificar. En un servidor dedicado, lo decides tú. Esa distinción no importa mucho cuando todo funciona bien. Pero sí importa mucho cuando una auditoría de seguridad, una revisión de riesgos de proveedores o un informe de SecurityScorecard señala problemas específicos que tu entorno actual no te permite resolver. La respuesta sincera a esa pregunta es: depende de quién sea el propietario del servidor.

En este artículo se explica exactamente qué decisiones de configuración de seguridad se toman a nivel del servidor, por qué los entornos de alojamiento gestionado limitan tu acceso a ellas y qué cambia realmente cuando te pasas a un servidor dedicado con acceso de root.

¿Qué significa «gestionado» en el ámbito de la seguridad?

El alojamiento gestionado es una solución de compromiso, no un inconveniente. El proveedor se encarga de la infraestructura para que tú puedas centrarte en tu sitio web. Eso incluye la configuración del servidor, las actualizaciones de software, el mantenimiento del hardware y, sí, la configuración de seguridad. El resultado es una forma más rápida de poner en marcha tu sitio web, con menos complicaciones técnicas.

La contrapartida es que «gestionado» también significa «configurado por otra persona». El servidor web, el sistema operativo, el cortafuegos, la pila TLS... Todos esos componentes se configuran según los estándares del proveedor, no los tuyos. Sus estándares se establecen una vez, se aplican de forma generalizada en un entorno compartido que da servicio a muchos clientes y se actualizan según el calendario del proveedor.

Esto funciona bien para la gran mayoría de las necesidades de alojamiento web. Sin embargo, para las empresas que deben cumplir con estándares de seguridad específicos, satisfacer los requisitos de contratación de las grandes empresas o subsanar las deficiencias detectadas en una evaluación de seguridad externa, esto supone un límite difícil de sortear sin cambiar de entorno de alojamiento.

¿Qué decisiones de seguridad se toman a nivel del servidor?

Hay varias configuraciones de seguridad que se encuentran totalmente al margen del código de tu aplicación y de tu sistema de gestión de contenidos. Se configuran en el software del servidor web —Apache, cPanel, Nginx o LiteSpeed— y en la configuración del sistema operativo. Ni el panel WordPress , ni el gestor cPanel , ni siquiera el acceso FTP tienen nada que ver con ellas.

Versiones del protocolo TLS. El hecho de que tu servidor acepte conexiones TLS 1.0, 1.1, 1.2 o 1.3 se controla en el archivo de configuración SSL del servidor web. La IETF dejó de recomendar el uso de TLS 1.0 y 1.1 en 2021 debido a vulnerabilidades criptográficas conocidas. Que sigan activadas en tu sitio web depende totalmente de cómo esté configurado el servidor para aceptarlas.

Conjuntos de cifrado. Los algoritmos de cifrado que tu servidor ofrece durante el protocolo de enlace TLS son una configuración independiente, aunque relacionada. Los conjuntos de cifrado débiles —esos que usan RC4, 3DES o longitudes de clave de nivel de exportación— aparecen como hallazgos distintos en las plataformas de evaluación de seguridad, incluso aunque hayas actualizado las versiones de TLS. Para eliminarlos, hay que editar la misma configuración a nivel del servidor.

Encabezados de seguridad HTTP. Encabezados como HTTP Strict Transport Security (HSTS), Content Security Policy (CSP), X-Content-Type-Options y X-Frame-Options son enviados por el servidor web con cada respuesta HTTP. Para añadirlos de forma fiable, se necesita una directiva en la configuración del host virtual del servidor web o una regla .htaccess en los servidores Apache. El servidor web los envía antes de que la capa de aplicación llegue a procesar la solicitud.

Configuración del certificado. El algoritmo de firma, la compatibilidad con la revocación (OCSP stapling) y las opciones de implementación de un certificado TLS se establecen al instalar y configurar el certificado en el servidor. Un complemento de aplicación no puede modificarlos a posteriori.

Frecuencia de aplicación de parches de software. La versión de PHP, OpenSSL y el núcleo de Linux que se ejecuta en el servidor la decide quien se encarga de gestionar las actualizaciones de paquetes. La rapidez con la que se corrige una vulnerabilidad CVE crítica —en comparación con la rapidez con la que aparece en un análisis— depende de la agenda y la autoridad de esa persona.

¿Qué ajustes de seguridad controla el alojamiento gestionado en tu nombre?

WordPress gestionado WordPress gestionan bien la seguridad dentro de su modelo. WP Engine, por ejemplo, ofrece un cortafuegos gestionado que bloquea los ataques más comunes, actualizaciones automáticas de plugins y supervisión las 24 horas del día con una respuesta rápida ante amenazas y malware. Estas medidas de protección son reales y, para muchos sitios web, resultan suficientes.

La limitación es que las decisiones en materia de seguridad las toma el proveedor, no el cliente.

WP Engine controla de cerca ciertos ajustes para proteger el rendimiento del servidor o por motivos de seguridad. En la documentación de su plataforma se enumeran una serie de configuraciones que los clientes no pueden modificar por su cuenta. Para algunas es necesario enviar una solicitud de asistencia, sin que se garantice un plazo de respuesta. Las revisiones en WordPress, por ejemplo, no se pueden habilitar en los archivos wp-config.php o php.ini, ya que esos ajustes se sobrescribirán a nivel del servidor.

En cuanto a TLS, WP Engine ha dejado de admitir las versiones 1.0 y 1.1 en toda la plataforma, y los clientes no tienen la opción de posponer la actualización ni de elegir una versión inferior a TLS 1.2. Se trata de una buena práctica de seguridad y resuelve esos hallazgos concretos. Pero lo contrario también es cierto: los clientes no pueden ir más allá de los valores predeterminados de TLS de la plataforma, no pueden seleccionar configuraciones específicas de conjuntos de cifrado y no pueden tomar decisiones sobre la implementación de certificados que difieran de lo que ofrece la plataforma.

En cuanto a los encabezados de seguridad HTTP, hay que leer con atención. Es posible añadir encabezados de seguridad desde dentro WordPress mediante un plugin o una entrada personalizada en el archivo functions.php—, pero se trata de una aplicación a nivel de capa de aplicación. Es posible que un escáner de seguridad que compruebe lo que envía el servidor a nivel de red no detecte estos encabezados de la misma manera que los que se configuran directamente en el servidor web. Los encabezados de seguridad HTTP funcionan mejor cuando se configuran a nivel del servidor web, es decir, en tu cuenta de alojamiento. En una plataforma gestionada, es el proveedor quien decide si esos encabezados se configuran a nivel del servidor o cómo los gestiona la capa CDN entre el cliente y el servidor de origen. En la Red Avanzada de WP Engine, el tráfico pasa por Cloudflare nivel de DNS. Los encabezados que Cloudflare , elimina o modifica durante el tránsito dependen de cómo WP Engine haya configurado esa integración, no de lo que pongas en un archivo .htaccess.

¿Por qué es tan difícil configurar la política de seguridad de contenidos en un alojamiento gestionado?

La Política de Seguridad de Contenidos (CSP) es el encabezado cuya ausencia se señala con mayor frecuencia en las auditorías de seguridad externas. La CSP indica al navegador exactamente qué fuentes de scripts, hojas de estilo, imágenes y otros recursos pueden cargarse en tus páginas. La ausencia de una CSP es un hallazgo habitual en SecurityScorecard, SecurityHeaders.io y la mayoría de los análisis de cumplimiento de la norma PCI.

Para implementar CSP correctamente se necesitan dos cosas: una política bien definida que se adapte a las dependencias específicas de los recursos de tu sitio web, y que ese encabezado de política se envíe de forma fiable con cada respuesta. La segunda parte es la que suele dar problemas en entornos gestionados.

En un servidor Apache, puedes añadir una CSP directamente al archivo .htaccess, lo que aplica la política a todo el sitio y es más seguro que usar metaetiquetas. En un Nginx , se añade al bloque del servidor en la configuración del host virtual. Ambos métodos requieren poder escribir y recargar los archivos de configuración del servidor. En una WordPress gestionada, esos archivos pertenecen al proveedor.

Los plugins pueden insertar encabezados CSP a través de PHP header() función, pero esto genera varios puntos de fallo: las capas de almacenamiento en caché pueden suprimir o anular los encabezados generados por PHP, es posible que los nodos periféricos de la CDN no los propaguen de forma coherente y cualquier cambio en la configuración de la CDN por parte del proveedor puede interrumpir la entrega sin que te des cuenta. Los entornos en los que no puedes acceder a los archivos sin procesar del servidor a través de cPanel, FTP o SSH requieren el uso de un plugin, lo que conlleva un mayor riesgo de implementación.

El resultado es una situación en la que puedes hacer todo el trabajo para implementar un CSP, comprobar que «funciona» en tu navegador, enviar un ticket de soporte solicitando la configuración a nivel de servidor y, aun así, que el encabezado siga apareciendo de forma inconsistente en un análisis automático.

¿Cómo cambia un servidor dedicado tus opciones de configuración de seguridad?

El acceso de root significa que tú controlas la configuración. Cada una de las decisiones de seguridad descritas anteriormente se convierte en un archivo de configuración que puedes editar, recargar y verificar.

Para desactivar TLS 1.0 y 1.1 en un servidor Apache, solo hace falta añadir una línea en la configuración de SSL y reiniciar el servicio. Añadir restricciones a los conjuntos de cifrado —eliminando RC4, 3DES y los de nivel de exportación— requiere unas cinco líneas más. Estos cambios se aplican de inmediato y se pueden comprobar con herramientas como openssl s_client o Qualys SSL Labs antes y después.

Para añadir HSTS a todas las respuestas, basta con incluir una sola directiva en el bloque del host virtual:

Establece siempre en el encabezado Strict-Transport-Security «max-age=31536000; includeSubDomains»

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

El CSP se configura de la misma manera, aplicándose a todas las respuestas del servidor de origen, sin pasar por un complemento de aplicación. X-Content-Type-Options, X-Frame-Options y Referrer-Policy son tres líneas adicionales.

La configuración del certificado —el uso de OCSP Stapling para la gestión de revocaciones, la elección de un algoritmo de firma y la configuración de las opciones de implementación— se realiza en el momento del aprovisionamiento y se puede actualizar en cualquier momento sin necesidad de ponerse en contacto con el proveedor.

Tú decides la frecuencia de las actualizaciones, con una salvedad importante: en un servidor no gestionado, la responsabilidad recae también sobre ti. En los servidores dedicados gestionados InMotion Hosting, InMotion se encarga del software y la infraestructura a nivel del servidor, mientras que los clientes conservan el acceso de root para realizar sus propios cambios en la configuración de seguridad.

Servidor dedicado frente a alojamiento compartido gestionado: ¿qué ajustes de seguridad puedes controlar?

Comparemos lo que permite cada entorno.

La columna de la derecha no significa «sin ayuda». Significa que las decisiones las tomas tú, con la ayuda de expertos cuando la necesites.

¿Cubre la certificación de seguridad de tu proveedor tus requisitos específicos?

Este es el matiz que a menudo se pasa por alto en los artículos comparativos. Las plataformas gestionadas como WP Engine cuentan con prácticas de seguridad serias y fiables. WP Engine cuenta con las certificaciones SOC 2 Tipo II e ISO 27001:2022, y limita el acceso de escritura al disco a nivel de proceso para reforzar la seguridad del entorno frente a la inyección de malware a través de temas o plugins vulnerables.

Esas certificaciones reflejan el nivel de seguridad del proveedor. Documentan cómo protege el proveedor la infraestructura compartida. Lo que no abordan es si la superficie de ataque externa de tu organización —las direcciones IP, los nombres de dominio y los servidores asociados a tu negocio— cumple con los requisitos específicos de configuración de seguridad de tus clientes, auditores o plataformas de evaluación de seguridad.

Una empresa que tiene un programa de gestión de riesgos de proveedores comprueba tu puntuación en SecurityScorecard, no el informe SOC 2 de tu proveedor. Un auditor certificado PCI (QSA) que evalúa tu entorno revisa la configuración TLS del servidor por el que se transmiten los datos de los titulares de tarjetas, no la certificación general de cumplimiento del proveedor de alojamiento. Esas son las configuraciones que debes controlar.

¿Quién necesita realmente un servidor dedicado por motivos de seguridad?

No todos los sitios web lo hacen. El alojamiento compartido gestionado es adecuado y lo suficientemente seguro para sitios web que no tienen que cumplir con requisitos de auditorías de seguridad externas y que no procesan datos confidenciales sujetos a marcos de cumplimiento normativo.

Un servidor dedicado es una buena opción cuando:

• Tu SecurityScorecard o cualquier otra herramienta similar de evaluación de seguridad muestra resultados de configuración que requieren acceso a nivel de servidor para solucionarlos
• Un cliente empresarial o un equipo de compras te está pidiendo documentación sobre tus configuraciones de seguridad específicas, no solo la certificación del proveedor
• Estás trabajando para cumplir con la norma PCI DSS y necesitas controlar la configuración de TLS, la segmentación de la red y el calendario de actualizaciones en el servidor que procesa las transacciones
• Tu organización se ha sometido a una prueba de penetración o a una evaluación de seguridad que ha detectado problemas a nivel de servidor
• Te encargas de gestionar varias sedes de clientes y eres responsable de la seguridad de cada una de ellas

Las agencias que asumen la responsabilidad de la seguridad de las instalaciones de sus clientes —ya sea por contrato o simplemente por cuestiones de reputación— se dan cuenta a menudo de que los entornos gestionados compartidos dejan las decisiones de seguridad fuera de su control justo en los momentos en que más importan.

«En el alojamiento compartido gestionado, el proveedor de alojamiento controla la configuración del servidor… En un servidor dedicado, con los servicios profesionales que ofrece el equipo de administración de sistemas de InMotion Solutions, lo haces tú».

¿Qué debes tener claro antes de pasarte a un servidor dedicado?

Pasarse a un servidor dedicado es una decisión importante en materia de infraestructura. Antes de dar ese paso, aclara algunas cosas:

¿Qué incidencias concretas hay que solucionar? No todas las incidencias de SecurityScorecard requieren un servidor específico. Algunas se pueden solucionar mediante la configuración de una CDN, actualizaciones de DNS o cambios de proveedor de SSL. Identifica qué incidencias requieren específicamente acceso a la configuración a nivel de servidor.

¿Quién se encargará de la configuración del servidor? El acceso de root conlleva una gran responsabilidad. Si no cuentas con personal interno de administración de sistemas, ten en cuenta el coste del soporte técnico gestionado o de los servicios profesionales.

¿Qué es lo que especifica realmente tu requisito de cumplimiento? PCI DSS, SOC 2 e HIPAA tienen definiciones de alcance específicas. Asegúrate de que el cambio en la configuración del servidor que necesitas se encuentra dentro del alcance y que cumplirá con los requisitos de auditoría.

Los servidores dedicados InMotion Hostingincluyen acceso root completo y control a través de cPanel, con soporte técnico para la infraestructura gestionada por parte del equipo de InMotion. El paquete Premier Care añade la protección contra malware Monarx, 500 GB de almacenamiento para copias de seguridad y tiempo de consulta mensual con InMotion Solutions, el equipo interno de administradores de sistemas disponible para reforzar la seguridad, configurar TLS y realizar ajustes en el servidor orientados al cumplimiento normativo. Echa un vistazo a los planes de servidores dedicados o ponte en contacto con nuestro equipo para hablar de tus necesidades específicas de seguridad.

Todos los servidores VPS o dedicados pueden cumplir con la norma PCI-DSS con nuestra ayuda, tanto para los clientes que trabajan con nosotros como para su entidad certificadora de PCI.