Pentest Cloud : méthodologie, vulnérabilités et techniques d’exploitation sur AWS, Azure et GCP

Les infrastructures cloud occupent désormais une place centrale dans les systèmes d’information. Applications web, APIs, bases de données, clusters Kubernetes, fonctions serverless, systèmes d’authentification, pipelines CI/CD ou environnements de développement sont fréquemment hébergés sur Amazon Web Services (AWS), Microsoft Azure ou Google Cloud Platform (GCP).

Cette transformation apporte des bénéfices majeurs en matière de flexibilité, d’automatisation et de capacité à faire évoluer rapidement les infrastructures. Elle modifie également profondément leur surface d’attaque. Dans un environnement informatique traditionnel, un attaquant cherche souvent à compromettre une machine, récupérer des identifiants puis progresser vers d’autres systèmes. Ces techniques restent pertinentes dans le cloud, mais les mécanismes IAM, les identités techniques, les APIs de gestion et les relations de confiance entre services occupent désormais une place beaucoup plus importante.

Une application compromise peut par exemple disposer d’une identité lui permettant d’accéder à un gestionnaire de secrets. Un utilisateur faiblement privilégié peut être autorisé à créer un workload utilisant un rôle beaucoup plus puissant. Un pod Kubernetes compromis peut bénéficier d’une identité lui donnant accès aux APIs du fournisseur cloud. Un pipeline CI/CD peut quant à lui posséder les permissions nécessaires pour modifier directement des ressources de production.

Une vulnérabilité initialement limitée à une seule application peut ainsi devenir le point de départ d’une compromission beaucoup plus large. C’est précisément ce que le pentest cloud cherche à évaluer : non seulement les faiblesses présentes, mais aussi la manière dont elles peuvent être combinées pour augmenter progressivement les capacités d’un attaquant.

Dans cet article, nous détaillons les spécificités du pentest cloud, les principales vulnérabilités rencontrées, les différences entre AWS, Microsoft Azure et Google Cloud Platform, ainsi qu’une méthodologie permettant d’analyser les identités, les workloads, Kubernetes, les services de stockage, le serverless, les pipelines CI/CD et l’Infrastructure as Code.

Guide complet sur le pentest cloud

Qu’est-ce qu’un pentest cloud ?

Un pentest cloud est une évaluation de sécurité consistant à simuler des attaques réalistes contre les ressources, les identités et les services déployés dans un environnement cloud. Son objectif est d’identifier les vulnérabilités et mauvaises configurations réellement exploitables, mais également de déterminer les conséquences qu’un attaquant pourrait tirer de leur exploitation.

Cette seconde dimension est essentielle. Un outil automatisé peut signaler qu’une policy IAM contient trop de permissions. Le pentester cherche à déterminer si ces permissions permettent réellement d’obtenir un rôle plus privilégié, de modifier un workload, de récupérer des secrets ou d’accéder à des ressources critiques. De la même manière, un scanner peut identifier un bucket accessible depuis Internet. L’auditeur cherche ensuite à comprendre la nature des données présentes, les opérations autorisées et les conséquences qu’aurait leur consultation ou leur modification.

Le pentest cloud ajoute donc une dimension offensive et contextuelle à l’analyse de sécurité. Il ne demande pas seulement si une configuration respecte une bonne pratique. Il cherche à répondre à une question plus concrète : comment un attaquant pourrait-il exploiter cette configuration dans les conditions réelles de l’environnement ?

Pentest cloud, audit de configuration et CSPM : quelles différences ?

Une revue de configuration consiste principalement à analyser l’état des ressources et à vérifier leur conformité à différentes bonnes pratiques ou politiques de sécurité. Une solution de Cloud Security Posture Management (CSPM) automatise une grande partie de cette démarche. Elle peut par exemple détecter un stockage public, une règle réseau trop permissive, une journalisation désactivée, une absence de chiffrement ou une identité possédant des droits excessifs.

Ces contrôles sont indispensables, mais ils ne reproduisent pas nécessairement le raisonnement d’un attaquant. Une permission considérée comme peu sensible peut devenir critique lorsqu’elle est combinée à une autre permission. Plusieurs erreurs de configuration apparemment mineures peuvent également former ensemble un chemin d’attaque particulièrement dangereux.

Le pentest cherche précisément à identifier ces combinaisons. Une organisation peut donc disposer d’un CSPM performant tout en bénéficiant d’un pentest cloud. Les deux approches ne remplissent pas le même objectif : le CSPM aide à surveiller la posture et les écarts de configuration dans la durée, alors que le pentest cherche à démontrer les scénarios réellement exploitables à un instant donné.

Pourquoi les identités occupent-elles une place centrale dans la sécurité cloud ?

Le cloud repose massivement sur des identités. Une identité peut représenter un utilisateur humain, une application, une machine virtuelle, une fonction serverless, un pod Kubernetes, un pipeline de déploiement ou un service cloud. Cette identité reçoit ensuite des permissions lui permettant d’effectuer certaines opérations.

Dans AWS, on rencontre notamment des utilisateurs IAM, des rôles et des sessions temporaires délivrées par AWS Security Token Service. Dans Azure, il faut distinguer les utilisateurs Microsoft Entra, les groupes, les service principals, les managed identities et les rôles Azure RBAC. Dans GCP, les utilisateurs, groupes, service accounts et principals fédérés constituent autant de contextes de sécurité différents.

Le pentester doit systématiquement déterminer quelle identité est utilisée par la ressource compromise et quelles permissions cette identité possède. Mais il doit également aller plus loin. La question la plus intéressante n’est parfois pas ce que l’identité peut faire directement, mais quelles autres identités elle peut contrôler, utiliser ou faire agir indirectement.

Cette logique constitue le cœur de nombreuses élévations de privilèges cloud. Une identité faiblement privilégiée peut rester incapable d’effectuer une action sensible tout en contrôlant une ressource qui, elle, s’exécute avec davantage de droits. Le changement de contexte de sécurité se produit alors au niveau du workload plutôt qu’au niveau du compte initial.

Control plane et data plane : comprendre les deux dimensions d’une compromission cloud

Les architectures cloud distinguent généralement les opérations d’administration des ressources et l’utilisation effective de ces ressources. Le control plane correspond principalement aux APIs permettant de créer, modifier ou supprimer l’infrastructure. Créer une machine virtuelle, modifier une policy IAM, déployer une fonction ou changer une configuration réseau constituent des opérations de control plane.

Le data plane concerne plutôt les opérations réalisées sur les données ou à l’intérieur des services. Lire un objet dans un bucket, interroger une base de données ou récupérer le contenu d’un secret relèvent davantage de cette dimension.

Cette distinction est importante lors d’un pentest. Une identité peut ne pas être autorisée à lire directement un secret, mais disposer du droit de modifier l’application qui, elle, est autorisée à le lire. Dans ce cas, un droit de control plane fournit indirectement un accès à une donnée protégée par le data plane.

L’auditeur doit donc éviter d’évaluer les permissions selon leur nom uniquement. Un droit permettant de modifier une ressource peut être aussi sensible qu’un droit de lecture directe si la ressource modifiée s’exécute avec une identité privilégiée.

Quels sont les différents types de pentest cloud ?

Le niveau d’information fourni au pentester modifie considérablement la couverture de l’audit. Comme pour d’autres tests d’intrusion, on distingue généralement les approches black box, grey box et white box. Ces approches ne s’opposent pas : elles répondent à des objectifs différents et peuvent parfois être combinées au cours d’une même mission.

Pentest cloud en boite noire

Dans un pentest black box, l’auditeur dispose de très peu d’informations. Il peut par exemple recevoir uniquement les noms de domaine appartenant à l’organisation et partir de ces éléments pour cartographier sa surface d’attaque publique.

Cette approche permet notamment d’identifier les applications, APIs, adresses IP publiques, buckets, endpoints serverless, registries ou interfaces administratives accessibles depuis Internet. Elle reproduit relativement bien la situation d’un attaquant externe n’ayant pas encore compromis d’identité interne.

Sa principale limite concerne l’analyse IAM. Sans accès authentifié, une grande partie des relations entre utilisateurs, rôles, workloads et ressources reste difficilement observable. Un pentest black box est donc particulièrement utile pour évaluer l’exposition externe, mais il ne permet pas toujours d’explorer les chemins de privilèges internes les plus complexes.

Pentest cloud en boite grise

Dans une approche grey box, une ou plusieurs identités faiblement privilégiées sont fournies au pentester. Il peut s’agir d’un utilisateur AWS, d’un compte Microsoft Entra, d’un principal GCP ou d’un accès développeur à un environnement donné.

L’audit cherche alors à déterminer ce qu’un attaquant ayant compromis cette identité pourrait accomplir. Cette approche est particulièrement pertinente pour analyser les permissions IAM, les relations de confiance, les possibilités de mouvement latéral et les chemins d’élévation de privilèges.

Elle permet également de tester la segmentation entre environnements. Un compte de développement ne devrait par exemple pas disposer de droits implicites sur la production simplement parce qu’un rôle a été attribué à un niveau trop large ou qu’une relation cross-account, cross-subscription ou cross-project est insuffisamment limitée.

Pentest cloud en boite blanche

Dans un pentest white box, l’auditeur dispose d’une visibilité beaucoup plus importante. L’organisation peut lui fournir l’architecture, les fichiers Terraform, les manifestes Kubernetes, la configuration des pipelines, les policies IAM et un accès de lecture aux différentes ressources cloud.

Cette approche facilite l’identification des chemins d’attaque complexes. Une permission dangereuse peut être accordée indirectement par un groupe, héritée depuis un niveau supérieur de l’organisation ou dépendre d’une relation entre plusieurs services. La visibilité offerte par le white box permet d’identifier plus facilement ces scénarios sans supprimer la nécessité de tester leur exploitabilité.

Le white box est également adapté aux environnements très vastes dans lesquels une simple énumération opportuniste laisserait de nombreuses zones non couvertes. Il permet d’orienter les investigations vers les composants réellement critiques et de distinguer plus facilement une mauvaise configuration théorique d’un chemin d’attaque viable.

Définir le périmètre et les règles d’engagement d’un pentest cloud

Le cadrage d’un pentest cloud doit être particulièrement rigoureux. Le client possède ou contrôle ses workloads et ses configurations, mais utilise également une infrastructure mutualisée opérée par son fournisseur cloud. L’autorisation de tester les ressources du client ne constitue donc jamais une autorisation d’attaquer l’infrastructure du fournisseur ou les ressources appartenant à d’autres clients.

