IAM : gérer les identités et permissions dans le cloud

IAM (Identity and Access Management) vous permet de contrôler précisément qui peut faire quoi sur votre infrastructure cloud. Sans ce système, tout le monde utilise le même compte root avec accès total : un développeur junior peut supprimer la production, un stagiaire peut voir les factures, et une fuite de credentials compromet l'ensemble de votre infrastructure.

Ce guide vous apprend à configurer IAM correctement, quel que soit votre fournisseur cloud. Vous découvrirez comment créer des utilisateurs, les organiser en groupes, définir des policies de permissions, et appliquer le principe du moindre privilège : la règle d'or de la sécurité cloud.

Chaque fournisseur cloud utilise sa propre terminologie pour IAM :

Fournisseur	Nom du service	Documentation
AWS	IAM (Identity and Access Management)	docs.aws.amazon.com
Azure	Entra ID (ex-Azure AD) + RBAC	learn.microsoft.com
GCP	Cloud IAM	cloud.google.com/iam
OUTSCALE	EIM (Elastic Identity Management)	docs.outscale.com
Scaleway	IAM	scaleway.com/docs/iam

Les concepts sont communs à tous : une identité, une permission, un rattachement, une règle d'évaluation. Les implémentations, elles, divergent réellement, au point que l'objet qui porte la permission n'est pas le même d'un cloud à l'autre. Ce guide part donc du modèle conceptuel, puis montre le même besoin réalisé sur quatre clouds.

Prérequis : comprendre le principe API-first du cloud. Si ce n'est pas le cas, commencez par le guide API-first dans le cloud.

Le problème : qui a le droit de faire quoi ?

Avant de parler d'outils, il faut cerner le problème que résout IAM. Dans le cloud, toute ressource est créée par un appel API authentifié : la seule question qui compte est donc de savoir quelle identité a le droit d'émettre quel appel. Tant que personne n'y répond explicitement, la réponse par défaut reste « n'importe qui peut tout faire », puisque tout le monde partage le même compte.

Scénario catastrophe : un compte partagé

Dans une entreprise où tout le monde utilise le même compte cloud avec les mêmes credentials, chaque ligne du tableau devient un risque bien réel :

Risque	Conséquence
Le développeur junior a les mêmes droits que le CTO	Il peut supprimer les serveurs de production par erreur
Le stagiaire accède aux informations de facturation	Données confidentielles exposées
Le prestataire externe voit toutes les ressources	Surface d'attaque élargie
Les credentials fuitent (commit Git, Slack...)	Tout est compromis : aucune isolation
Un incident survient	Impossible de savoir qui a fait quoi

Ces cinq risques ont une seule et même origine : l'absence d'identité individuelle. Le cloud ne voit qu'un unique appelant, il ne peut donc ni restreindre les droits selon la personne, ni attribuer une action à quelqu'un dans ses journaux.

La solution : un système IAM

Un système IAM (Identity and Access Management) résout ces problèmes en apportant :

Besoin	Solution IAM
Identifier chaque personne	Un utilisateur distinct avec ses propres credentials
Regrouper par fonction	Des groupes (développeurs, ops, comptabilité...)
Définir les droits	Des policies qui listent les actions autorisées
Tracer les actions	Des logs d'audit qui disent qui a fait quoi et quand

Les composants fondamentaux d'IAM

Tous les fournisseurs cloud utilisent les mêmes concepts de base, même si les noms varient légèrement.

Vue d'ensemble

Six notions se retrouvent chez tous les fournisseurs, même si chacun les nomme et les matérialise à sa façon. Les retenir permet de lire un système IAM inconnu sans en connaître le vocabulaire.

Notion universelle	Ce qu'elle désigne	Exemples
Identité	Qui agit : une personne, un service, une machine	`alice`, un compte de service, une instance
Regroupement	Ce qui factorise les droits de plusieurs identités	groupe, équipe, unité d'organisation
Permission	Ce qui est autorisé ou refusé	lire un objet, démarrer une instance
Rattachement	Comment la permission rejoint l'identité	document attaché, attribution de rôle, liaison sur la ressource
Périmètre	Jusqu'où la règle porte	un compte, un projet, une organisation
Preuve d'identité	Ce qui authentifie l'appel	jeton temporaire, certificat, secret statique

