0Pricing
Ethical Hacking Academy · Leçon

Surface d’attaque du cloud

AWS, Azure, GCP

Surface d’attaque du cloud est une leçon Ethical Hacking Academy gratuite sur CoddyKit. Ceci est la leçon 1 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Ethical Hacking Academy, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Ethical Hacking Academy comprend 4 leçons au total.

Qu’est-ce que la surface d’attaque du cloud ?

La surface d’attaque du cloud est l’ensemble des points par lesquels un attaquant pourrait tenter d’entrer dans un environnement cloud ou d’en extraire des données. Contrairement aux réseaux sur site, la surface cloud est principalement définie par la configuration et les identités, et non par un périmètre physique.

  • API et consoles d’administration accessibles publiquement
  • Gestion des identités et des accès (IAM)
  • Buckets de stockage, bases de données et fonctions sans serveur
  • Exposition réseau (groupes de sécurité, équilibreurs de charge)

Un seul paramètre mal configuré peut exposer un compte entier.

Le trio principal : AWS, Azure et GCP

La plupart des tests d’intrusion cloud ciblent l’un des trois grands fournisseurs. Chacun possède son propre modèle d’identité et sa propre terminologie, mais les schémas d’attaque se ressemblent.

  • AWS — utilisateurs et rôles IAM, S3, EC2, Lambda
  • Azure — Entra ID (Azure AD), Blob Storage, machines virtuelles, Functions
  • GCP — comptes de service IAM, Cloud Storage, Compute Engine

En apprendre un en profondeur facilite l’apprentissage des autres, car les concepts fondamentaux (identité, calcul, stockage, réseau) se retrouvent chez tous.

Le modèle de responsabilité partagée

Les fournisseurs cloud sécurisent l’infrastructure ; le client sécurise ce qu’il y place. C’est le modèle de responsabilité partagée, et presque toutes les compromissions cloud se produisent du côté du client.

  • Fournisseur : centres de données physiques, hyperviseur, correctifs des services gérés
  • Client : politiques IAM, données, correctifs de l’OS (IaaS), configuration réseau

En tant que testeur d’intrusion, concentrez-vous sur les responsabilités du client, car c’est là que se trouvent les erreurs exploitables.

Énumérer les identités cloud

La première tâche lors d’une évaluation cloud consiste à déterminer qui vous êtes et ce que vous pouvez faire avec les identifiants dont vous disposez. La CLI AWS expose instantanément l’identité de l’appelant.

Si une clé dispose de trop d’autorisations, cette identité peut à elle seule se déplacer dans l’ensemble du compte.

# Confirm which AWS identity a credential belongs to
aws sts get-caller-identity

# Example output
# {
#   "UserId": "AIDA...",
#   "Account": "123456789012",
#   "Arn": "arn:aws:iam::123456789012:user/devuser"
# }

Surface publique ou privée

Les ressources cloud peuvent être accessibles depuis l’Internet public ou uniquement depuis l’intérieur d’un réseau virtuel. Une exposition mal configurée est l’une des constatations les plus courantes.

  • Groupes de sécurité / NSG ouverts à 0.0.0.0/0
  • Buckets de stockage configurés en lecture publique
  • Bases de données dont les points de terminaison publics sont activés
  • Ports d’administration (22, 3389, 5432) exposés

Cartographier les ressources publiques constitue le fondement de la reconnaissance cloud.

Découvrir les ressources depuis l’extérieur

Même sans identifiants, les attaquants énumèrent l’empreinte cloud d’une cible. Les noms prévisibles et le DNS révèlent une quantité surprenante d’informations.

Les outils testent par force brute les noms de buckets et de stockages en s’appuyant sur le nom de l’entreprise et des schémas courants.

# Resolve a cloud-hosted hostname to map provider/region
nslookup assets.example.com

# Probe a guessed S3 bucket name
curl -s -o /dev/null -w '%{http_code}\n' https://example-backups.s3.amazonaws.com/

Plan de gestion et plan de données

Deux couches d’attaque distinctes existent dans chaque compte cloud :

  • Plan de gestion/contrôle — les API qui créent, modifient et suppriment les ressources (par exemple iam:CreateUser, ec2:RunInstances)
  • Plan de données — l’accès aux données contenues dans les ressources (lecture d’un objet S3, interrogation d’une base de données)

