Conception d'une infrastructure Docker sécurisée

Mission#

Concevoir une infrastructure hybride, sécurisée et automatisable pour une application Docker Compose, respectant les contraintes suivantes :

• Séparation stricte des services :

• VM dédiée aux services de paiement (non incluse ici)
• API, microservices, WAF et webapp hébergés sur cette VM (VM1)

• Chiffrement de bout en bout : TLS + mTLS
• Monitoring, audit, journalisation
• Architecture production-ready, 100% locale, sans cloud
• Déploiement automatisable, reproductible

Analyse de risques#

Matrice probabilité / impact :#

Justification des risques :#

Justification des choix technologiques#

Conteneurisation

La plupart des services ont été déployés via Docker pour :

• Faciliter le déploiement
• Assurer l'isolation logicielle entre composants
• Permettre la scalabilité horizontale rapide
• Automatiser le provisionnement des services d'applications.

Les applications conteneurisées sont :

StoreAPI, SecureBank, MailDev, NGINX, WAF (ModSecurity), Grafana, Prometheus, FocalBoard, Loki, Promtail et Fail2ban.

La base MSSQL est dans une VM pour plus de sécurité. Étant le cœur des données critiques (bancaires et personnelles), MSSQL bénéficie d’un hébergement isolé pour :

• Éviter tout accès latéral par d'autres conteneurs,
• Faciliter le chiffrement,
• Gérer les backups et la haute disponibilité de manière plus fiable.

Gestion des incidents de sécurité#

Incident 1 – Intrusion sur un conteneur exposé : activité inhabituelle détectée sur storeapi (logins anormaux, pics CPU, connexions sortantes suspectes).#

Procédure de réponse :

1. Isoler immédiatement le conteneur (docker network disconnect ou docker stop) ;
2. Extraire les logs (docker logs, audit.log, Grafana/Prometheus) ;
3. Identifier la méthode d'intrusion (faille exploitée, mot de passe exposé) ;
4. Supprimer et re-déployer une image propre durcie ;
5. Mettre à jour les secrets et valider leur non-exposition ;
6. Documenter l’incident et renforcer les règles réseau ou authentifications.

Incident 2 – Compromission d’identifiants MSSQL : accès non autorisé à certaines tables.#

Procédure de réponse :

1. Révoquer immédiatement les credentials exposés ;
2. Auditer les accès récents à la base (recherche d’actions malveillantes) ;
3. Réévaluer les permissions et appliquer le principe du moindre privilège ;
4. Déployer une alerte spécifique sur les tentatives de connexion inhabituelles.

Incident 3 – Fuite de données RGPD : données personnelles visibles publiquement (logs ou endpoint non protégé).#

Procédure de réponse :

1. Supprimer l’exposition immédiatement (via NGINX ou arrêt du conteneur) ;
2. Identifier le vecteur (XSS, accès non restreint, oubli d’authentification) ;
3. Avertir le DPO / responsable RGPD si applicable ;
4. Informer les utilisateurs concernés si fuite avérée ;
5. Appliquer un correctif, documenter et prévenir toute récurrence.

Sauvegarde#

Un plan de sauvegarde automatisé doit être en place :

• Base MSSQL : script de dump journalier avec enregistrement sur volume dédié
• Fichiers de config (certificats, nginx.conf, .env) : versionnés dans un dépôt Git privé avec historique
• Volumes applicatifs : synchronisation hebdomadaire vers un stockage sécurisé externe.

Test de restauration à effectuer chaque mois pour valider l’intégrité des sauvegardes.

Politique de mise à jour#

• Mise à jour des conteneurs via docker pull des dernières images stables mensuellement.
• Scan de vulnérabilités automatique.
• Automatisation des déploiements via CI/CD avec tests de régression intégrés.
• Interdiction de déployer manuellement des images non validées.

Plan de Formation#

Pour garantir un bon niveau de sécurité sur la durée, les équipes doivent être formées régulièrement.

Recommandations de formation :

Architectures et technologies#

Le schéma principal montre les interactions sécurisées suivantes au sein de l'architecture :

• Utilisateurs → WAF (ModSecurity) via HTTPS/TCP
• WAF → Reverse Proxy (NGINX) via HTTPS/TCP
• Reverse Proxy → StoreAPI / SecureBank via HTTPS/TCP (flux internes chiffrés)
• StoreAPI ↔ MSSQL : communication avec base de données critique contenant des données RGPD
• SecureBank ↔ MSSQL : échanges sécurisés pour les opérations bancaires
• StoreAPI ↔ SecureBank : appels interservices sécurisés
• Prometheus / Grafana connectés au Reverse Proxy pour le monitoring
• MailDev reçoit les emails de test via SMTP depuis les services applicatifs.

Architecture et réseau#

     ┌────────────────────────────┐
     │ Docker Compose Network     │
     │ (frontend/backend)         │
     └────────────────────────────┘
            ├── reverse-proxy (NGINX TLS/mTLS)
            ├── securebank      (API web)
            ├── storeapi        (API boutique)
            ├── maildev         (SMTP debug)
            ├── grafana         (Dashboard observabilité)
            ├── prometheus      (Scrapping métriques)
            ├── loki + promtail (Logs)
            ├── kanban          (outil gestion)
            ├── waf             (ModSecurity CRS + SSL)
            └── fail2ban        (brute force ban)

• Distribution : Debian 12
• Interfaces réseau :

