Analyse Cloud : détection des attaquants utilisant des identifiants valides

cloud les plus graves de ces deux dernières années n’ont pas commencé par malware. Elles ont commencé par une connexion. Les attaquants sont parvenus à accéder au système grâce à des identifiants valides ou à des jetons OAuth autorisés ; ils ont effectué des appels correctement formés vers des interfaces de programmation d’applications (API) légitimes, sans laisser de trace anormale pouvant être détectée par une signature. C’est à cette réalité que répond l’analyse cloud . Ce guide définit précisément ce terme, explique le fonctionnement du pipeline d’analyse, passe en revue deux cas d’intrusion emblématiques pour montrer pourquoi les signatures ne se déclenchent pas, et présente la mise en œuvre de cette pratique sur Amazon Web Services (AWS), Azure et Google Cloud y compris les aspects économiques de la télémétrie et l’alignement des cadres techniques, que la plupart des explications omettent.

Qu'est-ce que l'analyse cloud ?

L'analyse Cloud consiste à appliquer des techniques d'analyse de détection aux données de télémétrie cloud — journaux d'audit du plan de contrôle, événements liés aux identités et aux jetons, modèles d'appels d'API, ainsi que données sur les charges de travail et les flux — afin de mettre en évidence le comportement des attaquants. Elle se distingue de cloud intelligence cloud , de tout produit individuel de gestion des informations et des événements de sécurité (SIEM), ainsi que des contrôles de l'état de sécurité au repos effectués dans le cadre de la gestion de la posture cloud (CSPM).

Chaque terme voisin répond à une question différente. La pratique plus large qu’AWS définit comme « l’analyse de sécurité » — qui consiste à collecter et analyser des données de sécurité pour détecter les menaces — devient « l’analyse cloud » lorsque la télémétrie elle-même est cloud et que les comportements analysés concernent des identités et des API plutôt que des terminaux. Cette discipline constitue la couche de détection cloud , aux côtés des contrôles de prévention et de posture. Il ne s’agit en aucun cas d’analyse métier, même si les deux partagent des pipelines de données.

Les données de 2026 expliquent pourquoi cette discipline est désormais considérée comme une discipline à part entière. Dans le cadre des missions de réponse aux incidents et de détection gérée des menaces menées par Mandiant au second semestre 2025 — une analyse indépendante des plateformes concernant les principales intrusions cloud les services SaaS (Software-as-a-Service) —, la compromission d’identités était à l’origine de 83 % des cas, les attaquants ont ciblé des données dans 73 % des cas, et l’exploitation de vulnérabilités ne représentait que 2 % (Threat Horizons, premier semestre 2026). Il convient de garder à l’esprit ces limites de champ d’application : ces chiffres décrivent les intrusions ayant fait l’objet d’une enquête, et non l’ensemble des alertes chez chaque client.

Le paysage global des violations de données présente un visage différent, et la classification des victimes revêt une importance particulière. Le rapport 2026 de Verizon sur les enquêtes relatives aux violations de données (DBIR) a révélé que l’exploitation de vulnérabilités était à l’origine de 31 % des violations — dépassant pour la première fois en 19 ans le vol d’identifiants —, tandis que l’implication de tiers a grimpé à 48 %, soit une hausse de 60 % par rapport à l’année précédente (Verizon DBIR 2026). M-Trends 2026, qui constitue également un ensemble de données couvrant tous les environnements, a estimé la durée médiane de présence des intrus à l’échelle mondiale en 2025 à 14 jours, contre 11 auparavant, et a révélé que les exploits constituaient le principal vecteur d’attaque pour la sixième année consécutive, avec 32 % des cas (M-Trends 2026). Lues conjointement, ces données indiquent clairement une chose : si les exploits sont en tête pour l’ensemble des violations, l’usurpation d’identité domine quant à elle dans les intrusions majeures cloud les services SaaS. L’usurpation d’identité est précisément ce que les signatures de surface ne peuvent pas détecter.

Analyse Cloud vs cloud , SIEM et CSPM

