Combien de temps a duré cette refonte réseau et y a-t-il eu des interruptions de service pendant la migration ?

Le projet s'est déroulé sur 6 mois, phasé par vagues afin de migrer les agences et les datacenters progressivement plutôt qu'en une seule bascule. Les paires SD-WAN et pare-feu ont été déployées en haute disponibilité sur chaque site précisément pour éviter toute interruption locale pendant la transition, et les anciens chemins hub-and-spoke sont restés disponibles en secours tant que la nouvelle architecture de chaque site n'était pas validée.

Faut-il remplacer Cisco SD-WAN ou Palo Alto Networks si nous avons déjà standardisé sur d'autres fournisseurs ?

Non, le principe sous-jacent, sortie locale du trafic SaaS, accès Zero Trust basé sur l'identité et segmentation pilotée par Terraform, est indépendant du fournisseur et a déjà été mis en œuvre avec d'autres plateformes SD-WAN et pare-feu nouvelle génération. Les investissements Cisco et Palo Alto déjà réalisés par le client ont été réutilisés ici pour éviter un remplacement coûteux et inutile, pas parce qu'ils sont indispensables.

Cette approche est-elle réaliste pour une équipe IT qui n'est pas une grande organisation plateforme spécialisée ?

Oui, cette contrainte était explicite dès le cadrage du projet : l'équipe existante du client devait pouvoir exploiter le nouvel environnement sans effectif supplémentaire. La codification des règles et des politiques de routage dans Terraform, associée à l'automatisation des tâches récurrentes avec Ansible, est précisément ce qui a permis à une équipe restreinte de gérer des dizaines de sites de façon cohérente.

Quel a été le plus grand risque de ce projet et comment a-t-il été maîtrisé ?

Le risque principal était de casser des accès ou des connexions existants en rationalisant des milliers de règles de pare-feu qui se chevauchaient et étaient mal documentées après des années d'accumulation et d'acquisitions. Ce risque a été maîtrisé en réalisant d'abord une évaluation complète du trafic et des dépendances avant de toucher la moindre règle, puis en déployant les changements via Terraform versionné, revu par les pairs et doté d'un chemin de retour arrière fiable.

Retour aux études de cas

Services financiersRéseau et cloudSécurité et conformité

Refonte du réseau hybride

Moderniser la connectivité d'entreprise avec des modèles Zero Trust, en remplaçant une architecture hub-and-spoke rigide et centrée sur le périmètre par un modèle piloté par l'identité, pensé pour le travail hybride et les usages cloud-first.

Meilleures performances et moindre privilège appliqué

Client

Confidentiel — services financiers

Secteur

Services financiers

Calendrier

6 mois

Technologies

6+ outils

Le défi

!Le réseau central du client reposait encore sur une architecture hub-and-spoke vieille de dix ans, qui faisait transiter tout le trafic des agences et des collaborateurs distants par deux datacenters centralisés, même lorsque la destination réelle était une application SaaS à quelques sauts réseau seulement. Ce backhauling ajoutait de la latence sur des outils du quotidien comme le CRM ou les plateformes de support au trading, et transformait chaque incident régional en incident global.

!La sécurité reposait presque entièrement sur le périmètre réseau, avec un petit nombre de règles de pare-feu très larges autorisant un accès étendu entre sous-réseaux dès qu'un appareil se trouvait à l'intérieur du réseau de l'entreprise. Ce modèle supposait un réseau interne de confiance qui n'existait plus, entre travail à distance, accès prestataires et charges cloud devenus la norme.

!Les agences constataient des performances irrégulières et imprévisibles pour atteindre les plateformes SaaS et les API cloud, avec des pics de latence lors des fenêtres critiques de trading ou de reporting que l'IT ne parvenait ni à reproduire ni à diagnostiquer de façon fiable. De nombreux tickets se refermaient en 'intermittent, cause inconnue' faute d'outillage capable de corréler chemin réseau, application et horodatage.

!La visibilité sur les décisions d'accès basées sur l'identité et sur le trafic est-ouest entre serveurs et services internes était quasi inexistante. Les analystes sécurité pouvaient constater qu'une connexion existait, mais pas identifier l'utilisateur ou le compte de service à l'origine, ce qui rendait l'investigation d'un trafic interne anormal lente et largement manuelle.

!Les politiques de pare-feu s'étaient accumulées pendant des années, portées par plusieurs équipes et acquisitions successives, aboutissant à des milliers de règles qui se chevauchaient et se contredisaient parfois. Personne n'avait la certitude qu'en supprimer une n'allait rien casser, si bien que la base de règles ne cessait de grossir au lieu d'être nettoyée.

!Les cycles de conformité et d'audit mobilisaient des semaines de collecte manuelle de preuves, les journaux d'accès, les configurations de pare-feu et les historiques de changement vivant dans des systèmes disjoints sans couche de reporting commune. Les auditeurs demandaient régulièrement des éléments qui nécessitaient plusieurs jours d'assemblage manuel à partir d'exports de configuration et d'échanges d'e-mails.

!La segmentation entre les charges sensibles — dont des systèmes soumis à des exigences réglementaires financières — et le trafic d'entreprise général restait minimale, reposant surtout sur une séparation VLAN plutôt que sur une politique réellement appliquée. Un poste compromis pouvait, en théorie, atteindre bien plus de ressources que ne l'exigeait un quelconque processus métier légitime.

