DORA et résilience opérationnelle numérique financière

DORA et résilience opérationnelle numérique financière

DORA (Digital Operational Resilience Act) impose aux entités financières de démontrer que leurs services numériques résistent, se dégradent de façon maîtrisée et reviennent à un état exploitable après incident. Le texte ne transforme pas une architecture fragile en forteresse par décret : il force à identifier les dépendances, tester les ruptures et produire des preuves d’exploitation.

Explication de la marmotte

DORA ressemble au règlement qui oblige une banque à vérifier que ses guichets, ses dossiers et ses moyens de paiement continuent de fonctionner pendant une panne, un incendie ou une attaque. Le but n’est pas d’empêcher tous les problèmes, mais d’éviter qu’un problème numérique bloque durablement l’argent et les services.

→ Lire l’explication complète de la marmotte

DORA : le compromis entre résilience et complexité contrôlée

DORA s’applique depuis le 17 janvier 2025 aux entités financières relevant du périmètre de l’Union européenne (UE), ainsi qu’à une partie de leurs prestataires tiers de services de technologies de l’information et de la communication (TIC). Le sujet n’est donc pas seulement la cybersécurité. Une indisponibilité causée par une erreur de déploiement, une saturation réseau, une dépendance cloud indisponible ou un certificat expiré entre dans le problème.

Le compromis central est net : gagner une capacité de continuité vérifiable exige de payer en architecture, en discipline d’exploitation et en dette organisationnelle visible. La recommandation est de construire les contrôles autour des services critiques et de leurs dépendances réelles, pas autour d’une collection de politiques générales. Une matrice de risques sans inventaire de flux et de dépendances est un document décoratif. Décoratif, mais avec davantage de comités.

DORA attend cinq capacités qui doivent converger :

1. la gestion du risque lié aux TIC ;
2. la gestion et la notification des incidents ;
3. les tests de résilience opérationnelle numérique ;
4. la maîtrise du risque de prestataires tiers ;
5. le partage encadré d’informations sur les menaces.

Le règlement ne garantit ni l’absence d’incident ni la conformité technique de chaque application. Il ne garantit pas non plus qu’un fournisseur cloud restaurera plus vite qu’il ne l’annonce. La résilience dépend encore de l’architecture, des contrats, des procédures réellement exécutables et des données de restauration disponibles.

La responsabilité de l’organe de direction est structurante. Elle impose que les arbitrages de risque soient traçables : accepter un point unique de défaillance, reporter un test de reprise ou conserver une dépendance non substituable sont des décisions de risque, pas des détails réservés à l’exploitation. La page gouvernance couvre le cadre de pilotage ; DORA ajoute l’obligation de relier ce pilotage à des preuves techniques.

Gestion des risques TIC : partir des services, pas des outils

Un registre DORA exploitable commence par les fonctions métiers critiques, puis descend vers les applications, données, identités, flux réseau, plateformes et prestataires qui les rendent possibles. L’inverse échoue souvent : inventorier les pare-feu, les machines virtuelles et les licences donne une vue comptable, pas une carte de défaillance.

Pour chaque service critique, documenter au minimum :

• le propriétaire de service et le propriétaire de risque ;
• les objectifs de délai de reprise et de perte de données ;
• les dépendances internes et externes, y compris DNS (Domain Name System), messagerie, identité, horodatage et API (Application Programming Interface) ;
• les données manipulées et leur classification ;
• les comptes techniques, certificats et clés nécessaires au démarrage ;
• le mode dégradé autorisé et les opérations qui doivent être bloquées ;
• les métriques permettant de distinguer une lenteur d’une indisponibilité.

Le délai de reprise, souvent nommé RTO (Recovery Time Objective), fixe la durée maximale acceptable avant retour du service. Le point de reprise, ou RPO (Recovery Point Objective), fixe la quantité maximale de données perdables. Un RTO de deux heures avec une restauration de base de données qui nécessite six heures de relecture de journaux n’est pas un objectif ambitieux, c’est une contradiction avec un logo.

Les dépendances d’identité sont fréquemment sous-estimées. Une application peut disposer de trois zones actives, mais rester inutilisable si le fournisseur d’identité, le service de résolution de noms ou l’autorité de certification est indisponible. La fédération doit donc être testée avec les chemins de secours, les certificats de signature et les comptes d’administration hors bande. Les fondations sont détaillées dans architecture cyber et les enjeux d’accès dans identités.

La segmentation réseau réduit l’impact d’un mouvement latéral, mais ne remplace pas une stratégie de reprise. Une segmentation trop fine peut aussi bloquer la restauration si les flux de sauvegarde, les dépôts de paquets ou les services de noms ont été oubliés. Toute règle de filtrage nécessaire à la reprise doit être identifiée avant l’incident. Découvrir un flux au milieu d’une cellule de crise est un sport de contact peu rentable.

Incidents DORA, continuité et preuve de reprise

