Moindre privilège et accès Just-In-Time
Le moindre privilège limite les droits au strict besoin, l'accès Just-In-Time les accorde pour une durée limitée. Ce que le salarié fait.
En 30 secondes
- Où ça arrive
- Dans tout poste ou service où des droits d'administrateur existent, par exemple l'administration de Microsoft 365 ou d'un annuaire d'entreprise2.
- Ce que veut l'attaquant
- Utiliser un compte existant et ses droits, ce qui lui évite parfois d'employer un logiciel malveillant et rend sa présence plus difficile à repérer4.
- Le réflexe
- Demander un accès élevé pour une durée limitée avec un motif clair, ne jamais prêter ses droits d'administrateur, et signaler les droits qui ne servent plus.
- Si c'est déjà fait
- Prévenir le service informatique, qui peut retirer des droits devenus inutiles lors d'une révision des accès3.
De quoi parle-t-on
Le moindre privilège est un principe de sécurité : un système doit limiter les droits d'accès des utilisateurs, ou des programmes qui agissent pour eux, au minimum nécessaire pour accomplir les tâches assignées1. Un salarié qui n'a besoin que de lire un dossier n'a pas à pouvoir le supprimer.
L'accès Just-In-Time (juste-à-temps) pousse l'idée plus loin pour les droits élevés. Les utilisateurs reçoivent des autorisations temporaires pour effectuer des tâches privilégiées, et l'accès est accordé uniquement au moment où ils en ont besoin2. Une fois le délai écoulé, l'accès privilégié est automatiquement supprimé3.
Questions directes
Pourquoi limiter les droits d'un salarié de confiance ?
Les organisations limitent le nombre de personnes ayant accès aux ressources sensibles pour réduire deux risques : qu'un utilisateur malveillant accède à ces données, et qu'un utilisateur autorisé ait par inadvertance un impact sur une ressource sensible2. Microsoft ajoute qu'en limitant les rôles et les étendues, on limite les ressources menacées si le compte est compromis3.
Que veut dire « juste-à-temps » concrètement ?
Le salarié n'a pas de droit d'administrateur permanent. Il est « éligible » à un rôle et l'active quand il doit effectuer une tâche privilégiée. L'activation peut demander une vérification multifacteur, une justification professionnelle ou l'accord d'un approbateur désigné2. Une fois le rôle activé, il reste utilisable pendant une période prédéfinie, puis l'utilisateur doit l'activer de nouveau2.
Le moindre privilège concerne-t-il seulement les administrateurs ?
Non. L'OWASP le décrit comme une règle à appliquer à tous les niveaux : un comptable et un commercial occupent le même rang hiérarchique, mais n'ont pas besoin des mêmes ressources. Le comptable ne devrait pas accéder à la base de données clients, ni le commercial aux données de paie5.
Que se passe-t-il si une demande d'accès expire ?
Selon la documentation de Microsoft, quand une attribution de rôle approche de son expiration, l'utilisateur peut demander une extension. Une fois expirée, il peut demander un renouvellement. Les deux demandes passent par l'approbation d'un administrateur général ou d'un administrateur de rôle privilégié2.
1Comment ça marche2 min
Le fonctionnement décrit ici suit l'outil Privileged Identity Management de Microsoft, un exemple parmi d'autres. Un administrateur attribue un rôle à un utilisateur, à un groupe ou à une identité de service. L'attribution précise l'étendue (le rôle ne vaut que pour un ensemble donné de ressources), son type (éligible ou active) et sa durée, avec des dates de début et de fin ou sans limite2.
Pour activer un rôle éligible, l'utilisateur choisit une durée d'activation comprise dans les limites fixées par les administrateurs et indique la raison de sa demande2. L'outil peut exiger une approbation, imposer l'authentification multifacteur, envoyer des notifications lors de l'activation et conserver un historique des audits2. Le MITRE cite aussi les rôles éphémères d'autres fournisseurs de cloud pour accorder des permissions élevées limitées dans le temps6.
Microsoft recommande d'empiler plusieurs contrôles, car aucune fonctionnalité seule ne couvre tous les cas. Son exemple : un rôle personnalisé limité à une unité administrative, pour qu'un administrateur du support régional ne puisse réinitialiser que les mots de passe de sa région. L'activation passe ensuite par PIM, avec approbation, puis l'accès conditionnel exige un appareil conforme et l'authentification multifacteur3.
Le NCSC britannique définit ainsi l'approche « zero trust » : la confiance inhérente au réseau est retirée, le réseau est supposé hostile et chaque requête est vérifiée selon une politique d'accès7. La CISA y associe des décisions d'accès au moindre privilège, requête par requête8.
2Ce que vous faites1 min
- Demandez l'accès au moment du besoin, avec une durée adaptée à la tâche et un motif précis. Le motif donné à l'activation sert à comprendre pourquoi le rôle a été utilisé2.
- Utilisez le rôle étroit qui correspond à la tâche. Microsoft déconseille d'attribuer des rôles plus larges ou sur des étendues plus grandes, même s'ils semblent plus pratiques3.
- Gardez vos droits d'administrateur pour vous. Une activation de rôle est faite par un utilisateur et donne lieu à une notification, et l'historique des audits la conserve2. OWASP note que, sans journalisation correcte, une violation d'accès peut rester impossible à attribuer à un individu5.
- Si vous changez d'équipe ou de mission, demandez le retrait des droits de l'ancienne fonction. Microsoft relève que sans audit, les personnes qui changent d'équipe accumulent des accès inutiles3.
- Répondez aux révisions d'accès : elles servent à vérifier que les utilisateurs ont toujours besoin de leurs rôles2.
- Activez l'authentification multifacteur sur les comptes d'administration. Microsoft indique que, selon ses études, un compte est 99,9 % moins susceptible d'être compromis avec elle3.
3Les pièges2 min
Les droits qui s'accumulent. L'OWASP appelle « privilege creep » le cas où les privilèges des utilisateurs dépassent ceux définis au départ. Il recommande une revue périodique, et rappelle qu'il est plus facile d'ajouter des permissions que d'en retirer5.
Les comptes d'administration permanents. L'accès privilégié permanent est ce que PIM vise à éliminer pour les utilisateurs en rôle privilégié3. Microsoft recommande de donner le rôle d'administrateur général à moins de cinq personnes et de limiter les attributions de rôles privilégiés à moins de 10, car ces rôles permettent une élévation de privilèges3. Il prévoit une exception : deux comptes d'accès d'urgence, attribués définitivement, non rattachés à des personnes et réservés aux situations de « casse de vitre »3.
Les comptes oubliés. Le MITRE signale que des adversaires peuvent abuser de comptes inactifs, par exemple ceux de personnes parties de l'organisation, parce que l'ancien titulaire n'est plus là pour remarquer une activité anormale4. Le MITRE recommande aussi de désactiver les comptes après une période d'inactivité (30 jours en exemple) et de supprimer les comptes sans propriétaire lors des audits9.
Les comptes de service trop puissants. Les attributions de rôles peuvent viser des principaux de service ou des identités managées, au même titre que des personnes2. Pour les administrateurs, Microsoft distingue trois aspects d'une attribution de rôle : un ensemble spécifique d'autorisations, sur une étendue spécifique, pour une période spécifique3.
Les mêmes identifiants partout. Le MITRE s'inquiète du recoupement des permissions entre comptes locaux, de domaine et cloud : un adversaire peut passer d'un compte à l'autre jusqu'à un niveau élevé d'accès, comme administrateur de domaine4.
4Cas réels1 min
2015 : l'attaque contre le réseau électrique ukrainien
Selon le MITRE, lors de l'attaque de 2015 contre le réseau électrique ukrainien, le groupe Sandworm Team a utilisé des comptes valides sur le réseau d'entreprise pour élever ses privilèges, se déplacer latéralement et s'y installer durablement4. La source ne détaille pas quels droits ces comptes portaient.
Fiche
- Identifiant
- CP-197
- Aile
- 3. Protocoles et défense
- Compétence Brain
- Contrôler les accès (control_access)
- Réflexe Brain
- cr-029
- Schéma
- G3 · Coupe Anatomique
- Langues
- de, en, fr
- Sources
- 9 sources vérifiées le 3 novembre 2026
Sources9 sources
- NIST, « least privilege - Glossary | CSRC ». https://csrc.nist.gov/glossary/term/least_privilege (consulté le 3 novembre 2026)
- Microsoft, « Qu’est-ce que Microsoft Entra Privileged Identity Management ? ». https://learn.microsoft.com/fr-fr/entra/id-governance/privileged-identity-management/pim-configure (consulté le 3 novembre 2026)
- Microsoft, « Meilleures pratiques pour les rôles Microsoft Entra ». https://learn.microsoft.com/fr-fr/entra/identity/role-based-access-control/best-practices (consulté le 3 novembre 2026)
- MITRE ATT&CK, « Valid Accounts, Technique T1078 - Enterprise ». https://attack.mitre.org/techniques/T1078/ (consulté le 3 novembre 2026)
- OWASP, « Authorization - OWASP Cheat Sheet Series ». https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html (consulté le 3 novembre 2026)
- MITRE ATT&CK, « Privileged Account Management, Mitigation M1026 - Enterprise ». https://attack.mitre.org/mitigations/M1026/ (consulté le 3 novembre 2026)
- NCSC (Royaume-Uni), « Zero trust architecture design principles ». https://www.ncsc.gov.uk/collection/zero-trust/architecture-design-principles (consulté le 3 novembre 2026)
- CISA, « Zero Trust Maturity Model ». https://www.cisa.gov/zero-trust-maturity-model (consulté le 3 novembre 2026)
- MITRE ATT&CK, « User Account Management, Mitigation M1018 - Enterprise ». https://attack.mitre.org/mitigations/M1018/ (consulté le 3 novembre 2026)
Citer cet article
Brain, « Moindre privilège et accès Just-In-Time », Cyberpedia, 2026. https:/
BibTeX
@misc{brain_cp197_fr_2026,
author = {Brain},
title = {Moindre privilège et accès Just-In-Time},
year = {2026},
howpublished = {Cyberpedia},
url = {https://startbrain.io/cyberpedia/fr/articles/moindre-privilege-acces-jit/},
note = {CC BY 4.0}
}