Éditorial

Dossier d'enquête sur la métaphore du château fort et ses effets sur la conception des architectures de sécurité périmétrique modernes.

~10 min de lecture7 sections

Pourquoi le château fort biaise la sécurité réseau

La métaphore du château fort a rendu la sécurité périmétrique intuitive, puis dangereusement commode : un mur, une porte, un dehors hostile et un dedans réputé fiable. Les réseaux modernes n’ont ni frontière unique ni intérieur homogène. Continuer à les concevoir ainsi transforme chaque compromission interne en permis de circulation.

→ Lire l’explication complète de la marmotte

La frontière binaire n’existe pas sur un réseau moderne

Le modèle périmétrique suppose qu’une adresse réseau interne constitue un indice de confiance. Cette hypothèse était déjà fragile avec les réseaux privés virtuels, les postes nomades et les interconnexions partenaires. Elle devient fausse avec le cloud, les conteneurs, les interfaces de programmation applicative exposées, les outils de support distants et les identités fédérées.

Une même application peut recevoir des flux depuis Internet, un réseau privé, un cluster d’orchestration et un service géré externe. Son adresse source ne décrit ni l’identité du demandeur, ni son niveau d’autorisation, ni la sensibilité de l’action demandée. Une adresse interne prouve seulement qu’un paquet a atteint un segment interne. Ce n’est pas un certificat de moralité délivré par le câble Ethernet.

Le compromis central est net : la sécurité périmétrique réduit le coût opérationnel en concentrant le filtrage à quelques points, mais elle paie cette économie par une confiance implicite dans les flux qui ont franchi la frontière. Cette confiance facilite le déplacement latéral après compromission. La recommandation est donc de conserver le périmètre comme couche de réduction d’exposition, jamais comme décision d’autorisation.

Le pare-feu périmétrique reste utile pour bloquer les services non publiés, imposer des points d’entrée contrôlés et limiter les flux sortants. Il ne démontre pas qu’un appel autorisé provient du bon processus, qu’il porte une identité non volée ou qu’il respecte le moindre privilège. Confondre filtrage réseau et contrôle d’accès revient à demander à une barrière de parking de vérifier un contrat de travail.

Cette distinction compte particulièrement pour les services d’administration. Une console accessible uniquement depuis un réseau dit d’administration reste vulnérable si un poste de ce réseau est compromis, si un tunnel distant est détourné ou si une règle autorise un rebond depuis un bastion partagé. La séparation entre administration et usages courants doit être imposée par des identités distinctes, une authentification forte et des politiques de flux dédiées. Les bases sont détaillées dans les fondations d’architecture cyber.

Du périmètre réseau à la décision par flux et identité

Une architecture moderne doit évaluer chaque flux selon quatre propriétés : l’identité du demandeur, l’identité de la charge de travail appelée, le contexte d’accès et l’action demandée. L’adresse IP (Internet Protocol) peut contribuer au contexte, mais elle ne doit pas porter seule la décision.

Le modèle Zero Trust, ou confiance zéro, est souvent réduit à un produit d’accès distant rebaptisé. La version qui tient en production impose plutôt une vérification explicite avant l’accès à une ressource, une autorisation limitée à l’action nécessaire et une hypothèse de compromission pour les segments voisins. Le terme est à la mode, donc les slides lui ont déjà fait subir des choses répréhensibles. Le mécanisme, lui, reste banal : ne pas accorder de privilège parce qu’un paquet vient du bon couloir.

Pour les utilisateurs, l’identité vient généralement d’un fournisseur d’identité, avec authentification multifacteur et attributs d’autorisation. Pour les charges de travail, elle doit provenir d’un mécanisme non réutilisable par copie d’image : certificat à durée limitée, jeton signé avec audience restreinte, ou identité native de plateforme. Un secret statique injecté dans chaque conteneur n’est pas une identité de charge de travail, c’est une clé passe-partout avec une date d’expiration décorative.

Le chiffrement Transport Layer Security, ou TLS, doit authentifier le serveur et, pour les flux sensibles entre services, le client également. L’authentification mutuelle TLS, ou mTLS, réduit l’usurpation réseau mais ne remplace pas l’autorisation applicative : deux services authentifiés peuvent ne pas avoir le droit d’invoquer la même opération. Le contrôle doit donc vérifier l’identité, l’audience du jeton, la méthode demandée et les attributs métier avant d’exécuter une action.

