AWS a ajouté un inventaire de l’IA à Security Hub, offrant aux équipes de sécurité centrales une vue continuellement actualisée des actifs d’IA et de leur posture de sécurité dans toute l’organisation. Cette annonce répond à un problème qui se précise à mesure que les entreprises déploient davantage de modèles, d’agents et de services dotés de capacités d’IA : les équipes de sécurité ne peuvent pas protéger les systèmes qu’elles ne voient pas.
Cette nouvelle fonctionnalité est conçue pour identifier les charges de travail d’IA dans les services AWS gérés, les infrastructures autohébergées et les dépendances envers des modèles externes. AWS indique que l’inventaire est inclus avec Security Hub Essentials, ne nécessite aucune activation supplémentaire et est disponible dans toutes les Régions AWS commerciales où Security Hub est proposé.
Trois voies de découverte des charges de travail d’IA
Pour les services d’IA gérés, Security Hub utilise les ressources AWS Config afin d’inventorier les déploiements impliquant Amazon Bedrock, Bedrock AgentCore et Amazon SageMaker. AWS indique que cette voie ne nécessite aucune configuration supplémentaire, ce qui devrait la rendre utile aux organisations qui utilisent déjà ces services et souhaitent obtenir une vue consolidée de leur périmètre d’IA.
La deuxième voie couvre les charges de travail d’IA autohébergées. AWS a amélioré l’analyse de la nomenclature logicielle d’Amazon Inspector afin d’identifier les points de terminaison d’inférence, les modèles et les agents d’IA installés sur des instances Amazon EC2 et des images Amazon Elastic Container Registry. L’annonce cite Ollama, vLLM et Hugging Face Text Generation Inference parmi les frameworks pouvant être identifiés.
La troisième voie dépasse les services de modèles gérés par AWS. Security Hub peut utiliser la télémétrie DNS d’Amazon GuardDuty pour découvrir les points de terminaison d’API d’IA externes auxquels accèdent des instances EC2. Cela peut révéler des dépendances envers des fournisseurs de modèles tiers qui n’étaient pas auparavant enregistrées dans l’inventaire de l’organisation.
De la découverte des actifs à la priorisation des risques
La découverte n’est qu’une première étape. AWS indique que chaque actif d’IA est relié à l’infrastructure sous-jacente et corrélé aux résultats provenant de l’ensemble de la pile de sécurité AWS, notamment les résultats de détection de menaces de GuardDuty. Les équipes de sécurité peuvent filtrer, regrouper et interroger l’inventaire par compte, type de ressource, méthode de découverte et identité précise du modèle.
Cette structure fait évoluer la question de « Où utilisons-nous l’IA ? » vers « Quels actifs d’IA sont exposés, mal configurés ou déjà associés à une activité suspecte ? » Un point de terminaison de modèle sans résultat actif peut nécessiter un examen de gouvernance, tandis qu’une charge de travail d’IA liée à un signal de menace peut être priorisée pour investigation. Cette distinction est importante à mesure que les organisations accumulent des services d’IA au travers de projets formels, d’expérimentations de développeurs et de connexions à des API externes.
AWS présente l’inventaire comme une vue à l’échelle de l’organisation, mais l’annonce ne le décrit pas comme un remplacement des processus plus larges de gestion des actifs ou de la chaîne d’approvisionnement logicielle. Les équipes devront toujours déterminer comment la vue de Security Hub s’articule avec leurs registres et modèles de responsabilité existants. Elles devront également définir qui est chargé d’examiner les actifs nouvellement découverts et comment les résultats sont transmis pour traitement.
Ce que les équipes de sécurité devraient examiner en premier
La version propose un point de départ pratique pour examiner l’exposition liée à l’IA. Les organisations qui adoptent cette fonctionnalité devraient se concentrer sur quatre questions :
- L’inventaire correspond-il aux charges de travail d’IA déjà connues des équipes de sécurité et des équipes chargées des plateformes ?
- Quels points de terminaison, modèles ou agents autohébergés apparaissent grâce à l’analyse de la nomenclature logicielle ?
- Des API de modèles externes sont-elles appelées depuis une infrastructure qui n’a pas été documentée ou approuvée ?
- Quels actifs d’IA sont associés à des résultats actifs et nécessitent donc une décision de remédiation plus rapide ?
Ces vérifications sont plus utiles si l’inventaire n’est pas traité comme un rapport ponctuel. Les systèmes d’IA évoluent rapidement : de nouveaux points de terminaison sont déployés, les modèles sont remplacés et les applications obtiennent l’accès à des outils ou fournisseurs supplémentaires. Une vue continuellement actualisée peut soutenir des examens récurrents, mais seulement si les équipes attribuent les responsabilités et définissent les mesures à prendre lorsqu’un nouvel actif est découvert.
Pourquoi le moment est important
Les discussions sur la sécurité de l’IA se concentrent souvent sur l’injection de prompts, l’utilisation abusive des modèles ou le comportement des agents autonomes. Ces risques sont réels, mais ils sont difficiles à gérer lorsque l’organisation ne sait pas quels modèles, points de terminaison et intégrations existent. La mise à jour de Security Hub place la visibilité au centre du problème de contrôle et relie cette visibilité aux résultats de sécurité existants d’AWS.
Le résultat n’est pas une garantie de sécurité automatique. Il s’agit d’une couche d’inventaire et de corrélation qui peut aider les équipes à établir une base plus claire, à localiser les dépendances négligées et à prioriser les investigations. Sa valeur dépendra de l’exhaustivité des signaux disponibles dans chaque environnement et de la capacité des organisations à transformer les résultats obtenus en actions de remédiation clairement attribuées.
Pour les clients AWS qui utilisent déjà Security Hub, l’annonce est importante car elle étend une vue de sécurité existante au périmètre d’IA sans nécessiter de système d’inventaire distinct. Pour les équipes opérant dans plusieurs clouds ou disposant d’une infrastructure non gérée importante, cette fonctionnalité doit être considérée comme une source de preuves parmi d’autres dans un processus plus large de gouvernance des actifs.
L’annonce est documentée dans la publication officielle d’AWS.