Détection de Compromission Cloud : Guide Complet AWS, Azure et GCP

La détection d'une compromission dans un environnement cloud ne ressemble en rien à la chasse aux menaces sur un parc on-premise. Il n'y a plus de périmètre réseau à instrumenter, plus de tap SPAN sur un cœur de réseau, plus d'agent EDR à déployer sur une machine virtuelle éphémère qui vivra quarante secondes. L'attaquant n'exploite plus une faille mémoire : il s'authentifie. Il utilise une clé d'accès volée, un jeton OAuth détourné, une identité de charge de travail surprivilégiée, et il opère exclusivement via des API légitimes qui répondent HTTP 200. Toute la détection bascule donc sur un seul substrat : le journal d'audit du plan de contrôle — AWS CloudTrail, Azure Activity Logs et Microsoft Entra ID sign-in logs, Google Cloud Audit Logs. Ce guide complet s'adresse aux équipes SOC, aux analystes de réponse à incident et aux RSSI qui doivent bâtir une capacité de détection multi-cloud crédible. Nous détaillerons les indicateurs de compromission spécifiques à chaque fournisseur, les phases d'une intrusion cloud de la reconnaissance à l'exfiltration, les techniques de latéralisation inter-services, la surveillance des dépôts d'objets S3, Blob Storage et GCS, les outils natifs GuardDuty, Defender for Cloud et Security Command Center, l'intégration SIEM et CSPM, ainsi que les spécificités du forensics cloud. Une checklist opérationnelle par fournisseur clôt l'article.

Pourquoi la détection de compromission cloud diffère du on-premise

La première rupture est structurelle : dans le cloud, le plan de contrôle est exposé sur Internet par conception. Un acteur malveillant qui obtient une clé d'accès AWS ou un jeton de rafraîchissement Entra ID n'a besoin d'aucun accès réseau à votre infrastructure. Il appelle l'API depuis n'importe quel point du globe, et cette requête est indistinguable — au niveau réseau — d'une requête légitime de votre équipe plateforme. Les contrôles hérités du monde on-premise (segmentation, IDS périmétrique, inspection TLS) deviennent structurellement aveugles. Le signal ne se trouve plus dans les paquets mais dans les métadonnées d'appel d'API : qui, quoi, depuis où, avec quelle identité, à quelle fréquence.

La deuxième rupture est l'éphémérité. Une instance EC2 en groupe d'auto-scaling, un conteneur Fargate, une fonction Lambda ou Cloud Run n'existent que le temps d'un traitement. Quand l'analyste demande l'accès à la machine pour une acquisition mémoire, l'objet a déjà été détruit et son disque recyclé. La conséquence opérationnelle est brutale : ce qui n'a pas été journalisé en amont n'existera jamais. Contrairement au on-premise, où l'on peut revenir sur un disque saisi des semaines plus tard, le forensics cloud est un exercice de récolte anticipée. La stratégie de journalisation devient un contrôle de sécurité de premier rang, pas une commodité d'exploitation.

La troisième rupture tient au modèle de responsabilité partagée. Le fournisseur vous donne accès à ce qu'il décide de vous exposer. Vous ne verrez jamais l'hyperviseur, rarement le réseau sous-jacent, et le niveau de détail des journaux varie considérablement selon le service. Un appel s3:GetObject n'est pas journalisé par défaut dans CloudTrail : il relève des événements de données, facturés à part et désactivés à la création du compte. Des milliers d'organisations découvrent au moment de l'incident qu'elles sont incapables de prouver quels objets ont été lus. Le même piège existe sur Azure, où les journaux de plan de données d'un compte de stockage nécessitent une configuration de diagnostic explicite, et sur GCP, où les Data Access Logs sont désactivés par défaut hors BigQuery.

La quatrième rupture, enfin, est la vitesse. Une intrusion on-premise moyenne se déploie sur des jours. Une compromission de clé cloud peut aboutir à une exfiltration complète en moins de vingt minutes, parce que l'attaquant automatise : il énumère, il évalue ses droits, il copie. Les campagnes exploitant des identifiants Snowflake volés en 2024, ou la compromission de Capital One en 2019 via une SSRF atteignant le service de métadonnées d'instance, illustrent cette compression temporelle. Un SOC qui travaille sur des lots de journaux à H+24 détecte une exfiltration terminée. Le SIEM doit ingérer les journaux cloud en quasi-temps réel, faute de quoi la détection devient de la constatation.

Indicateurs de compromission (IoC) cloud : CloudTrail, Activity Logs, Cloud Audit Logs

