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

Les concepts fondamentaux (utilisateurs, groupes, policies, rôles) sont identiques. Ce guide utilise des exemples Outscale EIM — la syntaxe s’adapte facilement aux autres 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 ?

Scénario catastrophe : un compte partagé

Imaginez une entreprise où tout le monde utilise le même compte cloud avec les mêmes credentials :

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

C’est l’équivalent numérique de donner les clés du coffre-fort à tous les employés, y compris ceux qui n’ont besoin que d’accéder à la photocopieuse.

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

Composant	Description	Exemples
Root user	Propriétaire du compte, droits illimités	Vous, lors de la création du compte
Utilisateur	Identité avec des droits limités	`alice`, `bob`, `gitlab-ci`
Groupe	Ensemble d’utilisateurs	`developpeurs`, `ops`, `readonly`
Policy	Document définissant les permissions	”Peut créer et lister des VMs”
Rôle	Identité assumable temporairement	Service qui accède à une ressource
Credentials	Moyen d’authentification	Access Key/Secret Key, token

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

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

Imaginons 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

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 policy est un document (généralement JSON) qui définit des permissions. Elle répond à trois questions :

Qui ? → L’utilisateur, groupe ou rôle auquel elle est attachée
Quoi ? → Les actions autorisées (ou interdites)
Où ? → Les ressources concernées

Structure d’une policy (syntaxe JSON)

La syntaxe des policies est similaire sur la plupart des clouds. Voici un exemple générique :

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

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

Actions et préfixes selon les clouds

Chaque cloud utilise des préfixes pour identifier le service :

Préfixe	Service	Exemples d’actions
`ec2:`	Compute	`ec2:RunInstances`, `ec2:DescribeInstances`
`s3:`	Storage	`s3:GetObject`, `s3:PutObject`
`iam:`	Identity	`iam:CreateUser`, `iam:CreatePolicy`
`*`	Tous	`*` = toutes les actions

Préfixe	Service	Exemples d’actions
`api:`	OAPI	`api:CreateVms`, `api:ReadVolumes`
`ec2:`	FCU	`ec2:RunInstances`, `ec2:DescribeInstances`
`iam:`	EIM	`iam:CreateUser`, `iam:CreatePolicy`
`*`	Tous	`:` = toutes les actions

GCP utilise un format différent basé sur les rôles prédéfinis :

Rôle	Permissions
`roles/compute.viewer`	Lecture des instances
`roles/compute.admin`	Gestion complète du compute
`roles/storage.objectViewer`	Lecture des objets Storage

Wildcards : le caractère `*`

Le caractère * remplace une partie du nom d’action :

Pattern	Signification
`ec2:*`	Toutes les actions du service EC2
`ec2:Describe*`	Toutes les actions commençant par “Describe”
`:`	Toutes les actions de tous les services

Policies inline vs managed

Type	Description	Avantages	Inconvénients
Inline	Intégrée directement à un utilisateur/groupe	Simple, usage unique	Pas réutilisable, supprimée avec l’utilisateur
Managed	Objet indépendant, attachable à plusieurs	Réutilisable, versionnable	Un peu plus complexe

Exemple pratique : Outscale EIM

Cette section illustre la mise en œuvre concrète avec Outscale EIM. Les principes s’appliquent aux autres clouds avec une syntaxe adaptée.

Créer un utilisateur

Via la console Cockpit :

Accéder à EIM

Menu latéral → Identity & Access Management → Users
Créer l’utilisateur

Cliquez sur “Create User”, entrez un nom explicite (ex: alice-dev)
Créer des access keys

Pour que l’utilisateur puisse utiliser l’API, créez une paire Access Key / Secret Key
Sauvegarder la Secret Key

Elle n’est visible qu’une seule fois. Transmettez-la de façon sécurisée (gestionnaire de secrets, pas Slack).

Via osc-cli (ligne de commande) :

# Créer un utilisateur
osc-cli eim CreateUser --UserName alice-dev

# Créer une access key pour cet utilisateur
osc-cli eim CreateAccessKey --UserName alice-dev

Vérification : osc-cli eim ReadUsers doit afficher le nouvel utilisateur.

Créer un groupe et y ajouter des utilisateurs

# Créer un groupe
osc-cli eim CreateUserGroup --UserGroupName developpeurs

# Ajouter un utilisateur au groupe
osc-cli eim AddUserToUserGroup \
  --UserGroupName developpeurs \
  --UserName alice-dev

# Vérifier
osc-cli eim ReadUserGroupsPerUser --UserName alice-dev

Attacher une policy à un groupe

# Créer une policy managed
osc-cli eim CreatePolicy \
  --PolicyName DevReadOnly \
  --PolicyDocument '{"Statement":[{"Effect":"Allow","Action":["api:Read*"],"Resource":["*"]}]}'

# Attacher la policy au groupe
osc-cli eim AttachGroupPolicy \
  --UserGroupName developpeurs \
  --PolicyOrn orn:ows:eim::ACCOUNT_ID:policy/DevReadOnly

Le principe du moindre privilège (Least Privilege)

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 n’est pas nécessaire	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

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

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 utilisent la syntaxe Outscale OAPI. Adaptez les préfixes d’actions selon votre cloud.

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

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

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

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

Pour démarrer

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

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)

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.