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 lire une permission selon le fournisseur. Il fixe aussi trois règles de conception que l'on pose avant de configurer quoi que ce soit : relier les personnes à l'annuaire de l'entreprise, suivre les droits de l'arrivée au départ et exiger un journal d'audit exploitable. L'application du principe du moindre privilège, la règle d'or de la sécurité cloud, fait l'objet de la leçon Le moindre privilège appliqué.

Ce que vous allez apprendre

• Expliquer pourquoi un compte partagé est un risque, et ce qu'apporte un système IAM.
• Distinguer identité, groupe, policy, root user et ce qu'ils ont de commun d'un cloud à l'autre.
• Lire une permission selon qu'elle est un document, un rôle attribué ou une liaison sur la ressource.
• Rattacher un droit à un groupe sur quatre clouds, le vérifier, puis nettoyer.
• Concevoir la fédération des identités humaines avec l'annuaire de l'entreprise, avec ses exceptions : le compte de secours et les comptes d'administration de tout l'environnement.
• Décrire le cycle de vie des habilitations (arrivée, mobilité, départ) et leur recertification.
• Formuler ce qu'il faut exiger d'un journal d'audit : contenu, conservation, lecteurs, alertes.
• Éviter les cinq pièges courants et diagnostiquer un Access Denied.

Terminologie selon les fournisseurs

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

Glissez pour voir

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

Glissez pour voir

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

Glissez pour voir

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

Glissez pour voir

L'utilisateur racine n'est pas universel

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 que les politiques d'identité du compte ne peuvent pas restreindre. Ce n'est pas le cas partout, et ce n'est pas absolu : dans une organisation, une politique d'organisation (les SCP chez AWS) peut borner même cet utilisateur dans un compte membre. Seul le compte de gestion de l'organisation (chez AWS), celui qui l'administre, échappe à ce plafond.

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é puisque le compte ne peut pas lui retirer ses droits, les deux autres permettent de retirer le rôle à qui n'en a plus besoin, ce qui rend le compte administrateur révocable.

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