AWS autorise actuellement ses clients à tester un ensemble défini de services sans approbation préalable, sous réserve du respect de sa politique de sécurité. AWS précise également que les clients ne sont pas autorisés à réaliser des évaluations de sécurité de l’infrastructure AWS ou des services AWS eux-mêmes. Certaines activités, notamment celles impliquant du Command and Control, peuvent nécessiter une procédure spécifique ou une autorisation préalable selon la politique en vigueur.

Microsoft indique qu’une approbation préalable n’est pas nécessaire pour réaliser un test d’intrusion sur les ressources Azure possédées par le client ou pour lesquelles une autorisation explicite a été obtenue. Les tiers réalisant les tests doivent disposer d’une autorisation écrite du propriétaire des ressources et l’activité doit respecter les Microsoft Cloud Unified Penetration Testing Rules of Engagement.

Google Cloud indique qu’il n’est pas nécessaire de contacter Google avant de réaliser un pentest sur ses propres projets, à condition de respecter l’Acceptable Use Policy, les conditions de service et de veiller à ce que les tests n’affectent que les projets autorisés et non les applications d’autres clients. Certains services particuliers peuvent toutefois avoir des règles supplémentaires ; ces exceptions doivent être vérifiées lors du cadrage.

Ces politiques peuvent évoluer. Elles doivent donc être vérifiées au moment de chaque mission et intégrées aux règles d’engagement.

Le cadrage doit également identifier précisément les comptes, subscriptions, projects, organisations, régions et environnements concernés. Les actions présentant un risque particulier doivent être discutées avant le démarrage : création de ressources, modification temporaire d’une policy, accès à des données réelles, tests de persistance, manipulation de pipelines ou validation de certains scénarios Kubernetes.

Enfin, il est important de définir les données qui peuvent être consultées et les preuves acceptables. Un pentest cloud n’a pas besoin d’exfiltrer de grandes quantités de données pour démontrer un risque. Un objet de test, un secret spécifiquement préparé ou une preuve de capacité peut suffire à établir l’impact sans augmenter inutilement le risque opérationnel.

Quelle est la méthodologie d’un pentest cloud ?

Un pentest cloud efficace suit généralement une progression structurée. L’objectif n’est pas d’exécuter successivement une collection d’outils, mais de comprendre progressivement l’architecture et les relations de confiance afin d’identifier les chemins d’attaque présentant un impact réel.

Reconnaissance et cartographie de la surface d’attaque

La reconnaissance permet d’identifier les ressources susceptibles d’être atteintes depuis le niveau d’accès initial. Dans un scénario externe, l’auditeur recherche notamment les domaines, sous-domaines, applications, APIs, services cloud publiquement accessibles et endpoints exposés.

Dans un pentest authentifié, la cartographie s’étend aux comptes, subscriptions, projects, réseaux, workloads, identités et services auxquels le principal initial dispose d’une certaine visibilité. Cette étape permet également de comprendre l’organisation générale de l’environnement.

Une grande infrastructure peut par exemple utiliser plusieurs comptes AWS, plusieurs subscriptions Azure ou plusieurs projets GCP pour séparer les environnements et les responsabilités. Cette segmentation apparente doit ensuite être comparée aux relations de confiance réelles : rôles cross-account, groupes Entra, scopes Azure RBAC, permissions héritées GCP ou identités de déploiement partagées.

Énumération des identités et des permissions

Une fois le contexte identifié, l’auditeur analyse les permissions dont dispose son identité. Il ne suffit pas de relever le nom du rôle ou les rôles attribués. Il faut déterminer les autorisations réellement effectives, leur scope, les conditions associées et les éventuels mécanismes limitant leur application.

L’analyse s’intéresse ensuite aux permissions qui permettent de contrôler des ressources utilisant d’autres identités. Une identité incapable d’accéder directement à un secret peut par exemple être capable de modifier une fonction serverless dont le rôle d’exécution dispose de cet accès. Dans ce cas, la permission de modification du workload devient plus importante que l’absence d’accès direct au secret.

Cette étape doit aussi prendre en compte les mécanismes de réduction ou de délégation des permissions. Sur AWS, les permissions boundaries, les resource policies et les Service Control Policies peuvent modifier le résultat final. Sur Azure, le scope du rôle et la séparation entre Microsoft Entra et Azure RBAC sont essentiels. Sur GCP, les bindings hérités depuis l’organisation ou un folder peuvent donner une portée beaucoup plus large que celle visible au niveau d’un seul projet.

Analyse des mauvaises configurations

L’auditeur recherche ensuite les erreurs susceptibles d’ouvrir ou d’amplifier un chemin d’attaque. Les permissions excessives constituent évidemment un axe majeur, mais elles ne sont pas les seules.

Un stockage public, un service de management accessible depuis Internet, un secret présent dans une variable d’environnement, une relation OIDC trop large, une pipeline insuffisamment protégée ou un cluster Kubernetes mal cloisonné peuvent fournir les éléments nécessaires à une progression.

Les outils automatisés sont utiles pour accélérer cette phase, mais leurs résultats doivent être interprétés dans le contexte global de l’environnement. Un outil peut détecter iam:PassRole sans savoir si l’utilisateur contrôle effectivement un service capable d’utiliser le rôle. Il peut signaler un service account puissant sans identifier qu’un autre principal est autorisé à l’attacher à un workload. La validation manuelle reste donc essentielle.

Construction des chemins d’attaque

Cette phase constitue l’une des principales spécificités du pentest cloud. Le pentester cherche à comprendre comment plusieurs permissions ou faiblesses peuvent être combinées.

Prenons un utilisateur développeur qui ne possède aucun accès au gestionnaire de secrets. Cet utilisateur est cependant autorisé à modifier une fonction serverless utilisée en production. La fonction utilise une identité disposant, elle, d’un accès à un secret sensible.

Le développeur contrôle donc indirectement une ressource exécutée avec davantage de privilèges que son propre compte. S’il peut faire exécuter du code sous cette identité, l’absence d’accès direct au gestionnaire de secrets ne constitue plus une véritable frontière de sécurité. La vulnérabilité vient de la relation entre le droit de modifier la fonction et les privilèges de l’identité utilisée par cette fonction.

L’auditeur reproduit ce raisonnement pour chaque nouvelle capacité obtenue. Un secret peut contenir un second credential. Ce credential peut donner accès à une autre subscription, un autre compte ou un autre projet. Le nouveau principal peut à son tour contrôler un workload plus privilégié. Le chemin se construit progressivement jusqu’à ce qu’il ne soit plus possible de progresser ou que l’impact maximal puisse être démontré sans action supplémentaire.

Exploitation contrôlée

Lorsque l’auditeur identifie un chemin d’attaque plausible, il cherche à en valider l’exploitabilité de manière contrôlée. L’objectif n’est pas de provoquer un impact inutile.

Si l’accès à une donnée sensible doit être démontré, un fichier de test ou un secret spécifiquement préparé pour l’audit peut suffire. De même, il n’est pas toujours nécessaire d’attribuer réellement un rôle administrateur ou de créer un mécanisme persistant si les permissions et préconditions nécessaires sont démontrées sans ambiguïté.

Le niveau d’exploitation doit rester proportionné au besoin de preuve et aux règles d’engagement. Cette discipline est particulièrement importante dans le cloud, où une commande mal ciblée peut affecter rapidement un grand nombre de ressources ou déclencher des automatisations.

Post-exploitation et mouvement latéral

Une nouvelle identité obtenue pendant le pentest devient un nouveau point de départ. L’auditeur analyse alors ses permissions et les ressources qu’elle peut atteindre.

Cette logique peut être répétée plusieurs fois. Une application compromise peut fournir une identité de workload. Cette identité peut donner accès à un secret contenant un second credential. Celui-ci peut permettre d’accéder à un autre projet ou compte, dans lequel de nouvelles permissions deviennent disponibles.

Le mouvement latéral cloud repose donc souvent moins sur la compromission de machines successives que sur la succession de contextes d’identité. Le pentester doit documenter précisément ce qui change à chaque étape : principal courant, permissions, ressources contrôlables et nouveaux chemins accessibles.

Évaluation de la persistance

Une compromission cloud peut également permettre à un attaquant de maintenir son accès. La persistance ne prend pas nécessairement la forme d’un malware installé sur un serveur.

La création d’une access key supplémentaire, l’ajout d’un credential à une application, la modification d’une trust policy, la création d’un service account ou l’ajout d’une federated identity credential peuvent remplir le même objectif.

Lors d’un pentest, ces capacités doivent être analysées avec prudence. Dans de nombreux cas, démontrer qu’une permission permettrait d’établir la persistance est suffisant. L’auditeur peut documenter la primitive sans créer réellement un mécanisme durable dans l’environnement.

Reporting et contre-audit

Le rapport doit restituer les vulnérabilités mais aussi leur combinaison. Présenter séparément une permission excessive, une fonction trop privilégiée et un secret accessible peut masquer le risque réel.

Lorsque ces éléments participent au même scénario, le rapport doit expliquer comment le niveau d’accès initial permet de contrôler la fonction, comment cette fonction fournit un nouveau contexte d’identité et pourquoi ce contexte permet finalement d’accéder au secret.

Cette approche facilite également la remédiation. Supprimer un seul maillon important peut parfois rendre toute la chaîne inexploitable. Le contre-audit doit vérifier non seulement que le constat initial a disparu, mais aussi que le chemin de compromission n’a pas été déplacé vers une autre relation de confiance.

Quelles vulnérabilités sont recherchées lors d’un pentest cloud ?

La surface d’attaque dépend fortement de l’architecture, mais plusieurs familles de faiblesses apparaissent régulièrement. Elles ne doivent pas être considérées comme des catégories indépendantes : l’intérêt du pentest est précisément de comprendre comment elles se combinent.

Mauvaises configurations IAM et élévation de privilèges

Les mauvaises configurations IAM constituent souvent les vulnérabilités les plus importantes d’un environnement cloud. Elles peuvent résulter de rôles trop larges, de permissions accordées au mauvais niveau, de relations de confiance insuffisamment restrictives ou d’identités techniques disposant de droits disproportionnés.

L’erreur classique consiste à rechercher uniquement des comptes disposant déjà d’un rôle administrateur. De nombreuses élévations de privilèges reposent au contraire sur des permissions qui ne sont pas explicitement administratives.

La possibilité de créer un workload, de lui attribuer une identité privilégiée ou de modifier le code d’une fonction exécutée avec davantage de droits peut aboutir au même résultat qu’une permission IAM directement administrative. Le pentest doit donc étudier la combinaison des droits et non leur intitulé isolé.

