Cas d'usage — Se conformer à DORA
DORA et Netwrix Privilege Secure : attribuer le privilège au moment où il est nécessaire
Le règlement délégué (UE) 2024/1774 traite explicitement des accès privilégiés. Son article 21(e)(ii) exige que les accès privilégiés, d'urgence et d'administrateur soient attribués uniquement sur la base du besoin d'en disposer ou au cas par cas pour l'ensemble des systèmes TIC. Le même article précise que, lorsque cela est possible, des comptes dédiés doivent être utilisés pour les tâches d'administration et que, lorsque cela est faisable et approprié, les entités financières doivent déployer des solutions automatisées de Privileged Access Management.
Netwrix Privilege Secure répond précisément à cette problématique : remplacer autant que possible un privilège permanent par une activité privilégiée encadrée dans le temps. La plateforme utilise des politiques d'accès pour définir quels utilisateurs peuvent réaliser quelles activités sur quelles ressources. Une session d'activité peut ensuite accorder temporairement les privilèges nécessaires à l'intervention.
Transformer un droit d'administration permanent en accès temporaire : DORA article 21(e)(ii)
Exigence DORA
Article 21(e)(ii) — Accès privilégiés, d'urgence et administrateur attribués sur la base du besoin d'en disposer ou au cas par cas
- Accès privilégiés, d'urgence et administrateur
- Attribution need-to-use ou ad hoc
- Lorsque possible : comptes d'administration dédiés
- Lorsque faisable et approprié : solutions automatisées de PAM
Netwrix Privilege Secure
- Politiques d'accès
- Activities
- Pre-Session Grant
- Post-Session Remove
- Approbation
- Durée maximale
- Sessions RDP / SSH
- Session recording
Le risque d'un compte administrateur n'est pas seulement lié à la personne qui le possède. Il vient aussi du temps pendant lequel ce privilège reste exploitable. Un droit permanent peut être utilisé longtemps après la fin du besoin qui justifiait initialement son attribution, y compris après la compromission du compte concerné.
Privilege Secure permet de définir des Activities composées d'actions exécutées avant, pendant et après une session. La documentation Netwrix prévoit explicitement des actions Pre-Session (Grant) permettant d'accorder un droit avant l'intervention et des actions Post-Session (Remove) permettant de retirer le droit lorsque la session se termine. Netwrix donne notamment comme exemple l'ajout temporaire d'un utilisateur à un groupe d'administrateurs locaux.
Prenons un administrateur devant intervenir sur un serveur supportant une fonction importante. L'organisation peut considérer qu'il est légitime pour réaliser ce type d'intervention sans pour autant lui laisser un privilège administratif permanent. Privilege Secure peut préparer la session, attribuer les permissions prévues par la politique, permettre l'intervention, puis exécuter les actions de retrait définies à la fin de l'activité.
Cette mécanique traduit directement la logique need-to-use ou ad hoc de DORA : le privilège est associé à une opération déterminée plutôt qu'à la seule existence du compte utilisateur.
Soumettre les interventions sensibles à approbation
Une intervention privilégiée peut également nécessiter une décision supplémentaire avant son exécution. Privilege Secure permet d'associer un workflow d'approbation à une politique de connexion. Lorsqu'une session exige cette approbation, elle ne peut pas commencer tant que les validateurs requis n'ont pas accepté la demande. Le produit permet de définir plusieurs niveaux successifs d'approbation lorsque le contexte le nécessite.
La demande conserve notamment le demandeur, la ressource cible, le compte utilisé, l'activité concernée, les dates prévues, les éventuelles notes et un numéro de ticket. La durée de la session est également déterminée à partir de la durée maximale définie dans le profil de connexion.
Dans une démarche DORA, l'intérêt est de pouvoir rattacher l'usage d'un privilège à une intervention identifiable et, lorsque la politique l'exige, à une décision d'approbation. Toutes les opérations administratives ne doivent pas nécessairement passer par le même workflow : c'est à l'organisation de proportionner le contrôle au risque de la ressource et de l'activité.
Contrôler la session privilégiée
Exigence DORA
Article 12 — Journalisation du contrôle d'accès logique
Netwrix Privilege Secure
- Sessions actives et historiques
- Session recording
- Informations liées à l'activité privilégiée
Contribution à la preuve, pas dispositif de journalisation DORA complet.
L'article 12 de DORA demande que les événements liés au contrôle d'accès logique soient journalisés et que le niveau de détail des journaux permette leur utilisation à des fins de surveillance et de détection.
Privilege Secure peut enregistrer les sessions passant par ses proxies RDP et SSH lorsque cette option est activée dans le profil de connexion. La documentation Netwrix prévoit la consultation d'une session en direct, sa relecture ultérieure et l'enregistrement de données telles que les frappes clavier et certaines métadonnées. Pour SSH, les commandes et frappes sont indexées et recherchables ; les administrateurs peuvent également interrompre une session active.
Les tableaux de bord conservent par ailleurs les sessions actives et historiques avec leur utilisateur, leur ressource, le compte de connexion, l'activité, les dates et la durée. Des journaux d'exécution sont disponibles pour chaque session.
Ces éléments contribuent à la preuve de l'usage privilégié mais ne constituent pas à eux seuls le dispositif de journalisation prévu par DORA. Les journaux du PAM doivent s'intégrer à la politique de logs plus large couvrant les systèmes, applications, identités, réseaux et autres événements prévus par l'article 12.
Où Privilege Secure s'insère dans l'architecture DORA
Privilege Secure intervient après la gouvernance de l'identité. Une IGA peut déterminer qu'un administrateur est éligible à certaines responsabilités ; l'Access Management vérifie son identité selon le niveau d'assurance nécessaire ; Privilege Secure encadre ensuite l'exercice effectif du privilège en contrôlant la ressource, l'activité, la durée, l'éventuelle approbation et la session.
Cette séparation évite d'utiliser le PAM comme un substitut à la gouvernance IAM. L'objectif n'est pas de placer indistinctement chaque accès dans un bastion, mais de réserver un contrôle renforcé aux opérations qui justifient réellement un privilège et d'éviter, lorsque l'architecture le permet, de maintenir ce privilège en permanence.
Netwrix Privilege Secure ne constitue donc pas une « solution DORA ». Sa contribution est plus précise : il permet de traduire l'exigence de l'article 21(e)(ii) en accès privilégiés temporaires et contrôlés, tout en fournissant une partie des traces nécessaires à leur audit.
Administrateur
IGA
L'administrateur est éligible à cette activité.
Authentification
L'identité est vérifiée.
Netwrix Privilege Secure
Demande d'activité privilégiée
Approbation
uniquement si la politique l'exige
Pre-Session — Grant
Octroi du privilège nécessaire
Session RDP / SSH
- Ressource cible
- Durée encadrée
- Enregistrement si configuré
Post-Session — Remove
Retrait du privilège
Sources
Textes réglementaires — EUR-Lex
Documentation officielle Netwrix Privilege Secure
Pour aller plus loin
Se conformer à DORA : quels contrôles ?
La page maître : cartographie des contrôles DORA sur les identités, les accès, les privilèges et les données.
Keeper
La sous-page DORA consacrée aux credentials, secrets et connexions privilégiées.
Netwrix Identity Manager
La sous-page DORA consacrée à la gouvernance des identités et à la certification des accès.
Offre PAM
L'offre Ariovis : maîtrise des comptes et des opérations à privilèges.
Moindre privilège
La définition du moindre privilège dans le glossaire IAM.
Échanger sur vos accès privilégiés DORA
Ariovis accompagne la définition des usages PAM, la réduction des privilèges permanents et la mise en place de contrôles adaptés aux opérations administratives sensibles.