Ariovis

Cas d'usage

Se conformer à DORA : quels contrôles pour les identités, les accès, les privilèges et les données ?

Le Digital Operational Resilience Act (DORA), règlement (UE) 2022/2554, s'applique depuis le 17 janvier 2025. Il encadre largement la résilience opérationnelle numérique des entités financières concernées : gestion du risque TIC, incidents, continuité, tests, fournisseurs tiers, protection des systèmes et des données.

Une partie de ces exigences concerne très directement les identités et les accès. Le règlement délégué (UE) 2024/1774 précise notamment des obligations relatives à la gestion des identités, au moindre privilège, à l'authentification forte, aux accès administrateur, à la journalisation, à la détection d'activités anormales et à la prévention des fuites de données.

Il serait pourtant trompeur de chercher « la solution DORA ». Ces contrôles interviennent à des moments différents : avant l'accès, pendant l'authentification, au moment de la décision d'autorisation, lors de l'utilisation d'un privilège ou encore lorsque des données sont consultées, modifiées ou transférées.

Cette page propose donc une cartographie technique de certains contrôles DORA et des briques qui peuvent contribuer à leur mise en œuvre.

DORA : une exigence, plusieurs contrôles

L'Alliance pour la Confiance Numérique décrit DORA comme un règlement venant harmoniser un environnement réglementaire jusqu'alors fragmenté en introduisant notamment de nouvelles exigences de gouvernance, de gestion des risques et de contrôle interne.

Cette lecture est importante : DORA ne doit pas être traité comme une liste de produits à acheter. Pour un même accès, plusieurs contrôles peuvent intervenir successivement. Il faut gouverner l'identité et ses habilitations, vérifier son authentification, décider si une action précise est autorisée, contrôler les privilèges éventuels, conserver des traces exploitables et empêcher certains usages ou transferts de données.

La question devient donc moins « quel outil répond à DORA ? » que « quel contrôle devons-nous mettre en œuvre, à quel moment, et avec quelle preuve ? ».

Analyse — source française, non réglementaire

Alliance pour la Confiance Numérique

« Analyse détaillée de la réglementation européenne DORA »

10 septembre 2024

L'Alliance pour la Confiance Numérique est une source d'analyse française ; elle n'est pas une autorité réglementaire.

Matrice des contrôles DORA

Cette matrice est un mapping de contributions techniques à certaines exigences DORA. Elle ne représente pas une couverture exhaustive du règlement, qui couvre également la gouvernance générale du risque TIC, les incidents, la continuité, les tests de résilience, les prestataires tiers TIC, le reporting réglementaire et d'autres mesures organisationnelles et techniques.

  • Gouvernance

    Gouverner les identités et le cycle de vie des droits

    • Article 20
    • Article 21(a)
    • Article 21(b)
    • Article 21(c)
    • Article 21(e)

    Qui doit avoir quoi, pourquoi et jusqu'à quand ?

    Brique technologique

    Netwrix Identity Manager (ex-Usercube)

    • Référentiel d'identités, rapprochement identités/comptes
    • Joiner-Mover-Leaver, provisioning et déprovisioning
    • Catalogue de rôles, règles d'attribution
    • Séparation des tâches, risques High Privilege
    • Campagnes de certification
  • Authentification

    Authentifier avec un niveau de confiance adapté au risque

    • Article 20(1)
    • Article 21(f)

    La personne qui se présente est-elle correctement authentifiée au regard du risque de la ressource et du contexte ?

    Brique technologique

    Ping Identity / PingOne

    • Politiques d'authentification, MFA, authentification forte
    • FIDO2 selon les configurations
    • Politiques adaptatives et signaux de risque avec PingOne Protect
    • Step-up et maîtrise des durées de session
  • Autorisation

    Décider dynamiquement si une action précise doit être autorisée

    • Article 11(a)
    • Article 21(a)
    • Article 21(d)

    Même authentifié et éligible, cet utilisateur peut-il réaliser cette action sur cette ressource dans ce contexte ?

    Brique technologique

    Axiomatics

    • Autorisation ABAC/PBAC, politiques centralisées
    • Attributs du sujet, de l'action, de la ressource et de l'environnement
    • Décision dynamique au runtime via PDP
    • Application de la décision via PEP
  • Privilèges

    Attribuer les privilèges sur une base need-to-use ou ad hoc

    • Article 21(e)(ii)
    • Article 12 — traces associées

    Comment permettre une opération d'administration sans conserver inutilement le privilège ?

    Brique technologique

    Netwrix Privilege Secure

    • Sessions privilégiées soumises à politiques
    • Approbation lorsque nécessaire, durée maximale
    • Actions pré-session et post-session permettant notamment l'octroi puis la révocation d'accès
    • Proxy et enregistrement des sessions

    Le règlement précise également que, lorsque cela est faisable et approprié, les entités financières doivent déployer des solutions automatisées de gestion des accès privilégiés.

  • Privilèges

    Protéger les credentials, secrets et accès privilégiés

    • Article 21(e)(ii)
    • Article 12 — traçabilité des activités

    Comment protéger, utiliser et renouveler les secrets nécessaires aux opérations privilégiées ?

    Brique technologique

    KeeperPAM / Keeper Secrets Manager

    • Gestion et rotation automatisée des credentials, secrets applicatifs
    • Connexions privilégiées sans exposition du credential
    • Gestion et enregistrement des sessions, connexions Zero Trust
    • Partage temporaire de connexions ou tunnels, reporting des événements PAM

    Keeper et Netwrix Privilege Secure ont des zones de recouvrement et répondent à des architectures ou cas d'usage différents : ces deux briques ne sont pas à déployer systématiquement l'une en plus de l'autre.

  • Audit

    Journaliser les accès, changements et activités

    • Article 12
    • Contribution aux mécanismes de l'article 23

    Qui a fait quoi, quand et où, et quelles modifications ou activités avons-nous réellement observées ?

    Brique technologique

    Netwrix Auditor

    • Collecte et restitution des changements et activités sur les environnements supportés
    • Activité de connexion, accès à certaines ressources
    • Changements de permissions
    • Recherches permettant de retrouver qui a modifié quoi, quand et où

    Netwrix Auditor contribue à la visibilité, à l'investigation et à la production de preuves ; il ne doit pas être présenté comme remplaçant à lui seul un SIEM, un SOC ou l'ensemble du mécanisme de détection des activités anormales prévu par l'article 23.

  • Données

    Empêcher les transferts ou usages non autorisés de données depuis les endpoints

    • Article 11(e)
    • Article 11(f)(iii)
    • Article 11(i)
    • Article 14(b)

    Même si l'utilisateur peut légitimement consulter cette donnée, peut-il la transférer par ce support ou ce canal ?

    Brique technologique

    Netwrix Endpoint Protector

    • Device Control pour maîtriser les périphériques et supports
    • Content Aware Protection pour détecter les contenus sensibles
    • Politiques de blocage, d'autorisation ou de reporting sur les points de sortie
    • Capacités complémentaires d'eDiscovery et d'Enforced Encryption

    Endpoint Protector contribue directement aux contrôles de prévention des pertes et fuites de données, mais ne couvre pas à lui seul toutes les exigences de sécurité des endpoints prévues par l'article 11.

