Permission
Sécurité
Droit élémentaire d'effectuer une action précise (lire, écrire, exécuter, supprimer) sur une ressource donnée, accordé à un sujet : utilisateur, processus ou service. C'est la plus petite brique du contrôle d'accès ; un rôle ou une politique n'est jamais qu'un paquet de permissions.
Anatomie : Une permission associe trois éléments : un sujet, une action et une ressource. Sous Unix, elle tient en neuf bits rwx (propriétaire, groupe, autres) ; dans le cloud, en une ligne de politique du type s3:GetObject sur un bucket précis.
Après l'authentification : Prouver son identité ne donne aucun droit en soi. La permission intervient ensuite, quand le système vérifie si cette identité a le droit de faire ce qu'elle demande.
Moindre privilège : Le principe consiste à n'accorder que les permissions nécessaires, et pas une de plus. Un chmod 777 posé « le temps de déboguer » survit en général au projet, à son auteur et à trois migrations de serveur.
Refus par défaut : Un système bien conçu refuse tout ce qui n'est pas explicitement permis. Les moteurs qui connaissent le refus explicite (AWS IAM en tête) lui donnent le dernier mot : un seul refus annule toutes les autorisations accordées ailleurs. D'autres ne savent qu'accorder, comme le RBAC de Kubernetes, qui n'a aucune règle de refus : l'interdit n'y est que ce que personne n'a pensé à permettre.
Ce qui arrive si on s'en passe
Sans permission définie, le contrôle d'accès n'a plus rien à évaluer : soit tout est refusé et le service ne fonctionne pas, soit tout est accordé par défaut à chaque sujet authentifié. Dans ce second cas, n'importe quel compte ou processus peut lire, modifier, exécuter ou supprimer n'importe quelle ressource ; un seul identifiant compromis, ou un processus détourné, obtient alors la totalité des droits du système. Les rôles et les politiques deviennent des coquilles vides, puisqu'ils ne regroupent aucune action précise ; le moindre privilège et la séparation des tâches ne peuvent plus être appliqués. Les journaux perdent leur valeur de détection : comme aucune action n'est interdite, rien ne distingue un usage légitime d'un abus. Enfin, les sauvegardes et les journaux eux-mêmes restent effaçables par tout sujet, ce qui compromet la reprise et la traçabilité.
Explication de la marmotte
Dans une bibliothèque, chaque salle a sa fiche affichée à l'entrée : qui peut entrer, qui peut emprunter, qui peut aller chercher un livre dans la réserve. Une permission, c'est une seule ligne de cette fiche : telle personne, telle action, tel objet. Montrer sa carte à l'accueil prouve seulement qui l'on est ; c'est la ligne de la fiche qui décide si l'on ressort avec le manuscrit ancien sous le bras. Un ordinateur fonctionne pareil : chaque fichier, chaque dossier, chaque programme garde la liste de ceux qui ont le droit de le lire, de le modifier ou de le lancer. Aucune ligne au nom de celui qui demande, et la porte reste fermée, même avec le bon mot de passe.
Où ce terme est utilisé
- Mettre en place un accès JIT AWS pour comptes à privilèges (8 occurrences)
- Politique de sécurité des extensions navigateur en entreprise (7 occurrences)
- ReBAC Zanzibar pour les autorisations relationnelles fines (6 occurrences)
- Attaque par confusion de scope OAuth (4 occurrences)
- Auditer l'héritage des permissions et le droit effectif (4 occurrences)
- Installer et utiliser GitHub Copilot en mode agent (4 occurrences)
- Mettre en œuvre les revues d’accès IGA et la SoD (4 occurrences)
- CICD-SEC-2 : gestion des identités et des accès inadéquate (3 occurrences)
- Comment limiter le mouvement latéral après compromission (3 occurrences)
- Configurer le moindre privilège sur un compte cloud existant (3 occurrences)