L'augmentation constante des attaques ciblées sur les systèmes de gestion de contenu d'entreprise impose une vigilance extrême. Pour les responsables de la sécurité des systèmes d'information (RSSI) et les directeurs de la technologie (CTO), sécuriser une plateforme Drupal ne se résume plus à appliquer de simples mises à jour régulières. Une protection efficace nécessite une approche globale par couches successives englobant le système d'exploitation, l'architecture réseau des infrastructures cloud et les pipelines de déploiement continu.
Durcissement de la couche système sous Debian
Le système d'exploitation constitue le premier rempart physique de l'application. Sur un serveur Debian de production, la configuration par défaut de la pile logicielle offre une surface d'attaque trop importante qu'il convient de réduire immédiatement.
Isolation stricte des processus de PHP-FPM
La compromission d'une application web s'étend souvent au reste du système lorsque les processus partagent les mêmes droits d'exécution. Pour éviter cette escalade de privilèges, il est indispensable d'isoler l'exécution de Drupal au sein d'un pool PHP-FPM dédié, doté d'un utilisateur sans privilèges système.
Dans le fichier de configuration du pool PHP, souvent situé dans le répertoire /etc/php/8.x/fpm/pool.d/drupal.conf, les directives suivantes doivent être appliquées :
[drupal_prod]
user = drupal-user
group = drupal-group
listen = /run/php/php8.3-fpm-drupal.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660
; Limitation de la mémoire et des ressources
pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
; Durcissement des fonctions PHP autorisées
php_admin_value[disable_functions] = exec,passthru,shell_exec,system,proc_open,popen,curl_multi_exec,parse_ini_file,show_source
php_admin_flag[allow_url_fopen] = off
php_admin_flag[allow_url_include] = off
php_admin_value[open_basedir] = /var/www/html/drupal/:/tmp/
Cette configuration garantit que si une faille de type exécution de code à distance (RCE) est exploitée dans Drupal, l'attaquant ne pourra pas exécuter de commandes système via PHP ni accéder à d'autres répertoires en dehors de l'arborescence définie.
Configuration des serveurs web Nginx et Apache pour contrer les exécutions de scripts
Le répertoire des fichiers médias publics de Drupal, généralement situé dans /sites/default/files, doit pouvoir accepter l'écriture pour permettre le téléversement d'images ou de documents. Cependant, il ne doit sous aucun prétexte autoriser l'exécution de scripts PHP.
Configuration pour le serveur web Nginx
Voici les règles de configuration Nginx à mettre en place pour bloquer toute tentative d'exécution malveillante dans ces répertoires sensibles :
server {
listen 8443 ssl http2;
server_name www.mon-drupal-critique.fr;
root /var/www/html/drupal/web;
index index.php;
# Interdiction d'accès aux fichiers sensibles de configuration
location ~* \.(engine|hotx|inc|install|make|module|profile|po|sh|.*sql|theme|twig|tpl\.php|xtmpl)$ {
deny all;
}
# Blocage de l'exécution de scripts PHP dans le répertoire des fichiers téléversés
location ~* ^/sites/.*/files/.*\.php$ {
deny all;
access_log off;
log_not_found off;
}
# Routage standard sécurisé de Drupal
location / {
try_files $uri /index.php?$query_string;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.3-fpm-drupal.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
}
En complément de ces règles de routage, l'ajout d'en-têtes HTTP de sécurité au niveau du bloc serveur web limite les vecteurs d'attaques par injection de scripts ou par détournement de clic (clickjacking) :
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; frame-ancestors 'self';" always;
Équivalent de configuration pour le serveur web Apache
Si vous utilisez le serveur web Apache, la sécurisation s'effectue idéalement au niveau de la configuration du serveur (VirtualHost) ou, à défaut, via un fichier .htaccess placé à la racine du dossier des téléversements (/sites/default/files/.htaccess).
Voici les directives à intégrer pour désactiver l'exécution des scripts et sécuriser l'accès aux extensions sensibles :
# Désactivation de l'exécution de scripts PHP dans le répertoire des fichiers téléversés
<Directory "/var/www/html/drupal/web/sites/default/files">
# Désactivation du moteur PHP pour éviter l'interprétation
<IfModule mod_php.c>
php_flag engine off
</IfModule>
# Blocage de l'accès à tous les fichiers de scripts potentiels
<FilesMatch "\.(php|phtml|php3|php4|php5|php7|php8|phps|pl|py|jsp|asp|sh|cgi)$">
Require all denied
</FilesMatch>
</Directory>
# Interdiction d'accès aux fichiers sensibles de configuration de Drupal
<FilesMatch "\.(engine|hotx|inc|install|make|module|profile|po|sh|.*sql|theme|twig|tpl\.php|xtmpl)$">
Require all denied
</FilesMatch>
Pour appliquer les mêmes en-têtes HTTP de sécurité sous Apache, assurez-vous que le module mod_headers is activé et ajoutez les lignes suivantes dans votre hôte virtuel :
<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-XSS-Protection "1; mode=block"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; frame-ancestors 'self';"
</IfModule>
Duel d'infrastructure entre AWS et OVHcloud
Le choix de l'hébergeur cloud influence directement la stratégie de défense périmétrique de l'application Drupal. Un cloud public mondial comme Amazon Web Services (AWS) et un cloud souverain comme OVHcloud proposent des philosophies différentes en matière de sécurité et d'administration.
Implémentation d'un pare-feu applicatif web (WAF)
La protection des flux HTTP et HTTPS en amont de l'infrastructure applicative permet de filtrer le trafic illégitime avant même qu'il n'atteigne les serveurs Debian.
- Approche AWS : le service AWS WAF s'intègre nativement avec l'équilibreur de charge applicatif (Application Load Balancer) et le réseau de diffusion de contenu CloudFront. Il propose des règles gérées par défaut qui bloquent automatiquement les menaces courantes identifiées par l'OWASP, ainsi que des signatures spécifiques pour protéger l'écosystème PHP. La mise en place de politiques de filtrage d'adresses IP ou de limitation de requêtes par minute s'effectue directement via des API ou la console de gestion, simplifiant grandement la réactivité des équipes de sécurité.
- Approche OVHcloud : l'intégration d'un pare-feu applicatif web nécessite une approche plus manuelle ou l'intégration d'un partenaire tiers. Si OVHcloud excelle dans la protection contre les attaques par déni de service distribué (DDoS) grâce à sa technologie VAC, la couche applicative web doit souvent être sécurisée en déployant des appliances virtuelles spécifiques sur des instances de calcul publiques ou en configurant des répartiteurs de charge basés sur HAProxy avec des ensembles de règles complexes. Alternativement, l'utilisation conjointe d'un réseau tiers de confiance pour le trafic applicatif permet d'obtenir un niveau de filtrage équivalent sans surcharger l'administration système locale.
- Approche Cloudflare : positionné en tant que proxy inverse universel en amont de l'infrastructure, Cloudflare offre un bouclier de sécurité agnostique de l'hébergeur. Son pare-feu applicatif web s'appuie sur une analyse globale des menaces en temps réel pour bloquer les exploits applicatifs spécifiques à Drupal avant qu'ils n'atteignent le serveur Debian, tout en optimisant le temps de chargement grâce à un réseau de diffusion de contenu performant.
Gestion du stockage privé des fichiers médias sensibles
Une plateforme Drupal critique store régulièrement des données d'utilisateurs ou des fichiers administratifs confidentiels qui ne doivent pas être exposés publiquement sur internet.
- Approche AWS : l'utilisation d'Amazon S3 combinée avec le module Drupal S3 File System permet d'externaliser complètement le stockage des médias. La sécurité repose sur des politiques IAM strictes interdisant l'accès public au compartiment de stockage. Les fichiers sensibles sont alors servis aux utilisateurs authentifiés de Drupal sous forme de liens temporaires signés de manière cryptographique, générés à la volée par l'application web.
- Approche OVHcloud : l'offre Object Storage d'OVHcloud, compatible avec l'interface de programmation S3, offre une solution souveraine de stockage de fichiers. La configuration des droits d'accès s'appuie sur la gestion des identités OpenStack Keystone ou sur des politiques d'accès S3 spécifiques. Le chiffrement au repos des données stockées est également possible, assurant une parfaite confidentialité face aux réglementations de protection des données européennes les plus connaissables.
Automatisation du patching et DevSecOps
Attendre la découverte manuelle d'une vulnérabilité pour agir expose l'infrastructure à des risques inconsidérés. La mise en place d'une chaîne de livraison continue automatisée permet d'intégrer des analyses de sécurité régulières et de déployer des correctifs logiciels de manière fluide.
Architecture d'un pipeline de déploiement continu sécurisé
Le processus d'intégration continue doit tester le code de l'application à chaque modification pour identifier des failles potentielles avant leur mise en production.
Un pipeline moderne comprend trois phases essentielles de vérification :
- Analyse statique du code personnalisé : détection des mauvaises pratiques de développement et des risques d'injection SQL à l'aide d'outils d'analyse de structure.
- Audit des dépendances tierces : vérification automatique des paquets PHP gérés par Composer pour identifier des versions obsolètes comportant des vulnérabilités connues.
- Déploiement sans interruption : mise en production des fichiers mis à jour sans coupure d'accès pour les internautes, grâce à un mécanisme de bascule de liens symboliques ou de conteneurs isolés.
Voici un exemple de configuration de pipeline pour GitLab CI/CD permettant d'automatiser l'audit de sécurité d'un site Drupal :
# Fichier .gitlab-ci.yml pour l'audit de sécurité Drupal
stages:
- audit
variables:
PHP_VERSION: "8.3"
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- vendor/
audit_securite:
stage: audit
image: php:${PHP_VERSION}-cli
before_script:
- apt-get update && apt-get install -y git unzip zip
- curl -sS [https://getcomposer.org/installer](https://getcomposer.org/installer) | php -- --install-dir=/usr/local/bin --filename=composer
script:
- composer validate --no-check-publish
- composer install --no-interaction --prefer-dist
- # Analyse des vulnérabilités des dépendances PHP
- vendor/bin/security-checker security:check composer.lock || echo "Des vulnérabilités ont été détectées"
- # Analyse de la qualité et de la sécurité du code personnalisé
- composer require --dev drupal/coder --quiet
- vendor/bin/phpcs --standard=Drupal,DrupalPractice web/modules/custom
Méthodologie de déploiement sans interruption de service
Le déploiement des mises à jour de sécurité de Drupal s'effectue idéalement selon une stratégie de bascule par lien symbolique (symlink deployment) ou par conteneurs de services (blue-green deployment).
Pour une infrastructure basée sur Debian, la méthode par lien symbolique consiste à préparer la nouvelle version de l'application dans un dossier isolé, à exécuter les mises à jour de base de données avec l'outil en ligne de commande Drush, puis à rediriger instantanément le dossier racine du serveur web vers le nouvel emplacement.
Le script de déploiement exécute la séquence suivante :
#!/bin/bash
# Script de déploiement automatisé Drupal pour Debian via GitLab Runner
set -e
RELEASE_DIR="/var/www/html/drupal/releases/$(date +%Y%m%d%H%M%S)"
SHARED_DIR="/var/www/html/drupal/shared"
CURRENT_SYM="/var/www/html/drupal/current"
# Extraction de la nouvelle version depuis GitLab
mkdir -p "$RELEASE_DIR"
git clone --depth 1 git@gitlab.com:organisation/drupal-projet.git "$RELEASE_DIR"
# Création des liens vers les fichiers de configuration partagés
ln -s "$SHARED_DIR/settings.local.php" "$RELEASE_DIR/web/sites/default/settings.local.php"
ln -s "$SHARED_DIR/files" "$RELEASE_DIR/web/sites/default/files"
# Installation des dépendances avec Composer
cd "$RELEASE_DIR"
composer install --no-dev --optimize-autoloader
# Exécution des mises à jour de base de données et reconstruction des caches
./vendor/bin/drush state:set system.maintenance_mode 1 --yes
./vendor/bin/drush updatedb --yes
./vendor/bin/drush config:import --yes
./vendor/bin/drush cache:rebuild
./vendor/bin/drush state:set system.maintenance_mode 0 --yes
# Bascule instantanée du trafic
ln -nfs "$RELEASE_DIR" "$CURRENT_SYM"
# Nettoyage des anciennes versions
cd /var/www/html/drupal/releases && ls -1t | tail -n +5 | xargs rm -rf
Cette méthode de déploiement garantit que les utilisateurs ne rencontrent aucune erreur de chargement de page pendant que les fichiers PHP et les configurations système sont mis à jour en arrière-plan.
Foire aux questions
Comment protéger le fichier settings.php d'une écriture non autorisée ?
Le fichier de configuration principale de Drupal doit être en lecture seule pour l'utilisateur exécutant le serveur web. Après chaque installation ou modification, assurez-vous d'appliquer les droits d'accès restreints via la commande chmod 440 sur le fichier.
Quelle est la différence de souveraineté entre les offres d'AWS et d'OVHcloud ?
OVHcloud propose un hébergement conforme au droit européen et bénéficie de certifications de sécurité avancées comme SecNumCloud, empêchant toute application de lois extraterritoriales. AWS permet une plus grande souplesse technologique globale, mais relève du droit américain, ce qui peut poser des questions de conformité réglementaire pour certains ministères ou organisations de santé publique.
Est-il possible d'utiliser le module Security Review en production ?
Oui, le module Security Review est un excellent complément pour mener des audits de configuration directement depuis l'interface d'administration de Drupal. Cependant, pour des raisons de performance et de sécurité, il est préférable de planifier son exécution par des tâches planifiées (cron) plutôt que de charger l'interface d'évaluation à chaque requête utilisateur.
Comment limiter le risque lié aux modules Drupal obsolètes ?
La règle fondamentale consiste à installer uniquement des modules bénéficiant d'un support actif de la communauté et affichant le label de sécurité officiel de la Drupal Security Team. Pensez également à désactiver et désinstaller complètement les modules inutilisés pour ne laisser aucun code inerte sur votre serveur.
