La sécurité par défaut, en anglais secure by default, inverse la logique habituelle : au lieu de tout autoriser puis d'interdire au cas par cas, on refuse tout par défaut et on n'ouvre que ce qui est explicitement autorisé. Son corollaire, le fail-safe, veut qu'en cas d'erreur ou de panne le système se ferme et reste sûr, jamais il ne s'ouvre en grand. Cette page explique ce principe avec des images du quotidien, montre pourquoi il protège mieux, et déroule un cas concret. Aucun prérequis technique n'est nécessaire.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »Ce principe porte deux noms qui reviennent partout : le refus par défaut (en anglais deny by default) et le fail-safe (échouer en position sûre). Concrètement, vous saurez :
- Définir la sécurité par défaut et distinguer le refus par défaut du fail-safe, avec un exemple simple pour chacun.
- Comprendre pourquoi une liste blanche (tout interdit sauf exceptions) protège mieux qu'une liste noire (tout permis sauf interdictions).
- Reconnaître les endroits où appliquer ce réflexe : pare-feu, permissions, valeurs de configuration livrées d'origine.
- Repérer le piège le plus courant, une configuration par défaut trop permissive livrée par un produit.
- Relier ce principe au moindre privilège, à la minimisation et au modèle de menaces SOCLE, qui traduisent cette idée en contrôles concrets.
Qu'est-ce que la sécurité par défaut
Section intitulée « Qu'est-ce que la sécurité par défaut »La sécurité par défaut est un principe de conception qui dit ceci : quand un système ne sait pas s'il doit autoriser ou refuser une action, il refuse. Rien n'est ouvert tant qu'une règle explicite ne l'autorise pas. C'est l'inverse du réflexe naturel, qui consiste à tout laisser passer puis à bricoler des interdictions au fur et à mesure des problèmes.
L'analogie la plus parlante est celle d'une porte verrouillée par défaut. Imaginez un immeuble sécurisé : la porte d'entrée est fermée en permanence, et seules les personnes munies d'un badge valide peuvent entrer. On ne dresse pas la liste des gens à qui on interdit l'accès, ce serait sans fin. On dresse la liste courte des gens autorisés, et tout le reste est refusé sans discussion. Cette liste des autorisés porte un nom, la liste blanche (en anglais allowlist) : elle énumère ce qui est permis, et tout ce qui n'y figure pas est bloqué.
Le principe a un deuxième volet, tout aussi important, le fail-safe (littéralement « échouer en sécurité »). Il répond à une question dérangeante : que se passe-t-il quand le système tombe en panne ou rencontre une erreur ? Un système bien conçu se ferme dans ce cas, il ne s'ouvre pas. Reprenez l'immeuble : si le lecteur de badge tombe en panne, la porte doit rester verrouillée, pas se déverrouiller pour laisser tout le monde passer. Une panne ne doit jamais devenir une porte d'entrée pour un attaquant.
Ces deux idées se complètent. Le refus par défaut définit la règle en temps normal, tout est fermé sauf exception. Le fail-safe définit le comportement en cas d'incident, on reste fermé plutôt que de s'ouvrir. Ensemble, elles garantissent que l'état le plus sûr est aussi l'état par défaut, celui qu'on obtient sans rien faire.
Pourquoi inverser la logique
Section intitulée « Pourquoi inverser la logique »Pour saisir l'intérêt du refus par défaut, il faut comparer les deux façons de contrôler un accès. La liste noire (en anglais blocklist) part du principe que tout est permis, et on ajoute des interdictions au coup par coup : on bloque telle adresse, tel programme, tel comportement connu comme dangereux. La liste blanche part du principe inverse, tout est interdit, et on ajoute uniquement les autorisations dont on a réellement besoin.
La différence a l'air anodine, elle est décisive. Avec une liste noire, vous devez connaître à l'avance toutes les menaces pour les bloquer. Or les menaces évoluent chaque jour : un nouvel outil d'attaque, une nouvelle adresse, une technique inédite passeront tant qu'ils ne figurent pas encore sur la liste. Vous courez perpétuellement derrière les attaquants, et le moindre oubli laisse une porte ouverte.
Avec une liste blanche, la logique s'inverse en votre faveur. Vous n'avez à connaître que ce que vous voulez autoriser, ce qui est un ensemble petit et connu. Tout le reste, y compris les menaces que personne n'a encore imaginées, est bloqué d'office. Une nouvelle attaque n'a pas besoin d'être identifiée pour être arrêtée : elle ne figure tout simplement pas dans les autorisations.
C'est pour cela qu'on dit que la liste blanche est plus sûre. Elle transforme l'inconnu en refus, alors que la liste noire transforme l'inconnu en autorisation. Le prix à payer est un peu de travail au départ, il faut réfléchir à ce qu'on autorise vraiment. Mais ce travail se fait une fois, tandis que la liste noire demande une vigilance sans fin.
Comment l'appliquer
Section intitulée « Comment l'appliquer »La sécurité par défaut n'est pas une théorie abstraite, elle se décline en quelques réflexes concrets qu'on retrouve partout. Les voici, chacun accompagné de sa définition.
Le premier réflexe concerne le pare-feu, ce filtre qui décide quelles connexions réseau entrent et sortent d'une machine. Un pare-feu bien configuré fonctionne en deny by default : par défaut, il bloque tout le trafic, et l'administrateur ouvre ensuite uniquement les ports strictement nécessaires, par exemple le port du site web public. Ainsi, un service oublié ou installé par erreur reste injoignable de l'extérieur, il n'est pas exposé par accident.
Le deuxième réflexe concerne les permissions minimales, l'idée de n'accorder à chaque personne ou programme que les droits dont il a besoin, et rien de plus. Un compte utilisateur ne devrait pas pouvoir modifier les fichiers système s'il n'en a pas l'usage. On part de zéro droit et on ajoute au besoin, jamais l'inverse. Ce réflexe est le coeur du principe de moindre privilège, une page entière lui est consacrée.
Le troisième réflexe concerne les configurations sûres d'origine. Un logiciel ou un service devrait être livré déjà verrouillé, avec les options dangereuses désactivées par défaut. Le chiffrement des échanges activé, les comptes de test supprimés, les accès à distance fermés : c'est au produit d'être sûr dès l'installation, pas à l'utilisateur de le sécuriser après coup en connaissant tous les pièges.
Le quatrième réflexe concerne les valeurs par défaut sécurisées, un cas particulier du précédent. Chaque option de configuration a une valeur choisie quand on ne précise rien. Cette valeur doit toujours pencher du côté le plus prudent : un mot de passe obligatoire plutôt qu'optionnel, une durée de session courte plutôt qu'illimitée, un accès privé plutôt que public. La personne pressée qui accepte tous les réglages par défaut doit se retrouver, sans effort, dans une configuration sûre.
Ces quatre réflexes partagent la même colonne vertébrale : on réduit ce qui est ouvert au strict nécessaire. C'est exactement l'esprit de la minimisation, qui consiste à supprimer tout ce qui n'est pas indispensable pour offrir moins de prises à un attaquant.
Un scénario concret
Section intitulée « Un scénario concret »Prenons une petite équipe qui met en ligne une application web avec une base de données, un besoin banal pour n'importe quel service. Deux façons de faire vont donner deux niveaux de sécurité très différents.
Dans la première équipe, on procède « au plus simple ». Le pare-feu du serveur est ouvert par défaut, on ferme les ports gênants au fur et à mesure qu'on y pense. La base de données est installée avec ses réglages d'origine permissifs, dont un compte administrateur sans mot de passe, parce que « on le changera plus tard ». Les droits des comptes sont larges, tout le monde peut tout faire, pour éviter les blocages pendant le développement. Le résultat est une liste noire géante et incomplète : chaque port qu'on a oublié de fermer, chaque droit qu'on a laissé trop large est une entrée potentielle. Un attaquant scanne le serveur, trouve la base de données exposée avec son compte sans mot de passe, et récupère toutes les données.
Dans la seconde équipe, on applique la sécurité par défaut. Le pare-feu est en deny by default, seul le port du site public est ouvert, la base de données n'est joignable que localement. La base est configurée avec un mot de passe fort obligatoire dès l'installation, et chaque compte ne reçoit que les droits nécessaires à sa tâche. Le même attaquant scanne le serveur : il ne voit que le site web, la base est invisible de l'extérieur, et même s'il finissait par l'atteindre, aucun compte n'est laissé ouvert. La différence ne tient pas à un pare-feu plus cher, elle tient au choix de départ : refuser d'abord, ouvrir ensuite ce qui est justifié.
Ajoutons le volet fail-safe. Imaginez que le service qui vérifie les identités des utilisateurs tombe en panne. Dans un système bien conçu, cette panne bloque les connexions au lieu de laisser tout le monde entrer sans vérification. L'application devient momentanément indisponible, ce qui est gênant, mais elle ne s'ouvre pas à n'importe qui, ce qui serait catastrophique. Une panne coûte du temps, une ouverture accidentelle coûte une fuite de données.
Pièges courants
Section intitulée « Pièges courants »La sécurité par défaut est simple à énoncer, mais quelques erreurs reviennent sans cesse. Les connaître évite de croire son système protégé alors qu'il ne l'est pas.
Le piège le plus fréquent est la configuration par défaut permissive livrée par un produit. Beaucoup de logiciels sortent d'usine avec des réglages pensés pour « marcher tout de suite » plutôt que pour être sûrs : compte administrateur connu de tous, mot de passe standard identique partout, interface d'administration exposée sur le réseau. La personne qui installe sans rien changer hérite de tous ces trous. Le réflexe est de passer en revue la configuration livrée et de la durcir avant toute mise en production, jamais de faire confiance aux valeurs d'usine.
Le deuxième piège est de confondre discret et sécurisé. Cacher un service sur un port inhabituel ou ne pas en parler ne le protège pas, un scan automatique le trouvera. La discrétion n'est pas du refus par défaut : seule une règle qui bloque réellement l'accès compte, pas le fait de croiser les doigts pour que personne ne cherche.
Le troisième piège est le fail-open par mégarde, l'inverse du fail-safe. Certains systèmes, quand un contrôle de sécurité échoue, choisissent de laisser passer pour ne pas gêner l'utilisateur. Un antivirus qui plante et laisse tout s'exécuter, une vérification d'identité qui, en cas de doute, accorde l'accès : ce sont des portes grandes ouvertes déguisées en confort. Vérifiez toujours ce que fait un système quand il échoue, pas seulement quand tout va bien.
Le dernier piège est d'élargir les autorisations pour débloquer un problème, sans jamais les resserrer ensuite. « Ça ne marche pas, ouvrons tout, on affinera plus tard » : le « plus tard » n'arrive jamais, et la liste blanche se transforme peu à peu en liste noire par accumulation. Chaque autorisation ajoutée dans l'urgence doit être revue et justifiée, ou retirée.
À retenir
Section intitulée « À retenir »-
Refuser par défaut : tout est bloqué tant qu'une règle explicite ne l'autorise pas, l'inverse du réflexe « tout ouvrir puis interdire ».
-
Fail-safe : en cas d'erreur ou de panne, le système se ferme et reste sûr, il ne s'ouvre jamais en grand.
-
Liste blanche plutôt que liste noire : lister ce qu'on autorise, court et connu, protège mieux que lister ce qu'on interdit, infini et incomplet.
-
L'inconnu devient un refus : une menace jamais vue est bloquée d'office, car elle ne figure pas dans les autorisations.
-
Des réflexes concrets : pare-feu en deny by default, permissions minimales, configurations sûres d'origine et valeurs par défaut prudentes.
-
Le produit doit être sûr d'usine : passez toujours en revue la configuration livrée, ne faites jamais confiance aux réglages permissifs par défaut.
-
Reliez le principe aux menaces réelles : le modèle de menaces SOCLE montre, domaine par domaine, quelles attaques un refus par défaut arrête et quels contrôles le mettent en oeuvre.