Intune Endpoint Privilege Management : déléguer des droits admin sans risque

Le principe du moindre privilège (least privilege) est l'un des fondamentaux de la cybersécurité : chaque utilisateur et chaque processus ne doit disposer que des droits strictement nécessaires à l'exécution de ses tâches. Dans la pratique, c'est souvent là que le bât blesse. Pour éviter les tickets helpdesk constants liés aux installations de logiciels, aux mises à jour drivers ou aux paramétrages système, de nombreuses entreprises accordent des droits administrateur locaux à leurs utilisateurs — créant ainsi une surface d'attaque considérable. Un malware qui s'exécute sous un compte admin local a immédiatement accès à l'ensemble du système, aux clés de registre critiques et aux autres comptes présents sur la machine. Microsoft a répondu à ce défi avec l'Endpoint Privilege Management (EPM), une fonctionnalité Intune permettant d'élever ponctuellement les droits d'une application ou d'un processus spécifique, sans donner de droits administrateur permanents à l'utilisateur. Ce guide détaille l'architecture d'EPM, la création de politiques d'élévation (automatique, assistée et déclenchée par l'utilisateur), la configuration des règles par hash SHA-256, certificat ou chemin, le workflow d'approbation pour les élévations sensibles, et l'intégration avec Privileged Identity Management (PIM) Azure pour une gestion des accès privilégiés complète et auditée en 2026.

Le problème des droits administrateur locaux en entreprise — État des lieux 2026

Comprendre pourquoi le problème des droits admin locaux est si difficile à résoudre aide à mieux apprécier ce qu'EPM apporte réellement.

Pourquoi les entreprises accordent des droits admin — Les raisons réelles

Dans la majorité des PME et ETI, les droits administrateur locaux sont accordés pour des raisons pratiques qui s'accumulent au fil du temps :

• Installations logicielles fréquentes : commerciaux qui installent des plugins pour CRM, développeurs qui installent des IDE et outils, responsables qui installent des utilitaires métier
• Mises à jour de drivers : imprimantes, scanners, équipements spécialisés qui nécessitent des droits admin pour le driver
• Paramétrages réseau : modifier les paramètres de proxy, rejoindre un VPN, configurer une imprimante réseau
• Applications anciennes : logiciels métier développés il y a 10-15 ans qui écrivent dans HKLM ou Program Files à chaque exécution
• Réduction des tickets helpdesk : accorder les droits admin est souvent perçu comme la solution la moins coûteuse en temps pour le service IT

L'impact sécurité des droits admin locaux

Les statistiques 2025 de Microsoft Vulnerability Report montrent que 71% des vulnérabilités critiques Windows seraient neutralisées si les utilisateurs n'avaient pas de droits administrateur locaux. Les raisons :

• Un malware s'exécutant sous un compte standard ne peut pas modifier les clés de registre HKLM, installer des services Windows, désactiver Windows Defender, ou accéder aux données d'autres utilisateurs
• Les ransomwares modernes ont besoin de droits élevés pour chiffrer les fichiers système, désactiver les shadow copies et se propager via WMI/PsExec
• Les attaques de type "living off the land" (LOLBins) utilisent des outils système Windows qui nécessitent des droits élevés pour leur usage malveillant

Évaluer le niveau de risque actuel — Quick Audit

Avant de déployer EPM, auditez l'état actuel des droits admin sur votre parc via PowerShell (exécutable via Intune Proactive Remediation) :

# Lister les membres du groupe Administrateurs locaux
$admins = Get-LocalGroupMember -Group "Administrators"
$admins | Select-Object Name, ObjectClass, PrincipalSource

Sur un poste standard bien configuré, seuls deux membres devraient apparaître : le compte Administrator local (désactivé si LAPS est déployé) et un groupe de sécurité AD/Entra ID de l'IT. Si des comptes utilisateurs individuels apparaissent, c'est un risque à traiter avec EPM.

Qu'est-ce que l'Endpoint Privilege Management (EPM) Intune ?

L'Endpoint Privilege Management est une fonctionnalité introduite dans Microsoft Intune en 2023 et maturée en 2024-2026. Elle permet de définir des règles précises déterminant quand et comment un processus peut s'exécuter avec des droits élevés (administrator), sans que le compte utilisateur standard ne dispose en permanence de ces droits.

Fonctionnement technique

EPM fonctionne via un agent installé sur le poste Windows (livré automatiquement par Intune sur les appareils ciblés). Lorsqu'un utilisateur tente d'exécuter un fichier nécessitant des droits élevés (prompt UAC), l'agent EPM intercepte la demande et vérifie si une règle d'élévation s'applique :

• Si une règle automatique correspond : l'application s'élève silencieusement sans intervention utilisateur.
• Si une règle déclenchée par l'utilisateur s'applique : l'utilisateur voit une option "Exécuter avec accès élevé" dans le menu contextuel.
• Si une règle assistée est configurée : l'utilisateur soumet une demande d'élévation qui nécessite une approbation par un administrateur IT.
• Si aucune règle ne correspond et que l'utilisateur n'est pas admin local : l'UAC bloque l'exécution normalement.

Ce qu'EPM n'est pas

EPM ne remplace pas une solution PAM (Privileged Access Management) complète comme CyberArk ou BeyondTrust pour la gestion des comptes à privilèges élevés sur les serveurs. EPM est ciblé sur les postes de travail Windows et les cas d'usage courants (installations de logiciels, drivers, paramétrages spécifiques) dans un environnement endpoint.

Prérequis et licences pour Intune EPM

EPM est une fonctionnalité premium qui nécessite des licences spécifiques, distinctes de l'Intune de base.

Licences requises

EPM est disponible via deux options :

• Microsoft Intune Suite : bundle incluant EPM, Remote Help, Tunnel for MAM, Advanced Analytics et d'autres fonctionnalités avancées. Disponible en add-on sur Microsoft 365 E3/E5 ou standalone.
• Endpoint Privilege Management add-on : disponible séparément si vous ne souhaitez pas l'Intune Suite complet.

Vérifiez la disponibilité de la licence dans votre tenant : Intune → Tenant administration → Intune add-ons. EPM apparaîtra dans la liste avec son statut de licence.

Appareils supportés

• Windows 10 version 21H2 (build 19044) et supérieure
• Windows 11 toutes versions
• Appareils Entra ID-joincts ou Hybrides Entra ID-joincts
• Appareils gérés par Intune (pas en co-gestion partielle sans workload Endpoint Security dans Intune)

Rôles administratifs

Pour configurer EPM, vous avez besoin du rôle Endpoint Security Manager ou Global Administrator dans Intune. Pour approuver les demandes d'élévation assistée, un rôle spécifique EPM Approver peut être attribué à des membres du helpdesk sans droits IT complets.

Créer une politique EPM dans Intune

La configuration EPM se fait dans Endpoint Security → Endpoint Privilege Management.

Étape 1 : Activer EPM sur les appareils

1. Naviguez vers Endpoint Security → Endpoint Privilege Management → Policies
2. Cliquez sur + Create policy
3. Sélectionnez Windows elevation settings policy
4. Configurez les paramètres fondamentaux :

Étape 2 : Créer des règles d'élévation

Une fois la politique de base activée, créez les règles d'élévation via Windows elevation rules policy :

1. Nouvelle politique → Windows elevation rules policy
2. Dans Configuration settings → + Add, ajoutez vos règles

Types d'élévation — Automatique, Assistée, Déclenchée utilisateur

EPM propose trois types d'élévation, adaptés à des niveaux de risque et des usages différents.

Élévation automatique (Automatic elevation)

L'application s'exécute avec des droits élevés sans aucune action de l'utilisateur et sans prompt UAC. C'est le mode le plus transparent mais aussi le plus risqué si mal configuré.

Cas d'usage idéaux :

• Agent de monitoring (Zabbix, SCCM client, antivirus) qui doit s'exécuter avec des droits élevés
• Script de mise à jour déployé par IT
• Logiciel d'entreprise (ERP, outil CAO) dont le hash est connu et signé par un certificat d'entreprise

Précautions : utilisez impérativement le hash SHA-256 ou le certificat éditeur comme critère d'identification — jamais le chemin seul, qui est falsifiable.

Élévation déclenchée par l'utilisateur (User-confirmed elevation)

L'utilisateur voit une option "Run with elevated access" dans le menu contextuel (clic droit). Il doit confirmer mais aucune approbation IT n'est requise. Adapté pour des logiciels courants à usage ponctuel (installateurs de mises à jour validées, outils de configuration réseau pour les techniciens).

Élévation assistée avec approbation (Support-approved elevation)

L'utilisateur soumet une demande d'élévation avec une justification. Un administrateur ou membre du helpdesk approuve ou rejette la demande dans le portail Intune ou via l'application Company Portal. L'utilisateur reçoit une notification de décision. C'est le mode le plus sécurisé pour les applications dont l'élévation doit être auditée et justifiée.

Configurer les règles d'élévation — Critères d'identification

La robustesse d'EPM repose sur la précision des critères d'identification des applications autorisées à l'élévation. Trois méthodes principales :

Identification par hash SHA-256

Le hash SHA-256 du fichier exécutable est le critère le plus précis et le plus sécurisé. Toute modification du fichier (même une injection de code) change le hash, rendant la règle inopérante.

Pour obtenir le hash sous PowerShell :

Get-FileHash -Algorithm SHA256 "C:\Program Files\MonApp\setup.exe"

Collez ce hash dans le champ File hash (SHA-256) de la règle EPM. Inconvénient : à chaque mise à jour de l'application, le hash change et la règle doit être mise à jour.

Identification par certificat éditeur

Identifiez l'application via le certificat de signature de code de l'éditeur. Plus flexible que le hash (fonctionne pour toutes les versions signées par le même certificat éditeur), mais moins précis (toutes les applications signées par cet éditeur pourraient potentiellement être élevées si d'autres critères ne sont pas ajoutés).

Pour extraire le certificat :

$sig = Get-AuthenticodeSignature "C:\Program Files\MonApp\monapp.exe"
$sig.SignerCertificate | Export-Certificate -FilePath C:\temp\editeur.cer -Type CERT

Importez le fichier .cer dans la règle EPM. Combinez toujours avec le nom de fichier ou le chemin pour éviter les élévations non voulues d'autres exécutables du même éditeur.

Identification par chemin et nom de fichier

Utilisable seul uniquement pour les environnements très contrôlés où les chemins d'installation sont standardisés et en lecture seule pour les utilisateurs. En général, combinez le chemin avec le hash ou le certificat pour plus de sécurité. Exemple de chemin : %ProgramFiles%\MonERP\bin\erp_updater.exe.

Workflow d'approbation pour les élévations assistées

Le workflow d'approbation EPM est le mécanisme central de gouvernance des demandes d'élévation non pré-approuvées.

Côté utilisateur

1. L'utilisateur fait un clic droit sur l'exécutable et sélectionne "Request to run with elevated access" (si la règle de type support-approved s'applique).
2. Une boîte de dialogue s'affiche demandant une justification (champ texte libre, configurable comme obligatoire).
3. La demande est envoyée aux approbateurs configurés et l'utilisateur reçoit une notification de confirmation d'envoi.
4. Une fois la demande approuvée, l'utilisateur reçoit une notification et peut exécuter l'application dans un délai défini (ex. 24h).

Côté administrateur/helpdesk

1. Dans le portail Intune : Endpoint Security → Endpoint Privilege Management → Elevation requests
2. Liste toutes les demandes en attente avec l'utilisateur, le fichier, la justification et le hash de l'exécutable
3. L'approbateur peut Approve ou Deny avec un commentaire
4. Option : approuver pour une durée limitée (ex. 1 exécution, 24h, 7 jours)

Notifications et intégration Teams

Configurez des notifications Intune pour alerter les approbateurs des nouvelles demandes. Via Power Automate, ces notifications peuvent être intégrées à un canal Teams ou Slack pour une réponse rapide du helpdesk.

Rapports et logs EPM — Audit des élévations

L'audit complet des élévations est l'un des points forts d'EPM par rapport aux solutions alternatives.

Rapport d'élévations dans Intune

Naviguez vers Endpoint Security → Endpoint Privilege Management → Reports → Elevation report. Ce rapport liste :

• Chaque élévation effectuée (automatique, utilisateur, approuvée)
• L'utilisateur, l'appareil, la date et l'heure
• Le fichier élevé avec son hash SHA-256
• Le type d'élévation et la règle EPM qui l'a permise
• L'issue (succès/échec)

Détection des tentatives non autorisées

EPM logue également les tentatives d'élévation qui ont été refusées (aucune règle correspondante). Ces événements sont visibles dans le rapport Deny elevation report et peuvent être intégrés dans Defender for Endpoint pour une détection comportementale : un utilisateur qui tente régulièrement d'exécuter des fichiers non autorisés avec élévation peut indiquer une compromission ou un comportement problématique.

Export vers Log Analytics

Les données EPM sont incluses dans les logs Intune exportables vers Azure Monitor / Log Analytics. Créez des requêtes KQL (Kusto Query Language) pour analyser les patterns d'élévation et créer des alertes sur des comportements anormaux :

IntuneOperationalLogs
| where OperationName contains "ElevationRequest"
| summarize count() by UPN, bin(TimeGenerated, 1h)
| where count_ > 5  // Alerte si plus de 5 élévations par heure par utilisateur

EPM vs RunAs vs comptes admin locaux — Comparatif sécurité

LAPS (Local Administrator Password Solution) et EPM sont complémentaires : LAPS pour les opérations de maintenance IT nécessitant un accès admin complet ponctuel, EPM pour les élévations applicatives quotidiennes des utilisateurs standard. Microsoft recommande de déployer les deux conjointement.

Cas d'usage EPM par secteur d'activité

EPM ne se configure pas de la même façon selon le secteur d'activité et les besoins métier. Voici des exemples concrets par profil d'entreprise.

Cabinet d'expertise comptable ou juridique

Les comptables et juristes installent régulièrement des mises à jour de leurs logiciels métier (Sage, Cegid, EBP, logiciels de rédaction juridique) qui nécessitent des droits admin. Avec EPM, créez des règles d'élévation automatique pour les installateurs officiels de ces éditeurs (identifiés par leur certificat de signature de code), et des règles utilisateur-déclenchées pour les outils de configuration imprimante ou VPN. Les utilisateurs ne voient aucune différence au quotidien, mais leur compte ne dispose plus de droits admin permanents.

Entreprise industrielle avec postes OT/IoT

Les postes de supervision d'équipements industriels (SCADA, HMI) fonctionnent souvent avec des logiciels anciens nécessitant des droits admin pour accéder aux ports COM ou aux interfaces matérielles. EPM peut élever ces applications spécifiques via leur hash SHA-256 (stable tant que le logiciel n'est pas mis à jour) sans exposer l'ensemble du poste. Cette approche est recommandée dans les guides de l'ANSSI pour la sécurisation des systèmes industriels.

ESN / Cabinet de conseil IT

Les équipes techniques (développeurs, ingénieurs systèmes) ont des besoins d'élévation fréquents : installation d'outils de développement, modifications de configuration réseau, tests de logiciels clients. Créez des règles EPM spécifiques pour ce groupe (affectées à un groupe Entra ID "Technical Staff") autorisant l'élévation de catégories d'outils précises (IDE, outils de diagnostic, émulateurs) sans pour autant accorder des droits admin permanents. Le workflow d'approbation assistée peut couvrir les cas exceptionnels non prévus.

Intégration avec Privileged Identity Management (PIM) Azure

EPM gère les privilèges sur les endpoints (postes de travail). Privileged Identity Management (PIM) d'Entra ID gère les rôles privilégiés dans le cloud (Global Admin, Security Admin, Azure Subscription Owner). Ces deux solutions forment ensemble une stratégie de gestion des accès privilégiés (PAM) complète.

Scénario combiné EPM + PIM

Un technicien IT peut avoir :

• Un compte utilisateur standard sur son poste, avec EPM permettant d'élever uniquement les outils de diagnostic IT (Sysinternals, scripts PowerShell approuvés)
• Un rôle PIM "Intune Administrator" activable just-in-time pour 4 heures maximum, uniquement pour les tâches d'administration Intune
• Un rôle PIM "Security Reader" permanent pour la lecture des alertes Defender

Cette combinaison minimise la durée d'exposition des comptes privilégiés (PIM) tout en permettant les tâches opérationnelles quotidiennes (EPM) sans tickets helpdesk inutiles.

Pour une protection complémentaire au niveau poste, consultez notre guide sur la gestion du chiffrement BitLocker via Intune et notre tutoriel sur la configuration du pare-feu Windows Defender. Ces trois composantes — chiffrement, pare-feu et gestion des privilèges — forment la triade de sécurité endpoint recommandée par les frameworks Zero Trust.

FAQ — Intune Endpoint Privilege Management

EPM peut-il gérer les élévations PowerShell et les scripts ?

Oui, mais avec des précautions importantes. Vous pouvez créer une règle EPM pour powershell.exe identifiée par son hash et son chemin système. Cependant, élever PowerShell lui-même donne des droits très étendus. L'approche recommandée est plutôt d'élever un script spécifique via un wrapper compilé (.exe) signé par votre certificat d'entreprise, plutôt que d'élever l'interpréteur PowerShell directement. Les scripts PowerShell non compilés ne peuvent pas être identifiés par hash de façon fiable car leur contenu change facilement.

Que se passe-t-il si un utilisateur tente de contourner EPM en copiant un exécutable dans un autre dossier ?

Si la règle EPM est basée sur le hash SHA-256 et/ou le certificat éditeur (et non uniquement sur le chemin), déplacer l'exécutable dans un autre dossier ne change pas son hash ni son certificat — la règle s'applique toujours. Si la règle n'était basée que sur le chemin, le contournement serait effectif, ce qui illustre pourquoi le hash ou le certificat est indispensable comme critère principal d'identification.

Combien de règles EPM peut-on créer par politique ?

Microsoft ne publie pas de limite documentée stricte sur le nombre de règles par politique EPM, mais les bonnes pratiques recommandent de limiter chaque politique à 50-100 règles maximum pour maintenir des performances MDM optimales et faciliter l'audit. Regroupez les règles par catégorie (règles IT, règles Finance, règles Développeurs) dans des politiques distinctes affectées à des groupes différents.

EPM est-il compatible avec les environnements Virtual Desktop Infrastructure (VDI) ?

EPM fonctionne sur Windows 10/11 multi-session (Azure Virtual Desktop, Windows 365) à condition que les VMs soient inscrites dans Intune. Sur les environnements VDI persistants, EPM s'installe normalement. Sur les VDI non-persistants (pooled), chaque session doit recevoir la politique EPM — ce qui fonctionne si les VMs sont liées à Intune via des groupes dynamiques. Consultez la documentation Microsoft pour les spécificités de votre infrastructure VDI.

Comment migrer depuis une configuration où tous les utilisateurs sont admins locaux vers EPM sans impact business ?

La migration doit se faire en plusieurs phases : d'abord déployez EPM en mode "audit only" (sans retirer les droits admin) pour observer quelles applications nécessitent des élévations. Analysez le rapport EPM pendant 4 à 6 semaines pour identifier toutes les élévations courantes. Créez ensuite les règles d'élévation appropriées pour chaque cas d'usage identifié. Puis retirez les droits admin locaux sur un groupe pilote, validez pendant 2-4 semaines, et déployez progressivement. Cette approche évite les surprises et maintient la productivité pendant la transition.