DORA & Power Platform : sécuriser techniquement votre CRM Microsoft

Réglementation DORA : les fondamentaux à retenir

Qu'est-ce que la réglementation DORA ?

DORA, ou Digital Operational Resilience Act (Règlement sur la résilience opérationnelle numérique), fixe un cadre commun pour la résilience opérationnelle numérique du secteur financier. Adopté en décembre 2022 et applicable depuis le 17 janvier 2025, il renforce la capacité des établissements financiers et de leurs prestataires à endurer les incidents informatiques les plus graves et à s’en remettre.

Le périmètre est large : banques, assurances, sociétés de gestion d'actifs, établissements de paiement, émetteurs de monnaie électronique, infrastructures de marché, prestataires de services d'investissement et tous leurs prestataires de services TIC tiers critiques. Si vous gérez des systèmes d'information pour des clients du secteur financier, vous entrez dans le scope, notamment si vous êtes DSI ou responsable d'infrastructure critique.

Le Règlement (UE) 2022/2554 repose sur cinq piliers :

Résilience opérationnelle : la colonne vertébrale de DORA

La résilience opérationnelle désigne votre capacité à prévenir, détecter, résister et vous remettre rapidement des incidents TIC qui menacent vos activités critiques.

En pratique, DORA exige :

• un monitoring en temps réel avec mesures proactives de détection ;
• une capacité à restaurer rapidement les services avec des objectifs documentés ;
• des tests réguliers de vos plans de continuité ;
• une traçabilité complète de tous les événements.

Notez que pour être couronnée de succès, la résilience opérationnelle d’un système informatique est un processus continu qui nécessite une infrastructure robuste et une exploitation rigoureuse.

Pourquoi les prestataires IT sont-ils directement concernés ?

DORA introduit la notion de prestataire de services TIC tiers critique. Si vous gérez des systèmes essentiels pour des clients du secteur financier, vous devenez un maillon de leur chaîne de résilience opérationnelle.

En effet, ici, le principe de responsabilité partagée est central : votre client reste responsable de sa conformité, mais doit démontrer que ses prestataires respectent les exigences de résilience.

Pourquoi Microsoft Dataverse est-il directement concerné par DORA ?

Dataverse, plateforme critique pour les opérations métiers

Microsoft Dataverse alimente Dynamics 365 et Power Platform. Ce faisant, Dataverse centralise vos données clients, orchestre vos processus métiers critiques et héberge les workflows automatisés, en somme il s’agit du socle technique de votre CRM d’entreprise.

Plus spécifiquement, pour une institution financière, Dataverse héberge à la fois données clients, historique des transactions, processus d'onboarding, workflows de validation de crédit et informations contractuelles.

C’est pourquoi, si Dataverse tombe, c'est toute la chaîne opérationnelle qui s'arrête.

Les exigences DORA traduites en enjeux Dataverse

Les piliers de DORA impliquent des exigences techniques concrètes dans votre environnement Dataverse :

• Gestion des accès et des identités : RBAC finement configuré dans Dataverse selon une approche sécurité by design, MFA obligatoire via Entra ID, Conditional Access basé sur le risque.
• Gestion et classification des incidents : Logs d'audit Dataverse centralisés, Application Insights pour le monitoring applicatif, Azure Monitor pour la surveillance de l'infrastructure.
• Continuité d'activité et reprise : Stratégie de backup granulaire, environnements de secours avec réplication géo-redondante, tests réguliers de restauration avec RTO/RPO définis.
• Surveillance et détection : Performances suivies en temps réel, détection d'anomalies, journalisation exhaustive des événements.
• Tests de résilience : Tests de charge sur Dataverse, simulation de pannes, validation des plans de reprise d'activité.
• Cycle de vie sécurisé : Pipelines ALM automatisés, gestion rigoureuse des versions, contrôle des déploiements en production.

Dataverse n'est pas "DORA-ready" par défaut

Microsoft fournit une infrastructure cloud robuste avec des capacités avancées de sécurité, monitoring et haute disponibilité. Le SLA annoncé est de 99,9% pour Dataverse, soit environ 8,76 heures d'indisponibilité potentielle par an. Mais ces capacités ne sont ni activées ni configurées par défaut pour répondre aux exigences spécifiques de DORA, qui impose une approche bien plus stricte en détection, réaction et capacité de reprise.

Cette situation s'explique par le modèle de la responsabilité partagée dans le cloud. Microsoft assume la responsabilité de l'infrastructure physique, de la sécurité du datacenter et de la disponibilité de la plateforme. Vous, vous restez responsable de la sécurité des données, des identités, des configurations et des contrôles d'accès. C'est justement dans ce périmètre que les exigences de conformité DORA entrent en jeu.

Concrètement, un environnement Dataverse fraîchement provisionné peut présenter des lacunes importantes selon la configuration de votre tenant Azure :

