Contrôle fin des autorisations S3 avec les tags et les politiques IAM

Contexte et objectifs

Dans les environnements AWS, le stockage d’objets dans Amazon S3 est omniprésent, mais la gestion des droits d’accès reste critique. Les certifications AWS examinent la capacité à appliquer le principe du moindre privilège et à exploiter les mécanismes de tags pour simplifier la gouvernance. Cet article montre comment créer une politique IAM qui accorde l’accès uniquement aux buckets et aux objets portant des tags spécifiques, tout en conservant une architecture maintenable.

1. Principes des tags et des conditions IAM

• Tag d’un bucket : paire clé/valeur attachée au bucket (aws:s3:tag).
• Tag d’un objet : même notion, mais appliquée aux objets au moment de leur création.
• Condition StringEquals : permet de comparer la valeur du tag avec une valeur attendue.
• Condition ForAllValues:StringEquals : utile lorsqu’un bucket possède plusieurs tags.

IAM ne propose pas de condition directe sur les tags d’un objet ; il faut alors recourir aux conditions de type s3:ExistingObjectTag qui s’appliquent lors d’opérations comme GetObject ou PutObject.

2. Étape : baliser vos ressources S3

# Créer un bucket dédié aux logs d'application
aws s3api create-bucket --bucket logs-app-prod --region eu-west-1

# Ajouter un tag "Env=Prod" au bucket
aws s3api put-bucket-tagging \
  --bucket logs-app-prod \
  --tagging 'TagSet=[{Key=Env,Value=Prod}]'

Il est recommandé de normaliser les clés de tags (Env, Team, Project) afin d’éviter les incohérences entre équipes.

3. Rédaction d’une politique IAM basée sur les tags

Voici une politique qui autorise :

• La lecture (s3:GetObject) uniquement sur les objets possédant le tag Env=Prod.
• La mise à jour (s3:PutObject) uniquement si l’objet est créé avec le même tag.
• La liste (s3:ListBucket) du bucket uniquement si le bucket porte le tag Env=Prod.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": "arn:aws:s3:::logs-app-prod",
      "Condition": {
        "StringEquals": {"s3:ExistingBucketTag/Env": "Prod"}
      }
    },
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::logs-app-prod/*",
      "Condition": {
        "StringEquals": {"s3:ExistingObjectTag/Env": "Prod"}
      }
    },
    {
      "Effect": "Allow",
      "Action": ["s3:PutObject"],
      "Resource": "arn:aws:s3:::logs-app-prod/*",
      "Condition": {
        "StringEquals": {"s3:RequestObjectTag/Env": "Prod"}
      }
    }
  ]
}

Cette politique doit être rattachée à un rôle ou à un utilisateur dédié (par ex. AppLogReader). Le serveur d’application doit inclure le tag Env=Prod lors de chaque PutObject :

aws s3api put-object \
  --bucket logs-app-prod \
  --key app.log \
  --body ./app.log \
  --tagging "Env=Prod"

4. Bonnes pratiques et pièges à éviter

• Uniformité des tags : créez une convention de nommage et documentez‑la. Une différence de casse (prod vs Prod) entraîne un refus d’accès.
• Limite de 10 tags par ressource : prévoyez un schéma qui utilise les tags les plus discriminants.
• Éviter les politiques trop larges : ne combinez pas s3:* avec des conditions de tag, sinon le filtre est ignoré.
• Audit : utilisez AWS CloudTrail pour vérifier que les actions S3 sont bien filtrées par les tags attendus.
• Séparation des responsabilités : attribuez les droits de création de tags à un groupe dédié afin de garantir que les développeurs ne puissent pas contourner les restrictions.

5. Résumé

En associant les tags aux buckets et aux objets, puis en exploitant les conditions IAM s3:ExistingBucketTag/* et s3:ExistingObjectTag/*, on obtient un contrôle d’accès granulaire, facile à auditer et aligné avec les exigences des certifications AWS (notamment les modules sur la sécurité et la gouvernance). Cette approche réduit le nombre de politiques individuelles, simplifie la rotation des privilèges et renforce la conformité aux meilleures pratiques de sécurité.