Moindre privilège.

Le principe, et pourquoi il échoue sans cesse en pratique

Le moindre privilège est facile à énoncer et difficile à vivre. Chaque identité, qu'il s'agisse d'une personne, d'un compte de service, d'un script d'automatisation ou d'une clé d'API, devrait détenir exactement les permissions que sa tâche exige et rien de plus. La défaillance résulte rarement d'une décision délibérée d'attribuer trop de droits. Elle relève de l'accumulation. Quelqu'un a besoin de droits d'administration pour une migration ponctuelle et l'octroi n'est jamais retiré.

Un compte de service est créé avec des portées trop larges parce que les restreindre demanderait un après-midi de tests que personne n'a le temps de mener. Une équipe se voit attribuer un rôle conçu pour une autre équipe parce que c'était le plus proche disponible. Au fil des mois, les identités accumulent des permissions comme un bureau accumule du papier, et personne ne peut expliquer pourquoi telle ou telle est là.

Cette accumulation constitue la surface d'attaque. Lorsqu'un compte surdoté en permissions est hameçonné, divulgué ou détourné discrètement, le rayon d'impact correspond à tout ce que ce compte pouvait atteindre, ce qui dépasse généralement de loin son rôle réel. La discipline du moindre privilège ne réside pas dans l'octroi initial, qui en est la partie facile. Elle réside dans le travail continu de suppression de ce qui n'est plus nécessaire et dans la capacité à justifier ce qui demeure.

Comment les praticiens le mettent réellement en œuvre

Le moindre privilège est une habitude opérationnelle soutenue par l'outillage, et non une configuration ponctuelle. Le travail se concentre autour de quelques activités récurrentes :

• Conception des rôles et des permissions : construire les rôles autour des fonctions métier afin que l'octroi d'un accès soit une correspondance délibérée, et non une copie de ce que détenait la personne précédente.
• Accès juste-à-temps et juste-suffisant : accorder des droits élevés pour la fenêtre durant laquelle ils sont nécessaires et les retirer automatiquement ensuite, plutôt que de laisser en place des permissions d'administration permanentes.
• Revues d'accès : réexaminer périodiquement qui détient quoi et exiger qu'un propriétaire confirme que chaque octroi est toujours justifié. Tout ce que personne ne veut endosser est révoqué.
• Séparation des tâches : scinder les actions sensibles de sorte qu'aucune identité unique ne puisse à la fois initier et approuver une opération à haut risque, ce qui revient à appliquer le moindre privilège aux flux de travail plutôt qu'aux données.
• Identités machines : traiter les comptes de service, les jetons et les identifiants de pipeline avec la même rigueur que les utilisateurs humains, car ce sont souvent les plus surdotés en permissions et les moins revus.

Sa place parmi le zero trust, l'IAM et le PAM

Le moindre privilège est un principe. Les termes voisins constituent la mécanique qui le met en œuvre. La gestion des identités et des accès (IAM) est le système qui définit les identités et ce qu'elles peuvent faire ; le moindre privilège est donc la règle que l'IAM est censée faire respecter. La gestion des accès à privilèges (PAM) est la discipline plus stricte appliquée aux comptes les plus à risque, là où le moindre privilège importe le plus et où réside généralement l'élévation juste-à-temps.

Le zero trust est l'architecture plus large qui présume qu'aucune identité n'est digne de confiance par défaut et qui vérifie chaque requête ; le moindre privilège en est l'un des mécanismes fondamentaux, car vérifier une requête n'aide que si l'accès accordé est déjà minimal. On peut tenir le principe sans l'outillage, mais à toute échelle réelle, le principe sans l'IAM, le PAM et des revues régulières se délite discrètement en surprovisionnement.

L'idée traverse les référentiels même là où la formulation exacte varie. L'annexe A de l'ISO/IEC 27001 traite du contrôle d'accès, des droits d'accès à privilèges et de la revue périodique des droits d'accès des utilisateurs. La famille de contrôle d'accès du NIST est bâtie autour du moindre privilège et de la séparation des tâches en tant que principes nommés. Les CIS Controls exigent un usage contrôlé des privilèges d'administration et une gestion des comptes. Les auditeurs ne veulent pas seulement constater qu'un accès a été correctement accordé une fois. Ils attendent la preuve d'un cycle de revue continu, et un compte d'administration permanent que personne ne revoit est traité comme une non-conformité, et non comme une commodité.