La segmentation doit suivre les dépendances réelles, pas l’organigramme ni le plan d’adressage historique. Isoler « production » de « bureautique » est nécessaire, mais insuffisant. Il faut également distinguer le frontal du service métier, le service métier de la base de données, les flux de déploiement des flux applicatifs et l’administration des deux. Une règle trop large entre deux zones crée une zone unique avec une étiquette différente.

Exemple reproductible : constater l’échec du dedans fiable

Le scénario suivant utilise deux espaces de noms réseau Linux. Le premier représente un poste interne compromis, le second un service d’administration. Sans contrôle d’identité applicatif, le service accepte toute connexion provenant du segment autorisé.

# Prérequis : Linux, iproute2, curl et privilèges root.
# Créer deux hôtes réseau isolés reliés par une paire veth.
ip netns add poste-interne
ip netns add administration
ip link add veth-interne type veth peer name veth-admin
ip link set veth-interne netns poste-interne
ip link set veth-admin netns administration

# Adresser et démarrer les interfaces.
ip netns exec poste-interne ip addr add 10.42.0.10/24 dev veth-interne
ip netns exec administration ip addr add 10.42.0.20/24 dev veth-admin
ip netns exec poste-interne ip link set lo up
ip netns exec poste-interne ip link set veth-interne up
ip netns exec administration ip link set lo up
ip netns exec administration ip link set veth-admin up

# Exposer un service de test sur la zone d'administration.
ip netns exec administration python3 -m http.server 8443 --bind 10.42.0.20 &

# Depuis le poste interne, l'accès fonctionne sans identité ni autorisation.
ip netns exec poste-interne curl http://10.42.0.20:8443/

# Nettoyer les espaces de noms après le test.
ip netns del poste-interne
ip netns del administration

Le pare-feu peut bloquer les sources externes et laisser passer 10.42.0.0/24. Il ne distingue pas le poste légitime du poste compromis dans ce sous-réseau. Pour corriger le modèle, il faut d’abord restreindre le flux au service exact, puis exiger une authentification du client et appliquer une autorisation applicative. Chacune de ces couches couvre une défaillance différente.

Dans Kubernetes, la même erreur prend la forme d’une NetworkPolicy autorisant tout le trafic d’un espace de noms vers un autre. Cette règle limite un peu le blast radius, mais elle ne protège pas contre un conteneur compromis dans l’espace autorisé. Une politique réseau doit être complétée par une identité de charge de travail, des certificats ou jetons courts, et une autorisation côté serveur. Les sujets de réseau et d’interconnexion restent à traiter comme des contrôles d’exposition, pas comme une preuve de confiance : voir les ressources réseau.

Surface d’attaque et garanties absentes du modèle périmétrique

Le principal effet du château fort est le déplacement latéral. Après compromission d’un poste, d’une machine virtuelle ou d’un conteneur, un attaquant énumère les services accessibles, réutilise les informations d’authentification disponibles et cherche les interfaces d’administration insuffisamment séparées. Les protocoles qui propagent ou réutilisent des secrets aggravent immédiatement le problème. Le fonctionnement et le durcissement de ce cas sont documentés dans l’analyse de NTLM.

Le modèle ne garantit pas non plus la confidentialité des flux internes. Le trafic latéral non chiffré peut être intercepté depuis un équipement compromis, un port de supervision mal isolé ou une erreur de configuration. TLS chiffre le transport, mais ne masque pas nécessairement les métadonnées : noms de services, horaires, volumes et destinations restent exploitables selon le protocole.

La microsegmentation n’est pas une garantie contre une identité compromise. Si un compte de déploiement possède le droit de modifier les politiques réseau et les secrets, une séparation parfaite sur le papier devient une porte dérobée administrée. Les rôles doivent être séparés : exploitation du plan de données, administration des identités, déploiement applicatif et gestion des politiques. Le contrôle d’accès aux interfaces d’orchestration mérite le même niveau de protection que les données qu’elles exposent.

Enfin, aucun mécanisme réseau ne corrige une autorisation métier trop large. Autoriser un service de facturation à appeler une interface de paiement ne dit rien sur le droit de déclencher un remboursement donné. L’autorisation doit être portée par l’application ou une passerelle qui connaît la ressource et l’action. Le réseau ne voit que des paquets, ce qui est une vocation respectable mais assez limitée.

Exploitation : identités courtes, révocation et reprise