La gestion d’incident doit relier détection, qualification, confinement, notification, rétablissement et retour d’expérience. Les délais réglementaires et les critères de classification dépendent du type d’incident et du statut de l’entité ; ils demandent une lecture juridique et réglementaire propre à chaque organisation. L’architecture doit néanmoins fournir les faits nécessaires : horodatages fiables, périmètre touché, services affectés, volumes, mécanisme de compromission et état de rétablissement.

Les journaux doivent être centralisés, protégés contre l’altération et conservés selon une durée cohérente avec les enquêtes et les obligations internes. Une journalisation sans synchronisation de temps rend la chronologie incertaine. Un journal disponible seulement sur le système compromis n’est pas une preuve, c’est un souvenir.

La sauvegarde doit être séparée du plan de continuité. Une réplication synchrone propage efficacement une suppression malveillante, une corruption applicative ou un chiffrement par rançongiciel. Prévoir des copies immuables, des identifiants séparés, une restauration hors production et des tests de lisibilité. Le compte qui administre la production ne doit pas pouvoir supprimer sans contrôle les dernières copies restaurables.

Le mécanisme ne garantit pas qu’une sauvegarde contient un état sain. La restauration doit donc inclure des contrôles : intégrité des données, cohérence transactionnelle, analyse de logiciels malveillants, renouvellement des secrets exposés et validation fonctionnelle. Restaurer l’attaquant avec les données est une forme de haute disponibilité, mais personne n’avait demandé celle-là.

Tests de résilience opérationnelle numérique

Les tests doivent viser les scénarios qui cassent réellement les hypothèses d’architecture : perte d’une zone, indisponibilité du fournisseur d’identité, expiration de certificat, saturation d’un lien, corruption d’une sauvegarde, révocation d’un compte privilégié ou défaillance d’un prestataire SaaS (Software as a Service).

Un test utile produit trois résultats : un temps mesuré, des écarts documentés et des actions correctrices avec propriétaire et échéance. Un exercice qui se conclut par « procédure à améliorer » sans correction vérifiable doit être classé comme échec. C’est moins élégant dans le compte rendu, mais plus honnête pour le prochain incident.

Les entités concernées doivent aussi conduire, selon leur profil, des tests d’intrusion guidés par la menace, nommés TLPT (Threat-Led Penetration Testing). Ces exercices ne sont pas une campagne de scan déguisée avec une facture premium. Ils évaluent la capacité de détection et de réponse face à des chemins d’attaque plausibles, en évitant de mettre en danger la production et les tiers.

Les scénarios doivent inclure les mécanismes de sécurité eux-mêmes. Un coffre de secrets indisponible bloque les déploiements et parfois les redémarrages. Une infrastructure à clés publiques, ou PKI (Public Key Infrastructure), défaillante peut rendre les connexions internes impossibles malgré des applications intactes. La gestion des certificats et des autorités de certification est traitée dans PKI et TLS.

Exemple : vérifier une restauration avec des preuves horodatées

Le test suivant vérifie un service restauré depuis un environnement isolé. Il ne valide pas la totalité d’une reprise, mais établit une preuve minimale de disponibilité, de lecture applicative et de conservation des journaux. Les variables doivent pointer vers l’environnement de test, jamais vers la production par réflexe musculaire.

#!/usr/bin/env bash
# Vérifier un service restauré après chargement de données de sauvegarde.
# Pré-requis : curl, jq et un jeton de test à privilèges minimaux.
set -euo pipefail

export SERVICE_URL="https://restauration.exemple.interne"
export TEST_TOKEN="remplacer-par-un-jeton-de-test"
export EVIDENCE_DIR="./preuves-reprise/$(date -u +%Y%m%dT%H%M%SZ)"

mkdir -p "$EVIDENCE_DIR"

# Capturer l'état technique et échouer si le service ne répond pas en HTTPS.
curl --fail --silent --show-error \
  "$SERVICE_URL/health" \
  | jq . > "$EVIDENCE_DIR/health.json"

# Vérifier une donnée de contrôle créée avant la sauvegarde.
curl --fail --silent --show-error \
  -H "Authorization: Bearer $TEST_TOKEN" \
  "$SERVICE_URL/api/v1/transactions/controle-reprise" \
  | jq '.status, .updatedAt' > "$EVIDENCE_DIR/transaction-controle.txt"