Ne jamais utiliser le root user au quotidien

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 du compte ne peut restreindre ses droits (seule une politique d'organisation le peut, dans un compte membre). 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 les droits d'administration de son périmètre (compte, projet), pour le travail quotidien (de préférence fédérée, comme le décrit la section sur la fédération plus bas)
• Conservez les moyens d'authentification du racine dans un endroit sécurisé, coffre physique ou gestionnaire de secrets
• Activez l'authentification multifacteur (MFA : un second justificatif en plus du mot de passe) 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.

Un utilisateur sans policy ne peut rien faire

Par défaut, un utilisateur nouvellement créé n'a aucune permission. Il ne peut même pas lister les ressources. Vous devez explicitement lui attacher des policies pour qu'il puisse agir. C'est le principe du deny by default (refus par défaut).

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

Glissez pour voir

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 en staging (suppression à n'accorder que sur un compte jetable)	Pipelines GitLab/GitHub

Glissez pour voir

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

Glissez pour voir

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
Politique attachée à l'identité	l'identité (utilisateur, groupe, rôle ou application)	AWS et OUTSCALE (document JSON), Scaleway (règles sur des ensembles de permissions)
Attribution de rôle	un couple identité + périmètre	Azure
Liaison sur la ressource	la ressource elle-même	Google Cloud

Glissez pour voir

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)

Glissez pour voir

Scaleway attache aussi sa politique à l'identité (utilisateur, groupe ou application), mais ne la rédige pas action par action. Une policy y contient des règles, et chaque règle lie des ensembles de permissions (permission sets, par exemple InstancesFullAccess) à un périmètre : l'organisation entière ou une liste de projets. Les règles Scaleway sont de type autorisation seule : il n'y a pas de Deny à écrire. La commande scw iam rule update --help documente ces champs.

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. Outscale (EIM) documente la même règle, mais ne la présumez pas pour un autre fournisseur : Azure et GCP n'ont pas de Deny dans leurs politiques d'autorisation de base (voir la leçon Le moindre privilège appliqué).
• 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 AWS propose un simulateur de politique (IAM policy simulator, aws iam simulate-principal-policy) et Google Cloud un Policy Troubleshooter et un Policy Simulator : l'outil donne le droit effectif, pas la lecture du JSON. Azure offre un écran « Check access » qui affiche les droits d'une identité sur un périmètre, sans simuler un changement. Pour Scaleway et OUTSCALE, la CLI officielle (scw, octl) n'expose aucune commande de simulation : ne présumez pas qu'un tel outil existe, et testez avec une identité de test.

AWS

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

Glissez pour voir

OUTSCALE

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

Glissez pour voir

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 ».

L'erreur classique en changeant de cloud

Un administrateur AWS qui arrive sur Google Cloud cherche « la policy de l'utilisateur » et ne la trouve pas, parce qu'elle n'existe pas : il faut regarder les ressources. Un administrateur Google Cloud qui arrive sur Azure cherche à écrire un document et ne trouve que des rôles à assigner.

Ce ne sont pas des différences de vocabulaire, ce sont trois manières différentes de répondre à la même question. Retenez le modèle conceptuel des sections précédentes, identité, permission, rattachement, évaluation : lui est vraiment universel. La syntaxe, elle, se réapprend à chaque fournisseur, et c'est le travail d'une journée.

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

Glissez pour voir

Préférez les politiques gérées

Elles sont réutilisables (une politique pour dix personnes), versionnables (vous revenez en arrière après une modification malheureuse), centralisées (un changement s'applique partout) et auditables (vous pouvez les lister, donc les relire).

La politique intégrée a un usage légitime : l'exception ponctuelle qui doit mourir avec l'objet qui la porte. Dès qu'une permission concerne deux personnes, elle mérite un objet à elle.

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.

Prérequis de cette partie pratique. Il vous faut un compte administrateur sur le cloud que vous voulez essayer (ou un compte de test dédié, jamais votre production), et uniquement le CLI de ce cloud : aws pour AWS, octl pour OUTSCALE, az pour Azure, gcloud pour Google Cloud. Vous pouvez ne tester qu'un seul onglet. Les identités créées sont des identités de test : la section de nettoyage, après les onglets, les supprime. Elles servent à montrer le mécanisme ; en production, les personnes viennent de la fédération décrite plus bas, pas d'utilisateurs créés à la main.

AWS

# 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

OUTSCALE

# 1. L'identité
octl iaas api CreateUser --UserName alice-dev

# 2. Le regroupement, puis l'appartenance
octl iaas api CreateUserGroup --UserGroupName developpeurs
octl iaas api AddUserToUserGroup \
  --UserGroupName developpeurs \
  --UserName alice-dev

# 3. La permission
octl iaas api CreatePolicy \
  --PolicyName DevReadOnly \
  --Document '{"Statement":[{"Effect":"Allow","Action":["api:ReadVms"],"Resource":["*"]}]}'

# 4. Le rattachement au groupe, par l'ORN de la policy
octl iaas api LinkManagedPolicyToUserGroup \
  --UserGroupName developpeurs \
  --PolicyOrn orn:ows:idauth::ACCOUNT_ID:policy/DevReadOnly

Ces commandes utilisent octl, le CLI recommandé (voir les outils CLI OUTSCALE), qui appelle l'API native OUTSCALE (OAPI) : CreateUserGroup, AddUserToUserGroup, LinkManagedPolicyToUserGroup, paramètre --PolicyOrn. La variante compatible IAM (CreateGroup, AttachGroupPolicy, --PolicyArn) est une autre API, appelée avec aws-cli, et ne se mélange pas avec celle-ci. Le nom de policy DevReadOnly doit être celui créé à l'étape 3, et ACCOUNT_ID l'identifiant à 12 chiffres de votre compte. Pour vérifier la requête avant de l'envoyer, ajoutez --dry-run : octl affiche le corps JSON sans appeler l'API.

Azure

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. Attention : le rôle Reader donne la lecture sur toutes les ressources du groupe de ressources, pas seulement sur les machines virtuelles. Pour lire les VM et rien d'autre, il faut un rôle personnalisé limité à l'action Microsoft.Compute/virtualMachines/read.

Google Cloud

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

Aucun des quatre exemples n'est exactement « les VM et rien d'autre ». Chez AWS, ec2:Describe* couvre aussi les volumes, réseaux et groupes de sécurité ; chez Azure, Reader couvre tout le groupe de ressources ; chez Google Cloud, roles/compute.viewer couvre toutes les ressources Compute Engine. Seul l'exemple OUTSCALE, qui nomme l'action api:ReadVms, est aussi étroit que le besoin. La précision d'un droit se joue dans le détail de l'action ou du rôle choisi.

Vérifier le droit accordé, puis nettoyer les identités de test

Un droit se vérifie, il ne se suppose pas. Chez AWS, le simulateur de politique répond sans rien exécuter : ec2:DescribeInstances doit être allowed et ec2:RunInstances implicitDeny. Chez Azure et Google Cloud, on relit l'attribution créée. Remplacez les valeurs entre chevrons par les vôtres.

# AWS : simuler deux actions pour alice-dev (via son groupe)
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::ACCOUNT_ID:user/alice-dev \
  --action-names ec2:DescribeInstances ec2:RunInstances \
  --query 'EvaluationResults[].[EvalActionName,EvalDecision]' --output text

# OUTSCALE : relire le groupe et ses policies liées
octl iaas api ReadManagedPoliciesLinkedToUserGroup --UserGroupName developpeurs

# Azure : relire l'attribution du groupe
az role assignment list --assignee <ID_OBJET_DU_GROUPE> --output table

# Google Cloud : voir les liaisons du projet (déjà vu plus haut)
gcloud projects get-iam-policy MON_PROJET

Quand la vérification est faite, supprimez les identités de test : un compte oublié reste une porte d'entrée. L'ordre compte, on détache avant de supprimer.

# AWS
aws iam detach-group-policy --group-name developpeurs \
  --policy-arn arn:aws:iam::ACCOUNT_ID:policy/DevReadOnly
aws iam remove-user-from-group --user-name alice-dev --group-name developpeurs
aws iam delete-policy --policy-arn arn:aws:iam::ACCOUNT_ID:policy/DevReadOnly
aws iam delete-group --group-name developpeurs
aws iam delete-user --user-name alice-dev

# OUTSCALE
octl iaas api UnlinkManagedPolicyFromUserGroup --UserGroupName developpeurs \
  --PolicyOrn orn:ows:idauth::ACCOUNT_ID:policy/DevReadOnly
octl iaas api RemoveUserFromUserGroup --UserGroupName developpeurs --UserName alice-dev
octl iaas api DeletePolicy --PolicyOrn orn:ows:idauth::ACCOUNT_ID:policy/DevReadOnly
octl iaas api DeleteUserGroup --UserGroupName developpeurs
octl iaas api DeleteUser --UserName alice-dev

# Azure
az role assignment delete --assignee <ID_OBJET_DU_GROUPE> --role "Reader" \
  --scope /subscriptions/<ID_SOUSCRIPTION>/resourceGroups/<GROUPE_DE_RESSOURCES>
az ad group delete --group developpeurs

# Google Cloud
gcloud projects remove-iam-policy-binding MON_PROJET \
  --member="group:developpeurs@example.com" --role="roles/compute.viewer"

Ce que ces quatre onglets vous apprennent vraiment

Regardez ce qui bouge et ce qui ne bouge pas.

Ne bouge pas : on nomme une identité, on la range, on décrit un droit, on rattache le droit au groupe. Cette séquence vaut sur les quatre clouds, et sur ceux que vous rencontrerez ensuite.

Bouge : l'objet qui porte la permission, et donc l'endroit où vous enquêterez le jour d'un incident. Chez AWS et OUTSCALE, vous partez de la personne. Chez Azure, vous partez du périmètre. Chez Google Cloud, vous partez de la ressource.

Quand une équipe vous dira « on a le même IAM que sur AWS », demandez d'abord où vit la permission. La réponse vous dira si la migration est une traduction ou une refonte.

La création des clés d'accès, le moment où la clé secrète s'affiche et les alternatives à la clé de longue durée font l'objet de la leçon Identifiants temporaires et accès en ligne de commande. Appliquer ces mécanismes avec des droits minimaux est l'objet de la leçon Le moindre privilège appliqué, qui reprend aussi les exemples de policies concrètes et la logique d'évaluation des permissions.

Les trois sections suivantes quittent la configuration pour la conception : ce sont les règles qu'un architecte fixe et qu'un ingénieur met ensuite en œuvre chez un fournisseur. Elles ne demandent aucune manipulation ni aucun compte, et elles se lisent aussi pour comprendre ce qu'un audit de sécurité va vous demander.

Comment relier les identités humaines à l'annuaire de l'entreprise ?

La fédération d'identités consiste à ne créer aucun compte humain dans le cloud pour le travail quotidien : l'annuaire de l'entreprise authentifie la personne, et le cloud fait confiance à la preuve qu'il émet. Cet annuaire joue le rôle de fournisseur d'identité (IdP, Identity Provider) et reste la source de vérité des personnes : une arrivée, un changement d'équipe ou un départ s'y enregistrent une seule fois. L'authentification unique (SSO, Single Sign-On) évite un mot de passe de plus et permet d'imposer au même endroit le second facteur et la durée des sessions.

Deux protocoles standardisés, qui décrivent comment l'annuaire transmet cette preuve au cloud, dominent : SAML 2.0, très répandu en entreprise, et OpenID Connect (OIDC), plus récent. Leur fonctionnement est détaillé dans les guides SAML 2.0 et OpenID Connect ; cette section ne garde que les décisions de conception.

La fédération a un gain net et un coût. Le gain : un départ se traite à un seul endroit, les comptes fédérés n'ont aucun mot de passe cloud à voler, et les sessions sont courtes. Le coût : l'annuaire devient une dépendance critique, car s'il tombe, plus aucun humain ne se connecte.

Décision	Choix de conception	Raison
Source de vérité	Un seul annuaire, alimenté par le processus des ressources humaines	Un départ se traite une fois, au bon endroit
Du groupe au droit	Un groupe d'annuaire donne un rôle du cloud ; jamais une personne donne une permission	Une revue relit des groupes, pas des centaines de droits individuels
Durée de session	Courte (quelques heures), second facteur exigé à l'IdP	Une session volée expire d'elle-même
Création des comptes	Automatique, par le protocole SCIM (System for Cross-domain Identity Management) quand le fournisseur le prend en charge	Évite les comptes orphelins ; voir le guide SCIM
Comptes locaux	Interdits, sauf les comptes de secours, les comptes d'administration de tout l'environnement et les identités de service	Aucun contournement du SSO au quotidien
Compte de secours	Deux comptes locaux, mot de passe long conservé sous scellé, second facteur matériel, alerte à chaque usage, essai annuel	L'accès survit à une panne de l'annuaire

Glissez pour voir

Un compte de secours (break-glass) est un compte local créé hors fédération pour le jour où l'annuaire ne répond plus. Il est puissant et dangereux : on le range comme on range un extincteur. Chaque usage déclenche une alerte, et l'essai annuel prouve qu'il fonctionne encore, car un secours jamais testé tombe en panne le jour où l'on en a besoin.

Une seconde exception touche les comptes d'administration de tout l'environnement. La recommandation R11 du CERT-FR, dans le rapport CERTFR-2025-CTI-001 (cert.cyber.gouv.fr), demande que les comptes les plus privilégiés, ceux qui peuvent administrer l'intégralité de l'environnement cloud, ne soient pas hybrides, c'est-à-dire rattachés à l'annuaire de l'entreprise. Ils sont propres à la base d'identité du fournisseur, et utilisés depuis des postes d'administration dédiés. La raison est simple : un compte hybride hérite des faiblesses de l'annuaire, et la compromission de l'annuaire donnerait alors la main sur tout le cloud. Cela ne contredit pas l'identité fédérée du travail quotidien : celle-ci porte les droits d'un périmètre précis, alors que ces comptes-ci tiennent l'ensemble de l'environnement et restent rares.

La fédération a une limite qu'il faut connaître. Désactiver un compte à l'annuaire n'annule pas ce qui existe déjà côté cloud : une session ouverte reste valable jusqu'à son expiration (sauf révocation explicite, quand le fournisseur la permet), et une clé d'accès créée à la main survit au compte qui l'a créée. D'où les sessions courtes, la limitation des clés d'accès personnelles aux cas où rien d'autre ne convient (piège n°3) et la revue décrite dans la section suivante. Enfin, la prise en charge de SAML, d'OIDC et de SCIM varie d'un fournisseur à l'autre : vérifiez-la avant de bâtir le modèle sur elle. Pour la ligne de commande, la leçon Identifiants temporaires et accès en ligne de commande dit ce qui est documenté chez chacun.

Comment gérer les droits à l'arrivée, au changement de poste et au départ ?

Le cycle de vie des habilitations suit trois moments, que le métier nomme joiner, mover et leaver (arrivée, mobilité, départ), puis une revue périodique, la recertification, vérifie que le résultat est toujours juste. Le départ est le moment auquel tout le monde pense, comme le rappelle le piège n°4 plus bas. La mobilité est celui qu'on oublie : une personne qui change d'équipe garde ses anciens droits et en reçoit de nouveaux, ce qui produit une dérive des privilèges (privilege creep) invisible tant que personne ne relit.

Moment	Ce que l'architecte exige	Preuve observable
Arrivée	Les droits viennent de l'appartenance à un groupe de rôle ; tout droit hors rôle est demandé, approuvé par le propriétaire de la ressource et porte une date d'expiration	Une demande tracée avec l'approbateur et la date de fin
Mobilité	Les droits de l'ancien rôle sont retirés le jour du changement, pas seulement complétés	Les groupes de la personne avant et après le changement
Départ	Désactivation à l'annuaire le jour même, puis révocation de tout ce qui vit hors annuaire (clés d'accès, jetons personnels, accès de tiers) et reprise des ressources créées	Aucune connexion après la date de départ
Prestataire	Compte limité par une date d'expiration égale à la fin du contrat	La date de fin présente sur le compte

Glissez pour voir

La recertification est une revue où le responsable d'un accès confirme ou retire, ligne par ligne, chaque droit de ses équipes. Le relecteur est le responsable hiérarchique ou le propriétaire de la ressource, pas l'administrateur technique : celui-ci voit les droits mais ne sait pas si la personne en a encore besoin. Un accès que personne ne confirme est retiré, et non maintenu par défaut. Prévoyez au moins une revue annuelle pour tous les accès, et plus fréquente pour les comptes privilégiés ; la checklist de cette page propose un rythme trimestriel. La trace de la revue (date, relecteur, décisions) est la preuve que demande un auditeur.

La gouvernance tient à trois règles de conception. Chaque groupe et chaque identité de service a un propriétaire nommé, qui répond de ses droits. Les indicateurs se mesurent : nombre de comptes sans connexion depuis une durée que vous fixez (par exemple 90 jours), délai entre un départ et le retrait complet des accès, part des droits jamais utilisés. Enfin, la création de comptes automatisée par SCIM réduit l'écart entre l'annuaire et le cloud, sans le supprimer : il reste à contrôler les comptes créés hors annuaire. Le guide SCIM traite le départ propre côté protocole, et le référentiel IAM et accès cloud liste les exigences de revue des droits.

Que doit exiger l'architecte du journal d'audit ?

Le journal d'audit doit permettre de répondre, des mois après les faits, à une question : qui a fait quoi, sur quelle ressource, depuis où, quand et avec quel résultat. Le fournisseur en produit un, mais ses réglages par défaut conviennent rarement à une exigence de traçabilité. L'architecte ne choisit pas un produit : il pose cinq exigences que l'implémentation devra respecter, et dont chacune se vérifie.

Exigence	Ce que l'architecte fixe	Question de vérification
Quoi journaliser	Les actions sur le plan de contrôle, c'est-à-dire les appels qui gèrent les ressources (création, modification, suppression, changements de droits, connexions, échecs) ; les accès aux données seulement où la sensibilité le justifie, car ils sont volumineux et coûteux	Peut-on retrouver qui a supprimé cette ressource ?
Combien de temps	Le plus long de deux délais : l'obligation légale applicable, et le temps qu'il faut à votre organisation pour détecter une intrusion	La conservation par défaut du fournisseur couvre-t-elle ce délai ?
Où	Un stockage séparé de ce qui est journalisé, dans un autre compte ou projet, en écriture seule pour la source	Un administrateur de la production peut-il effacer sa propre trace ?
Qui lit	L'équipe de sécurité et l'audit en lecture seule ; les administrateurs de production n'administrent pas le coffre des journaux	Qui peut modifier la rétention ou supprimer un journal ?
Quelles alertes	Un petit nombre d'événements qui réveillent un humain	Quelqu'un est-il prévenu quand le journal s'arrête ?

Glissez pour voir

Les alertes doivent viser les événements dont personne ne devrait se passer : l'usage du compte de secours ou du compte racine, la modification d'une politique de droits, la création d'une clé d'accès, et surtout l'arrêt ou la modification de la journalisation elle-même. Un attaquant compétent coupe d'abord le journal ; l'alerte sur cet arrêt transforme sa tentative en signal.

Les Foundations Benchmarks du Center for Internet Security (CIS) demandent une alerte sur plusieurs d'entre eux : usage du compte racine, modification des politiques de droits, modification de la configuration de la journalisation, échecs d'authentification à la console (numérotation de la version 3.0 pour AWS, à vérifier pour votre fournisseur). L'alerte sur la création d'une clé d'accès et sur l'usage du compte de secours est un ajout de bonne pratique, pas une exigence de ce référentiel. Ajoutez des échecs d'authentification répétés et toute connexion hors du périmètre attendu.

Trois propriétés rendent le journal exploitable. Chaque entrée porte une identité nominative : avec un compte partagé, le journal dit « le compte admin » et n'apprend rien. Les horloges sont synchronisées, faute de quoi on ne reconstitue pas une chronologie entre systèmes. Enfin, la couverture diffère d'un fournisseur à l'autre : certains appels ne sont pas journalisés par le journal d'audit principal, comme le détaille la leçon Exploiter : journaux, alertes, incident et changements. Pour la durée, le référentiel Journalisation et audit retient au moins six mois, sous réserve des obligations légales. La séparation entre qui agit et qui contrôle est traitée dans la section sur la séparation des responsabilités de la leçon Le moindre privilège appliqué.

Les pièges courants et comment les éviter

Ces cinq erreurs sont des classiques des comptes cloud mal tenus. 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 resserrera après"

Risque : « après » 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 : donnez au script une identité dédiée avec les permissions minimales. Préférez des identifiants temporaires obtenus par un rôle, ou l'identité de charge de travail (OpenID Connect, OIDC) pour une chaîne d'intégration continue ; une clé d'utilisateur de longue durée n'est que le dernier recours.

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 : une identité par personne. Pour un humain, une connexion par la console ou un rôle assumé (identifiants temporaires) ; si une clé d'accès est vraiment nécessaire, une clé nominative par personne, jamais partagée.

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. Selon le fournisseur et le service, il nomme plus ou moins bien la cause : chez AWS, la plupart des messages citent l'action refusée et le type de politique en cause, mais certains services n'adoptent pas ce format. 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 le droit de créer des clés (iam:CreateAccessKey chez AWS)	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
Chez Scaleway, une commande list renvoie un tableau vide sans erreur	Les commandes list filtrent en silence : un projet hors périmètre paraît vide, il n'est pas forcément vide	Faites un get sur l'identifiant d'une ressource connue : la réponse dit sans ambiguïté si l'accès est refusé (voir Ouvrir son environnement de pratique)

Glissez pour voir

Pour savoir qui a fait quoi et quand une fois le droit en cause identifié, consultez le journal d'audit du fournisseur ; chez Scaleway, il est présenté dans Audit Trail. Ce qu'il faut exiger de ce journal est détaillé dans la section Que doit exiger l'architecte du journal d'audit ?.

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. Les deux lignes sur le root concernent les clouds qui en ont un (AWS, OUTSCALE) ; ailleurs, appliquez la même logique au rôle d'administration.

• Utiliser une identité nominative fédérée (SSO) avec les droits d'administration de son périmètre (compte, projet) pour le travail quotidien, au lieu du root et sans utilisateur local partagé
• Activer le MFA sur le compte root, ou sur le compte d'administration de l'organisation là où le root n'existe pas
• 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 après.

• Créer l'identité avec un nom explicite (prenom-role ou service-fonction) : un utilisateur IAM local seulement si la fédération n'est pas en place
• L'ajouter au(x) groupe(s) approprié(s)
• Créer des access keys seulement en dernier recours (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, tout-puissant : réservez-le aux opérations exceptionnelles, activez le MFA dessus et donnez aux personnes des identités nominatives, de préférence fédérées avec l'annuaire de l'entreprise, pour le travail quotidien.

• Chaque personne ou service a sa propre identité, jamais partagée. Préférez les identifiants temporaires (rôle assumé, OIDC pour la CI) aux clés d'accès de longue durée ; si une clé est inévitable, elle est nominative.

• 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 : un document JSON chez AWS et OUTSCALE, des règles qui lient des ensembles de permissions à un projet ou à l'organisation chez Scaleway, un rôle attribué sur un périmètre chez Azure, une liaison portée par la ressource chez Google Cloud. Ce n'est pas une différence de vocabulaire, c'est l'endroit où vit la permission.

• Le principe du moindre privilège est la règle d'or : n'accordez que les permissions strictement nécessaires, tout le reste étant interdit par défaut (deny by default). Il s'applique et se vérifie dans la leçon dédiée.

• L'annuaire de l'entreprise reste la source de vérité des personnes : la fédération (SAML, OIDC) évite les comptes humains locaux pour le travail quotidien, impose le second facteur et des sessions courtes. Deux exceptions se justifient : deux comptes de secours testés pour le jour où l'annuaire tombe, et les comptes d'administration de tout l'environnement, propres au fournisseur (recommandation R11 du CERT-FR).

• Les droits suivent la vie de la personne : arrivée par groupe de rôle, retrait des anciens droits à la mobilité, révocation complète au départ, puis recertification par le responsable de l'accès, avec une trace conservée.

• Le journal d'audit se spécifie : événements couverts, conservation fixée, stockage séparé hors de portée des administrateurs, et alerte quand la journalisation s'arrête.

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

8 questions

8 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 →