Audit d'un Réseau d'Entreprise de Classe Opérateur

Le type de mission dont il s’agit

Les grandes entreprises qui ont grandi pendant une décennie sous différentes équipes et différentes priorités accumulent un écart entre ce que la direction croit exploiter et ce qui se trouve réellement dans les racks. La documentation dérive, la propriété se fragmente, et le réseau fonctionne assez bien pour que personne n’ait à regarder de près. Puis un cycle budgétaire, un incident ou un nouvel architecte force la question : qu’avons-nous réellement, qu’est-ce qui est à risque, et à quoi doivent ressembler les prochaines années?

Ce texte est une synthèse de ce travail d’audit, dont les détails ont été généralisés. Le livrable n’est jamais un rapport de test d’intrusion ni une présentation. C’est un High-Level Design structuré, destiné à devenir la source unique de vérité, appuyé par des documents de conception détaillée, des exports d’inventaire et des preuves CLI brutes pour chaque affirmation.

Le type d’environnement

Les réseaux qui méritent un audit à ce niveau partagent souvent une même forme : un cœur de classe opérateur (SR-MPLS sur IS-IS, segment routing propre sans protocoles de labels hérités), des fabriques EVPN/VXLAN étendues sur le WAN, du routage internet public en bordure, une forte segmentation L3VPN et un parc multi-fournisseurs (Juniper dans le cœur, pare-feu variés, interconnexions cloud). Assez de pièces mobiles pour qu’aucune personne seule ne détienne l’image complète, ce qui est précisément pourquoi un audit fondé sur les preuves justifie son coût.

Méthode : les preuves d’abord, les opinions ensuite

Les audits échouent de deux manières. Soit ils font confiance à la documentation, toujours périmée, soit aux entrevues, toujours optimistes. Je construis l’audit sur une règle différente : chaque affirmation se rattache à une preuve confirmée, et toute inférence est signalée comme telle, jamais présentée comme un fait.

Concrètement :

• Extraction de l’état réel depuis les équipements eux-mêmes : tables de routage, états des sessions BGP, minuteries BFD, bases de données OSPF, compteurs de correspondance des politiques de pare-feu.
• Rapprochement avec le système d’inventaire, chaque écart devenant une trouvaille en soi.
• Séparation stricte des domaines. Un audit type en couvre cinq : WAN et backbone, fabriques data center et campus, bordure internet, sécurité et segmentation, et préparation opérationnelle. Les constats de sécurité ne débordent jamais dans les sections fabrique, ce qui rend chaque chapitre défendable isolément.
• Notation de chaque domaine sur la même échelle : ce qui fonctionne, ce qui est à optimiser, et ce qui constitue un risque d’affaires réel.

Le public visé est la haute direction, donc la discipline d’écriture compte autant que l’ingénierie. Les recommandations doivent résister à l’examen des dirigeants sans s’engager prématurément sur des détails d’implémentation.

La leçon centrale : juger le transport et la sécurité séparément

La phrase la plus utile d’un audit de ce type est presque toujours la même : le transport peut être excellemment conçu alors que les risques critiques vivent tout à fait ailleurs.

Un backbone de classe opérateur (segment routing propre, hiérarchie de métriques IS-IS étagée, conception soignée des route reflectors, communautés BGP uniformes, politique de validation d’origine RPKI templatée sur la bordure) indique que ceux qui l’ont bâti savaient ce qu’ils faisaient. Mais le risque se trouve souvent dans le modèle de sécurité posé par-dessus, et les deux sont des axes indépendants.

L’exemple récurrent est la politique d’import de routes VRF. La segmentation L3VPN est régie par l’import et l’export de route-targets, ce qui veut dire que la liste d’imports est fonctionnellement la liste de contrôle d’accès entre des segments entiers du réseau, sauf qu’elle vit dans la configuration de routage, se fait éditer par des ingénieurs réglant des tickets de connectivité, et n’est revue par personne qui pense en termes de chemins d’attaque. Au fil des années, un ticket à la fois, un segment d’accès distant peut finir par importer bien plus du réseau qu’il ne le devrait. Pire : quand deux segments échangent leurs routes directement, ce trafic est-ouest se résout à l’intérieur de la fabrique et ne traverse jamais les pare-feu nord-sud, si bien que le modèle d’inspection a un angle mort qu’aucune alarme ne signale. (Je détaille ce mode de défaillance dans l’article sur les fuites de routes VRF.) Le point réutilisable : lisez la matrice d’import/export comme s’il s’agissait d’une politique de pare-feu, parce que c’est ce qu’elle est.

