📅 Publié le 7 août 2026 sur le blog officiel AWS Security, cet article technique présente une méthodologie structurée pour détecter, remédier et surveiller en continu les buckets Amazon S3 sur-permissifs dans des environnements AWS mono ou multi-comptes.

🔍 Contexte et problématique Les buckets S3 mal configurés — via des politiques trop larges ou des ACL (Access Control Lists) permissives — peuvent exposer des données sensibles à des accès non autorisés. Sans revue proactive, ces configurations passent inaperçues.

🏗️ Architecture de la solution en cinq phases

  • Phase 1 – Prérequis : Configuration d’AWS Organizations, désignation d’un compte de sécurité central, déploiement d’AWS Config et activation d’AWS Security Hub.
  • Phase 2 – Détection : Déploiement de règles AWS Config (s3-bucket-public-read-prohibited, s3-bucket-public-write-prohibited) et d’une fonction Lambda d’audit en Python/Boto3 vérifiant le Public Access Block, le statut des politiques de bucket et les grants ACL. Les résultats sont exportés en CSV/JSON et une alerte SNS est envoyée.
  • Phase 3 – Remédiation : Application de politiques restrictives, déploiement d’une Lambda de remédiation automatique, ou utilisation de CloudFormation StackSets pour standardiser les politiques multi-comptes.
  • Phase 4 – Surveillance continue : Planification via Amazon EventBridge (quotidien/hebdomadaire), détection des changements de politique, activation d’IAM Access Analyzer pour identifier les accès externes.
  • Phase 5 – Nettoyage : Suppression des ressources créées pour l’audit (Lambda, rôles IAM, règles EventBridge, topics SNS, buckets de sortie, règles Config).

🛠️ Composants techniques utilisés

  • AWS Lambda (Python/Boto3)
  • AWS Config avec règles managées
  • AWS Security Hub
  • Amazon SNS
  • Amazon EventBridge
  • IAM Access Analyzer
  • AWS CloudFormation StackSets
  • AWS Organizations

⚠️ Points de sécurité clés vérifiés par la Lambda

  • Public Access Block non entièrement activé (4 paramètres)
  • Politique de bucket marquée comme publique (IsPublic: true)
  • ACL accordant l’accès à AllUsers ou AuthenticatedUsers

📊 Type d’article Article technique de type guide pratique (how-to), publié par AWS, destiné aux ingénieurs sécurité, architectes cloud et équipes DevOps. Son but principal est de fournir un cadre méthodologique et des exemples de code adaptables pour sécuriser les buckets S3 sur-permissifs.

🧠 TTPs et IOCs détectés

TTP

  • T1530 — Data from Cloud Storage (Collection)

IOC

  • Chemins : /tmp/full_access_buckets.csv

⚠️ À propos de ces IOC — ils sont extraits automatiquement de l’article original le 10 août 2026 et n’ont pas fait l’objet d’une vérification externe. Un indicateur peut avoir été réattribué depuis : une IP de C2 peut redevenir un service légitime, un domaine sinkholé peut changer de propriétaire. Aucune garantie d’exactitude ni d’actualité — contrôlez leur validité avant tout usage opérationnel, en particulier avant de les injecter dans une blocklist ou un SIEM.

🟡 Indice de vérification factuelle : 59/100 (moyenne)

  • ✅ aws.amazon.com — source reconnue (Rösti community) (20pts)
  • ✅ 15000 chars — texte complet (fulltext extrait) (15pts)
  • ✅ 1 IOC(s) (6pts)
  • ⬜ pas d’IOC vérifié (0pts)
  • ✅ 1 TTP(s) MITRE (8pts)
  • ✅ date extraite du HTML source (10pts)
  • ⬜ aucun acteur de menace nommé (0pts)
  • ⬜ pas de CVE à vérifier (0pts)

🔗 Source originale : https://aws.amazon.com/blogs/security/securing-your-amazon-s3-buckets-identifying-and-remediating-over-permissioned-access/