C'est là la nuance que la plupart des explications omettent, et qui change la donne en matière d'achats et de développement. Cloud répond à des questions métier — utilisation, chiffre d'affaires, comportement des produits — via des pipelines de business intelligence. Un SIEM est à la fois un produit et une architecture, un environnement où le contenu de détection peut s'exécuter. Le CSPM évalue la configuration au repos — compartiments publics, rôles dotés d'autorisations excessives — avant même l'apparition d'un attaquant. L’analyse Cloud détecte le comportement actif des attaquants dans cloud au fur et à mesure qu’il se déroule. Le tableau ci-dessous présente les quatre éléments séparément.

Quatre termes souvent confondus : l'analyse cloud détecte les comportements, cloud éclaire les décisions métier, un SIEM agrège les journaux, et le CSPM vérifie la posture de sécurité des données au repos.

Comment fonctionne l'analyse cloud ?

L'analyse Cloud transforme les volumes importants cloud en détections hiérarchisées et basées sur le comportement. Le pipeline est cohérent d'un fournisseur à l'autre, même lorsque les noms des journaux diffèrent, et se décompose en cinq étapes :

1. Collecter des données cloud sur l'ensemble des fournisseurs, des comptes et des charges de travail.
2. Normaliser et enrichir les événements en y associant des informations contextuelles sur l'identité, les actifs et les menaces.
3. Comportement normal de référence pour chaque identité humaine et non humaine.
4. Mettre en corrélation les événements et appliquer l'analyse comportementale à l'ensemble des sources.
5. Signaler les écarts significatifs et les classer par ordre de priorité en fonction du risque.

‍

‍

La matière première est la télémétrie « cloud ». Les journaux d’audit du plan de contrôle — AWS CloudTrail, Google Cloud Logs, ainsi que les journaux de connexion et d’audit d’Entra ID — enregistrent chaque action de gestion et chaque appel d’API au sein d’un environnement. Les événements liés aux identités et aux jetons capturent les authentifications, les autorisations et les consentements. Les modèles d’appels API montrent ce que chaque identité fait réellement, tandis que les données relatives aux charges de travail et aux flux réseau indiquent comment les données circulent. L’architecture de référence de Google décrit la séquence opérationnelle à suivre pour y parvenir correctement — activer les bons journaux, les acheminer vers une destination d’analyse, puis les analyser à cet endroit — dans son guide sur l’analyse des journaux de sécurité.

Il convient de souligner l'importance de la normalisation, car cloud ne s'accordent pas sur les schémas. Un même événement conceptuel — une identité s'octroyant des privilèges élevés — se présente de manière totalement différente dans CloudTrail, les journaux d'audit d'Entra ID et les journaux Cloud Google Cloud . L'enrichissement permet alors de compléter les informations manquantes dans les événements bruts, notamment le niveau de criticité des actifs, l'appartenance de l'identité et le contexte en matière de renseignements sur les menaces.

Ce qui rend cette discipline cloud , c’est la nature même des ressources. Cloud est éphémère, pilotée par des API et centrée sur l’identité : les charges de travail ne durent que quelques minutes, chaque action correspond à un appel d’API, et l’identité constitue le périmètre effectif. Le signal de détection correspond donc à un écart comportemental par rapport à une base de référence apprise, et non à une charge utile mal formée. C’est pourquoi l’analyse du comportement des utilisateurs et des entités (UEBA) est au cœur de cette pratique, et pourquoi la détection des anomalies réseau étend cette même logique de référence au trafic circulant entre les charges de travail.

C’est au cours des deux dernières étapes que l’analyse prouve toute sa valeur sur le plan opérationnel. La corrélation relie des événements isolés — une nouvelle connexion, une modification d’autorisation, un pic de lectures de données — pour former un scénario d’attaque cohérent, tandis que la hiérarchisation classe ce scénario par rapport à tous les autres éléments qui rivalisent pour attirer l’attention. Bien menée, cette approche constitue l’antidote à la fatigue des alertes. C’est également ce qui fait évoluer les deux indicateurs sur lesquels la plupart des centres d’opérations de sécurité (SOC) sont évalués — le temps moyen de détection (MTTD) et le temps moyen de réponse (MTTR) —, car les analystes partent d’une liste concise et classée plutôt que d’un flux d’événements bruts.

Pourquoi la détection basée sur les signatures échoue dans le cloud