Le passage à des contrôles par identité augmente la charge d’exploitation. C’est le prix à payer, et il faut le payer explicitement plutôt que de le découvrir lors d’une panne de l’autorité de certification. Les certificats, clés privées, jetons de signature et secrets d’automatisation sont des actifs critiques. Leur cycle de vie doit être inventorié, renouvelé et supervisé.

Les identités de charge de travail doivent avoir une durée courte et un mécanisme de renouvellement avant expiration. Une rotation sans chevauchement casse les connexions persistantes si le client et le serveur ne reconnaissent pas simultanément l’ancienne et la nouvelle chaîne de confiance. Une rotation avec chevauchement trop long maintient une fenêtre d’abus. La durée dépend donc de la capacité de détection, de révocation et de redéploiement, pas d’un chiffre sorti d’une plaquette.

La révocation d’un certificat ne ferme pas automatiquement les sessions déjà établies. Un proxy peut conserver une connexion mutualisée, un client peut ne consulter l’état de révocation qu’à l’établissement, et un jeton signé reste valide jusqu’à son expiration sauf vérification en ligne. Pour les accès à fort impact, réduire la durée de vie des jetons et forcer une réauthentification périodique est plus prévisible qu’espérer une révocation instantanée.

La supervision doit corréler les refus d’authentification, les changements de politique, les élévations de privilèges, les émissions de certificats et les flux inhabituels entre zones. Les journaux sans identité stable sont peu exploitables : conserver seulement l’adresse source ramène exactement au biais initial. Les sauvegardes doivent inclure les autorités de certification, leurs clés protégées, les configurations de politiques et les procédures de restauration testées. Restaurer un service sans sa chaîne de confiance, c’est restaurer une porte sans serrure et annoncer que le bâtiment est disponible.

🐝 Ce qui arrive si on s’en passe

Sans abandon du modèle périmétrique, chaque compromission interne se transforme en permis de circulation. Dès qu’un attaquant franchit le mur unique, l’intérieur réputé fiable lui offre un déplacement libre : il atteint des serveurs, des partages et des services qui ne vérifient plus rien, puisque la confiance a été accordée d’avance à quiconque se trouve dedans. Les réseaux modernes n’ayant ni frontière unique ni intérieur homogène, ce dedans présumé sûr inclut en réalité des prestataires, des accès distants et des livraisons permanentes. La conséquence est que la détection et le cloisonnement manquent là où ils comptent le plus, à l’intérieur, et qu’une intrusion limitée devient une emprise générale faute de contrôle entre les zones. Surveiller seulement le portail revient à ignorer tout ce qui se passe une fois la porte franchie.

🦫 Explication de la marmotte 🍫

La sécurité périmétrique traditionnelle sépare le réseau entre une zone extérieure et une zone intérieure. Un filtre à l’entrée bloque certains échanges venant de l’extérieur et laisse davantage passer ceux qui viennent de l’intérieur. Le problème commence lorsqu’un ordinateur interne est infecté, qu’un compte est volé ou qu’un service extérieur obtient un accès autorisé : il se retrouve déjà du bon côté du filtre.

Une architecture plus récente traite chaque demande séparément. Avant d’accéder à un service, le demandeur doit prouver son identité. Le service vérifie aussi à qui il parle. Ensuite, une règle décide si cette identité peut effectuer l’action demandée sur cette ressource précise. Le fait d’être connecté au même réseau ne suffit plus.

Le filtrage réseau reste nécessaire pour réduire le nombre de services accessibles, mais il ne remplace pas ces vérifications. Si le filtrage échoue, l’identité et l’autorisation doivent encore bloquer l’action. Si une identité est volée, les droits limités et la courte durée des accès réduisent les dégâts.

Ce système dépend de clés, de certificats et de journaux. Ils doivent être renouvelés, surveillés et sauvegardés. Quand ils expirent ou que le service qui les délivre tombe, les accès peuvent échouer. Prévoir ce cas fait partie de la sécurité : un contrôle qui empêche aussi les services légitimes de fonctionner n’est pas une protection, c’est une panne avec une cravate.

Pages voisines

La citent

Pourquoi le château fort biaise la sécurité réseau

Elle cite

Pourquoi le château fort biaise la sécurité réseau

Pourquoi le château fort biaise la sécurité réseau

La frontière binaire n’existe pas sur un réseau moderne

Du périmètre réseau à la décision par flux et identité

Exemple reproductible : constater l’échec du dedans fiable

Surface d’attaque et garanties absentes du modèle périmétrique

Exploitation : identités courtes, révocation et reprise

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines