Héberger soi-même des sites WordPress, c’est choisir la maîtrise plutôt que la commodité. On décide de la pile technique, des règles de déploiement, de ce qui tourne ou non sur le serveur. Mais cette liberté s’accompagne d’une responsabilité que les hébergeurs mutualisés portent à votre place : la sécurité de l’infrastructure. Voici comment j’ai structuré la mienne, couche par couche.
Le serveur
Un pare-feu décrit en code
Les règles de filtrage réseau sont gérées par Ansible, le même outil qui orchestre le reste de l’infrastructure. Le pare-feu est donc versionné dans un dépôt, relu comme du code et appliqué de façon reproductible. Une règle ne dépend pas de la mémoire d’une session SSH : chaque changement est tracé, daté et réversible.
Protection contre les attaques par force brute
Les tentatives de connexion répétées – sur SSH comme sur les sites – sont détectées, et les adresses IP suspectes bannies automatiquement. Ce n’est pas une mesure spectaculaire, mais c’est l’une des premières choses qu’on voit dans les journaux d’un serveur exposé : des robots qui testent des identifiants en continu. Les bloquer tôt réduit le bruit et la surface d’exposition.
Les outils internes derrière un VPN
Les outils internes – supervision, tableau de bord des tâches automatisées – ne sont pas exposés sur l’internet public. Ils ne sont accessibles qu’à travers un tunnel VPN WireGuard. Pour qui n’a pas les clés du tunnel, ces services n’existent tout simplement pas. La surface d’attaque diminue, sans complexité en plus pour qui a le bon accès.
Supervision et plafonds de ressources
Métriques système et journaux centralisés couvrent l’ensemble des conteneurs : un site qui consomme trop se voit avant de devenir un problème. Chaque site a ses plafonds – mémoire du conteneur, nombre de processus web, mémoire par requête PHP – pour qu’un pic de trafic sur un site limite son impact sur les sites hébergés à côté.
Les déploiements
La CI ne touche pas directement au serveur
Les déploiements des sites passent par un compte dédié, limité à une seule opération : déployer. Il n’ouvre pas de shell et n’administre rien. Avant d’agir, il vérifie auprès de GitLab que la demande vient bien d’un pipeline en cours d’exécution : sinon, rien ne se passe.
Des images construites sans privilèges
Les images Docker sont construites sans accès privilégié et sans accès au moteur Docker du serveur. Une dépendance compromise pendant le build reste confinée au build.
Des secrets chiffrés et cloisonnés
Les secrets de l’infrastructure sont chiffrés (Ansible Vault) et ne sont accessibles qu’aux projets qui en ont besoin. Ceux des sites sont stockés dans des variables protégées et masquées, propres à chaque projet et à chaque environnement : ils n’apparaissent ni dans le code, ni dans les journaux des pipelines.
Une liste blanche des domaines de production
Seuls les domaines explicitement autorisés peuvent être déployés en production. Un déploiement vers un domaine non référencé est refusé. C’est une protection simple, contre les erreurs de configuration autant que contre les tentatives de détournement.
Les projets et les dépôts
Les secrets sortent du code
Les clés de sécurité de WordPress et les clés d’API tierces n’ont pas leur place dans un dépôt. Elles sont injectées au déploiement, différentes pour chaque environnement. Un développeur qui clone un projet ne récupère pas les secrets de production, et en local, WordPress génère ses propres clés.
Les plugins premium installés par Composer
Les plugins commerciaux sont distribués depuis un dépôt Composer privé. Les sites n’ont plus besoin de clé de licence dans leur code, et chaque plugin vient d’une source unique et maîtrisée, dans une version précise, enregistrée dans le projet.
L’adresse IP réelle des visiteurs derrière le reverse proxy
Derrière un reverse proxy, toutes les requêtes semblent venir de la même adresse : celle du proxy. Sans réglage, les plugins de sécurité voient une seule IP pour tous les visiteurs, et le blocage par IP ne sert plus à rien. L’adresse réelle est donc lue dans l’en-tête transmis par le proxy, et seulement quand la requête vient bien du proxy : un visiteur ne peut pas se faire passer pour une autre adresse.
Une préproduction fermée au public
Les environnements de préproduction demandent une authentification. Un contenu en cours de validation n’est ni indexé par les moteurs de recherche, ni visible du public.
Ce que ça change dans la pratique
Les changements durables de l’infrastructure sont versionnés, relus et appliqués par la CI ou par Ansible. C’est une discipline autant qu’une garantie : une configuration se retrouve dans un dépôt, avec son historique, et peut être rejouée à l’identique.
Le fil conducteur de ces améliorations, c’est le principe du moindre privilège : chaque composant reçoit l’accès dont il a besoin, et pas davantage. Le pipeline déploie mais n’administre pas le serveur. Les secrets d’un site restent dans son projet. Un site a des plafonds de ressources. Ces règles ne rendent pas le système infaillible – rien ne l’est – mais elles réduisent la portée de ce qui peut mal tourner et la vitesse à laquelle un problème peut se propager.
Vous hébergez des sites WordPress et souhaitez faire le point sur la sécurité de votre infrastructure ou de vos projets ? Je propose des audits ciblés : contact@juzed.dev.
Stack : Ansible · WireGuard · Docker · GitLab CI/CD · Composer · Bedrock · WordPress FSE