Ma mission en cours m’amène à approfondir la sécurité des systèmes d’IA et notamment la sécurité des systèmes d’IA générative.
Avec toute nouvelle technologie vient son lot d’opportunités et de risques, l’IA Générative n’est pas exempte de risques très spécifiques.
Je vous avais parlé de possible fuites de données lorsque les entreprises ne font pas l’effort de doter leurs employers de chatbot interne et qu’ils utilisent les chabot publiques (voir la notion de shadow AI dans notre blog sur RAG). Mais il y a bien d'autres choses à prendre en considération lorsqu'on travaille avec l'IA.
Bien sûre, l’ANSSI est la référence française en matière de cyber sécurité et l’IA Générative ne pouvait pas échapper à sa vigilance. L’organisation a récemment publié un ensemble de recommandations qui couvre le risque de fuite de données et bien d’autres.
Le document fait un tour d’horizon de la technologie, des vecteurs d’attaques et des approches de mitigations des risques sous la forme de recommandations détaillées sur l'ensemble du cycle de vie d'un système d'IA.
C'est très intéressant et facile à lire mais il fait 38 pages. Je vous donc propose cette synthèse à commencer par un tableau récapitulatif de ces recommandations de l’ANSSI. Cela pourra vous servir de checklist lors de la revue de risques de vos systèmes d’IA.
Tableau récapitulatif des recommandations de sécurité en IA Générative
R1 | |
R2 | |
R3 | |
R4 | |
R5 | |
R6 | |
R7 | |
R8 | |
R9 | |
R10 | |
R11 | |
R12 | |
R13 | |
R14 | |
R15 | |
R16 | |
R17 | |
R18 | |
R19 | |
R20 | |
R21 | |
R22 | |
R23 | |
R24 | |
R25 | |
R26 | |
R27 | |
R28 | |
R29 | |
R30 | |
R31 | |
R32 | |
R33 | |
R34 | |
R35 |
Et pour mieux comprendre cette table, je vous partage aussi les extraits détaillés de ces recommandations que l’ANSSI a établie pour vous aider à mettre en place une gouvernance de vos systèmes d’IA adaptée à vos risques.
Cycle de vie d'un système d'IA générative
R1 Intégrer la sécurité dans toutes les phases du cycle de vie d'un système d'IA
Des mesures de sécurité doivent être identifiées et appliquées dans chacune des 3 phases du cycle de vie d’un système d’IA : entraînement, déploiement et production.
Ces mesures dépendent fortement du scénario de partage de responsabilités retenu et de la sous-traitance associée. Elles doivent également tenir compte des interactions avec d’autres applications ou composants internes ou externes au SI.
Il est possible de se référer au guide d’hygiène de l’ANSSI pour disposer d’un socle de base de sécurité à appliquer.
Scénarios d'attaques sur l'IA générative
R2
R2 Mener une analyse de risque sur les systèmes d'IA avant la phase d’entraînement
L’analyse de risque d’un système d’IA doit intégrer les problématiques suivantes :
cartographier l’ensemble des éléments en lien avec le modèle d’IA : bibliothèques tierces, sources de données, applications interconnectées, etc. ;
identifier les sous-parties du système d’IA qui traiteront les données de l’organisation, en particulier celles contenues dans les requêtes des utilisateurs ;
prendre en compte le scénario de partage de responsabilités et la question de la sous-traitance pour chacune des phases ;
identifier les impacts directs et indirects en cas de réponses erronées ou malveillantes du modèle d’IA aux utilisateurs ;
considérer la protection des données d’entraînement du modèle d’IA.
Recommandations générales
R3
R3 Évaluer le niveau de confiance des bibliothèques et modules externes utilisés dans le système d'IA
Il est recommandé de cartographier l’ensemble des bibliothèques et modules externes utilisés dans le cadre du projet et d’évaluer leur niveau de confiance.
R4
R4 Évaluer le niveau de confiance des sources de données externes utilisées dans le système d'IA
Il est recommandé de cartographier l’ensemble des sources de données externes utilisées dans le cadre du projet et d’évaluer leur niveau de confiance.
R5
R5 Appliquer les principes de DevSecOps sur l'ensemble des phases du projet
Il est recommandé d’appliquer les bonnes pratiques de développement sécurisé sur l’ensemble des phases du projet, par exemple :
déployer et sécuriser des chaînes d’intégration et de déploiement en continu (CI/CD) en appliquant le principe de moindre privilège pour l’accès aux outils de ces chaînes CI/CD ;
mettre en oeuvre une gestion sécurisée des secrets utilisés dans toutes les phases du projet ;
prévoir des tests de sécurité automatisés sur le code source (analyse statique de code) et lors de l’exécution de ce code source (analyse dynamique de code) ;
protéger en intégrité le code source et sécuriser l’accès à celui-ci (authentification multifacteur, signature du code, droits d’accès, etc.) ;
recourir à des langages de développement sécurisés (scripts de fine tuning, développement du modèle, maintenance, déploiement, etc.).
6
R6 Utiliser des formats de modèles d'IA sécurisés
Il est recommandé d’utiliser des formats à l’état de l’art du point de vue de la sécurité, comme le format safetensor par exemple. Certains formats peu sécurisés, comme le format pickle, sont à proscrire.
R7
R7 Prendre en compte les enjeux de confidentialité des données dès la conception du système d'IA
L’étude du projet doit cartographier l’ensemble des jeux de données utilisés à chaque phase du système d’IA : entraînement (jeux de données d’entraînement), déploiement (jeux de tests) et production (données additionnelles, base de données vectorielle, etc.).
Cette étude doit inclure les données d’usage du système d’IA en production, à savoir les requêtes des utilisateurs ainsi que les réponses apportées par le modèle d’IA.
L’analyse peut également traiter le cas de la protection en confidentialité des paramètres du modèle lui-même, par exemple pour des modèles propriétaires.
R8
R8 Prendre en compte la problématique de besoin d'en connaître dès la conception du système d'IA
Il est important de définir en amont du projet les options structurantes du modèle pour gérer le besoin d’en connaître :
le choix des données utilisées pour l’entraînement (sans la possibilité de gérer des droits d’accès) et des données additionnelles en production (avec la possibilité de gérer des rôles et des droits d’accès) ;
la stratégie d’apprentissage du modèle, c’est-à-dire à quel moment est-ce que l’on ré-entraîne le modèle et sur la base de quelles données (données additionnelles métier, requêtes des utilisateurs, réponses du modèle, etc.).
R9
R9 Proscrire l'usage automatisé de systèmes d'IA pour des actions critiques sur le SI
Un système d’IA doit être configuré de manière à ne pas être en mesure d’exécuter de manière automatisée des actions critiques sur le SI.
Ces actions peuvent être des actions critiques d’un point de vue métier (transactions bancaires, production de contenu public, impact direct sur des personnes, etc.) ou bien des actions critiques sur l’infrastructure du SI (reconfiguration de composants réseaux, créations d’utilisateurs à privilège, déploiement de serveurs virtuels, etc.).
R10
R10 Maîtriser et sécuriser les accès à privilèges des développeurs et des administrateurs sur le système d'IA
L’ensemble des opérations à privilèges sur le système d’IA doit respecter les bonnes pratiques d’administration sécurisée, notamment :
les opérations à privilège doivent être définies et leur déclenchement doit être validé : ré-entraînement, modification des jeux de données, nouvelle interconnexion avec une application, changement d’hébergement, etc. ;
les opérations à privilège doivent être réalisées avec des comptes dédiés et depuis un poste d’administration dédié à cet usage ;
le principe de moindre privilège doit être appliqué et l’usage de jetons d’authentification (token) temporaires doit être privilégié ;
l’environnement de développement doit être maîtrisé et administré au même niveau de sécurité que l’environnement de production.
R11
R11 Héberger le système d'IA dans des environnements de confiance cohérents avec les besoins de sécurité
L’hébergement du système d’IA lors des 3 phases du cycle de vie doit être cohérente avec les besoins de sécurité du projet, et notamment les besoins en confidentialité et en intégrité. En particulier, la sécurisation des données d’entraînement du modèle (au repos, en transit, lors d’un traitement) ne doit pas être négligée.
R12
R12 Cloisonner chaque phase du système d'IA dans un environnement dédié
Il est recommandé de cloisonner les 3 environnements techniques correspondant à chacune des phases du cycle de vie du système d’IA. Ce cloisonnement peut porter sur :
un cloisonnement réseau : chaque environnement est intégré dans un réseau physiquement ou logiquement dédié ;
un cloisonnement système : chaque environnement dispose de ses propres serveurs physiques ou hyperviseurs dédiés ;
un cloisonnement du stockage : chaque environnement dispose de son propre matériel de stockage ou de disques dédiés. Au minimum, un cloisonnement logique
est appliqué ;
un cloisonnement des comptes et des secrets : chaque environnement dispose de ses propres comptes utilisateurs et administrateurs et de secrets distincts.
R13
R13 Implémenter une passerelle Internet sécurisée dans le cas d'un système d'IA exposé sur Internet
Dans le cas d’un système d’IA exposé sur Internet, il est recommandé de suivre les bonnes pratiques de cloisonnement du guide de l’ANSSI à ce sujet, notamment :
dédier une fonction de reverse-proxy avant l’accès au service web du système d’IA ;
mettre en place deux zones logiques pour le filtrage réseau à l’aide de pare-feux : un filtrage externe en frontal d’Internet et un filtrage interne avant l’accès au système d’IA ;
ne pas exposer un annuaire interne de l’entité pour l’authentification sur le système d’IA ;
éviter de mutualiser sur un même hyperviseur des fonctions de sécurité distinctes de la passerelle Internet sécurisée (pare-feux, reverse-proxy, serveur de journalisation, etc.).
R14
R14 Privilégier un hébergement SecNumCloud dans le cas d'un déploiement d'un système d'IA dans un Cloud public
Si l’entité fait le choix d’utiliser un hébergement dans un Cloud public, il est recommandé de privilégier une offre de confiance SecNumCloud dans les cas suivants :
les données traitées par le système d’IA sont considérées comme sensibles ;
l’impact du système d’IA sur le métier est considéré comme critique ;
les utilisateurs du système d’IA ne sont pas considérés comme de confiance.
R15
R15 Prévoir un mode dégradé des services métier sans système d'IA
Afin de prévenir des dysfonctionnements ou des incohérences dans les réponses apportées par le modèle d’IA, il est recommandé de prévoir au minimum une procédure de contournement du système d’IA pour les utilisateurs, afin de répondre aux besoins métier.
R16
R16 Dédier les composants GPU au système d'IA
Il est recommandé de dédier les composants physiques GPU aux traitements réalisés par le système d’IA. Dans le cas de la virtualisation, il est recommandé que les hyperviseurs ayant accès aux cartes GPU soient dédiés au système d’IA, ou bien au minimum qu’il y ait une fonction de filtrage matériel (ex. : IOMMU) permettant de restreindre les accès des machines virtuelles à la mémoire de ces cartes GPU.
R17
R17 Prendre en compte les attaques par canaux auxiliaires sur le système d'IA
Il est recommandé de s’assurer que le système d’IA n’est pas vulnérable à des attaques par canaux auxiliaires (temporels, consommation, etc.) qui pourraient par exemple permettre à un attaquant de reconstruire une réponse apportée par un modèle d’IA.
Recommandations pour la phase d’entraînement
R18
R18 Entraîner un modèle d'IA uniquement avec des données légitimement accessibles par les utilisateurs
Il est fortement recommandé d’entraîner un modèle avec des données dont la sensibilité
est cohérente avec le besoin d’en connaître des utilisateurs.
R19
R19 Protéger en intégrité les données d’entraînement du modèle d'IA
Il est recommandé de s’assurer de l’intégrité des données d’entraînement du modèle tout au long du cycle d’entraînement. Cette protection peut prendre la forme d’une vérification systématique de la signature ou de l’empreinte (hash) des fichiers utilisés ou bien des archives compressés de l’ensemble de ces données.
R20
R20 Protéger en intégrité les fichiers du système d'IA
Il est recommandé de protéger en intégrité les fichiers du modèle entraîné, et de contrôler régulièrement que ceux-ci n’ont pas été altérés. La recommandation vaut également par extension pour tous les fichiers inhérents au fonctionnement du système d’IA (scripts, binaires, etc.).
R21
R21 Proscrire le ré-entraînement du modèle d'IA en production
Il est fortement recommandé de ne pas ré-entraîner un modèle d’IA directement en production. Cette action de ré-entraînement doit démarrer avec le cycle en 3 phases, dans les environnements adéquats pour chacune des phases.
R22
Recommandations pour la phase de déploiement
R22 Sécuriser la chaîne de déploiement en production des systèmes d'IA
Il est recommandé d’opérer le déploiement des systèmes d’IA générative depuis un SI d’administration, en respectant les bonnes pratiques du guide d’administration sécurisée de l’ANSSI.
R23
R23 Prévoir des audits de sécurité des systèmes d'IA avant déploiement en production
Il est recommandé de prévoir des tests de robustesse et de sécurité des systèmes d’IA.
Ces tests peuvent être :
des tests d’intrusion standards sur les composants techniques usuels d’un système d’IA : serveurs web, orchestrateur, base de données, etc.
des tests de sécurité sur les développements réalisés dans le système d’IA (via des outils SAST ou DAST par exemple) ;
des tests automatisés visant spécifiquement des vulnérabilités liées aux modèles d’IA (attaques adverses, extraction du modèle, etc.) ;
des tests manuels d’auditeurs visant spécifiquement à tester la robustesse d’un modèle d’IA générative sur des scénarios d’attaques plus sophistiqués.
R24
R24 Prévoir des tests fonctionnels métier des systèmes d'IA avant déploiement en production
Il est recommandé de prévoir des tests de performance et de qualité des réponses apportées par un système d’IA générative.
Recommandations pour la phase de production
R25 Protéger le système d'IA en filtrant les entrées et les sorties des utilisateurs
Il est recommandé de mettre en place des fonctions permettant de se prémunir d’une fuite de données ou d’une fuite de modèle dans les réponses :
une fonction de filtre de requêtes malveillantes des utilisateurs avant envoi au modèle ;
une fonction de filtre de requêtes jugées non légitimes d’un point de vue métier ;
une fonction de filtre d’informations internes du modèle (paramètres, entraînement) dans les réponses ;
une fonction de filtre d’informations définies comme sensibles dans les réponses (ex. : coordonnées personnelles, références de projets, etc.) ;
une limite sur la taille des réponses (nombre de caractères maximum).
R26
R26 Maîtriser et sécuriser les interactions du système d'IA avec d'autres applications métier
L’ensemble des interactions et des flux réseaux du système d’IA doit être documenté et validé. Les flux réseaux entre le système d’IA et d’autres ressources doivent respecter l’état de l’art en matière de sécurité :
ils doivent être strictement filtrés au niveau réseau, chiffrés et authentifiés (ex. : en suivant le guide TLS de l’ANSSI) ;
ils doivent utiliser des protocoles sécurisés (ex. : OpenID Connect) en cas d’usage d’un fournisseur d’identité;
ils doivent intégrer un contrôle des autorisations d’accès à la ressource en complément de l’authentification ;
ils doivent faire l’objet d’une journalisation au niveau de granularité adéquat.
R27
R27 Limiter les actions automatiques depuis un système d'IA traitant des entrées non-maîtrisées
Il est fortement recommandé de limiter voire de proscrire les actions automatiques sur le SI déclenchées depuis un système d’IA et à partir d’entrées non-maîtrisées (ex. : données issues d’Internet ou de mails, etc.).
R28
R28 Cloisonner le système d'IA dans un ou plusieurs environnements techniques dédiés
Il est recommandé que le système d’IA soit cloisonné dans des zones logiques dédiées, afin de limiter les risques de latéralisation d’un attaquant qui aurait compromis ce système.
R29
R29 Journaliser l'ensemble des traitements réalisés au sein du système d'IA
Il est recommandé de journaliser au bon niveau de granularité l’ensemble des traitements réalisés sur le système d’IA, notamment :
les requêtes des utilisateurs (en prenant garde à leur protection si ces requêtes contiennent des données sensibles) ;
les traitements réalisés en entrée sur cette requête avant l’envoi au modèle ;
les appels à des plugins ;
les appels à des données additionnelles ;
les traitements réalisés par les filtres en sortie ;
les réponses aux utilisateurs.
Cas particulier de la génération de code source assistée par l'IA
R30
R30 Contrôler systématiquement le code source généré par IA
Le code source généré par IA doit faire l’objet de mesures de sécurité afin de vérifier
son innocuité :
proscrire l’exécution automatique de code source généré par IA dans l’environnement
de développement ;
proscrire le commit automatique de code source généré par IA dans les dépôts ;
intégrer un outil d’assainissement de code source généré par IA dans l’environnement
de développement ;
vérifier l’innocuité des bibliothèques référencées dans le résultat du code source
généré par IA ;
faire contrôler régulièrement par un humain la qualité du code source généré à
partir de requêtes types suffisamment sophistiquées.
R31
R31 Limiter la génération de code source par IA pour des modules critiques d'applications
Il est fortement recommandé de ne pas utiliser un outil d’IA générative pour générer des blocs de code source destinés à des modules critiques d’applications :
les modules de cryptographie (authentification, chiffrement, signature, etc.) ;
les modules de gestion des droits d’accès des utilisateurs et administrateurs ;
les modules de traitement de données sensibles.
R32
R32 Sensibiliser les développeurs sur les risques liés au code source généré par IA
Il est recommandé d’effectuer des campagnes de sensibilisation sur les risques liés à l’utilisation de code source généré par IA. Cette sensibilisation peut s’appuyer sur des rapports publics sur ce sujet ou bien des papiers de recherche 23démontrant la présence de vulnérabilités dans le code généré par IA.
En complément, les développeurs peuvent également être formés sur les outils d’IA pour l’optimisation de leurs requêtes (prompt engineering) afin d’améliorer la qualité et la sécurité du code généré.
R33
Cas particulier de services d'IA grand public exposés sur Internet
R33 Durcir les mesures de sécurité pour des services d'IA grand public exposés sur Internet
Il est recommandé d’apporter une attention particulière sur certaines mesures de
sécurité pour les services exposés au grand public, notamment :
entraîner le modèle d’IA uniquement à partir de données publiques ;
s’assurer que les utilisateurs du système d’IA ont fait l’objet d’une authentification
au préalable ;
analyser systématiquement les requêtes des utilisateurs sur le système d’IA ;
faire un contrôle et une validation des réponses avant l’envoi aux utilisateurs ;
protéger en confidentialité les données des utilisateurs (historique des requêtes
et des réponses, etc.) ;
mettre en place des mesures contre les dénis de service distribués (DDoS);
sécuriser le service web en frontal des utilisateurs.
R34
Cas particulier de l'utilisation de solutions d'IA générative tierces
R34 Proscrire l'utilisation d'outils d'IA générative sur Internet pour un usage professionnel impliquant des données sensibles
L’entité cliente n’ayant pas la maîtrise du service d’IA générative, il n’est pas possible de s’assurer que la protection en confidentialité des données soumises en entrée respecte les besoins de sécurité de l’entité.
Par mesure de précaution, il est donc obligatoire de ne jamais intégrer de données sensibles de l’entité dans les requêtes des utilisateurs.
R35
R35 Effectuer une revue régulière de la configuration des droits des outils d'IA générative sur les applications métier
Il est recommandé de faire une revue des droits d’accès des outils d’IA générative dès l’activation du produit dans l’entité, afin de s’assurer que les droits positionnés par défaut ne sont pas trop laxistes ou trop ouverts par conception.
Enfin, une revue régulière des droits d’accès doit être réalisée (ex. : tous les mois), afin notamment de s’assurer que les mises à jour fonctionnelles et de sécurité du produit ne viennent pas impacter le besoin d’en connaître pour les utilisateurs.
Contacts
N'hésitez pas à contacter Hervé @ biZNov si vous avez des questions ou pour me faire savoir s’il y a d'autres sujets que vous aimeriez voir traiter sur ce blog.
Et n'oubliez pas de diffuser l'information si vous avez aimé cet article de blog , Il suffit de cliquer sur les boutons de réseaux sociaux ci-dessous.
Partager, c'est apprécier :-)
Comments