AWS : pourquoi votre cloud est vulnérable même si Security Hub est au vert

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

  • AWS Security Hub ne remonte rien de critique
  • GuardDuty n’a généré aucune alerte
  • Les buckets S3 ne sont pas publics

C’est une illusion.

Un attaquant sérieux ne cherche pas un bucket public. Il cherche un chemin d’escalade de privilèges.

 

1. Le vrai problème : IAM mal compris

https://miro.medium.com/0%2A2qvQJOBLk8HEDQNd

 

IAM est le cœur du risque AWS.

Erreurs fréquentes :

  • Policies trop permissives avec des wildcards
  • Rôles assumables sans condition stricte
  • Confiance inter-comptes mal maîtrisée
  • Absence de séparation entre rôles techniques et humains

Un exemple classique :
Un utilisateur a la permission iam:PassRole sur un rôle plus privilégié.
Il crée une ressource EC2 avec ce rôle.
Il récupère les credentials via le metadata service.
Escalade réussie.

Security Hub peut être vert.
L’environnement reste exploitable.

 

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

Un attaquant AWS ne s’arrête pas à une permission.

Il construit une chaîne :

  1. Accès initial via clé API exposée
  2. Enumeration IAM
  3. Identification d’un rôle assumable
  4. Escalade de privilège
  5. Accès à Secrets Manager
  6. Pivot vers RDS ou autre compte AWS

Ce type d’attaque ne ressemble pas à une faille classique.
C’est un abus logique de permissions légitimes.

C’est là que se joue la vraie sécurité cloud.

 

3. Les angles morts des environnements AWS

https://d2908q01vomqb2.cloudfront.net/22d200f8670dbdb3e253a90eee5098477c95c23d/2018/01/21/AR_Diagram_010418.png

4

Zones souvent ignorées :

– AWS Organizations

Mauvaise gestion des SCP.
Confiance excessive entre comptes.

– Lambda et rôles d’exécution

Fonctions avec privilèges trop larges.
Possibilité d’injecter du code via CI/CD compromis.

– STS et AssumeRole

Escalades inter-comptes via trust policies permissives.

– Journalisation

CloudTrail activé, mais non surveillé.
Logs stockés dans le même compte compromis.

 

4. Pourquoi les audits AWS classiques sont insuffisants

Beaucoup d’audits cloud se limitent à :

  • Analyse statique des policies
  • Vérification des services exposés
  • Scan automatisé

Ce n’est pas un pentest cloud.

Un vrai test AWS doit :

  • Simuler un attaquant interne avec clé API
  • Tenter une escalade IAM réelle
  • Tester les pivots inter-comptes
  • Vérifier l’impact business réel

La question n’est pas :
« Y a-t-il une mauvaise configuration visible ? »

La vraie question est :
« Peut-on devenir administrateur à partir d’un accès limité ? »

 

5. Comment se défendre concrètement

Approche efficace :

  • Appliquer le principe de moindre privilège strict
  • Supprimer les wildcards sur les actions sensibles
  • Interdire iam:PassRole sauf nécessité absolue
  • Segmenter les comptes via AWS Organizations
  • Centraliser les logs dans un compte isolé
  • Mettre en place une revue IAM trimestrielle

Et surtout :
Faire tester votre environnement par quelqu’un qui pense comme un attaquant.

 

Conclusion

Le risque AWS ne vient pas d’un bucket S3 public.
Il vient d’une mauvaise compréhension des mécanismes IAM.

Le cloud n’est pas moins sécurisé qu’un datacenter.
Il est simplement plus complexe.

Et dans la complexité, l’attaque trouve toujours un chemin.