Chapitre 11.4 — Durcir config.php & données

⏱️ TL;DR — Au-delà du code, une instance Moodle se durcit au niveau de la configuration et de l’hébergement. config.php contient des secrets (accès base) : permissions strictes, hors de portée du web, jamais commité. Le dossier moodledata (fichiers, copies d’apprenants) doit être hors de la racine web (inaccessible par URL). On force HTTPS ($CFG->wwwroot en https, cookies sécurisés), on désactive ce qui ne sert pas, on restreint l’accès admin, on sauvegarde (base + moodledata). Enfin, Moodle manipule des données personnelles d’apprenants (parfois sensibles) : c’est un enjeu RGPD direct (voir le cours RGPD) — minimisation, contrôle d’accès strict, journalisation, et capacité à répondre aux droits des personnes.

🎯 Objectifs

• Protéger config.php (secrets, permissions) et moodledata (hors racine web).
• Forcer HTTPS et les cookies sécurisés ; restreindre l’accès admin.
• Sauvegarder correctement (base + fichiers) — lien résilience.
• Traiter les données d’apprenants en conformité RGPD (minimisation, accès, droits).

config.php : le fichier le plus sensible

config.php (à la racine de Moodle) contient la configuration, dont les identifiants de base de données et des paramètres critiques. Un config.php lisible (mauvaises permissions) ou exposé (servi en clair, sauvegardé au mauvais endroit) livre l’accès à la base — donc à toutes les données.

Mesures :

• Permissions strictes : le fichier n’est lisible que par l’utilisateur du serveur web (ex. 640/440), pas par « les autres » (rappel permissions Unix, cours Serveur Linux).
• Jamais dans Git : config.php contient des secrets → hors du dépôt (Partie 13). Un secret qui a fuité dans Git est grillé (révoquer/régénérer).
• Pas exposé par le serveur web en tant que source : la config PHP doit être exécutée, jamais servie en texte ; attention aux sauvegardes (config.php.bak, ~) laissées dans la racine web.
• HTTPS : $CFG->wwwroot en https://... (force les URL en HTTPS), et activer les cookies sécurisés ($CFG->cookiesecure) pour que la session ne parte qu’en HTTPS (Partie 2).

// config.php (extrait) — durci
$CFG->wwwroot   = 'https://moodle.formacampus.fr'; // HTTPS force
$CFG->cookiesecure = true;                          // cookie de session Secure
// identifiants DB : secrets -> fichier hors Git, permissions strictes

moodledata : hors de la racine web

Moodle stocke les fichiers (documents uploadés, copies des apprenants, sauvegardes de cours, caches) dans le dossier moodledata. Ce dossier ne doit pas être accessible par URL : s’il est dans la racine web, un attaquant pourrait accéder directement à des fichiers (copies d’examens, données personnelles) en devinant des chemins.

Règle : moodledata doit être placé HORS de la racine web (ex. /var/moodledata, pas /var/www/html/moodledata), avec des permissions réservées à l’utilisateur du serveur. Moodle sert les fichiers via son code (qui applique le contrôle d’accès et les capabilities), jamais en accès direct.

⚠️ Piège — Laisser moodledata dans la racine web (ou config.php lisible) est une erreur d’hébergement grave et courante : elle transforme un contrôle d’accès applicatif soigné en passoire, car les fichiers (copies d’apprenants, sauvegardes, données personnelles) deviennent téléchargeables directement par URL, sans passer par les capabilities Moodle. La sécurité applicative (chapitres 11.1-11.2) ne sert à rien si les fichiers sensibles sont servis « à côté » par le serveur web. moodledata hors racine web, config.php en permissions strictes : non négociable.

Durcir l’accès et l’exécution

• Restreindre l’accès admin : limiter l’accès aux pages d’administration (par IP si possible), MFA pour les comptes admin/enseignants (Partie 4), mots de passe forts.
• Désactiver ce qui ne sert pas : fonctionnalités, méthodes d’auth, web services non utilisés (réduction de surface).
• Uploads : Moodle gère les uploads via son API (types, tailles) — s’assurer que le stockage (moodledata) n’est pas exécutable (pas de PHP exécuté depuis les fichiers uploadés — Partie 9).
• En-têtes de sécurité et HTTPS/HSTS au niveau du reverse proxy (Parties 2 et 14).
• Séparer les privilèges de la base : l’utilisateur DB de Moodle n’a que les droits nécessaires (moindre privilège, Partie 6).

