Introduction :
Cette formule est omniprésente dans les discours sur la sécurité des systèmes d’information.
On la retrouve dans les formations, les documentations et les recommandations opérationnelles, en particulier lorsqu’il s’agit de filtrage réseau et de configuration des pare-feu.
Elle exprime une intention légitime : réduire la surface d’exposition en limitant strictement ce qui est accessible.
Employée comme cadre méthodologique, elle a du sens. Mais sa portée réelle est fréquemment surestimée.
Car derrière l’énoncé, l’implicite est trompeur.
La formule suggère qu’un système rigoureusement configuré pourrait atteindre une forme de sûreté complète.
Qu’en fermant tout ce qui n’est pas explicitement ouvert, on contrôlerait intégralement son comportement.
Dans un univers idéal, où les logiciels seraient exempts de défauts, ce raisonnement tiendrait.
Mais cet univers n’existe pas.
L’illusion du contrôle total :
Tout ce qui n’est pas autorisé est interdit est une maxime familière des architectes réseau et des administrateurs en charge des pare-feu.
Et son usage est justifié.
Elle définit une posture défensive essentielle : le deny by default.
Mais une posture n’est pas une garantie.
Un pare-feu ne gouverne pas un système.
Il applique des règles sur des flux connus : ports, protocoles, adresses, états de session.
Il opère à une couche donnée, avec une vision nécessairement partielle.
Or, un système informatique moderne dépasse largement ce périmètre.
La complexité comme générateur d’incertitude :
Plus un logiciel est volumineux, plus la probabilité d’erreurs augmente.
C’est un fait statistique, confirmé par l’expérience.
Ni les tests unitaires, ni les revues de code, ni les méthodes formelles, ni l’intégration continue n’ont jamais permis d’éradiquer totalement les bugs.
Et le code applicatif n’est qu’un étage.
Le compilateur peut produire ses propres anomalies.
Les bibliothèques tierces introduisent des comportements non anticipés.
Le système d’exploitation est un empilement de couches historiques, ajustées, corrigées, parfois contournées.
Plus bas encore, le matériel lui-même n’est pas exempt de défauts, comme l’ont illustré Spectre, Meltdown, Rowhammer et d’autres.
Chaque couche ajoutée élargit l’espace des états possibles.
Et avec lui, l’étendue de ce qui échappe à la connaissance.
L’échelle de complexité d’une puce informatique est démesurée.
Un schéma pour illustrer cela :
L’axe vertical n’est pas une simple montée en “difficulté”.
Bas : complexité d’échelle → Beaucoup de combinaisons, mais un système clos, bien défini. Les règles sont fixes. L’espace est immense mais stable.
Haut : complexité systémique → Le problème change de nature. Interactions croisées, contraintes contradictoires, effets émergents. Le système réagit à la solution qu’on tente d’imposer.
Le passage du jeu formel au placement des cellules d’une puce marque un changement d’échelle mais surtout un changement de nature du problème. Là où les échecs ou le Go évoluent dans des espaces immenses mais clos, le placement de cellules sur une puce affronte un espace de recherche astronomique, dépassant 10^90000 configurations possibles, façonné par des contraintes physiques, temporelles et technologiques interdépendantes; longueur des fils,timing,consommation,bruit,densité,routabilité,dissipation thermique, etc. Cette explosion combinatoire n’est pas seulement quantitative : chaque décision locale modifie l’équilibre global du système, rendant toute exploration exhaustive irréaliste et toute notion de solution optimale absolue inapplicable. On ne cherche plus une réponse correcte, mais un compromis acceptable dans un espace continuellement déformé par la réalité matérielle de la puce.
Sans compter les effets quantiques qui peuvent survenir à ces echelles ( entre 45 et 50 nano-mètres)
Nous ne manquons donc pas, d’incertitude dans un système informatique !
Remarque: Dans le futur, peut-être que l’IA nous aidera à placer de manière optimale les composants d’une puce … Mieux que ce que nous pourrions faire.
Le domaine du connu et le domaine de l’inconnu :
C’est ici qu’une confusion persistante apparaît : celle entre sécurité et sûreté.
La sécurité s’inscrit dans le domaine du connu.
Elle traite des scénarios identifiés, modélisables, vérifiables.
- Un disque tombe en panne → mise en place d’un RAID.
- Une alimentation défaillante → redondance.
Ces événements sont prévisibles, quantifiables, intégrables dans des modèles de risque.
La sécurité relève de l’ingénierie et de la probabilité.
La sûreté commence là où cette logique atteint ses limites.
La sûreté : gérer ce qui n’a pas été anticipé :
La sûreté concerne l’imprévu.
Ce qui n’a pas été testé.
Ce qui n’a pas encore été découvert.
- Une vulnérabilité latente depuis des années.
- Une interaction inattendue entre composants pourtant conformes.
- Un comportement émergent issu d’une combinaison d’états jugée impossible.
Aucun acteur sérieux ne peut affirmer qu’un système complexe a été exhaustivement éprouvé.
Aucune garantie n’existe quant à l’absence de vulnérabilités inconnues.
Dans ce champ, il n’y a pas de règles absolues.
Seulement des principes : limitation d’impact, confinement, résilience.
Pourquoi le « tout interdire par défaut » est insuffisant :
Affirmer tout ce qui n’est pas autorisé est interdit revient à supposer que :
- ce qui est autorisé est nécessairement maîtrisé,
- et que tout comportement dangereux emprunte un chemin non autorisé.
Ces hypothèses ne tiennent pas face au réel.
Les vulnérabilités exploitables utilisent presque toujours des voies légitimes :
- un port ouvert,
- un service attendu,
- une fonctionnalité prévue,
- un flux conforme.
Le problème n’est pas l’ouverture.
Le problème est ce que l’on ignore de ce qui circule à travers cette ouverture.
Vers une approche plus lucide : la cybersûreté :
Le terme cybersécurité est devenu un mot-valise.
Il rassure, il simplifie, il donne l’illusion d’un périmètre pleinement maîtrisable.
Il masque pourtant une réalité plus inconfortable :
les systèmes informatiques relèvent autant de la sûreté que de la sécurité.
Et il est bien plus sage de parler de cybersûreté.
Parler de cybersûreté n’est pas un exercice de pessimisme.
C’est reconnaître que :
- tout système exposé est activement exploré,
- toute surface d’attaque est vivante et évolutive,
- toute protection est, par nature, temporaire.
- et que au grand dame de certains, la question n’est pas de savoir si ils vont rentrer mais quand ils vont rentrer. Oui, ils rentrent. Tôt ou tard. Le combat est sans fin.
La défense ne consiste pas uniquement à empêcher.
Elle implique aussi d’observer, de comprendre, de détecter, de réagir et surtout d’apprendre.
En somme. La sécurité protège. La sûreté comprend, surveille et gouverne.
Conclusion :
Tout ce qui n’est pas autorisé est interdit demeure un point de départ pertinent.
Mais ce ne sera jamais une finalité. Loin de là.
La maturité consiste moins à croire que toutes les portes sont closes qu’à comprendre ce qui se produit lorsqu’une porte cède, ou lorsqu’un contournement exploite une faiblesse ignorée.
Et surtout, à accepter qu’il existe toujours une faille que l’on n’avait pas identifiée.
Dans ce contexte, et pour des raisons que je développerai dans un autre article dédié,
le recours à l’open source, face aux modèles closed source, constitue une barrière supplémentaire en matière de sûreté informatique.
Non comme une promesse absolue, mais comme un levier de transparence, d’auditabilité et de compréhension du comportement logiciel face à l’inconnu.
À mes yeux, l’une des défenses les plus rationnelles dont nous disposons, est bien l’Open Source et toute la philosophie qui en découle.