Réponse aux Incidents Cloud : AWS, Azure et GCP — Fondamentaux

Pourquoi l'IR Cloud Est Différent

La réponse aux incidents dans les environnements cloud n'est pas simplement un IR traditionnel exécuté sur des machines virtuelles. Le cloud introduit des différences architecturales fondamentales qui modifient la manière dont les investigations sont menées, les preuves collectées et le confinement exécuté. Traiter l'IR cloud comme « la même chose mais à distance » conduit à des preuves manquées, un confinement bâclé et des artefacts forensiques détruits.

L'infrastructure éphémère est la différence la plus perturbatrice. Dans un environnement on-premises, un serveur compromis se trouve sur un rack, disponible pour l'acquisition et l'analyse indéfiniment. Dans le cloud, les instances s'activent et se désactivent avec des groupes d'auto-scaling, les conteneurs s'exécutent quelques minutes avant d'être remplacés, et les fonctions sans serveur s'exécutent en millisecondes. Les preuves dont vous avez besoin peuvent littéralement cesser d'exister entre le moment où vous détectez l'incident et celui où vous commencez votre investigation. L'IR cloud doit être rapide, et idéalement automatisé, pour capturer les preuves avant qu'elles disparaissent.

Les opérations pilotées par API signifient que presque tout ce qu'un attaquant fait — et presque tout ce que vous faites en réponse — est un appel API. Créer une instance, modifier un groupe de sécurité, exfiltrer des données depuis un bucket de stockage, escalader les privilèges via une prise de rôle — ce sont toutes des opérations API qui sont (ou devraient être) journalisées. C'est à la fois un défi et un avantage. Le défi est le volume et la complexité considérables des journaux API. L'avantage est que les environnements cloud peuvent fournir une piste d'audit plus complète que la plupart des environnements on-premises n'en atteignent jamais, si la journalisation est correctement configurée.

L'identité est le périmètre. Dans les environnements traditionnels, la segmentation réseau et les pare-feux définissent les frontières de sécurité. Dans le cloud, IAM est le plan de contrôle principal. Un attaquant disposant de credentials IAM valides peut accéder aux ressources quelle que soit leur localisation réseau. Les investigations d'IR cloud se concentrent donc fortement sur l'identité : quels credentials ont été compromis, quelles autorisations accordaient-ils, quelles actions ont été entreprises et quelles ressources ont été accédées.

La complexité multi-région et multi-compte ajoute une portée d'investigation qui n'existe pas dans les environnements traditionnels. Un seul utilisateur IAM compromis peut avoir accédé à des ressources dans plusieurs régions, plusieurs comptes et plusieurs services. L'investigation doit couvrir l'ensemble de ces éléments — une clé d'accès compromise dans us-east-1 peut avoir été utilisée pour exfiltrer des données d'un bucket dans eu-west-1 et lancer des instances de minage de cryptomonnaies dans ap-southeast-1.

Le Modèle de Responsabilité Partagée

Avant d'investiguer un incident cloud, vous devez comprendre ce dont vous êtes responsable — et ce dont vous ne l'êtes pas. Chaque grand fournisseur cloud opère selon un modèle de responsabilité partagée qui divise les obligations de sécurité entre le fournisseur et le client. La répartition varie selon le type de service :

Infrastructure as a Service (IaaS)

Pour l'IaaS (EC2, Azure VMs, Compute Engine), le fournisseur cloud est responsable de l'infrastructure physique, de l'hyperviseur et du système d'exploitation hôte. Vous êtes responsable de tout ce qui se trouve au-dessus : le système d'exploitation invité, la pile applicative, les données, la gestion des identités, la configuration réseau et les règles de pare-feu. Cela signifie que la forensique au niveau de l'OS (systèmes de fichiers, processus, mémoire) est de votre responsabilité, mais vous ne pouvez pas accéder à l'hyperviseur ou au matériel sous-jacent. L'acquisition de preuves doit être effectuée via des API et des outils in-guest.

