Attaques du plan de contrôle cloud : pourquoi l'identité est la nouvelle kill chain

Réponse courte : dans le cloud, la kill chain commence souvent par l'identité, pas par un serveur vulnérable. Une fois le plan de contrôle atteint, les attaquants peuvent créer des ressources, modifier des permissions, voler des données et persister via les API. Les défenseurs doivent surveiller les identités cloud aussi étroitement que les charges de travail.

La sécurité des infrastructures traditionnelles imaginait des attaquants progressant depuis des hôtes exposés vers les réseaux internes. Les environnements cloud ont changé ce schéma. Un seul identifiant peut atteindre le plan de gestion, là où les ressources sont créées, les politiques attribuées, les journaux configurés et l'automatisation exécutée.

Cette couche de gestion, c'est le plan de contrôle cloud. Elle dispose d'une autorité très large, par conception. Vos ingénieurs l'utilisent pour déployer des applications, dimensionner l'infrastructure, configurer le stockage, faire tourner les secrets et connecter des services. Les attaquants la convoitent pour exactement les mêmes raisons. Un accès au plan de contrôle peut rendre inutile l'exploitation des charges de travail individuelles.

Google Cloud M-Trends et d'autres rapports d'incidents montrent régulièrement à quel point les intrusions cloud reposent sur l'identité, les identifiants et la configuration. Les attaquants n'ont pas toujours besoin de zero-day. Ils ont besoin d'un jeton exposé disposant des bonnes permissions.

Le plan de contrôle comme surface d'attaque

Le plan de contrôle cloud comprend :

• Les utilisateurs IAM, rôles, comptes de service et politiques.
• Les clés API, jetons d'accès et jetons de rafraîchissement.
• Les consoles cloud et les outils en ligne de commande.
• Les pipelines d'infrastructure-as-code.
• Les API de gestion Kubernetes.
• Les contrôles de journalisation, de supervision et d'audit.
• Les API de stockage, de calcul, de réseau et de gestion des secrets.

Chacune de ces surfaces peut devenir un maillon d'un chemin d'attaque. Un attaquant disposant d'un accès cloud en lecture seule peut inventorier les actifs et identifier ses cibles. Un attaquant autorisé à créer des clés peut persister. Un attaquant capable de modifier des politiques peut élever ses privilèges. Un attaquant capable de désactiver la journalisation peut se dissimuler.

Le plan de contrôle abolit les distances. Un poste de développeur compromis devient une compromission cloud s'il contient le mauvais jeton.

Chemins d'accès initial les plus courants

Les chemins les plus fréquents n'ont rien d'exotique :

• Clés d'accès committées dans des dépôts.
• Jetons de comptes de service exposés dans la CI/CD.
• Malwares infostealer moissonnant les identifiants des CLI cloud.
• Sessions SSO obtenues par phishing.
• Consent phishing OAuth visant les administrateurs cloud.
• Abus du service de métadonnées depuis une charge de travail vulnérable.
• Intégrations tierces surprivilégiées.
• Identités fédérées mal configurées.

Ces chemins recoupent la sécurité des identités non humaines, le vol de jetons de session et le LLMjacking. Dans chaque cas, l'identifiant est le pont entre une compromission locale et un problème à l'échelle de tout le cloud.

Ce que font les attaquants après un accès au plan de contrôle

Une fois à l'intérieur, les attaquants commencent souvent par énumérer. Ils listent les utilisateurs, les rôles, les buckets de stockage, les secrets, les registres de conteneurs, les instances de calcul, les régions et les règles réseau. L'énumération leur indique ce qui a de la valeur et de quelles permissions ils disposent.

Ils cherchent ensuite à persister. Ils peuvent créer de nouvelles clés d'accès, ajouter un fournisseur d'identité fédérée, modifier des politiques de confiance, créer un compte de service ou déposer des identifiants dans l'automatisation.

Vient enfin l'impact. Selon leur motivation, les attaquants peuvent :

• Lire des données de stockage sensibles.
• Démarrer des instances de calcul pour du cryptominage ou de l'abus d'IA.
• Exfiltrer des bases de données ou des sauvegardes.
• Désactiver la journalisation ou modifier la rétention.
• Ajouter des règles de pare-feu.
• Créer des snapshots.
• Modifier des fonctions serverless.
• Déployer des conteneurs backdoorés.
• Accéder à des secrets et les réutiliser ailleurs.

Les attaques cloud reposent massivement sur les API. La bonne nouvelle, c'est que les API produisent des journaux. La difficulté est de rendre ces journaux exploitables.

Signaux de détection

La détection sur le plan de contrôle commence par des références comportementales. Quelles identités appellent habituellement quelles API, depuis quels réseaux, dans quelles régions et à quelles heures ?

Les alertes utiles incluent :

• Création d'une nouvelle clé d'accès pour une identité ancienne ou privilégiée.
• Changements de politiques ajoutant des permissions larges.
• Utilisation des comptes root ou des comptes de secours (break-glass).
• Appels d'API depuis des ASN ou des pays inhabituels.
• Première utilisation d'un service sensible.
• Journalisation désactivée, rétention réduite ou trails modifiés.
• Secrets lus par des principaux inhabituels.
• Instances de calcul démarrées dans des régions non utilisées.
• Sondages de permissions échoués suivis d'un succès.
• Activité provenant de proxys, VPN, Tor ou d'hébergeurs cloud connus pour l'abus.

