Les compromissions d’identité et les défaillances de processus sont les principaux moteurs des brèches impactantes dans le cloud
Les atteintes à la sécurité du cloud les plus préjudiciables ne proviennent pas de mystérieux exploits de type « zero-day ». Elles proviennent de l’intérieur, d’informations d’identification ordinaires qui tombent entre de mauvaises mains et de simples erreurs dans la configuration des systèmes. C’est ce que révèlent les données de l’analyse des menaces de ReliaQuest pour le troisième trimestre 2025. Ils ont constaté que près de la moitié, 44%, des alertes de sécurité cloud confirmées se résumaient à des problèmes d’identité. Et voici le véritable choc : 99 % des identités cloud avaient plus d’accès qu’elles n’en avaient besoin.
Pourquoi les PDG, les DSI et les directeurs techniques devraient-ils s’en préoccuper ? Parce que ces problèmes d’identité et de processus sont prévisibles, évitables et encore ignorés. Les acteurs de la menace n’ont pas besoin d’inventer de nouveaux exploits, il leur suffit de se connecter en utilisant des informations d’identification volées, souvent obtenues par hameçonnage ou par des fuites de bases de données. Une fois entrés, ils trouvent des comptes avec trop d’autorisations, et c’est parti. C’est ainsi qu’une compromission de routine se transforme en une grave perturbation.
L’échec du processus aggrave le problème. Nous constatons vulnérabilités héritéesNous voyons des vulnérabilités héritées, certaines suivies depuis des années, refaire surface encore et encore alors que les organisations mettent en place des actifs dans le nuage rapidement, mais sans précaution. En l’absence d’une validation appropriée intégrée au développement et au déploiement, les vulnérabilités sont clonées à grande échelle dans tous les environnements. La course au déploiement rapide a également créé un flou autour de la question de l’atténuation des risques. Il ne s’agit pas d’un ralentissement de l’innovation, mais d’une innovation réalisée avec discipline.
Le point de vue des dirigeants est clair : si vous voulez mettre fin aux violations majeures du cloud, ne vous contentez pas de courir après le prochain outil de sécurité de pointe. Commencez par remédier à la prolifération des identités et par améliorer la manière dont les actifs du cloud sont déployés. Il s’agit de questions fondamentales, et le retour sur investissement de leur résolution est extrêmement élevé.
Les identités cloud sur-privilégiées augmentent considérablement le risque et la gravité des violations.
Voici le problème : la plupart des utilisateurs du cloud ont beaucoup plus d’accès qu’ils n’en ont besoin. Il ne s’agit pas d’une légère erreur de configuration. C’est l’échec d’un principe de base : le moindre privilège. Il s’agit de ne donner aux utilisateurs que ce dont ils ont absolument besoin pour accomplir leur travail. La raison pour laquelle l’impact des attaques augmente si rapidement une fois que les informations d’identification ont été volées est que les attaquants héritent d’un accès complet ou presque complet par défaut.
Selon ReliaQuest, 99 % des identités dans le cloud sont sur-permises. Cela signifie que presque chaque compte pourrait causer de sérieux dommages s’il était compromis. Plus important encore, 52 % de toutes les alertes liées à l’identité impliquaient des attaquants escaladant les privilèges après une compromission initiale. C’est à ce niveau que la plupart des brèches s’élèvent, passant d’une situation gênante à une situation catastrophique.
Les grands fournisseurs comme AWS, Azure et Google Cloud sont livrés avec des rôles d’administrateur prédéfinis qui sont faciles à utiliser, mais dangereusement larges. La commodité tue la sécurité. Au niveau de l’organisation, il s’agit d’un compromis entre rapidité et sécurité, et pour l’instant, c’est la rapidité qui l’emporte. Mais cette approche n’est pas évolutive en toute sécurité. Si les informations d’identification d’un ingénieur sont volées et que ce compte peut accéder à 90 % de votre infrastructure, vous ne gérez pas le risque, vous l’invitez.
Pour les dirigeants, il s’agit d’un point de levier. La mise en œuvre de contrôles d’accès plus stricts ne se limite pas à la protection des données. Il s’agit de préserver vos options, votre capacité à vous développer sans avoir à assumer des niveaux de cyber-risques croissants. Les audits dynamiques des privilèges, les politiques de moindre privilège intégrées dans les flux de travail et la limitation de la durée de vie des comptes avec des informations d’identification à court terme ne sont pas des solutions complexes. Il s’agit de mesures simples et de grande valeur qui réduisent considérablement votre risque de violation.
Ce qu’il faut retenir : la gravité de la violation dépend de ce à quoi un compte compromis peut accéder. Plus tôt les dirigeants agiront pour limiter les autorisations excessives, moins les pirates pourront faire de dégâts en cas de fuite d’informations d’identification, et non en cas de fuite. La sécurité ne consiste pas à rendre les violations impossibles. Il s’agit de faire en sorte que l’on puisse y survivre.
Le volume d’alertes liées à l’identité constitue une charge opérationnelle majeure pour les équipes de sécurité.
Les équipes de sécurité sont débordées. Un tiers de toutes les alertes de sécurité du cloud brut sont liées à l’identité, 33%. Ces alertes nécessitent du temps, du contexte et des investigations manuelles, car les machines peuvent reconnaître des schémas inhabituels, mais seules les personnes peuvent dire si ces schémas sont réellement nuisibles. C’est une ponction sur les ressources que peu d’organisations peuvent se permettre.
Le chevauchement entre la source de bruit la plus courante (alertes d’identité) et la cause la plus fréquente des violations (compromission de l’identité) crée un goulot d’étranglement opérationnel. Les analystes de la sécurité doivent trier des volumes massifs de signaux à faible certitude pour identifier les véritables menaces. C’est lent. C’est coûteux. Cela épuise les meilleurs talents.
Les systèmes automatisés peuvent prendre en charge une partie du flux de travail, comme l’envoi de messages aux utilisateurs pour la validation des sessions. Mais le processus d’examen n’est pas simple. Il s’appuie sur les politiques de l’organisation, les connaissances institutionnelles et le jugement en temps réel pour déterminer si une tentative de connexion ou un accès élevé est légitime ou s’il s’agit d’une violation en cours.
Les dirigeants devraient considérer cette question non pas comme un problème de flux de travail informatique, mais comme un problème stratégique. Le coût d’une détection lente se mesure en perte de données, en temps d’arrêt et en exposition à la réglementation. Si les équipes de sécurité ne parviennent pas à se frayer un chemin à travers le bruit, les acteurs de la menace continueront à réussir en se fondant dans la masse. Le bruit des alertes doit être filtré. Le processus doit être renforcé par une automatisation qui identifie le contexte plus rapidement. Et les contrôles d’identité doivent être aplanis, de sorte que les informations d’identification compromises ne déclenchent pas systématiquement des réponses de niveau crise.
La priorité n’est pas seulement de réduire le volume des alertes, mais aussi d’améliorer la qualité du signal. Donnez à votre équipe de sécurité moins d’alertes, mais de meilleure qualité. C’est là que le temps, l’énergie et l’argent sont réellement rentabilisés.
Les vulnérabilités héritées sont réintroduites de manière répétée par le biais de processus de déploiement de clouds défectueux.
Le déploiement sécurisé est toujours à la traîne par rapport à l’automatisation. L’infrastructure cloud automatisée est précieuse, cela ne fait aucun doute. Mais lorsque les entreprises copient et redéploient du code à grande échelle sans validation de sécurité suffisante, elles reproduisent non seulement l’infrastructure, mais aussi les vulnérabilités. Aujourd’hui, 71 % de toutes les alertes de vulnérabilités critiques suivies par ReliaQuest proviennent de seulement quatre exploits connus : Log4Shell (CVE-2021-44228), OpenSSH (CVE-2024-6387), Windows (CVE-2023-36884) et Jenkins (CVE-2024-23897).
Ces risques ont été divulgués, corrigés, analysés, et pourtant, ils continuent de se manifester parce que la sécurité n’est pas devenue une partie intégrante du processus de déploiement. La pression exercée pour aller vite, combinée à un manque de clarté dans la répartition des responsabilités en matière de sécurité du cloud, se traduit par une prolifération d’actifs remplie de points faibles recyclés.
Il ne s’agit pas seulement de la dette technique. Il s’agit d’un risque systémique généré par une mauvaise discipline des processus. Et ce risque s’aggrave. Plus ces cycles de mauvaises configurations héritées ne sont pas contrôlés, plus les équipes chargées de la sécurité et de la conformité voient leur retard s’aggraver.
Si vous êtes à la tête d’une organisation dont les initiatives de cloud se développent rapidement, cette question devrait vous préoccuper. Chaque fois qu’une infrastructure est déployée ou modifiée sans test de sécurité, vous augmentez le coût et la difficulté de corriger les vulnérabilités ultérieurement. Faites en sorte que les contrôles de sécurité ne soient pas optionnels dans les flux de travail DevOps. Intégrez la détection des menaces lors de l’approvisionnement des actifs. Attribuez clairement la responsabilité des correctifs et de la validation.
L’objectif n’est pas de ralentir le développement, mais de le faire évoluer de manière responsable. Les problèmes hérités ne doivent pas nécessairement rester des problèmes hérités. Mais ils le resteront si la sécurité du cloud continue d’être un élément ajouté à la fin.
La réduction efficace des risques dépend de pratiques proactives en matière de sécurité du cloud.
La prévention des brèches dans le cloud ne se résume pas à des espoirs ou à des suppositions. Il s’agit de faire le travail dès le début et de manière cohérente. Le moyen le plus efficace d’anticiper les défaillances d’identité et de processus est de les empêcher de se produire à grande échelle, ce qui nécessite d’intégrer la sécurité dans le fonctionnement de vos systèmes.
Le rapport de ReliaQuest présente des mesures pratiques : éliminer les clés d’accès AWS statiques pour les utilisateurs humains, adopter des politiques d’accès au moindre privilège en utilisant des contrôles cloud intégrés, et incorporer la validation automatisée de la sécurité directement dans les flux de développement. Il ne s’agit pas d’idées spéculatives. Il s’agit d’actions que les organisations soucieuses de la sécurité intègrent déjà dans leurs processus afin de réduire les frictions et les risques.
Ce qui importe vraiment ici, c’est l’application continue de la loi. L’accès à l’identité doit être dynamique, les mots de passe et les informations d’identification doivent expirer rapidement. Les autorisations doivent être revérifiées en fonction de l’utilisation et la réponse aux incidents doit être prête à se déclencher en temps réel. Attendre qu’une alerte de violation apparaisse n’est pas une stratégie, c’est une réaction. Et le coût de la réaction est toujours plus élevé que celui de la préparation.
Pour les cadres et les dirigeants, le moment est venu de considérer la sécurité comme une fonction essentielle du produit et de l’infrastructure, et pas seulement comme une liste de contrôle de la conformité. Construisez plus vite, oui, mais construisez de manière sécurisée dès la conception. Il n’y a pas d’échelle à long terme sans la confiance et le contrôle de l’infrastructure dont dépendent vos équipes.
Investir dans une sécurité proactive ne limite pas la croissance. Il permet de réduire les surprises et les coûts de récupération. Le risque ne disparaît pas. Il est géré ou exploité.
Les acteurs de la menace s’orientent vers des pipelines d’intrusion entièrement automatisés utilisant des informations d’identification compromises.
Les attaquants n’attendent pas. Ils optimisent. Ce qui prenait des heures ou des jours est réduit à quelques minutes. Le processus de compromission d’un environnement cloud, depuis la recherche ou l’achat d’informations d’identification fuitées, jusqu’à l’ouverture d’une session et l’extension du contrôle, est de plus en plus automatisé. Les prévisions de ReliaQuest sont claires : l’ensemble de la chaîne évolue vers un service unique et efficace.
Les acteurs de la menace utilisent déjà les logs des voleurs d’informations pour extraire des données d’identification. Ils achètent des accès auprès de courtiers spécialisés. Et ils intègrent ces outils dans des flux de travail reproductibles. L’étape suivante, l’automatisation qui relie ces étapes, est déjà en cours.
Le calendrier s’en trouve complètement modifié. En cas de fuite de données d’identification, les organisations auront beaucoup moins de temps pour les détecter et y répondre. La vitesse devient un critère de survie. Les processus manuels et les alertes retardées ne permettront pas de contenir la prochaine vague de violations. La détection et la réponse doivent fonctionner en temps réel par défaut, et non dans le meilleur des cas.
Les dirigeants doivent reconnaître cette évolution pour ce qu’elle est : un changement structurel dans la manière dont la cybercriminalité opère. Si vos systèmes ne peuvent pas s’adapter à cette vitesse grâce à l’automatisation, vous n’êtes pas compétitif en matière de sécurité. La détection du cycle de vie complet, le confinement automatisé et les outils d’identité réactifs doivent figurer sur la feuille de route.
L’automatisation n’est plus seulement utile, elle est essentielle. Vous ne pouvez pas opposer une défense manuelle à une attaque à la vitesse de la machine et espérer gagner. Combler le fossé de la réponse est la prochaine frontière de la défense moderne du cloud. Les organisations qui s’alignent maintenant feront face à moins de perturbations, moins de pertes et moins de regrets après l’incident.
Les oublis et les erreurs de configuration en matière de sécurité restent largement évitables
La plupart des failles dans le cloud ne nécessitent pas d’innovation de la part des attaquants. Elles réussissent en raison d’erreurs évitables, d’autorisations excessives, de vulnérabilités non corrigées et de processus déconnectés. Ces problèmes ne sont pas nouveaux. Ils persistent parce que la sécurité est toujours considérée comme une fonction distincte, appliquée après la mise en service au lieu d’être intégrée dès le départ dans la manière dont les systèmes sont développés et les identités gérées.
L’analyse de ReliaQuest souligne que les mauvaises configurations et les défaillances de processus sont à l’origine de la majorité des incidents graves, et non des exploits compliqués. Lorsque les comptes à privilèges excessifs ne sont pas surveillés et que les vulnérabilités existantes sont redéployées automatiquement, il ne s’agit pas d’une défaillance technologique, mais d’une défaillance du flux de travail. Les contrôles d’accès sont négligés. Les étapes de validation sont sautées. Et le cycle se répète à mesure que l’échelle augmente.
Pour les dirigeants, cela signifie qu’il est nécessaire de procéder à des ajustements structurels. La sécurité ne devrait pas être confinée à la fin d’un sprint de déploiement ou déclenchée par une date limite de conformité. Elle doit être intégrée dès le début, liée à la gouvernance des identités, appliquée par le biais des pipelines CI/CD et mesurée en permanence. Les équipes doivent être formées à penser en termes de sécurité par défaut, et non en termes de correctifs post-mortem.
La propriété du processus est une autre question cruciale. De nombreuses organisations ne savent toujours pas clairement qui est responsable de la remédiation des risques pendant le déploiement. Il en résulte une duplication des efforts, des angles morts et des réponses retardées en cas d’incident. La sécurité doit être la responsabilité de tous, mais les dirigeants doivent définir ce à quoi ressemble cette responsabilité au sein des équipes d’ingénierie, d’exploitation et de sécurité.
Les organisations qui mettent en place une intégration plus étroite entre la sécurité et les opérations avanceront plus rapidement et commettront moins d’erreurs. Celles qui s’appuient sur des modèles réactifs continueront à prendre du retard, ajoutant des coûts et des risques à chaque étape. La sécurité doit faire partie du système d’exploitation de l’entreprise, et non pas se superposer. Les entreprises qui y parviendront auront une plus grande résilience, une plus grande confiance dans leurs opérations numériques et moins d’exercices d’évacuation inutiles.
Récapitulation
La sécurité du cloud n’échoue pas parce que les menaces évoluent trop rapidement. Elle échoue parce que les contrôles de base ne sont pas appliqués. Les comptes sur-autorisés, les pratiques d’identité faibles et les processus de déploiement non contrôlés sont à l’origine de la majorité des violations ayant un impact, et non pas des journées zéro, ni des attaquants très avancés.
C’est une bonne nouvelle pour les dirigeants. Il est possible de remédier à ces risques et les solutions ne nécessitent pas de révisions massives, mais simplement une appropriation claire, une mise en œuvre disciplinée et une automatisation plus stricte là où c’est nécessaire. Considérez l’accès au moindre privilège, la validation automatisée de la sécurité et la réponse en temps réel comme des fonctions essentielles, et non comme des mises à niveau optionnelles. L’investissement est minime par rapport au coût d’une violation majeure.
La sécurité ne commence plus au niveau du périmètre. Elle commence par la manière dont vos équipes attribuent les accès, construisent l’infrastructure et gèrent le changement. Si ces fondations sont faibles, les outils ne vous sauveront pas. Si ces fondations sont solides, votre organisation évolue plus rapidement, en toute confiance.
Les entreprises qui gagneront ne seront pas celles qui se lanceront à la poursuite de chaque nouvelle menace. Elles seront celles qui ont bien compris les principes de base et qui ont intégré la sécurité dans leur mode de fonctionnement, et pas seulement dans leur façon de réagir.