Secrets et credentials exposés

Les secrets peuvent être présents dans de nombreux endroits : repositories, variables d’environnement, fichiers de configuration, logs de pipelines, images de conteneurs, artifacts de build, fichiers Terraform ou backups.

Lorsqu’un secret est découvert, l’auditeur doit déterminer à quelle identité ou quel service il correspond. Une clé API limitée à une intégration secondaire n’a évidemment pas le même impact qu’un credential cloud disposant d’un accès à plusieurs environnements.

Le pentest ne s’arrête donc jamais à la découverte du secret. Il faut déterminer ce qu’il permet de faire, sa durée de validité, sa portée, les ressources accessibles et les éventuelles possibilités de pivot vers d’autres systèmes.

Stockages cloud mal configurés

Amazon S3, Azure Blob Storage et Google Cloud Storage offrent de nombreux mécanismes permettant de contrôler et déléguer les accès. Une ressource de stockage peut être exposée publiquement, partagée au moyen d’une URL signée ou accessible à un ensemble trop large d’identités authentifiées.

La sensibilité dépend également des opérations autorisées. Un accès en lecture peut provoquer une fuite de données. Un accès en écriture devient particulièrement critique lorsque les objets sont consommés par une application, téléchargés par des utilisateurs ou utilisés par un processus de déploiement.

La présence de fichiers Terraform State, de sauvegardes, de code source ou de credentials peut également transformer une simple exposition de stockage en point de départ d’une compromission plus large.

Exploitation des metadata services

Les metadata services permettent aux workloads d’obtenir différentes informations sur leur environnement. Ils interviennent également dans plusieurs mécanismes permettant de délivrer des credentials temporaires.

Les attaques basées sur une SSRF sont particulièrement connues sur AWS, mais des problématiques similaires doivent être étudiées sur Azure et GCP. Il faut cependant éviter le raccourci consistant à considérer que toute SSRF dans une application cloud permet automatiquement de récupérer des credentials.

Les capacités exactes de la SSRF, les protections du metadata service, le type de workload et la configuration réseau déterminent la faisabilité du scénario. La méthode HTTP, le contrôle des headers, les redirections, la résolution DNS et la possibilité d’atteindre certaines adresses internes sont autant d’éléments à analyser.

Vulnérabilités des APIs et services cloud-native

Les environnements cloud reposent largement sur des APIs. Les vulnérabilités applicatives traditionnelles telles que les contrôles d’accès défaillants, les injections, les erreurs d’authentification ou les SSRF restent donc pertinentes.

Leur impact peut cependant être amplifié par l’identité du workload hébergeant l’API. Une exécution de code dans une application disposant d’une identité quasiment dépourvue de permissions n’aura pas le même impact cloud qu’une exécution de code dans une fonction capable de lire des secrets ou de modifier d’autres ressources.

Un pentest cloud doit donc prolonger l’analyse applicative en évaluant les permissions du contexte d’exécution.

Vulnérabilités serverless

Les architectures serverless réduisent une partie de la surface d’administration traditionnelle, mais elles utilisent elles aussi des identités. AWS Lambda, Azure Functions et les workloads serverless GCP exécutent généralement le code dans un contexte auquel certaines permissions cloud sont attribuées.

Le pentester doit donc systématiquement analyser l’identité d’exécution d’une fonction compromise. Une vulnérabilité applicative ne doit jamais être évaluée indépendamment de ces permissions.

Des secrets sont également encore stockés directement dans des variables d’environnement. Cela peut être acceptable pour certaines valeurs de configuration, mais les secrets durables devraient être gérés par des services dédiés lorsque cela est possible. La présence d’un gestionnaire de secrets ne supprime cependant pas le risque si la fonction compromise est légitimement autorisée à lire son contenu.

Mauvaises configurations Kubernetes

Kubernetes ajoute son propre modèle d’identité et d’autorisation à celui du fournisseur cloud. Un pod peut être correctement isolé au niveau Kubernetes mais disposer d’une identité cloud trop puissante.

L’inverse est également possible : l’identité cloud peut être bien limitée alors que Kubernetes RBAC permet au ServiceAccount de créer des workloads privilégiés, de lire des Secrets inutiles ou d’administrer des bindings.

Un pentest EKS, AKS ou GKE doit donc analyser les deux dimensions simultanément et comprendre les relations entre ServiceAccounts Kubernetes, rôles RBAC et identités cloud.

Compromission des pipelines CI/CD

Les pipelines disposent souvent de permissions particulièrement sensibles puisqu’ils sont précisément destinés à modifier l’infrastructure ou les applications.

Un compte développeur incapable de modifier directement une ressource cloud peut néanmoins être autorisé à modifier le code ou la configuration d’un pipeline qui dispose de ces permissions. La sécurité du processus de déploiement devient alors une partie intégrante de la sécurité cloud.

L’auditeur doit comprendre qui peut modifier un workflow, qui peut l’exécuter, quelles branches ou environnements sont concernés, quelle identité cloud est obtenue et quels contrôles d’approbation encadrent le déploiement.

Infrastructure as Code et Terraform State

L’Infrastructure as Code offre de nombreux bénéfices, mais les fichiers générés et les workflows associés doivent être protégés. Terraform State contient une représentation détaillée de l’infrastructure et peut parfois contenir des données sensibles.

Une exposition du state peut donc révéler des ressources internes, des endpoints, des paramètres de configuration et parfois des credentials utiles à la poursuite de l’attaque. Les fichiers de plan peuvent également contenir des informations qui ne devraient pas être publiquement accessibles.

Le risque ne se limite toutefois pas à l’exposition de fichiers. Une personne capable de modifier le code IaC peut parfois demander à une pipeline privilégiée d’appliquer une configuration qu’elle ne serait pas autorisée à déployer directement depuis son propre compte.

Segmentation réseau insuffisante

IAM occupe une place essentielle dans le cloud, mais le réseau reste une couche de sécurité importante. Une application compromise peut donner accès à des services qui ne sont pas accessibles depuis Internet mais le sont depuis le VPC, VNet ou réseau interne concerné.

Le pentest doit donc identifier les nouvelles destinations accessibles depuis chaque workload compromis. Une segmentation réseau efficace peut empêcher une vulnérabilité applicative de devenir un point de pivot vers l’ensemble du système d’information.

Les private endpoints, security groups, Network Security Groups, firewall rules, VPC Service Controls et mécanismes équivalents doivent être étudiés en fonction de l’architecture réelle plutôt que comme une simple checklist de conformité.

Comment analyser les chemins d’attaque liés aux identités ?

L’analyse IAM doit être menée comme l’étude d’un ensemble de relations de confiance plutôt que comme la lecture isolée de chaque rôle. C’est cette logique qui permet de transformer une revue de configuration en véritable pentest.

Distinguer permission directe et primitive d’exploitation

Une permission directe permet immédiatement d’effectuer une action. Si une identité est autorisée à lire un secret déterminé, la conséquence est simple à comprendre.

Une primitive d’exploitation fonctionne différemment. Elle fournit une capacité qui peut devenir dangereuse lorsqu’elle est associée à une autre permission.

iam:PassRole sur AWS en constitue un exemple classique. Cette action n’accorde pas directement à l’utilisateur les permissions du rôle. Elle permet à un service AWS d’utiliser ce rôle. Le risque dépend donc de la capacité de l’utilisateur à contrôler un service qui pourra ensuite utiliser cette identité.

Le même raisonnement s’applique dans GCP avec iam.serviceAccounts.actAs. Cette permission permet notamment d’attacher un service account à certaines ressources ; elle ne permet pas à elle seule de générer directement un access token pour ce service account. La dangerosité apparaît lorsque le principal peut simultanément créer ou modifier un workload utilisant cette identité.

Analyser les changements de contexte d’identité

Pour chaque identité obtenue, l’auditeur doit comprendre non seulement ses permissions mais aussi les ressources dont elle peut contrôler le comportement.

Supposons qu’un développeur ne puisse pas lire un secret. Il peut cependant mettre à jour le code d’une fonction qui, elle, dispose de cette autorisation. Le développeur peut alors influencer l’exécution d’une identité plus privilégiée.

La frontière de sécurité ne se situe donc pas uniquement au niveau du rôle initial. Elle se situe aussi entre les personnes capables de modifier un workload et l’identité attribuée à ce workload.

Cette observation est valable dans les trois principaux clouds. Les noms des services changent, mais le principe reste similaire : une identité contrôlant un workload peut parfois faire agir l’identité du workload à sa place.

Comprendre les relations de confiance

Les mécanismes de fédération et de délégation doivent être analysés avec le même niveau d’attention. Les trust policies AWS, les federated identity credentials Microsoft Entra et les workload identity pools GCP permettent à des identités issues de contextes différents de se faire reconnaître par le fournisseur cloud.

Une relation de confiance trop large peut donc produire une élévation de privilèges sans qu’aucun secret ne soit compromis. Le pentest doit vérifier non seulement les permissions de l’identité obtenue mais aussi les conditions nécessaires pour l’obtenir.

Dans un environnement CI/CD, la question devient par exemple : quel repository, quelle branche, quel environnement ou quel workflow est autorisé à obtenir l’identité cloud ? Une restriction insuffisante peut permettre à un workflow non prévu d’obtenir un rôle de production parfaitement valide.

Pentest AWS

AWS repose fortement sur IAM, les rôles et les credentials temporaires délivrés notamment par AWS Security Token Service. Une grande partie du pentest consiste donc à comprendre les relations entre principals, policies, rôles et services capables d’exécuter du code.

Comprendre le modèle d’identité AWS

Les permissions effectives d’un principal AWS peuvent dépendre de plusieurs mécanismes. Les identity-based policies constituent seulement une partie du modèle. Les resource policies, trust policies, permissions boundaries, session policies et Service Control Policies éventuellement appliquées par AWS Organizations peuvent modifier les capacités finales du principal.

Une policy contenant une action dangereuse ne signifie donc pas automatiquement que l’action sera réellement autorisée. Inversement, une resource policy peut fournir un accès qui n’est pas visible en examinant uniquement les policies de l’utilisateur.

Le pentest doit essayer de reconstruire le contexte d’autorisation complet plutôt que de se limiter à la lecture d’une seule policy.

Énumérer le contexte AWS initial

Lorsqu’un jeu de credentials AWS est obtenu dans le cadre autorisé du pentest, une première étape consiste généralement à déterminer quelle identité est utilisée.

