Serveur dédié ou hébergement mutualisé géré : qui gère ta configuration de sécurité ?

Dans le cadre d'un hébergement mutualisé géré, c'est le fournisseur d'hébergement qui gère la configuration du serveur.

Ce sont eux qui décident quelles versions TLS prendre en charge, comment appliquer les en-têtes de sécurité, quand mettre à jour les logiciels et ce que tu as le droit de modifier. Sur un serveur dédié, c'est toi qui décides. Cette distinction n'a pas beaucoup d'importance quand tout fonctionne bien. Elle prend toute son importance lorsqu'un audit de sécurité, une évaluation des risques fournisseurs ou un rapport SecurityScorecard signale des problèmes spécifiques que ton environnement actuel ne te permet pas de résoudre. La réponse honnête à cette question est : ça dépend de qui est propriétaire du serveur.

Cet article explique précisément quelles décisions de configuration de sécurité relèvent du serveur, pourquoi les environnements d'hébergement géré limitent ton accès à celles-ci, et ce qui change concrètement lorsque tu passes à un serveur dédié avec accès root.

Qu'est-ce que « géré » signifie en matière de sécurité ?

L'hébergement géré est un compromis, pas un défaut. Le fournisseur s'occupe de l'infrastructure pour que tu puisses te concentrer sur ton site. Ça inclut la configuration du serveur, les mises à jour logicielles, la maintenance du matériel et, bien sûr, la configuration de la sécurité. Résultat : ton site est opérationnel plus rapidement, avec moins de contraintes techniques.

Le revers de la médaille, c'est que « géré » signifie aussi « configuré par quelqu'un d'autre ». Le serveur web, le système d'exploitation, le pare-feu, la pile TLS… tous ces composants sont configurés selon les normes du fournisseur, pas les tiennes. Leurs normes sont définies une fois pour toutes, appliquées à l'ensemble d'un environnement partagé desservant de nombreux clients, et mises à jour selon le calendrier du fournisseur.

Ça fonctionne très bien pour la grande majorité des besoins en hébergement. Par contre, pour les entreprises qui doivent respecter des normes de sécurité spécifiques, satisfaire aux exigences d'achat de leur structure ou corriger les failles relevées lors d'une évaluation de sécurité externe, ça crée une limite difficile à contourner sans changer d'environnement d'hébergement.

Quelles décisions de sécurité sont prises au niveau du serveur ?

Plusieurs paramètres de sécurité existent en dehors du code de ton application et de ton système de gestion de contenu. Ils sont définis dans le logiciel du serveur web — Apache, cPanel, Nginx ou LiteSpeed — et dans la configuration du système d'exploitation. Le panneau WordPress , le gestionnaire cPanel et même l'accès FTP n'y ont aucune incidence.

Versions du protocole TLS. C'est dans le fichier de configuration SSL du serveur web que l'on définit si ton serveur accepte les connexions TLS 1.0, 1.1, 1.2 ou 1.3. Les versions TLS 1.0 et 1.1 ont été dépréciées par l'IETF en 2021 en raison de failles cryptographiques connues. Leur activation sur ton site dépend entièrement de la configuration du serveur.

Suites de chiffrement. Les algorithmes de chiffrement que ton serveur propose lors de la négociation TLS constituent une configuration distincte, mais étroitement liée. Les suites de chiffrement faibles — celles qui utilisent RC4, 3DES ou des longueurs de clé de type « export » — apparaissent comme des problèmes distincts sur les plateformes d'évaluation de la sécurité, même si tu as mis à jour les versions TLS. Pour les supprimer, il faut modifier cette même configuration au niveau du serveur.

En-têtes de sécurité HTTP. Des en-têtes tels que HTTP Strict Transport Security (HSTS), Content Security Policy (CSP), X-Content-Type-Options et X-Frame-Options sont envoyés par le serveur web à chaque réponse HTTP. Pour les ajouter de manière fiable, il faut soit ajouter une directive dans la configuration de l'hôte virtuel du serveur web, soit définir une règle .htaccess sur les serveurs Apache. Le serveur web les envoie avant même que la couche applicative ne traite la requête.

Configuration du certificat. L'algorithme de signature, la prise en charge de la révocation (OCSP stapling) et les options de déploiement d'un certificat TLS sont définis lors de l'installation et de la configuration du certificat sur le serveur. Un plugin d'application ne peut pas modifier ces paramètres a posteriori.

