Surveillance des utilisateurs privilégiés : Visibilité sans confiance

L’accès privilégié permanent et toujours actif reste la norme dans la plupart des environnements, et 67 % des organisations l’accordent à au moins certains rôles, selon l’enquête à l’origine du Netwrix 2026 Data and Identity Security Report. Ces droits restent actifs entre les tâches qui les justifient, ce qui est le vide que la surveillance des utilisateurs privilégiés vise à combler.

Un administrateur membre de Domain Admins dispose d'une autorisation complète dans la limite de contrôle applicable d'Active Directory, que la personne derrière les identifiants soit le responsable de l'infrastructure ou un attaquant qui les a obtenus par phishing.

Une décision d’autorisation réussie prouve la permission et rien de plus. L’intention bienveillante et la légitimité opérationnelle nécessitent des preuves distinctes. La surveillance fournit ces preuves et renforce la gouvernance des accès sans ralentir l’administration dont dépend l’entreprise.

Qu’est-ce que la surveillance des utilisateurs privilégiés ?

La surveillance des utilisateurs privilégiés est la collecte et l'analyse continues des activités effectuées par des comptes de confiance chargés d'exécuter des fonctions liées à la sécurité, de sorte que chaque utilisation de droits élevés laisse une trace consultable. Le NIST définit un privileged user comme une personne disposant de l'autorisation, et donc de la confiance, pour effectuer des fonctions liées à la sécurité que les utilisateurs ordinaires ne peuvent pas réaliser.

Rien dans cette définition ne nécessite un humain derrière l’identifiant, donc les comptes de service, les managed identities et les automation principals détenant des droits élevés entrent dans le même périmètre.

La portée s'étend au-delà de l'annuaire local à partir duquel la plupart des équipes commencent. Chaque fois qu'une identité détient des droits administratifs, que ce soit dans Active Directory, un fournisseur d'identité cloud, une console d'administration SaaS ou une base de données, cette identité fait partie de la population surveillée.

Pourquoi les comptes utilisateur privilégiés sont les plus difficiles à suivre

Les systèmes d’autorisation déterminent si un principal peut effectuer une action, et pour un compte privilégié, la réponse à l’intérieur de sa limite de contrôle est généralement oui. Quatre mécanismes font que ce « oui » cache plus qu’il ne devrait.

Des identifiants valides rendent l'administration et l'attaque identiques

Une fois que l’annuaire accorde le droit, l’événement de connexion, la vérification de l’appartenance au groupe et l’accès à la ressource réussissent tous parce que les identifiants sont valides, que la personne derrière soit l’administrateur ou un attaquant qui les a obtenus par phishing.

La technique MITRE T1078.002 couvre précisément cet abus des identifiants valides de comptes de domaine pour l'accès initial, la persistance, l'escalade des privilèges et l'évasion de la défense. Dans l'enquête à l'origine du Netwrix 2026 Data and Identity Security Report, 73,78 % des organisations ont déclaré ne pas être entièrement confiantes que leur Active Directory est exempt de mauvaises configurations permettant l'escalade des privilèges. Chacune est une autre voie vers cette même position de confiance.

Les requêtes de groupe formelles omettent les membres imbriqués

L'attribut memberOf d'Active Directory omet l'appartenance aux groupes imbriqués, donc une lecture directe de Domain Admins ou de tout autre groupe privilégié ne détecte pas les utilisateurs qui y accèdent par imbrication. Une revue d'accès limitée à cette appartenance directe certifie dès le départ une population incorrecte.

Les ACL créent des administrateurs fantômes en dehors de chaque groupe privilégié

Les listes de contrôle d'accès accordent des droits sensibles aux shadow admins, des comptes qui se situent entièrement en dehors de tout groupe d'annuaire privilégié. Le cas le plus marquant est un compte ayant la permission de modifier l'appartenance à un groupe, qui peut s'ajouter lui-même à ce groupe. Ce comportement est intentionnel, ce n'est pas un paramètre que l'on peut désactiver.

Les droits d’administrateur local et GPO ne génèrent aucun événement d’adhésion à détecter

