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. Le principe de moindre privilège recommandé par AWS est rarement appliqué strictement en pratique.

Erreurs fréquentes :

  • politiques trop permissives avec des wildcards (voir les erreurs IAM critiques les plus courantes) ;
  • 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 - ces ressources hors gouvernance s'apparentent souvent à du shadow cloud.

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. L’ATT&CK Cloud Matrix (MITRE) documente ces techniques d’escalade et de persistance sur AWS.

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.