Beaucoup de supports posent le root user comme la première brique de tout système IAM. C'est le modèle d'AWS et d'OUTSCALE, où le compte est créé autour d'un propriétaire dont aucune politique ne peut restreindre les droits. Ce n'est pas le cas partout.

Google Cloud n'a pas d'utilisateur racine de compte : la racine de la hiérarchie est l'organisation, et les pouvoirs correspondants sont portés par des rôles attribuables et révocables. Azure sépare l'annuaire d'identités de la souscription, et le pouvoir maximal y est également un rôle d'administration, qu'on peut retirer.

La différence est loin d'être théorique : elle change la façon de sécuriser le compte. Là où AWS impose de mettre le root sous clé parce qu'on ne peut pas lui retirer ses droits, les deux autres permettent de retirer le rôle à qui n'en a plus besoin.

Le root user : puissant mais dangereux

Quand vous créez un compte cloud, vous obtenez un root user (utilisateur racine). Ce compte possède des permissions illimitées :

Créer, modifier, supprimer toutes les ressources
Gérer les utilisateurs et leurs permissions
Accéder aux informations de facturation
Fermer le compte

Le root user reste indispensable pour quelques opérations que rien d'autre ne permet, mais il est beaucoup trop puissant pour le travail quotidien : aucune policy ne peut restreindre ses droits. Si ses credentials sont compromis, l'attaquant obtient un accès total à votre infrastructure, facturation comprise, et il peut révoquer vos propres accès.

Bonnes pratiques sur les clouds qui ont un utilisateur racine, AWS et OUTSCALE au premier chef :

Créez une identité distincte, avec droits d'administration, pour le travail quotidien
Conservez les moyens d'authentification du racine dans un endroit sécurisé, coffre physique ou gestionnaire de secrets
Activez l'authentification multifacteur sur ce compte, sans exception
Ne l'utilisez que pour les opérations qui l'exigent : fermeture du compte, récupération d'urgence, quelques réglages de facturation

Sur les clouds sans utilisateur racine, la logique équivalente consiste à n'attribuer le rôle d'administration à personne en permanence et à le donner à la demande, pour une durée limitée.

Utilisateurs : une identité par personne ou service

Un utilisateur représente une personne ou un service qui a besoin d'accéder à vos ressources cloud. Chaque utilisateur possède :

Ses propres credentials (access keys distinctes)
Ses propres permissions (définies par des policies)
Son propre historique d'actions (traçabilité)

Règle fondamentale : jamais de partage de credentials entre plusieurs personnes ou services.

Groupes : simplifier la gestion à grande échelle

Prenons 10 développeurs qui ont tous besoin des mêmes permissions. Vous pourriez attacher la même policy à chacun individuellement... mais c'est fastidieux et source d'erreurs.

Solution : créer un groupe developpeurs, y attacher la policy, et ajouter les utilisateurs au groupe.

Sans groupes	Avec groupes
10 utilisateurs × 1 policy = 10 attachements	1 groupe avec 10 membres = 1 attachement
Nouveau développeur = rappeler d'attacher la policy	Nouveau développeur = ajouter au groupe
Modifier les droits = 10 modifications	Modifier les droits = 1 modification

Un utilisateur peut appartenir à plusieurs groupes et cumule les permissions :

alice → groupe "developpeurs" → permissions de développement
alice → groupe "on-call"      → permissions de surveillance production

Organisation type des groupes

Ce découpage sert de point de départ dans la plupart des organisations. Retenez surtout l'isolement du groupe ci-cd : un pipeline n'est pas un humain, il agit sans supervision et à grande vitesse, il mérite donc son propre jeu de permissions et son propre périmètre d'environnement.

Groupe	Permissions	Membres typiques
`administrators`	Tout (sauf facturation parfois)	CTO, Lead Ops
`developers`	VMs, volumes, réseaux en dev	Équipe de développement
`readonly`	Lecture seule sur tout	Auditeurs, support
`billing`	Accès aux informations de consommation	Comptabilité
`ci-cd`	Création/suppression en staging	Pipelines GitLab/GitHub

Policies : définir qui peut faire quoi

Une politique est un document, généralement en JSON, qui définit des permissions. Quel que soit le fournisseur, une permission répond aux mêmes six questions. Les retenir permet de lire n'importe quelle politique, chez n'importe qui, même sans en connaître la syntaxe :

Brique	La question	Exemple concret
Principal	Qui agit ?	une utilisatrice, un groupe, un rôle, une machine, un service
Action	Que veut-il faire ?	lire un objet, démarrer une instance, supprimer un instantané
Ressource	Sur quoi ?	un seau précis, toutes les bases d'un projet, une clé de chiffrement
Périmètre	Où cette règle s'applique-t-elle ?	un compte, un projet, un groupe de ressources, une organisation entière
Condition	Sous quelles réserves ?	seulement depuis un réseau donné, seulement avec double authentification, seulement avant une date
Effet	Autoriser ou refuser ?	autoriser par défaut, refuser explicitement pour créer une exception

La condition est la brique la plus utile et la moins utilisée. Elle permet de resserrer un droit sans réécrire la politique : le même droit de lecture devient inoffensif s'il n'est utilisable que depuis votre réseau d'entreprise, ou seulement par une session authentifiée à double facteur. Beaucoup de politiques trop larges pourraient être rendues acceptables par une seule condition bien placée.

Le périmètre est celle qui varie le plus d'un fournisseur à l'autre, et c'est la source principale des malentendus quand on change de cloud. Chez certains, il se déduit de la ressource visée ; chez d'autres, il est une donnée à part entière que vous choisissez explicitement au moment d'attribuer le droit. La section suivante montre exactement où chacun le place.

Comment s'écrit une permission, selon les clouds

Il n'existe pas une syntaxe IAM, il en existe trois familles, et confondre les trois est l'erreur la plus coûteuse quand on change de fournisseur. Beaucoup de documentations laissent croire que le modèle d'AWS est le modèle du cloud, parce qu'il est le plus ancien et le plus copié. Un administrateur formé sur ce seul modèle arrive sur Azure et ne trouve rien de ce qu'il cherche, non pas parce que les noms changent, mais parce que l'objet auquel la permission s'attache n'est pas le même.

Voici la question qui départage les trois familles : où vit la permission ?

Famille	La permission est attachée à	Clouds représentatifs
Document de politique	l'identité (utilisateur, groupe, rôle)	AWS, OUTSCALE, Scaleway
Attribution de rôle	un couple identité + périmètre	Azure
Liaison sur la ressource	la ressource elle-même	Google Cloud

Famille 1 : un document attaché à l'identité

C'est le modèle d'AWS, repris par OUTSCALE. Vous écrivez un document, souvent en JSON, et vous l'attachez à un utilisateur, un groupe ou un rôle. Le document énumère des actions et des ressources.

{
  "Statement": [
    {
      "Sid": "AllowReadVMs",
      "Effect": "Allow",
      "Action": ["compute:ReadInstances", "compute:DescribeInstances"],
      "Resource": ["*"]
    }
  ]
}

Élément	Obligatoire	Description
`Statement`	oui	Contient une ou plusieurs déclarations
`Sid`	non	Identifiant lisible pour la déclaration
`Effect`	oui	`Allow` (autoriser) ou `Deny` (interdire)
`Action`	oui	Liste des actions concernées
`Resource`	oui	Ressources concernées (`*` = toutes)

Le préfixe d'une action désigne le service, et il change d'un cloud à l'autre. C'est la différence la plus visible au sein de cette famille, ce n'est pas la seule.

Trois mécanismes varient aussi, et ce sont eux qui décident du résultat quand deux règles se contredisent :