Les droits d’édition de Group Policy Object (GPO) tels que GenericWrite ou WriteDacl, et local administrator rights stockés dans le Security Accounts Manager (SAM) local d’une machine, confèrent la même autorité effective sans nécessité d’appartenance à un groupe.

Les connexions de service et de tâches planifiées enregistrent également le mot de passe du compte comme un secret réutilisable sur le disque dans la Local Security Authority (LSA), ce qui transforme toute compromission de cet hôte en compromission d’identifiants. Aucun de ceux-ci ne génère les événements 4728, 4732 ou 4756 de changement d’appartenance dont dépendent les rapports d’habilitation.

Ce que la surveillance des utilisateurs privilégiés doit couvrir

La surveillance justifie son coût en capturant les changements qui déplacent le risque. L’événement d’alerte idéal présente une forte probabilité d’activité non autorisée et un faible taux de faux positifs, et audit records sont parfois la seule preuve qu’une attaque réussie laisse derrière elle (CIS Control 8). La tentation est de tout collecter, ce qui crée une file d’attente que personne ne lit.

Accès non propriétaire aux données sensibles, y compris la lecture des boîtes aux lettres, correspond à des techniques de collecte telles que MITRE T1114 et T1213 et apparaît dans Microsoft 365 via l’action d’audit MailItemsAccessed. La protection contre la falsification détecte les tentatives de désactivation d’un agent de point de terminaison.

L'inactivité nécessite un seuil défini, et la contre-mesure de CISA pour les comptes inactifs laisse ce nombre à chaque organisation (son exemple signale 180 jours d'ancienneté du mot de passe). Les comptes fournisseurs méritent la même rigueur que les employés partants.

Les Cross-Sector Cybersecurity Performance Goals 2.0, publiés en décembre 2025, associent un objectif sur le risque des fournisseurs de services gérés à une exigence de désactivation de chaque compte et chemin d'accès le jour du départ d'une personne.

Surveillance des utilisateurs privilégiés vs. gestion des sessions privilégiées vs. surveillance de l’activité utilisateur

Trois contrôles sont confondus car ils concernent tous le comportement administratif, mais chacun s’applique à une unité différente et répond à une question différente.

La gestion des sessions privilégiées gère la connexion elle-même, isolant les identifiants de l'utilisateur final, de sorte que ses artefacts les plus profonds sont les enregistrements de session et les journaux de frappes. Ces journaux capturent tout ce qui est tapé, y compris les mots de passe et les données personnelles, donc les fenêtres de rétention et les contrôles d'accès doivent rester stricts, et les enquêteurs ont toujours besoin d'un journal de commandes analysé en plus des enregistrements car nettoyer la vidéo pour une action ne peut pas être étendu.

La surveillance de l'activité des utilisateurs étend cette même capture de contenu à l'ensemble du personnel pour détecter les menaces internes, selon la définition UAM de NIST. Les directives du UK ICO sur la surveillance des travailleurs considèrent ce niveau de capture d'écran et de frappes comme un traitement suffisamment large pour nécessiter une évaluation d'impact sur la protection des données.

La surveillance des utilisateurs privilégiés évite par défaut la capture de contenu et reste centrée sur l'autorisation, en inventoriant la population des administrateurs et en auditant les droits élevés utilisés par chaque identité. Ce focus plus restreint rend possible une exécution continue sur chaque compte privilégié plutôt que sur un échantillon de sessions, et la plupart des programmes en exécutent au moins deux sur trois.

Comment créer un programme de surveillance des utilisateurs privilégiés

La découverte vient d'abord, puis la réduction, ensuite l'établissement de la base de référence et la détection, puis la protection des preuves. Chaque étape réduit ce que la suivante doit couvrir, c'est pourquoi commencer par des outils de détection signifie de toute façon reconstruire l'inventaire plus tard.

1. Découvrez l’ensemble de la population privilégiée

Cartographiez chaque compte et chaque droit conférant une autorité administrative, pas seulement l'appartenance à un groupe :