Un indicateur de compromission cloud n'est presque jamais un hachage de fichier ou une adresse IP de commande et contrôle. C'est un motif comportemental dans un journal d'audit. Trois familles d'événements méritent une attention prioritaire : la reconnaissance d'identité, la manipulation de la journalisation elle-même, et la création de persistance par les mécanismes d'authentification.

Sur AWS, CloudTrail enregistre chaque appel d'API du plan de contrôle. Les événements GetCallerIdentity, ListBuckets, DescribeInstances, ListUsers et GetAccountAuthorizationDetails émis en rafale par un même principal constituent la signature classique d'une énumération post-compromission. Le champ userAgent est ici un discriminant précieux : les outils offensifs comme Pacu ou ScoutSuite laissent des empreintes reconnaissables, et un appel émis depuis aws-cli/2.x Python/3.x sur un rôle habituellement utilisé par un SDK applicatif en production est une anomalie forte.

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=GetCallerIdentity \
  --start-time 2026-09-20T00:00:00Z \
  --max-results 50 \
  --query 'Events[].{T:EventTime,U:Username,S:CloudTrailEvent}' \
  --output json

# Recherche des altérations de la journalisation
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=StopLogging
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=DeleteTrail

Les événements StopLogging, DeleteTrail, PutEventSelectors et DeleteFlowLogs doivent déclencher une alerte de sévérité maximale, sans exception ni liste blanche automatique. Un attaquant compétent coupe la télémétrie avant d'agir ; une désactivation de trace est soit une intrusion, soit une erreur d'exploitation grave. Les deux méritent un appel téléphonique.

Sur Azure, la télémétrie est fragmentée entre trois sources qu'il faut corréler manuellement. Les Activity Logs couvrent les opérations sur les ressources ARM. Les journaux Entra ID (sign-in logs et audit logs) couvrent l'authentification et les modifications d'annuaire — c'est là que se détectent les ajouts de méthodes MFA frauduleuses, les créations d'application enregistrée et les octrois de consentement. Les journaux de diagnostic par ressource couvrent le plan de données. Une compromission Azure typique laisse des traces dans les trois, jamais dans une seule.

az monitor activity-log list \
  --start-time 2026-09-20T00:00:00Z \
  --query "[?contains(operationName.value,'roleAssignments/write')].\
{time:eventTimestamp,caller:caller,op:operationName.value,ip:claims.ipaddr}" \
  --output table

# Consentements applicatifs accordés récemment (Entra ID)
az rest --method GET \
  --url "https://graph.microsoft.com/v1.0/auditLogs/directoryAudits?\
\$filter=activityDisplayName eq 'Consent to application'" \
  --query "value[].{t:activityDateTime,who:initiatedBy.user.userPrincipalName}"

Sur GCP, Cloud Audit Logs se décompose en Admin Activity (toujours actif, non désactivable, gratuit), Data Access (désactivé par défaut, à activer explicitement), System Event et Policy Denied. Les indicateurs à privilégier sont SetIamPolicy sur un projet ou une organisation, google.iam.admin.v1.CreateServiceAccountKey — la création d'une clé de compte de service utilisateur est le mécanisme de persistance numéro un sur GCP — et les refus PERMISSION_DENIED en rafale, qui trahissent une énumération aveugle des droits.

gcloud logging read \
  'protoPayload.methodName="google.iam.admin.v1.CreateServiceAccountKey"' \
  --project=mon-projet --freshness=30d --limit=50 \
  --format="table(timestamp, protoPayload.authenticationInfo.principalEmail,
                  protoPayload.resourceName)"

gcloud logging read \
  'protoPayload.status.code=7 AND protoPayload.authenticationInfo.principalEmail!=""' \
  --project=mon-projet --freshness=2d --limit=200 \
  --format="value(protoPayload.authenticationInfo.principalEmail)" | sort | uniq -c | sort -rn

Trois indicateurs transverses méritent enfin une règle dédiée chez les trois fournisseurs : l'usage d'une identité depuis une région cloud jamais employée par l'organisation, l'appel d'API depuis un fournisseur d'hébergement ou un nœud de sortie Tor, et l'écart brutal entre le volume d'appels d'un principal et sa ligne de base des trente derniers jours.

Phases d'une attaque cloud : de la reconnaissance à l'exfiltration

La matrice MITRE ATT&CK Cloud fournit le référentiel commun pour structurer la détection. Traduite en pratique opérationnelle, une intrusion cloud se déroule en cinq temps, chacun produisant une télémétrie caractéristique qu'il faut savoir cartographier sur ses règles de détection.