• MFA non systématiquement obligatoire sans security defaults ou Conditional Access activées
• Environnements non segmentés selon les bonnes pratiques dev/test/prod
• Stratégie de rétention des logs non configurée pour conserver les traces sur la durée requise
• Contrôles d'accès trop permissifs avec rôles administrateur distribués largement
• Aucun monitoring proactif par défaut pour détecter les anomalies
• Workflows sans mécanismes robustes de gestion d'erreur et d'alerte

La conformité DORA nécessite donc un important durcissement technique significatif et une configuration experte de votre environnement Dataverse.

Les risques techniques spécifiques dans un environnement Dataverse

Risques liés à la gestion des accès et des identités

Les risques sont multiples : permissions trop larges accordées par facilité, absence de MFA strictement imposée, rôles de sécurité mal configurés qui donnent accès à des données sensibles ou encore comptes de service disposant de droits administrateur sans justification métier réelle.

À leur tour, ces failles entraînent des accès non autorisés, des modifications de données sans traçabilité, l'exfiltration d'informations confidentielles ou l'escalade de privilèges permettant à un attaquant de prendre le contrôle de l'environnement.

Par exemple, un consultant externe paramètre votre CRM Dynamics 365 avec un rôle administrateur. La mission se termine, mais personne ne révoque ses accès. Six mois plus tard, ce consultant travaille pour un concurrent et conserve un accès complet à vos données commerciales stratégiques.

La solution technique passe par la mise en place d'un RBAC granulaire avec des rôles définis selon le principe du moindre privilège. L'authentification multi-facteurs doit être obligatoire pour tous les utilisateurs via l'activation des security defaults ou des politiques Conditional Access dans Entra ID. Enfin, une revue régulière et automatisée des permissions garantit qu'aucun accès obsolète ne reste trop longtemps disponible.

Vulnérabilités des workflows et automatisations

Vos processus métiers critiques reposent sur des workflows et des automatisations Power Automate : validation de demandes de crédit, onboarding client, gestion des réclamations, alimentation des systèmes de reporting. Le problème ? Ces workflows peuvent être fragiles et échouer “silencieusement”.

Cas typique : une banque automatise la validation de crédit immobilier dans Dynamics 365. Le workflow appelle un service externe de scoring. Un jour, ce service change son format de réponse. Le workflow échoue sans que personne ne s’en aperçoive pendant trois jours, bloquant toutes les demandes de crédit, jusqu'à ce qu'un client mécontent escalade le problème.

La solution passe par un monitoring continu des workflows

avec des dashboards temps réel indiquant le taux de succès et les erreurs. Chaque automatisation doit intégrer une gestion d'erreurs avec des mécanismes de retry intelligents, en plus de quoi des alertes automatiques doivent notifier les équipes techniques dès qu'un workflow critique échoue.

Risques de performance et de throttling API

DORA exige une capacité à maintenir les opérations même dans des situations de stress intense.

Ainsi, Microsoft Dataverse impose des limites techniques sur les appels API pour protéger la plateforme et garantir une qualité de service équitable. Selon la documentation officielle, la limite standard est de 6000 requêtes par utilisateur dans une fenêtre glissante de 5 minutes (variable selon tenant, licences et évolutions de la plateforme). Le dépassement de ces limites déclenche un throttling : vos requêtes sont alors rejetées ou ralenties, provoquant ralentissements généralisés, échecs d'opérations critiques et dégradation sévère de l'expérience utilisateur.

Pour éviter ce scénario, il faut optimiser l'architecture de vos intégrations : réduction du nombre et de la complexité des requêtes, mise en place de mécanismes de cache pour éviter les appels répétitifs, dimensionnement approprié des licences pour augmenter les quotas si nécessaire, et monitoring permanent des quotas API avec alertes avant dépassement.

Absence de stratégie de continuité et de recovery

Beaucoup d'organisations n'ont pas de Plan de Reprise d'Activité testé pour Dataverse. Les backups existent, mais le délai réel de reprise est inconnu car les environnements de secours n'existent tout simplement pas et bien entendu les procédures ne sont pas non plus documentées.

Or, pour une conformité à la réglementation DORA, toute organisation doit :

• définir ses RTO (délai maximum pour remettre le service en ligne) et RPO (ancienneté maximum des données perdues acceptables) ;
• prouver par des tests qu’elle est en mesure de tenir ces objectifs.

La solution réside dans le croisement de plusieurs pistes, à savoir : une stratégie de backup multi-niveaux avec backups complets et sauvegardes incrémentales, l’utilisation d’environnements sandbox avec réplication géo-redondante, la conduite de tests réguliers.

Lacunes dans la traçabilité et l'auditabilité

Sans une traçabilité exhaustive, vous êtes aveugle. Vous ne pouvez ni démontrer votre conformité, ni analyser efficacement un incident, ni détecter des comportements anormaux avant qu'ils ne causent des dégâts.

Les lacunes possibles sont nombreuses :

• logs qui ne capturent pas les événements critiques ;
• absence de mécanismes de détection d'anomalies dans les patterns d'accès ;
• pas de traçabilité du déroulement d'un incident (ce qui compromet la conformité de toute votre GED ;
• logs conservés sur des périodes trop courtes.