Lorsqu’un attaquant s’authentifie à l’aide d’identifiants valides volés ou d’un jeton autorisé, l’analyse comportementale est souvent le seul moyen de détection restant. Les signatures correspondent à des éléments connus pour être malveillants : malware , charges utiles d’exploits, domaines malveillants. Une connexion réussie via une API approuvée ne génère aucun de ces éléments. Il n’y a ni échec d’authentification, ni fichier binaire déposé, ni trafic d’exploit à analyser. C’est là le point aveugle commun aux outils reposant uniquement sur les signatures et aux déploiements SIEM basés uniquement sur des règles.

‍

La campagne de 2024 visant les environnements clients de Snowflake, référencée sous le nom d’UNC5537, en est l’exemple type (analyse UNC5537 de Google Threat Intelligence). Les attaquants ont utilisé des identifiants volés par malware de type « infostealer » — 79,7 % d’entre eux avaient déjà été exposés, et certains n’avaient pas été renouvelés depuis quatre ans — contre des comptes ne disposant ni d’authentification multifactorielle (MFA) ni de listes d’autorisation réseau. Environ 165 organisations ont été informées. Aucune vulnérabilité n’a été exploitée, et aucun malware la plateforme. Chaque action des attaquants consistait en une requête authentifiée et correctement formée.

Il restait donc aux défenseurs trois types d'indicateurs, tous comportementaux : des déplacements impossibles entre les connexions, des applications clientes et des empreintes numériques inhabituelles, ainsi que des volumes de requêtes bien supérieurs aux valeurs de référence d'un compte. L'analyse comportementale fondée sur ces valeurs de référence, associée à l'analyse d'identité qui évalue la manière dont chaque compte s'authentifie habituellement, constitue la solution technique en matière de détection, parallèlement aux mesures préventives de base qui faisaient défaut aux victimes.

L’incident Salesloft Drift de 2025, référencé sous le numéro UNC6395, a étendu les enseignements tirés des mots de passe aux jetons (analyse UNC6395 de Google Threat Intelligence). Les attaquants ont compromis des jetons OAuth issus de l’intégration Drift et les ont utilisés pour exécuter des requêtes SOQL (Salesforce Object Query Language) bien formées sur de nombreuses instances client Salesforce — le rapport initial mentionne simplement « de nombreuses ». Aucune requête individuelle n’était mal formée. Les indices étaient d’ordre global et comportemental : volume d’appels API, structure des requêtes et écarts des user-agents par rapport à la référence établie pour l’intégration. C’est pourquoi les programmes de détection et de réponse aux menaces d’identité (ITDR) traitent les intégrations non humaines comme des identités à part entière.

Cette tendance s’est poursuivie en 2026 selon deux axes distincts. Les rapports de juillet 2026 ont mis en évidence une vague d’abus OAuth qui a duré un an, associée à l’écosystème d’extorsion ShinyHunters (The Hacker News). Une autrephishing a incité les victimes à enregistrer dans Entra ID des clés d’accès contrôlées par les attaquants, transformant ainsi un système de contrôle phishing en un point d’ancrage durable (Help Net Security). Des opérations différentes, mais un même problème de détection : des artefacts d’identité valides (jetons, cookies de session, clés d’accès) permettant d’exploiter des API légitimes.

Les exploits continuent de se produire dans le cloud avec une précision importante quant à leur portée. D’après les données de télémétrie propres Cloud Google Cloud, qui constituent un ensemble distinct des données issues des missions de Mandiant, l’exécution de code à distance (RCE) a vu sa part en tant que vecteur d’intrusion passer de 2,9 % au premier semestre 2025 à 13,6 % au second semestre (Threat Horizons, premier semestre 2026).

Lorsqu’une exploitation se produit, la mise au point d’outils d’exploitation devance la diffusion des signatures. React2Shell (CVE-2025-55182) est une vulnérabilité RCE (exécution de code à distance) avant authentification dans React Server Components, notée 10,0 (le score maximal) selon le système commun de notation des vulnérabilités (CVSS) (avis de sécurité React). Elle a fait l'objet d'une exploitation active dans les 48 heures environ qui ont suivi sa divulgation : l'Agence américaine de cybersécurité et de sécurité des infrastructures (CISA) l'a ajoutée au catalogue des vulnérabilités connues pour lesquelles des exploits existent le 5 décembre 2025, deux jours après la publication de l'avis, en invoquant des preuves d'exploitation active (alerte de la CISA). L'analyse comportementale comble également une partie de cette lacune : une charge de travail qui génère soudainement un cryptomineur s'écarte de sa ligne de base avant même qu'une signature ne soit diffusée.