Platform as a Service (PaaS)

Pour le PaaS (RDS, Azure App Service, Cloud SQL), le fournisseur gère également le runtime, les middleware et le système d'exploitation. Votre visibilité forensique est limitée aux journaux d'application, aux données et aux accès IAM. Vous ne pouvez pas créer une image du système d'exploitation sous-jacent d'une base de données gérée — vous ne pouvez travailler qu'avec les journaux et les enregistrements d'accès aux données que le service fournit.

Software as a Service (SaaS)

Pour le SaaS (Microsoft 365, Google Workspace, Salesforce), le fournisseur gère tout sauf les données et l'accès des utilisateurs. La portée de votre investigation est limitée aux journaux d'audit, à l'activité des utilisateurs et aux données. Comprendre cette frontière est crucial : vous ne pouvez pas demander un dump mémoire du serveur exécutant votre application SaaS.

Lors d'un incident, vous pourriez avoir besoin de faire appel au support de réponse aux incidents du fournisseur cloud. AWS, Azure et GCP proposent tous un support IR via leurs plans de support entreprise, et certains offrent des équipes IR dédiées pour les incidents majeurs. Sachez comment contacter ces équipes avant qu'un incident ne survienne.

Sources de Journaux Critiques par Fournisseur

La base de l'IR cloud est constituée des données de journalisation. Chaque fournisseur propose un ensemble distinct de services de journalisation, et les noms, formats et configurations par défaut diffèrent considérablement. Assurez-vous que ces services sont activés et que les données sont conservées avant un incident — une activation rétroactive ne génère pas de données historiques.

Amazon Web Services (AWS)

• CloudTrail : Enregistre les appels API dans votre compte AWS. C'est la source de journaux la plus importante pour l'IR AWS. Chaque appel API — qui l'a effectué, depuis où, quand et avec quels paramètres — est journalisé. Assurez-vous que CloudTrail est activé dans toutes les régions (les attaquants opèrent fréquemment dans des régions que vous n'utilisez pas), avec les événements de gestion et éventuellement les événements de données (opérations au niveau des objets Amazon S3, invocations Lambda) activés. Les journaux de piste doivent être livrés dans un bucket Amazon S3 centralisé et immuable avec Object Lock activé pour empêcher toute falsification.
• VPC Flow Logs : Capturent les métadonnées du trafic IP (IP source/destination, port, protocole, octets, action) pour les interfaces réseau de vos VPC. Pas des captures de paquets — uniquement des métadonnées. Activez au niveau du VPC pour une couverture complète. Essentiels pour détecter l'exfiltration de données, les mouvements latéraux et le trafic de commandement et contrôle.
• GuardDuty : Le service de détection de menaces géré d'AWS qui analyse CloudTrail, VPC Flow Logs et les journaux DNS pour générer des résultats pour les activités suspectes — reconnaissance, compromission d'instance, compromission de credentials et exfiltration de données. Les résultats GuardDuty constituent souvent le point de détection initial des incidents cloud.
• S3 Access Logs / S3 CloudTrail Data Events : Enregistrent l'accès aux objets Amazon S3. Essentiels pour investiguer l'exfiltration de données. Les journaux d'accès S3 fournissent des informations détaillées au niveau des requêtes ; les événements de données CloudTrail fournissent des enregistrements au niveau API des opérations GetObject, PutObject et DeleteObject.
• CloudWatch Logs : Agrégation centralisée de journaux pour les journaux d'application, les journaux de fonctions Lambda et les flux de journaux personnalisés. Les instances Amazon EC2 nécessitent l'agent CloudWatch pour transférer les journaux au niveau OS.
• Route 53 DNS Query Logs : Enregistrent les requêtes DNS adressées à Route 53 Resolver. Utiles pour détecter l'exfiltration de données par DNS et les communications C2.

