EIM OUTSCALE : identité, utilisateurs, groupes et policies

EIM (Elastic Identity Management) est le service d’identité et d’accès d’OUTSCALE — le socle du pilier Security du Well-Architected Framework, avec des contributions fortes aux piliers Operational Excellence (cycle de vie des comptes, audit) et Sovereignty (alignement avec les politiques d’identité de l’organisation). Une mauvaise configuration EIM transforme une vulnérabilité applicative en compromission complète du compte ; une discipline EIM rigoureuse contient les incidents et limite leur portée. Cette page pose les concepts fondamentaux — root user, EIM users, groups, policies, MFA, API Access Rules — et détaille les bonnes pratiques non négociables, tagguées par pilier WAF pour faciliter la lecture transverse depuis le Volet 5.

Ce que vous allez apprendre

Distinguer le root user et les EIM users — leurs rôles respectifs et les pièges à éviter.
Structurer les permissions avec des groups et des policies (managed et inline).
Activer la MFA sur tous les comptes humains, avec des codes de récupération.
Restreindre l’accès aux API avec les API Access Rules (filtrage par IP ou certificat).
Appliquer le moindre privilège — la discipline qui transforme votre posture de sécurité.
Repérer les antipatterns classiques (root au quotidien, AK/SK partagés, policy * sur *).

Prérequis

Un compte OUTSCALE actif.
Connaître le vocabulaire OUTSCALE ↔ AWS, en particulier l’équivalence EIM ↔ IAM.
Avoir lu le Cockpit OUTSCALE pour savoir naviguer dans les sections Identity & Access et Account Settings.
Bases de la sécurité cloud — moindre privilège, défense en profondeur.

EIM en deux phrases

EIM est l’API de gestion des identités d’OUTSCALE, compatible AWS IAM : les mêmes concepts (utilisateurs, groupes, politiques d’accès) s’appliquent avec une grammaire d’API similaire. Sa fonction est de contrôler qui peut faire quoi sur les ressources OUTSCALE, et de tracer chaque action pour des besoins d’audit et de conformité.

L’authentification EIM repose sur la signature des requêtes API avec une paire Access Key + Secret Key, selon le mécanisme AWS Signature Version 4. Cela permet de réutiliser aws-cli et les SDK AWS existants pour piloter EIM sur OUTSCALE.

Les deux types d’identités

EIM distingue deux types d’identités qui peuvent accéder à un compte OUTSCALE.

Le root user

Le root user est l’identité par défaut, créée automatiquement à l’ouverture d’un compte OUTSCALE. Il a des permissions illimitées sur toutes les ressources et tous les services du compte. Il ne peut pas être supprimé tant que le compte existe.

C’est précisément cette puissance qui en fait l’identité la plus sensible du compte — et qu’il ne faut jamais utiliser au quotidien.

Les EIM users

Les EIM users sont des identités créées par le root user (ou par un EIM user qui a la permission de créer d’autres users). Chacun peut avoir :

Un identifiant (nom d’utilisateur).
Un mot de passe (optionnel, pour l’accès au Cockpit) ou un schéma fédéré SSO.
Une ou plusieurs paires AK/SK pour l’accès API.
Des policies attachées qui définissent ce qu’il peut faire.
Une MFA activée (mandatory pour tout compte humain).

C’est avec des EIM users que vous travaillez au quotidien, jamais avec le root user.

Structurer les permissions avec des groups

Quand le compte commence à avoir plusieurs utilisateurs ou plusieurs équipes, gérer les permissions utilisateur par utilisateur devient ingérable et propice aux dérives. La discipline est de regrouper les permissions par rôle organisationnel via les groups EIM.

Le principe

Un group EIM regroupe plusieurs utilisateurs qui partagent les mêmes permissions. Les policies attachées au groupe s’appliquent à tous ses membres.

Exemple de structuration typique :

Groupe	Permissions typiques	Membres
`admins`	Toutes les opérations administratives sauf gestion du compte	DevOps lead, RSSI
`dev-team`	Lecture / écriture sur les ressources des projets dev	Développeurs backend
`ops-team`	Lecture / écriture sur prod, pas de gestion EIM	Ops, SRE
`auditeurs`	Lecture seule sur l’ensemble du compte	RSSI, audit interne
`cicd-runners`	Lecture / écriture sur un namespace projet précis	(utilisateur technique pour pipelines)

Quand un nouvel utilisateur arrive, on l’ajoute au groupe correspondant à son rôle ; on n’attache pas une policy individuelle. À l’inverse, quand quelqu’un quitte ou change de rôle, on le retire du groupe — les permissions sont automatiquement révoquées.

Bénéfices

Cette discipline apporte trois bénéfices :

