Sécurité Cloud : enjeux et techniques

La sécurité Cloud désigne l'ensemble des techniques, contrôles et architectures visant à protéger les environnements hébergés sur des plateformes IaaS, PaaS et SaaS. Son enjeu central repose sur le modèle de responsabilité partagée. Le fournisseur sécurise l'infrastructure physique et l'hyperviseur. Le client reste responsable de la configuration des ressources, des identités et des données. Cette frontière est fréquemment mal comprise. Elle génère des expositions critiques : buckets S3 publics, rôles IAM trop permissifs, secrets stockés en clair dans des variables d'environnement, ou Security Groups ouverts sur 0.0.0.0/0. Les trois grands hyperscalers, AWS, Azure et GCP, partagent des primitives communes : gestion des identités via IAM ou Entra ID, isolation réseau par VPC ou VNet, chiffrement au repos et en transit. Chaque service managé ajoute une surface d'attaque propre. Les fonctions serverless, les clusters Kubernetes managés (EKS, AKS, GKE) et les pipelines CI/CD connectés au cloud multiplient les chemins d'escalade de privilèges. La sécurité Cloud exige donc une vision unifiée des permissions, des flux réseau et des journaux d'activité sur l'ensemble du tenant.

La détection côté Blue Team s'appuie en priorité sur les journaux d'activité natifs des plateformes. Sur AWS, CloudTrail enregistre chaque appel d'API. Les événements clés à surveiller sont : ConsoleLoginWithoutMFA, CreateAccessKey sur un compte root, AttachRolePolicy avec des permissions wildcard, et GetSecretValue sur AWS Secrets Manager. Sur Azure, les journaux d'audit Entra ID et Azure Monitor exposent les opérations sur les rôles RBAC et les connexions suspectes. Sur GCP, Cloud Audit Logs couvre les Admin Activity et Data Access logs. Un outil CSPM (Cloud Security Posture Management) comme Prisma Cloud, Wiz ou AWS Security Hub corrèle ces événements et détecte les dérives de configuration en continu. Les indicateurs de compromission typiques incluent : des appels d'API depuis des régions inhabituelles, une augmentation soudaine des appels DescribeInstances ou ListBuckets (reconnaissance), et la création de nouvelles clés d'accès sur des comptes de service dormants. Côté SIEM, l'ingestion des logs CloudTrail dans Splunk ou Elastic permet de créer des règles de détection sur les patterns d'escalade de privilèges IAM. Le délai entre un appel API malveillant et son ingestion dans le SIEM doit être inférieur à cinq minutes pour espérer une réponse rapide.

Côté Red Team, l'exploitation d'un environnement cloud commence généralement par la collecte de credentials exposés. Les vecteurs les plus courants sont : clés AWS dans des dépôts GitHub publics, tokens d'accès dans des images Docker, métadonnées IMDS accessibles via SSRF (appel vers 169.254.169.254 ou IMDSv1 sans restriction). L'outil Pacu (framework AWS pentest) automatise l'énumération des permissions IAM, la recherche de politiques trop permissives et l'escalade de privilèges via iam:PassRole ou sts:AssumeRole. Sur Azure, ROADtools et AzureHound cartographient les relations entre objets Entra ID pour identifier les chemins d'escalade vers des rôles Global Administrator. Sur GCP, GCPBucketBrute et ScoutSuite couvrent l'énumération des ressources exposées. Les contre-mesures prioritaires sont : activer IMDSv2 obligatoire sur AWS pour bloquer les attaques SSRF, appliquer le principe de moindre privilège sur chaque rôle IAM, activer MFA sur tous les comptes humains, et interdire les clés d'accès longue durée au profit de rôles assumés temporairement. Le durcissement passe aussi par des Service Control Policies (SCP) sur AWS Organizations et des Azure Policy pour bloquer les configurations non conformes à l'échelle du tenant.