Accès initial. Quatre vecteurs dominent. Le premier reste l'identifiant valide : clé d'accès commitée dans un dépôt public, variable d'environnement exposée dans un fichier de configuration, secret stocké dans une image de conteneur publiée. Les robots de moissonnage détectent une clé AWS publiée sur GitHub en moins de deux minutes. Le deuxième vecteur est le phishing de jeton — l'attaquant ne vole plus le mot de passe mais le cookie de session ou le jeton de rafraîchissement, contournant ainsi le MFA. Le troisième est l'exploitation applicative aboutissant au service de métadonnées d'instance : une SSRF sur une application web permet d'interroger l'IMDS et d'obtenir les identifiants temporaires du rôle attaché, scénario exact de Capital One en 2019, que la version 2 de l'IMDS avec ses jetons de session atténue sans l'éliminer. Le quatrième est la chaîne d'approvisionnement : une application tierce à laquelle un utilisateur a accordé un consentement OAuth trop large.

Reconnaissance interne. L'attaquant ignore ce qu'il vient d'obtenir. Il appelle sts:GetCallerIdentity, énumère les politiques attachées, liste les dépôts d'objets, les bases de données, les secrets. Cette phase est la plus bruyante du cycle et représente la meilleure fenêtre de détection : l'écart entre le comportement observé et la ligne de base du principal y est maximal. Un rôle applicatif qui n'appelle habituellement que dynamodb:PutItem et se met soudain à faire iam:ListRoles et secretsmanager:ListSecrets est une compromission jusqu'à preuve du contraire.

Escalade de privilèges. Elle emprunte rarement une faille technique. Elle exploite une mauvaise configuration IAM : droit iam:PassRole combiné à ec2:RunInstances permettant d'instancier une machine portant un rôle administrateur ; droit iam:CreatePolicyVersion permettant de réécrire sa propre politique ; sur GCP, le rôle iam.serviceAccountTokenCreator permettant d'usurper un compte de service plus privilégié ; sur Azure, un rôle personnalisé disposant de Microsoft.Authorization/roleAssignments/write, qui équivaut à Propriétaire. La détection passe ici par la corrélation entre un événement de modification de politique et l'identité qui l'émet.

Persistance. L'attaquant sait que la clé initiale sera révoquée. Il crée donc des points d'entrée redondants : nouvel utilisateur IAM avec clé d'accès, rôle assumable depuis un compte externe, clé de compte de service GCP, application enregistrée Azure avec secret client de longue durée, ou modification d'un fournisseur d'identité fédérée. Les campagnes attribuées à Storm-0558 en 2023 ont montré jusqu'où peut aller la persistance par manipulation de jetons.

Actions sur objectifs. Exfiltration massive de données, chiffrement à des fins d'extorsion — le mode opératoire Codefinger observé début 2025 chiffrait des seaux S3 via SSE-C en conservant la clé —, ou détournement de ressources pour du minage de cryptomonnaie, détecté par le pic de dépense avant même d'être détecté par le SOC.

Détection de la latéralisation inter-services cloud

La latéralisation cloud n'est pas un déplacement réseau : c'est un enchaînement d'identités. L'attaquant part d'un principal et emprunte successivement des rôles jusqu'à atteindre la donnée. La primitive centrale sur AWS est sts:AssumeRole. Chaque emprunt produit un événement CloudTrail contenant l'identité source et l'identité cible, ce qui permet de reconstruire le graphe complet de la progression — à condition d'avoir agrégé les traces de tous les comptes de l'organisation dans un puits unique.

# Reconstruire la chaîne d'emprunts de rôles sur 7 jours
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRole \
  --start-time 2026-09-21T00:00:00Z --max-results 200 \
  --query 'Events[].CloudTrailEvent' --output text \
  | jq -r 'fromjson | [.eventTime, .sourceIPAddress,
      .userIdentity.arn, .requestParameters.roleArn] | @tsv'

Les motifs à alerter sont précis : un emprunt de rôle depuis un compte AWS externe non référencé dans la liste des partenaires connus ; une chaîne de plus de deux emprunts successifs en moins d'une minute ; un AssumeRole dont l'adresse IP source diffère de celle du principal d'origine ; et tout emprunt de rôle assorti d'un externalId absent alors que la politique de confiance en prévoyait un.

