Conseil d'expert en réseau : mieux vaut ne pas mettre ces trois « œufs de Pâques » dans votre panier.

De nombreux problèmes réseau ne sont pas dus à une technologie défaillante, mais à des structures qui se sont développées au fil du temps et à des décisions pragmatiques prises par le passé. On peut citer comme exemples typiques les réseaux plats sans séparation claire entre la technologie opérationnelle (OT) et la technologie de l'information (IT), ainsi que le manque de transparence concernant les systèmes OT, les règles de pare-feu mises en place à titre de solutions provisoires et les infrastructures exploitées bien au-delà de leur cycle de vie. Lors d’une analyse du réseau d’un client industriel, nous avons justement rencontré ce type de structures évoluées : les réseaux IT et OT n’étaient pas séparés, le réseau était de type plat, un réseau OT distinct d’un fabricant n’était pas du tout documenté, et plusieurs appareils étaient déjà en fin de vie (EOL) avec des logiciels obsolètes. De telles situations ne sont en aucun cas inhabituelles : les réseaux se développent au fil des ans, de nouveaux systèmes sont intégrés, des projets s’ajoutent, et toutes les décisions architecturales ne sont pas remises en question par la suite.

Conseil n° 1 : appareils OT inconnus – manque de visibilité

Dans de nombreuses entreprises, l’informatique classique est relativement bien inventoriée. Les serveurs, les clients, les équipements réseau ou les ressources cloud sont répertoriés dans des systèmes de gestion des actifs, des outils de surveillance ou des bases de données de gestion de la configuration (CMDB). Dans le domaine OT, cependant, la situation est souvent différente. Les installations de production, les systèmes de contrôle, les automates programmables (PLC) ou les PC industriels fonctionnent pendant de nombreuses années. De nouvelles machines viennent s’ajouter, les installations existantes sont étendues ou modernisées – mais la documentation du réseau n’est pas toujours mise à jour de manière cohérente. Il est donc difficile de savoir quels systèmes OT se trouvent réellement sur le réseau, quels appareils communiquent avec quels systèmes, quels composants sont critiques pour la production, et où tournent des systèmes d’exploitation obsolètes et des protocoles non sécurisés. Sans une visibilité OT suffisante, le réseau devient rapidement une boîte noire. Les risques de sécurité restent cachés et une segmentation claire devient difficile. Dans le domaine industriel en particulier, la transparence sur les systèmes OT est aujourd’hui un élément central des stratégies de sécurité modernes. Une approche structurée de la découverte des actifs et de la surveillance du réseau peut déjà faire une grande différence.

Conseil n° 2 : ne pas ouvrir de ports temporairement pour ensuite les oublier

Autre schéma que l’on retrouve dans de nombreux réseaux : une application ne fonctionne pas ou un fournisseur a besoin d’accéder à un système. La solution rapide consiste alors souvent à dire : « On va ouvrir le port rapidement. » Le problème, c’est que les règles de pare-feu temporaires restent rarement temporaires. Chez notre client industriel également, nous avons trouvé des pare-feu avec des ports ouverts, dont personne ne savait plus exactement pourquoi ils l’étaient. La documentation était en partie incomplète ou obsolète depuis longtemps. Souvent, de telles situations surviennent presque automatiquement – à cause de nouvelles applications, d’accès de fournisseurs ou de projets. Chaque modification laisse une règle supplémentaire. Avec le temps, cela conduit à des ensembles de règles confus, à des ports inutilement ouverts, à un manque de traçabilité et à des risques de sécurité accrus. Dans le cadre de la reprise de l’exploitation, nous avons systématiquement vérifié les règles de pare-feu, supprimé celles qui n’étaient plus nécessaires et restructuré les politiques. Il en a résulté une configuration de pare-feu nettement plus claire et plus sûre. Un principe simple s’applique souvent ici : chaque règle de pare-feu doit avoir un objectif clairement documenté, un responsable et, idéalement, une date de révision.

Conseil n° 3 : ne pas exploiter l’infrastructure trop longtemps

Un autre point qui a retenu notre attention : les équipements réseau sont déjà en fin de vie (EOL) ou fonctionnent avec des versions logicielles nettement obsolètes. Dans de nombreuses organisations, l’infrastructure est exploitée tant qu’elle fonctionne techniquement. Pour des raisons budgétaires ou de priorités, son remplacement est sans cesse reporté. Les risques augmentent cependant avec le temps : il n’y a plus de mises à jour de sécurité de la part du fabricant, l’assistance est limitée, voire inexistante, les pannes matérielles deviennent plus probables et les fonctionnalités réseau ou de sécurité modernes font défaut. Dans le domaine des réseaux en particulier, une gestion structurée du cycle de vie s’avère utile pour éviter de telles situations à un stade précoce.

L'amélioration commence par un état des lieux

Les réseaux modernes ne doivent pas seulement fonctionner. Ils doivent également être transparents, sécurisés et exploitables à long terme. Et parfois, l’amélioration commence tout simplement par un état des lieux complet. UMB AG peut vous y aider. En collaboration avec nos partenaires de pointe, nous garantissons un réseau performant qui fonctionne selon les normes de sécurité les plus élevées. Nous ne sommes pas seulement des spécialistes des réseaux, mais pouvons également prendre en charge l’ensemble de votre infrastructure. Notre approche globale de l'informatique garantit que tout fonctionne en harmonie. Grâce à nos services réseau, nous analysons votre configuration réseau et de sécurité actuelle et identifions la technologie et la conception adaptées à votre entreprise.  Contactez-nous !

Découvrez nos services réseau ici.

Décrouvez nos services réseau ici.