N'examinez pas ces événements comme des alertes isolées. Les attaquants enchaînent les actions. Une connexion suspecte suivie d'une énumération IAM, d'une création de clé et d'un listing de stockage constitue un seul et même récit.

Playbook de réponse

Lorsqu'une compromission du plan de contrôle est suspectée :

1. Préservez immédiatement les journaux.
2. Désactivez ou faites tourner les identifiants concernés.
3. Identifiez toutes les actions réalisées par l'identité compromise.
4. Passez en revue les clés, utilisateurs, rôles, politiques, comptes de service et relations de confiance créés récemment.
5. Vérifiez si la journalisation, la supervision ou les alertes ont été modifiées.
6. Inspectez les accès au stockage, les lectures de secrets, les démarrages de calcul et les changements réseau.
7. Enrichissez les IP sources et les domaines de callback.
8. Recherchez la même infrastructure dans les autres comptes et tenants.

Le confinement doit être mené avec prudence. Si vous détruisez des preuves ou révoquez la mauvaise automatisation de production sans planification, vous provoquez des interruptions de service. Préparez des runbooks d'incident spécifiques au cloud avant l'incident.

Priorités de prévention

Utilisez la fédération d'identité et des identifiants à durée de vie courte plutôt que des clés longue durée. Restreignez la portée des rôles. Séparez les responsabilités entre environnements. Exigez une approbation pour les changements de politiques sensibles. Surveillez toutes les API d'administration. Protégez les systèmes CI/CD comme des acteurs cloud privilégiés.

Appliquez des service control policies ou des garde-fous équivalents pour empêcher les actions dangereuses même en cas d'identité compromise. Par exemple : bloquer les régions inutilisées, empêcher la suppression des journaux, interdire le stockage public et restreindre la création de clés.

Pour les accès humains, exigez un MFA résistant au phishing pour les administrateurs. Pour les accès machine, privilégiez les workload identities et faites tourner agressivement les secrets statiques.

Cartographier les chemins d'attaque cloud

Le risque lié au plan de contrôle s'explique bien plus facilement quand les équipes peuvent visualiser les chemins d'attaque. Une bonne cartographie part des identités, puis les relie aux permissions, aux ressources, aux relations de confiance et à l'exposition réseau. La carte doit répondre à la question : si ce jeton est volé, que peut-il lire, modifier, créer ou supprimer ?

Ne cartographiez pas uniquement les administrateurs. Beaucoup d'incidents réels démarrent avec des permissions modérées qui s'enchaînent jusqu'à l'impact. Un rôle capable de lire des secrets peut exposer un mot de passe de base de données. Un jeton CI capable de mettre à jour un déploiement peut y implanter une porte dérobée. Un compte de service capable d'endosser un autre rôle peut devenir privilégié via les relations de confiance. Les chemins d'attaque sont souvent des combinaisons, pas une unique permission dangereuse.

Ajoutez du contexte externe à la carte. Les charges de travail exposées sur Internet, les dépôts publics, les systèmes de CI tiers, les prestataires distants et les intégrations SaaS sont des endroits classiques où les identifiants fuient ou sont détournés. Si l'un de ces points d'entrée mène à un rôle cloud très large, priorisez-le.

Revoyez la carte après chaque changement majeur d'infrastructure. Les permissions cloud dérivent vite. Une permission temporaire de débogage devient permanente. Un nouveau rôle d'automatisation hérite accidentellement d'un accès trop large. Une fusion ou une nouvelle intégration SaaS introduit des relations de confiance que personne ne revoit.

Exigences de journalisation

La défense du plan de contrôle cloud dépend des journaux d'audit. Ils doivent être activés avant l'incident, protégés contre la modification, centralisés et conservés assez longtemps pour permettre l'investigation. Les attaquants tentent souvent de désactiver ou de raccourcir la journalisation après leur accès. Cette action à elle seule doit être traitée en sévérité haute.

Collectez les journaux d'identité, d'API, de réseau, de stockage, de gestionnaire de secrets, de Kubernetes et de CI/CD. Normalisez des champs tels que le principal, l'IP source, le user agent, le nom d'API, la ressource, la région, le résultat et l'identifiant de requête. Sans normalisation, les investigations multi-comptes deviennent lentes.

Stockez les journaux dans un compte ou un projet de sécurité distinct, avec des contrôles write-once lorsque c'est possible. L'identité qui administre la production ne doit pas pouvoir effacer sa propre piste d'audit.

Synthèse pour le comité de direction

Auprès des dirigeants, les attaques du plan de contrôle cloud peuvent être présentées comme une « compromission du plan de gestion ». L'attaquant ne s'introduit pas dans un serveur : il utilise les mêmes API que vos équipes pour piloter l'entreprise. C'est pourquoi un seul identifiant peut avoir un impact très large.