!Les équipes IT et sécurité devaient par ailleurs accompagner de nouveaux modes de fonctionnement hybrides et distants sans augmenter leurs effectifs, ce qui imposait que toute refonte reste exploitable par l'équipe existante plutôt que d'exiger une équipe plateforme spécialisée et étoffée.

Notre solution

SystimaNX a commencé par une évaluation complète du trafic et des dépendances entre les agences, les datacenters et les environnements cloud, afin d'identifier les applications nécessitant réellement un chemin direct à faible latence, par opposition à celles pouvant tolérer une inspection centralisée. Cette cartographie de référence a servi de fondation à chaque décision de routage et de politique prise ensuite.

Nous avons repensé la connectivité WAN autour de Cisco SD-WAN, en introduisant un routage piloté par les politiques permettant au trafic SaaS et cloud de sortir localement depuis l'agence plutôt que de transiter par les datacenters centraux. La sélection de chemin sensible aux applications permet désormais au trafic critique en latence d'emprunter la route directe la plus adaptée, pendant que le trafic moins prioritaire utilise des liens optimisés en coût.

Nous avons mis en place un modèle d'accès Zero Trust reposant sur Azure AD, remplaçant la confiance large accordée au niveau réseau par une vérification continue et basée sur l'identité pour chaque session. Les décisions d'accès prennent désormais en compte l'identité de l'utilisateur, la posture de l'appareil et le contexte, et non plus seulement l'origine de la connexion au sein du réseau d'entreprise.

Des pare-feu nouvelle génération Palo Alto Networks ont été déployés en paires haute disponibilité sur tous les sites critiques, ce qui a permis de consolider et de rationaliser des années d'accumulation de règles en un ensemble de politiques plus réduit et clairement documenté. Le doublement redondant sur chaque site a supprimé les points de défaillance unique qui transformaient auparavant un incident local en interruption prolongée.

Nous avons établi une micro-segmentation explicite pour les charges réglementées et sensibles, les isolant du trafic d'entreprise général par une politique réellement appliquée et non plus par simple convention VLAN. L'équipe sécurité dispose ainsi d'une frontière démontrable et défendable autour des systèmes les plus critiques pour la conformité.

Les changements d'infrastructure ont été codifiés avec Terraform, afin que les règles de pare-feu, les politiques de routage et les frontières de segmentation puissent être versionnées, revues par les pairs et déployées de façon homogène sur tous les sites plutôt que configurées manuellement poste par poste. Cela a également offert à l'équipe un chemin de retour arrière fiable en cas de besoin d'annuler un changement.

Des playbooks Ansible ont automatisé les tâches récurrentes de configuration et de conformité sur l'ensemble du parc de pare-feu et de SD-WAN, réduisant l'effort manuel nécessaire pour maintenir des dizaines de sites dans un état cohérent. Les correctifs et déploiements de politiques qui nécessitaient auparavant plusieurs jours de fenêtres de changement coordonnées sont devenus des tâches planifiées et reproductibles.

Splunk a été déployé comme couche centrale de journalisation et d'analyse, corrélant les événements d'identité, de réseau et de pare-feu dans des tableaux de bord unifiés pour les équipes sécurité et exploitation réseau. Les deux équipes disposent désormais d'une source de vérité commune pour investiguer les incidents et produire des preuves d'audit à la demande.

Impact mesurable

Expérience utilisateur

Réduction de la latence de 30 à 40 %

La sortie locale du trafic SaaS via SD-WAN a réduit la latence aller-retour vers les plateformes cloud et SaaS d'environ 30 à 40 % pour les utilisateurs des agences lors des pics de trading et de reporting.

Posture de sécurité

Alignée Zero Trust

Les décisions d'accès centrées sur l'identité via Azure AD ont remplacé la confiance implicite large accordée à tout ce qui se trouvait dans le périmètre.

Exploitation

70 % de changements manuels en moins

Terraform et Ansible ont standardisé les politiques et les configurations sur tous les sites, réduisant d'environ 70 % les changements de pare-feu manuels et sources d'erreurs.

Conformité

De plusieurs semaines à moins de 3 jours

Les tableaux de bord Splunk et les dossiers de preuve alignés sur les référentiels courants ont réduit la préparation des audits de plusieurs semaines à moins de 3 jours par cycle.

Base de règles

60 % de règles de pare-feu en moins

Des années de règles de pare-feu qui se chevauchaient ont été consolidées d'environ 60 % en un ensemble de politiques plus restreint et clairement attribué sur les nouvelles paires HA.

Portée des incidents

Rayon d'impact limité à un seul segment

La segmentation des charges réglementées a confiné l'impact réel de tout poste ou compte compromis à un seul micro-segment plutôt qu'à l'ensemble du réseau.

Visibilité

100 % du trafic est-ouest corrélé

Le trafic est-ouest et les décisions d'accès basées sur l'identité sont devenus entièrement traçables dans Splunk pour la première fois, du datacenter jusqu'au cloud.

“Il nous fallait performance et sécurité sans nouveau « projet science ». L'architecture était pragmatique et exploitable, et elle nous a enfin permis de répondre clairement aux auditeurs et à la direction sur qui pouvait accéder à quoi et pourquoi. Cette combinaison de rapidité, de contrôle et de preuves, nous ne l'avions jamais eue avec notre ancienne installation.”
R
Responsable sécurité
RSSI, services financiers (NDA)

Stack technologique

Palo Alto NetworksCisco SD-WANAzure ADTerraformSplunkAnsible