Sauvegarder : base ET moodledata

Une sauvegarde complète d’un Moodle comprend trois éléments : la base de données, le dossier moodledata (les fichiers), et le code (Moodle + plugins + config.php). Sauvegarder seulement la base perd les copies des apprenants et les fichiers de cours. On applique la règle 3-2-1 et on teste la restauration (Partie 15 et cours Serveur Linux). Les sauvegardes contiennent des données personnelles → elles doivent être protégées (chiffrées, accès restreint) comme les données de production.

Données d’apprenants : l’enjeu RGPD

Moodle manipule des données personnelles d’apprenants — identité, résultats, activité, parfois données sensibles (santé/handicap pour l’accessibilité). C’est un traitement RGPD à part entière (voir le cours dédié RGPD) : la sécurité est une obligation légale (« sécurité du traitement »). Concrètement :

• Minimisation : ne collecter et ne conserver que les données nécessaires ; purger ce qui ne l’est plus (durées de conservation).
• Contrôle d’accès strict : les capabilities (chapitre 11.1) garantissent qu’un enseignant ne voit que ses cours, un apprenant que ses données — c’est de la sécurité et de la conformité.
• Journalisation : Moodle journalise les accès (logs) — utile pour la détection (Partie 15) et pour prouver la conformité, sans sur-collecter ni exposer les logs.
• Droits des personnes : Moodle fournit des outils (politique de confidentialité, export/suppression des données d’un utilisateur) pour répondre aux droits RGPD (accès, effacement). Les activer et les tester.
• Sous-traitance & hébergement : si l’hébergement est externalisé, l’hébergeur est sous-traitant (contrat, localisation des données — cours RGPD).

💡 Réflexe — Pense « données d’apprenants = données personnelles sensibles » : chaque décision de sécurité sur Moodle (accès, chiffrement, sauvegardes, logs) est aussi une décision de conformité RGPD. La sécurité et la protection des données ne sont pas deux sujets séparés ici — une fuite de copies d’examens ou de résultats est à la fois un incident de sécurité et une violation de données à notifier (Partie 15 et cours RGPD). Traite l’instance Moodle avec le niveau de soin qu’exigent des données d’élèves.

🧭 Sur FormaCampus — L’instance Moodle de FormaCampus est durcie de bout en bout : config.php en permissions 440, hors Git (secrets en variables d’environnement du serveur) ; moodledata hors de la racine web (/var/moodledata, servi uniquement par le code Moodle) ; HTTPS forcé (wwwroot en https, cookiesecure actif) et HSTS au proxy ; MFA obligatoire pour admins et enseignants ; accès admin restreint. Les sauvegardes couvrent base + moodledata + code, sont chiffrées, testées, et suivent la règle 3-2-1. Côté RGPD, la minimisation est appliquée (durées de conservation), les capabilities garantissent le cloisonnement des données d’apprenants, et les outils Moodle de droits des personnes (export/effacement) sont activés. Sécurité et conformité y sont traitées ensemble, comme le veut une plateforme de données d’élèves.

✏️ Exercices

Exercice 1 — Trouve l’erreur d’hébergement. Un Moodle a un contrôle d’accès applicatif impeccable (capabilities partout), mais moodledata est dans /var/www/html/moodledata et config.php est en permissions 644. Quels sont les deux problèmes ?

Exercice 2 — Sécurité et RGPD. En quoi une fuite de résultats d’apprenants depuis un Moodle est-elle à la fois un incident de sécurité et un problème RGPD ?

🧠 Quiz de révision

Fin de la Partie 11, et fin de l’application à ton stack (PHP/Symfony, Next.js, Moodle). Tu sais désormais sécuriser Moodle avec ses API (capabilities, sesskey, $DB), gérer ses plugins et le durcir. On passe à l’industrialisation, en commençant par un risque transversal majeur : la Partie 12 — Dépendances & supply chain.