Entre prompts bavards, shadow IA et code généré à la volée, les identités machines prolifèrent à une vitesse folle, souvent sans garde-fous adaptés pour éviter l’exposition massive de secrets. Avec des agents IA capables d’agir sans supervision, chaque clé API oubliée ou chaque secret codé en dur devient une faille potentielle prête à être exploitée.
Ce n’est pas un hasard si les identités machines (Non-Human Identities – NHIs) attirent de plus en plus l’attention alors que les outils basés sur l’IA et les agents autonomes sont rapidement adoptés. En fait, c’est en partie ce qui explique l’explosion des NHIs dans l’entreprise. Cela a suscité de nombreuses recherches et discussions sur l’identité et la gouvernance des identités machines.
Comme les utilisateurs humains des systèmes, les NHI, tels que les agents d’IA, les robots, les scripts et les workloads dans le cloud, fonctionnent à l’aide de secrets. Ces identifiants permettent d’accéder à des systèmes et des données sensibles. Ils peuvent prendre de nombreuses formes et doivent toujours être pris en compte, de leur création à leur suppression. Contrairement aux humains, les machines ne peuvent pas utiliser l’authentification multifactorielle ou les mots de passe, et les développeurs peuvent générer des centaines de ces identifiants dans le cadre de leur travail de déploiement d’applications.
Le taux d’adoption de l’IA dans les entreprises a été très rapide, ce qui a poussé les développeurs à déployer des NHI plus rapidement que jamais. L’IA offre la possibilité d’accomplir beaucoup plus de choses plus efficacement, mais elle comporte également des risques réels en matière de confidentialité, d’exposition des secrets et de code non sécurisé. Il existe des cas d’utilisation étonnants pour les LLM, mais nous devons nous rappeler que, comme pour toute technologie, plus nous ajoutons d’éléments à notre environnement, plus la surface d’attaque s’agrandit. Cela est particulièrement vrai lorsque nous donnons du pouvoir à ces agents d’IA.
Les risques des identités machine liées à l’IA
Les agents d’IA et les secrets de l’IA
Les « agents d’IA » sont des systèmes basés sur un LLM qui décident de manière indépendante de la manière d’accomplir une tâche spécifique. Il ne s’agit pas des robots déterministes que nous utilisons depuis des années avec de nombreux workflows, qui ne peuvent exécuter que les instructions spécifiques que le développeur a définies étape par étape. Ces agents d’IA peuvent accéder à des sources de données internes pour rechercher des informations, effectuer des recherches sur Internet et interagir avec d’autres applications au nom de l’utilisateur.
Par exemple, un agent d’approvisionnement alimenté par l’IA pourrait analyser les besoins d’achat, comparer les fournisseurs sur les sites d’achat en ligne, négocier les prix avec des chatbots IA et même passer des commandes de manière autonome si cela est autorisé. Chaque communication sécurisée nécessite des identifiants d’accès. Ce nouvel agent est produit par le biais d’un processus DevOps, ce qui nécessite encore plus d’authentification tout au long du pipeline. Les identifiants sont souvent, et accidentellement, fuités dans les systèmes, les journaux et les dépôts de code en cours de route.
Il est très courant d’accorder aux agents IA des autorisations de lecture, d’écriture et même de création et de suppression plus larges que celles que nous accorderions à des robots déterministes. Pour les workers traditionnels, nous définissons les systèmes auxquels ils peuvent ou ne peuvent pas accéder dans le cadre du travail que nous leur confions. Étant donné que les agents IA sont libres de déterminer la meilleure façon d’accomplir le travail sans supervision directe, nous bloquons le travail demandé si nous limitons trop strictement leurs accès. Les autorisations de lecture et d’écriture requises peuvent ne pas être claires dès le départ, et de nombreuses équipes commettent l’erreur d’être trop permissives.
La fuite de l’une des nombreuses clés impliquées pourrait entraîner une violation de données ou des achats non autorisés, entre autres risques. Une solide gouvernance des identités machine est essentielle pour sécuriser ces agents d’IA. Pour tous les identifiants connus et correctement stockés dans les coffres-forts, il faut donner l’accès avec le moins de privilèges possible, la protection des clés API et la journalisation des audits pour éviter toute exploitation. La stratégie des organisations doit également tenir compte des secrets qui seront sans aucun doute également trouvés en dehors de des coffres-forts.
Clés API orphelines
Une clé API orpheline est une clé API qui n’est plus associée à un compte utilisateur. Cela se produit lorsqu’un utilisateur quitte une entreprise ou supprime son compte. Toutes les clés API qu’il a créées restent valides, mais désormais, personne ne les possède et, à moins qu’elles ne soient correctement comptabilisées, elles ne seront probablement jamais renouvelées ou supprimées.
Dans le monde des identités machine, la question de savoir à qui appartient une NHI est délicate. Est-ce à la personne qui l’a créée ? À une équipe DevOps dédiée ? Sans propriété claire, la probabilité qu’un identifiant devienne orphelin et soit oublié tout en permettant toujours l’accès est très élevée.
Une meilleure question serait de savoir à qui appartient le risque associé à une violation causée ou facilitée par ces clés API ?
Architecture basée sur des prompts et exposition de données sensibles
Lorsque nous pensons à un assistant IA, nous pensons immédiatement à des acteurs tels que ChatGPT, Gemini et Claude, qui utilisent tous des architectures basées sur des prompts. GitHub Copilot aussi. Les modèles d’IA traitent, stockent et transmettent des informations sensibles par le biais de prompts, en envoyant du contexte, des commandes et des données à un fournisseur de modèles de langage large (LLM). Cette approche rend ces outils exceptionnellement faciles à utiliser, ce qui permet un prototypage et un développement rapides des outils.
Cela ne se limite pas aux équipes de développement. En effet, le shadow IT représente la majorité des dépenses informatiques dans de nombreuses organisations, les risques réels d’exposition des données, de données commerciales propriétaires et de fuite d’informations d’identification se propagent dans toute l’entreprise.
Par exemple, si une équipe financière utilise un chatbot alimenté par l’IA pour automatiser le traitement des factures, et que son prompt contient Trouver toutes les factures de plus de 100 000 $ au cours des 6 derniers mois en utilisant la clé API ABC123, cette clé API sera très probablement enregistrée. Si ces journaux sont laissés en clair, ils permettraient à un attaquant d’accéder sans autorisation à ce système de facturation. Il faut espérer que cette clé soit correctement délimitée.
Des mesures de protection doivent être mises en place pour empêcher les développeurs et tous les utilisateurs d’intégrer des données sensibles dans les prompts et les journaux. Idéalement, chaque sortie LLM peut être analysée pour détecter les informations qui ne devraient pas s’y trouver. S’il peut être difficile de définir quelles données renvoyées sont sensibles, trouver et éliminer les secrets devrait être simple et prioritaire.
Agents IA et risques liés à la collecte de données
Les agents IA ingèrent, traitent et stockent souvent des données provenant de diverses sources, notamment :
– Le stockage dans le cloud, comme AWS S3 et Google Drive.
– Les applications d’entreprise, comme Jira, Confluence et Salesforce.
-Les systèmes de messagerie, y compris Slack et Microsoft Teams.
Les organisations doivent s’efforcer de garder toutes les informations sensibles, telles que les identifiants, les informations personnelles identifiables ou d’autres données privées, hors de ces systèmes. Si un agent d’IA peut accéder à des données dans ces systèmes, alors le chemin pour un attaquant d’abuser de ces identités machines existe également.
Le seul moyen sûr d’éliminer ce vecteur d’attaque est de trouver et de renouveler toutes les clés trouvées dans tous les systèmes internes autour de tous les agents IA. Cela inclut les systèmes de contrôle de version, les systèmes de ticketing et les plateformes de messagerie. Associé à un bon nettoyage des journaux, cela peut grandement contribuer à garder vos secrets secrets.
Code généré par l’IA et secrets intégrés
Les outils de développement basés sur l’IA tels que GitHub Copilot, Amazon CodeWhisperer et Tabnine ont connu un taux d’adoption rapide. Aujourd’hui, plus de 50 % des développeurs utilisent des copilotes d’IA pour les aider à coder. Ces outils génèrent automatiquement des extraits de code à partir de vastes quantités de données d’apprentissage. Cependant, cela introduit un risque majeur pour la sécurité, car le code généré par l’IA peut induire en erreur un développeur et l’inciter à coder en dur des secrets, tels que des clés API, des identifiants de base de données et même des jetons OAuth.
Pour illustrer un risque généré par l’IA, imaginons qu’un développeur demande à Copilot de générer un appel API vers un service cloud, et que celui-ci produise :
# Exemple d'appel API vers un service Cloud en Python
import requests
API_KEY = "sk_live_ABC123XYZ"
response = requests.get("https://api.example.com/data", headers={"Authorization": f"Bearer {API_KEY}"})
Cet exemple de code a été produit par ChatGPT.
Bien qu’il ne s’agisse pas d’une véritable clé, un développeur pressé par le temps ou qui n’est pas familier avec la sécurité des secrets pourrait tout simplement échanger une vraie clé contre celle générée. Si rien n’est fait, ce code peut être validé dans les systèmes de contrôle de version, exposant ainsi les identifiants aux attaquants qui y accèdent ou à n’importe qui si le dépôt devient public.
Ce schéma explique en partie pourquoi la prolifération des secrets n’a cessé de s’aggraver au fil du temps.
La voie à suivre : sécuriser les identités machine
Éducation et sensibilisation
La première étape pour atténuer ces risques est d’éduquer les développeurs et les équipes de sécurité sur les dangers liés à l’exposition des secrets aux LLM. Les organisations devraient:
– Former les développeurs aux risques de partage de code contenant des secrets avec des LLM
– Élaborer des politiques claires sur ce qui peut être partagé avec les assistants IA
– Sensibiliser à l’importance du stockage sécurisé des secrets
Mise en œuvre de solutions techniques
Plusieurs approches techniques peuvent aider à sécuriser les identités machine à l’ère de l’IA:
– Détection automatisée des secrets: Utiliser des outils pour analyser le code avant qu’il ne soit partagé avec les LLM
– Gestion centralisée des secrets: Stocker les secrets dans des coffres-forts dédiés plutôt que dans le code
– Rotation régulière des identifiants: Limiter la période pendant laquelle un secret compromis peut être exploité
– Mise en place du principe du moindre privilège: Limiter les accès accordés à chaque identité machine
Adoption d’une approche proactive
Les organisations doivent intégrer la sécurité des identités machine dans leur stratégie globale de cybersécurité:
– Inclure les risques liés aux LLM dans les évaluations de sécurité
– Surveiller activement les activités suspectes liées aux identités machine
– Mettre en place des contrôles préventifs et des mécanismes de détection
– Développer des plans de réponse aux incidents spécifiques aux compromissions d’identités machine
À mesure que l’IA continue de s’intégrer dans les processus de développement logiciel, la sécurité des identités machine deviendra un pilier fondamental de toute stratégie de cybersécurité. En comprenant les risques et en adoptant une approche proactive, les organisations peuvent continuer à bénéficier des avantages de l’IA tout en protégeant leurs informations d’identification les plus sensibles.
L’équilibre entre innovation et sécurité nécessitera une vigilance constante, des politiques adaptées et l’utilisation d’outils spécialisés pour détecter et prévenir les fuites de secrets dans ce nouveau contexte technologique.
____________________________
Par Dwayne MacDaniel, Developer & Cybersecurity Advocate chez Gitguardian
puis