Parmi les indicateurs métier utiles : le nombre de clés cloud longue durée, le pourcentage de rôles privilégiés revus récemment, le nombre de régions inutilisées bloquées, le délai de désactivation d'une identité compromise et le pourcentage d'appels d'API sensibles couverts par des alertes.

Le message pour le conseil d'administration est simple : la résilience du cloud dépend de la résilience de l'identité. La gestion des correctifs compte toujours, mais des identifiants compromis peuvent contourner entièrement des charges de travail parfaitement à jour.

Exercice sur table

Entraînez-vous sur un scénario où un jeton CI est volé par une dépendance malveillante. L'attaquant s'en sert pour endosser un rôle de déploiement, lire des secrets, créer une nouvelle clé d'accès, démarrer du calcul dans une région inutilisée et désactiver un puits de journaux.

L'exercice doit tester qui peut révoquer le jeton, à quelle vitesse les journaux sont préservés, si les garde-fous bloquent les régions inutilisées, si les lectures de secrets sont visibles et si la réputation des IP sources est accessible directement dans le workflow d'investigation. L'objectif est de découvrir les lacunes avant que la même chaîne ne se déroule sous pression.

Feuille de route 90 jours pour le plan de contrôle

Dans les 30 premiers jours, identifiez les accès privilégiés permanents, les clés longue durée, les identités inactives, les régions inutilisées et les angles morts de journalisation. Supprimez ce qui est manifestement superflu. Activez des alertes sur la création de nouvelles clés, les changements de journalisation et les appels d'API d'administration depuis des réseaux inhabituels.

À 60 jours, introduisez des garde-fous plus stricts. Bloquez les régions inutilisées, protégez les puits de journaux, exigez des approbations pour les changements IAM larges et séparez les identités de production de celles de développement. Traitez les rôles CI/CD comme des identités cloud privilégiées, pas comme de la simple automatisation.

À 90 jours, mettez en place une revue continue des chemins d'attaque. Cartographiez quelles identités peuvent atteindre les secrets, les données de production, les systèmes de déploiement et les rôles d'administration. Priorisez les chemins qui partent de charges de travail exposées, de postes de développeurs, d'intégrations tierces ou de systèmes de build, car ce sont des points d'entrée classiques.

Facteurs humains

Les équipes cloud résistent souvent aux contrôles qui ralentissent les déploiements. Les équipes sécurité doivent miser sur les « paved roads » : gabarits, rôles approuvés, politiques réutilisables et contrôles automatisés qui font du chemin sûr le chemin le plus rapide. L'objectif n'est pas d'obliger les ingénieurs à ouvrir un ticket pour le moindre changement. L'objectif est d'empêcher qu'un seul jeton volé ne donne le contrôle total de l'environnement.

Contenus de détection à construire

Construisez vos détections autour de séquences dangereuses, pas seulement d'événements isolés. Une connexion depuis un ASN inhabituel, suivie d'une énumération IAM, de changements de politiques, d'une création de clé, de lectures de secrets et de démarrages de calcul, raconte une intrusion sur le plan de contrôle. Chaque événement pris isolément peut sembler explicable ; ensemble, ils sont urgents.

Priorisez les événements qui dégradent la visibilité. Désactiver la journalisation, modifier la rétention, supprimer des trails ou changer les destinations d'alerte doivent réveiller immédiatement les répondants. Un attaquant qui touche à la journalisation sait qu'il se trouve dans la couche de gestion.

Surveillez également les appels d'API refusés. Le sondage de permissions aide l'attaquant à comprendre ce que l'identité volée peut faire. Une rafale d'appels refusés suivie d'actions sensibles réussies est souvent plus révélatrice que le succès seul.

Intégrez les événements de coût et de quota à la même bibliothèque de détection. Des démarrages de calcul inattendus, une croissance du stockage et l'usage de services coûteux peuvent signaler un abus même quand l'activité IAM paraît légitime. Les attaquants du plan de contrôle utilisent souvent des API légitimes pour un travail illégitime : les anomalies opérationnelles sont donc de la télémétrie de sécurité.

Enfin, examinez les journaux des brokers d'accès si vos ingénieurs passent par des portails SSO, des bastions ou des systèmes d'accès à privilèges. Ces outils montrent souvent le premier point où une identité humaine ou automatisée est entrée dans le périmètre sensible du contrôle cloud.

Ces événements de broker clarifient les chronologies lorsque plusieurs comptes cloud sont touchés rapidement.

Ils révèlent aussi les brokers d'accès inhabituels.

À retenir côté threat intelligence

Les attaques du plan de contrôle cloud sont des attaques sur l'identité aux conséquences infrastructurelles. Le signal suspect peut être un appel d'API depuis une IP inconnue, une nouvelle clé ou un changement de politique qui semble purement administratif jusqu'à ce qu'on le replace dans son contexte.

isMalicious aide à enrichir les IP sources, les domaines et les infrastructures observés dans les journaux d'audit cloud. Quand une identité se met à piloter votre cloud depuis une infrastructure suspecte, le contexte de réputation raccourcit le chemin entre l'alerte et le confinement.