aws sts get-caller-identity

Cette commande permet d’identifier notamment le compte AWS et le principal courant. La suite de l’analyse vise à comprendre les services visibles, les rôles pouvant être obtenus et les permissions dont dispose réellement l’identité.

L’auditeur ne cherche pas seulement les actions explicitement administratives. Il recherche également les services qu’il peut créer ou modifier et les rôles utilisés par ces services. Cette démarche permet de détecter les chemins indirects qui sont souvent plus intéressants que les permissions d’administration évidentes.

Élévation de privilèges avec iam:PassRole

Prenons une policy volontairement simplifiée :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "arn:aws:iam::123456789012:role/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "lambda:CreateFunction",
        "lambda:InvokeFunction"
      ],
      "Resource": "*"
    }
  ]
}

La première permission autorise l’identité à transmettre un rôle à un service AWS. La seconde lui permet de créer puis d’exécuter une fonction Lambda.

Supposons maintenant qu’un rôle très privilégié soit utilisable par Lambda. L’utilisateur peut créer une fonction utilisant ce rôle puis exécuter du code dans le contexte de l’identité associée à la fonction.

Il ne reçoit jamais directement le rôle privilégié. L’élévation se produit parce qu’il contrôle un workload qui, lui, est autorisé à utiliser cette identité. La faiblesse provient donc de la combinaison entre la portée trop large de iam:PassRole et la capacité de créer ou contrôler un service utilisant le rôle.

Une configuration plus restrictive doit limiter précisément les rôles pouvant être transmis et, lorsque cela est pertinent, le service auquel le rôle peut être passé :

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "arn:aws:iam::123456789012:role/lambda-development-role",
  "Condition": {
    "StringEquals": {
      "iam:PassedToService": "lambda.amazonaws.com"
    }
  }
}

Il faut ensuite s’assurer que lambda-development-role applique lui-même un niveau de permissions adapté. La correction ne consiste donc pas simplement à supprimer iam:PassRole, mais à empêcher qu’un utilisateur puisse sélectionner arbitrairement une identité beaucoup plus privilégiée pour un workload qu’il contrôle.

Abus de sts:AssumeRole

sts:AssumeRole permet d’obtenir des credentials temporaires correspondant à un rôle. Le scénario dépend à la fois des permissions du principal et de la trust policy du rôle cible.

Dans une architecture multi-comptes, cette relation permet par exemple à un principal d’un compte de développement d’utiliser un rôle situé dans un compte de production. Ce mécanisme est parfaitement légitime lorsqu’il est correctement configuré.

Le pentester cherche cependant à déterminer si les principals autorisés sont trop nombreux, si les conditions sont insuffisamment restrictives ou si un rôle faiblement protégé donne accès à des ressources beaucoup plus sensibles.

Une trust policy faisant confiance à la racine d’un compte entier peut être acceptable dans certains modèles, mais elle doit être comprise avec les permissions présentes dans le compte de confiance. Le pentest doit donc analyser les deux côtés de la relation plutôt que de s’arrêter à la policy du rôle cible.

Modification des permissions IAM

Certaines actions offrent un chemin plus direct vers des privilèges supplémentaires. Des permissions telles que iam:AttachUserPolicy, iam:AttachRolePolicy, iam:PutUserPolicy, iam:PutRolePolicy, iam:CreateAccessKey ou certaines opérations permettant de modifier des trust policies doivent faire l’objet d’une attention particulière.

Leur présence ne suffit cependant pas à conclure à une compromission. Le scope de la ressource doit toujours être étudié. Une permission limitée à un seul utilisateur technique n’a pas le même impact qu’une action applicable à l’ensemble des identités du compte.

Les permissions boundaries doivent également être prises en compte. Elles peuvent empêcher un rôle créé ou modifié d’obtenir des permissions dépassant une limite définie, même lorsque l’utilisateur possède par ailleurs certaines actions IAM. Le pentester doit donc raisonner en termes de permissions effectives.

Détournement de fonctions Lambda

Une identité n’a pas nécessairement besoin de créer une nouvelle fonction. La capacité à modifier le code d’une Lambda existante peut suffire lorsqu’elle utilise un rôle plus privilégié.

Supposons qu’une fonction puisse appeler secretsmanager:GetSecretValue sur un secret de production. Un développeur n’a aucun accès direct à Secrets Manager mais peut mettre à jour le code de cette fonction.

Il existe alors une frontière de sécurité fragile : le développeur peut influencer un workload possédant un droit qu’il ne possède pas lui-même. Dans un pentest autorisé, il peut être suffisant de démontrer la capacité de modification et les permissions du rôle d’exécution sans récupérer réellement le secret de production.

Une séparation correcte doit donc tenir compte à la fois des permissions du développeur et du rôle d’exécution de la fonction. Plus le rôle de la Lambda est privilégié, plus les droits de déploiement sur son code doivent être considérés comme sensibles.

Exploitation d’AWS Secrets Manager et Parameter Store

Les gestionnaires de secrets sont conçus pour éviter la dispersion des credentials dans le code ou les configurations. Ils ne constituent cependant pas une protection contre un workload déjà autorisé à lire leur contenu.

Lorsqu’une identité compromise possède secretsmanager:GetSecretValue ou un accès équivalent à Systems Manager Parameter Store, le pentester doit déterminer quels secrets sont réellement accessibles.

Une credential de base de données peut conduire à l’accès aux données. Une seconde access key AWS peut fournir un nouveau principal à analyser. Un secret appartenant à un service externe peut également permettre de quitter le périmètre purement AWS et d’atteindre un autre environnement.

La remédiation doit donc s’appuyer sur des policies de moindre privilège et, lorsque cela est possible, sur des restrictions supplémentaires liées au contexte d’utilisation du secret.

Exposition et mauvaises configurations Amazon S3

S3 dispose de plusieurs mécanismes de contrôle d’accès et il est important d’évaluer les permissions effectives plutôt que d’interpréter uniquement une bucket policy.

Prenons une configuration simple autorisant la lecture publique :

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::example-bucket/*"
}

Si l’accès est réellement effectif, l’impact dépendra du contenu du bucket. AWS S3 Block Public Access peut cependant imposer des protections supplémentaires au niveau du bucket ou du compte. L’analyse doit donc vérifier le comportement réel et pas uniquement la présence d’une policy permissive.

Les presigned URLs doivent également être prises en compte. Elles permettent de donner temporairement accès à un objet sans fournir directement de credentials AWS à l’utilisateur final. Une URL trop longue durée ou permettant une opération d’écriture sensible peut devenir un vecteur d’attaque si elle est exposée.

Lorsqu’un bucket contient des fichiers de configuration, des backups ou des states Terraform, le pentester doit analyser leur contenu et déterminer s’ils révèlent des secrets, des endpoints ou de nouvelles relations de confiance.

Exploitation de l’Instance Metadata Service

L’Instance Metadata Service (IMDS) permet aux workloads EC2 d’obtenir des informations relatives à leur instance et peut leur fournir les credentials temporaires associés à leur rôle.

Le scénario classique consiste à exploiter une SSRF dans une application exécutée sur EC2 afin de provoquer une requête vers le metadata service. Il est toutefois essentiel de distinguer IMDSv1 et IMDSv2.

IMDSv2 utilise un mécanisme de session. Le client doit commencer par obtenir un token au moyen d’une requête HTTP PUT, puis présenter ce token lors des requêtes suivantes.

TOKEN=$(curl -X PUT \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" \
  http://169.254.169.254/latest/api/token)

Le token est ensuite utilisé pour accéder aux métadonnées. Lorsqu’IMDSv2 est obligatoire, une SSRF limitée à de simples requêtes GET et ne permettant pas de définir les headers ne suffit généralement pas à reproduire le scénario classique de récupération de credentials.

Une conclusion sérieuse doit donc analyser les capacités précises de la SSRF : méthodes autorisées, headers contrôlables, comportement face aux redirections et contexte réseau du workload. Il faut également prendre en compte la hop limit et l’architecture des conteneurs lorsque la ressource se trouve derrière plusieurs sauts réseau.

Pentest Amazon EKS

Amazon EKS combine Kubernetes avec le modèle IAM AWS. Un pod peut disposer de permissions Kubernetes au travers de son ServiceAccount et d’une identité AWS lui permettant d’accéder à d’autres ressources.

Amazon EKS fournit actuellement deux mécanismes privilégiés pour attribuer des credentials temporaires AWS aux workloads : IAM Roles for Service Accounts (IRSA) et EKS Pod Identities. AWS recommande EKS Pod Identities pour les nouveaux workloads lorsque l’environnement et les SDK utilisés sont compatibles, tandis qu’IRSA reste pleinement pris en charge et pertinent pour plusieurs scénarios existants.

Le pentester doit comprendre quel mécanisme est utilisé et déterminer les permissions associées au workload compromis. Il doit également analyser les permissions Kubernetes du ServiceAccount et les confronter aux permissions IAM disponibles côté AWS.

IRSA, EKS Pod Identity et identité des nodes

IRSA s’appuie sur les tokens de ServiceAccounts Kubernetes et une relation OIDC afin de permettre à un pod d’obtenir des credentials temporaires associés à un rôle IAM.

EKS Pod Identity associe également un rôle IAM à un Kubernetes ServiceAccount, mais la gestion de l’association passe par EKS et un Pod Identity Agent présent sur les nodes. Le mécanisme permet d’obtenir des credentials temporaires sans devoir configurer un fournisseur OIDC IAM distinct pour chaque cluster.

Pour le pentest, il faut déterminer quelle identité est réellement utilisée par le workload et si cette identité respecte le principe de moindre privilège. La possibilité de gérer des associations Pod Identity doit également être considérée comme sensible puisqu’elle influence les rôles accessibles aux workloads.

L’accès au rôle du node doit lui aussi être analysé. Si un pod peut atteindre l’Instance Metadata Service du node et que l’identité de ce node est plus privilégiée que celle du workload, l’isolation prévue peut perdre une partie de son efficacité. La recommandation consiste à fournir des identités dédiées aux workloads et à restreindre l’accès à IMDS lorsque le contexte le permet.

CI/CD et fédération OIDC dans AWS

Les pipelines modernes évitent de plus en plus de stocker des access keys permanentes. Ils utilisent plutôt une fédération OIDC permettant d’obtenir temporairement un rôle AWS.

Cette architecture est plus robuste, mais la sécurité dépend alors de la trust policy. Le pentester doit vérifier quelles identités du fournisseur CI/CD peuvent obtenir le rôle.

Une relation faisant confiance à un ensemble de repositories, de branches ou d’environnements beaucoup plus large que nécessaire peut permettre à un workflow non prévu d’obtenir une identité de production.

La question n’est donc plus seulement de savoir si un secret peut être volé. Il faut comprendre qui est autorisé à demander les credentials temporaires et si les claims utilisés dans la relation de confiance sont suffisamment précis.

Pentest Microsoft Azure

Le pentest Azure nécessite de distinguer plusieurs modèles d’autorisation. L’utilisation historique du terme Azure Active Directory doit également être actualisée : le service est désormais nommé Microsoft Entra ID.

Distinguer Microsoft Entra ID, Microsoft Graph et Azure RBAC

Microsoft Entra ID gère les identités du tenant. Microsoft Graph permet d’effectuer de nombreuses opérations sur les objets Microsoft Entra et Microsoft 365. Azure RBAC contrôle l’accès aux ressources Azure au travers d’Azure Resource Manager.

Ces domaines sont étroitement liés mais ne doivent pas être confondus. Un utilisateur peut disposer d’un rôle important dans Microsoft Entra sans pour autant être Owner d’une subscription Azure. Inversement, un Owner Azure n’est pas automatiquement administrateur global du tenant Microsoft Entra.

Cette distinction est indispensable pour comprendre les chemins d’attaque. Une permission Microsoft Graph permettant de modifier une application peut avoir un impact différent d’une permission Azure RBAC permettant de modifier une machine virtuelle. Le pentest doit identifier le plan d’autorisation concerné avant d’évaluer le scénario.

Abus des rôles et attributions Azure RBAC

Une permission particulièrement importante est :

Microsoft.Authorization/roleAssignments/write

Elle permet de créer des attributions de rôles dans le scope concerné. Une identité disposant de cette capacité peut potentiellement attribuer un rôle plus puissant à un principal qu’elle contrôle.

Microsoft indique par exemple que des rôles tels que Role Based Access Control Administrator ou User Access Administrator peuvent attribuer des rôles Azure et s’attribuer, ou attribuer à d’autres, le rôle Owner lorsque le scope le permet.

Cette permission ne doit donc pas être accordée aux rôles chargés uniquement de l’administration opérationnelle de workloads.

À l’inverse, le rôle Contributor dispose de permissions très étendues pour gérer les ressources, mais ne permet pas à lui seul d’attribuer des rôles Azure RBAC. Cette nuance est importante : Contributor n’est pas équivalent à Owner.

Élévation de privilèges via les workloads

L’absence de roleAssignments/write ne signifie pas qu’un Contributor ne peut jamais atteindre une identité plus privilégiée.

Supposons qu’une identité Contributor puisse modifier une machine virtuelle, une Function ou une autre ressource utilisant une managed identity plus privilégiée. Si elle peut exécuter du code dans le contexte de cette ressource, elle peut potentiellement utiliser l’identité associée.

Le niveau d’accès initial ne reflète donc pas nécessairement l’impact maximal. Le pentest doit comparer les permissions de la personne capable d’administrer le workload à celles de l’identité utilisée par ce workload.

Ce raisonnement est particulièrement important dans les architectures où les identités managées disposent d’accès à Key Vault, aux comptes de stockage ou à des APIs de management.

Abus des identités managées

Les managed identities permettent aux ressources Azure d’obtenir des tokens Microsoft Entra sans stocker de client secret permanent. Elles représentent donc une bonne pratique importante.

Le modèle de menace change cependant. Lorsqu’un attaquant compromet un workload utilisant une managed identity, il peut essayer de demander les mêmes tokens que l’application légitime.

Il ne récupère pas un mot de passe appartenant à l’identité. Il utilise le contexte d’exécution compromis pour obtenir un token que la ressource est autorisée à demander. L’impact dépend ensuite des permissions Azure ou Microsoft Graph attribuées à cette identité.

Il faut également distinguer les environnements. Une machine virtuelle s’appuie notamment sur l’Azure Instance Metadata Service, alors qu’App Service expose un endpoint local via IDENTITY_ENDPOINT et un mécanisme de contrôle reposant notamment sur IDENTITY_HEADER. Le guide et le rapport doivent donc préciser le type de workload avant de décrire la manière dont son identité est accessible.

Applications Microsoft Entra et service principals

Les applications Microsoft Entra peuvent disposer de permissions importantes sur Microsoft Graph ou d’autres APIs. L’objet Application décrit l’application, tandis que le service principal représente son identité dans un tenant.

Lorsqu’un attaquant peut ajouter un credential à une application très privilégiée ou prendre le contrôle d’une application dont il est owner, il peut parfois obtenir un nouveau contexte d’identité particulièrement intéressant.

L’auditeur doit donc analyser les owners des applications, les principals capables de gérer leurs credentials, les certificats ou secrets existants et les permissions accordées au service principal.

Une application possédant une permission Microsoft Graph sensible doit être considérée comme une ressource d’identité critique, même si elle n’est associée à aucun utilisateur administrateur traditionnel. Les rôles permettant d’administrer les applications doivent être surveillés pour la même raison.

Azure Key Vault

Azure Key Vault centralise des secrets, certificats et clés cryptographiques. Une managed identity ou un service principal peut être autorisé à accéder à certains secrets.

La compromission d’un workload utilisant cette identité peut donc permettre d’utiliser ses permissions Key Vault. L’auditeur doit analyser précisément les droits effectifs.

Pouvoir consulter un secret déterminé ne correspond pas au même niveau d’impact que pouvoir administrer le coffre ou modifier ses autorisations. Les contrôles réseau, les private endpoints et le modèle d’autorisation utilisé doivent également être pris en compte.

L’objectif reste de limiter chaque identité aux secrets indispensables à son fonctionnement et d’éviter qu’une identité de workload puisse accéder à un ensemble de secrets sans rapport avec l’application concernée.

Azure Storage et Shared Access Signatures

Azure Storage peut être rendu accessible au moyen de plusieurs mécanismes, notamment Microsoft Entra ID, les clés de compte et les Shared Access Signatures (SAS).

Une SAS permet de déléguer un accès limité à certaines ressources. Sa sécurité dépend de sa portée, de sa durée de validité et des opérations autorisées.

Une SAS permettant uniquement de lire un blob pendant quelques minutes n’a pas le même impact qu’une SAS valable plusieurs mois et autorisant la lecture, l’écriture ou la suppression sur un ensemble important de ressources.

Microsoft recommande de privilégier les user delegation SAS lorsque cela est possible, ainsi que Microsoft Entra ID plutôt que Shared Key pour plusieurs scénarios. L’auditeur doit également comprendre qui est capable de générer des SAS, car leur génération peut constituer une capacité sensible même lorsqu’aucun token existant n’a encore été découvert.

Pentest AKS

AKS introduit plusieurs identités qu’il faut distinguer. Le cluster possède ses propres identités lui permettant d’interagir avec Azure. Les workloads peuvent également utiliser Microsoft Entra Workload ID afin d’obtenir une identité adaptée aux besoins de l’application.

Microsoft décrit Workload ID comme le mécanisme couvrant le scénario pod-vers-Azure, c’est-à-dire l’authentification des applications exécutées dans des pods vers des services protégés par Microsoft Entra comme Key Vault ou Microsoft Graph.

Le pentester doit donc examiner séparément Kubernetes RBAC, le ServiceAccount du workload et l’identité Microsoft Entra éventuellement associée.

Microsoft Entra Workload ID

Microsoft Entra Workload ID s’appuie sur la fédération OIDC. Le cluster émet des tokens de ServiceAccount Kubernetes et Microsoft Entra peut vérifier la relation de confiance définie pour permettre au workload d’obtenir une identité adaptée.

Sur AKS Automatic, Microsoft indique que Workload Identity et l’issuer OIDC sont préconfigurés. Sur AKS Standard, le mécanisme doit être activé et configuré.

Pour le pentest, la présence du mécanisme n’est pas une vulnérabilité. La question porte sur la granularité de la relation de confiance et les permissions accordées à l’identité finale.

Un pod compromis ne devrait obtenir que les capacités strictement nécessaires à son fonctionnement. Les identities partagées entre plusieurs workloads et les fédérations trop larges doivent être étudiées avec attention.

Compromission des pipelines Azure DevOps

Azure DevOps représente une autre surface importante. Les pipelines peuvent utiliser des service connections leur permettant de déployer des ressources Azure.

Le pentester doit déterminer quelles pipelines peuvent utiliser ces connexions, qui peut modifier les pipelines et quel niveau de privilège possède l’identité de déploiement.

Un développeur incapable de modifier directement une subscription peut disposer indirectement du même pouvoir s’il peut contrôler un pipeline utilisant une service connection très privilégiée.

Les service connections basées sur Workload Identity Federation réduisent le besoin de stocker des secrets persistants, mais la sécurité dépend toujours des permissions attribuées à l’identité et des pipelines autorisées à utiliser la connexion. Une connexion de production ouverte à toutes les pipelines d’un projet élargit inutilement la surface de confiance.

Pentest Google Cloud Platform (GCP)

GCP repose fortement sur IAM, les service accounts et une hiérarchie de ressources composée notamment de l’organisation, des folders et des projects. La portée d’une permission est donc particulièrement importante.

Comprendre la hiérarchie IAM GCP

Une permission attribuée au niveau d’un projet peut affecter les ressources situées dans ce projet. Une permission attribuée à un folder ou à l’organisation peut être héritée par plusieurs projets.

Un pentest GCP ne doit donc pas examiner chaque projet comme une infrastructure totalement indépendante. Un principal compromis dans un environnement considéré comme secondaire peut posséder des permissions héritées lui permettant d’accéder à d’autres projets.

La première étape consiste à reconstruire autant que possible la hiérarchie et les bindings IAM associés. L’auditeur doit identifier l’origine de chaque permission importante et vérifier si son scope est réellement justifié.

Compromission des service accounts

Les service accounts sont des identités utilisées par les workloads GCP. Une application, une VM, un pipeline ou un service serverless peut fonctionner sous l’identité d’un service account.

Les anciennes architectures utilisent parfois des fichiers de clés JSON. La découverte d’une telle clé permet potentiellement de s’authentifier avec le service account jusqu’à sa révocation.

Google recommande de privilégier des alternatives reposant sur des credentials temporaires lorsque cela est possible. Workload Identity Federation et les mécanismes d’impersonation contrôlée permettent de réduire l’usage de clés persistantes sans supprimer le besoin d’analyser précisément les permissions de l’identité obtenue.

Distinguer Service Account User et Service Account Token Creator

Cette distinction est fondamentale.

Le rôle :

roles/iam.serviceAccountUser

contient notamment la permission :

iam.serviceAccounts.actAs

Cette permission permet à un principal d’attacher un service account à certaines ressources. Elle ne lui permet pas, à elle seule, de créer directement des credentials éphémères pour ce compte ni d’utiliser --impersonate-service-account avec la Google Cloud CLI.

Le rôle :

roles/iam.serviceAccountTokenCreator

accorde des capacités différentes et permet notamment de générer des credentials de courte durée pour le service account.

actAs peut néanmoins permettre une élévation de privilèges. Imaginons qu’un développeur puisse créer une machine virtuelle et dispose de iam.serviceAccounts.actAs sur un service account très privilégié. Il ne peut pas nécessairement générer directement un token au nom de ce compte, mais il peut créer une VM utilisant cette identité. Le code exécuté sur cette machine peut alors disposer des permissions du service account attaché.

L’escalade vient donc de la combinaison entre la capacité de créer le workload et celle de lui attribuer une identité plus privilégiée.

Abus de l’héritage IAM

Des rôles très larges attribués au mauvais niveau représentent un autre risque fréquent. Un rôle accordé au niveau d’un folder peut automatiquement concerner plusieurs projets.

Une identité de développement peut donc disposer involontairement de capacités dans des environnements de production simplement parce qu’elle hérite d’un binding situé plus haut dans la hiérarchie.

Le pentest doit identifier l’origine de chaque permission importante. La correction peut alors nécessiter de déplacer le binding vers un scope plus précis plutôt que de modifier le rôle lui-même.

Les rôles prédéfinis très larges comme roles/editor ou roles/owner doivent être considérés avec attention, mais les rôles personnalisés peuvent également contenir des combinaisons de permissions dangereuses. Là encore, le nom du rôle ne suffit pas à évaluer son impact.

Google Cloud Storage

Google Cloud Storage possède plusieurs mécanismes permettant de contrôler les accès. Uniform bucket-level access permet de désactiver les ACL sur les objets et de centraliser le contrôle d’accès via IAM.

Public Access Prevention permet de renforcer la protection contre l’exposition publique. Il faut cependant distinguer l’exposition publique des mécanismes de partage explicites.

Les signed URLs permettent de fournir temporairement l’accès à un objet et continuent donc à représenter une capability lorsqu’elles sont exposées. Le pentest doit déterminer la portée exacte de chaque mécanisme observé.

Une ressource de stockage privée n’est pas nécessairement protégée contre un attaquant disposant d’une identité cloud légitime. L’auditeur doit donc analyser aussi bien l’accès anonyme que les permissions IAM et les mécanismes de partage temporaires.

Workloads serverless GCP

Les services serverless GCP utilisent eux aussi des identités. La compromission d’une Cloud Run function ou d’un autre workload doit conduire à analyser le service account utilisé pour appeler les APIs Google Cloud.

La vulnérabilité applicative initiale n’est donc qu’une partie de l’impact. L’auditeur doit comprendre les ressources auxquelles le service account a accès et déterminer si certaines permissions permettent ensuite d’obtenir un autre contexte plus privilégié.

Un service account Editor attaché à une fonction exposée présente par exemple un niveau de risque bien différent d’une identité dédiée possédant seulement une permission de lecture sur une ressource précise.

Pentest GKE

GKE combine Kubernetes avec IAM GCP. L’auditeur doit analyser le ServiceAccount Kubernetes, ses permissions RBAC et les éventuelles permissions Google Cloud accessibles au workload.

La simple présence d’un ServiceAccount Kubernetes n’implique pas nécessairement que celui-ci puisse appeler des APIs GCP. Le lien dépend de l’architecture d’identité mise en place.

Dans les environnements modernes, Workload Identity Federation for GKE constitue le mécanisme privilégié pour permettre aux workloads d’utiliser des identities fines et temporaires sans distribuer de fichiers de clés persistants.

Workload Identity Federation for GKE

Google recommande Workload Identity Federation for GKE dans la majorité des scénarios où des workloads GKE doivent accéder aux services Google Cloud.

Le mécanisme crée un workload identity pool associé au projet et déploie un GKE metadata server sur les nodes. Les requêtes de credentials effectuées par les workloads sont interceptées afin d’obtenir une identité fédérée de courte durée correspondant au Kubernetes ServiceAccount ou au principal configuré.

L’activation du mécanisme n’accorde pas automatiquement de permissions supplémentaires. Les rôles IAM doivent toujours être attribués explicitement aux principals concernés.

Une particularité importante concerne l’identity sameness. Lorsque plusieurs clusters appartiennent au même projet et utilisent les mêmes noms de namespaces et de ServiceAccounts, IAM peut considérer les workloads correspondants comme la même identité si les principals sont construits de manière identique. Les architectures doivent donc tenir compte de cette portée et utiliser des projets distincts, des noms différents ou des conditions IAM lorsque cela est nécessaire.

Les pods utilisant hostNetwork: true constituent également un cas particulier, car leur traitement des requêtes metadata peut différer de celui des pods ordinaires. Le pentest doit donc vérifier le contexte exact du workload avant de conclure sur l’identité obtenue.

Pipelines et identités de déploiement GCP

Les pipelines GCP peuvent utiliser des service accounts ou Workload Identity Federation. Une pipeline utilisant un service account disposant de permissions importantes doit être considérée comme une ressource privilégiée.

Si un développeur peut modifier librement la définition de cette pipeline, il peut potentiellement contrôler les opérations exécutées sous l’identité de déploiement.

L’utilisation de credentials temporaires réduit fortement les risques liés aux clés persistantes mais ne supprime pas les risques liés aux relations de confiance. Le pentester doit donc analyser la fédération, les principals autorisés et les permissions finales du service account ou de l’identité fédérée.

Pentest Kubernetes dans le cloud

Kubernetes mérite une analyse transversale car les mêmes principes apparaissent dans EKS, AKS et GKE. Un environnement Kubernetes possède son propre modèle d’identité et d’autorisation, principalement fondé sur les ServiceAccounts et Kubernetes RBAC. Le fournisseur cloud possède parallèlement son propre système IAM.

La compromission d’une application exécutée dans un pod doit donc conduire l’auditeur à analyser séparément ces deux domaines, puis à déterminer les relations existant entre eux.

Analyser le contexte d’un pod compromis

Lorsqu’une application exécutée dans un pod est compromise, le pentester doit commencer par identifier le contexte Kubernetes. Il recherche notamment le namespace, le ServiceAccount, les volumes montés et les informations mises à disposition du workload.

Il analyse ensuite les permissions de cette identité auprès de l’API Kubernetes. Une commande telle que :

kubectl auth can-i --list

peut aider à comprendre le niveau d’autorisation lorsque le contexte du test permet de l’utiliser.

Le résultat doit cependant être interprété. Pouvoir lire quelques ConfigMaps n’a pas le même impact que pouvoir créer des pods, lire des Secrets ou administrer des RoleBindings.

ServiceAccounts et Kubernetes RBAC

Kubernetes RBAC permet d’accorder des permissions aux utilisateurs, groupes et ServiceAccounts. Les rôles doivent être définis avec un scope suffisamment limité.

Une permission de lecture sur tous les Secrets d’un namespace peut transformer la compromission d’une seule application en compromission de plusieurs workloads. Les RoleBindings et ClusterRoleBindings doivent également être examinés, car un binding trop large peut accorder beaucoup plus de permissions que prévu.

Les versions modernes de Kubernetes utilisent généralement des tokens de ServiceAccount projetés et à durée de vie limitée plutôt que les anciens secrets permanents créés automatiquement. Cette amélioration réduit le risque de réutilisation durable, mais ne supprime pas l’impact d’un token valide pendant la compromission du pod.

Création de workloads et changement indirect d’identité

La capacité à créer des pods peut être plus puissante qu’elle n’en a l’air.

Supposons qu’un ServiceAccount ne puisse pas lire un secret. Il peut cependant créer un pod utilisant un autre ServiceAccount qui, lui, dispose de cette permission. Le premier ServiceAccount contrôle alors indirectement une ressource exécutée avec une identité plus privilégiée.

Il ne reçoit pas directement les permissions du second compte. Il crée un workload capable de les utiliser.

Cette logique est extrêmement proche des primitives IAM observées dans les fournisseurs cloud. Le pentest doit donc étudier les permissions de création ou de modification de workloads avec la même attention que les permissions de lecture directe sur les données.

Privileged containers et compromission du node

Les containers privilégiés et certains montages hostPath peuvent réduire considérablement l’isolation offerte par Kubernetes.

Lorsqu’un workload obtient un accès important au système de fichiers ou aux namespaces du node, l’attaquant peut potentiellement sortir du simple contexte du container et interagir davantage avec le système hôte.

Dans un environnement cloud, cette situation devient particulièrement sensible puisque le node dispose lui-même d’une identité et d’un accès à différents composants d’infrastructure. Le pentest doit donc analyser si la compromission d’un pod peut être transformée en compromission du node et quelles permissions cloud seraient alors accessibles.

Passer du contexte Kubernetes aux permissions cloud

Après avoir analysé Kubernetes RBAC, l’auditeur doit déterminer si le workload possède également une identité cloud.

Sur EKS, il peut s’agir d’IRSA ou d’EKS Pod Identity. Sur AKS, Microsoft Entra Workload ID peut établir cette relation. Sur GKE, Workload Identity Federation for GKE remplit un rôle comparable.

L’auditeur doit déterminer les permissions finales obtenues et vérifier qu’elles correspondent réellement aux besoins de l’application. Le principe de moindre privilège doit donc s’appliquer simultanément aux deux systèmes d’autorisation.

Un pod correctement limité au niveau Kubernetes peut rester extrêmement dangereux si son identité cloud permet d’administrer un projet ou une subscription entière.

CI/CD et supply chain dans un environnement cloud

Le pentest d’un environnement moderne ne devrait pas s’arrêter au portail AWS, Azure ou GCP. Les outils utilisés pour construire et déployer l’infrastructure possèdent souvent des permissions particulièrement importantes.

Pourquoi les pipelines sont-ils des systèmes privilégiés ?

Un pipeline doit souvent pouvoir créer ou modifier des ressources de production. Il peut déployer une application, modifier un cluster Kubernetes, mettre à jour une fonction ou appliquer une configuration Terraform.

L’identité de la pipeline possède donc parfois davantage de permissions que les utilisateurs humains qui la déclenchent. Cette architecture est acceptable à condition que les personnes pouvant influencer le pipeline soient strictement contrôlées.

Le pentester doit analyser les deux dimensions. Il faut comprendre ce que peut faire l’identité de déploiement, puis identifier qui est capable de modifier le code, la configuration ou le workflow utilisant cette identité.

Credentials statiques et fédération OIDC

Les anciennes architectures stockent souvent des access keys, client secrets ou fichiers JSON dans les secrets CI/CD. Une compromission du système de build peut alors fournir un credential réutilisable en dehors du pipeline.

La fédération OIDC limite ce problème en utilisant des credentials temporaires. Elle ne supprime toutefois pas la nécessité d’un contrôle strict.

La sécurité dépend désormais des claims acceptés par la relation de confiance : repository, branche, environnement de déploiement ou autre caractéristique du workload. Une relation trop large peut permettre à un pipeline non prévu d’obtenir une identité sensible.

Le pentest doit donc examiner les conditions côté fournisseur cloud et les protections côté plateforme CI/CD. La relation de confiance n’est robuste que si les deux parties limitent correctement qui peut déclencher l’obtention du credential.

Runners et agents de build

Les runners self-hosted constituent eux aussi une surface critique. Ils peuvent bénéficier d’un accès réseau interne, conserver des caches ou exécuter plusieurs jobs ayant des niveaux de confiance différents.

Un attaquant capable de compromettre un runner peut chercher à observer les credentials temporaires utilisés pendant d’autres builds, accéder à des systèmes internes ou influencer les jobs suivants.

Les environnements sensibles doivent donc isoler autant que possible les exécutions et éviter de mélanger sur la même infrastructure des workloads non fiables et des pipelines fortement privilégiés.

Les runners éphémères et la séparation par niveau de confiance peuvent réduire le risque lorsque l’architecture le permet.

Protection des branches et environnements de déploiement

La sécurité du cloud peut dépendre d’un simple contrôle de repository. Si une branche pouvant déclencher un déploiement de production est modifiable sans revue obligatoire, les permissions du pipeline deviennent indirectement accessibles aux personnes pouvant pousser du code.

Les protections de branches, approbations et règles associées aux environnements doivent donc être considérées comme de véritables contrôles de sécurité cloud.

Le pentester doit vérifier si ces contrôles sont réellement imposés techniquement, s’ils peuvent être contournés par la modification du workflow lui-même et si les administrateurs du repository disposent de mécanismes de bypass incompatibles avec le niveau de criticité attendu.

Infrastructure as Code et sécurité cloud

L’Infrastructure as Code permet de versionner et automatiser le déploiement des ressources. Elle déplace cependant une partie du pouvoir d’administration vers le système de gestion de code et les pipelines.

Pourquoi Terraform State est-il sensible ?

Terraform utilise son state pour conserver une représentation de l’infrastructure qu’il gère. Ce fichier contient donc de nombreuses informations relatives aux ressources.

Selon les providers et les ressources utilisés, des valeurs sensibles peuvent également y apparaître. Un state exposé peut ainsi révéler des endpoints internes, des noms de ressources, des identifiants et parfois des secrets ou credentials.

Même lorsqu’aucun credential immédiatement exploitable n’est présent, cette visibilité peut considérablement faciliter la reconnaissance. L’auditeur peut découvrir des ressources qui n’étaient pas visibles depuis son point d’entrée initial puis vérifier si une autre identité lui permet d’y accéder.

Le state doit donc être stocké dans un backend correctement protégé, avec chiffrement, contrôle d’accès, journalisation et gestion appropriée des versions.

Les fichiers de plan Terraform

Les plans Terraform peuvent eux aussi contenir des informations sensibles. Ils représentent les modifications qui seront appliquées et peuvent embarquer des valeurs nécessaires à leur exécution.

Les artefacts CI/CD contenant des plans doivent donc être protégés et leur durée de conservation limitée lorsque cela est possible.

L’utilisation du mot-clé sensitive dans Terraform permet notamment de masquer certaines valeurs dans l’interface, mais ne doit pas être interprétée comme une garantie que la donnée n’apparaît jamais dans le state. Les mécanismes de stockage et de gestion des secrets doivent être traités séparément.

Détournement du processus de déploiement

L’un des scénarios les plus importants ne nécessite aucune fuite de state.

Supposons qu’un développeur ne soit pas autorisé à modifier IAM directement. Il peut cependant modifier un fichier Terraform utilisé par une pipeline disposant de permissions d’administration.

Si aucune revue ou restriction ne bloque les modifications sensibles, le développeur peut utiliser la pipeline comme intermédiaire pour demander à l’environnement de déployer une configuration qu’il ne pourrait pas créer lui-même.

L’identité privilégiée reste celle de la pipeline. L’utilisateur contrôle simplement ce qu’elle va exécuter. La frontière de sécurité dépend donc du processus de revue du code et des permissions de la pipeline autant que du contrôle IAM natif du fournisseur cloud.

Séparer la modification, la validation et l’application

Les architectures sensibles doivent distinguer autant que possible la capacité à proposer une modification de celle permettant de l’approuver et de la déployer.

Une pull request peut être examinée par une seconde personne. Une branche de production peut imposer des protections supplémentaires. L’étape d’application peut enfin nécessiter une approbation spécifique ou être limitée à un environnement contrôlé.

Le pentest doit vérifier si ces mécanismes constituent de véritables barrières techniques ou seulement des conventions organisationnelles facilement contournables.

L’objectif est d’empêcher qu’une seule identité développeur puisse à la fois modifier le code, contourner la revue et utiliser automatiquement une identité de déploiement très privilégiée.

Exposition des données et exploitation des services de stockage cloud

Les services de stockage constituent une surface d’attaque importante dans AWS, Azure et GCP. Limiter leur analyse à la recherche de buckets ou de containers publics serait toutefois réducteur.

L’auditeur doit d’abord comprendre comment l’accès aux données est autorisé. Une ressource peut être publiquement accessible, exposée à certaines identités authentifiées, partagée au moyen d’une URL temporaire ou rendue accessible indirectement par une application.

Il doit ensuite analyser les opérations permises. Une lecture publique peut exposer des documents confidentiels, des sauvegardes ou du code source. Une écriture non autorisée peut permettre de modifier des fichiers consommés par d’autres applications et produire des impacts sur l’intégrité ou la supply chain.

Presigned URLs et signed URLs

AWS S3 et Google Cloud Storage permettent de générer des URLs signées donnant temporairement accès à une ressource sans transmettre les credentials du principal qui a créé l’URL.

Ces URLs doivent être considérées comme des bearer capabilities : toute personne qui les possède peut généralement effectuer l’opération autorisée tant que la signature est valide et que les autres conditions sont respectées.

Lors d’un pentest, l’auditeur vérifie donc leur durée de validité, l’opération autorisée, la ressource visée et la manière dont l’URL est transmise ou journalisée.

Une URL permettant seulement de télécharger un objet public pendant quelques minutes présente un risque très différent d’une URL d’upload permettant de remplacer un fichier consommé ensuite par une application de production.

Azure SAS et délégation d’accès

Les Shared Access Signatures Azure remplissent un objectif comparable. Elles permettent de déléguer un accès à des ressources de stockage avec une portée et une durée déterminées.

L’auditeur doit examiner les permissions, la durée, le type de SAS et le service concerné. Une Account SAS très longue durée et fortement permissive représente un risque beaucoup plus important qu’une user delegation SAS courte et limitée à une ressource précise.

Il faut également déterminer qui peut générer de nouvelles SAS. La sécurité ne dépend pas seulement des tokens déjà exposés mais également des identités capables d’en produire de nouveaux.

Exfiltration de données et validation contrôlée

Lorsqu’une identité compromise dispose d’un accès à des données, l’analyse ne doit pas se limiter à vérifier que la lecture fonctionne. L’auditeur doit déterminer l’ampleur réelle de l’exposition.

La capacité de récupérer un seul objet prédéfini n’a pas le même impact que la possibilité de lister et lire toutes les sauvegardes de production. Il faut également tenir compte des restrictions réseau, des private endpoints et des contrôles de service.

Dans un pentest autorisé, il n’est pas nécessaire d’exfiltrer de grandes quantités de données réelles. Une preuve de capacité limitée, réalisée sur une donnée prévue pour l’audit, est généralement suffisante pour démontrer le risque.

Metadata services et identités de workloads

Les metadata services sont souvent associés aux scénarios SSRF dans le cloud, mais il est important d’en expliquer précisément le rôle. Ils permettent à un workload d’obtenir des informations sur son environnement et, selon le fournisseur, de participer à l’obtention de credentials temporaires.

La vulnérabilité n’est donc pas le metadata service lui-même. Le problème apparaît lorsqu’une application vulnérable permet à un attaquant de provoquer des requêtes depuis le contexte du workload et que ces requêtes suffisent à obtenir une identité ou des informations qui ne devraient pas lui être accessibles.

AWS IMDSv2 et portée réelle d’une SSRF

Sur EC2, IMDSv2 impose une requête PUT initiale pour obtenir un token de session, puis l’utilisation de ce token dans les requêtes suivantes. Une SSRF limitée à GET n’offre donc pas les mêmes possibilités qu’une SSRF permettant de choisir la méthode et certains headers.

Le pentester doit aussi examiner les redirections et les bibliothèques HTTP utilisées par l’application. Certaines protections ne sont efficaces que si les headers spécifiques ne sont pas retransmis vers des destinations non prévues ou si les redirections sont correctement contrôlées.

Le rapport doit donc décrire les capacités exactes de la SSRF plutôt que d’affirmer de manière générique qu’elle permet d’atteindre IMDS.

Azure Instance Metadata Service et App Service

Sur les machines virtuelles Azure, l’Instance Metadata Service est disponible via une adresse link-local et peut être utilisé dans plusieurs scénarios liés aux managed identities.

Pour App Service, le mécanisme d’accès à la managed identity diffère : l’application reçoit notamment un endpoint local via IDENTITY_ENDPOINT et doit utiliser le header attendu par la plateforme.

Cette nuance est importante lors de l’évaluation d’une SSRF. Une technique décrite pour une VM ne doit pas être appliquée automatiquement à App Service ou Azure Functions sans vérifier le mécanisme de l’environnement concerné.

GKE metadata server

Lorsque Workload Identity Federation for GKE est activé, GKE déploie un metadata server qui intercepte les requêtes de credentials des workloads.

Le Kubernetes ServiceAccount du pod est utilisé pour établir l’identité du workload et obtenir un token fédéré de courte durée. Le pentest doit déterminer quel principal IAM en résulte et quelles permissions lui sont accordées.

La présence du metadata server est normale. Le risque vient d’une identité de workload trop privilégiée, d’une relation de confiance trop large ou d’un contexte de pod permettant d’atteindre une identité différente de celle attendue.

Serverless : quand la compromission du code devient une compromission d’identité

Les architectures serverless réduisent une partie des problématiques liées à l’administration de serveurs. Elles ne suppriment cependant ni les vulnérabilités applicatives ni les enjeux IAM.

Une fonction serverless doit souvent accéder à d’autres services. Une Lambda peut lire un bucket S3, une Azure Function peut accéder à Key Vault et une fonction GCP peut utiliser un service account pour interagir avec Google Cloud.

Lorsqu’une vulnérabilité permet d’exécuter du code dans la fonction, l’attaquant obtient en pratique la possibilité d’effectuer les opérations autorisées à cette identité.

Distinguer la vulnérabilité applicative de l’amplification cloud

Supposons qu’une fonction Lambda soit vulnérable à une injection permettant l’exécution de commandes. Écrire simplement que la vulnérabilité permet une RCE sur Lambda ne suffit pas.

Le pentester doit immédiatement analyser le rôle d’exécution de la fonction. Si celui-ci permet uniquement d’écrire des logs, l’impact cloud additionnel reste relativement limité. S’il peut récupérer des secrets, accéder à plusieurs buckets ou utiliser des permissions IAM sensibles, la même vulnérabilité applicative devient un point d’entrée vers une compromission plus large.

Le rapport doit donc distinguer la vulnérabilité initiale de l’amplification de son impact par les permissions cloud du workload.

Secrets dans les variables d’environnement

Les variables d’environnement sont souvent utilisées pour transmettre de la configuration aux fonctions serverless. Elles peuvent cependant devenir problématiques lorsqu’elles contiennent directement des passwords, API keys ou autres secrets durables.

Une compromission du workload peut permettre de lire cette configuration. Le pentester doit alors étudier chaque secret selon sa portée.

Il est généralement préférable de conserver les secrets dans un service dédié et d’autoriser le workload à récupérer uniquement ceux dont il a besoin. Cette approche ne rend pas le secret inaccessible à une fonction déjà compromise, puisque la fonction doit légitimement pouvoir l’utiliser, mais elle améliore la gouvernance, la rotation et le contrôle des accès.

Comment renforcer la sécurité d’un environnement cloud ?

Il n’existe pas de mesure unique capable d’empêcher toutes les attaques cloud. Une défense efficace repose sur plusieurs couches complémentaires et sur l’application cohérente du principe de moindre privilège.

Appliquer réellement le principe du moindre privilège

Le moindre privilège ne consiste pas uniquement à réduire la longueur des policies. Il faut analyser les combinaisons de permissions.

Une identité capable de créer un workload ne devrait pas pouvoir lui attribuer arbitrairement un rôle beaucoup plus puissant. De même, une personne capable de modifier le code d’une fonction critique doit être considérée comme ayant potentiellement accès aux capacités de cette fonction.

Les droits doivent donc être évalués en tenant compte des dépendances et des relations entre ressources. L’analyse périodique des permissions inutilisées, des rôles génériques et des bindings hérités peut réduire considérablement la surface d’attaque.

Réduire les credentials persistants

Les access keys AWS, client secrets Microsoft Entra et fichiers de clés GCP doivent être réduits autant que possible. Les rôles, managed identities et systèmes de fédération permettent généralement d’utiliser des credentials temporaires.

Cette évolution réduit les risques liés à la fuite de secrets persistants. Elle ne dispense cependant jamais d’appliquer le moindre privilège aux identités temporaires.

Un token valable une heure peut largement suffire à compromettre un environnement si l’identité associée est administratrice. La durée de vie du credential et le niveau de privilège doivent donc être traités comme deux dimensions distinctes.

Isoler les identités des workloads

Chaque workload sensible devrait disposer d’une identité dédiée. Partager la même identité entre plusieurs applications augmente considérablement le rayon d’impact d’une compromission.

Lorsqu’une application ne nécessite qu’un accès en lecture à une ressource précise, son identité ne devrait pas disposer de permissions génériques sur l’ensemble du projet, compte ou subscription.

Les identités de nodes Kubernetes doivent également être séparées autant que possible des identités de pods. L’accès au metadata service du node doit être limité lorsque le workload n’en a pas besoin.

Sécuriser Kubernetes

Les ServiceAccounts doivent être spécialisés par workload et les permissions Kubernetes RBAC limitées. Les containers privilégiés et les montages du host doivent rester exceptionnels.

L’accès des pods à l’identité du node doit être contrôlé lorsqu’il présente un risque. Les mécanismes de workload identity doivent enfin fournir à chaque application uniquement les permissions cloud dont elle a réellement besoin.

Les namespaces, NetworkPolicies et politiques d’admission peuvent compléter cette approche en réduisant les possibilités de mouvement latéral et en empêchant le déploiement de workloads présentant des caractéristiques dangereuses.

Sécuriser les pipelines CI/CD et l’Infrastructure as Code

Les pipelines doivent être considérés comme des systèmes d’administration. Les personnes capables de modifier leurs définitions doivent donc être contrôlées.

Les connexions vers les fournisseurs cloud doivent utiliser autant que possible des credentials temporaires et des relations de confiance précisément limitées. Les branches et environnements de production doivent imposer des mécanismes de validation adaptés à leur criticité.

Les fichiers Terraform State, plans et autres artefacts Infrastructure as Code doivent être protégés comme des données sensibles.

Enfin, les permissions de la pipeline elle-même doivent être revues régulièrement. Une identité de déploiement qui conserve des permissions devenues inutiles peut transformer une compromission du repository en compromission beaucoup plus large du cloud.

Protéger les données et les services de stockage

Les stockages doivent être privés par défaut. Les mécanismes de partage temporaire doivent avoir une portée et une durée de vie minimales.

Les droits d’écriture doivent être encore plus strictement contrôlés lorsque les objets sont utilisés par des applications ou des processus de déploiement.

Les mécanismes natifs permettant de bloquer les expositions publiques doivent être activés lorsque le besoin métier ne nécessite pas ce type d’accès. Il faut également surveiller les principals disposant de la capacité de créer de nouveaux liens de partage ou URLs signées.

Renforcer la segmentation réseau

Les services internes ne doivent pas devenir automatiquement accessibles à tous les workloads du même environnement. Les VPC, VNets, security groups, Network Security Groups, firewall rules, private endpoints et mécanismes équivalents doivent limiter les communications aux flux nécessaires.

L’objectif est notamment de contenir l’impact lorsqu’une application est compromise. Une vulnérabilité dans un service exposé ne devrait pas fournir un accès réseau généralisé à l’ensemble des composants internes.

La segmentation réseau doit cependant être conçue en complément d’IAM. Une ressource privée reste vulnérable si une identité compromise peut l’administrer via le control plane depuis Internet.

Journaliser et détecter les activités suspectes

La prévention seule n’est pas suffisante. Les actions effectuées sur le control plane doivent être journalisées et surveillées.

AWS CloudTrail, Azure Activity Logs, les journaux Microsoft Entra et Google Cloud Audit Logs peuvent fournir des informations importantes sur les actions d’administration.

Une assumption de rôle inhabituelle, la création d’une nouvelle credential, une modification IAM, une nouvelle attribution de rôle ou l’utilisation d’une identité depuis un contexte inattendu peuvent constituer des signaux d’attaque.

Les scénarios identifiés pendant le pentest peuvent également servir à améliorer les règles de détection. Une mission offensive devient alors un moyen d’évaluer non seulement les possibilités de compromission mais aussi la capacité de l’organisation à observer et investiguer ces comportements.

Conclusion

Le pentest cloud ne consiste pas à appliquer un pentest réseau traditionnel à des machines hébergées chez AWS, Azure ou GCP. Les architectures cloud reposent fortement sur les identités, les APIs, l’automatisation et les relations de confiance entre workloads.

Une application compromise peut fournir l’identité d’un workload. Cette identité peut avoir accès à un secret. Le secret peut correspondre à une seconde identité disposant de permissions plus importantes. Un utilisateur ne disposant d’aucun droit administratif direct peut contrôler un pipeline ou une fonction exécutée sous une identité privilégiée. Un pod correctement limité par Kubernetes RBAC peut néanmoins disposer de permissions cloud beaucoup trop larges.

Ces situations montrent pourquoi une mauvaise configuration ne doit jamais être analysée isolément. La valeur d’un pentest cloud réside précisément dans la capacité à déterminer comment les différentes permissions et relations de confiance peuvent être combinées par un attaquant réel.

Une méthodologie efficace doit donc cartographier les ressources et identités, comprendre les permissions réellement effectives, identifier les primitives permettant de contrôler d’autres contextes d’identité, valider les scénarios de manière maîtrisée puis déterminer l’impact maximal réaliste.

Les remédiations doivent suivre le même raisonnement. L’objectif n’est pas uniquement d’empêcher toute compromission initiale, ce qui reste difficile dans un environnement complexe. Il faut également limiter ce qu’un attaquant pourrait accomplir après avoir compromis une application, un compte utilisateur ou un workload.

Une architecture cloud correctement cloisonnée doit être capable de contenir cette compromission. Une application vulnérable doit rester aussi longtemps que possible une application vulnérable, et non devenir le premier point d’accès permettant progressivement de prendre le contrôle des identités, des pipelines, des données et finalement de l’ensemble de l’infrastructure cloud.

Sources

Les mécanismes susceptibles d’évoluer ont été vérifiés à partir de documentations officielles ou des dépôts des outils concernés. Les politiques de pentest des fournisseurs doivent être revalidées avant chaque mission.

• AWS – Customer Support Policy for Penetration Testing
• AWS – Instance Metadata Service (IMDSv2)
• AWS – EKS Identity and Access Management best practices
• AWS – EKS Pod Identities
• Microsoft – Penetration testing on Azure
• Microsoft – Azure RBAC role assignment prerequisites
• Microsoft – Microsoft Entra Workload ID on AKS
• Microsoft – Managed identities for App Service and Azure Functions
• Google Cloud – Cloud Security FAQ / penetration testing
• Google Cloud – Service account authentication roles
• Google Cloud – Workload Identity Federation for GKE
• Google Cloud – Service account security best practices
• HashiCorp – Manage sensitive data in Terraform