Le modèle d'évaluation. Chez AWS, un Deny explicite l'emporte toujours sur n'importe quel Allow, et l'absence de règle vaut refus. D'autres implémentations de cette même famille n'appliquent pas les mêmes règles de résolution.
Les politiques attachées aux ressources. Un seau de stockage peut porter sa propre politique, qui se combine avec celle de l'identité. Le droit effectif est alors l'intersection ou l'union des deux selon le fournisseur, ce qui n'est pas du tout la même chose.
Les garde-fous de niveau supérieur. Frontières de permissions, politiques d'organisation, contraintes héritées d'une unité parente : ils peuvent retirer un droit que la politique de l'identité accorde.

Autrement dit, savoir lire un document de politique ne suffit pas à prédire ce qu'une identité peut réellement faire. C'est pourquoi tous les fournisseurs de cette famille offrent un simulateur de politique : c'est lui qui donne le droit effectif, pas la lecture du JSON.

AWS
OUTSCALE

Préfixe	Service	Exemples d'actions
`ec2:`	Compute	`ec2:RunInstances`, `ec2:DescribeInstances`
`s3:`	Stockage objet	`s3:GetObject`, `s3:PutObject`
`iam:`	Identités	`iam:CreateUser`, `iam:CreatePolicy`

Préfixe	Service	Exemples d'actions
`api:`	API OUTSCALE	`api:CreateVms`, `api:ReadVolumes`
`ec2:`	API compatible EC2	`ec2:RunInstances`, `ec2:DescribeInstances`
`iam:`	Identités (EIM)	`iam:CreateUser`, `iam:CreatePolicy`

Le caractère * remplace une partie du nom d'action. ec2:Describe* couvre toutes les actions de lecture, *:* couvre tout, ce qui revient à ne rien restreindre du tout.

Famille 2 : une attribution de rôle sur un périmètre

C'est le modèle d'Azure, et il déroute quand on vient d'AWS parce qu'on n'y écrit presque jamais de document. Vous assignez un rôle existant à une identité, sur un périmètre précis : une souscription, un groupe de ressources, ou une ressource unique.

La permission naît donc du triplet qui / quel rôle / sur quoi, et le périmètre est un objet de première classe, pas une chaîne de caractères dans un champ Resource. Les rôles se cumulent en héritant du périmètre parent : un rôle donné sur une souscription s'applique à tous les groupes de ressources qu'elle contient.

Ce que cela change en pratique : vous cherchez d'abord le bon périmètre, puis le rôle. L'inverse du réflexe AWS, où l'on cherche d'abord les actions.

Famille 3 : une liaison portée par la ressource

C'est le modèle de Google Cloud, et c'est le plus éloigné des deux autres. La politique n'est pas attachée à l'utilisateur mais à la ressource, qui déclare la liste des rôles et, pour chacun, les membres qui en bénéficient.

# Lecture : sur CETTE ressource, ces membres ont ce rôle.
bindings:
  - role: roles/compute.viewer
    members:
      - user:alice@example.com
      - serviceAccount:ci@projet.iam.gserviceaccount.com

Les rôles sont majoritairement prédéfinis (roles/compute.viewer, roles/storage.objectAdmin), et l'héritage suit la hiérarchie organisation, dossier, projet, ressource.

Ce que cela change : pour savoir ce qu'une personne peut faire, vous n'inspectez pas son profil, vous inspectez les ressources. C'est déstabilisant au début, et beaucoup plus lisible ensuite quand la question est « qui a accès à ce bucket ».

Politique attachée directement ou objet réutilisable

Dans la première famille, une même permission peut s'écrire sous deux formes qui ne diffèrent pas par leur contenu mais par leur cycle de vie. Une politique intégrée (inline) n'existe qu'attachée à un objet et disparaît avec lui ; une politique gérée (managed) est un objet autonome auquel plusieurs utilisateurs ou groupes viennent se rattacher.

