On a prévu de remplacer un pare-feu de génération précédente par un NGFW. L'intitulé du projet tient dans une phrase. Ce qu'on trouve en posant la pièce neuve ne tient pas dans la même.
Je raconte ici ce qu'on a vraiment appris, sans nommer l'organisation ni le fournisseur sortant, parce que ce n'est pas l'intéressant. L'intéressant, c'est le motif : chaque fois qu'on branche un contrôle moderne sur une infrastructure qui a vieilli à son rythme, le contrôle découvre ce que l'infrastructure n'avait jamais eu à montrer.
Un mot sur ma position dans l'histoire, parce qu'elle colore tout ce qui suit. Il s'agit de deux administrations distinctes qui coopèrent au quotidien mais dont les infrastructures informatiques sont restées complètement séparées : deux réseaux, deux annuaires, deux parcs — et à presque chaque étage, deux choix techniques différents. Pas les mêmes pare-feux, pas les mêmes switchs, pas les mêmes outils de supervision ; rien qui se parle sans qu'on écrive la colle.
Je n'ai pas conçu cet ensemble, et je ne suis pas la personne qui en tient la carte au quotidien. J'y interviens dans une position qui ressemble à celle d'un consultant — quelques jours par mois, pour qu'un projet comme celui-ci avance : on arrive de l'extérieur, on découvre à mesure, on documente ce qu'on comprend, on signale ce qui dépasse, et on repart. Dans ce type d'organisation, l'informatique se répartit entre une part internalisée et plusieurs contrats de sous-traitance distincts : chaque prestataire livre ce que son contrat demande, ni plus ni moins, et personne n'a par construction la mission d'assembler un regard transversal spontané sur l'ensemble. Une partie des surprises de ce chantier vient de là, et c'est utile de le poser avant de raconter la suite.
Dans ce format d'appui, on touche à tout — support utilisateur, spécifications, infrastructure, réseau, sécurité, parfois téléphonie. Ce sont, en théorie, autant de métiers distincts : chacun a sa pratique, son outillage, ses certifications, ses pièges connus, et dans une organisation un peu structurée chacun est tenu par quelqu'un qui ne fait que ça. Les regrouper dans la même semaine, pour la même personne, ne les rend pas interchangeables ; ça force seulement à les traiter en moins de profondeur que ce que chacun mériterait. On fait de son mieux, on priorise, on sait reconnaître ce qui dépasse — et on l'écrit noir sur blanc quand il faut remonter la main. Ce qui va suivre n'est donc pas un procès intenté à un cahier des charges qui aurait été mal préparé : c'est ce qu'on finit par voir quand on arrive de l'extérieur, qu'on branche une pièce neuve, et que toutes les questions auxquelles personne n'avait eu à répondre jusque-là tombent le même mois.
Le cahier des charges ment par omission
Côté papier, c'est simple. On remplace l'équipement périmétrique. On en profite pour sortir du SSL VPN au profit d'IPsec/IKEv2 — un geste de conformité qu'on peut rattacher à la trajectoire NIS2, et surtout un geste de bon sens : un tunnel pensé pour un navigateur n'est pas un tunnel pensé pour une flotte.
Côté réalité, IKEv2 demande trois choses que l'ancien montage n'exigeait pas vraiment : une identité à présenter, un endroit qui en atteste, un endroit qui l'évalue. L'ancien montage s'en passait parce que le portail web absorbait l'identité, délivrait la session, et personne n'allait voir derrière.
On va voir derrière. Pas de RADIUS exploitable. Pas d'annuaire d'identité moderne — ni Entra, ni équivalent — chaîné à l'authentification VPN. Pas de gestion centralisée des postes qui permettrait de distinguer un équipement de l'organisation d'un autre. Pas de PKI exploitable au point d'émettre et de révoquer des certificats machines sans y passer un trimestre.
Le pare-feu n'est pas le problème. Le pare-feu est la première pièce assez neuve pour avoir besoin des autres.
Le fournisseur, documenté factuellement
Je laisse de côté le ressenti et je m'en tiens à ce qui se vérifie. Le périmètre contractuel du support historique couvre l'équipement sortant, et pas l'interopérabilité avec le neuf. Les demandes sont tracées, les réponses aussi, les délais également. La reprise d'historique — ensembles de règles, exceptions, routes statiques — n'était pas incluse. Elle s'est faite en interne, à partir des exports qu'on a pu obtenir.
Ce n'est pas une anecdote, c'est une leçon de spécification : dans ce genre de projet, la « migration » n'est pas une tâche, c'est une colonne du devis — et si elle n'y est pas, elle sera faite par quelqu'un qui n'a pas été prévenu.
Le jour où on active l'inspection SSL
C'est là que les choses deviennent intéressantes.
On active l'inspection, pour les flux et les segments qui s'y prêtent, avec la liste d'exclusions qu'on sait devoir faire — paiement, services bancaires, télémétrie des postes, applications qui épinglent leur certificat. Et malgré ces précautions, des applications internes tombent, dont on ne connaissait pas la liste.
Un client lourd ancien qui ne sait pas valider une chaîne qu'il n'a pas apprise à l'installation. Un service hébergé il y a longtemps « temporairement » et qui parle en TLS 1.0 à une destination qu'aucun inventaire ne mentionne. Un équipement de production qui exfiltre une télémétrie vers un cloud dont personne au comité n'a entendu le nom. Deux imprimantes multifonctions qui synchronisent un carnet d'adresses contre un serveur sorti du support il y a cinq ans.
L'inspection n'est pas la fautive. L'inspection est le premier instrument qui demande au système d'information (SI) de se présenter, et le SI répond qu'il n'avait pas prévu la question.
À partir de là, chaque exception écrite pour « rétablir le service » est une dette. Pas une dette technique au sens habituel : une dette d'information. On ne sait pas ce qu'on a autorisé, et dans six mois on ne saura plus pourquoi.
Split, full, et l'utilisateur au milieu
L'autre point raide, c'est le passage du split tunneling au full tunneling en mode strict. Dans le modèle de menace qu'on s'est donné, c'est la direction qu'on a retenue : tant que le poste professionnel est connecté, ses communications repassent par les contrôles de l'organisation. Ça ne veut pas dire que le poste « est » dans le périmètre — il reste branché à un réseau local, il garde ses interfaces, et sa sécurité propre compte toujours autant. Mais au moins, ce qui doit être vu l'est.
Côté utilisateur, c'est un recul. L'impression locale cesse de fonctionner. L'accès au NAS familial aussi. Le fichier qu'on glissait sur le réseau local « parce que c'est plus simple » devient un détour. Pour la personne qui travaille, on a cassé quelque chose. Pour qui regarde la chaîne de confiance, on a comblé un trou qui n'avait jamais été fermé.
La vraie question n'est pas « split ou full ». La vraie question est : peut-on raisonnablement laisser un poste professionnel partager son routage avec un réseau dont l'organisation ne sait rien ? Posée comme ça, elle n'a plus la même tonalité.
Il faut quand même donner sa place au coût humain, parce qu'il décide du reste. Une politique de sécurité qu'on contourne par confort n'est plus une politique de sécurité : c'est un décor devant lequel les gens trouvent leur propre chemin. Je ne peux pas imprimer depuis le VPN, je coupe le VPN. Je ne peux pas déposer le fichier, je me l'envoie sur ma messagerie personnelle. Et on a troqué un risque qu'on voyait contre un risque qu'on ne verra pas.
Et le terrain, ici, n'est pas celui d'une organisation isolée. Deux administrations se partagent une partie du personnel, dans deux réseaux complètement séparés. Des personnes travaillent exclusivement pour l'une mais sont installées physiquement dans les locaux de l'autre : leur poste doit atteindre un SI qui n'est pas celui de la prise murale dans laquelle il est branché. D'autres encore passent une moitié de leur semaine de chaque côté, et avaient pris l'habitude, année après année, de poser leurs fichiers dans le réseau du voisin — c'était pratique, personne n'avait tracé la frontière, et pour qui travaille des deux côtés il n'y en avait pas vraiment.
Dans cette configuration-là, le passage au full tunnel strict n'est pas seulement un recul perçu, c'est la fin d'une pratique installée. On ne décourage pas un contournement, on démonte une infrastructure officieuse qui tenait toute seule depuis longtemps. Et on crée au passage une vraie question d'organisation, pas de technique : à qui appartient un fichier posé par une personne employée par A dans un dossier partagé par B, sur un poste fourni par C ? La réponse n'est pas dans le pare-feu.
L'arbitrage s'écrit alors en deux temps. L'architecture tient fermement sur le fond — un poste, un employeur, un périmètre, et le reste se demande explicitement. Et l'accompagnement fait exister autrement les cas d'usage légitimes : impression centralisée via l'infrastructure, dépôt documentaire aux endroits prévus, canaux inter-administrations nommés et bornés pour celles et ceux qui ont réellement une double appartenance. Sans ce second temps, le premier ne tient pas trois mois : les gens recommencent, et avec un peu d'ingéniosité ils trouvent un chemin qu'aucune règle ne journalise.
Le pare-feu finit par montrer le SI
Le passage que je retiens le plus de ce chantier n'est pas un paramètre de tunnel. C'est le moment où le pare-feu devient, pour la première fois, un endroit depuis lequel on voit vraiment ce qui se passe.
Un trafic qui ne devrait pas exister apparaît en clair dans les journaux dès qu'on cesse de le mélanger au reste. Une destination inconnue, interrogée tous les quarts d'heure par un équipement précis, finit par avoir un nom. Un poste qui tente d'ouvrir une session à des heures impossibles pose une question qu'il faut aller instruire — pas forcément une alerte, parfois juste un collègue qui travaille sur un autre fuseau. Et, parfois, autre chose.
Ce n'est pas tout à fait la même posture qu'administrer un pare-feu. Administrer, c'est répondre à : ce flux est-il autorisé ? Et quand il ne l'est pas, le bloquer. L'autre posture commence par la question d'avant : pourquoi ce flux existe-t-il ? Puis viennent les suivantes : qui l'a généré, depuis quel poste, avec quelle identité, depuis quand, et qu'est-ce qu'on en garde comme trace ? Les règles ne répondent pas à ces questions-là. Les journaux, les corrélations entre équipements, et un peu de patience, oui. Les deux postures ont leur place dans la même équipe — simplement ce n'est plus la même journée de travail.
Ce travail-là ressemble à ce que je décrivais devant une capture d'alarme ou devant un portier qui n'exposait aucune API : on regarde ce qui sort, on ne devine pas. La différence d'échelle est réelle, le réflexe est le même. Et pour que ce réflexe serve à quelque chose, deux conditions tiennent dans une main : l'horloge est à l'heure et son décalage est noté, et les règles qu'on croit appliquer sont celles qui s'appliquent vraiment — j'ai assez relaté ce qu'on trouve en relisant son propre travail pour ne plus avoir à le répéter.
Le mot « zero-trust » traîne au-dessus de tout ça. Comme la plupart des mots neufs, il désigne quelque chose d'ancien : on n'autorise pas ce qu'on n'a pas eu à autoriser, et on reconstitue le reste à partir de ce qu'on observe. Changer de pare-feu ne crée pas cette discipline. Il offre, à ceux qui veulent s'en servir, le premier endroit depuis lequel elle est possible.
Ce que je retiens
- La modernisation d'une pièce révèle l'âge des autres. Un NGFW n'invente pas l'identité, le poste géré, les certificats machine. Il demande à ce qu'ils existent, et il le fait au moment où on l'allume.
- Les contrôles de sécurité sont des révélateurs d'inventaire. L'inspection SSL ne « casse » pas les applications inconnues, elle les rend visibles pour la première fois.
- Chaque exception doit avoir un propriétaire et une date de revue. Sans ça, elle devient un meuble qu'on ne déplace plus.
- Une architecture tient par l'accompagnement autant que par la configuration. Le full tunnel ne vaut que si l'impression, le dépôt, le partage ont été repensés en même temps.
- Un pare-feu bien exploité est un poste d'observation. Les règles filtrent ; les journaux racontent — à qui prend le temps de les lire et de poser les bonnes questions.
Je sors de ce chantier avec moins de certitudes sur la technologie, et davantage sur la méthode. Le pare-feu neuf n'était pas la fin du projet. Il en était le début — et surtout, le premier endroit depuis lequel on pouvait enfin se demander, concrètement, qu'est-ce qui passe par là, qui le fait, pourquoi, et qu'est-ce qu'on en garde comme trace ?