> ## Content Index
> Fetch the complete content index at: https://www.idriss-benbassou.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# AWS IAM pour la data : lire une policy et les privilèges
- URL: https://www.idriss-benbassou.com/iam-data-roles-policies-moindre-privilege/
- Published: 2026-08-25T18:47:23.000Z
- Updated: 2026-08-25T18:47:23.000Z
- Author: Idriss BENBASSOU
- Tags: AWS, #rating-2

Depuis le début de la formation, à chaque service on a cliqué souvent sur "Create new IAM role" sans trop regarder, et on a même mis un `AmazonS3FullAccess` sur la Lambda en se disant qu'on y reviendrait. et il est temps maintenant pour tout mettre au propre.

## Le vocabulaire à connaitre

**Policy** : un fichier JSON qui liste les droits, du type "cette action, sur cette ressource, autorisée ou refusée".

**Role** : une identité temporaire qu'un service prend le temps de son exécution. C'est ce que font le crawler, le job Glue, la Lambda et la state machine depuis le début, ils n'ont pas de mot de passe, ils empruntent un rôle.

**User** : un compte permanent avec mot de passe et clés d'accès, pour une personne. 

***Trust policy*** : elle dit qui a le droit d'utiliser le rôle. C'est la partie que personne ne regarde et qui explique la moitié des erreurs.

## Lire une policy JSON