Type	Description	Avantages	Inconvénients
Intégrée	Écrite dans l'utilisateur ou le groupe	Simple, usage unique	Pas réutilisable, disparaît avec son porteur
Gérée	Objet indépendant, attachable à plusieurs	Réutilisable, versionnable	Un objet de plus à administrer

Le même besoin, sur quatre clouds

Prenons un besoin concret et suivons-le partout : donner à Alice, développeuse, le droit de lire les machines virtuelles, et rien d'autre. C'est le cas le plus banal, et c'est justement pour cela qu'il révèle bien les différences.

La démarche est la même partout, et c'est elle qu'il faut retenir : on crée une identité, on la range dans un regroupement, on décrit une permission, on rattache la permission au regroupement plutôt qu'à la personne. Ce dernier point n'est pas une coquetterie : le jour où Alice change d'équipe, vous déplacez une personne au lieu de relire ses droits un par un.

# 1. L'identité
aws iam create-user --user-name alice-dev

# 2. Le regroupement, puis l'appartenance
aws iam create-group --group-name developpeurs
aws iam add-user-to-group --user-name alice-dev --group-name developpeurs

# 3. La permission, comme objet réutilisable
aws iam create-policy \
  --policy-name DevReadOnly \
  --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":["ec2:Describe*"],"Resource":["*"]}]}'

# 4. Le rattachement au groupe, pas à la personne
aws iam attach-group-policy \
  --group-name developpeurs \
  --policy-arn arn:aws:iam::ACCOUNT_ID:policy/DevReadOnly

# 1. L'identité
osc-cli eim CreateUser --UserName alice-dev

# 2. Le regroupement, puis l'appartenance
osc-cli eim CreateUserGroup --UserGroupName developpeurs
osc-cli eim AddUserToUserGroup \
  --UserGroupName developpeurs \
  --UserName alice-dev

# 3. La permission
osc-cli eim CreatePolicy \
  --PolicyName DevReadOnly \
  --PolicyDocument '{"Statement":[{"Effect":"Allow","Action":["api:Read*"],"Resource":["*"]}]}'

# 4. Le rattachement, par l'identifiant de ressource du compte
osc-cli eim AttachGroupPolicy \
  --UserGroupName developpeurs \
  --PolicyOrn orn:ows:eim::ACCOUNT_ID:policy/DevReadOnly

Le raisonnement change : aucun document à écrire, un rôle existant à attribuer sur un périmètre.

# 1. Le regroupement d'abord, il porte l'attribution
az ad group create --display-name developpeurs --mail-nickname developpeurs

# 2. L'appartenance
az ad group member add --group developpeurs --member-id <ID_OBJET_ALICE>

# 3. et 4. La permission et son rattachement sont la même opération :
#    un rôle, un bénéficiaire, un périmètre.
az role assignment create \
  --assignee-object-id <ID_OBJET_DU_GROUPE> \
  --assignee-principal-type Group \
  --role "Reader" \
  --scope /subscriptions/<ID_SOUSCRIPTION>/resourceGroups/<GROUPE_DE_RESSOURCES>

Notez le --scope : c'est lui qui limite la portée, là où les deux clouds précédents utilisent le champ Resource du document.

Le raisonnement change encore : la permission est portée par la ressource, ici le projet.

# 1. et 2. Les identités sont fournies par Google Workspace ou Cloud Identity ;
#    le regroupement est un groupe d'annuaire, pas un objet du cloud.

# 3. et 4. On lie un rôle prédéfini à un membre, sur une ressource.
gcloud projects add-iam-policy-binding MON_PROJET \
  --member="group:developpeurs@example.com" \
  --role="roles/compute.viewer"

Pour savoir ensuite qui peut lire les machines, on interroge la ressource et non les utilisateurs :

gcloud projects get-iam-policy MON_PROJET

Créer les identifiants d'accès, et le moment où l'on se trompe

La clé secrète n'est affichée qu'une fois. C'est vrai sur les quatre clouds, et c'est le moment exact où les mauvaises habitudes se prennent : on la colle dans une conversation d'équipe « en attendant », et elle y reste des années.

