Modélisation Opérationnelle des Menaces et Détection Basée sur la Télémétrie pour les Environnements Multi‑Cloud : Stratégies Pratiques de Défense dans les Infrastructures IaaS, PaaS et Kubernetes (2025)

1. Introduction

L’informatique en nuage a radicalement transformé le modèle opérationnel des infrastructures informatiques. Entre 2018 et 2025, les organisations ont migré des charges critiques vers des plateformes telles que Amazon Web Services (AWS), Microsoft Azure et Google Cloud Platform (GCP), motivées par l’élasticité, l’automatisation et les économies d’échelle. Cependant, cette transformation a également introduit de nouveaux paradigmes de sécurité. Contrairement aux centres de données traditionnels, les environnements cloud sont définis par des API, des identités et des politiques programmables, ce qui déplace le centre de gravité de la sécurité du réseau vers le contrôle des identités et des configurations.

Les données issues de rapports d’incidents publiés par des entreprises de sécurité indiquent que la majorité des violations dans le cloud ne résulte pas de vulnérabilités logicielles classiques, mais plutôt de configurations incorrectes et d’abus d’identifiants. Des recherches menées par Unit 42 et Wiz Research montrent que des permissions IAM excessives et des clés d’API exposées restent un vecteur dominant de compromission (PALO ALTO NETWORKS, 2024; WIZ, 2023). Parallèlement, les environnements cloud‑native basés sur des conteneurs et Kubernetes introduisent de nouveaux plans de contrôle, augmentant la complexité de la surface d’attaque.

Un autre facteur critique en 2025 est la convergence entre l’informatique en nuage et l’intelligence artificielle. Les infrastructures exécutant des pipelines d’entraînement et d’inférence de modèles de machine learning stockent souvent de grands volumes de données sensibles et dépendent de ressources GPU évolutives. Ce scénario crée des incitations économiques claires pour les attaquants, que ce soit pour l’exfiltration de données ou pour l’abus de ressources de calcul.

Du point de vue opérationnel, la sécurité dans le cloud implique trois défis centraux :

• visibilité limitée dans des environnements distribués
• gestion complexe des identités et des permissions
• détection d’activités malveillantes dans des API hautement dynamiques

Des cadres tels que Zero Trust Architecture (NIST, 2020) et Cloud Security Posture Management (CSPM) ont émergé pour répondre à ces enjeux, mais de nombreuses organisations rencontrent encore des difficultés dans la mise en œuvre pratique de ces approches à grande échelle.

En outre, les techniques offensives spécifiques au cloud ont évolué rapidement. Des outils tels que Pacu, CloudFox et ScoutSuite démontrent comment des permissions apparemment bénignes peuvent être enchaînées pour élever des privilèges et accéder à des ressources sensibles. Dans les environnements Kubernetes, des attaques impliquant la compromission du kubelet, l’abus de service accounts ou l’exploitation de conteneurs privilégiés sont devenues courantes dans les exercices de red team.

Ce travail aborde ce contexte à partir d’une perspective opérationnelle. Plutôt que de se concentrer exclusivement sur des politiques ou des cadres conceptuels, nous présentons une méthode structurée pour :

• modéliser les menaces dans des environnements multi‑cloud
• formaliser le risque d’exposition des identités et des services
• mettre en œuvre des mécanismes de détection basés sur la télémétrie

L’hypothèse centrale de cette étude est que la combinaison de télémétrie native du cloud, d’instrumentation d’exécution avec eBPF et de modélisation quantitative du risque peut réduire significativement le temps de détection et de réponse aux incidents.

Le reste de l’article est organisé comme suit. La section suivante discute de l’état de l’art en matière de sécurité cloud et des travaux connexes. Ensuite, nous formalisons le modèle de menaces et présentons la méthodologie proposée. Par la suite, nous décrivons l’implémentation pratique et évaluons expérimentalement le système dans un environnement multi‑cloud. Enfin, nous discutons des implications opérationnelles et des orientations futures de recherche.

2. Background and Related Work