Toutes les policies ont la même structure et voici celle qu'on va donner à la Lambda.

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "LireLanding",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:DeleteObject"],
      "Resource": "arn:aws:s3:::ibdata-datalake-formation/landing/*"
    },
    {
      "Sid": "EcrireRaw",
      "Effect": "Allow",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::ibdata-datalake-formation/raw/*"
    }
  ]
}

```

Effect c'est Allow ou Deny. Action, ce qu'on autorise et au format `service:Operation`. Resource, sur quoi, avec son ARN. Sid, un libellé libre mais attention il faut le remplire avec un libellé clair et explicite pour la gouvernance.

Nb : l'ARN d'un bucket et l'ARN de son contenu ne sont pas la même chose. Donc par exemple `arn:aws:s3:::mon-bucket` c'est le bucket (pour lister), `arn:aws:s3:::mon-bucket/*` c'est les objets dedans (pour lire et écrire). Un `ListBucket` sur l'ARN avec `/*` ne marchera jamais.

## Remplacer le FullAccess de la Lambda

Notre Lambda a `AmazonS3FullAccess`, donc elle a accès à tous les buckets S3 du compte et c'est beaucoup trop large et on évite ce genre de droits en mission.

![](https://storage.ghost.io/c/60/f1/60f18be4-df79-4956-8e4a-c2fa80212e93/content/images/2026/08/image-105.png)

1. Ouvre IAM, menu Policies, "Create policy", onglet JSON.
2. Colle la policy ci-dessus, nomme-la `policy-lambda-landing-raw`, et crée-la.
3. Menu Roles, ouvre le rôle de la Lambda (`fn-landing-vers-raw-role-...`).
4. Attache la nouvelle policy, puis détache `AmazonS3FullAccess`.

![](https://storage.ghost.io/c/60/f1/60f18be4-df79-4956-8e4a-c2fa80212e93/content/images/2026/08/image-107.png)

Pour tester, duplique le fichier `commandes`, renomme-le `commandes_lambda` et dépose-le dans `landing/`. Il doit arriver dans `raw/` comme avant, sauf que cette fois la Lambda n'a accès qu'aux ressources dont elle a vraiment besoin.

![](https://storage.ghost.io/c/60/f1/60f18be4-df79-4956-8e4a-c2fa80212e93/content/images/2026/08/image-110.png)

💡

Nb : Les changements de droits sont presque toujours instantanés, mais pas systématiquement. Donc si un test échoue juste après une modif de policy, attends quelques minutes et retente avant de chercher l'erreur ailleurs.

## Le rôle de service, côté trust policy

On ouvre maintenant le rôle du crawler, `AWSGlueServiceRole-formation`, onglet "Trust relationships".

```json
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "glue.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}

```

Ce bloc dit une seule chose, seul le service Glue peut utiliser ce rôle. C'est pour ça qu'un rôle créé pour Glue ne marchera jamais avec Lambda, même si les permissions derrière sont bonnes, Lambda n'a tout simplement pas le droit de le prendre. Si tu vois l'erreur `is not authorized to perform: sts:AssumeRole`, c'est là qu'il faut regarder, pas dans les permissions

![](https://storage.ghost.io/c/60/f1/60f18be4-df79-4956-8e4a-c2fa80212e93/content/images/2026/08/image-108.png)

## Debugger un AccessDenied

Souvent le message d'erreur contient déjà la réponse, il faut juste savoir le lire. Celui qu'on a eu dans l'article Lambda :

```
User: arn:aws:sts::850919910380:assumed-role/fn-landing-vers-raw-role-073p97s9/fn-landing-vers-raw
is not authorized to perform: s3:GetObject
on resource: "arn:aws:s3:::ibdata-datalake-formation/landing/commandes.csv"

```

💡

Trois infos dans l'ordre, ****qui** (le rôle, ligne 1), quelle action manque (ligne 2), sur quelle ressource (ligne 3). On peut appliquer donc la correction directement.

Pour tester, il y a le IAM Policy Simulator, on on peut choisir un rôle, une action, une ressource, et on peut savoir rapidement si c'est allowed ou denied avec la policy donc c'est trés pratique avant une mise en prod ou quand un refus n'a aucun sens.

## Les erreurs à ne pas faire

Le wildcard partout car une policy avec `"Action": "*"` et `"Resource": "*"`, c'est un accès admin déguisé et peut être très dangereux.

Le rôle unique pour tout le pipeline, il faut un rôle par service, c'est ce qui te permet de savoir qui fait quoi dans les logs CloudTrail, et de retirer un droit sans tout casser.

Les access keys dans le code au lieu d'utilise les rôles.

Les policies AWS managées global en prod qui donnent trop d'accès car pareil que les wildcard avoir des `*FullAccess` dépannent bien en dev pour démarrer, mais ce n'est pas top en terme de gouvernance et contrôle d'accés et usage. 

## 

### Combien ça coûte ?

**0 €.** IAM est gratuit, quel que soit le nombre de rôles, de policies et d'utilisateurs.

## La suite ?

IAM gère l'accès aux services et aux fichiers, mais il ne sait pas dire "cette personne voit la table commandes sauf la colonne montant". Pour ce niveau de détail sur le lake il faut utiliser le Lake Formation, avec les droits par table et par colonne, plus le chiffrement KMS du bucket et ce sera justement le sujet du prochain article.

## Aller plus loin

Le programme complet du parcours est sur la page de [la formation AWS](https://www.idriss-benbassou.com/formation-aws/).

Tu prépares la certification AWS Certified Data Engineer Associate (DEA-C01) ? IAM, les rôles de service et le moindre privilège sont au programme du domaine sécurité. Pour t'entraîner, j'ai créé des questions d'examen blanc en français.

👉 [S'entraîner sur DataCertification.fr](https://datacertification.fr/certifications?ref=idriss-benbassou.com)

Tu veux que je t'accompagne sur ton projet data (AWS, Snowflake, dbt, modélisation, coûts) ?

👉 [Réserver un appel de 30 minutes](https://calendly.com/idriss-benbassou-datavio/30min?ref=idriss-benbassou.com)

## Questions fréquentes

#### Quelle différence entre un rôle et un utilisateur IAM ?

L'utilisateur est une identité permanente avec mot de passe et clés d'accès, pour une personne. Le rôle est une identité temporaire endossée par un service ou un utilisateur, avec des identifiants renouvelés automatiquement. Les services AWS travaillent toujours avec des rôles.

#### Comment lire une policy IAM ?

Chaque Statement répond à trois questions, Effect (Allow ou Deny), Action (l'opération autorisée, au format service:Operation) et Resource (l'ARN concerné). Le champ Sid sert de libellé pour retrouver le sens du bloc plus tard.

#### Pourquoi mon rôle S3 ne fonctionne pas malgré les permissions ?

Souvent à cause de l'ARN. L'ARN du bucket (arn:aws:s3:::mon-bucket) sert aux actions sur le bucket comme ListBucket, l'ARN des objets (arn:aws:s3:::mon-bucket/\*) sert à GetObject et PutObject. Il faut les deux quand les deux types d'actions sont nécessaires.

#### C'est quoi une trust policy ?

Le document qui dit qui a le droit d'endosser un rôle. Pour un rôle de service, il autorise un service précis (glue.amazonaws.com, lambda.amazonaws.com). Une erreur sts:AssumeRole vient toujours de là, pas des permissions.

#### Comment debugger une erreur AccessDenied sur AWS ?

Le message contient tout, le rôle concerné, l'action manquante et la ressource visée. Il suffit d'ajouter cette action sur cette ressource dans la policy du rôle. Le IAM Policy Simulator permet aussi de tester un droit avant de le déployer.