Cohérence entre les utilisateurs d’un même rôle.
Audit facile — il suffit de regarder qui appartient à quel groupe.
Réversibilité immédiate en cas de départ ou changement de rôle.

Les policies — managed et inline

Les policies EIM sont des documents JSON qui décrivent les actions autorisées (ou refusées) sur quelles ressources. Elles peuvent être attachées à un user, un group, ou (dans certains cas) directement à une ressource.

Policies managed

Une managed policy est une policy réutilisable, créée une fois puis attachée à plusieurs entités (users ou groups). Elle peut être :

AWS-managed — fournie par OUTSCALE (par exemple ReadOnlyAccess ou des policies équivalentes aux AmazonEC2ReadOnlyAccess d’AWS).
Customer-managed — créée par vous, pour vos besoins spécifiques.

Les managed policies sont versionnées : vous pouvez modifier une policy existante sans avoir à la rattacher manuellement à toutes les entités qui l’utilisent.

Policies inline

Une inline policy est attachée directement à une seule entité (un user, un group, un role). Elle n’existe pas indépendamment : si vous supprimez l’entité, l’inline policy disparaît avec.

Les inline policies sont utiles pour des cas très spécifiques (par exemple, un user technique avec une permission unique liée à son rôle), mais elles compliquent le suivi à grande échelle. La règle pratique : privilégier les managed policies sauf cas particulier.

Structure d’une policy EIM

Une policy EIM est un document JSON structuré autour d’un tableau Statement. Exemple minimal autorisant la lecture de VMs et refusant leur terminaison :

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["ec2:DescribeInstances", "ec2:DescribeVolumes"],
      "Resource": ["*"]
    },
    {
      "Effect": "Deny",
      "Action": ["ec2:TerminateInstances"],
      "Resource": ["*"]
    }
  ]
}

Éléments structurants documentés :

Statement — tableau de règles, évaluées dans l’ordre.
Effect : Allow ou Deny. Un Deny explicite prime toujours sur un Allow.
Action ou NotAction : liste des actions ciblées.
Resource : actuellement limité à ["*"] dans EIM — les resource-based policies (cibler une ressource spécifique par ARN) ne sont pas supportées.

Préfixes d’actions disponibles selon le service ciblé :

Préfixe	Service ciblé
`api`	OAPI native OUTSCALE
`ec2`	FCU (compute, compatible EC2)
`elasticloadbalancing`	LBU (compatible ELB Classic)
`iam`	EIM (gestion d’identité elle-même)
`directconnect`	DirectLink
`*`	Tous services

OUTSCALE met à disposition un EIM Policy Generator interactif pour construire des policies sans écrire le JSON à la main, et la page EIM Policy Elements décrit la grammaire complète des policies.

L’authentification — quatre méthodes

Le service EIM accepte quatre méthodes d’authentification, chacune adaptée à un contexte précis. Elles sont détaillées dans la page Découverte du Cockpit, récapitulé ici dans l’angle EIM.

Méthode	Cas d’usage typique
Email + mot de passe	Connexion humaine au Cockpit, simple à mettre en place
Access Key (AK/SK)	Appels API depuis scripts, CI/CD, Terraform, SDK
Federation SSO	Organisation avec un Identity Provider central déjà en place
Certificat X.509	Environnements à sécurité maximale, accès par machines spécifiques

Federation SSO — quand c’est pertinent

Pour une organisation qui dispose déjà d’un Identity Provider (IdP) en place, la fédération SSO apporte plusieurs bénéfices :

Cycle de vie des comptes centralisé — quand un employé quitte l’organisation, son compte est désactivé dans l’IdP, et tous les accès cloud (dont OUTSCALE) sont révoqués automatiquement.
Politique d’authentification unifiée — la MFA, la complexité du mot de passe, les sessions, les durées d’expiration sont gérées au niveau IdP.
Audit centralisé — les connexions OUTSCALE remontent dans les logs IdP, à côté de tous les autres accès.

La mise en place demande une configuration côté OUTSCALE (déclaration de l’IdP) et côté IdP (déclaration d’OUTSCALE comme service). Typiquement gérée par votre équipe sécurité ou IT — pas par les développeurs individuellement.

MFA — non négociable

L’authentification multi-facteurs ajoute une vérification au-delà du mot de passe. Sur OUTSCALE, deux mécanismes sont disponibles :

WebAuthn — clé matérielle (YubiKey, Titan Security Key) ou biométrie de l’appareil.
OTP (One-Time Password) — application génératrice de codes (Google Authenticator, Authy, 1Password, Bitwarden).

Activer la MFA

Depuis Cockpit, menu utilisateur (initiales en haut à droite) → Account Settings → Authentication → section MFA → Set up.

Après activation :

Générer immédiatement les codes de récupération.
Conserver les codes hors ligne dans un coffre (papier dans un coffre physique, ou stockage chiffré offline).
Tester la connexion avec MFA depuis une autre session pour s’assurer que tout fonctionne.