Rythme des mises à jour logicielles. La version de PHP, d'OpenSSL et du noyau Linux utilisée sur le serveur est déterminée par la personne chargée de gérer les mises à jour des paquets. La rapidité avec laquelle une vulnérabilité CVE critique est corrigée — par rapport à la rapidité avec laquelle elle apparaît lors d'un scan — dépend de l'emploi du temps et des compétences de cette personne.

Quels paramètres de sécurité l'hébergement géré gère-t-il pour toi ?

WordPress gérés gèrent bien la sécurité dans le cadre de leur modèle. WP Engine, par exemple, propose un pare-feu géré qui bloque les attaques courantes, des mises à jour automatisées des plugins et une surveillance 24 heures sur 24 avec une réponse rapide aux menaces et aux logiciels malveillants. Ces protections sont bien réelles, et pour de nombreux sites, elles sont suffisantes.

Le problème, c'est que c'est au fournisseur de prendre les décisions en matière de sécurité, pas au client.

WP Engine gère de près certains paramètres afin de préserver les performances du serveur ou pour des raisons de sécurité. La documentation de leur plateforme répertorie un ensemble de configurations que les clients ne peuvent pas modifier eux-mêmes. Pour certaines, il faut envoyer une demande d'assistance, sans garantie de délai de réponse. Les révisions dans WordPress, par exemple, ne peuvent pas être activées dans les fichiers wp-config.php ou php.ini, car ces paramètres seront écrasés au niveau du serveur.

En ce qui concerne le protocole TLS, WP Engine a déprécié les versions 1.0 et 1.1 sur l'ensemble de la plateforme, et les clients n'ont pas la possibilité de reporter la mise à niveau ou d'opter pour une version antérieure à TLS 1.2. C'est une bonne pratique en matière de sécurité, et ça résout ces problèmes spécifiques. Mais l'inverse est également vrai : les clients ne peuvent pas aller au-delà des paramètres TLS par défaut de la plateforme, ne peuvent pas sélectionner de configurations spécifiques de suites de chiffrement et ne peuvent pas prendre de décisions de déploiement de certificats qui diffèrent de ce que la plateforme propose.

En ce qui concerne les en-têtes de sécurité HTTP, il faut bien comprendre la situation. Il est possible d'ajouter des en-têtes de sécurité depuis WordPress via un plugin ou une entrée personnalisée dans le fichier functions.php —, mais cela se fait au niveau de la couche application. Un scanner de sécurité qui vérifie ce que le serveur envoie au niveau réseau pourrait ne pas percevoir ces en-têtes de la même manière que ceux définis dans la configuration du serveur web. Les en-têtes de sécurité HTTP fonctionnent mieux lorsqu'ils sont définis au niveau du serveur web, c'est-à-dire sur ton compte d'hébergement. Sur une plateforme gérée, c’est au fournisseur de décider si ces en-têtes sont définis au niveau du serveur, ou comment la couche CDN entre le client et le serveur d’origine les gère. Sur le réseau avancé de WP Engine, le trafic passe par Cloudflare niveau DNS. Les en-têtes que Cloudflare , supprime ou modifie en transit dépendent de la façon dont WP Engine a configuré cette intégration, et non de ce que tu mets dans un fichier .htaccess.

Pourquoi est-ce si difficile de configurer la politique de sécurité du contenu sur un hébergement géré ?

La politique de sécurité du contenu (CSP) est l'en-tête dont l'absence est le plus souvent signalée lors des audits de sécurité externes. La CSP indique précisément au navigateur quelles sources de scripts, de feuilles de style, d'images et d'autres ressources sont autorisées à se charger sur tes pages. L'absence de CSP est un constat récurrent sur SecurityScorecard, SecurityHeaders.io et la plupart des analyses de conformité PCI.

Pour mettre en œuvre correctement le CSP, deux éléments sont indispensables : une politique bien définie, adaptée aux dépendances spécifiques de ton site en matière de ressources, et la transmission fiable de cet en-tête de politique à chaque réponse. C'est justement ce deuxième point qui pose problème dans les environnements gérés.