• Administrateurs de domaine et locaux, résolus via l’appartenance transitive au groupe afin d’inclure les membres imbriqués.
• Droits accordés par ACL et permissions de modification GPO sur les objets de l’annuaire.
• Le groupe local des Administrateurs sur chaque endpoint.
• Types de comptes de service, y compris group Managed Service Accounts (gMSAs), standalone Managed Service Accounts (sMSAs), comptes ordinateurs et comptes utilisateurs exécutant des services.
• Break-glass emergency accounts and vendor and contractor access.
• Cloud and SaaS privileged roles, from Entra ID Global Administrator and Privileged Role Administrator to the equivalent tenant-admin roles in other identity providers and business applications.

Give every entry a named owner and a stated purpose, or the inventory becomes a list nobody acts on.

2. Reduce it before monitoring it

Remove every standing account monitoring doesn't need to cover before building the next stage. Most environments carry more elevated rights than the work requires, and the same Netwrix survey found 68% of organizations don't enforce strict least privilege.

Move accounts to just-in-time elevation at minimum, temporary permissions that lapse on expiry, or further to zero standing privilege, where no account holds elevated rights between approved sessions and ephemeral accounts exist only for the duration of the work.

3. Baseline normal administration by role

Feed authentication attempts, access requests, privilege changes, and directory modifications into an identity threat detection and response platform, and let it build a profile for each identity and its peer group instead of judging one connection at a time.

Behavioral analytics and signal correlation catch what single-event rules miss, the same principle behind Microsoft Defender for Identity's own detections. Expect weaker signal for the first few weeks on a new administrator or freshly provisioned service account, since baseline quality improves as activity accumulates.

4. Track entitlement drift between reviews

Compare current entitlements against the last certified state between review cycles, not just during them. Periodic certifications only capture a moment, so a grant added the week after reviewers close a campaign can go unchecked until the next one. Flag any grant that appeared since the last certification, so the annual review confirms what monitoring already caught instead of being the only check that ever runs.

5. Alert on change, correlate on pattern

Alert immediately on the small set of events that are almost never legitimate on their own. Correlate everything else. Most attack activity only becomes visible across a sequence of weaker signals, such as an unusual logon followed by a privilege change followed by access to a system the account has never touched. Build single-event rules and behavioral correlation into the same design, rather than choosing one.

6. Protect the evidence from the administrators it describes

Assume the administrators being monitored can edit the record until the architecture proves otherwise. Domain Admins membership includes membership in the local Administrators group on every domain-joined computer by default, which grants the right to read the Security log and the ability to clear it outright.

NIST SP 800-53 AU-9(4) covers exactly this recursion, since individuals with privileged access who are also audit subjects can affect audit information reliability by inhibiting logging or modifying records.

A determined domain administrator can still bypass ACL restrictions on log access by using SeTakeOwnershipPrivilege to take object ownership and rewrite the object's discretionary access control list (DACL). Build architectural separation instead; that control survives the move. AU-9(2) requires separate audit storage so a compromise of the monitored system doesn't compromise its record.

• Forward security events in near real time to a collector under separate administration. Windows Event Forwarding supports this, but it sends no notification and leaves no gap indicator when a disconnected client's log overwrites events.
• Send the 4728, 4732, and 4756 group-membership-addition events and 5136 changes on AdminSDHolder to that same collector, so nobody can edit a re-grant out of the record between reviews.
• Restrict audit log management to a defined subset of privileged users separate from the administrators the audit covers, per AU-9(4), and grant reviewers read-only access, per AU-9(6).
• Alert on tampering itself. Event 4719 records an audit policy change, and Windows logs it regardless of the audit policy setting; rate it as high criticality. Correlate it with a preceding 4688 process-creation event showing wevtutil or auditpol, which requires command-line logging.

Compliance requirements for privileged user monitoring

Auditors ask organizations to prove who held which rights, when they held them, and what they did with them. Frameworks express that demand as recertification intervals and logging obligations, and the intervals are the easy half. What sinks programs is reconstruction, because a review that nobody can rebuild six months later fails the audit, whether or not it ran on schedule.

Les références ci-dessous utilisent les versions en vigueur en septembre 2026, couvrant PCI DSS v4.0.1, NIST SP 800-53 Rev 5, la HIPAA Security Rule à 45 CFR Partie 164 Sous-partie C, et ISO/IEC 27001:2022.

