Identity and Access Management (IAM) : définition et exemples

Qu'est-ce que l'Identity and Access Management (IAM) ?

L'Identity and Access Management (IAM, gestion des identités et des accès) regroupe les politiques, processus et outils qui décident qui peut se connecter à un système et ce que chaque identité peut faire ensuite. Une identité peut être une personne, un service ou un appareil. L'IAM répond à trois questions : qui êtes-vous, qu'avez-vous le droit de faire, et qu'avez-vous fait ?

Comment fonctionne l'IAM

Toute mise en place d'IAM combine trois piliers, qui agissent dans l'ordre : la requête est authentifiée, puis autorisée, et le résultat est enregistré.

L'authentification unique (SSO) vient s'y ajouter : une session ouvre plusieurs applications, en général via un protocole comme SAML ou OpenID Connect, ce qui permet de retirer l'accès en un seul endroit quand quelqu'un part.

Modèles de contrôle d'accès

• RBAC (basé sur les rôles) : les permissions sont rattachées à des rôles comme "lecteur" ou "responsable facturation", et les personnes reçoivent des rôles. Le modèle le plus courant et le plus simple à revoir.
• ABAC (basé sur les attributs) : une règle compare des attributs de l'utilisateur, de la ressource et du contexte, par exemple "autoriser si user.department est égal à resource.department". Plus fin, mais plus difficile à auditer.
• ACL (liste de contrôle d'accès) : chaque ressource porte sa propre liste de qui peut faire quoi. Convient aux fichiers et aux petits systèmes, encombrant à grande échelle.

Exemple : un job CI qui pousse une image de conteneur

Un pipeline doit pousser une image vers un seul dépôt du registre. Une configuration fragile lui donne une clé d'administrateur partagée qui reste indéfiniment dans une variable de build. Une configuration IAM saine donne au job sa propre identité de service avec un rôle qui n'autorise que "pousser vers ce dépôt", délivre des identifiants qui expirent à la fin du job et journalise chaque appel. Si le pipeline est retiré, l'identité est supprimée et rien d'autre ne change.

Erreurs courantes en IAM

• Comptes sur-privilégiés. Des droits d'administrateur accordés "juste pour l'instant" et jamais retirés.
• Identifiants partagés. Plusieurs personnes ou services sur un même compte : aucune ligne de log ne peut être attribuée à quelqu'un.
• Secrets à longue durée de vie dans le code. Clés d'accès dans git ou collées dans des tickets. Préférez des tokens à courte durée de vie.
• Comptes obsolètes. Anciens salariés, prestataires passés et services arrêtés qui gardent un accès.
• Pas d'authentification multifacteur sur les comptes administrateur. Un mot de passe volé devient une compromission totale.
• Pas de revues d'accès. Les permissions s'accumulent pendant des années parce que personne ne les contrôle.

IAM, sécurité des API et tests de performance

L'IAM s'applique au niveau de l'API : chaque appel porte un token ou une clé que votre passerelle vérifie par rapport aux rôles et aux politiques. C'est le sujet de la sécurité des API, et c'est pourquoi un bon IAM doit aussi tenir face à un trafic réel. Les émetteurs de tokens limitent le débit, les tokens expirent au milieu d'un long test et le renouvellement ajoute sa propre latence. Le guide sur les tests de performance d'API avec OAuth2 (en anglais) détaille ces effets.

LoadFocus n'est pas un fournisseur d'identité : votre IAM reste le vôtre. LoadFocus apporte le côté trafic : des tests de charge pour voir comment se comportent vos endpoints de connexion et de tokens sous charge, et le monitoring d'API pour surveiller en continu les endpoints protégés.

Questions fréquentes : IAM

Quelle est la différence entre authentification et autorisation ?

L'authentification prouve qui vous êtes, par exemple avec un mot de passe et un second facteur. L'autorisation décide ensuite ce que vous pouvez faire, selon des rôles ou des politiques. Un système authentifie d'abord, puis autorise chaque action.

Le RBAC suffit-il ?

Pour la plupart des équipes, oui. Commencez avec peu de rôles et revoyez-les régulièrement. Passez aux règles par attributs seulement quand les rôles se multiplient ou que l'accès dépend des données, par exemple quand un client ne doit jamais voir les enregistrements d'un autre.

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

Donner à une identité uniquement les permissions dont elle a besoin pour sa tâche, et rien de plus. Refuser par défaut et accorder des actions précises sur des ressources précises limite les dégâts d'un identifiant divulgué.

En quoi l'IAM diffère-t-il du PAM ?

L'IAM couvre toutes les identités et toutes les décisions d'accès. La gestion des accès à privilèges (PAM) en est le sous-ensemble qui protège les comptes puissants comme root, les administrateurs de bases de données et les accès de secours, généralement avec un coffre pour les identifiants, l'enregistrement des sessions et des accès limités dans le temps.

Dois-je construire mon propre IAM ou utiliser un fournisseur ?

Utilisez un fournisseur établi ou l'IAM de votre cloud. Le stockage des mots de passe, la gestion des sessions, la récupération de compte et les journaux d'audit sont faciles à mal faire sans s'en apercevoir, et une erreur à cet endroit touche tout ce qui se trouve derrière la connexion.