MFA sur tous les comptes humains

La MFA n’est pas optionnelle sur OUTSCALE :

Root user : MFA matérielle, jamais d’OTP application (l’application peut être compromise sur un poste infecté).
EIM users humains : MFA matérielle de préférence, OTP acceptable pour les usages secondaires.
EIM users techniques (utilisateurs pour pipelines, automation) : pas de MFA, mais des AK/SK avec date d’expiration + API Access Rules restrictives.

API Access Rules — restreindre l’accès aux API

Au-delà de l’authentification (qui valide qui vous êtes) et de l’autorisation (qui valide ce que vous pouvez faire), les API Access Rules ajoutent un filtrage réseau à l’entrée de l’API OUTSCALE.

Le principe

Une API Access Rule autorise (ou refuse) l’accès à l’API depuis :

une plage d’adresses IP (par exemple, l’IP fixe du bureau ou d’un VPN d’entreprise) ;
un certificat client X.509 (autorité de certification interne).

Une seule règle au format 0.0.0.0/0 existe par défaut et autorise tout le monde. Elle doit être remplacée dès que possible par des règles restrictives.

Bonne pratique de mise en place

Mise en place sans casser l’accès :

Ce filtrage réseau se cumule avec les policies EIM : un appel API doit passer les API Access Rules ET passer la policy de l’utilisateur pour aboutir.

Bonnes pratiques EIM (par pilier Well-Architected)

Six disciplines à appliquer sur tout compte OUTSCALE en production, avec le pilier WAF dominant que chacune adresse.

1. Root user au coffre — pilier Security

Le root user est protégé par MFA matérielle et n’est utilisé qu’exceptionnellement. Toutes les opérations courantes passent par un EIM user admin dédié. Cette discipline isole la clé maîtresse du compte des opérations quotidiennes — elle ne sert plus qu’aux opérations rares qui ne peuvent pas être déléguées.

2. Une AK/SK par usage — piliers Security + Operational Excellence

Chaque AK/SK identifie un usage précis : laptop d’un développeur spécifique, runner CI/CD d’un projet, scanner de sécurité, Terraform pour un environnement. Si une clé est compromise, vous ne révoquez que celle-là, pas l’ensemble. Côté Operational Excellence, cette granularité facilite l’audit — qui a fait quoi avec quelle clé.

3. Date d’expiration sur toutes les AK/SK — pilier Security

Cockpit affiche un avertissement lorsqu’une clé a plus de 3 mois et qu’elle devrait être renouvelée. La discipline : réviser tous les trimestres ce qui est encore actif et rotater systématiquement les clés qui dépassent ce seuil. Une clé oubliée est une fenêtre d’attaque ouverte dans le temps.

4. Moindre privilège dans les policies — pilier Security

Partir d’aucune permission et ajouter uniquement ce qui est nécessaire. Préférer plusieurs policies ciblées plutôt qu’une grosse policy Allow *. Auditer les permissions inutilisées via les logs OMS (traçage des appels API). C’est le principe fondateur du pilier Security — et la discipline qui distingue une posture défendable d’une checklist cosmétique.

5. Groups par rôle organisationnel — pilier Operational Excellence

Permissions attachées à des groups, jamais directement aux utilisateurs (sauf cas particulier dûment documenté). Cycle de vie : ajout au groupe à l’arrivée, retrait au départ ou au changement de rôle. Cette discipline transforme la gestion des accès en opération routinière plutôt qu’en chantier ponctuel.

6. Federation SSO si l’organisation l’a déjà — piliers Security + Sovereignty

Si votre organisation a un IdP central, brancher OUTSCALE dessus. Cela élimine la dérive courante d’avoir des comptes EIM qui survivent au départ de leur titulaire. Côté Sovereignty, la fédération aligne OUTSCALE sur les politiques d’identité globales de l’entreprise — y compris les exigences spécifiques (SecNumCloud, ISO 27001, sectorielles) gérées au niveau IdP.

EIM sous l’angle Well-Architected

EIM contribue à plusieurs piliers Well-Architected — la lecture par pilier ci-dessous facilite l’agrégation depuis le Volet 5.

Security — le cœur

EIM est le pilier Security en pratique sur OUTSCALE. Sans une discipline EIM rigoureuse, aucune autre mesure ne tient : un Security Group bien configuré ne sert à rien si une AK/SK fuit donne accès à Allow *. Les questions clés du pilier Security adressées par EIM :

Qui peut accéder à quoi ? — policies ciblées, moindre privilège.
Comment sont gérées les identités humaines vs techniques ? — EIM users humains avec MFA, EIM users techniques avec API Access Rules + AK/SK expirantes.
Comment détecte-t-on une compromission ? — logs OMS (équivalent CloudTrail), revue régulière des accès, alertes sur usage inhabituel d’AK/SK.

