Principe du Moindre Privilège, Expliqué

Le principe du moindre privilège paraît évident une fois qu'on l'énonce : donner à un compte, un processus ou un utilisateur seulement l'accès nécessaire pour faire son travail, rien de plus. L'écart entre l'énoncer et faire réellement fonctionner ses systèmes ainsi est là où la plupart des brèches passent d'un incident mineur à un compromis complet du domaine.

Ce que cela signifie réellement

Le principe du moindre privilège (PoLP) énonce que chaque sujet dans un système — un utilisateur, un compte de service, une application, un conteneur — doit fonctionner avec l'ensemble minimal de permissions requises pour accomplir sa fonction. Pas les permissions qui sont commodes. Pas les permissions que quelqu'un a accordées il y a trois ans et a oublié de révoquer. Le minimum.

Cela s'applique à chaque couche : permissions du système de fichiers, rôles de base de données, périmètres d'API, politiques IAM cloud, règles de pare-feu, accès sudo. Un processus serveur web lisant des fichiers statiques n'a pas besoin d'accès en écriture à /etc. Un script de reporting qui n'exécute que des requêtes SELECT n'a pas besoin d'un rôle de base de données avec les droits DROP TABLE. Un stagiaire en marketing n'a pas besoin d'être administrateur de domaine parce que c'était plus facile que de déterminer le bon groupe.

Pourquoi c'est plus important que ça ne le paraît

Quand un attaquant compromise un compte ou un processus, il hérite de tout ce que ce compte peut faire. Si l'ordinateur portable d'un employé hameçonné n'a accès qu'aux partages de fichiers pertinents pour son équipe, le rayon d'impact de cet hameçonnage est contenu. Si ce même compte se trouve avoir les droits d'administrateur de domaine parce que le service IT l'a configuré ainsi une fois pour du dépannage et ne l'a jamais annulé, l'attaquant possède maintenant le réseau.

C'est la logique derrière la plupart des rapports d'investigation post-brèche : l'accès initial avait peu de valeur, mais le mouvement latéral à travers des comptes surprivilégiés l'a transformé en ransomware dans tout l'environnement. Le privilège excessif ne cause pas le compromis initial, mais c'est presque toujours ce qui rend le compromis coûteux.

Où cela se manifeste en pratique

IAM Cloud. AWS, Azure et GCP adoptent par défaut un comportement permissif si vous n'êtes pas prudent — une politique IAM avec "Action": "*" et "Resource": "*" passera la validation et fonctionnera bien, jusqu'à ce qu'une clé d'accès divulguée donne à un attaquant un contrôle complet du compte. Limitez les politiques à des actions spécifiques et des ARN de ressources au lieu d'utiliser des caractères génériques.

Comptes de service. Ce sont souvent les pires contrevenants parce que personne ne les examine comme ils examinent les comptes humains. Un pipeline CI/CD qui déploie vers un seul bucket S3 ne devrait pas détenir des identifiants qui peuvent lire chaque bucket du compte.

Rôles de base de données. Séparez les rôles de reporting en lecture seule des rôles d'application qui nécessitent INSERT/UPDATE, et séparez ceux-ci du rôle DBA qui peut modifier le schéma. PostgreSQL et MySQL supportent tous deux des déclarations GRANT granulaires — utilisez-les au lieu de donner à chaque connexion d'application l'équivalent de root.

Sudo et administrateur local. L'élévation juste-à-temps (demander l'accès, l'obtenir pour une fenêtre limitée, le perdre automatiquement) bat toujours les droits d'administrateur permanents. Des outils comme sudo avec des règles limitées dans le temps, ou des solutions PAM dans les environnements d'entreprise, existent spécifiquement pour cela.

La tension avec