• enp0s3: NAT (10.0.2.15/24)
• enp0s8: Host-only (192.168.56.101/24)

Sécurité & TLS#

• Certificats signé par une root CA via cfssl dans ./certs
• Reverse proxy NGINX sécurisé :

• HTTPS avec TLS 1.2/1.3
• Redirection HTTP ➜ HTTPS
• Headers stricts : HSTS, X-Frame-Options, CSP, etc.
• Authentification mutuelle (mTLS) activée sur certaines routes

• WAF actif sur port 8443 :

• Image owasp/modsecurity-crs
• CRS 3.3 activé avec paranoia level 1
• SSL hardening appliqué

• Fail2ban activé sur logs NGINX, détecte les erreurs 401

Observabilité#

Grafana#

• Accès : https://securebank.local:3000
• Provisioning automatique des datasources :

• Prometheus (scrapping : NGINX, storeapi, securebank, etc.)
• Loki (via promtail pour tous les conteneurs)

• Dashboards disponibles :

• Docker host (via node-exporter)
• Containers stats (via cAdvisor)
• Reverse proxy / API / DB

Prometheus#

• Scrapping :

• node-exporter sur la VM
• cadvisor pour les conteneurs
• Services exposant /metrics

• Config : ./observability/prometheus/prometheus.yml

Loki + Promtail#

• Promtail lit :

• /var/lib/docker/containers
• /var/log/

• Les logs sont centralisés dans Grafana via Loki

Protection active#

ModSecurity (WAF)#

• WAF actif sur le conteneur waf (port 8443)
• Analyse les requêtes entrantes
• Bloque XSS / SQLi / LFI / fuzz

Fail2ban#

• Container fail2ban avec NET_ADMIN pour bannir les IP
• Règles actives sur logs NGINX 401 / brute force
• Configuration : fail2ban/jail.local + nginx-http-auth.conf

Synchronisation NTP#

• chrony configuré avec les pools NTP publics
• La synchronisation est essentielle pour TLS, logs, audit

Axe d'améliorations#

• Remplacer MailDev

➤ Utiliser un vrai serveur SMTP sécurisé (Postfix + Dovecot ou service SaaS) avec authentification et chiffrement TLS pour éviter d’exposer un service non sécurisé, même en environnement de test.

• Gestion centralisée des secrets

➤ Intégrer un outil comme HashiCorp Vault, Gopass, ou Docker secrets pour ne plus exposer les mots de passe et tokens dans les variables d’environnement.

• Activer la MFA

➤ Pour toutes les interfaces critiques : Grafana, portails admins, reverse proxy (via OpenID Connect ou TOTP).

• Renforcer les politiques de logs et de rétention

➤ Étendre la journalisation à toutes les actions sensibles (login, modification de données bancaires, suppression, export).

• Améliorer la configuration de ModSecurity

➤ Augmenter le niveau de paranoïa (paranoia_level 2 ou 3). ➤ Définir des whitelists contextuelles pour éviter les faux positifs.

• Supervision de la sécurité système

➤ Ajouter Lynis ou OpenSCAP pour effectuer des audits réguliers de sécurité OS. ➤ Monitorer les binaires critiques (/bin, /sbin) avec AIDE ou OSSEC.

Amélioration de l’infrastructure#

• Externalisation de MSSQL

➤ Déporter la base vers un service managé (ex. Azure SQL, RDS, etc.) pour :

• bénéficier de la HA native

• automatiser les sauvegardes et la réplication

• réduire l’empreinte locale et la maintenance

• Stockage des logs dans un SIEM

➤ Rediriger les logs Loki ou journaux applicatifs vers un SIEM externe comme Wazuh, Graylog, ou ELK, pour une analyse centralisée de la sécurité.

• Renforcement des certificats TLS

➤ Passer de certificats autosignés à une PKI locale complète ou à des certificats Let's Encrypt DNS-based si exposé en prod (ex: avec acme.sh + DNS challenge).

• Ajout d’un Bastion SSH (Jump host)

➤ Pour isoler l’accès à la VM dockerhost. ➤ Activer journaux de session + MFA + alertes sur échec d’authentification.

Évolutivité et automatisation#

• Passage à Kubernetes à moyen terme

➤ Pour :

• faire du blue/green deployment

• avoir des rolling updates

• autoscaler les pods et intégrer des probes (readiness/liveness)

• introduire RBAC, Network Policies, PodSecurity Standards

• Automatisation complète avec Ansible / Terraform

➤ Générer la stack via un playbook Ansible unique ou un setup hybride avec Terraform pour automatiser :

• le provisioning des VM

• le déploiement des services

• la configuration réseau et TLS

• Ajout de tests de conformité automatisés

➤ Intégrer un outil comme Inspec ou Testinfra pour vérifier :

• la configuration de sécurité

• la présence des services critiques

• l’intégrité des fichiers sensibles

Monitoring avancé & alerte#

• Alerte Grafana

➤ Activer les alert rules sur les dashboards existants (ex: HTTP errors > 5xx, CPU usage, RAM, services down).

• Enrichir la visibilité des logs

➤ Ajouter des labels dynamiques dans Promtail/Loki (ex: niveau de criticité, module source, user_id).

• CrowdSec + Fail2ban

➤ Intégrer CrowdSec avec bouncer nginx/Docker. ➤ Ajouter l’intelligence collaborative pour bloquer les IP malveillantes en temps réel.