Microsoft Azure

• Azure Activity Log : Enregistre les opérations du plan de contrôle (création, modification, suppression de ressources) dans votre abonnement Azure. Équivalent aux événements de gestion CloudTrail. Conservé 90 jours par défaut — exportez vers un espace de travail Log Analytics ou un compte de stockage pour une conservation plus longue.
• Azure AD Sign-in Logs et Audit Logs (Entra ID) : Enregistrent les événements d'authentification des utilisateurs (connexions réussies et échouées, défis MFA, évaluations d'accès conditionnel) et les modifications de répertoire (création d'utilisateurs, attributions de rôles, enregistrements d'applications). Essentiels pour investiguer la compromission d'identité. Les Azure AD Sign-in Logs incluent des détections de risques — déplacements impossibles, IP anonyme, propriétés de connexion inhabituelles.
• NSG Flow Logs : Journaux de flux des groupes de sécurité réseau, équivalents aux VPC Flow Logs. Enregistrent le trafic autorisé et refusé au niveau du groupe de sécurité réseau. Activez la version 2 pour des champs supplémentaires incluant les octets transférés.
• Microsoft Defender for Cloud : Gestion de la posture de sécurité et détection de menaces. Génère des alertes de sécurité pour les activités suspectes sur les ressources Azure, similaire à GuardDuty.
• Key Vault Audit Logs : Enregistrent l'accès aux secrets, clés et certificats. Essentiels lorsqu'on investigate si des credentials stockés dans Key Vault ont été accédés par une identité compromise.
• Azure Storage Analytics Logs : Enregistrent les opérations de lecture, écriture et suppression sur Azure Storage. Activez les paramètres de diagnostic sur les comptes de stockage pour capturer ces événements.

Google Cloud Platform (GCP)

• Google Cloud Audit Logs — Admin Activity : Enregistrent les opérations administratives (création de ressources, modifications de politique IAM, modifications de configuration). Activés par défaut, ne peuvent pas être désactivés, conservés pendant 400 jours. Équivalent aux événements de gestion CloudTrail.
• Google Cloud Audit Logs — Data Access : Enregistrent les opérations de lecture/écriture de données. Non activés par défaut pour la plupart des services (doivent être explicitement configurés). Peuvent générer un volume élevé — activez sélectivement pour les ressources sensibles. Conservés 30 jours par défaut.
• VPC Flow Logs : Enregistrent les métadonnées du trafic réseau pour les sous-réseaux VPC. Similaires aux AWS VPC Flow Logs. Activez au niveau du sous-réseau. Taux d'échantillonnage et intervalle d'agrégation configurables.
• Cloud DNS Logs : Enregistrent les requêtes DNS. Utiles pour détecter le tunneling DNS et les communications C2.
• Security Command Center : La plateforme de gestion intégrée de la sécurité et des risques de GCP. Le niveau Premium inclut la détection de menaces (Event Threat Detection, Container Threat Detection) qui génère des résultats pour les activités suspectes.

Schémas d'Attaque Spécifiques au Cloud

Les environnements cloud introduisent des vecteurs d'attaque qui n'existent pas dans l'infrastructure traditionnelle. Comprendre ces schémas est essentiel pour une investigation efficace.