Sur un serveur Apache, tu peux ajouter une politique CSP directement dans ton fichier .htaccess, ce qui permet d'appliquer la politique à l'ensemble du site et offre une sécurité supérieure à celle des balises meta. Sur un Nginx , tu l'ajoutes au bloc serveur dans la configuration de l'hôte virtuel. Ces deux méthodes nécessitent de pouvoir modifier et recharger les fichiers de configuration du serveur. Sur une WordPress gérée, ces fichiers appartiennent au fournisseur.

Les plugins peuvent insérer des en-têtes CSP via PHP header() fonction, mais cela crée plusieurs sources de défaillance : les couches de mise en cache peuvent supprimer ou remplacer les en-têtes générés par PHP, les nœuds périphériques du CDN peuvent ne pas les propager de manière cohérente, et toute modification de la configuration du CDN par le fournisseur peut interrompre la diffusion sans que tu t'en rendes compte. Les environnements dans lesquels tu ne peux pas accéder aux fichiers bruts du serveur via cPanel, FTP ou SSH nécessitent l'utilisation d'un plugin, ce qui comporte davantage de risques liés à la mise en œuvre.

Du coup, tu peux très bien mettre en place un CSP, vérifier qu’il « fonctionne » dans ton navigateur, envoyer un ticket d’assistance pour demander une configuration au niveau du serveur, et pourtant voir l’en-tête s’afficher de manière irrégulière lors d’un scan automatisé.

En quoi un serveur dédié modifie-t-il tes options de configuration de sécurité ?

L'accès root signifie que tu es maître de la configuration. Chaque décision de sécurité décrite ci-dessus se traduit par un fichier de configuration que tu peux modifier, recharger et vérifier.

Pour désactiver TLS 1.0 et 1.1 sur un serveur Apache, il suffit d'ajouter une ligne dans la configuration SSL et de redémarrer le service. Pour ajouter des restrictions sur les suites de chiffrement — en supprimant RC4, 3DES et les versions destinées à l'exportation —, il faut environ cinq lignes supplémentaires. Ces modifications prennent effet immédiatement et peuvent être vérifiées à l'aide d'outils tels que openssl s_client ou Qualys SSL Labs avant et après.

Pour ajouter HSTS à chaque réponse, il suffit d'une seule directive dans le bloc de l'hôte virtuel :

Toujours définir l'en-tête Strict-Transport-Security « max-age=31536000; includeSubDomains »

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

La configuration du CSP est identique : elle s'applique à toutes les réponses provenant du serveur d'origine, sans passer par un plugin d'application. Les en-têtes X-Content-Type-Options, X-Frame-Options et Referrer-Policy constituent trois lignes supplémentaires.

La configuration des certificats — prise en charge de la révocation via l'OCSP Stapling, choix d'un algorithme de signature, paramétrage des options de déploiement — est effectuée lors de la mise en service et peut être mise à jour à tout moment sans avoir à contacter un fournisseur.

C'est toi qui décides de la fréquence des mises à jour, mais attention : sur un serveur non géré, c'est aussi à toi qu'incombe cette responsabilité. Sur les serveurs dédiés gérés InMotion Hosting, InMotion s'occupe des logiciels et de l'infrastructure au niveau du serveur, tandis que les clients conservent un accès root pour effectuer leurs propres modifications de configuration de sécurité.

Serveur dédié ou hébergement mutualisé géré : quels paramètres de sécurité peux-tu contrôler ?

Comparons ce que permet chaque environnement.

La colonne de droite ne signifie pas « pas d'aide ». Ça veut dire que c'est toi qui prends les décisions, tout en pouvant compter sur l'aide d'experts si besoin.

La certification de sécurité de ton fournisseur répond-elle à tes besoins spécifiques ?

C'est une nuance qui passe souvent inaperçue dans les articles comparatifs. Les plateformes gérées comme WP Engine mettent en œuvre des mesures de sécurité sérieuses et rigoureuses. WP Engine est certifié SOC 2 Type II et ISO 27001:2022, et limite l'accès en écriture au disque au niveau des processus afin de renforcer la sécurité de l'environnement contre l'injection de logiciels malveillants via des thèmes ou des plugins vulnérables.

Ces certifications reflètent le niveau de sécurité du fournisseur. Elles attestent de la manière dont celui-ci protège l'infrastructure partagée. En revanche, elles ne permettent pas de déterminer si la surface d'attaque externe de ton organisation — c'est-à-dire les adresses IP, les noms de domaine et les serveurs associés à ton entreprise — répond aux exigences spécifiques de configuration de sécurité de tes clients, de tes auditeurs ou des plateformes d'évaluation de la sécurité.

