--- id: CP-197 slug: moindre-privilege-acces-jit lang: fr title: Moindre privilège et accès Just-In-Time description: 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. canonical_url: https://startbrain.io/cyberpedia/fr/articles/moindre-privilege-acces-jit/ markdown_url: https://startbrain.io/cyberpedia/fr/articles/moindre-privilege-acces-jit.md publisher: Brain (https://startbrain.io) license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) cite_as: Brain, « Moindre privilège et accès Just-In-Time », Cyberpedia, 2026. https://startbrain.io/cyberpedia/fr/articles/moindre-privilege-acces-jit/ (CC BY 4.0) wing: 3 theme: control_access reflex: cr-029 schema: G3 updated: "2026-11-03" translations: fr: https://startbrain.io/cyberpedia/fr/articles/moindre-privilege-acces-jit/ en: https://startbrain.io/cyberpedia/en/articles/least-privilege-just-in-time-access/ de: https://startbrain.io/cyberpedia/de/articles/minimale-rechte-just-in-time-zugriff/ es: https://startbrain.io/cyberpedia/es/articles/minimo-privilegio-acceso-jit/ sources: - "n": 1 title: least privilege - Glossary | CSRC publisher: NIST url: https://csrc.nist.gov/glossary/term/least_privilege accessed: "2026-11-03" - "n": 2 title: Qu’est-ce que Microsoft Entra Privileged Identity Management ? publisher: Microsoft url: https://learn.microsoft.com/fr-fr/entra/id-governance/privileged-identity-management/pim-configure accessed: "2026-11-03" - "n": 3 title: Meilleures pratiques pour les rôles Microsoft Entra publisher: Microsoft url: https://learn.microsoft.com/fr-fr/entra/identity/role-based-access-control/best-practices accessed: "2026-11-03" - "n": 4 title: Valid Accounts, Technique T1078 - Enterprise publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1078/ accessed: "2026-11-03" - "n": 5 title: Authorization - OWASP Cheat Sheet Series publisher: OWASP url: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html accessed: "2026-11-03" - "n": 6 title: Privileged Account Management, Mitigation M1026 - Enterprise publisher: MITRE ATT&CK url: https://attack.mitre.org/mitigations/M1026/ accessed: "2026-11-03" - "n": 7 title: Zero trust architecture design principles publisher: NCSC (Royaume-Uni) url: https://www.ncsc.gov.uk/collection/zero-trust/architecture-design-principles accessed: "2026-11-03" - "n": 8 title: Zero Trust Maturity Model publisher: CISA url: https://www.cisa.gov/zero-trust-maturity-model accessed: "2026-11-03" - "n": 9 title: User Account Management, Mitigation M1018 - Enterprise publisher: MITRE ATT&CK url: https://attack.mitre.org/mitigations/M1018/ accessed: "2026-11-03" --- # Moindre privilège et accès Just-In-Time 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ées [1]. 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 besoin [2]. Une fois le délai écoulé, l'accès privilégié est automatiquement supprimé [3]. ## 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'entreprise [2]. - 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érer [4]. - 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ès [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 sensible [2]. Microsoft ajoute qu'en limitant les rôles et les étendues, on limite les ressources menacées si le compte est compromis [3]. ### 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 nouveau [2]. ### 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 paie [5]. ### 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]. ## Comment ça marche 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 limite [2]. 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 demande [2]. L'outil peut exiger une approbation, imposer l'authentification multifacteur, envoyer des notifications lors de l'activation et conserver un historique des audits [2]. 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 temps [6]. 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 multifacteur [3]. 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ès [7]. La CISA y associe des décisions d'accès au moindre privilège, requête par requête [8]. ## Ce que vous faites - 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 pratiques [3]. - 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 conserve [2]. OWASP note que, sans journalisation correcte, une violation d'accès peut rester impossible à attribuer à un individu [5]. - 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 inutiles [3]. - Répondez aux révisions d'accès : elles servent à vérifier que les utilisateurs ont toujours besoin de leurs rôles [2]. - 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 elle [3]. ## Les pièges 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 retirer [5]. 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èges [3]. 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é anormale [4]. 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 audits [9]. 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 personnes [2]. 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écifique [3]. 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 domaine [4]. ## Cas réels ### 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 durablement [4]. La source ne détaille pas quels droits ces comptes portaient. ## Sources 1. NIST, « least privilege - Glossary | CSRC ». https://csrc.nist.gov/glossary/term/least_privilege (consulté le 3 novembre 2026) 2. 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) 3. 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) 4. MITRE ATT&CK, « Valid Accounts, Technique T1078 - Enterprise ». https://attack.mitre.org/techniques/T1078/ (consulté le 3 novembre 2026) 5. OWASP, « Authorization - OWASP Cheat Sheet Series ». https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html (consulté le 3 novembre 2026) 6. MITRE ATT&CK, « Privileged Account Management, Mitigation M1026 - Enterprise ». https://attack.mitre.org/mitigations/M1026/ (consulté le 3 novembre 2026) 7. NCSC (Royaume-Uni), « Zero trust architecture design principles ». https://www.ncsc.gov.uk/collection/zero-trust/architecture-design-principles (consulté le 3 novembre 2026) 8. CISA, « Zero Trust Maturity Model ». https://www.cisa.gov/zero-trust-maturity-model (consulté le 3 novembre 2026) 9. MITRE ATT&CK, « User Account Management, Mitigation M1018 - Enterprise ». https://attack.mitre.org/mitigations/M1018/ (consulté le 3 novembre 2026) --- Source originale : Cyberpedia, l'encyclopédie publique de cybersécurité et d'IA publiée par Brain. Version canonique : https://startbrain.io/cyberpedia/fr/articles/moindre-privilege-acces-jit/ Vous pouvez reprendre ce texte librement sous licence CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/), à condition de citer « Brain, Cyberpedia » avec un lien vers l'adresse ci-dessus.