Le règlement DORA est entré en vigueur le 17 janvier 2025, sans période de transition. Pour les banques, les assureurs et les gestionnaires de patrimoine européens, le règlement impose la segmentation du réseau, l’accès au moindre privilège, l’authentification forte et la surveillance continue de tous les systèmes TIC. Il ne s’agit pas d’objectifs ambitieux. Il s’agit d’exigences vérifiables, assorties d’amendes pouvant aller jusqu’à 1 % du chiffre d’affaires journalier moyen mondial.
La plupart des institutions financières de taille moyenne utilisent encore des piles de sécurité fragmentées : concentrateurs VPN séparés, pare-feu autonomes dans chaque succursale, filtrage web d’un fournisseur, protection des points d’extrémité d’un autre. Cette approche fonctionnait lorsque les employés étaient assis au bureau et que les applications se trouvaient dans le centre de données. Elle ne fonctionne plus lorsque les conseillers se connectent depuis leur domicile, que les outils de conformité fonctionnent dans le nuage et que les autorités de réglementation exigent une piste d’audit unifiée qui retrace chaque décision d’accès jusqu’à une identité vérifiée.
Une plateforme Secure Access Service Edge (SASE) consolide ces contrôles en un seul service géré dans le nuage. Ce guide explique comment chaque composant SASE correspond à des obligations DORA spécifiques, à quoi ressemble actuellement le paysage des menaces pour les services financiers européens et comment les institutions du marché intermédiaire peuvent mettre en œuvre SASE sans la complexité des projets d’entreprise des méga-fournisseurs.
Pourquoi DORA change l’équation de la sécurité pour les services financiers
Les précédents règlements financiers de l’UE ont abordé la cybersécurité de manière indirecte. DORA est différent. Il s’agit du premier cadre harmonisé qui prescrit des contrôles techniques des TIC à plus de 22 000 entités financières et à leurs fournisseurs de services TIC dans toute l’UE.
Le règlement repose sur cinq piliers : la gestion des risques liés aux TIC, la notification des incidents, les tests de résilience opérationnelle numérique, la gestion des risques liés aux TIC pour les tiers et le partage d’informations. Chaque pilier correspond à des capacités qu’une plateforme SASE unifiée fournit de manière native.
L’article 9 est le plus pertinent pour la sécurité des réseaux. Il exige des entités financières qu’elles conçoivent une infrastructure de réseau qui puisse être « instantanément coupée ou segmentée » afin d’éviter la contagion en cas d’incident. Le même article exige que l’accès aux actifs TIC soit limité à « ce qui est nécessaire pour des fonctions légitimes et approuvées uniquement » et que les entités déploient des « mécanismes d’authentification forte » avec des contrôles cryptographiques. L’article 10 exige des mécanismes de détection avec « plusieurs niveaux de contrôle » et la surveillance de « l’activité des utilisateurs, des anomalies des TIC et des incidents liés aux TIC ».
Les obligations en matière de rapports d’incidents sont strictes. Les entités financières doivent soumettre une notification initiale dans les quatre heures suivant la classification d’un incident TIC majeur, un rapport intermédiaire dans les 72 heures et un rapport final une fois l’analyse des causes profondes terminée. En l’absence d’un enregistrement centralisé permettant de corréler les événements d’accès pour tous les utilisateurs, appareils et applications, il n’est pas possible de respecter ces délais.
La gestion des risques liés aux TIC pour les tiers (articles 28 à 44) ajoute une couche supplémentaire. Les entités financières doivent tenir un registre d’informations documentant tous les contrats de TIC avec des tiers. L’article 30 exige des dispositions contractuelles concernant la localisation des données, les accords de niveau de service, les conditions de résiliation et les droits d’audit illimités. Pour les institutions qui utilisent des fournisseurs de sécurité dont le siège est aux États-Unis, cela soulève des questions gênantes quant à l’exposition juridictionnelle en vertu du CLOUD Act.
| Exigence DORA | Article pertinent | Composant SASE |
|---|---|---|
| Accès au moindre privilège avec authentification forte | Art. 9(4)(c), 9(4)(d) | ZTNA avec MFA et posture de l’appareil |
| Segmentation du réseau et isolation automatisée | Art. 9(4)(b) | FWaaS avec micro-segmentation |
| Protection des données en transit et au repos | Art. 9(2), 9(3)(a) | GTS avec inspection TLS et DLP |
| Détection multicouche et surveillance de l’activité des utilisateurs | Art. 10(1), 10(3) | Enregistrement et analyse centralisés des SASE |
| Continuité des activités avec possibilité de basculement | Art. 11(6)(a) | SD-WAN avec basculement de liaison |
| Contrôle de l’accès des tiers et audit | Art. 28, 30 | ZTNA avec enregistrement des sessions et accès limité dans le temps |
| classification et notification des incidents dans les 4 heures | Art. 19 | Journalisation unifiée avec intégration SIEM |
Le paysage des menaces exige de l’action et non de la planification
Les chiffres parlent d’eux-mêmes. Le rapport Finance Sector Threat Landscape de l’ENISA, publié en février 2025, fait état de 488 incidents signalés publiquement qui ont affecté les services financiers européens entre janvier 2023 et juin 2024. Les banques ont absorbé 46 % de toutes les attaques. Le DDoS était le type de menace le plus répandu, avec des attaques atteignant 1 Tbps contre des cibles comprenant des banques et des associations financières européennes.
Le vecteur de risque tiers spécifiquement ciblé par DORA est déjà la voie d’attaque dominante. Banco Santander a révélé en mai 2024 qu’une base de données hébergée par un tiers avait exposé les données de clients de trois pays. Le même mois, ABN Amro a été victime d’une attaque par ransomware de la chaîne d’approvisionnement par l’intermédiaire du fournisseur AddComm. La panne de CrowdStrike en juillet 2024 a touché des banques comme UBS et Deutsche Bank, exposant le risque de concentration des TIC à grande échelle.
Les institutions belges sont confrontées aux mêmes pressions. La banque Crelan a perdu environ 70 millions d’euros dans une fraude BEC qui reste l’une des plus importantes d’Europe. Degroof Petercam a connu une fuite de données d’initiés en 2022 lorsqu’un ancien employé a exfiltré des informations sur ses clients. Le Centre belge de cybersécurité a enregistré 120 cas uniques de ransomware en 2024, soit une hausse de 24 % d’une année sur l’autre.
L’impact financier renforce l’urgence. Le rapport d’IBM sur le coût des violations de données estime que les violations dans les services financiers coûtent en moyenne 6,08 millions de dollars, soit 22 % de plus que la moyenne mondiale. Selon Sophos, les ransomwares toucheront 65 % des entreprises financières en 2024, avec des coûts de récupération moyens de 1,53 million de dollars, sans compter les paiements de rançon.
Il ne s’agit pas de scénarios de risque abstraits. Il s’agit de la réalité opérationnelle pour laquelle le DORA a été conçu.
Comment chaque composante de SASE résout un problème de services financiers
ZTNA remplace le VPN pour l’accès réglementé
Les VPN traditionnels offrent un large accès au niveau du réseau. Une fois connecté, un utilisateur ou un pirate peut se déplacer latéralement dans les systèmes de négociation, les bases de données bancaires centrales et les dossiers des clients. ZTNA fournit un accès au niveau de l’application : chaque session est authentifiée individuellement avec MFA et la vérification de la position de l’appareil, puis l’accès n’est accordé qu’à l’application spécifique demandée.
Pour une société de gestion de patrimoine, cela signifie que les conseillers se connectent directement à leur système de gestion de portefeuille et à leur CRM sans jamais rejoindre le réseau de l’entreprise. Les systèmes bancaires de base deviennent invisibles aux scanners de ports. L’accès des administrateurs à l’infrastructure du réseau nécessite des rôles distincts avec une authentification progressive et des sessions limitées dans le temps. Un gestionnaire de patrimoine belge a réduit la latence de l’accès à distance de 85 ms à 12 ms après avoir migré du VPN au SASE.
L’accès des tiers est particulièrement important dans le cadre de DORA. Les auditeurs externes et les régulateurs peuvent accéder à des applications spécifiques par le biais de portails basés sur un navigateur. Aucun client VPN, aucune installation d’agent, aucun appareil d’entreprise n’est nécessaire. Les sessions sont enregistrées et limitées dans le temps. À la fin de la mission, l’accès est automatiquement révoqué.
SWG protège contre l’exfiltration de données et le phishing
Les campagnes d’hameçonnage dans le secteur des services financiers sont très ciblées. Les attaquants se font passer pour des flux de travail internes d’approbation de virements, des portails bancaires et des organismes de réglementation. Une passerelle Web sécurisée inspecte l’ensemble du trafic Web, bloque les domaines malveillants connus et utilise l’analyse ML pour identifier les pages de collecte d’informations d’identification de type « zero-day ».
Les fonctionnalités DLP intégrées détectent les modèles de données financières en transit : numéros de compte, informations confidentielles, modèles de négociation exclusifs et correspondance avec les clients. Les contrôles tenant compte de l’instance font la distinction entre l’instance SharePoint de l’entreprise et un compte Dropbox personnel, bloquant ainsi le mouvement de données sensibles vers des destinations non approuvées. Cela s’attaque directement à l’informatique parallèle, un problème dans lequel les entreprises utilisent en moyenne plus de 2 000 applications, dont plus de 60 % n’ont pas été approuvées par le service informatique.
Le SD-WAN transforme la connectivité des succursales
Les institutions financières qui disposent de plusieurs bureaux de conseil, d’agences bancaires ou de sièges régionaux s’appuient généralement sur des circuits MPLS coûteux. Le SD-WAN offre une diversité de transport en augmentant ou en remplaçant le MPLS par des connexions à large bande et 4G/5G. Les institutions financières font état d’une réduction de 30 à 50 % des coûts de connectivité.
Le routage adapté aux applications garantit la qualité de service pour les applications de trading avec des exigences strictes en matière de latence, la vidéoconférence pour les réunions avec les clients et la VoIP pour les opérations des centres d’appels. Pour la plupart des entreprises financières de taille moyenne, l’approche recommandée consiste à conserver le MPLS pour les flux critiques tels que la messagerie SWIFT, tandis que le SD-WAN gère le trafic quotidien.
Le positionnement de l’appareil crée un accès différencié
La DORA exige un accès limité aux fonctions légitimes et approuvées. L’application de la posture de l’appareil traduit cela dans la pratique avec un modèle à plusieurs niveaux. Les appareils conformes et entièrement gérés bénéficient d’un accès total aux applications autorisées. Les appareils gérés mais non conformes reçoivent un accès limité avec des invites de remédiation. Les appareils BYOD non gérés, fréquents lors de la visite d’auditeurs ou de régulateurs, se connectent via des portails basés sur un navigateur, sans téléchargement de données et avec un enregistrement complet de la session. Les appareils non conformes sont totalement interdits d’accès.
La question de la souveraineté des données que les services financiers ne peuvent ignorer
L’article 30 de la loi DORA exige une transparence contractuelle sur la localisation des données et les juridictions de traitement. Pour les institutions qui utilisent des fournisseurs de SASE basés aux États-Unis, cela crée une tension structurelle. Le US CLOUD Act oblige les entreprises américaines à produire des données stockées n’importe où dans le monde lorsqu’elles font l’objet d’une demande valide de la part des autorités américaines chargées de l’application de la loi.
La distinction entre « hébergé dans l’UE » et « contrôlé par l’UE » devient une exigence d’approvisionnement dans les services financiers européens. Les données traitées sur des serveurs européens exploités par une société mère américaine relèvent toujours de la juridiction américaine. Un fournisseur de SASE ayant son siège en Europe élimine totalement ce risque. Il ne s’agit pas d’une déclaration politique. Il s’agit d’une simple gestion des risques dans le cadre des dispositions de la loi DORA relatives aux tiers.
La tendance réglementaire européenne renforce cette orientation. La déclaration de novembre 2025 de l’UE sur la souveraineté numérique européenne, l’examen minutieux des fournisseurs américains de services d’informatique en nuage en vertu de la loi sur les marchés numériques (Digital Markets Act) et la réalité opérationnelle des audits par des tiers (DORA) vont tous dans le même sens.
Mise en œuvre progressive de SASE pour les services financiers de taille moyenne
Le déploiement de SASE ne nécessite pas de tout remplacer en même temps. Une approche progressive permet d’améliorer la conformité à chaque étape tout en maintenant les opérations en contact avec les clients. Pour les institutions de taille moyenne comptant de 50 à 400 utilisateurs, le calendrier s’étend généralement sur six à douze mois.
Phase 1 : évaluation et intégration de l’identité (4 à 6 semaines)
Cartographier l’architecture réseau existante, les outils de sécurité et les schémas d’accès des utilisateurs. Inventorier toutes les applications financières : banque centrale, trading, SWIFT, CRM, conformité et systèmes de reporting. Intégrez votre fournisseur d’identité et synchronisez les groupes d’utilisateurs avec les rôles de l’entreprise. Définissez des lignes de base pour la posture des appareils gérés.
Phase 2 : Essai pilote avec accès à distance (4 à 8 semaines)
Publier deux ou trois applications à forte utilisation par l’intermédiaire de ZTNA pour les conseillers et les employés à distance. Exécutez VPN et ZTNA en parallèle pendant le projet pilote. Activez une politique de base pour la passerelle Web sécurisée qui bloque les domaines malveillants connus. Mesurez la latence, le taux de réussite de l’authentification et le volume des tickets d’assistance.
Phase 3 : Extension aux branches et à la sécurité web (8 à 16 semaines)
Déployez le SD-WAN dans les succursales, en commençant par les sites non critiques. Étendez le ZTNA à toutes les applications professionnelles. Activez le SWG complet avec l’inspection TLS lorsque cela est légal et approprié, ainsi que les politiques DLP pour les données financières sensibles. Déployez l’isolation en ligne pour les appareils sans agent : imprimantes, scanners et équipements de salle de réunion dans les espaces de bureaux partagés.
Phase 4 : Déclassement de l’héritage et rapports de conformité (4 à 8 semaines)
Retirer les concentrateurs VPN une fois la couverture ZTNA achevée. Supprimer progressivement les circuits MPLS à mesure que le SD-WAN s’avère stable, en conservant des circuits dédiés à SWIFT si nécessaire. Mettre hors service les dispositifs de pare-feu sur site. Configurer l’intégration SIEM et les rapports de conformité automatisés alignés sur les délais de signalement des incidents du DORA.
Une société belge de gestion de patrimoine a réalisé cette migration en huit semaines, ce qui a permis de réduire de 58 % les coûts totaux de sécurité tout en simplifiant la conformité aux normes DORA et NIS2.
Preuve de conformité DORA que SASE génère automatiquement
Les auditeurs attendent des preuves, pas des promesses. Une plateforme SASE unifiée génère la documentation exigée par la DORA sans corrélation manuelle des journaux entre plusieurs systèmes.
la gestion des risques liés aux TIC (articles 5 à 16). La plateforme fournit un cadre documenté couvrant l’identification, la protection, la détection, la réponse et la récupération. Les politiques de contrôle d’accès, les règles de posture des appareils et les configurations de sécurité web sont contrôlées par version avec des horodatages et des identités d’approbateurs.
Rapports d’incidents (articles 17 à 23). L’enregistrement centralisé avec alerte en temps réel permet une classification rapide des incidents. Lorsque quelque chose se produit, l’équipe établit une chronologie unique des événements indiquant quel utilisateur, à partir de quel appareil, a accédé à quelle application, à quelle heure et à partir de quel endroit. Cela permet de répondre à l’exigence de notification initiale dans les quatre heures.
Test de résilience (articles 24 à 27). La sécurité gérée dans le nuage avec des mises à jour continues réduit la surface d’attaque qui doit être testée. La visibilité centralisée simplifie le processus de délimitation du champ d’application et d’établissement de rapports pour les évaluations annuelles des vulnérabilités et, pour les institutions d’importance systémique, les tests de pénétration basés sur les menaces dans le cadre de TIBER-EU.
Gestion des risques pour les tiers (articles 28 à 44). Le registre d’information, dont la première échéance est le 30 avril 2025, exige de documenter tous les contrats de TIC avec des tiers. Une plateforme SASE à fournisseur unique simplifie cette tâche en consolidant plusieurs contrats de produits ponctuels en un seul. L’enregistrement des sessions et les pistes d’audit pour l’accès des tiers soutiennent les exigences de surveillance du DORA.
Partage d’informations (article 45). L’intégration du SIEM permet de participer à l’échange de renseignements sur les menaces spécifiques au secteur sans exposer les données brutes des clients.
Le contexte belge des services financiers
Le modèle belge « Twin Peaks » répartit la surveillance financière entre la BNB et la FSMA. Cinq institutions importantes sont directement supervisées par la BCE, tandis que 17 institutions moins importantes relèvent de la surveillance de la BNB. Outre les grandes banques, il existe un marché intermédiaire important : des banques privées comme Delen, J. Van Breda et Degroof Petercam ; des banques coopératives comme Crelan ; et une série d’assureurs et d’intermédiaires financiers.
La Belgique a été le premier État membre de l’UE à transposer le NIS2 en droit national. Le projet de loi d’application de la loi DORA a été adopté le 30 janvier 2025 et prévoit des amendes pouvant aller jusqu’à 10 % du chiffre d’affaires de l’entreprise ou 5 millions d’euros. La BNB a publié en février 2025 des circulaires relatives à la déclaration d’incidents et à l’inscription au registre des informations.
Les enquêtes de la FSMA ont révélé des progrès dans l’évaluation des risques liés aux TIC, mais des lacunes persistantes dans la réponse aux incidents, les tests et la gestion des risques par des tiers. Ce sont précisément ces capacités qu’offre une plateforme SASE unifiée. Pour les institutions financières belges qui se préparent à leur première évaluation de conformité DORA, la liste de contrôle de conformité NIS2 fournit un cadre de départ pratique, étant donné que de nombreux contrôles NIS2 se chevauchent avec les exigences DORA.
Les actifs financiers des ménages belges dépassent 1 500 milliards d’euros, ce qui fait de la gestion de patrimoine un segment important. Les banques privées et les gestionnaires de patrimoine indépendants qui gèrent des actifs de 100 millions à 1 milliard d’euros représentent le profil classique du marché intermédiaire : ils sont réglementés, gèrent des données sensibles, exploitent des effectifs hybrides répartis dans plusieurs bureaux de conseil et sont de plus en plus ciblés par des acteurs de menaces sophistiquées.
Comment Jimber rend SASE utilisable pour les services financiers
Jimber propose Real SASE dans une plateforme unique gérée dans le nuage, conçue pour les organisations européennes du marché intermédiaire et les partenaires de services qui les soutiennent.
Zero Trust Network Access fournit un accès granulaire par application avec une vérification de l’identité et de la position de l’appareil. Les conseillers accèdent à leur système de portefeuille. Les responsables de la conformité accèdent à leurs outils de reporting. Personne n’accède au réseau.
Secure Web Gateway et Firewall-as-a-Service appliquent des contrôles web cohérents avec blocage des menaces, inspection TLS et DLP. Les politiques suivent les utilisateurs, qu’ils se connectent depuis le siège, une succursale ou leur domicile.
Le SD-WAN offre une connectivité résiliente et performante entre les bureaux de conseil et les succursales, sans le coût d’un réseau MPLS dédié à chaque site.
Le matériel NIAC fournit une isolation en ligne pour les appareils sans agent. Les imprimantes, les scanners et les systèmes de salles de réunion dans les bureaux de services financiers partagés sont des points aveugles courants. Sans isolation, ils se trouvent sur le même réseau que les stations de travail qui traitent les données des clients. Jimber comble cette lacune sans nécessiter d’agents sur des appareils qui ne peuvent pas les exécuter.
La plateforme a son siège en Belgique et le traitement des données se fait au sein de l’Union européenne. Pas de société mère américaine. Pas d’exposition juridictionnelle au CLOUD Act. Pour les institutions financières où les dispositions de la loi DORA relatives aux tiers font de la souveraineté des données une exigence en matière de passation de marchés, ce point est important.
La tarification transparente par utilisateur facilite les projections de coût total de possession sur trois ans. Pas de supplément de bande passante, pas d’ajouts cachés. Les partenaires de service peuvent créer des packages de sécurité gérés avec des marges claires et des économies prévisibles.
Vous êtes prêt à voir comment Jimber répond à vos exigences de conformité DORA ? Réservez une démonstration et découvrez un plan de déploiement pour votre environnement de services financiers.
FAQ
SASE est-il adapté aux banques et aux gestionnaires de patrimoine du marché intermédiaire ?
Oui. Les institutions financières du marché intermédiaire sont souvent mieux positionnées pour le SASE que les grandes banques, car elles ont moins de complexité à démêler. Une plateforme unifiée remplace les piles fragmentées que les petites équipes informatiques ont du mal à gérer. Le déploiement prend généralement de six à douze mois, avec une approche progressive.
Comment SASE contribue-t-il à la mise en conformité avec la loi DORA ?
SASE répond aux cinq piliers de DORA. La ZTNA et l’application de la posture des appareils satisfont aux exigences de l’article 9 en matière de contrôle d’accès. Le FWaaS assure la segmentation du réseau exigée par l’article 9. La journalisation centralisée permet de respecter le délai de quatre heures pour la notification d’un incident. Enfin, une plateforme européenne à fournisseur unique simplifie le registre des informations et les obligations de gestion des risques des tiers, conformément aux articles 28 à 44.
SASE remplace-t-il nos pare-feux existants ?
Pas nécessairement dès le premier jour. La plupart des institutions financières utilisent SASE parallèlement aux pare-feu existants pendant la transition. Le FWaaS fourni dans le nuage prend progressivement en charge l’application des politiques à mesure que le ZTNA supprime le besoin d’accès au niveau du réseau. Les pare-feu des succursales sont généralement les premiers à être mis hors service, car le SD-WAN fournit une connectivité sécurisée.
Qu’en est-il de SWIFT et de l’intégration des systèmes de négociation ?
L’approche recommandée conserve des circuits dédiés pour le transport de la messagerie SWIFT, tandis que SASE gère le contrôle d’accès des utilisateurs et l’application des politiques. ZTNA fournit un accès à moindre privilège aux interfaces SWIFT (Alliance Access, Alliance Lite2) avec une authentification progressive et l’enregistrement de la session, prenant en charge les contrôles du CSP 2025 de SWIFT.
Comment la souveraineté européenne en matière de données affecte-t-elle la sélection des fournisseurs de SASE dans le cadre de DORA ?
L’article 30 de la loi DORA exige la transparence contractuelle sur les lieux de traitement des données et impose des stratégies de sortie. Les fournisseurs de SASE ayant leur siège aux États-Unis sont soumis à la loi CLOUD, qui peut contraindre à la production de données indépendamment de l’endroit où elles sont stockées. Un fournisseur ayant son siège en Europe élimine ce conflit juridictionnel, ce qui simplifie l’évaluation des risques pour les tiers et la documentation du registre d’information.
Notre MSP peut-il gérer SASE pour nous ?
Oui. Une plateforme SASE multi-locataires permet aux partenaires de services de gérer la sécurité de plusieurs clients de services financiers à partir d’une console unique. Ce modèle est courant sur le marché intermédiaire, où environ 63 % des organisations font appel à un MSP pour le déploiement de SASE. Le modèle de tarification transparent et l’architecture API-first permettent d’offrir des services gérés évolutifs.