Sur Azure, la latéralisation emprunte trois routes distinctes. La première est l'identité managée : une machine virtuelle compromise dispose d'une identité affectée, et l'attaquant demande un jeton auprès du point de terminaison de métadonnées pour agir sur les ressources autorisées. La seconde est l'exécution de commande sur machine virtuelle via Microsoft.Compute/virtualMachines/runCommand/action, qui permet d'exécuter du code arbitraire en tant que SYSTEM depuis le plan de contrôle, sans jamais toucher au réseau. La troisième est l'escalade depuis Azure vers Entra ID lorsqu'un administrateur global active la gestion des abonnements, ou inversement via un Automation Account disposant d'une identité privilégiée.

az monitor activity-log list --start-time 2026-09-21T00:00:00Z \
  --query "[?contains(operationName.value,'runCommand')].\
{t:eventTimestamp,caller:caller,res:resourceId,status:status.value}" -o table

Sur GCP, la latéralisation repose massivement sur l'usurpation de compte de service. Un principal disposant de iam.serviceAccounts.getAccessToken sur un compte de service plus privilégié peut générer un jeton et agir sous cette identité. L'événement GenerateAccessToken dans les Data Access Logs est l'indicateur à surveiller, et il n'est visible que si ces journaux sont activés. S'y ajoute l'abus des déclencheurs : déploiement d'une Cloud Function ou d'un job Cloud Build s'exécutant avec un compte de service par défaut aux droits Éditeur sur tout le projet.

gcloud logging read \
  'protoPayload.methodName=~"GenerateAccessToken|SignJwt"' \
  --project=mon-projet --freshness=7d --limit=100 \
  --format="table(timestamp, protoPayload.authenticationInfo.principalEmail,
                  protoPayload.request.name)"

La règle de détection la plus rentable, tous fournisseurs confondus, consiste à modéliser le graphe des identités attendues — quel principal emprunte habituellement quel rôle — et à alerter sur toute arête nouvelle. Les outils de type CIEM automatisent cette construction, mais une requête planifiée dans le SIEM comparant les arêtes du jour à celles des trente jours précédents couvre déjà l'essentiel du besoin.

Surveillance de l'exfiltration S3 / Blob Storage / GCS

Le dépôt d'objets est l'objectif final de la majorité des intrusions cloud, et c'est précisément la zone la plus mal instrumentée. Sur AWS, rappelons-le sans détour : les appels GetObject, PutObject et DeleteObject ne figurent pas dans CloudTrail par défaut. Sans activation explicite des événements de données, une exfiltration de plusieurs téraoctets ne laisse aucune trace exploitable dans le journal d'audit. Le coût de ces événements est réel sur des seaux à fort trafic ; la réponse consiste à cibler par sélecteur avancé les seaux contenant de la donnée sensible plutôt qu'à renoncer.

# Activer les événements de données S3 sur les seaux sensibles
aws cloudtrail put-event-selectors --trail-name org-trail \
  --advanced-event-selectors '[{
    "Name": "S3 data events sur seaux sensibles",
    "FieldSelectors": [
      {"Field":"eventCategory","Equals":["Data"]},
      {"Field":"resources.type","Equals":["AWS::S3::Object"]},
      {"Field":"resources.ARN","StartsWith":["arn:aws:s3:::donnees-clients/"]}
    ]}]'

# Vérifier l'exposition publique et la journalisation d'accès d'un seau
aws s3api get-public-access-block --bucket donnees-clients
aws s3api get-bucket-logging --bucket donnees-clients
aws s3api get-bucket-policy --bucket donnees-clients --output text

Les signaux d'exfiltration à modéliser sont au nombre de cinq. Premièrement, le volume : un principal qui télécharge en une heure davantage d'octets que sa moyenne mensuelle. Deuxièmement, la dispersion : un nombre de clés distinctes lues très supérieur à la normale, signature d'un aws s3 sync récursif. Troisièmement, la destination : trafic sortant vers une adresse hors des plages connues, visible dans les VPC Flow Logs corrélés aux points de terminaison S3. Quatrièmement, la modification de posture : PutBucketPolicy, PutBucketAcl, DeletePublicAccessBlock ou PutBucketReplication — cette dernière étant une technique d'exfiltration élégante, la réplication vers un compte tiers ne générant aucun GetObject. Cinquièmement, le chiffrement non sollicité : des CopyObject massifs avec en-tête SSE-C signalent une extorsion en cours.