Cas d'utilisation et techniques d'analyse Cloud

Ce même noyau analytique prend en charge toute une famille de cas d'utilisation, chacun posant une question comportementale à laquelle aucune signature ne peut répondre. Les analystes SOC utilisent ces détections pour le triage, les chasseurs de menaces pour tester des hypothèses, et les équipes chargées de la conformité comme preuve de la couverture de la surveillance. Cela se traduit par une détection plus précoce, moins de faux positifs et des enquêtes plus courtes. Toutes ces activités s'appuient sur la phase d'établissement des références du pipeline.

• Établissement d'une base de référence comportementale pour l'identification des utilisateurs. Les modèles de type UEBA apprennent les habitudes de chaque utilisateur en matière de localisation géographique, d'horaires et de clients utilisés lors de la connexion, puis signalent les déplacements impossibles, les accès en dehors des horaires habituels et les applications utilisées pour la première fois.
• Détection des anomalies dans l'activité des API. L'évaluation du volume d'appels, de la composition des appels, de la répartition géographique et de l'empreinte client par rapport aux valeurs de référence de chaque identité permet de détecter rapidement les vols de jetons et les abus liés à l'automatisation.
• Détectionmenace interne des exfiltrations de données. Les pics de volume de requêtes et les accès inhabituels aux données permettent de mettre au jour les menaces internes et les vols de données organisés, tandis que l'analyse du trafic réseau confirme la manière dont les données ont effectivement été transférées.
• Enrichissement des renseignements sur les menaces. La mise en corrélation cloud avec des renseignements sur les menaces validés permet de relier une connexion suspecte à une infrastructure connue — et de lui attribuer la priorité qui s'impose.

Deux d’entre eux méritent d’être soulignés, car ils constituent le fondement des enquêtes. La détection des exfiltrations dans le cloud en grande partie cloud un problème lié aux requêtes et aux flux sortants : dans le cadre de la campagne Snowflake, les signaux persistants étaient des volumes et des schémas de requêtes s’écartant considérablement des valeurs de référence du compte. Quant à l’enrichissement, il permet de transformer une anomalie en décision : une même connexion est évaluée différemment lorsque son infrastructure d’origine est déjà associée à des campagnes de « credential stuffing ».

Analyse des identités des machines et des entités non humaines

Dans la plupart cloud , les comptes de service, les clés API et les jetons OAuth sont désormais bien plus nombreux que les utilisateurs humains. Une analyse réalisée en 2026 par Tenable et publiée par la Cloud Alliance (CSA) estime que le rapport entre les identités machines et les identités humaines est d’environ 100 pour 1. Le rapport Cloud Cyber IA Report 2026 » de Tenable a par ailleurs révélé que 65 % des entreprises hébergent cloud « fantômes » oubliés — des identités dont personne n’est responsable, que personne ne met à jour ni ne surveille.

Ces « fantômes » ne relèvent pas de l’hypothèse. Les identifiants anciens, n’ayant jamais été mis à jour, à l’origine de la campagne UNC5537, entraient précisément dans cette catégorie. Les identités non humaines ne se comportent pas non plus comme des personnes — pas d’horaires de travail, pas de déplacements et des schémas d’appels très réguliers — ; elles ont donc besoin de leurs propres seuils de référence, distincts de l’UEBA humaine. Un compte de service qui s’authentifie soudainement de manière interactive, étend son champ d’action ou interroge un nouvel ensemble de données constitue l’un des signaux les plus évidents générés par les analyses cloud .

Analyse Cloud vs SIEM et catégories connexes

Un SIEM est l'environnement dans lequel les analyses peuvent être exécutées ; l'analyse cloud correspond à la fonctionnalité de détection comportementale qui y est mise en œuvre. Ces deux éléments sont complémentaires, et non concurrents. Toute confusion à ce sujet peut coûter cher : les équipes risquent soit d'acheter un deuxième produit dont elles n'ont pas besoin, soit de supposer que leur solution d'agrégation de journaux détecte déjà cloud . Le tableau ci-dessous établit les limites, y compris les catégories de plateformes connexes auxquelles les acheteurs sont confrontés.

