IAM expliqué : identités, rôles, RBAC et moindre privilège

L’IAM (Identity and Access Management) répond à une question simple mais centrale : qui peut faire quoi, sur quelle ressource ? C’est le fondement de la sécurité de tout système, et un sujet que tout pipeline qui génère du code cloud doit traiter correctement.

Les briques de l’IAM

• Identité (principal) : un utilisateur, un service, une application.
• Authentification : prouver qui l’on est (mot de passe, clé, token).
• Autorisation : ce que l’on a le droit de faire, une fois identifié.
• Ressource : ce sur quoi on agit (un bucket, une base, une file).

RBAC : le contrôle d’accès par rôles

Plutôt que d’attribuer des permissions une par une, on les regroupe en rôles qu’on assigne aux identités. Un développeur reçoit le rôle « lecture logs », pas trente permissions éparses. Plus simple à auditer, plus difficile à se tromper.

Le principe du moindre privilège

La règle d’or : n’accorder que le strict nécessaire, rien de plus. Une politique typique, au format déclaratif :

{
  "Effect": "Allow",
  "Action": ["s3:GetObject"],
  "Resource": "arn:aws:s3:::rapports/*"
}

Ici, l’identité peut lire les objets d’un seul bucket — ni écrire, ni supprimer, ni toucher au reste. Comparez à un "Action": "s3:*" sur "Resource": "*" : ce dernier est la porte ouverte aux catastrophes.

Les erreurs fréquentes

• Des rôles « administrateur » distribués par confort.
• Des secrets longue durée au lieu de jetons temporaires.
• L’absence de revue régulière des accès.

Un pipeline contractuel peut injecter ces bonnes pratiques par défaut — moindre privilège, rôles ciblés, secrets gérés — plutôt que de les laisser en exercice à l’utilisateur. La sécurité par défaut bat la sécurité optionnelle.