La réponse courte
AWS a transformé Security Hub en un plan de contrôle de sécurité multicloud et conscient de l'IA, disponible depuis le 14 juillet 2026. Il surveille désormais nativement les machines virtuelles Microsoft Azure, les images de conteneurs, les Function Apps et les identités par rapport au CIS Azure Foundations Benchmark, faisant remonter ces résultats dans la même console et les mêmes workflows que les résultats AWS. Parallèlement, GuardDuty AI Protection est devenu disponible pour Amazon Bedrock et SageMaker, signalant les invocations de modèles anormales, les tentatives d'injection de prompt et le « cost harvesting » piloté par des identifiants volés, avec un inventaire IA et une préversion d'investigations pilotées par l'IA par-dessus.
Pour les équipes qui exécutent des charges sur plus d'un cloud — c'est-à-dire la plupart —, le gain pratique est : moins d'angles morts et un seul endroit pour trier le risque. Le signal plus profond est que les charges IA sont désormais une surface d'attaque à part entière, avec leurs propres modes de défaillance, et que les grands clouds se pressent de les instrumenter. Aucun de ces deux changements ne vous décharge de votre propre travail de sécurité ; tous deux relèvent la barre de ce que « nous avons de la visibilité » est censé vouloir dire.
Qu'a réellement livré AWS ?
Le changement phare : Security Hub — le service AWS de collecte et de priorisation des résultats de sécurité — n'est plus réservé à AWS. Ses capacités multicloud pour Microsoft Azure sont désormais disponibles pour tous les clients, permettant à Security Hub de découvrir et de surveiller nativement les ressources Azure telles que les machines virtuelles, les images de conteneurs, les Function Apps et les identités d'utilisateurs. Ces ressources sont évaluées par rapport au CIS Azure Foundations Benchmark, et leurs résultats arrivent dans le même format, la même automatisation et les mêmes workflows de réponse que les résultats AWS, si bien qu'une équipe de sécurité peut évaluer le risque sur les deux clouds via une seule interface. Les ressources Azure sont facturées aux tarifs AWS équivalents, sans frais séparés.
Le deuxième changement cible l'IA. GuardDuty AI Protection, également disponible avec un essai gratuit de 30 jours, surveille les invocations de modèles anormales sur Amazon Bedrock et SageMaker, s'intègre à Bedrock Guardrails pour détecter les tentatives d'injection de prompt, et recherche le « cost harvesting » — où des identifiants volés servent à accumuler de lourdes factures sur des modèles de fondation coûteux. AWS a couplé cela à un inventaire IA dans Security Hub qui découvre les actifs IA à l'échelle de l'organisation, depuis l'usage géré de Bedrock, SageMaker et AgentCore jusqu'aux modèles auto-hébergés sur EC2, ECS et EKS et aux points de terminaison de modèles externes. Pour les équipes qui démarrent leurs premières charges IA et données, cet inventaire fait la différence entre deviner où tournent les modèles et le savoir. Une préversion des investigations pilotées par l'IA de GuardDuty, active dans dix régions AWS, utilise des agents IA pour trier les alertes et les rattacher à MITRE ATT&CK.
AWS a présenté le mouvement comme le comblement d'une lacune, et non la fermeture du marché. « Security Hub s'étend d'un fournisseur cloud à l'autre, en commençant par Azure et en s'élargissant ensuite », a déclaré Michael Fuller, directeur des services de sécurité d'AWS, qui a aussi posé le problème central comme une affaire de vitesse et de corrélation : « Le plus dur est de les comprendre, de les relier et d'agir avant l'attaquant, et de le faire à la vitesse à laquelle les attaques se déplacent aujourd'hui. » Cela reflète là où les opérations de sécurité cloud font réellement mal — non pas un manque d'alertes, mais l'effort de coudre les signaux de nombreux outils en une seule image actionnable. Les équipes qui tournent surtout sur AWS mais gardent un pied dans Azure sont le public immédiat.
Pourquoi une sécurité multicloud et consciente de l'IA compte-t-elle maintenant ?
Deux tendances structurelles font que cela porte. La première : le multicloud est la norme, pas l'exception. Acquisitions, préférences d'équipes, services best-of-breed et exigences régionales poussent toutes les entreprises vers plus d'un fournisseur, et chaque cloud est traditionnellement venu avec son propre outillage de sécurité et sa propre console. Chaque écran supplémentaire est un endroit où une mauvaise configuration se cache et où une alerte passe inaperçue parce que personne n'est propriétaire de cet écran. Une vue inter-cloud native — même une première version qui commence par Azure — s'attaque directement à cette fragmentation.
La seconde : les charges d'IA générative sont devenues une surface réelle et exploitable, avec des modes de défaillance que l'outillage classique n'a jamais été conçu pour voir. L'injection de prompt peut transformer un modèle ou un agent en initié involontaire ; un point de terminaison de modèle sur-privilégié peut fuiter des données ; et le cost harvesting montre à quelle vitesse une clé volée se convertit en une facture d'inférence à cinq ou six chiffres, parce que la ressource abusée est coûteuse à dessein. Instrumenter Bedrock et SageMaker précisément pour ces schémas reconnaît que « sécuriser la VM et le réseau » ne couvre plus toute la surface d'attaque quand une partie de votre stack est un modèle de fondation.
Il vaut la peine d'être précis sur le périmètre. C'est une expansion significative, pas une plateforme de sécurité multicloud universelle : la couverture commence par un ensemble défini de types de ressources Azure et de vérifications de benchmark, Google Cloud n'est pas dans cette version, et les détections IA les plus poussées sont ancrées aux propres services de modèles d'AWS. La direction est claire, et les plateformes rivales répondront, mais les équipes devraient dimensionner la capacité à ce qu'elle couvre aujourd'hui, plutôt qu'à la catégorie marketing qu'elle vise.
Qu'est-ce que cela change dans votre stack ?
La première chose que cela change, c'est votre excuse pour les angles morts. Si vous exécutez des charges de production sur AWS et Azure et que vous corréliez leur posture de sécurité à la main — ou pas du tout —, il existe désormais un chemin natif vers une vue unique, et les auditeurs attendront de plus en plus que vous utilisiez quelque chose de ce genre. Des résultats consolidés, des workflows communs et un benchmark partagé rendent « on ne l'a pas vu dans l'autre console » une réponse plus faible après un incident. C'est une bonne pression à subir, mais c'est une pression : quelqu'un doit activer la couverture, ajuster les exceptions de benchmark et traiter réellement la file.
La deuxième : vos charges IA sont désormais inventoriées et surveillées d'une manière qui expose des lacunes que vous n'aviez peut-être jamais cartographiées. Un inventaire IA qui fait remonter les modèles auto-hébergés sur EC2, ECS et EKS, plus les points de terminaison externes, trouvera presque certainement un usage de modèles qui a poussé de façon organique en dehors de votre revue de sécurité. Détecter l'injection de prompt et le cost harvesting est précieux, mais cela rend aussi visible la part de votre empreinte IA qui tourne avec de larges permissions et une surveillance ténue. Pour les équipes FinTech et santé réglementées, cet inventaire recoupe directement le RGPD, SOC 2 et les obligations de résidence des données — savoir où tournent les modèles et ce qu'ils peuvent atteindre est désormais un artefact de conformité, pas une simple commodité d'exploitation. C'est là qu'un audit de sécurité ciblé de votre périmètre IA et multicloud se rentabilise.
Le troisième risque est le discret : prendre un tableau de bord pour une défense. Une vue sur écran unique réduit la fatigue liée aux alertes et les angles morts, mais le modèle de responsabilité partagée n'a pas bougé. La détection native ne configure pas l'accès au moindre privilège, ne segmente pas un réseau, ne fait pas tourner une clé fuitée et ne contient pas un incident. La consolidation fournisseur porte aussi son propre compromis : une intégration plus profonde dans l'écosystème d'un fournisseur peut discrètement augmenter le coût de rester réellement multicloud. La capacité est réelle ; le travail qu'elle implique reste le vôtre.
Ce que cela signifie pour les équipes logicielles américaines & françaises
Si vous tournez déjà sur AWS et touchez à Azure, c'est une mise à niveau à faible friction qui mérite d'être pilotée délibérément. Activez d'abord la couverture Azure de Security Hub sur un abonnement non critique, confirmez que les résultats du benchmark CIS s'alignent sur des propriétaires et des chemins de remédiation que vous avez réellement, et décidez où une vue véritablement inter-cloud s'inscrit face à un CNAPP best-of-breed que vous utilisez déjà. L'essai gratuit de 30 jours de GuardDuty AI Protection est un moyen propre de mesurer le rapport signal/bruit sur votre trafic Bedrock et SageMaker réel avant de vous engager.
Si vous construisez des fonctionnalités IA, traitez l'inventaire IA comme un catalyseur. Utilisez-le pour énumérer chaque endroit où un modèle tourne — géré et auto-hébergé —, puis comblez les lacunes évidentes : moindre privilège sur les points de terminaison de modèles, garde-fous contre l'injection de prompt, hygiène stricte des identifiants et alerting sur les invocations et les dépenses anormales. Le cost harvesting rappelle qu'une clé IA porte désormais de l'argent réel et doit être protégée comme telle. Intégrer ces contrôles tôt dans votre socle de sécurité entreprise coûte bien moins cher que de les rétro-adapter après un incident ou un constat d'audit.
Il y a aussi une lecture côté livraison. Un outillage consolidé n'aide que si quelqu'un possède la console, ajuste les règles et traite les résultats ; un service de sécurité que personne ne surveille n'est qu'une facture plus lourde. Les équipes qui bâtissent une capacité permanente à gérer la posture cloud et la sécurité IA comme un travail de routine — en interne ou via une équipe d'ingénierie dédiée — transforment des annonces comme celle-ci en un changement de configuration. Les équipes qui boulonnent des outils sans propriétaire les transforment en logiciels dormants et sont surprises quand la lacune qu'elles croyaient couverte s'ouvre sous un incident.
Quoi faire cette semaine
Transformez l'annonce en un court passage de posture concret plutôt qu'en un débat d'achat.
- Cartographiez vos clouds et vos propriétaires. Listez chaque compte AWS et Azure en production et nommez qui possède les résultats de sécurité pour chacun — vous ne pouvez pas consolider ce que vous n'avez pas inventorié.
- Pilotez la couverture Azure. Activez la surveillance Azure de Security Hub sur un abonnement à faible risque et vérifiez les résultats du benchmark CIS face à de vrais chemins de remédiation.
- Testez AI Protection. Utilisez l'essai de 30 jours de GuardDuty AI Protection sur du trafic Bedrock/SageMaker réel pour jauger la qualité du signal et détecter les invocations anormales.
- Exécutez l'inventaire IA. Énumérez les modèles gérés et auto-hébergés, y compris sur EC2/ECS/EKS et les points de terminaison externes, et signalez tout ce qui tourne avec de larges permissions.
- Verrouillez les identifiants IA. Faites tourner et limitez les clés d'accès aux modèles, imposez le moindre privilège sur les points de terminaison et ajoutez de l'alerting sur les volumes d'invocation et les dépenses inhabituels.
- Décidez de la frontière d'outillage. Choisissez délibérément où une vue inter-cloud remplace ou complète les outils de sécurité best-of-breed existants, et évitez les consoles en double que personne ne surveille.
Une console de sécurité inter-cloud avec détection native des menaces IA est un vrai pas vers l'alignement de l'outillage sur la façon dont les logiciels sont réellement construits et exploités aujourd'hui. Les équipes qui la pilotent délibérément, gardent une propriété claire et traitent les charges IA comme une surface d'attaque à part entière absorberont ce type de nouvelle comme une amélioration de routine. Les équipes qui supposent qu'un nouveau tableau de bord équivaut à une nouvelle sécurité apprendront, à la dure, que visibilité et défense ne sont pas la même chose.
Questions fréquentes
Qu'est-ce qu'AWS a ajouté à Security Hub ?
Le 14 juillet 2026, AWS a rendu les capacités multicloud de Security Hub disponibles pour Microsoft Azure. Le service peut désormais découvrir et surveiller nativement les machines virtuelles Azure, les images de conteneurs, les Function Apps et les identités, en les évaluant par rapport au CIS Azure Foundations Benchmark. Les résultats Azure utilisent le même format, la même automatisation et les mêmes workflows de réponse que les résultats AWS et apparaissent dans une seule interface. AWS a également ajouté GuardDuty AI Protection et un inventaire IA dans Security Hub, étendant la couverture d'AWS uniquement à une vue multicloud et consciente de l'IA.
Qu'est-ce que le cost harvesting IA ?
Le cost harvesting est une attaque où quelqu'un utilise des identifiants cloud volés pour invoquer des modèles de fondation coûteux — par exemple sur Amazon Bedrock ou SageMaker — et générer de lourdes factures d'inférence, souvent pour revendre cet accès. L'inférence est coûteuse et très demandée, si bien que des identifiants compromis se convertissent directement en valeur sans que l'attaquant déploie la moindre infrastructure. GuardDuty AI Protection analyse l'activité, comme les enregistrements CloudTrail, pour signaler les invocations de modèles anormales révélant cet abus.
Un tableau de bord de sécurité unique supprime-t-il ma propre responsabilité ?
Non. Consolider les résultats d'AWS et d'Azure dans une seule console réduit la fatigue liée aux alertes et les angles morts, mais le modèle de responsabilité partagée s'applique toujours. Vous êtes responsable d'activer la couverture, d'ajuster les benchmarks, de trier et de corriger les résultats, et de sécuriser les charges IA elles-mêmes. Un écran unique améliore la visibilité ; il ne configure pas l'accès au moindre privilège, ne corrige pas une mauvaise configuration et ne contient pas un incident à votre place.
Quelles parties sont disponibles et lesquelles sont en préversion ?
La surveillance multicloud Azure de Security Hub, GuardDuty AI Protection et l'inventaire IA de Security Hub sont disponibles ; GuardDuty AI Protection inclut un essai gratuit de 30 jours, et l'inventaire IA fait partie de Security Hub Essentials sans coût supplémentaire. Les investigations pilotées par l'IA de GuardDuty, qui utilisent des agents IA pour trier les alertes et les rattacher à MITRE ATT&CK, sont en préversion dans dix régions AWS au lancement. Les ressources Azure sont facturées aux tarifs AWS équivalents.
Sources
AWS Security Blog — Security Hub adds AI workload protection and multicloud support for Microsoft Azure
SiliconANGLE — AWS Security Hub expands coverage to Microsoft Azure and beefs up AI protections
Help Net Security — AWS retools Security Hub for AI and multicloud threats