L'analyse Cloud est une fonctionnalité, tandis que les solutions SIEM, CDR et CNAPP sont les produits et les plateformes sur lesquelles elle s'exécute ou dans lesquelles elle est intégrée.

Les plateformes SIEM restent la colonne vertébrale de l’agrégation, de la corrélation et de la conformité pour de nombreuses équipes, et c’est précisément là où réside tout l’enjeu : la question du produit est distincte de celle des capacités. Les plateformes Cloud et de réponseCloud (CDR) répondent directement à la question des capacités, en combinant des analyses comportementales cloud avec des actions de réponse pour les équipes qui souhaitent que le contenu de détection soit géré à leur place. Dans la pratique, cette relation passe souvent par le coût : les équipes utilisent cloud pour déterminer quelles données télémétriques doivent être ingérées par le SIEM et lesquelles doivent être acheminées vers un stockage moins coûteux, un compromis que la section suivante quantifie.

Les acronymes ci-contre décrivent le champ d’application, et non la concurrence. Une plateforme de protection des applications cloud(CNAPP) regroupe la protection de la posture et des charges de travail tout au long du cycle de vie des applications. Le CSPM évalue la configuration au repos, une plateforme de protection cloud (CWPP) protège la couche de calcul, et la gestion des droits d’accès cloud (CIEM) régit qui peut faire quoi. Aucune d’entre elles ne remplace la détection comportementale : elles réduisent et cartographient la surface d’attaque que l’analyse surveille ensuite. Les preuves d’intrusion axées sur l’identité de 2026, avec 83 % des cas majeurs cloud au SaaS fondés sur l’identité dans les missions de Mandiant (Threat Horizons H1 2026), expliquent pourquoi chacune de ces catégories continue de converger vers le comportement lié à l’identité.

Le marché s'est déjà prononcé sur la question opposant « fonctionnalité » à « produit ». Les produits autonomes d'analyse cloud ont été à plusieurs reprises retirés du marché ou intégrés à des plateformes plus larges de détection et d'évaluation de la posture de sécurité. Considérez ce terme comme une fonctionnalité dont vous avez besoin — au sein d'un SIEM, d'un « security data lake » ou d'une plateforme CDR — plutôt que comme un élément isolé sur un schéma d'architecture.

Les aspects économiques de cloud

L'efficacité de l'analyse Cloud dépend entièrement de la quantité de données télémétriques que l'on peut se permettre de conserver. Le coût de l'ingestion est la principale objection soulevée par les professionnels face à toute architecture gourmande en données télémétriques, et c'est la véritable raison d'être des « lacs de données de sécurité » : dissocier le stockage peu coûteux de la détection sélective.

Le volume augmente plus vite que les budgets, et tous les journaux ne justifient pas leur existence. Les journaux d’audit d’accès aux données en sont l’exemple typique : les recommandations de mise en œuvre de Google accordent une attention particulière à la gestion du volume des journaux d’audit d’accès aux données avant tout acheminement (recommandations sur l’analyse des journaux de sécurité). La clé réside dans la sélection des données de télémétrie. Les journaux du plan de contrôle et d’identité offrent la meilleure valeur de détection par gigaoctet, tandis que les journaux détaillés du plan de données ne doivent être ingérés que lorsque les ressources le justifient. C’est ce travail de sélection qui permet de maintenir la viabilité de la surveillancecloud à mesure que les environnements s’étendent.

La hiérarchisation de la conservation permet de résoudre le dilemme entre l'ingestion et la détection. Conservez les données de télémétrie de détection en temps réel en accès « chaud », celles d'investigation en accès « tiède » et celles de recherche proactive en accès « froid » — elles restent consultables, mais leur tarif est celui d'un stockage d'archives.

La conservation par niveaux permet de conserver les données de télémétrie à forte valeur ajoutée afin de pouvoir les interroger à des fins de recherche, sans pour autant payer le prix du stockage à accès fréquent pour l'ensemble des données.