Une entreprise cliente qui gère un programme de gestion des risques fournisseurs vérifie ta note SecurityScorecard, et non le rapport SOC 2 de ton fournisseur. Un auditeur PCI QSA qui évalue ton environnement examine la configuration TLS du serveur sur lequel transitent les données des titulaires de carte, et non la certification de conformité générale de l'hébergeur. Ce sont ces configurations-là que tu dois maîtriser.

Qui a vraiment besoin d'un serveur dédié pour des raisons de sécurité ?

Ce n'est pas le cas de tous les sites web. L'hébergement mutualisé géré est une solution adaptée et suffisamment sécurisée pour les sites qui ne sont pas soumis à des audits de sécurité externes et qui ne traitent pas de données sensibles dans le cadre de normes de conformité.

Un serveur dédié est une bonne option quand :

• Ton SecurityScorecard ou tout autre outil d'évaluation de la sécurité similaire met en évidence des problèmes de configuration qui nécessitent un accès au niveau du serveur pour être résolus
• Un client professionnel ou une équipe chargée des achats te demande de fournir la documentation relative à tes configurations de sécurité spécifiques — et pas seulement la certification du fournisseur
• Tu es en train de te mettre en conformité avec la norme PCI DSS et tu dois contrôler la configuration TLS, la segmentation du réseau et le calendrier de mise à jour sur le serveur qui traite les transactions
• Ton organisation a fait l'objet d'un test d'intrusion ou d'une évaluation de sécurité qui a mis en évidence des problèmes au niveau des serveurs
• Tu gères plusieurs sites clients et tu es responsable de la sécurité de chacun d'entre eux

Les agences qui assument la responsabilité de la sécurité des sites de leurs clients — que ce soit par contrat ou simplement pour des raisons de réputation — constatent régulièrement que les environnements gérés partagés les privent de tout contrôle sur les décisions de sécurité, précisément au moment où ces décisions sont les plus cruciales.

« Avec l'hébergement mutualisé géré, c'est le fournisseur d'hébergement qui gère la configuration du serveur… Sur un serveur dédié, grâce aux services professionnels proposés par l'équipe d'administrateurs système d'InMotion Solutions, c'est toi qui t'en charges. »

Que faut-il clarifier avant de passer à un serveur dédié ?

Passer à un serveur dédié est une décision importante en matière d'infrastructure. Avant de franchir le pas, clarifie quelques points :

Quels sont les problèmes spécifiques à corriger ? Tous les problèmes signalés par SecurityScorecard ne nécessitent pas un serveur dédié. Certains peuvent être résolus en modifiant la configuration du CDN, en mettant à jour le DNS ou en changeant de fournisseur SSL. Détermine quels problèmes nécessitent spécifiquement un accès à la configuration au niveau du serveur.

Qui se chargera de la configuration du serveur ? L'accès root implique des responsabilités. Si tu ne disposes pas de ressources internes en administration système, prévois le coût d'un support géré ou de services professionnels.

Que prévoient exactement tes exigences de conformité ? Les normes PCI DSS, SOC 2 et HIPAA ont chacune leur propre champ d'application. Vérifie que la modification de configuration du serveur dont tu as besoin entre bien dans ce champ d'application et qu'elle répondra aux exigences de l'audit.

Les serveurs dédiés InMotion Hostingoffrent un accès root complet et un panneau de contrôle cPanel, avec une assistance technique gérée par l'équipe d'InMotion. L'offre Premier Care Bundle inclut la protection contre les logiciels malveillants Monarx, 500 Go d'espace de sauvegarde et un temps de consultation mensuel avec InMotion Solutions — l'équipe d'administrateurs système interne disponible pour le renforcement de la sécurité, la configuration TLS et la configuration des serveurs en conformité avec les normes. Découvre nos offres de serveurs dédiés ou contacte notre équipe pour discuter de tes besoins spécifiques en matière de sécurité.

Tous les serveurs VPS ou dédiés peuvent être mis en conformité avec la norme PCI-DSS grâce à notre aide, en collaboration avec nos clients et leur organisme de certification PCI.