Comment les contrôles s'articulent

Ces briques ne répondent pas au même moment de la décision de sécurité. Netwrix Identity Manager agit principalement en amont pour déterminer et gouverner les droits qu'une identité doit posséder. Ping Identity intervient au moment de l'authentification et permet d'adapter le niveau de confiance demandé au risque de l'accès. Axiomatics permet ensuite d'aller plus loin lorsque la décision ne peut pas être déterminée uniquement à partir d'un rôle et doit prendre en compte l'action, la ressource et le contexte au runtime.

Lorsqu'un privilège est nécessaire, une brique PAM telle que Netwrix Privilege Secure ou Keeper permet de contrôler son utilisation selon l'architecture retenue. Netwrix Auditor apporte ensuite de la visibilité et des éléments de preuve sur les activités et changements observés, tandis que Netwrix Endpoint Protector intervient lorsque le risque porte sur la sortie ou le transfert de données depuis les endpoints.

Cette séparation est volontaire. Un projet DORA cohérent ne consiste pas à empiler ces solutions, mais à déterminer quels contrôles sont nécessaires au regard des risques, des actifs concernés et de l'existant.

Un exemple : un administrateur sur un système critique

Prenons le cas d'un administrateur devant intervenir sur un système TIC supportant une fonction critique ou importante. La gouvernance IAM peut établir qu'il est éligible à cette responsabilité et maintenir cette décision dans le temps. L'Access Management peut imposer une authentification forte adaptée au risque. Le PAM peut limiter l'accès administratif à la durée nécessaire à l'intervention et conserver les traces prévues par la politique. Si l'application exige une décision plus fine, une politique d'autorisation peut encore limiter certaines opérations selon la ressource ou le contexte.

Les événements produits par ces différents contrôles peuvent ensuite alimenter les mécanismes de journalisation et d'investigation. Si l'administrateur accède légitimement à des données sensibles, une politique DLP peut enfin empêcher leur copie vers un périphérique ou leur transfert par un canal interdit.

Cet exemple illustre pourquoi une seule technologie ne peut pas constituer une « solution DORA ». Le contrôle résulte de l'articulation entre gouvernance, authentification, autorisation, privilège, traçabilité et protection des données.

DORA va beaucoup plus loin

Cette cartographie ne couvre volontairement qu'une partie de DORA : celle sur laquelle les technologies d'identité, d'accès, de privilège, d'audit et de protection des données peuvent apporter des contrôles concrets.

Le règlement comporte également des exigences importantes sur la gestion globale du risque TIC, les incidents, la continuité et la reprise, les tests de résilience opérationnelle, la gestion des prestataires tiers de services TIC et les mécanismes réglementaires associés. Une organisation ne peut donc pas conclure à sa conformité DORA à partir de la seule mise en œuvre des contrôles présentés ici.

L'intérêt de la matrice est différent : permettre de partir d'une exigence précise, identifier le contrôle nécessaire, comprendre le rôle de chaque brique et déterminer la preuve attendue.

De l'exigence à la preuve

La mise en conformité devient réellement exploitable lorsque chaque exigence peut être reliée à un processus, un responsable, un contrôle technique et une preuve. Côté identités et accès, cela signifie par exemple être capable de démontrer pourquoi une habilitation existe, quand elle a été revue, comment un privilège a été obtenu, quel niveau d'authentification a été imposé, quelle décision d'autorisation a été prise ou encore quel transfert de données a été bloqué.

C'est cette logique que nous retenons : ne pas partir du produit, mais du contrôle à mettre en œuvre.

Sources

Les exigences réglementaires renvoient à EUR-Lex ; les capacités techniques renvoient aux documentations officielles des éditeurs.

Textes réglementaires — EUR-Lex

Analyse — Alliance pour la Confiance Numérique, 10 septembre 2024

Netwrix Identity Manager

Ping Identity

Axiomatics

Netwrix Privilege Secure

Keeper

Netwrix Auditor

Netwrix Endpoint Protector

Pour aller plus loin

Échanger sur vos contrôles DORA

Ariovis part du contrôle à mettre en œuvre, de la preuve attendue et de l'existant, avant de parler d'outillage.

Parler de votre trajectoire DORAVoir l'offre Gouvernance des identités