# Figer l'horodatage et l'empreinte des preuves pour le dossier d'exercice.
sha256sum "$EVIDENCE_DIR"/* > "$EVIDENCE_DIR/SHA256SUMS.txt"
date -u --iso-8601=seconds > "$EVIDENCE_DIR/fin-test-utc.txt"

Le jeton de test doit être émis spécifiquement pour l’exercice, stocké dans un gestionnaire de secrets et révoqué après usage. La sortie doit être versée dans un espace de preuve protégé contre la modification par les opérateurs du test. Sinon, le contrôle confirme surtout que curl sait écrire dans un dossier.

Prestataires TIC et concentration de dépendances

DORA impose de traiter les prestataires TIC comme des éléments de l’architecture de résilience. Une clause contractuelle ne crée ni redondance ni capacité de sortie. La revue doit couvrir la localisation des données, les sous-traitants, les droits d’audit, les délais de notification, les engagements de restauration, la réversibilité et les dépendances techniques non documentées.

Le risque de concentration mérite une analyse spécifique. Trois applications hébergées chez trois fournisseurs différents peuvent dépendre du même opérateur DNS, de la même plateforme d’identité ou de la même région cloud. La diversité de factures n’est pas une diversité de défaillances.

Pour les services critiques, maintenir un plan de sortie techniquement crédible : formats exportables, procédures de récupération, dépendances de chiffrement, capacité réseau, licences, compétences et délai de reconstruction. Une clé de chiffrement détenue exclusivement par un prestataire rend toute réversibilité théorique. Une clé protégée dans un HSM (Hardware Security Module) avec procédures d’accès indépendantes peut réduire ce verrouillage, à condition que les applications sachent réellement l’utiliser ailleurs.

🐝 Ce qui arrive si on s’en passe

Sans ce dispositif, l’absence n’est pas silencieuse : elle se paie au moment où quelqu’un pousse la porte. Faute de registre reliant fonctions critiques et dépendances, l’ampleur d’un incident ne peut être qualifiée dans les délais attendus, et la déclaration part incomplète ou tardive. Faute de preuves horodatées et d’empreintes figées, les constats d’un exercice ou d’une crise ne sont plus opposables à un auditeur, un assureur ou un superviseur : il reste des récits. Faute de plan de sortie testé, la renégociation avec un prestataire s’ouvre sans levier, au tarif de l’urgence. Faute d’arbitrages tracés, un point unique de défaillance accepté un jour devient une caractéristique invisible du système, que personne ne réévalue et que personne n’assume lorsqu’il cède.

🦫 Explication de la marmotte 🍫

DORA est une règle européenne pour les organisations financières qui utilisent des systèmes numériques. Elle demande de savoir quels services sont indispensables, quelles données ils utilisent, quels fournisseurs les font fonctionner et qui peut les administrer. Cette liste doit aller des activités visibles, comme un paiement, jusqu’aux éléments moins visibles, comme la connexion des employés, la résolution des noms de machines et les sauvegardes.

L’organisation doit ensuite décider combien de temps un service peut rester arrêté et combien de données peuvent être perdues. Elle prépare des procédures pour détecter un problème, limiter ses effets, prévenir les personnes concernées, remettre le service en route et garder les preuves de ce qui s’est passé.

Les sauvegardes doivent être séparées des systèmes habituels. Elles doivent être testées, car une copie inutilisable ou contaminée ne permet pas de repartir. Les clés, mots de passe et certificats nécessaires au redémarrage doivent aussi rester disponibles sans donner trop de pouvoir à une seule personne.

Des exercices vérifient que les procédures fonctionnent réellement. Ils mesurent le temps de retour, contrôlent les données restaurées et révèlent les dépendances oubliées. Les fournisseurs informatiques font partie du contrôle : si un service extérieur tombe, il faut connaître les conséquences et disposer d’une solution de remplacement ou d’un plan de sortie.

À lire aussi

• Sécurité des systèmes bancaires et financiersLes systèmes bancaires et financiers combinent exigences PCI DSS, DORA, disponibilité continue et lutte antifraude temps réel.
• NIS2 entités essentielles, obligations, périmètre et sanctionsCe que la directive NIS2 impose aux entités essentielles (périmètre, mesures de l'article 21, notification d'incident, supervision et sanctions) lu depuis l'architecture.
• Tester une restauration après sinistre simuléGuide pratique pour préparer, exécuter et mesurer un test de restauration après un sinistre simulé dans un environnement isolé.
• Continuité, sauvegardes, PRA/PCA et haute disponibilitéRelier réseau, stockage, serveurs, sauvegardes et continuité d’activité pour concevoir des services résistants aux pannes, erreurs et incidents.

Pages voisines

La citent

• AI Act : articuler les obligations de sécurité avec NIS 2, le CRA et le RGPD
• AI Act : obligations du déployeur d'une IA à haut risque (article 26)
• Sécurité des systèmes bancaires et financiers
• Test d'intrusion : commander, cadrer et exploiter un pentest

DORA et résilience opérationnelle numérique financière

Elle cite

• ⇄Lien dans les deux sens :Délais de notification d’incident NIS2 RGPD DORA
• ⇄Lien dans les deux sens :Partager le renseignement sur la menace avec ISAC, MISP et STIX
• Sauvegarde immuable anti-ransomware et verrouillage WORM

⇄ : les deux pages se citent l’une l’autre.