Transmettez-la par un gestionnaire de secrets, jamais par messagerie ni par courriel. Et posez-vous la question qui évite le problème : cette personne a-t-elle besoin d'une clé d'API, ou seulement d'un accès à la console ? Une clé qui n'existe pas ne fuit pas.

Le principe du moindre privilège (Least Privilege)

Cette section est la plus importante du guide. Les objets IAM ne protègent rien par eux-mêmes : c'est la manière de les combiner qui produit la sécurité. Le moindre privilège est la règle qui guide cette combinaison, et les trois sous-sections en donnent la définition, la justification puis la méthode d'application concrète.

De quoi s'agit-il ?

Le principe du moindre privilège stipule que chaque utilisateur ne doit avoir que les permissions strictement nécessaires à son travail, pas une de plus. C'est la règle d'or de la sécurité IAM.

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

Pourquoi c'est 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.

Appliquer le moindre privilège en 5 é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é.

Lister les tâches réelles

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

Pour "déployer", il faut peut-être CreateVms, ReadVms, CreateVolume... mais pas DeleteVms en production.
Créer des policies ciblées

Une policy par rôle/fonction, pas une policy fourre-tout "full access".
Séparer les environnements

Des credentials différentes pour dev, staging, production. Des permissions différentes selon l'environnement.
Réviser régulièrement

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

Exemples de policies concrètes

Ces exemples relèvent de la première famille décrite plus haut, 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.

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": ["*"]
    }
  ]
}

Équivalent AWS : utilisez le rôle managé arn:aws:iam::aws:policy/ReadOnlyAccess

Policy "développeur"

Permet de créer et gérer des ressources compute/storage, mais pas de toucher à IAM :

{
  "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 déploie en staging :

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

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

Réfléchissez bien avant de les accorder.

Policy avec exclusion explicite

Tout autoriser sauf certaines actions dangereuses :

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

Logique d'évaluation des permissions

Comprendre l'ordre d'évaluation évite des heures perdues sur un Access Denied incompréhensible. Deux règles suffisent à tout expliquer : l'interdiction par défaut, et la priorité absolue du refus explicite sur n'importe quelle autorisation.

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) :

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

Exemple concret

Alice appartient à deux groupes :

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

Résultat : Alice peut tout faire sauf supprimer des VMs, car le Deny explicite l'emporte toujours.

Les pièges courants et comment les éviter

Ces cinq erreurs se retrouvent dans la quasi-totalité des comptes cloud audités. Aucune n'est de nature technique : ce sont des raccourcis pris sous la pression du délai, dont le coût n'apparaît que le jour de l'incident ou du départ d'un collaborateur.

Piège n°1 : "Full Access pour tout le monde, on verra plus tard"

Risque : "plus tard" n'arrive jamais, et une erreur ou un compte compromis peut tout détruire.

Solution : commencez avec des permissions minimales et ajoutez au besoin. C'est plus facile d'ajouter que de retirer (et de convaincre les équipes de perdre des droits).

Piège n°2 : "J'utilise les credentials root pour les scripts"

Risque : si le script est compromis (commit Git accidentel, log exposé), l'attaquant a un accès total.

Solution : créez un utilisateur IAM dédié avec les permissions minimales pour le script. Utilisez des rôles si votre cloud le permet.

Piège n°3 : "Tous les développeurs partagent les mêmes access keys"

Risque : impossible de savoir qui a fait quoi. Si les clés doivent être révoquées, tout le monde est impacté.

Solution : un utilisateur IAM par personne, avec ses propres access keys.

Piège n°4 : "Je ne révoque jamais les accès des personnes qui partent"

Risque : un ancien employé ou prestataire conserve un accès à l'infrastructure.

Solution : intégrez la révocation des accès cloud dans le processus de départ (offboarding). Désactivez immédiatement les access keys.

Piège n°5 : "Je ne documente pas mes policies"

Risque : dans 6 mois, personne ne sait pourquoi telle policy existe ou ce qu'elle fait.

