Le 27 mai, un service interne s'est retrouvé exposé sur Internet, à l'écoute de toutes les adresses au lieu de la seule machine locale. Une clé d'API a été consommée pour environ 250 dollars avant qu'on s'en aperçoive. L'incident a été corrigé et consigné dans la mémoire de l'agent d'exploitation : date, cause, impact, correctif. Une note irréprochable.
Le 3 août, deux autres services étaient exposés exactement de la même façon : le coffre de mots de passe et un serveur de fichiers, activement scanné.
La mémoire avait retenu le cas, pas la règle
Une note se relit quand on pense à la chercher. Un contrôle s'exécute même quand on n'y pense pas. C'est toute la différence entre une organisation qui documente ses erreurs et une organisation qui cesse de les refaire.
Le même jour, une autre découverte
En auditant cette mémoire, un second problème est apparu. Un script planifié, que personne n'avait documenté, y ajoutait chaque nuit une déclaration « tout va bien », sans rien avoir mesuré. 51 blocs identiques occupaient plus de la moitié de la mémoire long terme de l'agent, celle qu'il relit à chaque démarrage.
Une tâche qui écrit « tout va bien » sans avoir rien vérifié est pire que pas de tâche du tout : elle fabrique une fausse assurance.
La règle adoptée
Chaque incident vécu engendre un contrôle quotidien :
- service exposé → liste de tous les ports ouverts, alerte sur tout nouveau ;
- service arrêté sept semaines sans alerte → vérifier que chaque service attendu tourne ;
- disque saturé par des caches → seuil d'espace et volume des caches ;
- mémoire gonflée en silence → taille de la mémoire comparée à un plafond ;
- test de sécurité lancé depuis la machine testée → toujours valider depuis un réseau tiers.
Chez vous
La question à poser après chaque incident, humain ou machine, n'est pas « avons-nous bien documenté ? » mais « qu'est-ce qui, désormais, le détectera sans nous ? ». Si la réponse est « quelqu'un qui relira la note », l'incident se reproduira.