Sur Azure, les journaux de plan de données d'un compte de stockage exigent une configuration de diagnostic explicite envoyée vers un espace de travail Log Analytics. Sans elle, seules les opérations ARM sont visibles. Une attention particulière doit porter sur les jetons SAS : un jeton de signature d'accès partagé délégué, de longue durée et de portée large, constitue une porte dérobée d'exfiltration qui survit à la rotation des clés de compte tant que la clé de délégation d'utilisateur n'est pas révoquée.

az monitor diagnostic-settings create --name blob-audit \
  --resource "/subscriptions/$SUB/resourceGroups/rg-data/providers/\
Microsoft.Storage/storageAccounts/stdonnees/blobServices/default" \
  --workspace "/subscriptions/$SUB/resourceGroups/rg-sec/providers/\
Microsoft.OperationalInsights/workspaces/law-soc" \
  --logs '[{"category":"StorageRead","enabled":true},
           {"category":"StorageWrite","enabled":true},
           {"category":"StorageDelete","enabled":true}]'

az storage account show --name stdonnees \
  --query "{public:allowBlobPublicAccess,https:enableHttpsTrafficOnly,\
sharedKey:allowSharedKeyAccess,network:networkRuleSet.defaultAction}"

Sur GCP, les Data Access Logs de Cloud Storage doivent être activés au niveau de la politique IAM d'audit, projet par projet ou au niveau organisation. Les indicateurs clés sont storage.objects.get en volume anormal, storage.setIamPolicy ajoutant allUsers ou allAuthenticatedUsers, et la création d'un job Storage Transfer Service vers un seau externe — technique d'exfiltration qui utilise l'infrastructure du fournisseur et ne produit aucun trafic sortant depuis vos réseaux.

gcloud logging read \
  'resource.type="gcs_bucket" AND protoPayload.methodName="storage.objects.get"' \
  --project=mon-projet --freshness=1d --limit=1000 \
  --format="value(protoPayload.authenticationInfo.principalEmail)" \
  | sort | uniq -c | sort -rn | head -20

gcloud storage buckets get-iam-policy gs://donnees-clients \
  --format="json(bindings)" | grep -E "allUsers|allAuthenticatedUsers"

Outils natifs : AWS GuardDuty, Microsoft Defender for Cloud, Google SCC

Les trois fournisseurs proposent un moteur de détection managé. Aucun ne suffit seul, mais aucun ne devrait être absent d'un socle de sécurité cloud sérieux : ils apportent une intelligence sur les menaces que l'on ne peut pas reproduire en interne.

AWS GuardDuty analyse en continu CloudTrail, les journaux DNS, les VPC Flow Logs et, via ses modules additionnels, les événements de données S3, l'audit Kubernetes EKS, le comportement d'exécution des conteneurs et RDS. Les familles de constats les plus significatives pour un SOC sont UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration, qui signale l'usage d'identifiants de rôle EC2 depuis l'extérieur du réseau AWS — l'indicateur le plus fiable d'un vol de jeton par SSRF —, Discovery:S3/MaliciousIPCaller, CredentialAccess:IAMUser/AnomalousBehavior et Exfiltration:S3/ObjectRead.Unusual. GuardDuty doit être activé dans toutes les régions, y compris celles que vous n'utilisez pas : c'est précisément là que les attaquants déploient leurs instances de minage.

DET=$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text)

aws guardduty list-findings --detector-id "$DET" \
  --finding-criteria '{"Criterion":{"severity":{"Gte":7},
                       "service.archived":{"Eq":["false"]}}}' \
  --query 'FindingIds' --output text | tr '\t' ' ' | head -20

aws guardduty get-findings --detector-id "$DET" --finding-ids "$ID" \
  --query 'Findings[].{type:Type,sev:Severity,res:Resource.ResourceType,
                       actor:Service.Action.AwsApiCallAction.RemoteIpDetails.IpAddressV4}'

Microsoft Defender for Cloud combine une évaluation de posture (Secure Score, recommandations CSPM) et des plans de protection des charges de travail par type de ressource : serveurs, stockage, SQL, conteneurs, App Service. Sa valeur différenciante pour la détection d'identité vient de son intégration avec Microsoft Defender for Cloud Apps et Entra ID Protection, qui remontent les voyages impossibles, les connexions depuis des adresses anonymisées et les jeux d'identifiants divulgués. Les alertes sont exportables en continu vers Microsoft Sentinel ou vers un SIEM tiers.

az security alert list --query "[?properties.status=='Active'].\
{name:properties.alertDisplayName,sev:properties.severity,\
time:properties.timeGeneratedUtc,res:properties.compromisedEntity}" -o table