La conservation des données n'est pas une simple case à cocher en matière de conformité : elle détermine les éléments sur lesquels une enquête peut se pencher. Lors de la campagne UNC5537, la durée de conservation par défaut de Snowflake a permis aux enquêteurs de disposer d'une fenêtre de 365 jours d'activité des comptes à analyser (enquête UNC5537). Les organisations dont la durée de conservation est plus courte disposent tout simplement d'un historique moins complet à reconstituer.

Les références permettent de cerner les enjeux. L’étude « Cost of a Data Breach » (Coût d’une fuite de données) de l’Institut Ponemon estime la moyenne mondiale pour 2025 à 4,44 millions de dollars, avec un délai de 241 jours pour identifier et contenir une fuite — ces chiffres s’appliquent à tous les environnements, et l’édition 2026 est imminente (Help Net Security). Les délais Cloud témoignent de la même urgence. Dans l’analyse par Push Security cloud du rapport DBIR 2026 cloud , seules 23 % des organisations tierces avaient entièrement comblé leurs lacunes cloud , et l’organisation médiane avait besoin de huit mois pour résoudre 50 % des problèmes identifiés liés aux mots de passe et aux erreurs de configuration des autorisations (Push Security).

Mise en œuvre d'analyses cloud sur AWS, Azure et GCP

