Un lundi matin, la téléphonie IP tombe sur un site distant pendant deux heures. Le prestataire diagnostic un switch saturé, installé trois ans plus tôt sans documentation. Ce type de panne, souvent évitable, illustre à quel point un audit réseau informatique ne se limite pas à cocher des cases : on cherche les angles morts que le quotidien finit par masquer.
Shadow IT et équipements non inventoriés : le vrai point de départ d’un audit réseau
Les articles sur l’audit réseau commencent souvent par la définition du périmètre. Sur le terrain, le périmètre bouge en permanence. Des caméras IP branchées par le service maintenance, une borne Wi-Fi ajoutée dans un open space, un NAS personnel connecté au VLAN bureautique : ces équipements « shadow IT » échappent à l’inventaire officiel.
A découvrir également : Plongée dans l'art fascinant de faire des animaux en origami 3D
Avant même de lancer un scan de vulnérabilités, on gagne du temps en faisant un balayage physique et logique de tous les ports actifs. Cela signifie parcourir les baies de brassage, relever les connexions réelles, puis croiser avec les tables ARP et les logs DHCP. L’écart entre les deux listes donne la mesure du shadow IT présent sur le réseau.
Cette phase de découverte est d’autant plus critique que les environnements hybrides (sites physiques, cloud, télétravail) multiplient les points d’entrée. Depuis 2023, les retours d’expérience montrent une hausse significative des incidents liés à des équipements IoT non inventoriés. On peut approfondir l’audit réseau informatique avec E-novateur pour structurer cette étape de cartographie initiale.
A découvrir également : Les meilleures astuces pour regarder des films en streaming sur votre smart TV
Cartographie des flux inter-sites et multi-cloud : une étape souvent bâclée
La plupart des audits réseau documentent correctement le LAN. Les flux entre sites distants, entre le datacenter et les fournisseurs cloud, ou entre deux environnements cloud distincts, sont beaucoup moins souvent tracés.
Cartographier les flux inter-cloud avant de tester la sécurité évite de découvrir en fin d’audit qu’un tunnel VPN site-to-site utilise encore un chiffrement obsolète, ou qu’un peering direct entre deux providers cloud n’est supervisé par aucune sonde.
Ce que la cartographie doit couvrir concrètement
- Les connexions WAN et SD-WAN entre chaque site, avec les débits réels mesurés (pas seulement les débits contractuels)
- Les flux applicatifs vers les services SaaS critiques (messagerie, ERP, téléphonie), en identifiant les chemins de routage et les points de sortie Internet
- Les interconnexions cloud-to-cloud et cloud-to-on-premise, avec vérification des règles de segmentation et des politiques de filtrage appliquées à chaque passerelle
Des outils de type NDR (Network Detection and Response) ou des plateformes SASE permettent d’obtenir cette visibilité. Ça dépend de l’installation : une PME mono-site avec un seul tenant cloud n’a pas besoin du même outillage qu’un groupe multi-sites.
Audit réseau et conformité NIS2 : ce que la directive change en pratique
La directive européenne NIS2, dont la transposition nationale a démarré à partir de 2024, impose aux entités classées « essentielles » ou « importantes » de démontrer une surveillance régulière de leurs réseaux avec traçabilité des audits. Concrètement, cela signifie qu’un audit ponctuel réalisé une fois tous les trois ans ne suffit plus.
NIS2 demande des plans d’actions documentés après chaque audit, avec un suivi des remédiations. Pour une entreprise qui réalise son premier audit, l’enjeu est de produire un livrable exploitable par la direction comme par l’équipe technique.
Structurer le rapport pour répondre aux exigences réglementaires
Le rapport d’audit doit contenir au minimum trois éléments distincts :
- Un inventaire à jour des actifs réseau (matériels, logiciels, configurations), horodaté et signé
- Une matrice des vulnérabilités identifiées, classées par criticité, avec pour chacune la recommandation technique associée et un délai de correction proposé
- Un plan de remédiation priorisé, validé par un responsable identifié, avec des jalons de suivi trimestriels
Ce formalisme peut sembler lourd pour une PME. Mieux vaut un document court et actionnable qu’un rapport de 80 pages jamais lu. Nous recommandons de séparer la synthèse décisionnelle (deux pages maximum, destinée à la direction) du détail technique (annexes structurées par catégorie d’équipement).
Tests de segmentation réseau : vérifier ce que le pare-feu laisse réellement passer
Configurer des VLANs et des règles de filtrage ne garantit rien si personne ne vérifie leur efficacité réelle. On constate régulièrement des règles « any-any » laissées en place après une migration, ou des exceptions temporaires devenues permanentes.
Tester la segmentation consiste à simuler un déplacement latéral depuis un poste utilisateur standard vers les sous-réseaux sensibles (serveurs, administration, IoT). Si un poste du VLAN bureautique peut atteindre l’interface de management d’un switch coeur de réseau, la segmentation est en échec, quelle que soit la politique documentée.
Ce test se fait avec des outils simples (Nmap, Netcat) ou avec des solutions de pentest automatisé. L’objectif n’est pas de produire un rapport de centaines de ports scannés, mais de répondre à une question binaire pour chaque zone : le cloisonnement fonctionne-t-il ou non.
Prioriser les corrections après les tests
Toutes les failles de segmentation n’ont pas le même impact. Une communication ouverte entre le VLAN imprimantes et le VLAN serveurs de fichiers présente un risque modéré. Un accès direct depuis le Wi-Fi invité vers le réseau d’administration représente une faille critique à corriger en priorité.
Le piège classique est de vouloir tout corriger simultanément. On bloque alors des flux légitimes et on génère des tickets d’incident en cascade. La séquence la plus fiable : corriger d’abord les accès à l’administration réseau, puis les flux vers les données sensibles, et enfin les communications inter-VLAN secondaires.
Un audit réseau réussi ne se mesure pas au nombre de pages du rapport, mais au nombre de corrections effectivement appliquées trois mois plus tard. Le livrable le plus utile reste un tableau de suivi partagé entre la DSI et la direction, mis à jour à chaque jalon, avec un statut clair pour chaque vulnérabilité identifiée.