az security pricing list --query "value[].{plan:name,tier:pricingTier}" -o table

Google Security Command Center agrège Event Threat Detection, qui analyse les Cloud Audit Logs, Container Threat Detection, Virtual Machine Threat Detection pour le minage, et Security Health Analytics pour la posture. Les constats les plus utiles concernent l'ajout de persistance IAM, l'exfiltration BigQuery et les identifiants de compte de service utilisés depuis une adresse anormale.

gcloud scc findings list "organizations/$ORG_ID" \
  --filter='state="ACTIVE" AND severity="HIGH"' \
  --format="table(finding.category, finding.eventTime,
                  finding.resourceName, finding.severity)" --limit=25

Les limites de ces outils doivent être assumées : ils ne connaissent pas votre contexte métier, ils génèrent des faux positifs sur les tâches automatisées légitimes, leur couverture varie selon les services et ils ne corrèlent pas entre fournisseurs. Ils constituent une source d'alertes de qualité, pas une capacité de détection complète. C'est le rôle du SIEM.

SIEM et CSPM : intégration pour la détection multi-cloud

La détection multi-cloud impose un point de convergence. Trois consoles natives que personne ne surveille simultanément ne constituent pas une capacité de détection : l'attaquant qui compromet une identité fédérée traversant AWS et Azure ne sera vu par aucune des deux. La corrélation exige un modèle de données commun.

Le premier chantier est la collecte, et il est plus subtil qu'il n'y paraît. Sur AWS, on agrège les traces de tous les comptes d'une organisation dans un puits centralisé via un trail d'organisation, puis on diffuse vers le SIEM par EventBridge ou par lecture du seau, avec une attention particulière à la latence : une collecte par sondage horaire d'un seau S3 rend impossible toute détection utile. Sur Azure, on exporte Activity Logs, journaux Entra ID et journaux de diagnostic vers un espace de travail Log Analytics, puis vers le SIEM via Event Hub. Sur GCP, on crée un puits de journalisation au niveau de l'organisation vers Pub/Sub, ce qui garantit la capture des projets créés ultérieurement — un puits par projet laisse systématiquement des angles morts.

# AWS : trail d'organisation multi-région vers un puits centralisé
aws cloudtrail create-trail --name org-trail \
  --s3-bucket-name audit-logs-central --is-organization-trail \
  --is-multi-region-trail --enable-log-file-validation
aws cloudtrail start-logging --name org-trail

# GCP : puits d'organisation vers Pub/Sub pour ingestion SIEM
gcloud logging sinks create siem-sink \
  pubsub.googleapis.com/projects/prj-sec/topics/cloud-audit \
  --organization=$ORG_ID --include-children \
  --log-filter='logName:"logs/cloudaudit.googleapis.com"'

Le deuxième chantier est la normalisation. Les trois fournisseurs nomment différemment les mêmes concepts : userIdentity.arn, caller, protoPayload.authenticationInfo.principalEmail désignent tous l'acteur. Un schéma commun — OCSF, ASIM ou un modèle maison — est indispensable pour écrire une règle unique du type « création de crédential persistant par un principal non administrateur » qui s'applique aux trois plateformes. Sans cette normalisation, on maintient trois jeux de règles divergents, et la dette de détection devient ingérable.

Le troisième chantier est le CSPM. La gestion de posture ne détecte pas une intrusion, mais elle alimente la détection de deux manières. D'une part, elle fournit le contexte d'exposition : une alerte concernant un seau accessible publiquement et contenant des données classées confidentielles ne se traite pas comme la même alerte sur un seau d'artefacts publics. D'autre part, la dérive de configuration est elle-même un signal : un contrôle de sécurité qui passe de conforme à non conforme en dehors d'une fenêtre de déploiement est un indicateur de compromission à part entière. L'articulation cible consiste à enrichir chaque alerte du SIEM avec la criticité de la ressource, sa classification de données et sa posture, issues du CSPM. Cette corrélation réduit fortement le volume d'alertes réellement escaladées, ce qui conditionne la soutenabilité du dispositif pour une équipe de détection et réponse de taille humaine.

Enfin, mesurez la couverture plutôt que le nombre de règles. Cartographier ses détections sur la matrice ATT&CK Cloud révèle presque toujours une surreprésentation des techniques d'accès initial et un vide sur la persistance et l'évasion de défense — précisément les phases où le temps de détection décide de l'ampleur de l'incident.

Réponse à incident et forensics cloud

