Chapitre 16.3 — Checklist mise en prod

⏱️ TL;DR — La checklist de mise en production sécurisée : le tour du propriétaire avant de livrer, pour ne rien oublier de ce qui, absent, transforme une appli fonctionnelle en fuite ou en panne. Elle couvre le transport (HTTPS/HSTS, en-têtes), l’authentification & l’accès, la configuration (erreurs masquées, secrets hors du code), les dépendances (audit, lockfile), l’infra (moindre privilège, ports, isolation, CI/CD), et l’observabilité (logs, monitoring, alerting, sauvegardes, plan d’incident). Comme pour la revue de code (16.2), l’idéal est d’automatiser ce qui peut l’être et de garder la checklist comme rituel avant chaque mise en prod. Beaucoup de points renvoient au cours Serveur Linux.

🎯 Objectifs

• Disposer d’une checklist de mise en production sécurisée, par thème.
• Ne pas confondre « ça marche » et « c’est prêt pour la prod » (Partie 1).
• Savoir ce qui est automatisable et ce qui relève d’un contrôle avant livraison.

« Ça marche » ≠ « prêt pour la prod »

Rappel de la Partie 1 : une appli accessible n’est pas une appli en prod. Sans HTTPS, sans erreurs masquées, sans sauvegardes, sans monitoring, sans contrôle d’accès, c’est une panne ou une fuite qui attend. Cette checklist est le garde-fou entre les deux. On la passe avant de livrer, et on automatise un maximum de points en CI/CD pour qu’ils ne dépendent pas de la mémoire.

Transport & en-têtes

• HTTPS partout, certificat valide (Let’s Encrypt auto-renouvelé), TLS 1.2/1.3 seulement.
• Redirection HTTP → HTTPS et HSTS activé (durée adaptée ; includeSubDomains/preload seulement si tous les sous-domaines sont en HTTPS).
• En-têtes de sécurité posés (avec always) : nosniff, X-Frame-Options/frame-ancestors, Referrer-Policy, Permissions-Policy.
• CSP en place (idéalement à nonce, sans unsafe-inline) — déployée d’abord en Report-Only.
• Vérifié empiriquement (SSL Labs, securityheaders.com) sur toutes les routes (dont erreurs).

Authentification & accès

• Mots de passe hachés (argon2id), MFA disponible (obligatoire pour les rôles à privilèges).
• Sessions solides (cookie HttpOnly/Secure/SameSite, régénérées à la connexion, expiration).
• Rate limiting sur login/reset/endpoints sensibles ; messages génériques (anti-énumération).
• Autorisation vérifiée côté serveur, par objet (pas d’IDOR) ; comptes de test/admin par défaut supprimés.
• Panneaux d’admin protégés/restreints (accès, MFA).

Configuration

• Erreurs masquées en prod (APP_ENV=prod, display_errors=Off, pas de stacktrace au client) ; message générique + logs internes.
• Aucun secret dans le code / le dépôt ; secrets en vault/variables d’environnement ; .env sensibles ignorés.
• Debug/profiler désactivés ; endpoints de debug/test retirés ; expose_php/bannières serveur off.
• Fichiers sensibles non servis (.env, .git, config.php, moodledata hors racine web) ; permissions strictes.
• CORS strict (allow-list, pas de * + credentials).

Dépendances

• npm/composer audit sans vulnérabilité critique (bloquant en CI) ; Dependabot actif.
• Lockfile committé ; installation reproductible (npm ci/composer install).
• Images de conteneurs scannées (Trivy) et à jour.

Infra & déploiement

• Appli sous compte non-root ; conteneurs non-root, image minimale, sans --privileged.
• Pare-feu deny-by-default (80/443 + SSH restreint) ; base non exposée (réseau privé).
• Réseau segmenté (l’appli ne joint pas les métadonnées cloud ni les services superflus — anti-SSRF).
• SSH durci (clés, root off, mot de passe off — Partie 4/Serveur Linux) ; fail2ban actif.
• CI/CD sécurisée : droits minimaux, secrets courts (OIDC), actions/images épinglées, artefacts signés.

Observabilité & résilience

• Logs de sécurité activés (connexions, 403, changements sensibles) — sans fuiter secrets/PII ; centralisés.
• Monitoring (métriques, erreurs, uptime) et alerting dosé (pas de fatigue d’alerte).
• Sauvegardes en place (règle 3-2-1), chiffrées, et restauration testée (Partie 14/Serveur Linux).
• Plan de réponse à incident prêt (contacts, DPO, runbook) ; procédure de violation de données (RGPD).

Conformité (si données personnelles)

• Minimisation (collecte/conservation limitées) ; durées de conservation définies.
• Droits des personnes possibles (accès, effacement) ; politique de confidentialité à jour.
• Sous-traitants/hébergement conformes (lien cours RGPD).

💡 Réflexe — Fais de cette checklist un rituel de mise en prod (et automatise le maximum en CI/CD : audit, scan de secrets/images, vérification des en-têtes). Le jour d’une livraison, on est pressé et concentré sur la fonctionnalité — c’est exactement le moment où l’on oublie HTTPS, les erreurs masquées ou une sauvegarde. Une checklist écrite et passée systématiquement rattrape ces oublis. « Prêt pour la prod » se vérifie, ça ne se suppose pas.

🎯 Côté attaquant — Après un déploiement, l’attaquant scanne immédiatement les oublis de mise en prod : TLS faible, en-têtes manquants, erreurs verbeuses (stacktraces → cartographie), endpoints de debug laissés ouverts, .env/.git servis, comptes par défaut, base exposée, pas de rate limiting. Ces oublis sont des prises gratuites, indépendantes de la qualité du code applicatif — un déploiement bâclé annule le soin mis dans le développement. Une checklist passée lui refuse ces cadeaux.

🧭 Sur FormaCampus — FormaCampus a fait de cette checklist un gate de déploiement : la plupart des points sont automatisés en CI/CD (audit bloquant, scan de secrets et d’images, vérification des en-têtes/TLS, npm ci), et les points non automatisables (comptes par défaut retirés, endpoints de debug off, sauvegarde testée, plan d’incident prêt) sont cochés dans une procédure de release. Un déploiement ne part pas si un point critique manque. C’est la traduction opérationnelle du « secure by default » (Partie 1) : la prod est sûre parce que la checklist l’impose, pas parce que quelqu’un y a pensé.

✏️ Exercices

Exercice 1 — L’oubli classique. Une nouvelle appli est déployée : elle marche, mais en APP_ENV=dev, avec le profiler actif et .git accessible. Quels risques concrets, et quels points de la checklist ont été manqués ?

Exercice 2 — Automatiser le gate. Cite trois points de cette checklist qu’on peut rendre bloquants automatiquement en CI/CD, et un qui reste un contrôle manuel.

🧠 Quiz de révision

Chapitre suivant : DevSecOps, glossaire & quiz final — la culture qui pérennise tout ça, un glossaire des termes, et le quiz transversal de fin de cours.