Le modèle de sécurité par périmètre est mort. En banque et fintech, les applications sont dans le cloud, les collaborateurs travaillent à distance, les APIs connectent des tiers, et les réglementations exigent une résilience numérique démontrable. Le Zero Trust n’est plus une option — c’est le cadre de sécurité que les régulateurs attendent.
Pourtant, la plupart des établissements financiers vivent encore sur un modèle hérité : un pare-feu en périphérie, un VPN d’accès distant, et une confiance implicite une fois à l’intérieur. Ce modèle est précisément ce que DORA, NIS2 et l’ANSSI remettent en cause.
Ce guide vous explique comment déployer le Zero Trust dans un environnement bancaire, en conformité avec les exigences réglementaires, sans paralyser les métiers.
Pourquoi le périmètre ne suffit plus
L’érosion du château fort
Le modèle traditionnel repose sur une métaphore obsolète : le château fort. Un mur épais (pare-feu) entoure les actifs précieux. Tout ce qui est à l’intérieur est considéré comme sûr. Le problème : dans le secteur financier contemporain, il n’y a plus de mur.
| Réalité bancaire | Consequence sur le périmètre |
|---|---|
| 60 % des collaborateurs en hybride | Le VPN est le nouvel axe d’attaque |
| APIs ouvertes (PSD2, Open Banking) | Les tiers accèdent aux données sensibles |
| Multi-cloud et SaaS | Les données sortent du périmètre |
| Fournisseurs ICT (DORA) | La chaîne d’approvisionnement est une surface d’attaque |
| BYOD et terminaux personnels | L’endpoint n’est plus contrôlé |
Résultat : 80 % des violations de données dans le secteur financier impliquent des credentials compromis utilisés depuis l’intérieur du périmètre (rapport Verizon DBIR 2025).
Ce que disent les réglementations
DORA (Art. 5) exige une gestion des risques ICT incluant « les risques liés aux fournisseurs tiers de services ICT ». En pratique, DORA impose de ne pas faire confiance par défaut — ce qui est la définition même du Zero Trust.
NIS2 (Art. 21) exige des « politiques de sécurité de l’information » et des « mesures de gestion des risques » couvrant toute la chaîne d’approvisionnement.
RGPD (Art. 32) exige que les mesures techniques soient « adaptées au risque » — ce qui signifie une évaluation continue, pas une validation ponctuelle.
ANSSI : le guide d’hygiène informatique recommande explicitement le principe du moindre privilège et l’authentification multifacteur, deux piliers du Zero Trust.
Zero Trust : les 5 principes fondamentaux
1. Ne jamais faire confiance, toujours vérifier
Chaque accès — humain, machine ou service — doit être authentifié, autorisé et chiffré avant d’obtenir l’accès à une ressource. Il n’y a pas de réseau « interne » sûr par défaut.
En pratique :
- Authentification multifacteur (MFA) obligatoire pour tous les utilisateurs
- Certificats mutuels (mTLS) pour les communications service-à-service
- Tokens à durée de vie courte pour les APIs
2. Moindre privilège
Chaque utilisateur, chaque service, chaque application n’accède qu’aux ressources strictement nécessaires à sa fonction — et seulement pour la durée nécessaire.
En pratique :
- RBAC (Role-Based Access Control) avec profils métiers fins
- Just-in-time access : élévation de privilèges temporaire et traçée
- Service accounts avec permissions minimales
3. Micro-segmentation
Au lieu d’un grand réseau plat « de confiance », on divise l’infrastructure en zones isolées. Si un attaquant compromised un service, il ne peut pas se déplacer latéralement.
En pratique :
- Network policies par application (CiliumNetworkPolicy dans Kubernetes)
- VLANs dédiés par sensibilité des données
- Pare-feu applicatif (WAF) entre les zones
4. Visibilité et analyse continue
Le Zero Trust n’est pas un état — c’est un processus continu. Chaque accès est journalisé, chaque anomalie est analysée, chaque comportement suspect déclenche une alerte.
En pratique :
- Surveillance des connexions et accès en temps réel (Grafana + Loki)
- Détection d’anomalies comportementales (UEBA)
- Audit trail complet et ingérable
5. Chiffrement de bout en bout
Les données sont chiffrées au repos et en transit — y compris à l’intérieur du réseau. Le réseau interne est traité comme hostile.
En pratique :
- TLS 1.3 pour toutes les communications internes
- Chiffrement au repos avec gestion des clés (Vault)
- Rotation automatique des certificats
Architecture Zero Trust pour le secteur financier
Vue d’ensemble
┌─────────────────────────────────────────────────┐
│ IDENTITY PROVIDER │
│ (OIDC/SAML + MFA + SSO) │
└───────────┬──────────────┬──────────────────────┘
│ │
┌───────▼──────┐ ┌─────▼────────┐
│ POLICY │ │ POLICY │
│ ENGINE │ │ ENGINE │
│ (Accès users)│ │(Accès services)│
└───────┬──────┘ └─────┬────────┘
│ │
┌───────▼──────────────▼──────────┐
│ ZERO TRUST PROXY │
│ (Traefik + WAF + mTLS) │
└──┬─────┬─────┬─────┬─────┬──────┘
│ │ │ │ │
┌──▼─┐┌──▼─┐┌──▼─┐┌──▼─┐┌──▼──┐
│Core││Risq││Pai ││API ││Data │
│Bank││Comp││ement││Open││Lake │
└────┘└────┘└────┘└────┘└─────┘Chaque macro-service est dans une zone micro-segmentée. L’accès est contrôlé par le Policy Engine, pas par la position dans le réseau.
Composants de la stack Zero Trust Cloud Inspire
| Composant | Outil | Rôle Zero Trust |
|---|---|---|
| Identity Provider | Keycloak | OIDC/SAML, MFA, SSO fédéré |
| Policy Engine | OPA (Open Policy Agent) | Autorisation fine, policies as code |
| Proxy ZT | Traefik + Coraza WAF | Routage, terminaison TLS, inspection L7 |
| mTLS | Vault PKI | Certificats mutuels, rotation automatique |
| Micro-segmentation | CiliumNetworkPolicy | Isolation réseau dans Kubernetes |
| Observabilité | Grafana + Prometheus + Loki | Visibilité continue, audit trail |
| Secrets | HashiCorp Vault | Gestion centralisée, rotation automatique |
Déploiement Zero Trust en 4 phases
Phase 1 : Identité et accès (Semaines 1-3)
La fondation du Zero Trust est l’identité. Avant de cloisonner le réseau, il faut savoir qui accède à quoi.
- Déployer un Identity Provider fédéré (Keycloak)
- Activer la MFA pour tous les utilisateurs (TOTP + WebAuthn)
- Mapper les profils métiers aux permissions (RBAC)
- Configurer le SSO pour éliminer les mots de passe multi-applications
Livrable : 100 % des utilisateurs en MFA, SSO unifié
Phase 2 : Micro-segmentation (Semaines 4-6)
Isoler les workloads par niveau de sensibilité :
- Zone critique : core banking, gestion des risques, paiements
- Zone sensible : CRM, reporting, conformité
- Zone standard : bureautique, communication interne
- Zone DMZ : APIs exposées, portails clients, Open Banking
Chaque zone a ses propres network policies. Le trafic entre zones passe par le Zero Trust Proxy (Traefik + WAF).
Livrable : 4 zones isolées, trafic inter-zones contrôlé
Phase 3 : Chiffrement et certificats (Semaines 7-9)
Déployer le chiffrement de bout en bout :
- mTLS entre tous les services internes
- Vault PKI pour la gestion automatisée des certificats
- Rotation automatique (durée de vie : 24h pour les certificats internes)
- Chiffrement au repos pour toutes les bases de données sensibles
Livrable : 100 % du trafic interne en mTLS, rotation automatique active
Phase 4 : Observabilité et remédiation (Semaines 10-12)
Rendre le Zero Trust visible et réactif :
- Dashboards Grafana : accès par zone, tentatives d’authentification, anomalies
- Alertes : comportements suspects (élévation de privilèges, accès hors horaires, volume anormal)
- Audit trail : chaque accès journalisé, traçable, ingérable
- Remédiation : blocage automatique des credentials compromis
Livrable : tableau de bord Zero Trust, alertes configurées, audit trail continu
Zero Trust et conformité : le mapping réglementaire
DORA : résilience opérationnelle
| Exigence DORA | Réponse Zero Trust |
|---|---|
| Art. 5 — Gestion des risques ICT | Threat modeling continu, policies as code |
| Art. 9 — Protection des données | Chiffrement bout en bout, moindre privilège |
| Art. 10 — Gestion des incidents | Détection comportementale, audit trail |
| Art. 28-44 — Fournisseurs tiers | Pas de confiance par défaut, évaluation continue |
| Art. 25-27 — Tests de résilience | Red teaming contre les policies ZT |
NIS2 : cybersécurité des réseaux
| Exigence NIS2 | Réponse Zero Trust |
|---|---|
| Art. 21 — Politiques de sécurité | Policies as code, gouvernance automatisée |
| Art. 21 — Gestion des incidents | Détection temps réel, escalades automatisées |
| Art. 21 — Chaîne d’approvisionnement | Évaluation continue des tiers, mTLS |
RGPD : protection des données
| Principe RGPD | Réponse Zero Trust |
|---|---|
| Minimisation des données | Moindre privilège d’accès |
| Intégrité et confidentialité | Chiffrement, micro-segmentation |
| Sécurité par design | Zero Trust by design |
| Droit à l’oubli | Audit trail, gestion des accès révocable |
Les obstacles réels au Zero Trust (et comment les surmonter)
« Ça va ralentir nos applications »
Faux. Le Zero Trust bien implémenté utilise le mTLS et les tokens JWT — des mécanismes plus rapides que les VPN traditionnels. Les latences observées avec la stack Cloud Inspire sont inférieures à 5 ms par saut de proxy.
« C’est trop complexe pour nos équipes »
Le Zero Trust est un parcours, pas un big bang. On commence par la MFA et le SSO (phase 1), puis on itère. Les équipes ne changent pas de méthodologie — elles gagnent en visibilité.
« Nos applications legacy ne supportent pas le mTLS »
C’est le cas le plus courant. Solution : un proxy sidecar (Traefik) qui gère la terminaison mTLS à la place de l’application. L’application ne change pas, le réseau se sécurise.
« Le budget ne suit pas »
Le Zero Trust réduit les coûts de sécurité à moyen terme :
| Poste | Avant ZT | Après ZT | Économie |
|---|---|---|---|
| Licences VPN | 15-30 K€/an | 0 K€ | -100 % |
| Incidents de sécurité | 50-200 K€/an | 5-20 K€/an | -80 % |
| Audits de conformité | 40 K€/an | 10 K€/an | -75 % |
| Gestion des certificats | 8 K€/an | Automatisé | -100 % |
ROI typique : 18 mois pour une banque moyenne, 12 mois pour une fintech agile.
Cas d’usage : fintech en hyper-croissance
Profil : Fintech africaine, 200 employés, 500 K clients, croissance 150 %/an
Problème : L’infrastructure a été construite pour 50 personnes. Les développeurs ont un accès root partout. Les APIs partagent des tokens sans expiration. L’auditeur DORA arrive dans 3 mois.
Déploiement Zero Trust en 12 semaines :
- Semaines 1-3 : Keycloak + MFA pour tous. Fin des comptes partagés. SSO unifié.
- Semaines 4-6 : 4 zones de micro-segmentation. Les développeurs n’ont plus accès à la production par défaut.
- Semaines 7-9 : mTLS interne. Les APIs utilisent des tokens JWT à durée de vie courte (15 min). Les tokens sans expiration sont révoqués.
- Semaines 10-12 : Dashboards de supervision. Audit trail continu. L’auditeur DORA reçoit un rapport automatique.
Résultat :
- MFA à 100 % ✅
- Élévation de privilèges temporaire seulement ✅
- Aucun token sans expiration ✅
- Audit trail DORA-ready ✅
- Temps de détection d’intrusion : de 72h à 5 min ✅
Outils du trade : stack Zero Trust open source
La stack Cloud Inspire est 100 % open source — pas de vendor lock-in sur la sécurité :
| Fonction | Outil | Licence |
|---|---|---|
| Identity & Access | Keycloak | Apache 2.0 |
| Policy Engine | OPA | Apache 2.0 |
| WAF | Coraza | Apache 2.0 |
| Proxy ZT | Traefik | MIT |
| PKI / Certificats | HashiCorp Vault | BSL / MPL 2.0 |
| Micro-segmentation | Cilium | Apache 2.0 |
| Observabilité | Grafana + Prometheus + Loki | AGPL / Apache 2.0 |
| SIEM | Wazuh | GPLv2 |
Pourquoi l’open source : en secteur financier, la sécurité par obscurité n’est pas une stratégie. Les outils open source sont audibles, vérifiables et communautairement éprouvés. C’est aussi ce que recommande l’ANSSI pour les Infrastructures Critiques.
Par où commencer demain
Quick win : la MFA
Si vous ne faites qu’une chose ce trimestre, activez la MFA pour tous les utilisateurs. C’est la mesure la plus impactante et la moins coûteuse. Keycloak le fait en une journée.
Quick win : l’audit des accès
Listez tous les comptes avec des privilèges élevés. Vous serez surpris du nombre de comptes dormants, de comptes partagés et de permissions excédentaires. Nettoyer l’existant est la moitié du travail.
Quick win : les tokens d’API
Vérifiez les durées de vie des tokens d’API dans votre infrastructure. Si un token vit plus d’une heure sans rotation, c’est un risque.
Conclusion
Le Zero Trust n’est pas un produit — c’est un cadre de pensée qui aligne votre sécurité sur la réalité de votre infrastructure. En banque et fintech, où la confiance est la monnaie la plus précieuse, ne plus faire confiance par défaut est paradoxalement la meilleure stratégie.
Les réglementations (DORA, NIS2, RGPD) convergent vers les mêmes principes : vérification continue, moindre privilège, traçabilité. Le Zero Trust est la traduction technique de ces exigences.
Cloud Inspire déploie une stack Zero Trust 100 % open source en 12 semaines, conforme DORA et NIS2, sur votre cloud privé OpenNebula. Si vous êtes un DSI du secteur financier qui veut sécuriser sans paralyser, parlons-en.