Reponse aux incidents dans le cloud AWS : ou regarder d'abord

Quand une alerte se declenche dans un compte AWS, la difference entre une enquete de deux heures et une de deux semaines tient a savoir ou regarder d'abord. La reponse aux incidents dans le cloud n'est pas comme enqueter sur un portable ou un serveur local : il n'y a pas de disque a imager au sens classique, le plan de controle est une API, et la preuve la plus importante est souvent une entree de log qui expire si vous n'avez pas active la journalisation a l'avance. Ce guide s'adresse aux defenseurs. Le but est de comprendre la surface d'attaque pour detecter l'abus et se retablir en securite, pas d'apprendre a quiconque a s'introduire. Nous parcourrons la telemetrie AWS qui compte, les signaux qui separent le bruit d'une vraie intrusion, et comment contenir les degats sans detruire les preuves dont vous avez besoin.

Pourquoi la reponse aux incidents cloud est differente#

Dans un environnement classique, vous repondez a un hote : vous l'isolez, capturez la memoire et imagez le disque. Sur AWS, l'objet principal de l'enquete est le compte et ses identites. Un attaquant qui obtient une credential valide peut agir depuis n'importe ou dans le monde via la meme API que vous, et ses actions paraissent syntaxiquement identiques a une administration legitime. Lors d'une compromission du plan de controle, il n'y a pas de malware a trouver, seulement une sequence d'appels d'API. Cela deplace le centre de gravite de l'enquete des binaires et des fichiers vers l'identite, les droits et les logs d'audit. Cela signifie aussi que la preparation est decisive : les preuves que vous pourrez recueillir apres coup sont exactement celles que vous avez configurees avant l'incident. Si la journalisation a l'echelle de l'organisation etait desactivee, la reconstruction possible est fondamentalement limitee.

Se preparer avant l'incident : une preparation qui paie#