• Credentials IAM compromis : Le vecteur d'attaque cloud le plus courant. Les credentials sont exposés via des dépôts de code, du phishing, l'exploitation du service de métadonnées (SSRF vers le service de métadonnées d'instance à 169.254.169.254) ou des pipelines CI/CD compromis. Une fois obtenus, l'attaquant opère avec les autorisations que les credentials accordent — ce qui, dans des environnements avec des politiques IAM trop permissives, peut être dévastateur.
• Buckets de stockage mal configurés : Les buckets Amazon S3 publics, les conteneurs Azure Blob et les buckets GCS continuent d'exposer des données sensibles. L'attaque peut être aussi simple que de lister un bucket accessible publiquement et de télécharger son contenu. Vérifiez les politiques de bucket, les ACL et les paramètres « Block Public Access » (AWS) ou les contrôles équivalents.
• Escalade de privilèges via chaînage de rôles : Un attaquant avec des autorisations limitées découvre qu'il peut assumer un rôle plus privilégié, qui peut assumer un rôle encore plus privilégié, ou créer de nouveaux credentials avec des autorisations élevées. Dans AWS, cela se manifeste par des chaînes sts:AssumeRole. Dans GCP, par des chaînes d'usurpation de comptes de service. L'enregistrement CloudTrail ou du journal d'audit montre le chemin d'escalade.
• Détournement de ressources : Les comptes cloud compromis sont fréquemment utilisés pour lancer des instances de minage de cryptomonnaies. L'attaquant lance les types d'instances les plus grands disponibles dans plusieurs régions. Le premier indicateur est souvent un pic dans le tableau de bord de facturation cloud ou une alerte de facturation. Au moment où vous commencez l'investigation, l'attaquant peut déjà avoir lancé des centaines d'instances.
• Exfiltration de données via snapshot ou export : Plutôt que de télécharger des données via des connexions réseau (ce qui pourrait déclencher des alertes DLP ou de journaux de flux), les attaquants peuvent partager un snapshot EBS, un snapshot RDS ou un bucket de stockage avec un compte externe qu'ils contrôlent. C'est une opération API, pas un transfert réseau — elle n'apparaît que dans CloudTrail ou les journaux équivalents, pas dans VPC Flow Logs.
• Mouvement latéral via comptes de service : Les charges de travail cloud se voient attribuer des comptes de service ou des profils d'instance avec des rôles IAM. Compromettre une charge de travail donne à l'attaquant accès aux autorisations du rôle — qui incluent souvent l'accès à d'autres services cloud, bases de données, stockage et gestionnaires de secrets.

Confinement dans le Cloud

Les stratégies de confinement cloud diffèrent fondamentalement des approches on-premises. Vous ne pouvez pas déconnecter physiquement un serveur. Vous ne pouvez pas marcher jusqu'à un rack et débrancher un câble réseau. Tout se fait via des appels API, et chaque action doit être soigneusement considérée pour son impact sur la préservation des preuves.

Confinement d'Identité

Pour les credentials IAM compromis, le confinement se concentre sur la révocation des accès tout en préservant la piste d'audit :

• Révoquer les sessions actives : Dans AWS, attachez une politique inline qui refuse toutes les actions pour les sessions émises avant l'heure actuelle (en utilisant la clé de condition aws:TokenIssueTime). Dans Azure, révoquez tous les jetons d'actualisation pour l'utilisateur compromis via Entra ID. Dans GCP, révoquez les jetons OAuth pour le compte de service.
• Rotation des credentials : Désactivez et remplacez les clés d'accès (ne supprimez pas — l'ID de clé est nécessaire pour la corrélation CloudTrail). Réinitialisez les mots de passe. Générez de nouvelles clés de compte de service.
• Restreindre les politiques IAM : Appliquez une politique de tout-refus à l'entité compromise. Ne supprimez pas l'utilisateur ou le rôle — cela détruit l'historique des politiques IAM et brise la piste d'audit. Attachez plutôt une politique restrictive qui remplace toutes les autorisations.
• Examiner et supprimer les mécanismes de persistance : Vérifiez les clés d'accès créées par l'attaquant, les rôles assumés, les configurations de fédération, les applications OAuth et les clés de compte de service qui fournissent des chemins d'accès alternatifs.

Confinement Réseau