La réponse à incident cloud obéit à une contrainte inversée par rapport au on-premise : les preuves disparaissent d'elles-mêmes. La séquence recommandée est la suivante, et son ordre importe.

Préserver avant de contenir. Avant toute action de remédiation, figer l'état : instantané des disques des instances suspectes, capture mémoire si l'agent le permet, export des journaux d'audit de la période sur un compte forensique séparé, relevé des politiques IAM en vigueur. Sur AWS, aws ec2 create-snapshot puis partage du volume vers le compte d'investigation ; sur Azure, instantané de disque managé ; sur GCP, gcloud compute disks snapshot. Une instance terminée par précipitation est une preuve perdue définitivement.

# Isolement réseau sans destruction de preuve (AWS)
aws ec2 modify-instance-attribute --instance-id i-0abc123 \
  --groups sg-quarantaine-sans-egress
aws ec2 create-snapshot --volume-id vol-0abc123 \
  --description "IR-2026-014 preuve"

# Révocation des sessions actives d'un rôle compromis
aws iam put-role-policy --role-name RoleCompromis \
  --policy-name RevokeOlderSessions \
  --policy-document file:///tmp/revoke-sessions.json

Contenir l'identité avant la machine. Dans le cloud, l'actif compromis n'est presque jamais la machine : c'est l'identité. Isoler une instance sans révoquer les sessions du rôle qu'elle portait laisse l'attaquant pleinement opérationnel, puisqu'il détient déjà les jetons. La révocation des sessions par politique de date, la désactivation des clés d'accès, la révocation des jetons de rafraîchissement Entra ID et la suppression des clés de compte de service GCP doivent précéder toute action sur les ressources de calcul.

# Azure : révoquer toutes les sessions d'un utilisateur compromis
az rest --method POST --url \
  "https://graph.microsoft.com/v1.0/users/$UPN/revokeSignInSessions"

# GCP : lister puis supprimer les clés d'un compte de service
gcloud iam service-accounts keys list \
  --iam-account=sa-app@mon-projet.iam.gserviceaccount.com \
  --managed-by=user
gcloud iam service-accounts keys delete "$KEY_ID" \
  --iam-account=sa-app@mon-projet.iam.gserviceaccount.com

Reconstruire la chronologie. Le journal d'audit est la source primaire. On part de l'identité compromise, on extrait tous ses appels d'API sur la période, on identifie les emprunts de rôle successifs et l'on répète l'opération pour chaque identité dérivée. Les adresses IP source, les agents utilisateurs et les identifiants de session permettent de distinguer l'activité légitime de l'activité malveillante partageant la même identité. L'objectif de cette phase est de répondre à la question qui déclenche les obligations réglementaires : quelles données ont été effectivement lues ?

Éradiquer la persistance. Auditer exhaustivement les utilisateurs et rôles créés sur la période, les politiques de confiance modifiées, les applications enregistrées et consentements accordés, les fournisseurs d'identité fédérée, les fonctions serverless et les règles d'événement planifiées, ainsi que les instantanés et images partagés vers des comptes externes. Un incident cloud clos sans audit de persistance se rouvre sous quinze jours.

Notifier. En cas de données à caractère personnel concernées, l'article 33 du RGPD impose la notification à la CNIL dans les soixante-douze heures. Cette contrainte de délai doit être anticipée dans le plan de réponse, en particulier la capacité à qualifier le périmètre exfiltré — laquelle dépend entièrement des journaux de plan de données activés avant l'incident. Les organisations soumises à NIS2 ont en outre une obligation d'alerte précoce à vingt-quatre heures.

Checklist de détection rapide

Cette checklist est conçue pour être exécutée en moins de deux heures sur un environnement existant, afin d'identifier les angles morts majeurs avant d'engager un chantier de fond. Elle ne remplace pas un audit complet mais elle révèle les défauts les plus fréquemment exploités.

Checklist AWS

Vérifier qu'un trail d'organisation multi-région est actif avec validation d'intégrité des fichiers journaux ; que les événements de données S3 sont activés sur les seaux sensibles ; que GuardDuty est actif dans toutes les régions avec les modules S3, EKS et Runtime Monitoring ; qu'aucun utilisateur IAM ne possède de clé d'accès de plus de quatre-vingt-dix jours ; que le compte racine ne présente aucun usage récent ; que les politiques de confiance des rôles ne contiennent aucun principal générique sans condition ; que les VPC Flow Logs sont activés ; et qu'une alerte existe sur StopLogging, DeleteTrail et PutBucketPolicy.