Les noms des indicateurs de télémétrie varient d'un fournisseur à l'autre, mais les questions relatives au comportement restent les mêmes. L'architecture de référence de Google définit les grandes catégories de questions auxquelles chaque environnement doit répondre : anomalies de connexion et d'accès, modifications des autorisations, activités de provisionnement, accès aux données et schémas de trafic réseau (conseils sur l'analyse des journaux de sécurité). Le tableau ci-dessous met en correspondance ces questions avec les principales sources de chaque fournisseur.

Les mêmes critères comportementaux sont appliqués à tous les fournisseurs dès lors que les données de télémétrie relatives au plan de contrôle et à l'identité sont transmises.

La plupart des entreprises traitent ces questions à plusieurs niveaux à la fois. Un programme cloud harmonise les schémas de journaux des différents fournisseurs au sein d’une seule couche analytique, de sorte qu’une logique de référence unique s’applique partout. L’expertise spécifique à chaque fournisseur reste toutefois utile : la détection des menaces d’AWS, par exemple, superpose les événements de données CloudTrail et les journaux de flux au-dessus du plan de gestion afin de repérer ce que les journaux au niveau du compte ne détectent pas.

Les conteneurs élargissent la surface d'expositioncloud . Les journaux d'audit et les événements d'exécution de Kubernetes se présentent de la même manière, quel que soit l'endroit où le cluster est exécuté, ce qui fait de la télémétrie de sécurité de Kubernetes un élément fédérateur naturel — et étend ces mêmes références aux architectures cloud hybride où les charges de travail s'étendent à la fois aux centres de données et aux clouds.

Surveillez le fournisseur d'identité (IdP) lui-même, et pas seulement les charges de travail qui s'y rattachent. La vulnérabilité CVE-2026-40379, une faille d’usurpation d’identité découverte en 2026 dans Entra ID, a reçu une note de 9,3 de la part de son autorité de numérotation CVE (CNA) et de 7,5 de la part de l’Institut national des normes et des technologies (NIST) (fiche NVD). Lorsque l’IdP est la cible, ses propres données de télémétrie relatives à la connexion et à l’audit constituent la surface de détection.

Correspondance avec le référentiel MITRE ATT&CK et les cadres de conformité

MITRE ATT&CK , publiée le 28 avril 2026, a repensé la manière dont l'évasion est modélisée. L'ancienne tactique « Defense Evasion » a été supprimée et scindée en deux sous-catégories : « Stealth » (0005) et Déficience de défense (0112) — cette dernière catégorie désignant les adversaires qui contournent les mécanismes de sécurité, les chaînes de traitement et les outils, de sorte que les défenseurs ne puissent ni voir ni se fier à ce qui se passe. La cloud ATT&CK pour cloud couvre 12 tactiques réparties sur quatre plateformes — suite bureautique, fournisseur d'identité, SaaS et IaaS (infrastructure en tant que service) — et fournit aux ingénieurs en détection un vocabulaire commun pour décrire les comportements présentés dans ce guide.

Une feuille de route partant des cloud d'ATT&CK v19 pour aboutir aux détections comportementales que peuvent fournir les analyses cloud .

La cartographie de conformité s'inscrit naturellement dans ce cadre. Au sein du Cadre de cybersécurité (CSF) 2.0 du NIST, publié en 2024, cette pratique relève de la fonction « Détection » — l'une des six fonctions du cadre —, sous les catégories DE.CM et DE.AE (NIST). La matrice Cloud de la CSA (CSA Cloud Controls Matrix) v4, qui comprend 197 contrôles répartis sur 17 domaines, intègre des exigences équivalentes dans son domaine « Journalisation et surveillance » (LOG) (CSA CCM).

La directive NIS2 (directive (UE) 2022/2555) exige, en vertu de son article 23, une alerte précoce dans les 24 heures suivant la prise de connaissance d’un incident significatif, une notification de l’incident dans les 72 heures et un rapport final dans un délai d’un mois. La directive DORA (règlement (UE) 2022/2554) s’applique aux entités financières de l’UE depuis le 17 janvier 2025 — des délais de déclaration aussi courts accordent une importance manifeste à la rapidité de détection.

Approches modernes de l'analyse cloud

Le secteur s'oriente vers trois grandes tendances. La détection privilégie désormais l'identité, car c'est ce que révèlent les preuves vérifiées : l'identité était à l'origine de 83 % des intrusions majeures dans cloud les services SaaS, selon les données de Mandiant relatives au second semestre 2025 (Threat Horizons, premier semestre 2026). Les outils d’analyse autonomes continuent de se regrouper au sein de plateformes, qu’il s’agisse de packs de contenu hébergés sur des solutions SIEM ou de plateformes cloud et de réponsecloud . Par ailleurs, le triage et la recherche assistés par l’IA deviennent la norme, car les équipes réduites ne peuvent pas recouper manuellement les comportements sur plusieurs surfaces à cloud .

Pour les acheteurs, trois critères permettent de distinguer les plateformes pérennes des simples tableaux de bord. Recherchez une visibilité unifiée sur les environnements cloud, d’identité et SaaS. Exigez des détections comportementales qui continuent de fonctionner même après le vol d’identifiants — c’est le test de détection et de réponse aux menaces liées à l’identité. Et privilégiez la qualité des signaux plutôt que le volume d’alertes, en fonction de ce qu’une petite équipe est réellement capable d’analyser.

Vectra AI en matière d'analyse cloud

Vectra AI l’analyse cloud en partant du principe que le système est déjà compromis. Les attaquants se présentant de plus en plus souvent sous des identités valides, cette méthodologie privilégie la clarté des signaux d’attaque à travers le réseau, les identités, cloud et les services SaaS — en mettant en évidence les comportements qui révèlent la présence d’un attaquant actif plutôt que les signatures que l’utilisation abusive d’identifiants valides ne déclenche jamais. Concrètement, cela implique d’établir une base de référence pour chaque identité, qu’elle soit humaine ou machine, de regrouper les écarts observés sur l’ensemble des surfaces d’attaque en un seul scénario d’attaque, et de privilégier les quelques signaux indiquant une progression réelle plutôt que le volume brut d’alertes.

Conclusion

L’analyse Cloud mérite bien son nom, car le cloud ce que les systèmes de détection doivent repérer. Les attaquants qui parviennent à s’introduire avec des identifiants et des jetons valides contournent purement et simplement les signatures : les violations emblématiques de 2024 et 2025 n’ont généré ni malware, ni exploit, ni échec de connexion, mais uniquement des comportements s’écartant de la ligne de base. La réponse réside dans une discipline, et non dans un produit isolé. Collectez les données télémétriques pertinentes concernant le plan de contrôle, les identités, les API et les charges de travail. Établissez une base de référence pour chaque identité, qu’il s’agisse d’un utilisateur ou d’une machine. Hiérarchisez la conservation des données afin que la recherche d’anomalies reste abordable. Mettez en correspondance les détections avec la cloud ATT&CK v19 et les référentiels reconnus par les auditeurs. Les équipes qui considèrent l’analyse cloud comme une capacité à part entière — quel que soit l’environnement dans lequel elle s’exécute — continueront à repérer les attaquants que leurs signatures ne détectent jamais.

‍