Deux instruments européens s'appliquent parallèlement : le règlement d'exécution pour la Network and Information Systems Directive 2 (NIS2) et le règlement délégué pour la Digital Operational Resilience Act (DORA).

HHS a proposé une révision de la Security Rule en janvier 2025, mais cela reste une proposition, et l'agenda réglementaire vise juillet 2027 pour l'action finale. Tel que proposé, la norme des contrôles d'audit passerait de 164.312(b) à 164.312(d)(1) et s'étendrait à tous les systèmes concernés, pas seulement ceux contenant des ePHI. Jusqu'à ce que HHS finalise la règle, la référence applicable est 164.312(b).

La préparation à l’audit montre ses limites lorsqu’on demande à une organisation de reconstituer une action privilégiée datant de plusieurs mois, et la réponse dépend de la durée de conservation des preuves.

Microsoft Entra ID conserve les journaux d’audit et de connexion pendant 7 jours sur le niveau Free et 30 jours sur P1 et P2 selon ses périodes de rétention natives.

L’exigence 10.5.1 de PCI DSS requiert douze mois d’historique des journaux d’audit, avec les trois derniers mois immédiatement disponibles pour analyse. La rétention native seule est insuffisante, c’est pourquoi le collecteur qui détient la copie transférée devient généralement le système de référence.

Défis courants et comment les surmonter

Les obstacles ci-dessous sont culturels et opérationnels, donc changer d’outil les résout rarement.

• Les administrateurs perçoivent la surveillance comme une méfiance institutionnelle, et certains essaient de la désactiver : Maintenez la supervision en dehors du domaine administré en transférant les journaux vers un système inaccessible aux administrateurs, et expliquez quelles menaces ciblent leurs identifiants avant la mise en place des contrôles. Des droits attribués individuellement et limités dans le temps préservent la piste d’audit sans traiter les administrateurs comme des suspects.
• L'activité privilégiée légitime génère un volume qui noie les alertes significatives : Évaluez les écarts par rapport à la ligne de base au lieu d'alerter pour chaque événement. Alignez l'ingénierie de détection sur les tactiques, techniques, et procédures (TTPs) afin qu'un administrateur exécutant un script de mise à jour connu soit supprimé au lieu d'être alerté.
• Les comptes partagés, break-glass et fournisseurs résistent à l’attribution individuelle, et les comptes d’urgence n’ont pas de propriétaire nommé par conception : Use dedicated administrator accounts (CIS Control 5) et examinez les comptes de service au moins trimestriellement. Assignez un propriétaire nommé à chaque compte de service et alertez en severity 0 à chaque utilisation break-glass.

Comment Netwrix aide à la surveillance des utilisateurs privilégiés

Netwrix répartit ces responsabilités sur quatre produits, un par étape. Netwrix Access Analyzer gère la découverte et Netwrix Privilege Secure la réduction.

Netwrix Auditor et Netwrix Threat Manager couvrent ensuite les deux volets du problème des preuves : l'historique des modifications et la détection des comportements qui s'écartent du modèle établi d'une identité.

Découvrez les privilèges effectifs au-delà de l'appartenance au groupe

Netwrix Access Analyzer détermine automatiquement les permissions effectives sur les domaines, UO, groupes, utilisateurs et ordinateurs Active Directory. Son rapport d’accès effectif résout l’appartenance aux groupes imbriqués et les droits accordés par ACL pour montrer l’accès réel d’un compte, et signale également les comptes de fiduciaires obsolètes dans le même processus. Cet inventaire alimente la réduction, car un inventaire sans réduction ne fait qu’élargir la liste de surveillance.

Remplacer l'accès privilégié permanent par un accès limité aux tâches

Netwrix Privilege Secure est un produit de Privileged Access Management qui remplace les droits administratifs permanents par un accès limité aux tâches. Il émet un Activity Token, un compte unique et limité dans le temps qui existe pour une activité. Netwrix Privilege Secure supprime ce compte à la fin de l’activité, de sorte qu’aucun identifiant élevé persistant ne reste entre les utilisations.

