Attribuer les droits d'accès selon le principe du moindre privilège

Ce que c'est

Le principe du moindre privilège (least privilege) exige qu'un compte ou un processus dispose exactement des droits qu'exige sa tâche — pas de ceux qui seraient commodes. Linux offre pour cela des outils plus fins que « root ou pas root » : les capabilities décomposent les droits du superutilisateur en capacités individuelles ; CAP_NET_BIND_SERVICE, par exemple, autorise uniquement la liaison à des ports inférieurs à 1024, sans le reste. Dans PostgreSQL, GRANT attribue des droits par objet et par action (par exemple SELECT, INSERT, UPDATE, DELETE) à des rôles, et les rôles peuvent être membres d'autres rôles, de sorte que les droits sont regroupés plutôt que distribués un par un.

Pourquoi c'est important

Le dommage d'une erreur ou d'une intrusion est limité par les droits de l'identité concernée. Un service web disposant d'un rôle qui ne peut que lire et écrire dans deux tables ne peut pas, en cas d'injection SQL, supprimer le schéma. Un script exécuté avec un compte standard ne peut pas, à la suite d'une faute de frappe, vider le répertoire racine. Pour les agents automatisés, cela vaut doublement : ils exécutent des instructions dont ils ne peuvent pas toujours juger l'origine, et leurs droits constituent le plafond du dommage possible.

Comment l'appliquer

• Une identité propre par service et par environnement : un rôle de base de données propre, une clé d'API propre, un utilisateur système propre ; jamais un compte « app » partagé pour tout.
• Dériver les droits de la tâche et les consigner : quelles tables, quelles actions, quels répertoires, quelles destinations réseau ? Tout le reste n'est pas accordé. Les migrations s'exécutent avec un rôle séparé, dans une étape séparée.
• Démarrer les processus sans root ; là où un droit root est nécessaire, n'accorder que la capability isolée et abandonner les autres.
• Pour les personnes : compte standard sans droits particuliers, élévation seulement temporaire et journalisée, comptes d'administration séparés du compte quotidien.
• Refus par défaut : les nouvelles ressources ne sont accessibles à personne tant que quelqu'un n'y a pas inscrit un droit — jamais l'inverse.
• Nettoyer régulièrement : retirer les droits qui n'ont pas été utilisés depuis longtemps ; supprimer le jour même les personnes parties et les services désactivés.

Pièges

Les droits croissent : chaque dépannage en ajoute un, personne ne le retire. Des rôles fourre-tout comme « developer » avec accès à la production. Le service a peu de droits, mais son jeton de déploiement est administrateur. L'accès en lecture est considéré comme inoffensif, alors qu'il expose des données personnelles et des secrets. Le principe du moindre privilège limite l'usage abusif de droits d'autrui, pas l'usage abusif de ses propres droits légitimes ; cela nécessite la journalisation et le principe des quatre yeux.