Le durcissement n’est pas une option technique mais un choix d’ingénierie. Sébastien Viou, Field Cybersecurity Strategist chez Fortinet, rappelle que la résilience des infrastructures critiques ne se décrète pas au moment de l’incident : elle se construit dès la conception, par la réduction de la surface d’attaque et la discipline opérationnelle.
Les systèmes numériques sont partout ; ils pilotent nos déplacements, soutiennent les chaînes de soins, orchestrent les flux financiers. La plupart du temps, tout fonctionne de manière invisible, fluide, presque évidente. C’est précisément cette apparente normalité qui fait oublier une réalité essentielle : lorsque ces infrastructures critiques sont attaquées ou défaillantes, les conséquences dépassent largement le cadre informatique.
Anticiper la fragilité dès la conception
Dans les incidents majeurs observés ces dernières années, la cause n’est que rarement une attaque extraordinairement sophistiquée. Bien plus souvent, elle tient à une surface d’attaque trop large, laissée ouverte par habitude, par confort ou par héritage technique. C’est ici qu’intervient le durcissement, un concept fondamental pour bâtir des systèmes capables d’encaisser les chocs.
La résilience ne se joue pas uniquement au moment de la détection ou de la réponse à incident, c’est presque trop tard. Elle se construit en amont, dès la conception. Un système fragile est un système contraint par ses défauts : dépendances non maîtrisées, configurations par défaut, empilements techniques mal compris. À l’inverse, un système durci offre une forme de maîtrise opérationnelle : la capacité à décider, à prioriser et à continuer à fonctionner même en situation dégradée.
Le durcissement : une stratégie du strict minimum
Le durcissement consiste à retirer plutôt qu’à ajouter. Retirer des composants superflus, des privilèges excessifs, des accès implicites, des hypothèses de confiance non justifiées. L’objectif n’est pas de rendre un système parfait, mais de le rendre robuste. Un système durci n’est pas inviolable, mais il est conçu pour limiter l’impact d’une attaque et continuer à remplir ses fonctions essentielles.
Côté développement, la règle est simple : n’exposer que le strict nécessaire. Chaque bibliothèque ajoutée « au cas où », chaque fonctionnalité activée par défaut, élargit la surface d’attaque. Supprimer les composants inutiles n’est pas une optimisation cosmétique ; c’est une mesure de sécurité directe. Moins de code, c’est moins de comportements imprévus et moins de vulnérabilités exploitables, et au passage de meilleures performances.
Étanchéité des flux et maîtrise des secrets
Le principe du moindre privilège est tout aussi structurant. Une application n’a aucune raison de disposer de droits étendus par défaut. Lorsqu’un composant est compromis, l’attaquant n’obtient que ce qui est explicitement autorisé. Dans les systèmes critiques qui manipulent des flux sensibles ou pilotent des processus réels, ce choix d’architecture est déterminant.
La validation des entrées reste un fondamental intemporel. Injections, formats mal contrôlés, désérialisations dangereuses : ces exploitations persistent parce qu’elles continuent de fonctionner. Et leurs effets peuvent être disproportionnés lorsque les systèmes concernés interagissent avec le monde réel.
La gestion des secrets mérite la même rigueur. Clés API, certificats, identités machines doivent être protégés, chiffrés et isolés. Les stocker en clair ou les disséminer dans le code, voire sur le dépôt Cloud, revient à fragiliser durablement l’ensemble du système. Les mécanismes matériels de protection, comme les TPM ou HSM, ne sont plus réservés aux environnements d’exception.
La résilience comme objectif d’ingénierie
Une fois l’application conçue et en production, sa configuration devient critique. Tout ce qui n’est pas indispensable doit être désactivé : services inutiles, ports ouverts par défaut, comptes génériques. L’administration doit être isolée, contrôlée et tracée. Accès bastionnés, authentification forte, segmentation réseau et journalisation sont autant de garde-fous indispensables pour éviter qu’un accès légitime ne devienne un point d’entrée critique.
Enfin, la résilience n’est pas un état figé mais un entretien permanent : supervision continue, journaux exploitables, mises à jour maîtrisées, sauvegardes régulièrement testées. Sans ces pratiques, la résilience s’érode avec le temps.
En définitive, le durcissement est ce qui distingue un système qui fonctionne d’un système qui résiste. Il conditionne la continuité d’activité, la crédibilité numérique et la capacité d’une organisation à rester maîtresse de son environnement technique. La sécurité n’est pas un vernis que l’on applique après coup. C’est une discipline d’ingénierie. Et comme toute discipline, elle commence par de bonnes habitudes.
