Comprendre la détection de la sécurité des modèles d’IA
Le scan de sécurité des modèles IA consiste à vérifier vos modèles et leur pile environnante pour détecter des problèmes de sécurité tout au long du cycle de vie. Cela inclut le balayage statique des artefacts (fichiers modèles, dépendances, formats de sérialisation), l’application des pipelines et des politiques (portes CI/CD, contrôles d’admission), les tests dynamiques des terminaux (injection de prompts, schémas d’abus) et la surveillance à l’exécution (anomalies comportementales, détection de dérive). Vous examinez l’artefact du modèle, les données d’entraînement, les points d’inférence et l’infrastructure cloud qui les héberge.
Les modèles d’IA dans le cloud font face à des menaces spécifiques que vous ne voyez pas avec les applications classiques. Vous allez tomber sur des termes comme Extraction de modèles, Empoisonnement des données, et injection rapide –des schémas d’attaque qui sont en hausse selon une récente enquête de Gartner. Ces menaces visent différentes étapes du cycle de vie de l’IA, de l’entraînement à l’inférence en production.
Extraction du modèle : Un attaquant copie votre modèle'en envoyant de nombreuses requêtes conçues.
Empoisonnement des données: Les données malveillantes sont glissées dans l’entraînement ou le réglage fin, de sorte que le modèle se comporte incorrectement ou possède une porte dérobée cachée.
Injection rapide et entrées adverses : Les entrées sont conçues pour contourner les instructions, divulguer des données ou forcer un comportement dangereux. La recherche sur le red-teaming (par exemple, cette étude) démontre de nombreuses violations des politiques contre les agents IA, montrant que les prompts adversaires peuvent contourner les garde-fous de sécurité sur plusieurs architectures de modèles.
Les outils de sécurité traditionnels se concentrent sur les serveurs et les réseaux. Ils comprennent rarement Attaques de sérialisation de modèles (code malveillant caché dans les fichiers modèles), Jeux de données d’entraînement exposés, Inférence de l’appartenance (déterminant si des données spécifiques faisaient partie de l’ensemble d’entraînement), ou Inversion du modèle (reconstruisant les données d’entraînement originales à partir des sorties).
Vous devriez penser en termes de Combinaisons toxiques, pas des résultats isolés. Par exemple, une vulnérabilité de modèle devient grave lorsque :
Le modèle peut être appelé depuis Internet.
Le modèle a accès à des entrepôts de données sensibles.
L’hébergeur modèle a des permissions trop larges dans votre compte cloud.
En pratique, cela signifie que vos principaux risques résident là où des modèles vulnérables, des identités puissantes et des données importantes se rencontrent. Une entreprise mondiale de services a découvert ainsi des vulnérabilités des LLM et a utilisé le routage automatisé pour envoyer les problèmes aux équipes respectives possédant chaque modèle, au lieu d’obliger la sécurité à poursuivre manuellement les propriétaires.
25 AI Agents. 257 Real Attacks. Who Wins?
From zero-day discovery to cloud privilege escalation, we tested 25 agent-model combinations on 257 real-world offensive security challenges. The results might surprise you 👀
Mise en œuvre de la découverte et d’inventaire complets des modèles
La découverte de modèles, c’est trouver chaque asset d’IA dans votre environnement. L’inventaire des modèles consiste à tenir un registre à jour de ces actifs, de ce qu’ils touchent et de qui les possède.
Vous voulez que cet inventaire inclue des services managés, des modèles auto-hébergés et tout ce qui est expérimental. Cela signifie rentrer :
Des terminaux gérés depuis des plateformes comme SageMaker, Azure ML ou Vertex AI.
Déploiements personnalisés sur Kubernetes, VM ou serverless.
Infrastructure de formation, magasins de fonctionnalités et emplois d’inférence par lots.
Une fois que vous savez où vivent les modèles, reliez-les à leur construction. Voilà Lignée des modèles: tracer un modèle depuis les données d’entraînement, à travers les pipelines, jusqu’aux terminaux de production.
Registre des mannequins : Utilisez ou créez un espace central pour enregistrer chaque modèle de qualité production.
Inventaire des pipelines IA : Cartographiez les dépôts de code, les tâches de formation, les étapes d’évaluation et les tâches de déploiement.
Propriété : Étiquetez les modèles avec les noms des équipes, les services et les unités métier afin que les problèmes puissent être assignés instantanément.
Il faut aussi faire surface Modèles d’IA de l’ombre. Ce sont des modèles que les équipes mettent en place seules, souvent hors contrôle officiel, mais qui restent conservés dans leurs comptes cloud — une tâche importante étant donné que les charges de travail de l’IA ont rapidement augmenté d’année en année dans le dernier rapport d’utilisation de Sysdig.
Une entreprise axée sur les données ayant connu plusieurs fusions a utilisé cette approche pour IA de balayage Utilisation dans six environnements différents. Avec un seul graphique d’inventaire et de sécurité, ils pouvaient enfin voir quels modèles utilisaient des données sensibles et lesquels étaient exposés à Internet, quelle que soit l’entreprise d’origine.
Automatisation de l’analyse de modèles dans les pipelines CI/CD
Le balayage de modèles en CI/CD signifie que vous traitez les modèles comme n’importe quel autre artefact dans vos pipelines de build. Vous les scannez avant qu’ils ne passent à la mise en scène ou à la production, pas seulement après qu’ils soient en direct.
Commencez par ajouter des vérifications de sécurité des modèles comme étapes explicites du pipeline. Lorsque l’entraînement ou le réglage fin se termine et qu’un fichier modèle est produit, vous :
Scan les artefacts du modèle pour détecter la désérialisation dangereuse et le code intégré. Privilégiez des formats plus sûrs comme les safetensors plutôt que les pickles, et chargez le code personnalisé non fiable. Les fichiers pickle peuvent exécuter du code Python arbitraire lors de la désérialisation, créant un risque direct d’exécution du code.
Vérifiez l’environnement et les conteneurs pour détecter des vulnérabilités connues et des mauvaises configurations.
Générer un SBOM pour l’IA Qui liste tous les frameworks et dépendances impliqués.
Ensuite, appliquer les règles avec Policy-as-code. Par exemple, vous pourriez codifier : aucun modèle de production ne peut référencer un magasin de données de développement. Un moteur de politique unifié qui couvre le code, les pipelines, le cloud et l’exécution aide les équipes à bloquer tôt les déploiements risqués de l’IA et à maintenir la cohérence des politiques dans tous les environnements, réduisant ainsi le risque qu’un modèle passe à travers des configurations dangereuses.
Aucun modèle de production ne peut référencer un magasin de données de développement.
Aucun déploiement n’est autorisé si des vulnérabilités critiques existent dans les cadres de ML.
Aucun point public n’est autorisé pour des projets ou types de données spécifiques.
Sur Kubernetes, ajoutez Contrôleurs d’admission comme le Gatekeeper de l’OPA ou Kyverno comme dernier portail. Ces contrôleurs interceptent les demandes de déploiement et appliquent les politiques avant la création des ressources dans le cluster.
Signature de mannequin : Exigez des artefacts de modèles signés et vérifiez les signatures avant de servir.
Balayage IaC: Validez Terraform, Helm et d’autres modèles qui font fonctionner des infrastructures d’IA.
Déploiements non conformes : Échouez rapidement et faites passer des messages clairs à l’équipe propriétaire.
Une entreprise mondiale de produits utilise ce schéma pour détecter les erreurs de configuration avant la création des ressources cloud. Vous pouvez appliquer la même approche pour toute tentative IA de balayage Les modèles et les infrastructures se font automatiquement, à chaque changement.
Sécuriser les déploiements de services d’IA cloud
Sécuriser les services d’IA dans le cloud consiste à exposer et à câbler vos modèles. Vous pouvez avoir un fichier modèle parfaitement sûr et quand même créer un gros problème de sécurité du modèle avec de mauvais choix de déploiement.
Concentrez-vous d’abord sur la façon dont les points de terminaison sont exposés. Posez des questions simples comme : "Qui peut appeler ça ?" et "D’où ?"
Exposition aux points de fin : Privilégiez les points d’accès privés aux publics dès que possible. Utilisez AWS PrivateLink pour les terminaux SageMaker, Azure Private Link pour Azure ML, ou GCP Private Service Connect pour Vertex AI. Cela permet de maintenir le trafic d’inférence dans votre VPC et hors de l’internet public.
Contrôles réseau : Utilisez des constructions de réseau privé comme AWS PrivateLink, Azure Private Link ou GCP Private Service Connect pour empêcher les terminaux d’inférence hors de l’internet public. Les maillages de service et les passerelles internes ajoutent des couches supplémentaires d’application des politiques.
Ensuite, verrouillez l’authentification et les permissions. Chaque appel à un modèle doit être authentifié, et l’environnement de service doit suivre le minimum de privilèges.
Authentification : Utilisez des schémas d’authentification forts comme l’identité de charge de travail ou des jetons de courte durée. Les identités des machines dépassent largement celles des humains dans les environnements cloud et sont souvent plus risquées en raison de permissions excessives et inutilisées qui s’accumulent au fil du temps.
Autorisations : Assurez-vous que les hôtes modèles ne peuvent lire que les buckets, files d’attente ou secrets spécifiques dont ils ont réellement besoin.
Il faut aussi surveiller Dérive de configuration. Le développement peut utiliser une configuration verrouillée pendant que la production dérive discrètement vers "Ouvert au monde" territoire.
Contrôles de dérive : Comparez régulièrement le développement, la mise en scène et la production pour l’exposition des terminaux, le chiffrement, la journalisation et les paramètres d’identité.
Chiffrement : Assurez-vous que les fichiers modèles et les données d’entraînement sont chiffrés au repos en utilisant des clés de chiffrement gérées par le client (CMEK) via AWS KMS, Azure Key Vault ou GCP Cloud KMS. Protégez le trafic en transit avec TLS 1.3 pour tous les points d’inférence et les transferts de données.
Quand vous sécurisez les déploiements de cette façon, Sécurité des modèles Ça ne concerne plus seulement le modèle et ça fait partie intégrante de ton hygiène cloud au sens large.
Sample AI Security Assessment
Get a glimpse into how Wiz surfaces AI risks with AI-BOM visibility, real-world findings from the Wiz Security Graph, and a first look at AI-specific Issues and threat detection rules.
Protection et surveillance du modèle à l’exécution
La protection en temps réel, c’est la façon dont on observe les modèles une fois qu’ils servent réellement le trafic. Ici, vous vous souciez moins des propriétés du fichier modèle que du comportement.
Commencez par déployer Capteurs d’exécution sur votre infrastructure de service de modèles, ou activez la télémétrie native cloud où les capteurs sont disponibles'Pas faisable. Ces composants légers basés sur eBPF peuvent voir :
Processus suspects commençant sur des hôtes modèles.
Écritures de fichiers inattendues ou connexions réseau.
Fuites de conteneurs ou tentatives d’escalade de privilèges.
En même temps, vous surveillez le comportement du modèle. Des schémas inhabituels dans les requêtes ou les réponses indiquent souvent des attaques ou des abus. Associer la télémétrie à l’exécution avec l’identité cloud, l’exposition réseau et le contexte de sensibilité aux données réduit les faux positifs et le triage rapide — vous vous concentrez sur les anomalies qui comptent réellement au lieu de poursuivre chaque exception.
Analyse comportementale : Cherchez des pics étranges, des motifs de prompts étranges ou des recherches approfondies sur les cas limites.
Exfiltration des données : Observez les tentatives d’envoi de données des hôtes modèles vers des destinations que vous ne reconnaissez pas.
Tu fais aussi du suivi Dérive. Lorsque les sorties du modèle ou la distribution des entrées changent de manière inattendue, cela peut être un signe d’empoisonnement, de systèmes en amont défaillants ou d’une attaque silencieuse.
Une entreprise de logiciels qui s’appuie sur Kubernetes pour des charges de travail critiques utilise des capteurs d’exécution pour protéger les services conteneurisés. Les mêmes capteurs les aident désormais à détecter les charges de travail de l’IA qui commencent soudainement à passer des appels sortants ou à se comporter de manière à ne pas correspondre aux schémas d’inférence habituels, leur fournissant un avertissement précoce avant que les dégâts ne se propagent.
Gestion de la sécurité des chaînes d’approvisionnement modèles
Modèle Sécurité de la chaîne d’approvisionnement c’est l’origine de vos modèles et composants ML. Il est facile d’intégrer un modèle open source puissant et de glisser accidentellement une porte dérobée cachée aussi.
Vous devez vérifier l’origine et l’intégrité de tous les modèles tiers et open source que vous utilisez. Cela inclut des poids pré-entraînés, des points de contrôle d’ajustement, et même de petits modèles d’assistance.
Provenance du modèle : Notez d’où vient chaque modèle et comment il a été modifié.
Analyse des dépôts : Scanez les dépôts de modèles à la recherche d’artefacts malveillants ou de formats connus comme dangereux. Faire respecter la signature des modèles et vérifier les signatures avant utilisation pour garantir un bon refuge des modèles'A été trafiqué entre l’entraînement et le déploiement.
Ensuite, maintenez un dégagement Lettre de documents logicielle pour chaque modèle. Ce SBOM doit lister les frameworks, bibliothèques et composants système dont dépend le modèle.
Balayage des dépendances: Vérifiez continuellement cette liste par rapport aux flux de vulnérabilités.
Mises à jour régulières : Planifiez et testez les mises à jour des cadres ML critiques lorsque des vulnérabilités apparaissent.
C’est ainsi que vous évitez qu’une vulnérabilité silencieuse du modèle issue d’un package en amont ne devienne un compromis complet. Vous traitez votre chaîne d’approvisionnement modèle d’IA avec le même soin que votre chaîne d’approvisionnement en conteneurs ou système d’exploitation, avec une attention particulière à Falsification de modèles et Attaques contre les chaînes d’approvisionnement qui sont propres à l’IA.
GenAI Security Best Practices Cheat Sheet
This cheat sheet provides a practical overview of the 7 best practices you can adopt to start fortifying your organization’s GenAI security posture.
Cadres de gouvernance et de conformité pour les modèles d’IA
La gouvernance des modèles par IA est l’ensemble des règles que vous établissez pour la manière dont les modèles sont construits, déployés et utilisés. La conformité est la façon de prouver que vous avez respecté ces règles.
Vous commencez par définir des politiques pour le cycle de vie du modèle. Ces polices doivent couvrir l’accès, les approbations et le moment où les modèles doivent être retirés.
Politiques d’accès : Qui peut voir les données d’entraînement, les poids des modèles et les journaux d’inférence.
Politiques d’utilisation : Où un modèle peut être utilisé, pour quels utilisateurs et avec quels types de données.
Politiques de retraite : Quand un modèle doit être retiré du service et que devient de ses données.
Vous définissez ensuite les flux de travail d’approbation. Les modèles à fort impact ou à haut risque devraient passer par un processus d’examen plus formel avant d’entrer en production.
Vous associez également vos contrôles IA à des normes externes et internes comme NIST AI, RMF 1.0, ISO/IEC 42001, et des réglementations applicables telles que la loi européenne sur l’IA. Aligner les contrôles de soutien avec SOC 2 et ISO 27001 lorsque cela est pertinent afin de démontrer une gouvernance de sécurité globale.
Gouvernance de l’IA: Documentez qui a approuvé le modèle, quels tests ont été réalisés et comment les risques ont été évalués.
Évaluation des risques de modèle : Classez les modèles en catégories de risque en fonction des données utilisées et de l’impact d’une défaillance.
Cartographie de la conformité : Reliez vos contrôles de modèle aux cadres de sécurité et de confidentialité que votre organisation suit. Contrôles d’accès des modèles cartographiques vers le RMF IA NIST's Régir la fonction, entraîner la protection des données selon ISO/IEC 42001's exigences de gouvernance des données, et la surveillance à l’exécution jusqu’aux contrôles de surveillance continue SOC 2 Type II. Pour les industries réglementées, alignez-vous sur des exigences sectorielles comme la HIPAA pour l’IA de la santé ou le PCI DSS pour les modèles de traitement des paiements.
En faisant cela, vous vous transformez Sécurité des modèles d’un ensemble de décisions ponctuelles à un processus répétable que les équipes juridiques, des risques et de la sécurité peuvent toutes comprendre.
Réponse aux incidents pour des modèles d’IA compromis
Intervention en cas d’incident par IA c’est ce que l’on fait quand quelque chose tourne mal avec un modèle. Vous gérez cela comme n’importe quel autre incident, mais avec un accent particulier sur les modèles, les données et les pipelines.
Vous commencez par écrire des manuels de stratégie spécifiques à l’IA. Ces manuels devraient couvrir des sujets comme le vol de modèles, l’abus de mannequins et les attaques adverses.
Un point de terminaison servant le modèle se comporte de manière étrange ou fournit des sorties inattendues.
Vous découvrez un modèle ou un jeu de données empoisonné dans votre environnement.
Quelqu’un a copié ou téléchargé des poids de modèles sans approbation.
Chaque manuel doit préciser clairement les étapes de confinement. Par exemple, vous pourriez :
Limiter le débit ou désactiver des points d’inférence spécifiques.
Changez de trafic vers une version sûre précédente.
Coupez les identités ou réseaux suspects de l’accès au modèle, et faites immédiatement tourner ou révoquer les identifiants, jetons et clés API affectés. Cela empêche les attaquants de maintenir l’accès via des documents d’authentification compromis.
Vous avez aussi besoin Médecine légale modèle. C’est ainsi que vous étudiez ce qui s’est passé, en utilisant des journaux, des modèles de lignée et des données d’environnement.
Criminalistique : Capturez les artefacts du modèle, les journaux de bord et les données pertinentes pour analyse.
Analyse du chemin d’attaque: Retrace comment l’attaquant est passé des problèmes de modèles ou de bibliothèques à des ressources cloud plus larges.
Une entreprise de services financiers confrontée à une vulnérabilité critique dans une bibliothèque liée à l’IA a utilisé ce type de visibilité pour identifier précisément quelles charges de travail utilisaient le composant défectueux et les corriger rapidement. Ce même schéma fonctionne pour tout événement de sécurité lié à l’IA.
Techniques avancées de sécurité des modèles
Les contrôles de sécurité avancés des modèles sont des couches supplémentaires que l’on ajoute quand les enjeux sont élevés. Ce ne sont pas les premières choses que vous construisez, mais elles deviennent importantes pour des charges de travail sensibles.
Quelques exemples courants :
Filigranage du modèle : Vous ajoutez un signal ou un comportement invisible à un modèle pour pouvoir ensuite prouver qu’il vous appartient ou détecter des copies.
Confidentialité différente : Vous entraînez les modèles de manière à limiter ce qu’un attaquant peut apprendre sur chaque point de données individuel, même avec accès aux résultats.
Chiffrement homomorphe : Vous structurez les données et le calcul de façon à ce que certaines inférences puissent se produire sur des données chiffrées, réduisant ainsi l’exposition des valeurs brutes.
Entraînement à l’adversaire : Vous entraînez intentionnellement les modèles sur des exemples adverses pour qu’ils apprennent à résister à ces schémas d’attaque.
Ces outils peuvent aider à lutter contre le vol de modèles, la fuite de données d’entraînement et les attaques adverses. Ils comportent des compromis en termes de performance et de complexité, donc vous les utilisez là où le profil de risque justifie vraiment le coût.
Construire un programme unifié de sécurité IA avec Wiz
Un programme unifié de sécurité IA est lorsque la sécurité de l’IA et la sécurité cloud partagent la même plateforme, les mêmes données et les mêmes flux de travail. Tu arrêtes de gérer un autre "Sécurité de l’IA" et l’intégrer à votre modèle opérationnel actuel. Cette approche s’aligne avec le Top 10 OWASP pour les applications LLM, vous aidant à traiter de manière structurée les risques de sécurité les plus critiques pour les systèmes d’IA.
Vous commencez par regrouper tous vos assets dans une seule vue. Cela inclut les modèles, les magasins de données, le calcul, les identités, les pipelines et les points de terminaison.
Visualisation des graphes de sécurité : Utilisez un graphique de sécurité pour montrer comment un modèle donné se connecte aux données d’entraînement, aux données de production, aux identités et aux réseaux. Le contexte des graphes à travers les modèles, les magasins de données, les identités et les points de terminaison facilite la trace de la propriété et l’acheminement des problèmes vers la bonne équipe rapidement, donc la sécurité ne le fait pas'Ne deviendrait un goulot d’étranglement.
Priorisation contextuelle : Problèmes de classement basés sur de vrais chemins d’attaque, pas seulement sur les scores bruts de gravité.
Ensuite, vous connectez l’automatisation. Lorsque des vulnérabilités, des mauvaises configurations ou des expositions de données du modèle sont détectées, elles doivent être automatiquement transférées aux bonnes équipes.
Assainissement automatisé : Créez des règles qui ouvrent des tickets, envoient des alertes ou déclenchent des défaillances de pipeline lorsque certaines conditions sont remplies. Avec Réhabilitation IA 2.0, vous recevez des suggestions alimentées par l’IA qui suggèrent des solutions spécifiques adaptées à votre environnement, accélérant la résolution et réduisant le travail manuel.
Capacités décal-gauche : Donnez aux data scientists et aux ingénieurs en apprentissage automatique l’accès à la numérisation dans leurs IDEs, notebooks et pipelines CI afin qu’ils puissent corriger les problèmes rapidement.
Une plateforme unifiée rassemble ces idées en un seul endroit. Wiz AI-SPM évalue les services d’IA pour détecter des configurations et expositions risquées. Le Wiz Security Graph montre ensuite comment les vulnérabilités, les mauvaises configurations et les permissions excessives se combinent en des chemins d’attaque qui pourraient menacer vos modèles d’IA et vos données d’entraînement.
Avec une couverture sans agent, vous obtenez une visibilité full-stack sans ajouter d’agents lourds aux serveurs modélisés. Procurez-vous une démo pour explorer le scan sans agent, la protection à l’exécution et la visibilité unifiée pour vos charges de travail IA cloud.
See Wiz AI-SPM in Action
Accelerate AI adoption securely with continuous visibility and proactive risk mitigation across your AI models, training data, and AI services.