La preparation est le controle le moins cher que vous acheterez jamais. Avant que quoi que ce soit n'arrive, confirmez qu'un trail CloudTrail multi-region et au niveau de l'organisation est active et livre vers un compte de journalisation dedie, en ecriture seule, que les repondeurs peuvent lire mais que les comptes de service ne peuvent pas supprimer. Activez GuardDuty sur toutes les regions et tous les comptes, activez Config pour enregistrer l'etat des ressources dans le temps, et assurez-vous que les VPC Flow Logs et les logs de service pertinents (journalisation d'acces S3, logs de load balancer, journalisation des requetes DNS via Route 53 Resolver) sont captures de maniere centralisee. Etablissez des roles de secours avec une MFA forte et documentez qui peut les assumer. Un runbook court et repete qui nomme les emplacements des logs, les etapes d'isolement et les contacts d'escalade fera gagner plus de temps lors d'un vrai evenement que n'importe quel outil.

Les sources de logs AWS essentielles sur lesquelles vous vous appuierez#

Quatre sources portent la plupart des enquetes cloud. CloudTrail est le log d'audit du plan de controle : chaque appel d'API, qui l'a fait, depuis quelle IP et identite, et s'il a reussi. GuardDuty est un detecteur gere qui correle les donnees CloudTrail, DNS et flux en constats tels que l'exfiltration de credentials ou un usage anormal de l'API. VPC Flow Logs enregistrent les conversations reseau au niveau de l'ENI, la ou vous reconstruisez le mouvement lateral et la sortie de donnees. Config vous donne une chronologie de l'aspect d'une ressource a chaque instant, inestimable pour prouver quand un groupe de securite a ete ouvert ou une politique modifiee. Autour d'elles se trouvent des logs specifiques aux services (S3, RDS, Lambda, CloudFront, WAF) qui ajoutent du contexte sur les charges de travail impliquees.

Ou regarder d'abord : CloudTrail#

CloudTrail est presque toujours la premiere etape. Commencez par pivoter sur l'identite de l'alerte et posez trois questions : qu'a fait ce principal, depuis ou, et quand le comportement a-t-il change. Filtrez sur les valeurs d'eventName qui indiquent une reconnaissance ou des tentatives d'escalade, et pretez une attention particuliere aux evenements du plan de gestion. Les evenements a fort signal pour une compromission incluent des changements d'identite et de confiance, comme CreateUser, CreateAccessKey, AttachUserPolicy, PutUserPolicy, UpdateAssumeRolePolicy et CreateLoginProfile. Surveillez les enregistrements ConsoleLogin sans MFA, un GetCallerIdentity immediatement suivi d'appels de listage large, et les pics de resultats AccessDenied qui revelent un acteur sondant les permissions. Correlez l'IP source, le user agent et si les appels sont venus par des credentials de role temporaires, ce qui indique si une access key ou un role assume a ete abuse.

Signaux d'identite et d'acces#

Comme l'identite est le champ de bataille, investissez dans la vue des droits. Enumerez les utilisateurs, roles et access keys IAM recemment crees ou modifies et comparez-les a vos registres de changement. Une access key toute neuve sur un compte de service, une politique de confiance de role qui autorise soudain un compte externe, ou une politique en ligne accordant iam:* sont de forts indicateurs d'un attaquant etablissant un acces durable. Les constats GuardDuty des familles UnauthorizedAccess, CredentialAccess et Persistence meritent un tri immediat. IAM Access Analyzer aide a reperer les ressources devenues accessibles depuis l'exterieur du compte. Tout du long, rappelez-vous que l'automatisation legitime cree aussi des keys et des roles, donc le signal est l'ecart par rapport a la reference, pas l'action isolee.

Telemetrie reseau et du plan de donnees#

Une fois que vous comprenez ce qu'a fait l'identite, suivez les donnees. Les VPC Flow Logs vous laissent voir quelles instances ont parle a quels endpoints et combien d'octets ont circule, afin de distinguer le trafic de routine d'une sortie massive vers une destination inconnue. Les logs de requetes DNS revelent frequemment des domaines de commande et controle ou de staging que les donnees de flux par IP masquent derriere des CDN. Cote stockage, les logs d'acces serveur S3 et les data events CloudTrail pour S3 montrent des lectures au niveau objet : une serie soudaine d'appels GetObject sur un bucket entier, ou un ListBuckets suivi de telechargements cibles, est la forme classique de l'exfiltration. Pour les bases de donnees, examinez les logs RDS et tout audit de requetes que vous avez active. La question a laquelle vous repondez est simple et lourde de consequences : des donnees sont-elles sorties et, si oui, lesquelles et combien.

Transformer les signaux en detections#

Une chasse efficace consiste a ecrire les questions sous forme de requetes reproductibles. Avec CloudTrail dans Athena ou votre SIEM, construisez des detections pour les connexions console depuis de nouveaux pays ou ASN, pour les appels d'API dont le user agent ne correspond pas a votre outillage connu, pour tout usage du compte root et pour la desactivation de services de securite comme StopLogging, DeleteTrail, DeleteFlowLogs ou DisableSecurityHub. Alertez sur les appariements vus pour la premiere fois de principal et region, car les attaquants operent souvent dans des regions que vos equipes n'utilisent jamais. Classez les constats par rayon d'impact : un changement sur une identite pouvant assumer d'autres roles compte plus qu'un seul appel refuse. Ajustez de maniere agressive pour que les alertes qui reveillent une personne soient celles qui le justifient vraiment.

Containment sans detruire les preuves#

La containment dans le cloud est rapide, ce qui est a la fois un cadeau et un danger. Vous pouvez revoquer une session, desactiver une access key ou detacher une politique en quelques secondes, mais si vous supprimez le role compromis ou terminez l'instance, vous risquez d'effacer des preuves non encore recueillies. La sequence preservant les preuves est d'abord de faire un snapshot et de preserver : prenez des snapshots EBS des volumes affectes, capturez les metadonnees de l'instance et exportez les plages de logs pertinentes vers votre stockage de dossier. Puis contraignez l'identite en attachant un deny explicite ou en revoquant les sessions plutot qu'en supprimant le principal, et isolez le compute en le deplacant dans un groupe de securite de quarantaine sans sortie. Faites tourner les credentials exposees et invalidez les tokens temporaires. Ce n'est qu'apres la preservation et la containment que vous passez a l'eradication et reconstruisez depuis une infrastructure as code connue et saine.

Pieges frequents#

Plusieurs erreurs reviennent. Les equipes decouvrent pendant l'incident que CloudTrail etait mono-region ou ne livrait jamais vers un compte isole, si bien que les actions de l'attaquant dans une autre region sont invisibles. Les repondeurs terminent des instances par rapidite et perdent des artefacts de memoire et de disque. Les enqueteurs se fient aux horodatages d'un seul log sans correler les horloges entre sources. On poursuit un seul appel d'API malveillant et on manque la persistance que l'attaquant a plantee trois etapes plus tot, comme une access key oubliee ou une confiance de role modifiee. Et une erreur evitable frequente est de corriger le symptome puis de ne pas faire tourner chaque credential que l'acteur a pu toucher, ce qui invite au reentree immediat. Inscrivez ces lecons dans le runbook pour que le prochain repondeur ne les reapprenne pas sous pression.

Checklist blue team#

Utilisez ceci comme sequence de depart. 1. Confirmez le perimetre : quels comptes, regions et identites sont impliques. 2. Preservez d'abord : exportez les plages CloudTrail, snapshotez les volumes, capturez les metadonnees d'instance. 3. Reconstruisez la chronologie de l'identite depuis CloudTrail, en vous concentrant sur les changements IAM et de confiance. 4. Tirez les constats GuardDuty et correlez avec les logs de flux et DNS. 5. Determinez l'impact sur les donnees a partir des data events S3 et du volume de sortie. 6. Contenez avec des politiques de deny, la revocation de sessions et des groupes de securite de quarantaine, pas par suppression. 7. Faites tourner chaque credential potentiellement exposee et invalidez les tokens temporaires. 8. Eradiquez et reconstruisez depuis l'infrastructure as code. 9. Documentez la chronologie et reinjectez les detections dans votre supervision.

FAQ : combien de temps les logs AWS sont-ils conserves par defaut ?#

Cela depend du service et de votre configuration. L'historique des evenements de la console CloudTrail est conserve 90 jours, mais cela ne remplace pas un trail durable livrant vers S3, que vous controlez et devriez conserver selon votre politique. Les constats GuardDuty, les VPC Flow Logs et les logs de service ont chacun leur propre retention que vous fixez. C'est precisement pourquoi la preparation compte : si vous dependez de l'historique de console par defaut, une enquete qui commence tard peut trouver les premieres preuves deja disparues. Configurez une livraison de logs durable et resistante a l'alteration avant d'en avoir besoin.

FAQ : dois-je imager une instance EC2, ou est-ce obsolete dans le cloud ?#

Les artefacts volatils et de disque comptent toujours quand une charge de travail est compromise, donc l'imaging n'est pas obsolete pour les intrusions au niveau de l'hote. L'approche preservant les preuves est de prendre un snapshot EBS du volume affecte et, quand c'est faisable, de capturer la memoire avant d'arreter l'instance, puis d'attacher le snapshot a une station forensique pour une analyse hors ligne. Ce qui change dans le cloud, c'est que pour une compromission purement du plan de controle il peut n'y avoir aucun hote a imager ; l'enquete vit entierement dans CloudTrail et les registres d'identite. Adaptez la collecte a la nature de l'incident plutot que d'appliquer une seule habitude partout.

Conclusion#

La reponse aux incidents cloud recompense la preparation et la discipline. Les comptes qui se retablissent vite sont ceux qui ont active une journalisation a l'echelle de l'organisation et resistante a l'alteration avant un incident, qui savent que CloudTrail, GuardDuty, VPC Flow Logs et Config sont les quatre piliers, et qui contiennent les menaces sans incinerer les preuves. Traitez l'identite comme le champ de bataille principal, suivez les donnees pour repondre si quelque chose est sorti, et preservez toujours avant d'agir. Integrez ces etapes dans un runbook repete, mesurez a quelle vitesse vous reconstruisez une chronologie d'identite, et continuez a reinjecter ce que vous apprenez dans les detections. Bien menee, la reponse cloud transforme une alerte effrayante en une procedure methodique et reproductible.