AWS élargit officiellement le périmètre de Security Hub, son service de centralisation des opérations de sécurité, à un terrain jusque-là extérieur à son propre nuage : Microsoft Azure. L’annonce marque une étape importante pour AWS, qui commence à faire de Security Hub une console de sécurité réellement multicloud, tout en ajoutant de nouveaux outils destinés à protéger les charges de travail d’intelligence artificielle.
La nouveauté est double. D’un côté, les équipes sécurité peuvent désormais surveiller certains actifs Azure depuis l’environnement AWS. De l’autre, AWS renforce GuardDuty et Security Hub autour des usages IA, avec des fonctions pensées pour détecter les abus de modèles, les tentatives d’injection de prompt ou encore les consommations frauduleuses de ressources d’inférence.
Selon les éléments annoncés, quatre mises à jour structurent ce lancement : la surveillance native de ressources Azure dans Security Hub, Amazon GuardDuty AI Protection, les enquêtes assistées par IA dans GuardDuty et un inventaire des actifs IA intégré à Security Hub. À l’exception des enquêtes assistées par IA, actuellement disponibles en préversion dans 10 régions AWS, ces fonctionnalités sont en disponibilité générale.
AWS fait entrer Azure dans Security Hub
La mise à jour la plus symbolique concerne la prise en charge de Microsoft Azure. Pour la première fois, Security Hub surveille nativement des ressources qui ne se trouvent pas dans AWS. Jusqu’ici, le service était principalement conçu pour agréger, prioriser et automatiser les alertes de sécurité au sein de l’écosystème AWS.
Security Hub peut désormais découvrir automatiquement plusieurs types de ressources Azure utilisées par les clients, notamment :
- les machines virtuelles Azure ;
- les images de conteneurs ;
- les applications serverless de type Azure Function Apps ;
- les identités et éléments associés à la gestion des accès.
Une fois ces ressources détectées, le service les analyse afin d’identifier des erreurs de configuration, des expositions à Internet non souhaitées ou encore des logiciels vulnérables. AWS indique s’appuyer notamment sur le référentiel CIS Azure Foundations Benchmark, un standard utilisé pour évaluer la posture de sécurité des environnements Azure.
L’intérêt opérationnel est évident : les résultats liés à Azure apparaissent dans la même file de priorisation que les alertes AWS. Les équipes peuvent donc les traiter depuis un point central, sans devoir basculer constamment entre plusieurs consoles ou répliquer manuellement leurs processus.
Autre point important : ces alertes Azure peuvent déclencher les flux d’automatisation déjà construits par les équipes autour de Security Hub. Pour une organisation qui utilise AWS comme centre de gravité de ses opérations de sécurité, cela réduit le coût d’intégration d’un environnement Azure dans les procédures existantes.
Un signal fort pour les entreprises multicloud
Cette évolution répond à une réalité devenue courante dans les grandes organisations : les charges de travail ne restent plus confinées dans un seul cloud. Une application peut tourner sur AWS, s’appuyer sur des services Microsoft pour l’identité ou la productivité, et consommer des API externes pour certaines fonctions d’IA.
Dans ce contexte, la sécurité souffre souvent d’un problème de fragmentation. Chaque plateforme dispose de ses propres outils, de ses propres métriques, de ses propres alertes et de ses propres règles. Les équipes SOC doivent alors composer avec un volume de signaux difficile à corréler.
La promesse d’AWS est donc simple : si les charges de travail se déplacent vers plusieurs clouds, la sécurité doit les suivre. Security Hub devient ainsi un candidat au rôle de console centrale, au moins pour les environnements combinant AWS et Azure.
Côté tarification, AWS indique que la surveillance d’une ressource Azure coûte le même prix que celle de son équivalent AWS, sans frais de plateforme supplémentaires. Une période d’essai séparée de 30 jours est également prévue, ce qui devrait faciliter les tests pour les équipes sécurité et cloud.
GuardDuty s’attaque aux menaces propres à l’IA
Le deuxième volet de l’annonce concerne la protection des charges de travail IA. Contrairement au support Azure, GuardDuty AI Protection reste fortement centré sur l’écosystème AWS. Le service vise surtout les usages liés à Amazon Bedrock et Amazon SageMaker, deux briques clés de l’offre IA d’AWS.
Les menaces ciblées ne sont pas théoriques. Avec l’adoption rapide des modèles de fondation, les attaquants cherchent désormais à exploiter les accès aux services d’IA comme ils exploitaient auparavant les accès aux ressources de calcul ou de stockage. Un compte compromis peut par exemple être utilisé pour lancer massivement des inférences coûteuses, détourner un modèle ou tester des prompts malveillants.
GuardDuty AI Protection cherche notamment à détecter :
- des invocations anormales de modèles ;
- des tentatives d’injection de prompt, notamment via une intégration avec Bedrock Guardrails ;
- des usages suspects de comptes ou d’identifiants compromis ;
- des comportements assimilables à du cost harvesting, où un attaquant génère des coûts d’inférence sur le compte d’une victime.
Ce dernier point est particulièrement sensible pour les directions techniques. Une compromission discrète d’un compte de service peut ne pas provoquer immédiatement de panne visible, mais elle peut entraîner une facture inhabituelle si des appels à un modèle sont déclenchés en masse. Dans certains cas, l’équipe finance peut détecter l’incident avant l’équipe sécurité, ce qui illustre le besoin d’outils spécialisés.
Des enquêtes assistées par IA pour réduire le bruit
AWS ajoute également une capacité d’enquête assistée par IA dans GuardDuty. Elle est disponible en préversion dans 10 régions AWS et vise à accélérer la première analyse des alertes.
Le principe est de produire automatiquement un premier tri entre les signaux réellement préoccupants et le bruit opérationnel. Chaque investigation fournit une conclusion, un score de confiance, une classification selon MITRE ATT&CK et des recommandations de remédiation. L’analyse s’appuie sur 90 jours d’activité liée afin de replacer l’événement dans son contexte.
Pour les équipes SOC, l’intérêt est concret. Dans un environnement cloud actif, les alertes peuvent se compter par centaines ou milliers. La difficulté n’est pas seulement de les recevoir, mais de comprendre lesquelles exigent une action immédiate. Si l’IA parvient à résumer les événements, corréler les signaux et proposer une marche à suivre, elle peut réduire le temps passé sur les investigations de niveau 1.
AWS affirme que ce type d’analyse peut être réalisé en quelques minutes là où il fallait auparavant plusieurs heures. Comme toujours avec les outils d’assistance automatisée, la valeur réelle dépendra de la qualité des recommandations, du taux de faux positifs et de la capacité des équipes à intégrer ces résultats dans leurs processus existants.
Un inventaire IA intégré à Security Hub
La dernière brique annoncée est un inventaire des actifs IA inclus dans l’offre Security Hub Essentials sans coût supplémentaire. Son objectif est de donner aux organisations une vue consolidée de leurs ressources liées à l’intelligence artificielle.
L’inventaire couvre plusieurs catégories d’actifs :
- les services managés comme Bedrock, SageMaker et AgentCore ;
- les modèles exécutés par les clients sur EC2, ECS ou EKS ;
- les API de modèles externes appelées par des charges de travail internes ;
- les ressources d’infrastructure sous-jacentes associées à ces usages IA.
Cette visibilité est devenue un enjeu majeur. Beaucoup d’organisations déploient rapidement des fonctions IA dans leurs produits internes ou externes, parfois sans gouvernance homogène. Le risque n’est pas uniquement technique : il concerne aussi les coûts, la conformité, la protection des données et la traçabilité des usages.
En reliant les actifs IA à l’infrastructure qui les supporte et aux alertes GuardDuty correspondantes, AWS cherche à transformer l’inventaire en outil d’action, pas seulement en catalogue. Une équipe sécurité peut ainsi repérer non seulement qu’un modèle existe, mais aussi s’il est lié à une activité suspecte, à une exposition réseau ou à une configuration fragile.
AWS arrive sur un marché déjà très disputé
Cette extension multicloud ne fait pas d’AWS un pionnier absolu. Microsoft propose déjà, via Defender for Cloud, des fonctions de gestion de posture de sécurité pour AWS depuis fin 2021 et pour Google Cloud depuis début 2022. De son côté, Google a renforcé sa position dans la sécurité multicloud avec l’acquisition de Wiz, annoncée pour 32 milliards de dollars, une plateforme déjà reconnue pour sa couverture des grands clouds publics.
Le marché de la sécurité IA est lui aussi très concurrentiel. Des acteurs comme Wiz, Palo Alto Networks ou CrowdStrike commercialisent déjà des solutions d’AI security posture management, avec des promesses proches : identifier les usages IA, cartographier les risques, surveiller les accès et détecter les comportements anormaux.
La stratégie d’AWS consiste donc à capitaliser sur un avantage différent : son intégration native avec les services cloud déjà utilisés par ses clients. Pour une entreprise fortement ancrée dans AWS mais exploitant aussi Azure, l’idée d’une console unique et d’une facture centralisée peut être séduisante.
La limite actuelle reste toutefois claire : Security Hub ne couvre pour l’instant que Microsoft Azure en dehors d’AWS. AWS n’a pas indiqué si Google Cloud serait prochainement pris en charge. Or, pour de nombreuses grandes entreprises, le multicloud signifie bien plus qu’un duo AWS-Azure.
Ce que cela change pour les équipes sécurité
Pour les responsables sécurité, cette annonce doit être lue comme une évolution pragmatique plutôt qu’une révolution immédiate. Elle ne supprime pas le besoin d’une stratégie de sécurité cloud complète, mais elle peut simplifier certains cas d’usage.
Les équipes qui utilisent déjà Security Hub peuvent envisager plusieurs actions concrètes :
- tester la découverte automatique des ressources Azure pendant la période d’essai ;
- comparer les alertes Azure remontées par Security Hub avec celles des outils Microsoft déjà en place ;
- vérifier si les workflows d’automatisation existants fonctionnent correctement avec les résultats Azure ;
- évaluer GuardDuty AI Protection sur les charges Bedrock et SageMaker les plus sensibles ;
- utiliser l’inventaire IA pour identifier les modèles, API et services déployés hors des circuits habituels de gouvernance.
Le principal gain potentiel se situe dans la réduction de la dispersion opérationnelle. Moins de consoles, moins de formats d’alertes, moins de silos entre équipes cloud et cybersécurité. Mais cette consolidation ne sera utile que si les résultats sont suffisamment fiables et actionnables.
Un pas vers le multicloud, mais pas encore tout le multicloud
Avec cette mise à jour, AWS reconnaît explicitement que ses clients ne vivent pas dans un monde mono-cloud. En ouvrant Security Hub à Azure, le groupe accepte de surveiller une partie du terrain de Microsoft, tout en renforçant ses propres défenses autour de l’IA générative et des modèles de fondation.
Le mouvement est stratégique. Il répond à la montée des architectures multicloud, à l’explosion des usages IA et à la pression des équipes sécurité qui cherchent à réduire la complexité. Mais il soulève aussi une question immédiate : jusqu’où AWS ira-t-il dans cette ouverture ?
Si Security Hub reste limité à AWS et Azure, son positionnement multicloud restera partiel. Si Google Cloud et davantage de services externes rejoignent la couverture, AWS pourrait transformer Security Hub en pilier plus large de la sécurité cloud moderne. Pour l’instant, le message est clair : AWS veut que sa console de sécurité accompagne les charges de travail, même lorsqu’elles passent chez Microsoft.