La sécurité dans le cloud a considérablement évolué au cours de la dernière décennie. Les premières études se concentraient principalement sur l’isolation entre tenants et sur la sécurité de la virtualisation. Toutefois, avec l’essor des architectures cloud‑native, la surface d’attaque s’est élargie pour inclure les API de gestion, les pipelines CI/CD, les systèmes d’identité et l’orchestration de conteneurs.

Le modèle de responsabilité partagée, adopté par les principaux fournisseurs cloud, établit que la sécurité de l’infrastructure physique et de l’hyperviseur relève de la responsabilité du fournisseur, tandis que les clients doivent protéger les identités, les données et les configurations. Ce modèle génère fréquemment des lacunes opérationnelles lorsque les organisations supposent que certains contrôles sont automatiquement garantis par le fournisseur (AWS, 2024).

Plusieurs cadres ont été développés pour orienter les pratiques de sécurité dans le cloud. Le NIST Cloud Computing Security Reference Architecture définit des principes de contrôle et de gouvernance pour les environnements cloud (NIST, 2018). La Cloud Security Alliance (CSA) a introduit la Cloud Controls Matrix, largement utilisée pour les audits et la conformité (CSA, 2023).

Une autre avancée importante a été la création de la matrice MITRE ATT&CK for Cloud, qui catégorise les techniques adverses spécifiques à AWS, Azure et GCP (MITRE, 2024). Cette matrice inclut des tactiques telles que :

• accès initial via des identifiants exposés
• élévation de privilèges via des politiques IAM mal configurées
• exfiltration via des API de stockage

Les outils open source jouent également un rôle important dans la sécurité cloud. Le Tableau 1 présente certains des outils les plus utilisés lors d’audits et d’exercices de red teaming.

Outil	Fonction principale	Plateforme	Année
ScoutSuite	Audit automatisé de configuration	AWS/Azure/GCP	2017
Pacu	Framework d’exploitation AWS	AWS	2018
CloudFox	Énumération et élévation de privilèges	AWS/Azure	2022
kube-bench	Vérification CIS Kubernetes	Kubernetes	2018
Falco	Détection de comportement à l’exécution	Linux/K8s	2016

Des études récentes soulignent que la majorité des violations dans le cloud impliquent des identifiants compromis. Un rapport de Verizon a identifié que des identifiants volés ou réutilisés ont été utilisés dans plus de 40 % des incidents impliquant une infrastructure cloud (VERIZON, 2024).

Une autre tendance importante est l’adoption des CNAPP (Cloud Native Application Protection Platforms), qui combinent des fonctionnalités de CSPM, CWPP et de sécurité des conteneurs dans une seule plateforme. Des solutions commerciales telles que Prisma Cloud, Wiz et Orca Security sont devenues largement utilisées pour la visibilité continue des risques.

Parallèlement, les technologies basées sur eBPF ont gagné en popularité pour la surveillance à l’exécution. Des outils tels que Falco utilisent eBPF pour capturer des événements système avec une surcharge minimale, permettant la détection de comportements suspects dans les conteneurs et les hôtes.

Malgré ces avancées, il existe encore un écart entre la théorie de la sécurité cloud et les opérations pratiques de défense. De nombreuses organisations collectent de grands volumes de journaux, mais manquent de modèles formels permettant de prioriser les événements à haut risque.

Cet article cherche à combler cette lacune en proposant un modèle quantitatif de risque combiné à une télémétrie opérationnelle.

3. Modèle de menace et formalisation du problème

Les environnements multi‑cloud introduisent une surface d’attaque distribuée composée d’identités, de services gérés, de réseaux virtuels et de workloads. Pour formaliser le problème de sécurité, nous définissons trois composants principaux :

1. Identités (utilisateurs, rôles, comptes de service)
2. Ressources (instances, buckets, bases de données)
3. Canaux d’accès (APIs, réseaux, endpoints)

Un adversaire typique dans des scénarios cloud possède l’une des capacités initiales suivantes :

• accès à des identifiants exposés
• accès à un conteneur compromis
• accès à un token d’API

À partir de ce point initial, l’attaquant tente d’escalader les privilèges ou d’accéder à des données sensibles.