Checklist Azure

Vérifier que les Activity Logs et les journaux Entra ID (SignInLogs, AuditLogs, NonInteractiveUserSignInLogs) sont exportés vers Log Analytics avec une rétention suffisante ; que les paramètres de diagnostic sont configurés sur les comptes de stockage sensibles ; que Defender for Cloud est activé sur les plans serveurs, stockage et conteneurs ; qu'aucune application enregistrée ne détient de secret client de plus d'un an ; que les consentements applicatifs utilisateurs sont restreints ; que PIM est utilisé pour les rôles privilégiés avec activation à la demande ; et que allowSharedKeyAccess est désactivé sur les comptes de stockage critiques.

Checklist GCP

Vérifier qu'un puits de journalisation au niveau organisation exporte vers Pub/Sub ou BigQuery avec --include-children ; que les Data Access Logs sont activés sur Cloud Storage, BigQuery et Secret Manager ; que Security Command Center est actif avec Event Threat Detection ; qu'aucune clé de compte de service gérée par l'utilisateur ne subsiste hors cas justifié ; qu'aucune liaison IAM ne comporte allUsers ou allAuthenticatedUsers ; que les comptes de service par défaut de Compute et Cloud Build ne disposent pas du rôle Éditeur ; et qu'une alerte couvre SetIamPolicy au niveau projet et organisation.

Questions fréquentes

Combien de temps faut-il conserver les journaux d'audit cloud pour être en mesure d'investiguer ?

Douze mois constituent le minimum défendable, et dix-huit mois sont recommandés pour les environnements réglementés. Les rétentions par défaut sont très inférieures : quatre-vingt-dix jours pour l'historique d'événements CloudTrail, trente jours pour les journaux Entra ID hors licence P1 ou P2, quatre cents jours pour l'Admin Activity de GCP mais trente jours seulement pour les Data Access Logs. Or le délai entre la compromission initiale et sa détection dépasse fréquemment ces fenêtres. La pratique consistant à exporter les journaux vers un stockage objet immuable, avec verrouillage en écriture unique dans un compte distinct disposant de droits séparés, répond à la fois au besoin d'investigation et à la protection contre l'effacement par l'attaquant.

GuardDuty, Defender for Cloud et SCC suffisent-ils à détecter une compromission cloud ?

Non, mais ils constituent un socle indispensable. Ces moteurs apportent une intelligence sur les menaces et des modèles comportementaux que l'on ne peut pas reproduire en interne à coût raisonnable. Leurs limites sont structurelles : ils ignorent votre contexte métier et la criticité réelle de vos ressources, leur couverture de services est inégale, et surtout ils ne corrèlent rien au-delà de leur propre fournisseur. Une intrusion qui débute par un jeton Entra ID détourné et se poursuit sur AWS via une fédération d'identité échappe à chacun d'eux pris isolément. Activez-les partout, puis exportez leurs constats vers un SIEM où ils seront corrélés aux journaux bruts et enrichis du contexte CSPM.

Comment détecter l'exfiltration de données depuis un bucket S3 sans exploser le budget de journalisation ?

Par le ciblage plutôt que par le renoncement. Les sélecteurs d'événements avancés de CloudTrail permettent de n'activer les événements de données que sur les préfixes de seaux contenant de la donnée sensible, identifiés au préalable par une classification — Macie sur AWS, Purview sur Azure, DLP sur GCP. Complétez par trois signaux peu coûteux : les journaux d'accès serveur du seau, les métriques CloudWatch de volume d'octets sortants par seau, et les constats GuardDuty de la famille Exfiltration:S3. Surveillez enfin les configurations de réplication inter-comptes, qui permettent une exfiltration continue sans générer le moindre événement de lecture.

Quelles sont les erreurs les plus fréquentes en réponse à incident cloud ?

La première est de terminer ou de redémarrer les ressources suspectes avant d'en avoir pris un instantané, ce qui détruit irrémédiablement la preuve. La deuxième est de traiter la machine avant l'identité : isoler une instance sans révoquer les sessions du rôle qu'elle portait laisse l'attaquant pleinement opérationnel. La troisième est de clore l'incident après avoir révoqué la clé initiale, sans auditer les mécanismes de persistance créés entre-temps — utilisateurs, rôles de confiance externes, applications enregistrées, clés de compte de service. La quatrième est d'investiguer depuis le compte compromis lui-même, ce qui alerte l'attaquant et pollue les journaux. Menez l'investigation depuis un compte forensique séparé, préparé à l'avance.