La compromission du plan de gestion signifie généralement que la partie est perdue, car l’attaquant peut s’accorder tous les accès au plan de données qu’il souhaite.

Surface de journalisation et de détection

Les actions effectuées dans le cloud sont journalisées de manière centralisée. En tant que pentester, vous devez savoir que ces journaux existent, car les défenseurs les surveillent ; constater qu’ils sont désactivés constitue en soi une vulnérabilité.

  • AWS CloudTrail — enregistre tous les appels d’API
  • Azure Journal d’activité / Surveillance
  • GCP Journaux d’audit du cloud

Un compte dont la journalisation est désactivée ou qui n’est pas surveillé constitue une vulnérabilité à haut risque, même avant toute exploitation.

# Check whether CloudTrail logging is active
aws cloudtrail describe-trails
aws cloudtrail get-trail-status --name my-trail

Points d’entrée courants dans le cloud

La plupart des compromissions du cloud commencent par l’un de quelques points d’appui :

  • Clés d’accès divulguées dans des dépôts Git, des journaux d’intégration continue ou des applications mobiles
  • Rôles IAM excessivement permissifs associés à des serveurs compromis
  • SSRF atteignant le service de métadonnées de l’instance
  • Buckets de stockage publics exposant des secrets ou des sauvegardes

Reconnaître ces schémas vous permet de déterminer où chercher en priorité.

Cartographier méthodiquement la surface

Une approche structurée permet de mener une évaluation du cloud de manière exhaustive. Les outils automatisés énumèrent l’intégralité du compte dès que vous disposez des identifiants.

Des outils comme ScoutSuite et Prowler vérifient la configuration des différents services et signalent automatiquement les risques.

# Audit an AWS account for misconfigurations (read-only)
prowler aws

# Multi-cloud configuration review
scout aws

Périmètre et autorisation en premier

Les tests du cloud doivent rester dans le cadre de l’autorisation prévue pour la mission. Les fournisseurs ont également leurs propres règles d’engagement.

  • Confirmez précisément les comptes, abonnements ou projets compris dans le périmètre
  • Évitez les actions qui affectent d’autres locataires ou une infrastructure partagée
  • Ne lancez jamais de tests de type déni de service sans autorisation écrite explicite

Des tests du cloud non autorisés peuvent enfreindre les conditions du fournisseur et le droit local.

Vérification rapide

Dans le modèle de responsabilité partagée, quelle partie est responsable des politiques IAM et de la configuration des données ?

Récapitulatif : surface d’attaque du cloud

Vous avez appris ce qui définit la surface d’attaque du cloud et en quoi elle diffère des réseaux traditionnels.

  • La surface est déterminée par l’identité et la configuration, et non par un périmètre physique
  • AWS, Azure et GCP partagent les mêmes concepts fondamentaux : identité, calcul, stockage et réseau
  • Le modèle de responsabilité partagée attribue la configuration et les données au client
  • Distinguez le plan de gestion du plan de données
  • Confirmez toujours le périmètre et l’autorisation avant les tests

Ensuite, nous examinerons en détail les mauvaises configurations IAM, au cœur des attaques contre le cloud.

Questions Fréquemment Posées

La leçon « Surface d’attaque du cloud » est-elle gratuite ?

Oui — le texte complet de « Surface d’attaque du cloud » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Ethical Hacking Academy, passe à CoddyKit PRO. Le cours Ethical Hacking Academy comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Surface d’attaque du cloud » ?

AWS, Azure, GCP Tu pratiques Ethical Hacking Academy avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer Ethical Hacking Academy ?

Aucune expérience préalable n'est requise. Ethical Hacking Academy sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 1 sur 4.

Combien de temps prend la leçon « Surface d’attaque du cloud » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon Ethical Hacking Academy ?

Oui. Chaque leçon Ethical Hacking Academy inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

  1. Surface d’attaque du cloud
  2. Mauvaises configurations IAM
  3. Exposition de S3 et du stockage
  4. Métadonnées et SSRF
← Retour à Ethical Hacking Academy