• Modification du groupe de sécurité : Remplacez le groupe de sécurité de l'instance par un groupe de sécurité isolé qui n'autorise aucun trafic entrant ou sortant (sauf depuis l'adresse IP de votre équipe d'investigation forensique). Dans AWS, notez que les modifications du groupe de sécurité prennent effet immédiatement mais ne terminent pas les connexions existantes — vous devrez peut-être redémarrer l'interface réseau.
• ACL réseau : Appliquez des règles de refus au niveau du sous-réseau pour un isolement plus large. Les NACL sont sans état et prennent effet immédiatement, y compris pour les connexions existantes.
• Règles WAF : Si le vecteur d'attaque est une application web, déployez des règles WAF pour bloquer les adresses IP de l'attaquant ou les schémas de requêtes malveillantes pendant que l'investigation progresse.

Confinement de Calcul

Le principe crucial pour le confinement de calcul est : effectuez un snapshot avant d'agir, et ne terminez jamais une instance que vous n'avez pas préservée.

• Créer des snapshots de disque : Avant toute action de confinement, effectuez un snapshot de tous les volumes attachés à l'instance compromise. Cela préserve l'état du système de fichiers au moment de l'investigation. Dans AWS, utilisez create-snapshot pour chaque volume EBS. Dans Azure, créez un snapshot de disque. Dans GCP, créez un snapshot de disque persistant.
• Capturer les métadonnées de l'instance : Enregistrez la configuration de l'instance, les groupes de sécurité, le rôle IAM, les données utilisateur, les tags et les interfaces réseau. Ces métadonnées peuvent changer pendant le confinement ou la remédiation et ne peuvent pas être récupérées ultérieurement.
• Isoler, ne pas terminer : Déplacez l'instance vers un VPC ou sous-réseau de quarantaine sans accès Internet et sans accès aux autres ressources de production. Ne stoppez pas ou ne terminez pas l'instance — les preuves volatiles (processus en cours, connexions réseau, mémoire) sont perdues lorsque l'instance s'arrête. Si l'acquisition de mémoire est nécessaire, installez un outil d'acquisition de mémoire (comme LiME pour Linux) et capturez le dump mémoire avant de stopper l'instance.

Confinement du Stockage

• Activer le versionnement : Si ce n'est pas déjà fait, activez le versionnement sur les buckets de stockage compromis pour empêcher l'attaquant de supprimer définitivement des preuves.
• Restreindre les politiques d'accès : Modifiez les politiques de bucket pour refuser tout accès sauf depuis les adresses IP et identités IAM de l'équipe d'investigation.
• Activer Object Lock : Pour les buckets Amazon S3 contenant des preuves critiques, activez Object Lock en mode de conformité pour empêcher la suppression ou la modification, même par le compte root.

Acquisition de Preuves

L'acquisition de preuves dans le cloud fait face à des défis uniques qui exigent une préparation proactive. Vous ne pouvez pas activer la journalisation rétrospectivement, prolonger la conservation ou récupérer des instances terminées.

Préparation Avant l'Incident

• Activez la journalisation partout, avant d'en avoir besoin. CloudTrail dans toutes les régions (y compris les régions que vous n'utilisez pas). VPC Flow Logs sur tous les VPC. Journalisation des requêtes DNS. Journaux d'audit d'accès aux données sur les ressources sensibles. Services de sécurité du fournisseur cloud (GuardDuty, Defender, SCC). Le constat post-incident le plus courant est « le journal dont nous avions besoin n'était pas activé ».
• Centralisez et protégez le stockage des journaux. Envoyez tous les journaux vers un emplacement de stockage centralisé et immuable — un bucket Amazon S3 avec Object Lock, un espace de travail Log Analytics avec conservation immuable, ou un bucket GCS avec une politique de conservation. Utilisez un compte séparé et restreint (un compte « sécurité » ou « archive de journaux ») qui n'est pas accessible depuis l'environnement de production. Si l'attaquant compromet votre compte de production mais pas votre archive de journaux, vos preuves sont préservées.
• Prolongez les périodes de conservation par défaut. La conservation par défaut pour de nombreux journaux cloud est de 90 jours ou moins. De nombreuses violations ne sont pas détectées pendant des mois. Configurez des périodes de conservation d'au moins 365 jours pour les journaux pertinents en matière de sécurité. Le coût du stockage des journaux est négligeable par rapport au coût d'une investigation de violation avec des preuves manquantes.
• Pré-déployez les rôles et accès IR. Créez des rôles IAM IR dédiés avec accès break-glass aux services et ressources pertinents pour l'investigation. Ces rôles doivent être dormants pendant les opérations normales et activés uniquement lors d'incidents. Documentez le processus d'activation. Testez-le avant d'en avoir besoin.