Eastern Carver County Schools a supprimé les comptes privilégiés permanents de la gestion des commutateurs réseau, VMware et des systèmes de caméras de sécurité desservant 9 300 élèves et plus de 2 000 membres du personnel, les remplaçant par un accès temporaire expirant à la fin de la tâche. L’équipe a terminé le déploiement en quelques jours.

Enregistrez les modifications des droits et de la configuration avec les valeurs avant et après

La recertification et la requête historique d'un auditeur dépendent toutes deux d'un enregistrement de l'état antérieur de l'environnement.

Netwrix Auditor, un produit d’audit informatique et de reporting de conformité, surveille Active Directory, Group Policy, Entra ID, Exchange, les serveurs de fichiers et SQL Server, enregistrant qui a modifié quoi, quand et d’où, avec des valeurs avant-après dans les détails des modifications.

Rapports à un instant donné reconstruisent la configuration à un moment choisi à partir de clichés quotidiens. Pour rapporter sur une date passée, vous devez d'abord importer ce cliché historique.

Détecter les comportements anormaux des comptes privilégiés et de service

La définition de la ligne de base est l’étape que les équipes reportent le plus souvent, et Netwrix Threat Manager l’automatise. Le produit d’Identity Threat Detection signale les comportements des comptes privilégiés et de service qui s’écartent d’un modèle établi.

La détection des comportements anormaux commence une fois qu’un compte est actif depuis au moins 30 jours, s’appuie sur jusqu’à 120 jours d’activité pour établir la base de référence de ce compte, et réévalue chaque utilisateur toutes les 15 minutes. Une déviation qui dépasse le seuil configuré crée un enregistrement de menace pour enquête.

Pour la plupart des équipes, la question utile est de savoir quelle étape de ces phases leur programme actuel a réellement terminée. Netwrix Access Analyzer, Netwrix Privilege Secure, Netwrix Auditor et Netwrix Threat Manager traitent chacun une étape différente.

Couvrir les contre-mesures de compte de CISA

Outil de Stratégies d'Éviction de CISA recense les contre-mesures post-compromission par ID. Cinq d'entre elles ciblent les comptes privilégiés et obsolètes, chacune étant soutenue par un produit Netwrix :

• Supprimez les comptes superflus et obsolètes (CM0112): Netwrix Access Analyzer signale les comptes utilisateurs désactivés et inactifs et automatise leur nettoyage.
• Surveillez les autorisations des comptes utilisateur, service et administrateur (CM0043): Netwrix Access Analyzer résout les groupes imbriqués et les droits accordés par ACL pour afficher les autorisations effectives de chaque compte.
• Surveillez la création de comptes et les modifications des autorisations (CM0044): Netwrix Auditor enregistre les nouveaux comptes et les modifications des membres des groupes de sécurité avec qui, quoi, quand et où.
• Auditer les objets Group Policy dans Active Directory (CM0085): Netwrix Auditor enregistre les modifications de Group Policy avec les valeurs avant et après.
• Enquêter sur les tentatives de connexion suspectes (CM0063) : Netwrix Threat Manager signale les authentifications anormales par rapport à la référence de chaque identité.

Transformez la confiance administrative en un enregistrement que vous pouvez consulter

Un système d’autorisation continuera à accepter une identité valide, que la personne derrière soit l’administrateur ou l’attaquant qui l’a obtenue par phishing. La surveillance est ce qui les différencie, et elle ne fonctionne qu’en tant que programme.

Ce programme signifie une population découverte, une surface d’attaque réduite, une base comportementale, une dérive des droits détectée entre les revues, des alertes corrélées au lieu d’une file d’attente que personne ne lit, et des preuves que les administrateurs surveillés ne peuvent pas modifier discrètement.

Les auditeurs, conseils d’administration et assureurs cyber demandent désormais précisément ce registre, et non une simple déclaration de politique indiquant qu’un outil de surveillance existe. L’écart entre les deux se comble étape par étape, en commençant par celle que votre programme actuel n’a pas encore terminée.

Demandez une démo pour voir comment Netwrix couvre la découverte, la réduction, les preuves et la détection pour vos comptes privilégiés.