AdminII Analyse Sécurité - dudleydehenau/Ephec GitHub Wiki
0. Introduction à l'infrastructure
L'infrastructure analysée est composée de 6 éléments :
5 conteneurs :
- DNS (BIND9)
- Serveur Web (NGINX)
- PHP
- Base de données (MariaDB)
- Serveur mail (docker-mailserver)
Et un pare-feu installé directement sur l’hôte.
Description du schéma
Le schéma représente un VPS (VPS1 55.36.180.56) et les services (conteneurs Docker) qu'il héberge. Pour chaque conteneur, nous avons :
- Son FQDN
- Ses ports ouverts et publiés
- Son nom de conteneur et la version de l'image utilisée
- Son adresse IP interne au sein de l'environnement Docker
Les services conteneurisés sur VPS1 sont :
- Serveur Web (Nginx) : agit comme reverse proxy et sert le contenu web
- Application PHP (PHP-FPM) : exécute la business logic des sites web
- Base de données (MariaDB) : stocke les données des applications
- Serveur DNS (Bind9) : gère les résolutions de noms de domaine pour i2-6.ephec-ti.be
- Serveur Mail (Docker-mailserver) : gère les e-mails
Pour les réseaux, nous avons :
dmz_net(172.18.x.x) qui assure la communication entre le serveur web et l'application PHP. Ce réseau est destiné aux services exposés et aux requêtes externes.db_net(172.19.x.x) qui sert à isoler la base de données ; seule l'application PHP peut y accéder. Cela permet de protéger la base de données en limitant la surface d'attaque.- Le serveur DNS (172.17.0.2) et le serveur mail (172.20.0.2) sont sur leurs propres sous-réseaux et connectés grâce à des ports hôtes. Leur isolation permet d'augmenter la sécurité du réseau.
Tous les conteneurs sont sur l'hôte VPS1, qui est protégé par un pare-feu UFW. Seul le trafic destiné aux ports publiés par les services est autorisé en entrée.
Les VPS2 et VPS3 sont aussi connectés au réseau et protégés par UFW, mais n'hébergent aucun service.
1. Liste des biens à protéger
| Bien | Type de bien | Description | Importance (Haute/Moyenne/Basse) |
|---|---|---|---|
| Serveur VPS | Physique/Logique | Serveur hébergeant les différents services (web, mail, DNS) | Haute |
| Accès SSH | Logique | Point d’entrée pour l’administration du serveur | Haute |
| Zone DNS | Logique | Enregistrements DNS pour les domaines hébergés | Haute |
| Base de données | Logique | Contient les données applicatives (ex. : utilisateurs, contenus) | Haute |
| Code source des sites web | Logique | Fichiers PHP hébergés sur le serveur | Basse |
| Service web | Logique | Sert les pages web accessibles par les utilisateurs | Basse |
| Comptes utilisateurs | Immatériel | Identifiants des utilisateurs, clients ou admins | Haute |
| Mails envoyés/reçus | Logique | Contenu des communications mail, potentiellement sensibles | Haute |
| Réputation de l’organisation | Immatériel | Impact potentiel si services web/mail sont compromis ou utilisés à des fins malveillantes (spam, phishing) | Haute |
| Certificats TLS/SSL | Logique | Assurent le chiffrement des communications | Moyenne |
| Sauvegardes | Logique | Permettent de restaurer en cas d’attaque ou de perte de données | Haute |
Classement par ordre de priorité
- Accès SSH
- Base de données
- Mails envoyés/reçus
- Réputation de l’organisation
- Sauvegardes
- Zone DNS
- Serveur VPS
- Comptes utilisateurs
- Certificats SSL
- Service web
- Code source des sites web
2. Vulnérabilités et menaces
L’analyse ci-dessous repose sur les biens identifiés à l’étape précédente et prend en compte les trois piliers de la sécurité de l’information : Confidentialité, Intégrité et Disponibilité (le modèle CIA).
Légende
- C : Confidentialité
- I : Intégrité
- D : Disponibilité
1. Accès SSH
| # | Vulnérabilités | Menaces | Risque associé | Code Ref. Analyse des risques |
|---|---|---|---|---|
| C | Connexions autorisées avec clé ou avec mot de passe | Divulgation de clé de connexion ou du mot de passe | Accès non autorisé au VPS, fuite de données, confidentialité des utilisateurs compromise, Indisponibilité du service suite à une intrusion non autorisée | 1a |
| I | Mauvais contrôle des accès / sudo | Perte du contrôle des permissions | Effacement accidentel des données utilisateurs, panne de service | 10 |
| D | Port SSH exposé sans protection | Tentatives de connexion non voulues, déni de service, brut force sans limite | Saturation du service SSH, panne partielle ou totale du serveur, Indisponibilité du service suite à une intrusion non autorisée (brut force) | 1b |
2. Base de données
| # | Vulnérabilités | Menaces | Risque associé | Code Ref. Analyse des risques |
|---|---|---|---|---|
| C | Données non chiffrées | Vol & lecture possible directement sans protection des données sensibles si injection SQL / dump de la db | Exploitation de données sensible de l'utilisateur en cas de dataleak | 5 |
| I | Absence de validation des entrées | Injection SQL, altération des données | Utilisation d’injections pour exécuter du code malveillant côté client | 3b |
| D | Pas de réplication ni de sauvegarde | Perte totale en cas de panne, d'erreur ou d’attaque | Perte des données importantes ou altération des données utilisateur, obligeant à des actions fastidieuses comme la reconfiguration du compte | 10 |
3. Service mail
| # | Vulnérabilités | Menaces | Risque associé | Code Ref. Analyse des risques |
|---|---|---|---|---|
| C | Mails envoyés sans chiffrement | Interception des communications | Espionnage, récupération d’informations confidentielles | 11 |
| I | Mauvaise configuration SPF/DKIM/DMARC | Falsification de mails | Usurpation d'identité via l'envoi de faux mails (SPAM, phishing) | 8 |
| D | Serveur SMTP ouvert ou mal sécurisé | Utilisé comme relais de spam, risque de blacklistage | Perte de réputation du domaine, interruption du service | 12 |
4. Réputation de l’organisation
| # | Vulnérabilités | Menaces | Risque associé | Code Ref. Analyse des risques |
|---|---|---|---|---|
| C | Fuite de données sensibles (utilisateurs, mails, mots de passe) | Perte de confiance des utilisateurs, impact médiatique | Perte de client, perte financière | 6 |
| I | Défiguration du site web, envoi de mails frauduleux | L’image de l’organisation est associée à des activités malveillantes (phishing, escroquerie) | Perte de client, perte financière | 8 |
| D | Pannes fréquentes, services inaccessibles (web, mail, DNS) | Utilisateurs mécontents, mauvaise réputation en ligne | Perte de client, perte financière | 12 |
5. Sauvegardes
| # | Vulnérabilités | Menaces | Risque associé | Code Ref. Analyse des risques |
|---|---|---|---|---|
| C | Sauvegardes non chiffrées ou stockées localement | Accès non autorisé ou vol | Exploitation de données sensible de l'utilisateur en cas de dataleak | 5 |
| I | Aucune vérification d’intégrité | Données altérées sans possibilité de restauration fiable | Propagation d’erreurs dans les systèmes & Risque de sécurité | 13 |
| D | Sauvegardes absentes ou non testées | Perte définitive de données après incident | Perte des données importantes ou altération des données utilisateur | 10 |
6. Zone DNS
| # | Vulnérabilités | Menaces | Risque associé | Code Ref. Analyse des risques |
|---|---|---|---|---|
| C | Zone DNS modifiable sans authentification forte, sans DNSSEC | Redirection malveillante des noms de domaine | Détournement du DNS pour rediriger les utilisateurs | 2 |
| I | Modification non autorisée des enregistrements | Empoisonnement DNS | Détournement du DNS pour rediriger les utilisateurs | 7a |
| D | Serveur DNS mal configuré ou vulnérable | Rupture du service DNS | Indisponibilité du site web | 2 |
7. Serveur VPS
| # | Vulnérabilités | Menaces | Risque associé | Code Ref. Analyse des risques |
|---|---|---|---|---|
| C | Mots de passe faibles du compte administrateur VPS | Prise de contrôle du serveur | Piratage du VPS via un mot de passe SSH faible | 2 |
| I | Système d’exploitation ou services non mis à jour | Altération ou compromission via vulnérabilité connue | Piratage du VPS par exploitation d’une faille non corrigée | 1c |
| D | Serveur VPS hors service | Indisponibilité totale du serveur | Perte de client perte de confiance, perte financière | 1d |
8. Comptes utilisateurs
| # | Vulnérabilités | Menaces | Risque associé | Code Ref. Analyse des risques |
|---|---|---|---|---|
| C | Mots de passe stockés en clair ou trop faibles | Vol d’identité, accès non autorisé | Exploitation de données sensible de l'utilisateur en cas de dataleak | 5 |
| I | Absence de contrôle des accès | Usurpation ou modification de privilèges | Perte d’intégrité du site, compromission de l’image de l’entreprise, risque pour la sécurité des clients | 15 |
| D | Absence de système de réinitialisation fiable | Utilisateur bloqué ou abus possible via spam de demandes de réinitialisation | Indisponibilité du site web | 7b |
9. Certificats TLS/SSL
| # | Vulnérabilités | Menaces | Risque associé | Code Ref. Analyse des risques |
|---|---|---|---|---|
| C | Certificats TLS/SSL expirés | Risque d’attaque de type MITM (man-in-the-middle) & gros warning sur le navigateur du client, créant de la confusion et de la méfiance | Perte de confiance chez le client ou client en danger à cause de le non encryptions des données. | 14 |
| I | Mauvaise gestion du renouvellement ou usage inadapté | Dégradation de la confiance des utilisateurs | Perte de confiance chez le client ou client en danger à cause de la non encryptions des données. | 14 |
| D | Erreur de configuration (ex : HTTPS désactivé) | Site considéré comme non sécurisé, perte de trafic | Perte de confiance chez le client ou client en danger à cause de le non encryptions des données. | 14 |
10. Service web (Apache/Nginx)
| # | Vulnérabilités | Menaces | Risque associé | Code Ref. Analyse des risques |
|---|---|---|---|---|
| C | Mauvaise configuration SSL | Interception du trafic (MITM) | Perte de confiance chez le client ou client en danger à cause de le non encryptions des données. | 14 |
| I | Mauvaise configuration des permissions | Défigurations, attaques sur le contenu | Perte d’intégrité du site, compromission de l’image de l’entreprise, risque pour la sécurité des clients | 15 |
| D | Failles non corrigées (DoS via HTTP, CVE connues) | Indisponibilité du site | Piratage du VPS par exploitation d’une faille non corrigée | 1c |
11. Code source des sites web
| # | Vulnérabilités | Menaces | Risque associé | Code Ref. Analyse des risques |
|---|---|---|---|---|
| C | Dépôt public ou exposé par erreur | Révélation d’informations sensibles (mots de passe, configurations) | Piratage du VPS via divulgation de clé de connexion ou du mot de passe | 1a |
| I | Failles de sécurité dans le code | Modification du site ou attaque contre les utilisateurs | Utilisation d’injections pour leak des données & Utilisation d’injections pour exécuter du code malveillant côté client | 1c |
| D | Dépendances obsolètes ou non maintenues | Plantage ou indisponibilité du service | Problème de stabilité, mauvaise expérience utilisateur, service non disponible | 16 |
3. Analyse des risques
| # | Menace | Probabilité | Impact | Estimation du risque | Contre-mesure |
|---|---|---|---|---|---|
| 1a | Piratage du VPS via divulgation de clé de connexion ou du mot de passe | Faible | Fort (prise de contrôle du serveur) | Élevé | Authentification par clé SSH et mot de passe combinés + rotation régulière du mot de passe |
| 1b | Piratage du VPS via un mot de passe SSH faible | Moyenne | Fort (prise de contrôle du serveur) | Élevé | Authentification par clé SSH, désactivation du compte root, Fail2Ban, mot de passe robuste |
| 1c | Piratage du VPS par exploitation d’une faille non corrigée | Moyenne | Fort (prise de contrôle du serveur) | Élevé | Mises à jour régulières & scan de vulnérabilités (ex. Nessus) |
| 1d | Crash du VPS | Élevé | Élevé (indisponibilité totale du service) | Élevé | Sauvegardes régulières, système de monitoring, plan de reprise d'activité |
| 2 | Détournement du DNS pour rediriger les utilisateurs | Moyenne | Fort (redirection vers un faux site) | Élevé | DNSSEC, sécurisation de la configuration BIND |
| 3a | Utilisation d’injections pour leak des données | Moyenne | Extrême | Élevé | Échappement des entrées, utilisation d’un ORM |
| 3b | Utilisation d’injections pour exécuter du code malveillant côté client | Moyenne | Extrême (perte de confiance, réputation, poursuites) | Élevé | Échappement des entrées, utilisation d’un ORM |
| 4 | Perte de données de la base due à un crash du VPS | Moyenne | Fort | Élevé | Sauvegarde automatique + export régulier hors site |
| 5 | Exploitation de données sensibles en cas de dataleak | Moyenne | Extrême (perte de confiance, poursuites) | Élevé | Hachage des données sensibles (mots de passe, CB) |
| 6 | Fuite de mails due à une mauvaise configuration SMTP | Faible | Moyen (perte de confidentialité) | Moyen | Configuration stricte Postfix/Dovecot, TLS, SPF/DKIM/DMARC |
| 7a | Indisponibilité du site web (attaque DNS) | Faible | Fort | Moyen | DNSSEC, sécurisation BIND, surveillance des requêtes |
| 7b | Indisponibilité du site web (DDoS ou crash PHP) | Faible | Fort (site inaccessible, perte d’image) | Moyen | Surveillance, redémarrage automatique, limitation des requêtes |
| 8 | Usurpation d’identité via faux mails (spam/phishing) | Faible | Haut | Moyen | Mise en place de SPF, DKIM et DMARC |
| 9 | Mauvaise configuration DNS rendant les services inaccessibles | Moyenne | Moyen | Moyen | Vérifications régulières, supervision DNS |
| 10 | Perte ou altération de données importantes | Moyenne | Moyen | Moyen | Backups multi-supports automatisés et testés + ne pas travailler avec sudo, moindre privilège |
| 11 | Espionnage via service mail non chiffré | Moyenne | Moyen | Moyen | Chiffrement des mails |
| 12 | Perte de réputation du domaine / interruption de service | Moyenne | Moyen | Moyen | Filtrer les mails internes & authentification SMTP |
| 13 | Absence de vérification d’intégrité des données | Faible | Moyen (propagation d’erreurs, exécution de données altérées) | Moyen | Hash, signature, contrôle de version, sauvegardes vérifiées |
| 14 | Données non chiffrées (mauvaise config ou certificats expirés) | Faible | Moyen (perte de confiance, exposition de données) | Moyen | Gestion auto des certificats (Let’s Encrypt), surveillance TLS/SSL |
| 15 | Perte d’intégrité du site, compromission de l’image de l’entreprise, risque pour la sécurité des clients à cause d'une modification des fichiers de configuration du a des droits mal géré en cas de compromission du serveur web | Faible | Moyen (perte de confiance, exposition) | Moyen | Permissions strictes (ex. ro) |
| 16 | Instabilité due à des dépendances obsolètes | Faible | Moyen (indisponibilité, mauvaise UX) | Moyen | Veille techno, mises à jour régulières, outils de gestion de vulnérabilités |
4. Contre-mesures
Une fois les risques évalués, nous devons adopter des contre-mesures efficaces pour y faire face.
Ces contre-mesures peuvent être classées selon trois grandes catégories : les personnes, les éléments physiques et les éléments informatiques.
| Contre-ref | Contre-mesure | Catégorie | Explication / justification |
|---|---|---|---|
| 1a | Authentification par clé SSH + mot de passe, rotation régulière du mot de passe | Informatique | Clé et mot de passe forment deux secrets isolés. Changer le mot de passe réduit la fenêtre d’attaque |
| 1b | Authentification par clé SSH, désactivation du compte root, Fail2Ban, mot de passe robuste | Informatique | La clé évite l’envoi d’un mot de passe sur le réseau. Sans root direct et avec blocage bruteforce, le pirate s’épuise tandis qu’un mot de passe robuste protège les comptes restants |
| 1c | Mises à jour régulières & scan de vulnérabilités (ex. Nessus) | Informatique | Les correctifs ferment les failles avant qu’elles ne soient utilisées. Le scanner liste les vulnérabilités pour une réaction immédiate |
| 1d | Sauvegardes régulières, système de monitoring, plan de reprise d’activité | Physique | Les copies hors ligne ramènent les données après un crash. La surveillance et le plan documenté guident la remise en service |
| 2 | DNSSEC, sécurisation de la configuration BIND | Informatique | Les réponses signées bloquent le cache poisoning. Le durcissement retire recursion ouverte et autres fonctions risquées |
| 3a, 3b | Échappement des entrées, utilisation d’un ORM | Informatique | Chaque caractère spécial est neutralisé avant la base. L’ORM génère du SQL sûr donc l’injection ne passe pas |
| 4 | Sauvegarde automatique + export régulier hors site | Physique | Dump régulier pour ne pas trop perdre + stockage distant et multiple pour garantir une copie survivante. |
| 5 | Hachage des données sensibles (mots de passe, CB) | Informatique | Hash fort avec sel rend le mot de passe illisible même volé. Les cartes bancaires hachées demeurent inutiles pour l’attaquant |
| 6 | Configuration stricte Postfix/Dovecot, TLS, SPF/DKIM/DMARC | Informatique | TLS chiffre le transport donc personne ne lit en clair |
| 7a | DNSSEC, sécurisation BIND, surveillance des requêtes | Informatique | La zone authentifiée sécurise et empêche le cache poisoning et les métriques volume détectent l’attaque DNS |
| 7b | Surveillance, redémarrage automatique, limitation des requêtes | Informatique | Le service redémarre dès la panne PHP. La limite de requêtes freine l'attaque DDoS. |
| 8 | Mise en place de SPF, DKIM & DMARC | Informatique | Ces mécanismes authentifient les emails envoyés depuis le domaine, empêchant leur usurpation (phishing, spam) |
| 9 | Vérifications régulières, supervision DNS | Informatique | Assure que la configuration DNS reste conforme et détecte toute altération |
| 10 | Backups multi-supports automatisés et testés, ne pas travailler avec sudo, moindre privilège | Personnes | Limiter l'usage de sudo pour éviter des erreurs, et tester les sauvegardes garantit leur fiabilité en cas de besoin. |
| 11 | Chiffrement des mails | Informatique | Le contenu reste privé sans la clé du destinataire donc l’espionnage échoue |
| 12 | Filtrage des mails internes & authentification SMTP | Informatique | L’authentification prouve l’expéditeur et préserve la réputation + Le filtrage stoppe les envois suspects |
| 13 | Hash, signature, contrôle de version, sauvegardes vérifiées | Informatique | Chaque fichier est signé et versionné, toute altération est visible et réversible |
| 14 | Gestion automatique des certificats (Let’s Encrypt), surveillance TLS/SSL | Informatique | Renouvellement automatique évite un certificat expiré |
| 15 | Permissions strictes (lecture seule, etc.) | Informatique | Même si le serveur web tombe, l’attaquant ne peut rien écrire donc le code reste intact |
| 16 | Veille technologique, mises à jour régulières, outils de gestion de vulnérabilités | Personnes | La veille repère les bibliothèques périmées. Les mises à jour continues maintiennent la stabilité et la sécurité |
Suivi des contre-mesures
La mise en œuvre d’une contre-mesure ne suffit pas à garantir la sécurité sur le long terme. Pour être réellement efficace, chaque mesure doit être suivie dans le temps à travers plusieurs actions structurées et rigoureuses :
Validation lors du déploiement
Avant de considérer une contre-mesure comme effective, il faut valider son bon fonctionnement :
- Test SSH : s'assurer que la connexion au VPS ne fonctionne qu'avec une clé privée et que le mot de passe est désactivé.
- Test du pare-feu : vérifier que seuls les ports nécessaires sont ouverts (par exemple 80/443 pour le web, 53 pour le DNS, 25/587/993 pour les mails).
- Vérification DNSSEC : tester que la signature des zones DNS fonctionne avec un outil comme
dig +dnssec. - Simulation d’injection SQL : tester un formulaire avec des caractères spéciaux pour vérifier la bonne protection de la base de données.
Documentation claire et accessible
La documentation est essentielle pour assurer la continuité en cas de changement d’administrateur :
- Procédures pas à pas pour l’installation, la configuration et la mise à jour des services.
- Fiches de configuration pour chaque machine/service (ex. :
/etc/ssh/sshd_config,/etc/bind/named.conf.options,nginx.conf, etc.). - Inventaire des services et des ports utilisés, avec un schéma réseau si possible.
Maintenance régulière
Une contre-mesure non maintenue perd en efficacité, voire devient une vulnérabilité :
- Mises à jour système automatiques ou planifiées régulièrement (via
unattended-upgrades,apt,dnf, etc.). - Mises à jour des applications (ex. : PHP, MariaDB/MySQL, Postfix, Dovecot) pour éviter les failles critiques (CVE).
- Revue périodique de la configuration (ex. : s’assurer que les règles Fail2ban sont toujours actives).
Monitoring actif
La surveillance continue permet de détecter rapidement les anomalies ou tentatives d’attaque :
- Surveillance des journaux :
/var/log/auth.logpour SSH et les tentatives de connexion./var/log/mysql/error.logpour la base de données./var/log/mail.logpour le serveur de messagerie.
- Utilisation d’outils de supervision :
- Prometheus + Grafana pour suivre la charge serveur, les accès, l’espace disque, etc.
- Logwatch / Rsyslog pour des rapports automatiques des journaux critiques.
- Alertes par mail ou via webhook en cas d’anomalie (erreurs HTTP 500, trop de tentatives SSH, etc.).
Vérifications périodiques et audits
Même une configuration initialement sécurisée peut devenir vulnérable avec le temps :
- Tests de vulnérabilités (Nessus, OpenVAS, Lynis).
- Audit SSH : vérifier que seules les IP ou utilisateurs autorisés ont accès.
- Contrôle des permissions des fichiers sensibles : fichiers de zone DNS, etc.
- Revue des comptes utilisateurs : suppression des comptes inutiles ou oubliés.
5. Gestion des risques résiduels et procédures de détection / réaction / récupération
Même après l’identification des menaces et la mise en place de contre-mesures adaptées, certains risques subsistent. On parle alors de risques résiduels, qui peuvent être de deux types :
- Risques connus mais non traités, souvent en raison de contraintes budgétaires, techniques ou propres à une société.
- Risques inconnus, comme les failles 0-day ou des erreurs de configuration.
La sécurité ne peut pas être assurée à 100 %, il faut donc mettre en place des procédures de détection, de réaction et de récupération, afin de limiter l’impact d’un incident de sécurité sur la société.
Risques résiduels
| Risque identifié | Raison du non-traitement | Type | Réf. Analyse sécurité | Impact potentiel | Mesures atténuantes en place |
|---|---|---|---|---|---|
| Vulnérabilité 0-day | Dépendance aux correctifs éditeur | Risque inconnu | 1c, 16 | Prise de contrôle, fuite de données | Mises à jour régulières, scanner de vulnérabilités |
| DDoS massif | Coût élevé d’une solution dédiée | Risque connu non traité | 1b, 7b | Indisponibilité des services | Fail2Ban, monitoring, alertes |
| Erreur humaine (config critique) | Complexité technique + ressources limitées | Risque connu non traité | 10, 15 | Altération/défaillance de service critique | Documentation, validation manuelle, logs |
Détection des incidents
Pour pouvoir réagir à une attaque, encore faut-il être capable de la détecter rapidement. Cela passe par :
- La supervision des services critiques (web, base de données, DNS, mail, etc.) via des outils comme Prometheus et des tableaux de bord Grafana.
- La surveillance des logs système (authentification, erreurs, accès web, logs MySQL, etc.) avec des outils comme Fail2ban, Logwatch ou Wazuh/OSSEC.
- La mise en place de systèmes de détection d’intrusion, comme Snort ou Suricata, pouvant alerter sur des comportements réseau anormaux.
- Des alertes automatisées (email, SMS, webhook) dès qu’un seuil critique est dépassé (ex. : trop de connexions SSH échouées, usage CPU/disque anormal, etc.).
Objectifs de continuité (RTO / RPO)
L’analyse des risques a mis en évidence plusieurs menaces critiques, notamment :
- L’indisponibilité totale du serveur (risque 1d),
- La perte ou corruption de la base de données (risque 4, 10),
- L’interruption des services de messagerie ou DNS (risques 7a, 12),
- L’exploitation d’une faille 0-day (risque 1c),
- Les attaques DDoS (risque 7b),
- Les erreurs humaines sur des configurations critiques (risque 10, 15).
Afin de garantir une continuité d'activité minimale sans compromettre la qualité de service ni les données critiques, les valeurs cibles suivantes ont été définies :
| Objectif | Définition | Valeur retenue | Justification |
|---|---|---|---|
| RTO (Recovery Time Objective) | Temps maximum d’interruption acceptable | 2 heures | Permet la remise en ligne d’un service web ou base en cas de panne via restauration de conteneurs et sauvegardes locales. Le risque 1d impose un temps de reprise rapide. |
| RPO (Recovery Point Objective) | Période maximale de perte de données tolérée | 1 heure | L’analyse de risque (risques 4, 10) montre que la base de données est critique. Des sauvegardes horaires garantissent cette exigence. |
Mesures techniques mises en place pour atteindre ces objectifs
| Mesure | Description | Risques concernés |
|---|---|---|
| Sauvegardes automatisées toutes les heures | Dump de la base de données et des fichiers sensibles (config, web, mail) sur un volume isolé | 4, 5, 10 |
| Snapshots Docker réguliers | Création de snapshots journaliers pour une restauration rapide des services applicatifs | 1d, 16 |
| Monitoring proactif (Prometheus + Alerting) | Détection des anomalies système (crash, charge CPU, logs suspects) | 1d, 7b, 11 |
| Test périodique des sauvegardes | Validation manuelle des fichiers de restauration pour éviter les mauvaises surprises | 10, 13 |
| Documentation des procédures de reprise | Étapes claires pour relancer chaque conteneur à l’identique avec ses paramètres | 1d, 10, 15 |
Réaction aux incidents
En cas de détection d’un incident, les procédures suivantes sont appliquées, conformément à l’analyse des risques :
| Étape | Action | Objectif | Référence |
|---|---|---|---|
| Détection | Surveillance automatique des logs système, échecs SSH, surcharges CPU, erreurs applicatives | Déclencher une alerte avant dégradation critique | 1b, 7b, 11 |
| Isolation | Mise hors ligne temporaire d’un conteneur ou fermeture de port via UFW | Éviter la propagation ou le maintien de l’attaque | 1c, 15 |
| Analyse | Vérification des journaux (auth.log, mail.log, syslog, etc.) et comparaison avec les snapshots | Identifier la source de la compromission | 1c, 10, 16 |
| Communication | Information des intervenants techniques et, si nécessaire, des utilisateurs ou du prestataire VPS | Garantir la transparence et la coordination | 4, 12 |
| Correction | Patch système, régénération de certificats, changement de mot de passe, reconfiguration service | Stopper définitivement la faille | 1c, 14 |
Récupération post-incident
Une fois l’attaque contenue, les actions suivantes permettent une reprise rapide et fiable :
| Étape | Action | Risques couverts |
|---|---|---|
| Restauration | Réimportation des données depuis la dernière sauvegarde horaire saine (RPO ≤ 1 h) | 4, 10 |
| Redéploiement des conteneurs | Utilisation des snapshots Docker avec fichiers de config versionnés | 1d, 16 |
| Contrôle d’intégrité | Vérification post-restauration (hash, logs, accès web testés) | 13, 14 |
| Suivi post-incident | Rédaction d’un rapport d’analyse, plan d’amélioration, mise à jour des procédures | Tous |
Métriques pour la planification de la continuité d’activité
-
RPO (Recovery Point Objective) : définit la quantité de données que l’on accepte de perdre en cas de panne.
Exemple : un RPO de 1 h implique une sauvegarde toutes les heures, au minimum.
-
RTO (Recovery Time Objective) : correspond au temps maximum acceptable d’indisponibilité du service.
Exemple : un RTO de 2 h implique que les services doivent être restaurés dans les deux heures suivant l’incident.
Mise en pratique (infrastructure VPS)
| Événement | Détection | Réaction | Récupération |
|---|---|---|---|
| SSH compromis | Alerte Fail2ban + pic d’échecs dans les logs | Interruption du service SSH, révocation des clés concernées | Réactivation avec de nouvelles clés, rotation des mots de passe |
| Ransomware sur site web | Alertes CPU/disque + logs suspects | Isolation du conteneur/dossier, arrêt du service | Restauration depuis une sauvegarde distante |
| Faille 0-day sur DNS BIND | Annonce de CVE + scan régulier | Application du patch, redémarrage contrôlé du service | Vérification de l’intégrité des zones et des logs |
6. Amélioration continue et gestion post-incident
Mise en pratique concrète de la gestion d'incident
Les incidents ci-dessous sont directement dérivés des risques majeurs identifiés dans l’analyse précédente (failles 0-day, erreurs humaines, DDoS, compromission SSH, etc.). Ils illustrent les capacités de détection, réaction et reprise de l’infrastructure VPS décrite.
| Scénario d’incident | Détection | Réaction | Récupération |
|---|---|---|---|
| Compromission SSH (risques 1a, 1b) | Alertes Fail2ban + échecs anormaux dans auth.log |
Suspension du service SSH, révocation des clés, audit des comptes utilisateurs | Réactivation du service avec nouvelles clés SSH, rotation des mots de passe, renforcement UFW |
| Erreur humaine sur la base de données (risques 10, 15) | Anomalies SQL dans les logs, données corrompues ou supprimées | Mise hors ligne du conteneur PHP, rollback manuel | Restauration depuis le dernier dump validé (RPO = 1 h), vérification des droits et permissions |
| Attaque DDoS (risque 7b) | Augmentation du trafic détectée via Prometheus + logs NGINX | Blocage temporaire via UFW, activation du rate limiting |
Retour à la normale surveillé, ajustement de la limite de connexions |
| Faille 0-day sur le DNS (risques 1c, 16) | Notification CERT + scan Nessus détectant une vulnérabilité critique | Application immédiate du correctif de sécurité, redémarrage contrôlé de BIND9 | Vérification de l’intégrité des zones DNS, consultation des logs |
Nécessité d’une amélioration continue
L’analyse de risque a démontré que certains risques résiduels persistent malgré les contre-mesures déployées, notamment :
- Les 0-day (risques inconnus, non maîtrisables),
- Les erreurs humaines (inévitables dans une petite équipe),
- Les attaques DDoS massives (protection dédiée non déployée).
Pour faire face à ces menaces évolutives, l’infrastructure doit intégrer une démarche d’amélioration continue, garante de sa résilience dans le temps.
Objectifs principaux :
- S’assurer que les contre-mesures existantes restent efficaces.
- Détecter les nouvelles failles avant qu’elles ne soient exploitées.
Mise en œuvre du cycle PDCA
Le modèle PDCA (Plan – Do – Check – Act) est appliqué à l’infrastructure analysée comme suit :
| Phase | Objectif | Mise en œuvre sur le VPS |
|---|---|---|
| Plan (Planifier) | Identifier les nouvelles menaces et points faibles | Veille CVE/CERT, revue de configuration, analyse des logs |
| Do (Mettre en œuvre) | Appliquer les mesures correctives ou préventives | Mises à jour, reconfiguration BIND, activation de TLS strict |
| Check (Vérifier) | Contrôler l'efficacité des changements | Tests d'injection SQL, test de restauration, scans de vulnérabilités |
| Act (Ajuster) | Améliorer les procédures, documenter, former | Mise à jour des procédures internes, relecture collective des configs |
Outils et pratiques de maintien en condition de sécurité
Pour garantir l’efficacité de cette amélioration continue, plusieurs moyens peuvent être mise en place:
| Moyen | Objectif | Risques concernés |
|---|---|---|
| Veille technologique (CVE, CERT) | Anticiper les 0-day et vulnérabilités critiques | 1c, 16 |
| Audit de permissions et tests de sécurité | Réduire les risques d’erreurs humaines ou de failles applicatives | 10, 15, 3a |
| Supervision active (Prometheus/Grafana) | Détecter les anomalies système et comportements anormaux | 1d, 7b |
| Revues de logs & configurations | Détecter les dérives ou erreurs manuelles | 10, 13 |
| Sauvegardes testées | Vérifier la capacité réelle de récupération (RPO/RTO) | 4, 10 |
| Documentation claire & formations régulières | Renforcer la transmission de savoir et éviter les erreurs | 15, 10 |
Conclusion
En définitive, la sécurité évolue de manière constante. C’est cette capacité à s’adapter et à évoluer qui permettra à l'entreprise de résister efficacement aux menaces actuelles et futures.
Documentation
Usage de l'IA : Utilisé pour l'orthographe et la grammaire uniquement.