Le moindre privilège appliqué : écrire des policies et prédire l'évaluation

Le moindre privilège consiste à n'accorder à une identité que les actions dont elle a besoin pour sa tâche, sur les ressources qu'elle doit toucher, et rien de plus. Cette leçon vous le fait appliquer : une méthode en cinq étapes, quatre policies commentées (lecture seule, développeur, pipeline, exclusion explicite) et la règle d'évaluation qui permet de prédire un verdict avant de le subir. Une dernière section ajoute la séparation des responsabilités, qui interdit qu'une même identité mène seule une chaîne dangereuse. Elle s'adresse à qui sait déjà créer une identité et lui rattacher une permission. Les exemples sont écrits en syntaxe EIM d'OUTSCALE, avec les équivalents AWS, Azure et Google Cloud signalés quand ils diffèrent.

Ce que vous allez apprendre

• Définir le moindre privilège et dire pourquoi il réduit l'impact d'un incident.
• Dérouler les cinq étapes qui partent des tâches réelles, jamais du catalogue des permissions.
• Écrire quatre policies sans droit superflu, et repérer les actions dangereuses.
• Prédire le verdict de l'évaluation : refus par défaut, Allow, Deny explicite.
• Séparer les responsabilités sensibles pour qu'aucune identité ne mène seule une chaîne dangereuse.

Prérequis

• Savoir ce qu'est une identité, un groupe et une policy (un document qui énumère des actions autorisées ou refusées) : voir la leçon IAM : gérer les identités et permissions dans le cloud.
• Savoir lire un document JSON de politique. Une policy se compose de déclarations (Statement) qui portent un Effect (Allow ou Deny), des Action et des Resource.

Qu'est-ce que le principe du moindre privilège ?

Le principe du moindre privilège (least privilege) stipule que chaque identité ne doit avoir que les permissions strictement nécessaires à son travail, pas une de plus. C'est la règle qui décide comment on combine les objets d'un système IAM : ils ne protègent rien par eux-mêmes, c'est leur dosage qui produit la sécurité. Les trois blocs qui suivent donnent la définition, la justification, puis la méthode.

Le concept est présenté dans Moindre privilège : accorder juste ce qu'il faut ; cette leçon garde l'application : la méthode, des policies écrites et la prédiction du verdict.

Situation	Exemple
Ce qui est nécessaire	Un développeur peut créer des VMs en environnement de dev
Ce qui ne l'est pas	Un développeur peut supprimer des VMs en production
Ce qui est dangereux	Un développeur peut créer d'autres utilisateurs avec plus de droits

Glissez pour voir

Pourquoi le moindre privilège est-il crucial ?

Trois arguments justifient l'effort, et ils ne relèvent pas du même registre. Les deux premiers réduisent l'impact d'un incident déjà survenu, le troisième répond à une obligation externe que vous n'avez pas choisie.

Bénéfice	Explication
Réduction de la surface d'attaque	Si les credentials d'Alice sont compromis, l'attaquant ne peut faire que ce qu'Alice peut faire. Si Alice n'a que des droits en lecture, les dégâts sont limités.
Protection contre les erreurs	Une commande mal tapée ne peut pas supprimer ce que l'utilisateur n'a pas le droit de supprimer.
Conformité et audit	Les normes de sécurité (ISO 27001, SOC 2, HDS, SecNumCloud) exigent une gestion fine des accès.

Glissez pour voir

Le créateur n'a pas automatiquement accès à sa création

Sur la plupart des clouds, si vous avez le droit de créer une ressource mais pas de la lister, vous ne pourrez pas voir ce que vous venez de créer. Les permissions sont strictement appliquées. C'est voulu : cela oblige à définir explicitement chaque droit.

Comment appliquer le moindre privilège en cinq étapes ?

La démarche part des tâches réelles, jamais du catalogue des permissions disponibles. Commencer par la liste des actions offertes par le cloud conduit systématiquement à en accorder trop, par simple effet de proximité. Les cinq étapes se suivent dans l'ordre, et la dernière est celle qu'on abandonne le plus vite.

1. Lister les tâches réelles

   Que fait concrètement chaque personne ou service ? "Déployer l'application" = quelles actions API exactement ?

2. Identifier les actions minimales

   Pour "déployer", il faut peut-être CreateVms, ReadVms, CreateVolume... mais pas DeleteVms en production.

