Les erreurs fréquentes dans l’exploitation quotidienne des systèmes

Les exceptions qui deviennent la règle

Les politiques de sécurité prévoient des mécanismes d'exception — pour permettre des dérogations temporaires dans des situations justifiées. Dans la pratique, ces exceptions ont tendance à se pérenniser. Une règle de pare-feu ouverte temporairement pour permettre un dépannage urgent n'est jamais refermée. Un accès d'administration accordé pour une intervention ponctuelle reste actif indéfiniment. Une politique de mot de passe assouplie pendant une migration n'est jamais rétablie. Ces exceptions oubliées s'accumulent et constituent une dérive progressive de la posture sécuritaire. La gestion rigoureuse des exceptions — avec une date d'expiration et un processus de renouvellement conscient — est une pratique essentielle d'exploitation sécurisée.

La gestion des changements sans validation de sécurité

Les processus de gestion des changements (change management) sont bien établis dans les environnements d'exploitation matures. Ce qui l'est moins, c'est l'intégration systématique d'une revue de sécurité dans ce processus. Chaque changement — mise à jour d'un composant, modification d'une règle réseau, ajout d'un service, évolution d'une configuration — peut introduire des vulnérabilités involontaires. Un changement qui améliore les performances peut simultanément affaiblir les contrôles d'accès. Une mise à jour corrective peut introduire une régression dans la configuration sécurisée. La revue de sécurité des changements, intégrée dans le processus CAB (Change Advisory Board), est le mécanisme qui permet de détecter ces effets de bord avant la mise en production.

Les backups non testés : une fausse assurance

Maintenir des backups réguliers est une pratique d'exploitation fondamentale. Mais un backup dont la restauration n'a jamais été testée est une assurance non vérifiée — elle peut ne fonctionner que sur le papier. Les tests de restauration révèlent régulièrement des surprises : des backups incomplets car certains volumes n'étaient pas inclus, des temps de restauration très supérieurs aux estimations, des sauvegardes corrompues non détectées. Les exercices réguliers de restauration — documentés, mesurés et intégrés dans les processus d'exploitation — sont la seule façon de valider que le dispositif de backup produit effectivement la résilience annoncée.

La surveillance sans escalade : un non-sens opérationnel

Les équipes d'exploitation déploient des outils de surveillance et de collecte de logs qui génèrent des volumes considérables d'événements. Sans processus d'escalade formalisé — définissant quels types d'alertes doivent être transmis à qui, dans quels délais et avec quelles actions attendues — cette surveillance reste sans effet sur la détection des incidents réels. Les alertes de sécurité noyées dans des milliers d'alertes opérationnelles non hiérarchisées ne seront pas traitées à temps. La qualité d'une surveillance se mesure à la qualité des alertes générées et à la rapidité des réponses apportées, pas au volume des logs collectés.

La gestion de la dette technique d'exploitation

Les environnements d'exploitation accumulent une dette technique : des systèmes non mis à jour, des configurations héritées non revisitées, des processus manuels jamais automatisés. Cette dette a une dimension sécuritaire directe : les systèmes non patchés exposent des vulnérabilités connues, les configurations héritées incluent souvent des exceptions oubliées, les processus manuels introduisent des variations imprévisibles. La gestion de cette dette d'exploitation sécurisée suppose un inventaire régulier des items de dette existants, leur priorisation selon leur impact sécuritaire et un plan de remédiation intégré dans le backlog opérationnel.