Cette distinction, un transport excellent et une question de sécurité séparable, est ce qui distingue un plan de remédiation ciblé d’une panique de remplacement intégral. C’est aussi l’argument qui empêche de jeter un cœur MPLS bien construit au profit du SD-WAN sous prétexte que « le réseau a des problèmes ».

Les types de constats qui reviennent

Un échantillon des schémas qu’un audit fondé sur les preuves tend à révéler, généralisés plutôt que rattachés à un réseau précis :

• Du théâtre RPKI. Une politique de validation d’origine templatée identiquement partout, mais tous les points de bordure n’ont pas forcément un flux de validateur fonctionnel derrière, si bien que sur certaines sessions la politique est un no-op silencieux. La leçon se généralise : vérifier l’effet, pas la présence de configuration. (Plus de détails dans RPKI : la politique était parfaite, les validateurs manquaient.)
• Décrépitude des règles de pare-feu. La grande majorité des règles n’ayant jamais correspondu à un seul paquet, le trafic se concentrant dans une poignée de permissions larges. (Le schéma complet est ici.)
• Dette de cycle de vie. Des commutateurs d’accès au-delà de la fin de support sans contrat fournisseur, et des équipements privilégiés (serveurs de console, appliances de gestion) exécutant un firmware en retard de plusieurs années portant des CVE connues et nommées, souvent joignables plus largement que prévu.
• Le paradoxe du hors-bande. Un chemin de gestion de secours qui dépend discrètement du réseau qu’il est censé secourir, si bien que lors d’une vraie panne l’outil de réparation du réseau tombe avec le réseau. (Détaillé ici.)
• Dérive silencieuse. Restes de configuration, minuteries incohérentes, authentification de protocole de routage manquante, et redondance qui existe sur papier mais pas en pratique.

Chaque constat entre dans un registre des risques avec sévérité, rayon d’impact et remédiation concrète, pour que la direction raisonne sur des priorités plutôt que sur des adjectifs.

Des constats à un plan pluriannuel

Un audit qui s’arrête aux constats n’est qu’une plainte. Celui-ci se termine en feuille de route :

1. Stabiliser. Gains rapides et réduction des risques : durcir en place les segments d’accès trop permissifs, combler les manques de validateurs RPKI, corriger et renouveler le parc hors-bande, remplacer les commutateurs en fin de vie, rétablir la redondance AAA. Surtout du travail de configuration, très peu de capital.
2. Segmenter. L’investissement de sécurité stratégique : bâtir un point d’inspection est-ouest, isoler la DMZ dans son propre segment, et amorcer un déploiement ZTNA pour retirer l’accès VPN à plat, avec une base de référence des flux comme prérequis avant de toucher aux imports de routes.
3. Standardiser. Refonte des VLAN et VRF alignée sur les départements, matrice d’import/export uniforme entre les sites, schéma EVPN ESI cohérent, authentification OSPF sur tout le parc.
4. Observer et automatiser. Supervision consolidée, audits de conformité automatisés, détection de dérive, protection DDoS hybride.
5. Optionnalité. Réévaluer le SD-WAN uniquement pour les petits sites satellites. Les sites du backbone qui portent des tables de routage complètes, de l’EVPN sur le WAN et une forte segmentation tendent à rester en MPLS, et prétendre le contraire est du théâtre coûteux.

Les chiffres budgétaires sont cadrés en catégories capital et récurrent, avec soumissions fournisseurs en attente, jamais de précision inventée. L’acquisition de pare-feu, par exemple, est présentée comme un comparatif à plusieurs fournisseurs avec un modèle de coût total plutôt qu’un chiffre unique.

Ce que j’en retiens

Ce travail a renforcé une conviction que j’applique désormais partout : séparer la qualité de ce qui a été construit du risque lié à la façon dont c’est utilisé. Ce sont des axes indépendants, et les fusionner en un seul « score de santé réseau » produit soit une fausse alerte, soit un faux confort. Les travaux qui suivent deviennent leur propre série de projets, dont la conception de segmentation est-ouest et la couche de connaissance IA construite sur la base documentaire d’un audit.