Par exemple, un incident de sécurité est détecté dans votre environnement Dataverse. Une table contenant des informations contractuelles sensibles a été modifiée de manière suspecte. Vous lancez l'investigation, mais découvrez que les logs d'audit n'ont pas été configurés pour tracer les modifications sur cette table spécifique. Dès lors, impossible d'identifier qui a effectué les modifications, depuis quelle machine, à quel moment précis et l'investigation est dans l'impasse.

Pour pallier ce problème, il faut configurer l'audit Dataverse de manière à pouvoir retracer tous les événements pertinents sur toutes les entités critiques. Voyons tout ceci plus en détail.

Approche technique pour atteindre la conformité DORA sur Dataverse

Diagnostic technique DORA de votre environnement Dataverse

Concrètement, selon notre méthodologie interne, un audit complet peut couvrir plus de 150 points de contrôle techniques.

La première étape vers la conformité consiste à réaliser un audit technique approfondi de votre configuration Dataverse actuelle. Ce diagnostic révèle vos vulnérabilités invisibles et quantifie précisément votre niveau de risque.

La méthodologie d'audit couvre tous les aspects de la résilience opérationnelle : sécurité et gestion des identités, performances et robustesse des workflows, capacités de résilience et de recovery, complétude du monitoring et de l'observabilité, maturité de votre cycle de vie applicatif.

Via cette analyse systématique, vous obtenez un rapport d'écarts techniques documentant tous les points de non-conformité par rapport aux exigences DORA, accompagné d'une matrice de risques évaluant chaque vulnérabilité selon sa criticité et sa probabilité d'occurrence. Ne reste plus alors qu’à établir une roadmap pour hiérarchiser les actions correctives selon un ordre logique tenant compte des dépendances techniques et des priorités métiers.

Durcissement et mise à niveau technique

Une fois les écarts identifiés, vient la remédiation technique pour transformer votre plateforme en infrastructure résiliente.

L'approche repose sur une priorisation rigoureuse : les actions sont classées par criticité, les chantiers les plus urgents et les plus impactants sont traités en priorité, l'implémentation se fait de manière progressive par vagues successives avec une validation à chaque étape.

• Dans Entra ID : MFA obligatoire via security defaults ou Conditional Access, politiques basées sur le risque, gouvernance des identités avec revue périodique.
• Dans Dataverse : RBAC au plus juste selon le moindre privilège, logs d'audit sur entités critiques, stratégies de rétention appropriées, segmentation des environnements dev/test/prod.
• Dans Azure : monitoring complet avec Azure Monitor et Application Insights, alertes automatiques, stratégie de backup multi-niveaux avec réplication géo-redondante, procédures de reprise documentées et testées.
• Dans Power Platform : gouvernance stricte des workflows, pipelines de déploiement automatisés, gestion rigoureuse des versions.

Monitoring continu et run DORA technique

La conformité DORA est un mode d'exploitation permanent qui nécessite une surveillance continue et une capacité de réaction rapide.

L'approche de monitoring continu repose sur des dashboards temps réel consolidant tous les indicateurs critiques de santé de votre plateforme. Des alertes automatiques se déclenchent dès qu'un seuil est dépassé ou qu'une anomalie est détectée. Des rapports périodiques documentent les événements, les incidents et les évolutions des indicateurs. Les indicateurs suivis couvrent tous les aspects de la résilience : disponibilité de chaque composant critique, performances mesurées pour détecter les dégradations, quotas API surveillés pour anticiper les dépassements, événements de sécurité corrélés et analysés, incidents tracés et documentés.

Dans l’idéal, l'organisation du run intègre des astreintes pour garantir une capacité de réaction 24 heures sur 24 et 7 jours sur 7 sur les systèmes critiques, ainsi que des procédures d'escalade clairement définies pour que chaque incident soit traité avec le niveau d'expertise approprié. Enfin, il faudra également veiller constamment à maintenir une documentation à jour.

‍

Vous l’aurez compris, atteindre la conformité DORA suppose une expertise Microsoft pointue dont la plupart des cabinets de conformité traditionnels ne disposent pas. En effet, il ne faut rien de moins que maîtriser les subtilités de Dataverse, Entra ID, Azure et Power Platform pour diagnostiquer les vulnérabilités, mettre en œuvre les configurations de durcissement et établir un mode d'exploitation résilient.

Parmi les acteurs capables de croiser maîtrise technique spécialisée dans l'écosystème Microsoft et compréhension des enjeux réglementaires DORA, Askware se distingue par cette combinaison. Grâce à notre accompagnement sur vos projets de long terme, vous pourrez répondre simultanément aux enjeux de conformité, sécurité, performance et retour sur investissement.

Votre environnement Dataverse est-il réellement prêt pour DORA ? Askware vous propose un diagnostic technique approfondi pour identifier vos vulnérabilités et établir votre roadmap de mise à niveau. Contactez nos experts Microsoft pour sécuriser techniquement votre plateforme.