Solution : utilisez le champ Sid pour nommer clairement chaque statement. Maintenez une documentation externe si nécessaire (wiki, repo Git).

Dépannage

Presque toutes les erreurs IAM se manifestent par un message unique, Access Denied, qui ne précise jamais quelle permission manque. Le tableau associe donc le symptôme observable à la cause la plus probable et au contrôle à effectuer en priorité.

Symptôme	Cause probable	Solution
`Access Denied` sur une action	Policy manquante ou Deny explicite	Vérifiez les policies attachées à l'utilisateur et ses groupes
L'utilisateur ne voit pas ses propres ressources	Il manque l'action `Read` / `Describe`	Ajoutez les permissions de lecture
Impossible de créer des access keys	L'utilisateur n'a pas `iam:CreateAccessKey`	Seul un admin peut créer des clés pour d'autres
Policy attachée mais sans effet	La policy n'est pas attachée au bon groupe/utilisateur	Vérifiez l'attachement avec la CLI
Élévation de privilèges détectée	Un utilisateur a `iam:*` ou peut créer d'autres users	Retirez ces permissions dangereuses

Checklist : mettre en place IAM correctement

Trois listes, selon le moment : la mise en place initiale du compte, l'arrivée d'un utilisateur, et la revue périodique. C'est la troisième qu'on abandonne le plus vite, alors que c'est la seule qui détecte les accès devenus inutiles.

Pour démarrer

Ces cinq actions ne se font qu'une fois, dès l'ouverture du compte, et conditionnent tout le reste.

Créer un utilisateur IAM admin pour le travail quotidien (au lieu du root)
Activer le MFA sur le compte root
Sécuriser les credentials root dans un endroit sûr (coffre-fort, gestionnaire de secrets)
Créer des groupes correspondant aux rôles de votre organisation
Définir des policies basées sur le moindre privilège

Pour chaque nouvel utilisateur

À dérouler à chaque arrivée. Le nom explicite est le point le plus souvent négligé, alors que c'est lui qui rend les journaux d'audit lisibles six mois plus tard.

Créer l'utilisateur IAM avec un nom explicite (prenom-role ou service-fonction)
L'ajouter au(x) groupe(s) approprié(s)
Créer des access keys si nécessaire (et les transmettre de façon sécurisée)
Documenter le rôle et les droits attendus

Pour l'audit régulier (trimestriel)

Une revue trimestrielle suffit dans la plupart des organisations. Elle cherche les écarts : comptes non révoqués après un départ, policies devenues trop larges au fil des demandes, et access keys trop anciennes.

Lister tous les utilisateurs et leurs groupes
Vérifier que les personnes parties n'ont plus d'accès
Réviser les policies : sont-elles toujours adaptées aux besoins actuels ?
Vérifier l'âge des access keys et les renouveler si nécessaire (90 jours max recommandé)
Identifier les credentials inutilisées et les supprimer

À retenir

IAM contrôle qui peut faire quoi sur votre infrastructure cloud. Sans IAM, tout le monde utilise le root user avec accès total, risque majeur.
Le root user est tout-puissant et ne doit être utilisé que pour des opérations exceptionnelles. Créez des utilisateurs IAM pour le travail quotidien et activez le MFA sur le root.
Chaque personne ou service = un utilisateur IAM avec ses propres credentials. Jamais de partage d'access keys entre plusieurs personnes.
Les groupes simplifient la gestion : une policy attachée à un groupe s'applique à tous ses membres. Organisez par rôle (dev, ops, readonly, billing).
Les policies définissent les permissions via des documents JSON. Allow autorise, Deny interdit, et Deny l'emporte toujours.
Le principe du moindre privilège est la règle d'or : n'accordez que les permissions strictement nécessaires. Révisez régulièrement.
Par défaut, tout est interdit (deny by default). Un utilisateur sans policy ne peut rien faire, même pas voir ce qu'il a créé.

Prochaines étapes

Souveraineté des données Comprendre comment garantir la souveraineté et la protection de vos données dans le cloud.