3. Créer des policies ciblées

   Une policy par rôle/fonction, pas une policy fourre-tout "full access".

4. Séparer les environnements

   Des credentials différentes pour dev, staging, production. Des permissions différentes selon l'environnement.

5. Réviser régulièrement

   Les besoins évoluent. Un audit trimestriel des permissions est une bonne pratique.

À quoi ressemblent des policies au moindre privilège ?

Ces exemples relèvent de la première famille décrite dans la leçon IAM, celle du document attaché à l'identité. Le préfixe api: est celui d'OUTSCALE ; sur AWS il devient ec2: ou s3:, et sur Azure comme sur Google Cloud la même intention s'exprime par un rôle plutôt que par un document. Les quatre cas vont du plus simple au plus délicat : chacun ajoute une difficulté à celui d'avant.

Policy "lecture seule"

Idéale pour les dashboards de monitoring, les auditeurs, le support niveau 1 :

{
  "Statement": [
    {
      "Sid": "ReadOnlyAccess",
      "Effect": "Allow",
      "Action": ["api:Read*"],
      "Resource": ["*"]
    }
  ]
}

Le joker api:Read* couvre aussi des lectures sensibles : ReadAdminPassword (mot de passe administrateur chiffré d'une VM Windows), ReadConsoleOutput (console de la VM) et ReadApiLogs (journal des appels API). Pour un profil de support, ajoutez un second énoncé "Effect": "Deny" sur ces trois actions : un refus explicite l'emporte sur tout Allow.

Équivalent AWS : la policy managée (un objet de permissions fourni par AWS, et non un rôle) arn:aws:iam::aws:policy/job-function/ViewOnlyAccess. Pour un support de niveau 1, préférez-la à arn:aws:iam::aws:policy/ReadOnlyAccess : cette dernière accorde s3:Get* et permet donc de lire le contenu des objets, alors que ViewOnlyAccess se limite à la consultation des ressources et de leurs métadonnées.

Équivalent Scaleway : une policy est attachée à une application IAM, et chaque règle nomme un ensemble de permissions et un périmètre. La lecture seule des Instances d'un seul projet s'écrit avec InstancesReadOnly et project-ids, comme dans la leçon Ouvrir son environnement de pratique cloud en sécurité :

scw iam policy create name=<nom> application-id=<id-application> \
  rules.0.project-ids.0=<id-projet> rules.0.permission-set-names.0=InstancesReadOnly

Les règles Scaleway sont de type autorisation seule : le périmètre (le projet) et le choix de l'ensemble de permissions font tout le travail du moindre privilège, sans Deny pour rattraper.

Policy "développeur"

Elle permet de créer et gérer des ressources compute et storage, mais pas de toucher à IAM : l'absence de tout iam: ou api:CreateUser l'empêche de s'octroyer plus de droits.

{
  "Statement": [
    {
      "Sid": "ManageCompute",
      "Effect": "Allow",
      "Action": [
        "api:CreateVms",
        "api:ReadVms",
        "api:UpdateVm",
        "api:DeleteVms",
        "api:StartVms",
        "api:StopVms",
        "api:RebootVms"
      ],
      "Resource": ["*"]
    },
    {
      "Sid": "ManageStorage",
      "Effect": "Allow",
      "Action": [
        "api:CreateVolume",
        "api:ReadVolumes",
        "api:DeleteVolume",
        "api:LinkVolume",
        "api:UnlinkVolume"
      ],
      "Resource": ["*"]
    },
    {
      "Sid": "ReadNetwork",
      "Effect": "Allow",
      "Action": ["api:ReadNets", "api:ReadSubnets", "api:ReadSecurityGroups"],
      "Resource": ["*"]
    }
  ]
}

Policy "pipeline CI/CD"

Pour un service automatisé qui crée des machines de test dans le compte de staging. Elle accorde la création et la lecture, pas la suppression :

{
  "Statement": [
    {
      "Sid": "DeployVms",
      "Effect": "Allow",
      "Action": [
        "api:CreateVms",
        "api:ReadVms",
        "api:CreateTags",
        "api:ReadTags"
      ],
      "Resource": ["*"]
    }
  ]
}

Une policy EIM ne peut pas viser « le staging ». Dans le modèle EIM d'OUTSCALE, l'élément Resource n'accepte que la valeur * et la documentation ne décrit aucun élément Condition (voir EIM Policy Elements). Écrire Resource avec l'identifiant d'une VM de staging, ou une condition sur un tag d'environnement, comme on le ferait sur AWS, n'est donc pas possible. La frontière entre staging et production se trace autrement : un compte OUTSCALE distinct par environnement, avec ses propres utilisateurs et ses propres clés, de sorte que la clé du pipeline de staging n'existe tout simplement pas en production.

Ce choix explique aussi l'absence de api:DeleteVms : avec Resource: ["*"], cette action permettrait de supprimer toutes les VMs du compte, pas seulement celles que le pipeline a créées. Si le pipeline doit nettoyer ses environnements éphémères, accordez api:DeleteVms uniquement dans un compte dédié aux environnements jetables, où rien de précieux ne vit.

Dernier piège : OUTSCALE expose les mêmes opérations par plusieurs API, et une règle posée sur l'une ne couvre pas les autres. Interdire la suppression demande de viser à la fois api:DeleteVms et ec2:TerminateInstances, sans quoi un client qui passe par l'API compatible AWS contourne le refus.

Actions dangereuses à surveiller

Certaines actions sont particulièrement sensibles sur tous les clouds :

Action	Risque
iam:* / iam:CreateUser	Création d'utilisateurs avec plus de droits (élévation de privilèges)
*:Delete*	Suppression irréversible de ressources
iam:CreateAccessKey	Création de nouvelles credentials
sts:AssumeRole (AWS)	Prise de rôles avec des droits élevés

Glissez pour voir

Réfléchissez bien avant de les accorder.

Policy avec exclusion explicite

Cette dernière policy renverse la logique : elle autorise tout, puis retire quelques actions dangereuses. Tout autoriser sauf certaines actions n'est pas du moindre privilège au sens strict, mais c'est un garde-fou utile sur un compte jetable ou pour un profil d'administration restreint.

{
  "Statement": [
    {
      "Sid": "AllowMostActions",
      "Effect": "Allow",
      "Action": ["api:*"],
      "Resource": ["*"]
    },
    {
      "Sid": "DenyDangerousActions",
      "Effect": "Deny",
      "Action": [
        "api:DeleteVms",
        "api:DeleteVolume",
        "api:DeleteNet"
      ],
      "Resource": ["*"]
    }
  ]
}

Deny l'emporte toujours sur Allow

Dans le modèle AWS, repris par les exemples de cette page, si une action est à la fois autorisée par une policy et interdite par une autre, l'interdiction gagne. C'est le principe de l'explicit deny qui prime sur tout, et il permet de créer des "garde-fous" difficiles à contourner. Ce n'est pas universel. Chez Azure, le contrôle d'accès repose sur des attributions de rôles qui autorisent seulement ; les deny assignments, qui bloquent même un rôle accordé, sont créées et gérées par Azure (par exemple par les deployment stacks), et les deny assignments gérées par le client sont en préversion privée selon la documentation Microsoft. Chez GCP, les deny policies sont des politiques distinctes des politiques d'autorisation, et IAM les évalue avant les politiques d'autorisation. Chez Scaleway, les règles d'une policy sont de type autorisation seule (scw iam rule update --help). Vérifiez la règle de résolution de votre fournisseur dans sa documentation, puis confirmez-la par le simulateur de politique quand il en offre un (AWS, Google Cloud).

Comment le système décide-t-il d'autoriser ou de refuser ?

Le système applique deux règles : tout est interdit par défaut, et un refus explicite l'emporte sur n'importe quelle autorisation. Comprendre cet ordre d'évaluation (celui du modèle AWS, repris par EIM) évite des heures perdues sur un Access Denied incompréhensible. Chez AWS, la plupart des messages citent l'action refusée et le type de politique en cause (par exemple « no identity-based policy allows the … action » ou « explicit deny in a service control policy »), mais pas tous les services adoptent ce format ; ailleurs, le message est souvent plus pauvre.

Comment IAM décide-t-il ?

Quand un utilisateur tente une action, le système IAM évalue toutes les policies qui s'appliquent (directement + via ses groupes) :

1. Par défaut, tout est interdit (default deny)
2. Si une policy autorise l'action → autorisé (sauf étape 3)
3. Si une seule policy interdit explicitement l'action → interdit

Quel verdict pour Alice, membre de deux groupes ?

Alice appartient à deux groupes :

Groupe	Policy	Effet
developers	Allow: api:*	Autorise tout
safety	Deny: api:DeleteVms	Interdit la suppression de VMs

Glissez pour voir

Résultat : Alice peut tout faire sauf supprimer des VMs, car le Deny explicite l'emporte. Retirez le groupe safety et la suppression redevient possible : c'est l'appartenance au groupe qui porte le garde-fou, pas la policy developers.

Pour vérifier une prédiction sans rien exécuter, utilisez le simulateur de politique quand le fournisseur en offre un (AWS, Google Cloud ; pas de commande de simulation dans scw ni octl). Chez AWS, aws iam simulate-principal-policy renvoie allowed, implicitDeny ou explicitDeny pour chaque action testée.

Comment séparer les responsabilités sensibles entre plusieurs identités ?

La séparation des responsabilités consiste à répartir une action sensible entre plusieurs identités, de sorte qu'aucune ne puisse la mener seule de bout en bout, même si elle est compromise. Elle complète le moindre privilège sans le remplacer. Le moindre privilège réduit ce qu'une identité peut faire ; la séparation interdit qu'une même identité enchaîne deux rôles dont la combinaison est dangereuse. Le principe général est présenté dans Séparation des privilèges ; cette section ne garde que l'application dans un cloud, c'est-à-dire les endroits où l'architecte (la personne qui fixe les règles de conception, avant que l'ingénieur ne les implémente) décide de couper.

Chaîne à couper	Séparation à prévoir	Ce qu'elle empêche
Administrer les droits et exploiter les ressources	Qui modifie les droits n'est pas celui qui pilote les machines et les données	S'attribuer à soi-même tous les droits
Écrire un changement et le mettre en production	Le déploiement exige une approbation d'une autre personne que l'auteur	Pousser seul du code erroné ou malveillant en production
Administrer une clé de chiffrement et l'utiliser	Les droits de rotation et de suppression d'une clé sont distincts du droit de déchiffrer	Qu'un administrateur lise les données, ou qu'un lecteur détruise la clé
Agir et garder les journaux	Les administrateurs de production n'ont aucun droit sur le coffre des journaux	Effacer sa propre trace
Demander et approuver un droit	L'approbateur est le propriétaire de la ressource, jamais le demandeur	Se donner un accès à soi-même

Glissez pour voir

La séparation a un coût, donc on la réserve aux chaînes à fort impact. Une équipe de quatre personnes ne peut pas faire valider chaque action par un tiers. L'architecte choisit les chaînes qui menacent l'activité (production, clés, journaux, droits) et compense ailleurs par un accès temporaire qui expire, une alerte et une relecture après coup dans le journal d'audit. Le piège classique est la séparation de façade : trois rôles bien découpés, mais un compte d'administration partagé qui les cumule tous. L'exemple d'Alice plus haut en montre le ressort : le garde-fou tient à l'appartenance au groupe safety, donc il ne vaut rien si Alice peut aussi modifier ses propres groupes. Pour la vérifier, posez la question à l'envers : quelle identité peut, seule, mener cette chaîne complète ? Si la réponse n'est pas « aucune », la séparation n'existe pas.

À retenir

• Le moindre privilège : chaque identité n'a que les permissions strictement nécessaires à sa tâche, sur les ressources voulues.
• Il réduit l'impact d'un incident (clés compromises, erreur de commande) et répond aux exigences de conformité.
• La méthode part des tâches réelles, jamais du catalogue des permissions : lister, identifier le minimum, cibler, séparer les environnements, réviser.
• Une policy EIM ne cible pas une ressource : Resource n'accepte que *, donc un compte distinct par environnement trace la frontière.
• Les actions d'IAM sont les plus dangereuses : iam:*, iam:CreateAccessKey et sts:AssumeRole permettent d'élever ses privilèges.
• La séparation des responsabilités complète le moindre privilège : elle coupe les chaînes dangereuses (droits, production, clés, journaux) entre plusieurs identités, et se vérifie en demandant quelle identité peut, seule, mener la chaîne entière.
• Tout est interdit par défaut, et un Deny explicite l'emporte sur tout Allow dans le modèle AWS. Ce n'est pas universel : la documentation de votre fournisseur tranche, et son simulateur de politique quand il en offre un (AWS, Google Cloud).

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →