38 To de données exposées par erreur par des chercheurs IA de Microsoft

• L’équipe de recherche en IA de Microsoft a accidentellement exposé 38 téraoctets de données privées en publiant sur GitHub des données d’entraînement open source
• Parmi les données exposées figuraient des sauvegardes de disques de travail de deux employés, des secrets, des clés privées, des mots de passe, ainsi que plus de 30�00 messages internes de Microsoft Teams
• Ces données ont été partagées à l’aide de jetons SAS, une fonctionnalité Azure permettant de partager des données dans un compte Azure Storage. Cependant, le lien était configuré pour partager l’ensemble du compte de stockage, ce qui a entraîné l’exposition des données
• Cet incident met en lumière les nouveaux risques auxquels les organisations sont confrontées lorsqu’elles utilisent l’IA, et montre la nécessité de contrôles de sécurité supplémentaires et de garde-fous à mesure que davantage d’ingénieurs manipulent de grands volumes de données d’entraînement
• L’équipe de recherche de Wiz a découvert cette exposition en repérant sur Internet un conteneur de stockage mal configuré
• Ils ont trouvé un dépôt GitHub nommé robust-models-transfer sous l’organisation Microsoft, créé pour fournir du code open source et des modèles d’IA pour la reconnaissance d’images, mais dont la mauvaise configuration permettait à une URL d’accéder à bien plus que les seuls modèles open source
• Le jeton utilisé était lui aussi mal configuré pour accorder un accès avec « contrôle total », ce qui permettait à un attaquant de consulter, supprimer et écraser des fichiers existants
• Cet incident souligne les risques de sécurité liés aux jetons SAS, qui accordent un niveau d’accès élevé aux comptes de stockage et peuvent poser des problèmes d’expiration. Ils sont également difficiles à gérer et à révoquer
• L’équipe de recherche de Wiz recommande d’éviter l’utilisation d’Account SAS pour le partage externe en raison de l’absence de sécurité et de gouvernance, et de privilégier Stored Access Policy ou User Delegation SAS pour un partage limité dans le temps
• L’équipe recommande également de créer des comptes de stockage dédiés pour le partage externe et d’utiliser un CSPM pour suivre et appliquer les politiques
• Cet incident rappelle aux équipes sécurité qu’elles doivent comprendre les risques de sécurité inhérents à chaque étape du processus de développement de l’IA, y compris les risques de surpartage des données et d’attaques de la chaîne d’approvisionnement
• Microsoft a ensuite invalidé les jetons SAS, les a remplacés sur GitHub, et a terminé une enquête interne sur l’impact potentiel

[GN⁺]

Avis Hacker News

• Article sur l’incident d’exposition de données causé par des chercheurs en IA de Microsoft, mais les commentateurs soulignent que cela n’a pas de lien direct avec l’IA
• Le problème concerne davantage le fournisseur cloud, des jetons de sécurité confus et la gestion des téléchargements de données à grande échelle
• L’un des risques spécifiques à l’IA mis en avant est l’utilisation d’objets Python sérialisés pour stocker de grands modèles d’IA, ce qui peut être obfusqué et potentiellement contenir du code malveillant
• L’incident était dû à une mauvaise configuration des jetons de stockage, un cas classique qui souligne la nécessité de tests d’intrusion réguliers
• L’utilisation de fichiers Pickle et de jetons SAS dans le stockage Azure est critiquée, et il est proposé d’utiliser à la place le contrôle d’accès basé sur les rôles (RBAC)
• Cet incident révèle une absence de défense en profondeur : les jetons SAS n’avaient pas de date d’expiration, donnaient un accès étendu et incluaient des sauvegardes de machines avec leurs propres jetons
• Il est suggéré de détruire tous les secrets et variables d’environnement, et de faire fonctionner la plupart des systèmes sur une base de rôles
• Cet incident semble être un échec humain dans la génération de jetons de sécurité, et il est proposé que les organisations mettent en place des OrgPolicy pour empêcher le partage massif de jetons d’authentification/identifiants
• Certains s’étonnent qu’il ait été possible d’exporter des messages Teams depuis Teams
• L’exposition des données a duré deux ans et a été corrigée il y a deux mois
• Certains commentateurs n’aiment pas le système de gestion des clés d’Azure et suggèrent qu’il vaudrait mieux avoir un nombre illimité de clés nommées par conteneur
• Cet incident semble prouver la difficulté de la sécurité cloud : une ou deux erreurs peuvent exposer des téraoctets de données