Collecte Pendant l'Incident

Lors de la collecte de preuves pendant un incident actif, suivez cet ordre de priorité pour capturer d'abord les preuves les plus volatiles :

1. Mémoire de l'instance en cours d'exécution — la plus volatile, perdue à l'arrêt/la terminaison
2. État réseau de l'instance en cours d'exécution — connexions actives, ports en écoute
3. État des processus de l'instance en cours d'exécution — listes de processus, fichiers ouverts
4. Snapshots de disque — persistants mais pouvant être modifiés par l'attaquant
5. Journaux API cloud — persistants si correctement configurés et conservés
6. Politiques et configurations IAM — peuvent être modifiées pendant l'incident
7. Configurations réseau — groupes de sécurité, NACL, tables de routage

Pour chaque élément de preuve collecté, enregistrez une chaîne de custody : ce qui a été collecté, quand, par qui, depuis où et comment. Utilisez des hachages cryptographiques (SHA-256) pour vérifier l'intégrité. Stockez les preuves dans un emplacement de stockage dédié, contrôlé en accès et immuable, séparé de l'environnement compromis.

Boîte à Outils IR Cloud

Un écosystème croissant d'outils soutient la réponse aux incidents cloud. Constituer votre boîte à outils avant un incident est essentiel — vous ne voulez pas évaluer des outils pendant une crise.

AWS

• AWS IR Playbooks (aws-incident-response-playbooks) : Playbooks open-source couvrant les scénarios d'incidents AWS courants — credentials IAM compromis, buckets Amazon S3 exposés, instances Amazon EC2 compromises.
• Prowler : Outil d'évaluation de sécurité open-source qui évalue votre environnement AWS par rapport à des centaines de vérifications basées sur les benchmarks CIS, PCI-DSS et les meilleures pratiques AWS. Utile pour identifier les mauvaises configurations qui ont permis l'attaque.
• ScoutSuite : Outil d'audit de sécurité multi-cloud qui collecte des données de configuration depuis AWS, Azure et GCP et identifie les risques de sécurité. Génère un rapport complet de votre posture de sécurité cloud.
• CloudTrail Lake : Le service de requête CloudTrail géré d'AWS qui permet l'analyse SQL des événements CloudTrail. Utile pour les requêtes complexes sur de grands volumes de données d'audit pendant les investigations.

Azure

• AzureHound : Outil open-source pour cartographier les relations Azure AD et Azure Resource Manager, utile pour comprendre les chemins d'escalade de privilèges et les opportunités de mouvement latéral.
• Microsoft Incident Response tools : L'équipe IR de Microsoft utilise et documente publiquement des outils pour l'investigation Azure, y compris des requêtes KQL pour Sentinel et Log Analytics.
• Azure Resource Graph : Permet d'interroger les configurations de ressources dans plusieurs abonnements. Utile pour évaluer rapidement la portée d'un incident dans un grand environnement Azure.

GCP

• Security Command Center (Premium) : Fournit la détection de menaces (Event Threat Detection, Container Threat Detection), l'analyse de vulnérabilités et l'inventaire des actifs. L'espace de travail d'investigation prend en charge les requêtes forensiques sur les journaux d'audit.
• GCP Policy Analyzer : Analyse les politiques IAM pour déterminer quelles identités ont accès à quelles ressources. Essentiel pour comprendre le rayon d'action d'un compte de service compromis.

