Moindre privilège : appliquer le principe aux comptes, rôles et services

Niveau : débutant à intermédiaire.

Prérequis : distinguer compte, rôle, permission, ressource, authentification et autorisation. Une lecture préalable de l’article sur les différences entre identité et accès facilite l’exercice, mais aucun produit IAM n’est requis.

L’exercice utilise un inventaire fictif dans un fichier local. Il ne demande aucun changement sur un annuaire, un service cloud ou un environnement professionnel.

Le moindre privilège limite les capacités d’une personne, d’un programme ou d’un processus à ce qui est nécessaire pour accomplir une tâche autorisée. Le contrôle AC-6 du NIST SP 800-53 Rev. 5 relie ce principe aux fonctions et tâches assignées. La formulation compte : « accès à la finance » reste vague, tandis que « lire les factures de l’entité A pendant la clôture » décrit ressource, action, périmètre et durée.

Le but n’est pas d’obtenir le nombre minimal de permissions à tout prix. Une restriction qui empêche une tâche légitime sera contournée ou supprimée. Il faut accorder un ensemble suffisant, compréhensible et testable, sans capacités étrangères au besoin. Cette décision dépend donc d’une analyse du travail réel.

Pour chaque accès, note six éléments : identité, action, ressource, contexte, durée et approbateur. Ajoute la preuve attendue, comme une demande approuvée, une règle de rôle ou un journal d’élévation. Cette structure rend les écarts visibles et prépare la révocation. Un rôle nommé lecture-factures-A est plus vérifiable qu’un groupe divers-finance accumulé au fil des années.

Un compte utilisé pour la messagerie, la navigation et les documents ne devrait pas disposer en permanence de capacités d’administration. Sépare l’usage quotidien de l’administration afin de réduire les occasions d’utiliser un privilège dans un contexte risqué. Associe chaque compte privilégié à une personne ou à un propriétaire identifiable, sans recourir à un compte partagé lorsque l’attribution individuelle est possible.

La séparation seule ne suffit pas. Définis les systèmes administrables, les commandes ou fonctions permises, les postes autorisés, les horaires éventuels et la durée. Un administrateur de postes n’a pas automatiquement besoin d’administrer l’annuaire, les sauvegardes et la facturation cloud. Les comptes de secours demandent une protection, un inventaire, des tests contrôlés et une revue particulière.

L’authentification multifacteur protège certains parcours, mais elle ne réduit pas la liste des permissions. Un compte fortement authentifié peut encore supprimer trop de ressources. Le moindre privilège agit donc après et autour de l’authentification : droits ciblés, élévation contrôlée, traces, expiration et révocation. La MFA reste une mesure complémentaire, pas la définition du principe.

Le contrôle par rôles regroupe des permissions correspondant à une fonction stable. Commence par les tâches : consulter une commande, corriger une adresse, rembourser dans une limite donnée ou publier un rapport. Regroupe ensuite les tâches cohérentes dans des rôles, puis attribue les rôles aux identités. Ne pars pas d’un ancien supercompte pour retirer quelques droits au hasard.

Des rôles trop larges créent un excès de privilèges. Des rôles trop nombreux deviennent illisibles et favorisent les attributions directes. Cherche un équilibre : socle commun par fonction, périmètres séparés pour les ressources sensibles et mécanisme explicite pour les exceptions temporaires. Interdis les combinaisons incompatibles lorsqu’une séparation des tâches est nécessaire, par exemple créer un fournisseur et approuver seul son paiement.

L’OWASP Authorization Cheat Sheet recommande le refus par défaut et la validation des permissions sur chaque requête. Teste un rôle avec des cas positifs et négatifs : action permise sur la bonne ressource, action interdite, ressource d’une autre équipe et objet créé après l’attribution. Un rôle correct sur le papier peut être contredit par une permission héritée ou une règle applicative plus large.

Les identités non humaines méritent le même niveau d’attention. Une application, une tâche planifiée ou un agent de sauvegarde doit utiliser une identité distincte, avec un propriétaire, un objectif et une date de revue. Évite les secrets partagés entre plusieurs services : une fuite devient alors difficile à attribuer et la rotation peut interrompre plusieurs composants.

Accorde au service les opérations exactes. Un générateur de rapport peut lire une vue définie sans modifier toute la base. Un processus qui dépose un fichier n’a pas nécessairement besoin de lister ou supprimer le répertoire. Limite aussi les environnements : une identité de test ne doit pas atteindre la production. Lorsque la plateforme le permet, préfère des identités gérées ou des justificatifs de courte durée à un secret statique copié dans un fichier.

Documente la dépendance avant révocation. Un compte sans connexion interactive visible peut encore être utilisé par une automatisation mensuelle. Recherche les appels, propriétaires, coffres, configurations et journaux, puis réalise une désactivation contrôlée avec retour arrière préparé. Le moindre privilège ne justifie pas une suppression aveugle qui rend un service indisponible. Il exige une réduction mesurée et vérifiée.

Un besoin d’administration ponctuel ne justifie pas un rôle permanent. Un mécanisme d’élévation temporaire peut accorder une capacité après une demande, une approbation et une vérification du contexte, puis la retirer automatiquement. Fixe une durée adaptée à la tâche, pas une valeur arbitraire si courte qu’elle provoque des renouvellements incontrôlés.

