Le cloud computing était censé rendre l'infrastructure plus facile à gérer de façon sécurisée. La réalité documentée dans les recherches sur la surface d'attaque externe est plus complexe : l'infrastructure cloud est plus facile à provisionner, ce qui signifie qu'elle est aussi plus facile à provisionner de façon non sécurisée, et les configurations par défaut de nombreux services cloud sont permissives plutôt que restrictives. Le résultat est une génération d'infrastructure hébergée dans le cloud où les mauvaises configurations qui exposent des données sensibles ou fournissent un accès non autorisé sont courantes, persistent souvent pendant de longues périodes, et sont découvertes par les attaquants avec les mêmes outils de scan automatisés que ceux que les équipes de sécurité utilisent pour auditer leurs propres environnements.
Les catégories de mauvaises configurations cloud qui apparaissent systématiquement dans les audits de surface d'attaque externe sont bien documentées depuis des années, mais elles continuent d'apparaître en grand nombre parce que la vitesse de provisionnement cloud dépasse les processus de revue de sécurité qui les détecteraient, parce que les développeurs qui ont besoin de tester quelque chose rapidement priorisent le faire fonctionner plutôt que le faire de façon sécurisée, et parce que le modèle de permissions dans les environnements cloud est suffisamment complexe pour que la mauvaise configuration soit facile même pour des ingénieurs qui comprennent la sécurité en principe.
Les buckets Amazon S3 configurés pour un accès public sont la catégorie de mauvaise configuration cloud la plus documentée. L'historique des incidents de buckets S3 ouverts divulgués publiquement est long et comprend des brèches dans des organisations majeures de tous les secteurs. Malgré des années d'attention à ce problème et l'introduction par AWS de paramètres de blocage d'accès public au niveau du compte en 2018, des buckets ouverts continuent d'apparaître parce que chaque nouveau compte, filiale, ou intégration tierce peut ne pas avoir ce paramètre appliqué, et parce que les paramètres de permissions hérités peuvent être remplacés au niveau du bucket individuel par des développeurs qui ont besoin de tester l'accès public pour une raison légitime et oublient de revenir à la configuration précédente.
Ce qui rend les buckets S3 ouverts à fort impact, ce n'est pas seulement que les attaquants peuvent lire les données qu'ils contiennent, mais que ces données sont souvent disproportionnellement sensibles par rapport à la façon dont le bucket a été traité. Les archives de sauvegarde créées pendant une migration système contiennent des dumps de base de données. Les archives de logs contiennent des enregistrements d'authentification. Les configurations d'environnements de développement contiennent des credentials de base de données et des clés API. Les données occasionnelles qui se retrouvent dans un bucket S3 "juste temporairement accessible" sont fréquemment le type de données qui devrait être dans l'environnement de stockage le plus restreint disponible.
Des outils de scan automatisés comme TruffleHog et Grayhat Warfare indexent en continu les buckets S3 accessibles publiquement, et leurs résultats sont interrogeables publiquement. Tout bucket S3 ouvert est découvrable via ces services dans les heures suivant son ouverture au public. Les organisations qui veulent connaître leurs buckets ouverts avant les attaquants doivent scanner leurs propres comptes AWS de façon proactive, ce qui nécessite de savoir quels comptes contiennent des buckets S3, ce qui peut lui-même nécessiter de maintenir un inventaire de tous les comptes cloud.
Kubernetes est devenu la plateforme d'orchestration de conteneurs dominante pour l'infrastructure cloud d'entreprise, et ses interfaces de gestion présentent plusieurs catégories de risque de mauvaise configuration. Le tableau de bord Kubernetes, quand il est déployé et exposé sans authentification ou avec une authentification faible, fournit une interface via laquelle un attaquant peut voir toute la configuration du cluster, accéder aux secrets stockés dans les objets secrets Kubernetes, et dans de nombreux cas créer de nouveaux pods ou modifier des déploiements existants. Un tableau de bord Kubernetes public est essentiellement une console administrative pour l'infrastructure de production exposée à internet.
Shodan et Censys indexent les serveurs API Kubernetes et les tableaux de bord accessibles depuis internet public, et les données résultantes sont recherchables. Le modèle Kubernetes est particulièrement susceptible à cette exposition parce que les clusters sont couramment créés pour le développement et les tests avec des configurations par défaut qui incluent un tableau de bord accessible, et ces clusters se retrouvent parfois en production ou sont oubliés plutôt que décommissionnés. La surveillance continue de la surface d'attaque externe qui inclut la détection des interfaces de gestion Kubernetes exposées est le contrôle qui détecte ces exposures au moment où elles se produisent plutôt que lors du prochain audit trimestriel.
OAuth 2.0 est le standard de délégation d'authentification qui sous-tend la plupart des intégrations de services cloud, et sa complexité crée plusieurs catégories de mauvaises configurations. Les permissions d'application OAuth trop larges, où une application tierce s'est vu accorder l'accès pour lire tous les emails ou tous les fichiers dans un service de stockage cloud plutôt que les permissions minimales dont elle a besoin, représentent une exposition latente : si l'application tierce est compromise, l'attaquant hérite de ces permissions dans l'environnement de l'organisation cible.
La mauvaise utilisation du Device Code Flow OAuth a été documentée dans des attaques réelles : un attaquant initie une requête d'authentification Device Code Flow, envoie le code résultant à la victime via email ou message Teams, et la victime qui entre le code accorde à l'attaquant un token OAuth authentifié sans réaliser qu'elle a authentifié quoi que ce soit de malveillant. L'attaque exploite un flux OAuth légitime conçu pour l'authentification des appareils, mais le détourne à des fins malveillantes.
La surveillance continue des autorisations d'applications OAuth dans les tenants cloud, en signalant spécifiquement les nouvelles applications avec des permissions larges et en révisant l'historique d'accès des applications qui n'ont pas été récemment auditées, est le contrôle interne pour les mauvaises configurations OAuth. La surveillance de la surface d'attaque externe qui inclut la découverte d'applications OAuth, en cherchant les applications enregistrées dans votre tenant cloud qui ne sont pas dans votre inventaire d'applications approuvées, fournit une couche de détection complémentaire pour les intégrations OAuth de shadow IT provisionnées sans revue de sécurité. La visibilité externe sur votre environnement cloud du point de vue de l'attaquant est la façon la plus fiable d'identifier ce qui nécessite une attention avant que les attaquants ne le trouvent.
Le modèle de responsabilité partagée dans le cloud, dans lequel le fournisseur cloud est responsable de la sécurité de l'infrastructure sous-jacente et le client est responsable de la sécurité dans le cloud (configuration, données, accès), est bien connu des professionnels de la sécurité mais continue d'être mal appliqué dans la pratique. La confusion la plus courante est de supposer que parce qu'un service cloud est "géré" par le fournisseur, sa configuration de sécurité est également gérée par le fournisseur. Un bucket S3 "géré" par AWS signifie que l'infrastructure de stockage est gérée ; les politiques d'accès qui déterminent qui peut lire les données dans ce bucket restent entièrement la responsabilité du client.
Cette confusion de responsabilité est aggravée par la vitesse à laquelle de nouveaux services cloud sont adoptés. Quand un développeur utilise un nouveau service cloud pour la première fois et configure sa politique d'accès par défaut sans comprendre pleinement les implications de cette politique, la responsabilité de la configuration incorrecte qui en résulte est celle de l'organisation cliente, pas du fournisseur cloud. Les outils de surveillance de la posture de sécurité cloud (CSPM) comme ceux intégrés dans AWS Security Hub, Azure Security Center, ou les solutions tierces comme Wiz ou Orca Security, aident à identifier les mauvaises configurations en analysant la configuration des ressources cloud par rapport aux bonnes pratiques de sécurité connues.
La complémentarité entre les outils CSPM (qui voient la configuration de l'intérieur du compte cloud) et la surveillance de la surface d'attaque externe (qui voit ce qui est effectivement accessible depuis internet) est importante : un CSPM peut signaler qu'un bucket est techniquement configurable comme public mais ne confirme pas qu'il est effectivement accessible depuis internet dans sa configuration actuelle. La surveillance externe confirme ce que les attaquants peuvent réellement trouver et atteindre. La visibilité externe est donc le complément indispensable des outils CSPM pour une posture de sécurité cloud complète.
Les outils de gestion de la posture de sécurité cloud (CSPM) sont conçus pour identifier les mauvaises configurations dans les environnements cloud en analysant la configuration des ressources par rapport aux bonnes pratiques de sécurité et aux benchmarks CIS. Ces outils sont précieux pour identifier les mauvaises configurations connues dans les comptes cloud gérés, mais ils présentent des limitations importantes qui sont directement pertinentes pour comprendre pourquoi les mauvaises configurations cloud persistent malgré l'utilisation d'outils CSPM.
La limitation principale des outils CSPM est qu'ils ne peuvent surveiller que les comptes cloud dont ils ont connaissance. Dans un grand environnement multi-cloud avec des centaines de comptes AWS, des dizaines de tenants Azure, et des projets GCP gérés par différentes équipes, l'outil CSPM doit être connecté à chacun de ces comptes pour les surveiller. Les comptes shadow IT, ceux créés par des équipes individuelles en dehors du processus d'approvisionnement central, ne sont pas visibles pour l'outil CSPM et leurs mauvaises configurations ne sont pas détectées.
La surveillance de la surface d'attaque externe qui prend une vue agnostique au fournisseur de l'infrastructure internet-facing de l'organisation, en cherchant les services exposés, le stockage ouvert, et les interfaces de gestion à travers tous les fournisseurs cloud, traite la limitation d'inventaire du CSPM. En scannant les plages IP et l'espace de domaine de l'organisation depuis l'extérieur, quel que soit le fournisseur cloud qui héberge l'infrastructure derrière ces adresses, les outils ASM externes peuvent trouver des ressources cloud exposées que les outils internes manquent parce qu'ils sont dans un compte cloud ou un fournisseur qui n'est pas connecté à l'infrastructure de surveillance interne. La visibilité externe est donc le complément indispensable des outils CSPM.
Les attaquants utilisent les mêmes outils et sources de données que les chercheurs en sécurité pour trouver des ressources cloud mal configurées : des bases de données de scan internet comme Shodan et Censys qui indexent les services exposés, des outils automatisés qui scannent des patterns de misconfiguration spécifiques comme les outils d'énumération de buckets S3, et des flux d'intelligence commerciaux qui agrègent les données de scan. Certains attaquants achètent l'accès à des résultats de scan détaillés de sources commerciales. La vitesse de découverte par ces outils est mesurable en heures pour les nouvelles exposures.
Non. Le modèle de responsabilité partagée divise clairement les responsabilités : le fournisseur cloud est responsable de la sécurité de l'infrastructure sous-jacente, et le client est responsable de la sécurité dans le cloud, y compris la configuration des ressources. Une mauvaise configuration d'un bucket S3 ou d'un dashboard Kubernetes par le client est entièrement sous la responsabilité du client dans ce modèle. Les fournisseurs cloud fournissent des outils pour aider à identifier les mauvaises configurations (Security Hub, Advisor), mais la détection et la correction restent la responsabilité du client.
Un audit de sécurité cloud analyse la configuration interne des ressources cloud d'un compte connu, identifiant les déviances par rapport aux bonnes pratiques de sécurité. La surveillance de la surface d'attaque externe scanne ce qui est accessible depuis internet indépendamment de la configuration interne, identifiant les services exposés qui ne devraient pas l'être. Les deux sont complémentaires : l'audit interne identifie les configurations problématiques dans les comptes connus, la surveillance externe identifie les exposures dans tous les comptes y compris les comptes shadow IT non inventoriés. Ensemble, ils fournissent une vue complète de la posture de sécurité cloud.
Les outils de scan de surface d'attaque externe, tels que ceux utilisés par les équipes de sécurité offensives et les programmes de bug bounty, appliquent à votre propre environnement les mêmes techniques que les attaquants utilisent pour identifier des cibles. Ces outils découvrent les services exposés via des scans de ports sur les plages IP de l'organisation, des recherches de certificats TLS dans les logs de transparence des certificats pour identifier les sous-domaines actifs, et des requêtes vers des agrégateurs de données comme Shodan pour trouver les services indexés associés aux netblocks de l'organisation. Appliqués régulièrement à votre propre infrastructure cloud, ils révèlent ce que les attaquants voient quand ils vous regardent.
La valeur de cette perspective externe ne peut pas être entièrement reproduite par les outils internes. Les outils CSPM analysent la configuration des ressources dans les comptes cloud connus. Les outils de scan de surface d'attaque externe découvrent les ressources cloud exposées quelle que soit leur appartenance à un compte connu ou inconnu. Cette différence fondamentale explique pourquoi les organisations qui ont des outils CSPM matures continuent à trouver des exposures inattendues quand elles effectuent des évaluations de surface d'attaque externe : les deux outils regardent la même infrastructure depuis des angles différents et voient des choses différentes.
L'intégration des résultats d'un scan de surface d'attaque externe dans un programme de gestion de la posture de sécurité cloud nécessite un processus pour traiter les ressources nouvellement découvertes qui ne sont pas dans l'inventaire existant. Chaque ressource nouvellement découverte doit être classée : est-elle connue et gérée mais manquante dans l'inventaire (problème de processus), est-elle du shadow IT actif (problème de gouvernance), ou est-elle une ressource abandonnée qui nécessite une décommission (problème d'hygiène) ? La réponse à cette question détermine l'action appropriée. La surveillance continue de la surface d'attaque externe qui déclenche ce processus de triage automatiquement pour chaque nouvelle découverte fournit le flux continu d'inventaire que les scans périodiques ne peuvent pas fournir.
La solution structurelle aux mauvaises configurations cloud récurrentes n'est pas uniquement la surveillance et la remédiation après le fait, mais l'intégration de la sécurité dans les processus de provisionnement eux-mêmes. Cette approche, communément désignée sous les termes "Security as Code" ou "Policy as Code", encode les exigences de sécurité dans les outils d'automatisation qui provisionnent l'infrastructure cloud, de sorte que les ressources non conformes ne peuvent pas être créées sans une approbation explicite.
Les outils de politique-as-code comme Open Policy Agent (OPA), HashiCorp Sentinel, ou les mécanismes natifs de guardrails des fournisseurs cloud (Service Control Policies dans AWS, Azure Policy dans Azure) permettent aux équipes de sécurité de définir des règles qui s'appliquent automatiquement à tout provisionnement d'infrastructure, quels que soient les individus ou les équipes qui provisionnent. Une politique qui interdit la création de buckets S3 accessibles publiquement sans approbation explicite du responsable de sécurité, appliquée via Service Control Policies au niveau de l'organisation AWS, prévient la catégorie entière d'exposition de bucket ouvert dans les comptes couverts par cette politique.
L'implémentation de cette approche nécessite une collaboration entre les équipes de sécurité et les équipes d'ingénierie qui fait souvent défaut dans les organisations où la sécurité est perçue comme un frein plutôt qu'un enabler. Les programmes qui positionnent la sécurité cloud comme un moyen d'accélérer le provisionnement en donnant aux développeurs des templates pré-approuvés et des guardrails qui préviennent les erreurs courantes, plutôt que comme une approbation bureaucratique qui ralentit le déploiement, sont ceux qui réussissent à intégrer la sécurité dans les workflows de développement. La surveillance externe de la surface d'attaque reste nécessaire même avec des guardrails de provisionnement en place, car elle couvre les comptes legacy et les exceptions qui échappent aux contrôles de provisionnement standardisés.
La mesure de la maturité de la sécurité cloud d'une organisation bénéficie d'une perspective externe en plus des évaluations internes. Les audits de sécurité cloud conduits par des tiers appliquent un regard frais sur la configuration et les processus de l'organisation, identifiant souvent des exposures que les équipes internes ont normalisées ou que les outils internes ont des angles morts pour détecter. Les évaluations de surface d'attaque externe, qui regardent l'infrastructure cloud de l'organisation depuis internet, sont une forme d'audit externe qui se concentre spécifiquement sur ce qui est accessible depuis l'extérieur plutôt que sur la configuration interne. La combinaison d'audits internes réguliers et d'évaluations de surface d'attaque externe continues fournit la couverture la plus complète de la posture de sécurité cloud.
Les campagnes de quishing distribuent des leurres via des canaux que la sécurité email interne ne peut pas scanner. Les expositions de mauvaises configurations cloud apparaissent sur les outils de reconnaissance des attaquants en quelques heures. Ces deux catégories de menaces dépendent d'une visibilité externe : voir ce à quoi ressemble votre organisation depuis l'extérieur, y compris les assets et les chemins d'attaque que les outils internes n'ont pas de contexte pour voir.
Defendis surveille votre surface d'attaque externe en continu et la corrèle avec le renseignement dark web, afin que vous connaissiez les assets exposés avant les attaquants et l'infrastructure de phishing ciblant vos utilisateurs avant que le premier credential ne soit volé.
Réservez une démo pour voir la surveillance de la surface d'attaque externe et du renseignement sur les menaces en action.
