DORA sur Azure
DORA sur Azure : les quatre piliers, et les preuves que chacun demande
DORA est, par construction, un régime continu : gestion permanente du risque ICT, tests de résilience obligatoires et registre de tiers à tenir à jour. Ce guide explique ce que chaque pilier attend d'un environnement Azure, et quelle part de ces preuves Cloudivence, anciennement Governator, lit déjà. La cartographie DORA elle-même figure sur la roadmap de Cloudivence.
Ce que DORA exige réellement de votre environnement Azure
Le règlement DORA (Règlement (UE) 2022/2554) est entré en application le 17 janvier 2025 pour les entités financières opérant dans l'UE : banques, assureurs, entreprises d'investissement, établissements de paiement, prestataires de services sur crypto-actifs et bien d'autres. Contrairement à NIS2, qui est transversal, DORA est sectoriel et explicitement prescriptif. Il définit quatre piliers que chaque entité concernée doit démontrer, ainsi qu'un cinquième volet sur le partage d'informations.
Sur Microsoft Azure, les briques sous-jacentes existent : Defender for Cloud, Sentinel, Azure Backup, Site Recovery, Lighthouse, ainsi que les logs d'activité et de coût. Ce qui n'existe pas par défaut, c'est la couche de preuves qui démontre, dans une forme exploitable par le régulateur, que les quatre piliers DORA fonctionnent en continu et que le registre de tiers est à jour.
Cloudivence ne rattache pas encore les constats aux articles DORA ; cela figure sur sa roadmap, avec le registre des tiers ICT et la trace des incidents. Il lit déjà une partie des preuves Azure dont dépendent le premier et le quatrième pilier, détaillée ci-dessous pilier par pilier.
Les quatre piliers sur Azure
Chaque pilier appelle ses propres preuves Azure. Pour chacun, le premier bloc indique ce que le pilier demande, et le second ce que Cloudivence lit aujourd'hui.
Cadre de gestion du risque ICT
Un cadre documenté et approuvé par la direction qui rattache les contrôles aux risques identifiés, avec revue périodique et entretien démontrable.
Preuves Azure attendues pour le pilier
Tableau de bord regulatory de Defender for Cloud, état de conformité Azure Policy, registre d'exemptions avec dates de revue, tendance du Secure Score.
Ce que Cloudivence lit aujourd'hui
Les recommandations Defender, la conformité Azure Policy et le Secure Score sont lus, et les exceptions de contrôle portent une date d'expiration. Les constats ne sont pas encore rattachés aux articles DORA.
Gestion et notification des incidents ICT
Classification, notification et analyse post-incident des incidents ICT majeurs dans les délais définis par le régulateur.
Preuves Azure attendues pour le pilier
Incidents Sentinel avec métadonnées de timeline, traces du workflow d'alertes Defender, attestations de runbooks, registre des comptes-rendus post-incident.
Ce que Cloudivence lit aujourd'hui
Non couvert. Cloudivence ne lit ni les incidents Sentinel ni leurs timelines.
Tests de résilience opérationnelle numérique
Tests scénarisés annuels pour les entités concernées, plus Threat-Led Penetration Testing (TLPT) tous les trois ans pour les entités significatives.
Preuves Azure attendues pour le pilier
Attestations des plans de test, matrice de couverture des scénarios, preuves d'actions correctives, résultats de retests datés.
Ce que Cloudivence lit aujourd'hui
Des attestations avec lien de preuve peuvent enregistrer un test par contrôle. Il n'existe pas de registre des tests DORA.
Gestion du risque ICT lié aux tiers
Un registre tenu à jour de tous les contrats ICT avec des tiers, incluant l'évaluation de criticité, la couverture contractuelle et les stratégies de sortie pour les fournisseurs critiques.
Preuves Azure attendues pour le pilier
Inventaire des service principals rattaché aux fournisseurs tiers, périmètre RBAC par fournisseur, registre des délégations Lighthouse, métadonnées contractuelles.
Ce que Cloudivence lit aujourd'hui
Les service principals disposant de rôles privilégiés sont listés, avec leur périmètre. Il n'existe ni registre des tiers ICT ni inventaire Lighthouse.
Pourquoi les preuves DORA doivent rester à jour
DORA a été conçu, dès le texte réglementaire, comme un régime continu. Le registre des tiers ne peut pas dater de douze mois. Les tests de résilience constituent une obligation récurrente, pas un projet. Les notifications d'incidents sont déclenchées par les événements, pas par le calendrier d'audit. Un modèle où l'on commande une évaluation de readiness tous les douze mois, où l'on récupère un nouveau PDF et où l'on accepte la dérive entre deux passages s'accorde mal avec cette régulation.
Un outillage qui conserve les preuves entre deux cycles convient mieux à cette forme qu'un instantané annuel, et c'est la direction que prend Cloudivence. Aujourd'hui, il couvre les éléments indiqués ci-dessus pour chaque pilier. Le registre des tiers, le registre des tests de résilience et les timelines d'incidents ne font pas encore partie du produit, et GenioCT les prend en charge en mission de conseil.
Ce que Microsoft fournit, et ce qu'il ne fournit pas
Ce que Microsoft fournit
- ✓Defender for Cloud et Secure Score pour l'identification des risques ICT
- ✓Sentinel pour la détection d'incidents et les données de timeline
- ✓Azure Backup, Site Recovery, ainsi que la redondance par zone et par région
- ✓Activity Log et piste d'audit au niveau ressource
- ✓Télémétrie des délégations Lighthouse pour les accès cross-tenant
Ce que DORA exige en plus
- ✓Le rattachement de chaque constat aux articles DORA (5–14, 17–23, 24–27, 28–44)
- ✓Un registre des tiers ICT entretenu et lié aux accès Azure réels
- ✓Un registre des tests de résilience avec attestations datées et actions correctives
- ✓Des métadonnées de classification d'incidents alignées sur les délais de notification DORA
- ✓Un export pré-audit avec executive summary et matrice de preuves par article
- ✓Un tableau de bord d'assurance continue qui démontre un fonctionnement durable, pas un instantané
Le tableau de bord regulatory de Defender intègre désormais une initiative DORA, ce qui constitue un point de départ utile pour les contrôles des Articles 5–14. Il n'entretient pas pour autant le registre des tiers, la trace des tests de résilience ou les métadonnées de classification d'incidents qu'attend DORA. Ces couches relèvent aujourd'hui du conseil chez GenioCT. La cartographie DORA dans Cloudivence figure sur la roadmap.
Par où commencer
La plupart des entités financières exploitant des workloads Azure démarrent par une évaluation de readiness DORA : GenioCT établit la baseline des quatre piliers (preuves de gestion du risque ICT, notification des incidents, trace des tests de résilience et registre des tiers), et Cloudivence couvre les preuves Azure qu'il lit aujourd'hui. L'évaluation produit une roadmap cadrée et un dossier de preuves à un instant T.
Commencez par un Azure Health Check
Pas sûr par où commencer ? Une revue rapide d'architecture vous donne une image claire. Sans engagement.
- ✓ Scorecard des risques : identité, réseau, gouvernance et sécurité
- ✓ Top 10 des problèmes classés par impact et effort
- ✓ Feuille de route 30-60-90 jours avec quick wins