La décision doit préciser le rôle activé, le périmètre, le motif, l’approbateur et l’expiration. Une demande « admin complet » sans ressource ni action reste insuffisante. Pour une urgence, prévois un parcours distinct, journalisé et revu après usage. L’accès exceptionnel ne doit pas devenir la voie normale.

Le NIST SP 800-207 sur l’architecture Zero Trust met l’accent sur des décisions d’accès explicites, dynamiques et limitées à une session ou demande. Cela ne signifie pas qu’un moteur automatique connaît toujours le bon niveau de droit. Les attributs peuvent être obsolètes et les règles erronées. Conserve une possibilité de refus, une procédure de correction et des journaux permettant de comprendre la décision.

Une revue d’accès ne consiste pas à envoyer une longue liste puis enregistrer un clic d’approbation. Donne au responsable un contexte lisible : identité, fonction, propriétaire, rôle, permissions sensibles, dernière utilisation pertinente, date d’attribution, expiration et ressources concernées. Sépare les comptes humains, comptes de service, accès externes et privilèges d’urgence.

Compare trois vues : droits attendus, droits configurés et droits observés. Une permission inutilisée peut être superflue, mais l’absence d’usage récent ne suffit pas toujours : une capacité de reprise annuelle peut être légitime. À l’inverse, un droit fréquemment utilisé peut rester excessif. Vérifie le besoin avec le propriétaire de la tâche.

Les CIS Controls, contrôle 6 sur la gestion des accès couvrent la création, l’attribution, la revue et la révocation des accès. Déclenche aussi des revues après un départ, un changement de poste, la fin d’un contrat, un incident ou la suppression d’un service. La révocation doit atteindre les groupes, rôles directs, sessions actives, clés, jetons, secrets, accès fédérés et mécanismes de récupération concernés.

Mesure le délai entre l’événement déclencheur et la suppression effective, le nombre de privilèges sans propriétaire, les exceptions expirées encore actives et les échecs de révocation. Ces indicateurs montrent un processus, sans prouver à eux seuls que chaque permission restante est correcte.

Crée revue-acces.md avec cet inventaire fictif :

lea | support | tickets:read, tickets:update, users:delete | permanent | usage delete: jamais
sam | finance | invoices:read, invoices:approve, vendors:create | permanent | cumul sensible
svc-report | service | database:read, database:write | permanent | écritures: aucune
noa | prestataire | docs:read, admin:full | fin prévue 2026-08-31 | compte actif

Travaille uniquement sur ce fichier. Pour chaque ligne, ajoute besoin, décision, propriétaire, échéance, preuve et retour arrière. Propose de retirer users:delete à lea après validation du responsable support. Pour sam, sépare la création de fournisseur et l’approbation ou documente un contrôle compensatoire. Pour svc-report, remplace l’accès global par une lecture de la vue nécessaire, après un test de rapport. Pour noa, suspends l’accès arrivé à échéance, révoque les sessions et demande une nouvelle justification si la mission continue.

Ne modifie aucun compte réel. Note à confirmer lorsque le scénario ne fournit pas assez d’éléments. Ajoute un test positif et un test négatif par identité, par exemple lecture de ticket permise et suppression d’utilisateur refusée pour lea.

Critère observable

Ton tableau final contient quatre décisions, quatre propriétaires ou mentions à confirmer, une échéance par accès conservé et huit tests au total. Il retire ou suspend les quatre capacités signalées comme excessives, sans supprimer les capacités nécessaires décrites. Chaque révocation comporte une preuve attendue et un retour arrière borné.

• Réduire le principe à la MFA. Elle vérifie mieux un accès, mais ne limite ni l’action, ni la ressource, ni la durée.
• Attribuer un rôle par copie. Reproduire les droits d’un collègue copie aussi ses exceptions historiques.
• Utiliser des comptes partagés. L’attribution, la révocation individuelle et l’enquête deviennent fragiles.
• Oublier les droits hérités. Groupes imbriqués, rôles fédérés et politiques applicatives peuvent élargir l’accès effectif.
• Créer des rôles trop fins. Une explosion de rôles rend la revue impraticable et encourage les contournements.
• Supprimer sans vérifier les dépendances. Une identité de service apparemment inactive peut soutenir une tâche rare.
• Conserver une exception sans échéance. Une urgence ponctuelle devient un privilège permanent.
• Confondre non-usage et inutilité. Les accès de reprise nécessitent une justification et un test adaptés.
• Valider une revue sans contexte. Un intitulé de groupe ne révèle pas toujours ses permissions effectives.

Le moindre privilège réduit l’exposition et l’impact potentiel, mais ne supprime pas les vulnérabilités, les erreurs de politique ou les abus permis par une tâche légitime. Il doit s’intégrer à la séparation des tâches, à la journalisation, au durcissement, à la détection et à la reprise.

Maintiens le dispositif comme un cycle : découvrir, justifier, réduire, tester, observer, revoir et révoquer. Priorise les privilèges d’administration, les données sensibles, les identités sans propriétaire, les accès tiers et les secrets durables. Une progression mesurée et réversible apporte davantage de preuves qu’une campagne massive dont les effets ne sont pas testés.