Multi-Cloud

• Steampipe : Outil open-source qui expose les API cloud sous forme de tables SQL, permettant des requêtes SQL sur AWS, Azure, GCP et des dizaines d'autres services cloud. Puissant pour les requêtes d'investigation multi-cloud.
• CloudQuery : Inventaire d'actifs cloud open-source qui synchronise la configuration cloud et les données d'audit vers une base de données pour analyse. Utile pour construire un inventaire interrogeable de votre environnement cloud.
• Cartography : Outil open-source de Lyft qui crée une base de données graphe de votre infrastructure cloud, cartographiant les relations entre ressources, identités et chemins réseau. Indispensable pour comprendre les chemins de mouvement latéral et l'analyse du rayon d'action.

Construire la Préparation à l'IR Cloud

Les organisations qui répondent efficacement aux incidents cloud sont celles qui se sont préparées avant l'incident. La préparation à l'IR cloud n'est pas un projet ponctuel — c'est une pratique continue qui doit évoluer à mesure que votre environnement cloud grandit et change.

• Activez la journalisation de manière exhaustive. S'il y a une action que vous prenez après avoir lu cet article, faites-en celle-ci : auditez chaque compte cloud et assurez-vous que toute la journalisation pertinente en matière de sécurité est activée, centralisée et conservée pendant au moins 365 jours. Cette seule étape a plus d'impact sur votre capacité IR que toute autre.
• Maintenez des diagrammes d'architecture cloud. Lors d'un incident, les intervenants doivent rapidement comprendre l'environnement — quels comptes existent, quels services sont déployés, comment ils se connectent, où se trouvent les données sensibles. Des outils automatisés comme CloudQuery, Steampipe ou les inventaires natifs d'actifs cloud peuvent générer des cartes d'architecture à jour.
• Pré-déployez la collecte automatisée de preuves. Écrivez et testez des scripts qui capturent automatiquement les snapshots de disque, les métadonnées d'instance, les dumps mémoire et les exports de journaux. Lorsqu'un incident survient, la collecte manuelle de preuves est trop lente pour les environnements éphémères. L'automatisation garantit une collecte cohérente, complète et opportune.
• Organisez des exercices de simulation spécifiques au cloud. Les exercices de simulation traditionnels supposent souvent une infrastructure on-premises. Concevez des exercices qui testent spécifiquement la capacité de votre équipe à investiguer dans des environnements cloud — credentials IAM compromis, exposition de buckets publics, minage de cryptomonnaies dans des régions inutilisées, mouvement latéral inter-comptes.
• Établissez les contacts IR des fournisseurs cloud. Sachez comment contacter l'équipe IR de sécurité de votre fournisseur cloud avant d'en avoir besoin. Pour AWS, c'est l'AWS Customer Incident Response Team (CIRT). Pour Azure, c'est Microsoft DART. Pour GCP, c'est l'équipe Google Cloud Incident Response. Comprenez quel support votre niveau de contrat vous donne droit.

« Dans l'IR cloud, le processus de réponse aux incidents commence des mois avant l'incident. La journalisation que vous activez aujourd'hui, la conservation que vous configurez aujourd'hui et les rôles IR que vous pré-déployez aujourd'hui déterminent si vous pouvez investiguer efficacement lorsqu'une violation survient. »

Les environnements cloud changent fondamentalement la pratique de la réponse aux incidents, mais les principes fondamentaux restent les mêmes : préparez-vous à l'avance, détectez rapidement, confinement décisif, préservez soigneusement les preuves et apprenez de chaque incident. Les organisations qui traitent l'IR cloud comme une discipline distincte — et non comme une réflexion après coup greffée à leur programme IR existant — sont celles qui navigueront les incidents cloud avec la rapidité et la précision que ces environnements exigent.