Analyse de sécurité - DeumeniDerval/admin-2 GitHub Wiki
Analyse de sécurité de l’infrastructure
1. Identification des biens
- Notre VPS, hébergé chez OVH et tournant sous debian. Nous voulons en protéger l'accès, ainsi que la disponibilité qui sont cruciaux car il est responsable de :
- Notre infrastructure, principalement composée des services exécutés par docker (DNS, Nginx, PHP, MariaDB, Mail), dont la disponibilité et la fiabilité dépend grandement de celles du VPS. Cette infrastructure repose sur :
- Nos données, hébergées sur notre VPS. Par exemple :
- Les fichiers HTML servis par nginx
- Les données contenues dans la base de données
- Les données de notre serveur mail
- Les RRs DNS
- Les clés privées, notamment pour le certificat de zone, la chaine de confiance DNS ainsi que l'identification SSH. Ce type de données est particulièrement sensible car la sécurité et l'intégrité de toute notre infrastructure en dépend.
Schema d'infrastucure
Le VPS est relié à Internet, son adresse IP est 54.36.181.37.
ipTables est configuré pour servir de pare-feu afin de protéger le VPS d'attaques potentielles.
Le service SSH est configuré avec un port secret, pour prévenir des attaques par force brute.
La connexion de l'infrastructure est gérée par Docker.
Les conteneurs mail et DNS sont chacun sur un subnet. Le port 53 du DNS et les ports 465 et 993 du mail sont publiés afin de pouvoir être accessibles depuis l'extérieur du VPS.
Le service web est segmenté en deux subnets : dmz pour le trafic entre nginx et PHP, et db_net entre PHP et la DB.
Ceci permet une isolation entre le serveur web, accessible depuis l'extérieur puisque ses ports 80 et 443 sont publiés, et la base de données dont le port 3306 n'est pas publié et accessible seulement depuis le subnet (tout comme le port 9000 du conteneur PHP).
Cette isolation est une mesure de sécurité afin de protéger les données de la BDD.
Enfin, la zone DNS est configurée pour publier plusieurs Host :
- ns, pour le serveur DNS
- mail, pour le serveur mail
- www et blog, gérés par nginx
Tout ces Host partagent l'adresse du VPS.
2. Vulnérabilités
VPS (Debian chez OVH)
| Type | Vulnérabilité |
|---|---|
| Confidentialité | Accès SSH potentiellement exposé sans filtrage IP |
| Confidentialité | Clés privées stockées en clair sur le disque |
| Confidentialité | Données sensibles dans les journaux système accessibles localement |
| Confidentialité | Absence de chiffrement de disque ou de snapshot OVH protégé |
| Intégrité | Vulnérabilités kernel locales permettant élévation de privilèges |
| Intégrité | Binaire système modifiable si intégrité non vérifiée |
| Intégrité | Écriture arbitraire par utilisateur root compromis |
| Disponibilité | Attaques DoS/DDoS ciblant SSH ou services réseau |
| Disponibilité | Ressources système consommables par processus malveillants |
| Disponibilité | Dépendance unique à OVH (risque de panne centralisée) |
Docker
| Type | Vulnérabilité |
|---|---|
| Confidentialité | Socket Docker accessible à un conteneur = escalade totale |
| Confidentialité | Variables d’environnement contenant secrets accessibles depuis les conteneurs |
| Confidentialité | Mauvais cloisonnement réseau entre conteneurs |
| Intégrité | Images non signées ou téléchargées depuis un registre non fiable |
| Intégrité | Conteneurs exécutés avec --privileged ou en root |
| Intégrité | Volumes montés en écriture contenant des fichiers de configuration |
| Disponibilité | Saturation mémoire ou CPU d’un conteneur affectant l’hôte |
| Disponibilité | Crash d’un service Docker affectant d'autres via redémarrages en boucle |
| Disponibilité | Exploitation d’une vulnérabilité dans le moteur Docker |
DNS
| Type | Vulnérabilité |
|---|---|
| Confidentialité | Configuration incorrecte des enregistrements DNS (exposition d’informations sensibles) |
| Confidentialité | Utilisation de protocoles DNS non sécurisés (ex : absence de DNS over TLS/HTTPS) |
| Intégrité | Vulnérabilités dans le logiciel DNS (ex: faille dans BIND, dnsmasq, etc.) |
| Intégrité | Attaques par empoisonnement de cache DNS (DNS cache poisoning) |
| Intégrité | Absence de signatures DNSSEC ou mauvaise implémentation DNSSEC |
| Disponibilité | Attaques par déni de service (DoS/DDoS) ciblant le serveur DNS |
Nginx
| Type | Vulnérabilité |
|---|---|
| Confidentialité | Fichiers .env, .git ou de backup exposés publiquement |
| Confidentialité | Mauvaise configuration des règles d’accès (ex : /admin non protégé) |
| Confidentialité | Informations sensibles divulguées via headers HTTP mal configurés |
| Intégrité | Possibilité d’injecter des scripts (XSS) via mauvaise validation en amont |
| Intégrité | Réécriture ou suppression de fichiers via mauvaise gestion des permissions |
| Disponibilité | Attaques de type Slowloris ou flood HTTP |
| Disponibilité | Mauvaise configuration entraînant plantages (worker_connections, timeouts, etc.) |
PHP
| Type | Vulnérabilité |
|---|---|
| Confidentialité | Inclusion de fichiers non protégés (LFI – Local File Inclusion) |
| Confidentialité | Exposition d’erreurs PHP contenant des chemins ou données sensibles |
| Confidentialité | Accès direct à des fichiers exécutables via URL (.php~, .bak, etc.) |
| Intégrité | Failles d’injection (RCE, code eval() vulnérable) |
| Intégrité | Manipulation des fichiers via uploads mal filtrés |
| Disponibilité | Scripts PHP pouvant épuiser mémoire ou temps de traitement |
| Disponibilité | Exploits ciblant des failles de la version PHP utilisée |
MariaDB
| Type | Vulnérabilité |
|---|---|
| Confidentialité | Accès réseau sans restriction IP ou chiffrement |
| Confidentialité | Comptes avec privilèges excessifs ou mots de passe faibles |
| Confidentialité | Fichiers de dump ou sauvegardes stockés sans protection |
| Intégrité | Injections SQL via entrées non filtrées dans les applications |
| Intégrité | Écriture directe dans les tables critiques via comptes mal configurés |
| Disponibilité | Requêtes lourdes ou récursives bloquant les threads |
| Disponibilité | Exploitation de failles dans le moteur de stockage (ex : crash) |
Serveur mail
| Type | Vulnérabilité |
|---|---|
| Confidentialité | Courriels stockés en clair, accessibles en local |
| Confidentialité | Ports IMAP/SMTP exposés sans chiffrement (STARTTLS absent ou mal configuré) |
| Confidentialité | Mauvaise configuration des ACL ou boîtes partagées |
| Intégrité | Modification des messages via compromission locale |
| Intégrité | Spoofing ou usurpation d’identité si SPF/DKIM absents |
| Disponibilité | Saturation de la file d’attente via spam ou rebonds |
| Disponibilité | Rejet de messages par blacklist suite à envoi massif |
Fichiers (config, HTML, zones DNS, mails, dumps, etc.)
| Type | Vulnérabilité |
|---|---|
| Confidentialité | Fichiers sensibles accessibles via le web |
| Confidentialité | Permissions laxistes sur fichiers privés |
| Confidentialité | Présence de dumps ou backups non chiffrés |
| Intégrité | Modification silencieuse des fichiers critiques |
| Intégrité | Absence de suivi de version ou d’audit des changements |
| Disponibilité | Suppression ou corruption de fichiers critiques |
| Disponibilité | Verrouillage ou écrasement par un service mal configuré |
3. Analyse des risques
| Bien/Service | Vulnérabilité | Probabilité | Impact | Estimation du risque |
|---|---|---|---|---|
| VPS | Accès SSH potentiellement exposé sans filtrage IP | Moyenne | Élevé | Élevé |
| VPS | Clés privées stockées en clair sur le disque | Faible | Critique | Élevé |
| VPS | Données sensibles dans journaux accessibles | Moyenne | Moyen | Moyen |
| VPS | Absence de chiffrement disque ou snapshot | Faible | Critique | Élevé |
| VPS | Vulnérabilités kernel locales (élévation privilèges) | Faible | Critique | Élevé |
| VPS | Binaire système modifiable sans contrôle intégrité | Faible | Critique | Élevé |
| VPS | Écriture arbitraire par root compromis | Faible | Critique | Élevé |
| VPS | Attaques DoS/DDoS ciblant SSH ou services réseau | Moyenne | Élevé | Élevé |
| VPS | Ressources système consommables par processus malveillants | Moyenne | Moyen | Moyen |
| VPS | Dépendance unique à OVH | Faible | Élevé | Moyen |
| Docker | Socket Docker accessible à un conteneur | Faible | Critique | Élevé |
| Docker | Variables d’environnement secrets accessibles | Faible | Élevé | Élevé |
| Docker | Mauvais cloisonnement réseau entre conteneurs | Moyenne | Élevé | Élevé |
| Docker | Images non signées ou registre non fiable | Moyenne | Élevé | Élevé |
| Docker | Conteneurs exécutés avec --privileged ou root |
Faible | Critique | Élevé |
| Docker | Volumes montés en écriture avec fichiers config | Moyenne | Élevé | Élevé |
| Docker | Saturation mémoire/CPU d’un conteneur | Moyenne | Élevé | Élevé |
| Docker | Crash d’un service Docker avec redémarrage en boucle | Faible | Élevé | Moyen |
| Docker | Exploitation vulnérabilité Docker moteur | Faible | Critique | Élevé |
| DNS | Configuration incorrecte des enregistrements DNS (exposition d’informations sensibles) | Moyenne | Élevé | Élevé |
| DNS | Utilisation de protocoles DNS non sécurisés (ex : absence de DNS over TLS/HTTPS) | Moyenne | Moyen | Moyen |
| DNS | Vulnérabilités dans le logiciel DNS (ex: faille dans BIND, dnsmasq, etc.) | Faible | Élevé | Moyen |
| DNS | Attaques par empoisonnement de cache DNS (DNS cache poisoning) | Moyenne | Élevé | Élevé |
| DNS | Absence de signatures DNSSEC ou mauvaise implémentation DNSSEC | Faible | Élevé | Moyen |
| DNS | Attaques par déni de service (DoS/DDoS) ciblant le serveur DNS | Moyenne | Critique | Critique |
| Nginx | Fichiers .env, .git, backup exposés |
Moyenne | Élevé | Élevé |
| Nginx | Mauvaise config règles accès (ex: /admin non protégé) |
Moyenne | Élevé | Élevé |
| Nginx | Infos sensibles via headers HTTP mal configurés | Moyenne | Moyen | Moyen |
| Nginx | Injection de scripts (XSS) | Moyenne | Élevé | Élevé |
| Nginx | Réécriture/suppression fichiers (permissions) | Faible | Élevé | Moyen |
| Nginx | Attaques Slowloris, flood HTTP | Moyenne | Élevé | Élevé |
| Nginx | Mauvaise config provoquant plantages | Faible | Moyen | Faible |
| PHP | Inclusion fichiers non protégés (LFI) | Moyenne | Élevé | Élevé |
| PHP | Exposition erreurs PHP avec données sensibles | Moyenne | Moyen | Moyen |
| PHP | Accès direct fichiers exécutables via URL | Faible | Moyen | Faible |
| PHP | Failles d’injection RCE | Moyenne | Critique | Élevé |
| PHP | Uploads mal filtrés | Moyenne | Élevé | Élevé |
| PHP | Scripts épuisant mémoire/temps | Moyenne | Élevé | Élevé |
| PHP | Exploits version PHP vulnérable | Faible | Élevé | Moyen |
| MariaDB | Accès réseau sans restriction ou chiffrement | Faible | Critique | Élevé |
| MariaDB | Comptes avec privilèges excessifs | Moyenne | Critique | Élevé |
| MariaDB | Dumps/sauvegardes non protégés | Moyenne | Élevé | Élevé |
| MariaDB | Injection SQL via applications | Moyenne | Critique | Élevé |
| MariaDB | Écriture dans tables critiques | Faible | Critique | Moyen |
| MariaDB | Requêtes lourdes bloquant threads | Moyenne | Élevé | Élevé |
| MariaDB | Exploitation failles moteur stockage |
4. Contre-mesures
Chaque vulnérabilité identifiée est associée à une menace, qui fait l’objet d’une évaluation du risque. Une contre-mesure correspondante est ensuite proposée, dans la mesure du budget et des ressources disponibles.
Les contre-mesures doivent être correctement déployées, documentées, surveillées et révisées.
Tableau : Vulnérabilité → Menace → Contre-mesure
| Bien | Vulnérabilité | Menace associée | Contre-mesure proposée |
|---|---|---|---|
| VPS | Accès SSH potentiellement exposé sans filtrage IP | Intrusion par force brute | Restreindre SSH par pare-feu et filtrage IP |
| VPS | Clés privées stockées en clair | Vol de clé → accès complet | Chiffrement des clés et répertoires restreints |
| VPS | Données sensibles dans logs système accessibles | Exfiltration de données via logs | Nettoyage des logs + journalisation contrôlée |
| VPS | Absence de chiffrement de disque | Accès aux données après compromission physique | Chiffrement des volumes (dm-crypt/LUKS) |
| VPS | Vulnérabilités kernel locales | Élévation de privilèges | Mises à jour régulières et surveillance vulnérabilités |
| VPS | Binaire système modifiable si non protégé | Insertion de backdoor dans système | Intégrité système (AIDE, tripwire, etc.) |
| VPS | Écriture arbitraire en root | Dégradation complète du système | Restrictions strictes sudo/root |
| VPS | DoS/DDoS réseau | Indisponibilité du serveur | Filtrage réseau, mitigation OVH, limites de connexions |
| VPS | Consommation excessive des ressources système | Blocage total de l’hôte | Limites ulimits, cgroups et supervision |
| VPS | Dépendance unique à OVH | Indisponibilité suite à incident datacenter | Prévoir une stratégie de redondance externalisée |
| Docker | Socket Docker accessible | Prise de contrôle du moteur Docker | Restreindre socket à root uniquement |
| Docker | Secrets exposés dans variables env | Fuite de données sensibles | Utiliser systèmes de secrets dédiés |
| Docker | Réseau mal isolé entre conteneurs | Espionnage ou attaque latérale | Réseaux Docker segmentés, pare-feu entre conteneurs |
| Docker | Images non signées ou d’origine douteuse | Exécution de code malveillant | Télécharger depuis registre vérifié, activer content trust |
| Docker | Conteneurs exécutés en root ou mode --privileged |
Brèche totale dans l’isolation | Utiliser utilisateurs non-root et limiter les capacités |
| Docker | Volumes montés en écriture non protégés | Écrasement de fichiers critiques | Définir les volumes en lecture seule quand possible |
| Docker | Conteneur épuisant ressources | Instabilité ou crash du VPS | Limites de ressources avec mem_limit, cpu_limit |
| Docker | Crash d’un service Docker | Interruption d’autres services | Redondance et supervision avec restart: always + monitoring |
| Docker | Exploit dans le moteur Docker | Compromission complète | Maintien à jour du moteur et durcissement de la configuration |
| DNS | Configuration incorrecte des enregistrements DNS (exposition d’informations sensibles) | Divulgation d’informations sensibles | Mise en place d’une configuration stricte des enregistrements DNS |
| DNS | Utilisation de protocoles DNS non sécurisés (ex : absence de DNS over TLS/HTTPS) | Interception et modification des requêtes | Adoption de protocoles sécurisés (DNS over TLS/HTTPS) |
| DNS | Vulnérabilités dans le logiciel DNS (ex: faille dans BIND, dnsmasq, etc.) | Exploitation de failles logicielles | Mise à jour régulière du logiciel DNS |
| DNS | Attaques par empoisonnement de cache DNS (DNS cache poisoning) | Altération des réponses DNS | Implémentation de mécanismes de validation (DNSSEC) |
| DNS | Absence de signatures DNSSEC ou mauvaise implémentation DNSSEC | Usurpation et falsification des données DNS | Activation et maintenance correcte de DNSSEC |
| DNS | Attaques par déni de service (DoS/DDoS) ciblant le serveur DNS | Indisponibilité du service DNS | Protection contre DoS, surveillance et limitation du trafic |
| Nginx | Fichiers .env, .git, backup exposés |
Fuite de secrets ou code source | Bloquer l’accès aux fichiers cachés via config nginx |
| Nginx | Mauvaise protection de répertoires sensibles | Accès non autorisé à /admin, /api |
Ajout d’authentification forte |
| Nginx | Headers HTTP informatifs | Fuite d’informations système | Masquer headers sensibles (Server, etc.) |
| Nginx | XSS via contenu mal filtré | Exécution de script malveillant côté client | Désactivation autoindex, validation côté serveur |
| Nginx | Réécriture de fichiers publics | Défiguration ou malware web | Permissions strictes sur répertoires /var/www |
| Nginx | Slowloris / Flood HTTP | Indisponibilité serveur | Limitation des connexions et timeouts |
| Nginx | Mauvaise config worker / timeout | Plantage ou saturation de Nginx | Revue et ajustement des paramètres de perf |
| PHP | Inclusion locale de fichier (LFI) | Lecture ou exécution de fichiers non prévus | Désactiver allow_url_include, filtrer les entrées |
| PHP | Fichiers d’erreur détaillés exposés | Fuite de structure du code | Désactivation de display_errors en production |
| PHP | Fichiers .php~, .bak accessibles |
Exposition de code source | Nettoyage automatique des fichiers temporaires |
| PHP | RCE via eval() ou injections |
Exécution de commande arbitraire | Suppression des fonctions dangereuses dans php.ini |
| PHP | Uploads mal filtrés | Téléversement de shell ou virus | Vérification stricte des extensions et types MIME |
| PHP | Scripts longs ou en boucle | Saturation du serveur PHP | Limiter max_execution_time et mémoire |
| PHP | Exploit de version vulnérable | Contrôle serveur via CVE connu | Mettre à jour régulièrement PHP |
| MariaDB | Accès non restreint via réseau | Connexion non autorisée | Liaison à localhost ou VPN uniquement |
| MariaDB | Comptes avec privilèges excessifs | Fuite ou modification massive de données | Principe du moindre privilège |
| MariaDB | Fichiers de dump accessibles | Fuite d’informations complètes | Stockage restreint et chiffré des sauvegardes |
| MariaDB | Injections SQL | Lecture / modification de données | Paramétrage avec PDO / mysqli et requêtes préparées |
| MariaDB | Accès en écriture mal contrôlé | Corruption de la base | ACL SQL précises et surveillance des requêtes |
| MariaDB | Requêtes lourdes | Blocage du service | Indice, analyse de performances, limites de temps |
| MariaDB | Failles moteur (MyISAM, etc.) | Crash du moteur ou corruption | Moteur InnoDB + mise à jour |
| Mails stockés en clair | Espionnage ou vol d’infos | Chiffrement du stockage ou usage d’un serveur IMAP chiffré | |
| Ports SMTP/IMAP sans TLS | Interception de mails | Activation de STARTTLS et configuration stricte | |
| ACL mal configurées | Accès non autorisé à des boîtes | Vérification des règles d’accès | |
| Modification des messages | Altération de communications | Intégrité du spool + audit des accès | |
| Absence de SPF/DKIM | Spoofing / phishing | Mise en place complète des normes SPF, DKIM, DMARC | |
| File d’attente saturée | Blocage du serveur mail | Mise en place de quotas, surveillance, greylisting | |
| Blacklist suite à abus | Rejet global des mails envoyés | Surveillance des logs, prévention des abus | |
| Fichiers | Fichiers accessibles publiquement | Fuite d’informations sensibles | Configuration restrictive du serveur web |
| Fichiers | Permissions trop permissives | Modification ou vol de données | chmod et chown stricts selon l’usage |
| Fichiers | Présence de backups non protégés | Fuite ou altération de données | Chiffrement et stockage sécurisé des backups |
| Fichiers | Altération silencieuse | Corruption ou compromission | Mise en place de mécanisme d’intégrité (hash, surveillance) |
| Fichiers | Écrasement par service mal configuré | Perte de fichiers critiques | Validation des chemins utilisés par les services |
5. Gestion des risques résiduels et procédures de détection / réaction / récupération
Certaines vulnérabilités identifiées précédemment peuvent ne pas être entièrement couvertes par des contre-mesures, faute de ressources ou de solutions techniques. De plus, des vulnérabilités inconnues (failles zero-day, erreurs de configuration non détectées) peuvent exister.
Cette section décrit les risques résiduels et les mécanismes mis en place pour détecter, réagir et récupérer efficacement en cas d’attaque ou de défaillance.
5.1. Risques résiduels spécifiques
Les risques ci-dessous ne sont pas entièrement éliminés, malgré les contre-mesures identifiées précédemment :
| Bien concerné | Vulnérabilité résiduelle | Justification |
|---|---|---|
| VPS | Dépendance unique à OVH | Pas de redondance géographique |
| Docker | Failes zero-day dans le moteur Docker | Non maîtrisable, dépend du mainteneur |
| DNS (bind) | Exploits sur la stack réseau ou DNSSEC | Impossible à prévenir totalement |
| Nginx | Erreurs de configuration manuelles ou oublis dans la validation | Facteur humain toujours possible |
| PHP | Failles dans des bibliothèques tierces | Difficulté à tout auditer manuellement |
| MariaDB | Erreurs dans les règles d'accès ou requêtes mal protégées | Risque d’erreur de configuration |
| Serveur mail | Bypass des filtres SPF/DKIM/DMARC | Dépend aussi des politiques des autres domaines |
| Données & fichiers | Perte ou altération de fichiers ou clés suite à faille non détectée | Impossible de garantir l’absence de 0-day |
5.2. Mécanismes de détection
Des outils et pratiques sont mis en œuvre pour surveiller l’infrastructure et détecter toute activité anormale :
| Cible | Mécanisme de détection |
|---|---|
| VPS (système) | Auditd + journalctl avec rotation et alertes |
| Docker | Logs Docker monitorés + contrôle des redémarrages |
| Réseau | Suricata (IDS) ou équivalent pour surveillance réseau |
| Services exposés | Fail2ban, logs Nginx, postfix, php-fpm, bind |
| Intégrité système | aide ou tripwire pour détection de modification |
| Accès administratifs | Audit des connexions SSH + alerte sur connexions root |
| Fichiers critiques | Hachage régulier et comparaison automatique |
5.3. Procédures de réaction
En cas d’attaque détectée ou de suspicion :
5.3.1. Analyse initiale
- Identifier la source (IP, utilisateur, conteneur, service)
- Vérifier les logs des services liés
- Comparer l’activité par rapport à un comportement attendu
5.3.2. Isolement et containment
- Stopper le conteneur ou le service affecté
- Isoler la machine réseau si nécessaire
- Passer en mode lecture seule les volumes concernés
5.3.3. Mobilisation des personnes
- Informer les administrateurs du service concerné
- Réunir les logs et hachages pour analyse
- Documenter immédiatement les actions entreprises
5.4. Récupération et continuité
Pour garantir la reprise d’activité :
| Élément | Méthode de récupération |
|---|---|
| Base de données | Restauration automatisée depuis sauvegarde chiffrée |
| Fichiers HTML | Git pull depuis dépôt distant |
| Zone DNS | Rechargement à partir de fichiers versionnés |
| Clés privées | Stockage dans un coffre-fort chiffré avec redondance |
| VPS complet | Snapshot OVH journalier avec rétention sur 7 jours |
5.4.1. RPO & RTO définis
| Composant | RPO | RTO |
|---|---|---|
| Données MariaDB | 15 minutes | 2 heures |
| Données mail | 1 heure | 4 heures |
| Zone DNS | 12 heures | 6 heures |
| Fichiers HTML | 24 heures | 12 heures |
| Infrastructure VPS | 1 heure (snapshot) | 6 heures |
5.5. Retours d'expérience et amélioration continue
Après chaque incident :
- Une analyse post-mortem est réalisée (causes, vecteurs, correctifs)
- La documentation est mise à jour
- Les contre-mesures sont réévaluées
- Des tests de restauration sont réalisés
Un audit de sécurité trimestriel permet de vérifier que les procédures restent à jour et efficaces.
6. Amélioration continue
Cette analyse de sécurité ne constitue pas une fin en soi, mais bien le début d’un processus cyclique d’évaluation, d’adaptation et de renforcement des pratiques de sécurité.
6.1. Veille technologique
Les administrateurs doivent s'engager dans une veille active concernant :
- Les vulnérabilités affectant les composants utilisés :
- Debian, Docker, Nginx, PHP, MariaDB, Postfix, Bind
- Les failles zero-day ou exploits publiés (CVE)
- Les bonnes pratiques de configuration et de durcissement
- Les évolutions dans les outils de monitoring et de détection
La veille doit s'appuyer sur :
- Listes de diffusion de sécurité (Debian Security Announce, CERT-FR, etc.)
- Outils de surveillance de vulnérabilités (ex. :
vulners,trivy, etc.) - Suivi des dépôts officiels des projets utilisés (GitHub, changelogs)
6.2. Surveillance du fonctionnement quotidien
Des audits périodiques et une attention quotidienne sont nécessaires pour vérifier que :
- Les contre-mesures déployées sont toujours actives et efficaces
- Les journaux système et de services ne révèlent pas d’anomalies
- Les politiques de sauvegarde sont respectées et les restaurations testées
- Les utilisateurs ne contournent pas les mesures de sécurité
6.3. Réévaluation périodique de l’analyse de risque
La situation technique, les menaces et les priorités évoluant, une révision régulière de l’analyse est indispensable :
- Trimestriellement pour les services critiques (DNS, base de données, mail)
- Annuellement pour l’ensemble de l’analyse, y compris les risques et contre-mesures
- Après tout incident ou modification majeure de l’infrastructure
6.4. Documentation et retour d’expérience
Chaque changement significatif ou incident doit donner lieu à :
- Une mise à jour des documents d’analyse
- Un retour d’expérience documenté (post-mortem)
- Une amélioration des procédures (techniques, humaines, organisationnelles)
6.5. Vers une sécurité durable
La sécurité ne peut être garantie de façon absolue, mais une démarche d’amélioration continue permet de :
- Réduire l’impact des attaques potentielles
- Renforcer la résilience de l’infrastructure
- Maintenir un niveau de sécurité cohérent dans le temps