Surface d’attaque du cloud

Dans le cloud, le fournisseur sécurise l'infrastructure tandis que le client sécurise la configuration, l'identité et les données. La plupart des compromissions surviennent du côté du client.

• Le fournisseur corrige les hyperviseurs et assure la sécurité physique.
• Le client est responsable des politiques IAM, des autorisations de stockage et des règles réseau.
• Les erreurs de configuration, et non la compromission du fournisseur, constituent le risque dominant.

Le cloud n'a pas de frontière réseau traditionnelle. L'accès est régi par IAM : utilisateurs, rôles, politiques et clés. Une clé d'accès divulguée peut être aussi dommageable qu'un mot de passe d'administrateur de domaine volé.

• Les politiques IAM autorisent des actions sur des ressources.
• Les rôles permettent aux services et aux utilisateurs d'endosser des identifiants temporaires.
• Les identités trop permissives constituent le principal vecteur d'élévation.

Les identifiants cloud sont constamment exposés. Les sources courantes comprennent :

• Clés d'accès enregistrées dans des référentiels Git publics.
• Clés codées en dur dans des applications mobiles, des journaux de CI ou des images de conteneurs.
• Falsification de requêtes côté serveur (SSRF) atteignant le service de métadonnées.
• Partage excessivement large de clés à longue durée de vie au lieu de rôles à courte durée de vie.

Chaque instance infonuagique expose un point de terminaison de métadonnées capable de fournir des identifiants temporaires associés à un rôle. Une SSRF ou une RCE sur une VM qui peut l'atteindre permet souvent d'obtenir le rôle de l'instance.

• AWS IMDS est accessible à l'adresse 169.254.169.254.
• IMDSv1 se limite aux requêtes et peut être exploité très facilement via une SSRF.
• IMDSv2 exige un jeton de session (PUT puis GET), ce qui neutralise de nombreuses attaques SSRF.

Le stockage d'objets (S3, GCS, Blob Azure) est régulièrement à l'origine d'expositions de données.

• Les compartiments accessibles en lecture publique exposent des fichiers sensibles.
• Les compartiments accessibles en écriture publique permettent la falsification de données ou l'hébergement de logiciels malveillants.
• Les politiques de compartiment ou les listes de contrôle d'accès trop permissives accordent un accès aux utilisateurs authentifiés.
• Les URL pré-signées avec une longue durée d'expiration permettent un accès persistant.

Les contrôles réseau infonuagiques (groupes de sécurité, groupes de sécurité réseau, règles de pare-feu) sont faciles à configurer de manière trop permissive.

• Des bases de données ou des ports d'administration exposés à 0.0.0.0/0.
• Des plans de gestion (API Kubernetes, RDP, SSH) accessibles depuis Internet.
• Des services internes qui font implicitement confiance au VPC, sans authentification.

Le sans-serveur déplace les risques, mais ne les élimine pas. Les fonctions, les files d'attente et les bases de données gérées possèdent chacune une identité d'exécution.

• Le rôle d'exécution d'une fonction Lambda peut disposer d'autorisations excessives.
• Les variables d'environnement contiennent souvent des secrets lisibles après une compromission.
• Une mauvaise configuration de la source d'événements peut permettre à des entrées non fiables de déclencher des fonctions privilégiées.

Vous devez distinguer les deux surfaces d'attaque :

• Plan de contrôle : l'API infonuagique (créer des ressources, modifier IAM, lire des configurations). Une compromission de ce plan concerne tout le compte.
• Plan de données : les charges de travail elles-mêmes (applications, VM, conteneurs).

Un point d'appui dans le plan de données qui permet d'obtenir des identifiants du plan de contrôle constitue le scénario classique d'élévation de privilèges dans le cloud.

Les grandes organisations répartissent leurs charges de travail entre de nombreux comptes, abonnements et projets.

• Les rôles intercomptes associés à des politiques de confiance faibles permettent de pivoter.
• Un problème de mandataire confus dans un rôle d'intégration tiers peut être exploité.
• Les rôles au niveau de l'organisation (p. ex. OrganizationAccountAccessRole) ont une valeur élevée.

Les défenseurs s'appuient sur les journaux natifs de l'infonuagique. Les attaquants essaient de les rendre aveugles.

• CloudTrail, le journal d'activité et les journaux d'audit enregistrent les appels du plan de contrôle.
• Les attaquants peuvent désactiver les traces ou interrompre la transmission des journaux.
• GuardDuty, le Centre de commande de sécurité et Defender signalent les anomalies.

La désactivation de la journalisation constitue elle-même un événement très révélateur qui mérite de déclencher une alerte.

Les tests d'intrusion infonuagiques exigent de connaître les règles du fournisseur et d'obtenir son autorisation. Certaines actions (déni de service, certains balayages) enfreignent les conditions d'utilisation du fournisseur. Confirmez toujours la propriété du compte, définissez ensemble le rayon d'impact et privilégiez d'abord l'énumération en lecture seule.

Utilisez un compte de test dédié ou des ressources clairement étiquetées, et ne touchez jamais aux ressources situées en dehors du périmètre documenté.

Vérifiez votre compréhension de la surface d'attaque infonuagique.

Vous avez cartographié la surface d'attaque infonuagique.

• Les erreurs de configuration du côté client dominent les risques infonuagiques.
• L'identité constitue le périmètre de sécurité ; les clés et les rôles exposés sont des vecteurs majeurs.
• Le service de métadonnées relie les vulnérabilités du plan de données aux identifiants infonuagiques.
• Les erreurs de configuration du stockage, du réseau et de la journalisation complètent cette surface.

Ensuite : énumérer les ressources infonuagiques pour trouver ces problèmes.