Operational Excellence — cycle de vie et audit

EIM contribue au pilier Operational Excellence par le cycle de vie des accès et l’audit. Les groupes EIM permettent d’industrialiser l’arrivée et le départ des utilisateurs, la rotation des AK/SK, la révocation propre. Les logs OMS tracent chaque appel API et fournissent la base d’un audit de posture.

Sovereignty — alignement avec les politiques d’organisation

Pour une organisation soumise à des exigences de souveraineté (SecNumCloud, OIV / OSE), EIM doit s’aligner sur les politiques d’identité globales de l’entreprise. La federation SSO vers l’Identity Provider déjà en place dans l’organisation est le chemin principal : cela centralise la conformité et évite les comptes EIM orphelins.

Reliability et autres piliers — contributions indirectes

EIM contribue aussi aux autres piliers indirectement : sans accès propres, pas de Reliability (impossibilité d’opérer un PRA), pas de Cost Optimization (impossibilité de mettre en place un FinOps qui restreint les actions coûteuses aux bons utilisateurs). C’est pour cette raison qu’EIM est le premier chapitre des fondations.

Antipatterns à éviter

Cinq erreurs récurrentes qui annulent une grande partie du bénéfice EIM.

Antipattern	Conséquence	Discipline correcte
Root user utilisé au quotidien	Une compromission donne un compte complet	Root au coffre, EIM user admin pour les opérations
*Policy `Allow ` sur ``*	Équivalent au root user	Moindre privilège, policies ciblées
AK/SK partagée entre plusieurs personnes	Impossible de révoquer individuellement	Une AK/SK par personne et par usage
MFA non activée sur des comptes humains	Phishing = compromission	MFA mandatory, contrôle automatisé si possible
Pas d’expiration sur les AK/SK	Clés oubliées qui traînent des années	Expiration systématique + revue trimestrielle

À retenir

EIM est le service d’identité et accès d’OUTSCALE, compatible AWS IAM — aws-cli et SDK AWS utilisables.
Le root user a des permissions illimitées : il est protégé par MFA matérielle et rangé dans un coffre, jamais utilisé au quotidien.
Les EIM users sont créés par le root et utilisés pour toutes les opérations courantes ; MFA mandatory sur tout compte humain.
Les groups structurent les permissions par rôle organisationnel ; les policies (managed ou inline) définissent les actions autorisées.
Le moindre privilège est non négociable — partir d’aucune permission, ajouter uniquement ce qui est nécessaire.
Une AK/SK par usage, avec date d’expiration, jamais en clair dans Git.
Les API Access Rules ajoutent un filtrage réseau (IP ou certificat X.509) en complément des policies EIM — créer la nouvelle règle avant de supprimer l’ancienne pour éviter le verrouillage.
Federation SSO quand l’organisation a déjà un IdP — bénéfices forts en termes de cycle de vie des comptes.

Prochaines étapes

EIM patterns multi-comptes / projets Architecture multi-comptes, séparation des environnements, organisation à grande échelle.

Réseau — design Net + Subnets Concevoir un réseau OUTSCALE multi-AZ après avoir posé l'identité.

Découverte du Cockpit OUTSCALE L'interface web pour gérer Account Settings, MFA et API Access Rules.

Vocabulaire OUTSCALE ↔ AWS EIM ↔ IAM, et tous les autres acronymes.

EIM OUTSCALE : identité, utilisateurs, groupes et policies

Ce que vous allez apprendre

Prérequis

EIM en deux phrases

Les deux types d’identités

Le root user

Les EIM users

Structurer les permissions avec des groups

Le principe

Bénéfices

Les policies — managed et inline

Policies managed

Policies inline

Structure d’une policy EIM

L’authentification — quatre méthodes

Federation SSO — quand c’est pertinent

MFA — non négociable

Activer la MFA

MFA sur tous les comptes humains

API Access Rules — restreindre l’accès aux API

Le principe

Bonne pratique de mise en place

Bonnes pratiques EIM (par pilier Well-Architected)

1. Root user au coffre — pilier Security

2. Une AK/SK par usage — piliers Security + Operational Excellence

3. Date d’expiration sur toutes les AK/SK — pilier Security

4. Moindre privilège dans les policies — pilier Security

5. Groups par rôle organisationnel — pilier Operational Excellence

6. Federation SSO si l’organisation l’a déjà — piliers Security + Sovereignty

EIM sous l’angle Well-Architected

Security — le cœur

Operational Excellence — cycle de vie et audit

Sovereignty — alignement avec les politiques d’organisation

Reliability et autres piliers — contributions indirectes

Antipatterns à éviter

À retenir

Prochaines étapes

Ressources externes