Beaucoup d’entreprises pensent être sécurisées parce que :

  • AWS Security Hub ne remonte rien de critique ;
  • GuardDuty n’a pas généré d’alerte récente ;
  • les buckets S3 ne sont pas publics.

C’est une illusion. Un attaquant déterminé ne se limite pas à chercher un bucket public : il cherche un chemin d’escalade de privilèges à partir d’un accès déjà obtenu.

1. Le vrai problème : IAM mal compris

IAM est au cœur du risque AWS.

Erreurs fréquentes :

  • politiques trop permissives avec des wildcards ;
  • rôles assumables sans conditions strictes ;
  • confiance inter-comptes mal maîtrisée ;
  • absence de séparation nette entre rôles techniques et comptes humains.

Exemple classique : un utilisateur dispose de iam:PassRole vers un rôle plus privilégié → il lance une ressource (ex. EC2) avec ce rôle → récupération de métadonnées / credentials → escalade réussie.

Security Hub peut afficher un tableau rassurant ; l’environnement reste exploitable si les chaînes IAM le permettent.

2. L’attaque moderne : la chaîne d’abus

Un attaquant sur AWS ne s’arrête pas à une permission isolée. Il construit une chaîne :

  1. accès initial (clé API exposée, compte compromis, CI/CD) ;
  2. énumération IAM ;
  3. identification d’un rôle ou d’un chemin AssumeRole ;
  4. escalade de privilège ;
  5. accès à Secrets Manager, bases, ou autres comptes ;
  6. pivot vers la donnée métier.

Ce scénario ressemble souvent à un abus logique de permissions légitimes, pas à une CVE isolée. C’est là que se joue la sécurité cloud réelle.

3. Les angles morts des environnements AWS

Zones souvent sous-estimées :

AWS Organizations

SCP mal calibrées, confiance excessive entre comptes, comptes « satellite » hors processus standard.

Lambda et rôles d’exécution

Fonctions avec des rôles trop larges ; risque si la chaîne CI/CD ou le dépôt est compromis.

STS et AssumeRole

Escalades inter-comptes lorsque les trust policies sont trop ouvertes.

Journalisation

CloudTrail activé mais logs peu consultés, ou stockés dans un compte qui peut être atteint par le même chemin d’abus.

4. Pourquoi les audits AWS « classiques » sont souvent insuffisants

Trop d’audits se limitent à :

  • analyse statique des policies ;
  • vérification des services exposés ;
  • scans automatisés.

Ce n’est pas équivalent à un pentest cloud. Un test sérieux doit :

  • simuler un attaquant disposant d’un accès limité (clé, rôle faible) ;
  • tenter une escalade IAM réelle ;
  • tester les pivots inter-comptes ;
  • relier les findings à un impact métier (données, indisponibilité, conformité).

La bonne question n’est pas : « Y a-t-il une mauvaise configuration évidente ? » mais : « Peut-on atteindre un objectif critique à partir d’un accès restreint ? »

5. Se défendre concrètement

  • appliquer le moindre privilège de façon stricte ;
  • supprimer les wildcards sur les actions sensibles ;
  • limiter iam:PassRole aux cas indispensables ;
  • segmenter les comptes (Organizations, landing zone) ;
  • centraliser et protéger les logs (compte dédié, immuabilité, corrélation) ;
  • instaurer une revue IAM périodique ;
  • faire tester l’environnement par quelqu’un qui raisonne comme un attaquant - voir nos prestations pentest et audit AWS.

Conclusion

Le risque AWS ne vient pas seulement d’un bucket public : il vient souvent d’une mauvaise maîtrise des mécanismes IAM et des chaînes d’abus. Le cloud n’est pas « moins sûr » qu’un datacenter : il est plus complexe, et c’est dans cette complexité que l’attaque trouve un chemin.

Pour en discuter sur votre périmètre : demande de contact.