Le Tableau 2 présente des vecteurs d’attaque courants observés dans les environnements cloud.

Vecteur d’attaque	Technique ATT&CK	Impact
Identifiants IAM exposés	T1078	Accès initial
Permissions IAM excessives	T1098	Escalade de privilèges
Buckets S3 publics	T1530	Exfiltration de données
Conteneurs privilégiés	T1611	Évasion de conteneur
Tokens Kubernetes volés	T1552	Mouvement latéral

Pour quantifier le risque, nous définissons une fonction de risque basée sur trois facteurs :

• exposition ($E$)
• privilège ($P$)
• détectabilité ($D$)

Le risque opérationnel est défini comme :

$$ R = \frac{E \times P}{D} $$

Où :

• $E$ représente le nombre de chemins accessibles vers la ressource
• $P$ représente le niveau de privilège associé
• $D$ représente la probabilité de détection basée sur la télémétrie

Plus la valeur de $R$ est élevée, plus la priorité de mitigation est importante.

Ce modèle permet de prioriser les configurations dangereuses, telles que des rôles avec des permissions larges et une faible visibilité des logs.

4. Méthodologie proposée

La méthodologie proposée combine trois couches principales de sécurité :

1. Audit continu de configuration
2. Surveillance du runtime
3. Analyse comportementale basée sur les logs

Premièrement, des outils d’audit comme ScoutSuite identifient des configurations non sécurisées dans les comptes cloud.

Exemple d’exécution :

python scoutsuite.py aws --profile security-audit --report-dir reports

Cette étape identifie des problèmes tels que :

• buckets publics
• rôles avec des politiques AdministratorAccess
• logs désactivés

La deuxième couche utilise une surveillance du runtime basée sur eBPF pour détecter des comportements suspects dans les conteneurs.

Exemple de vérification de conformité Kubernetes :

kube-bench run --targets master,node --benchmark cis-1.23

Ces contrôles détectent des configurations non sécurisées telles que :

• conteneurs privilégiés
• utilisation de hostNetwork
• permissions excessives des comptes de service

La troisième couche analyse les logs des APIs cloud. Des événements tels que CreateAccessKey, AssumeRole ou GetObject peuvent indiquer des activités malveillantes.

Le Tableau 3 montre des exemples d’événements critiques.

Événement	Service	Indicateur
CreateAccessKey	IAM	Persistance possible
AssumeRole	STS	Mouvement latéral
GetObject	S3	Exfiltration
RunInstances	EC2	Cryptominage

Les événements sont corrélés dans un SIEM afin d’identifier des chaînes d’attaque.

5. Implémentation

L’implémentation a été réalisée dans un environnement expérimental contenant :

• AWS
• Azure
• cluster Kubernetes sur GKE

L’architecture inclut :

• collecte des logs via CloudTrail et Audit Logs
• ingestion dans un SIEM
• détection comportementale via Falco

Exemple de règle Falco :

- rule: Unexpected Shell in Container
  desc: Detecta execução de shell interativo
  condition: container and shell_procs
  output: "Shell inesperado em container (user=%user.name)"
  priority: WARNING

De plus, des scripts automatisés calculent le score de risque $R$ pour chaque ressource cloud.

6. Évaluation expérimentale

L’environnement expérimental comprenait 120 ressources cloud et 35 identités IAM.

Métrique	Avant	Après
MTTD	47 min	8 min
MTTF	3.2 h	1.1 h
Ressources à haut risque	28	9

Une autre évaluation a comparé des outils de détection.

Outil	Type	Couverture
Falco	Runtime	Élevée
GuardDuty	Managed	Moyenne
Azure Defender	Managed	Élevée
SIEM custom	Logs	Élevée

Les résultats indiquent que la combinaison de la télémétrie runtime avec les logs cloud améliore significativement la visibilité.

7. Étude de cas

Dans un scénario simulé inspiré d’incidents réels, un développeur a exposé une clé AWS dans un dépôt public. Un attaquant automatisé a utilisé la clé pour exécuter des commandes STS et assumer un rôle privilégié.

L’attaquant a ensuite accédé à un bucket S3 contenant des sauvegardes de base de données. La séquence d’événements comprenait :

1. GetCallerIdentity
2. ListBuckets
3. AssumeRole
4. GetObject

La corrélation des logs a permis de détecter le comportement en moins de 10 minutes.

8. Discussion

Les résultats démontrent que la sécurité cloud dépend fortement de la visibilité opérationnelle. Même les organisations qui collectent des logs ne disposent souvent pas de mécanismes efficaces de corrélation.

Un autre défi est la gestion des identités. Dans les grands environnements, un seul compte AWS peut posséder des milliers de rôles IAM. Cela rend difficile l’identification de permissions dangereuses sans automatisation.

De plus, les environnements Kubernetes introduisent une complexité supplémentaire en raison de l’interaction entre le contrôle d’identité, le réseau et le runtime.

9. Conclusion et travaux futurs

Cette étude a présenté une approche opérationnelle de la sécurité dans les environnements cloud basée sur une modélisation formelle du risque et une télémétrie distribuée. La combinaison de l’audit de configuration, de la surveillance du runtime et de l’analyse des logs a démontré une réduction significative du temps de détection des activités malveillantes.

Les travaux futurs devraient explorer l’utilisation du machine learning pour l’analyse comportementale des APIs cloud et intégrer des techniques de détection avec des politiques automatisées de remédiation.

12. RÉFÉRENCES

AMAZON WEB SERVICES. Bonnes pratiques de sécurité AWS. 2024. https://docs.aws.amazon.com/security/

CLOUD SECURITY ALLIANCE. Cloud Controls Matrix v4. 2023. https://cloudsecurityalliance.org

FALCO PROJECT. Documentation Falco. 2024. https://falco.org

GOOGLE CLOUD. Présentation de Security Command Center. 2024. https://cloud.google.com/security-command-center

KUBERNETES. Documentation de sécurité Kubernetes. 2024. https://kubernetes.io/docs/concepts/security/

MITRE. Matrice ATT&CK pour le Cloud. 2024. https://attack.mitre.org

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Architecture Zero Trust. 2020. https://nvlpubs.nist.gov

NIST. Architecture de référence de sécurité pour le Cloud Computing. 2018. https://nvlpubs.nist.gov

ORCA SECURITY. Rapport sur l’état de la sécurité du cloud. 2024. https://orca.security

PALO ALTO NETWORKS. Rapport Unit 42 sur les menaces cloud. 2024. https://unit42.paloaltonetworks.com

SCOUTSUITE. Outil d’audit de sécurité multi‑cloud. 2024. https://github.com/nccgroup/ScoutSuite

SYSDIG. Sécurité d’exécution Falco. 2023. https://sysdig.com

VERIZON. Rapport sur les enquêtes de violations de données. 2024. https://www.verizon.com/business/resources/reports/dbir/

WIZ. Rapport sur les risques de sécurité du cloud. 2023. https://www.wiz.io

MICROSOFT. Référence de sécurité Azure. 2024. https://learn.microsoft.com/security/benchmark/

CISA. Architecture technique de référence pour la sécurité du cloud. 2023. https://www.cisa.gov

CNCF. Livre blanc sur la sécurité cloud native. 2022. https://www.cncf.io

SNYK. Rapport sur la sécurité Kubernetes. 2023. https://snyk.io

AQUA SECURITY. Rapport sur les menaces cloud native. 2024. https://www.aquasec.com

RED HAT. Guide de sécurité Kubernetes. 2024. https://access.redhat.com

IBM SECURITY. Paysage des menaces dans le cloud. 2023. https://www.ibm.com/security

GOOGLE. Modèle Zero Trust BeyondCorp. 2021. https://cloud.google.com/beyondcorp

MICROSOFT. Documentation Defender for Cloud. 2024. https://learn.microsoft.com/azure/defender-for-cloud

AWS. Documentation CloudTrail. 2024. https://docs.aws.amazon.com/cloudtrail

KUBERNETES CIS BENCHMARK. Center for Internet Security. 2023. https://www.cisecurity.org

EBPF FOUNDATION. Présentation de eBPF. 2024. https://ebpf.io