Accueil > Smart Business / MLSecOps : comment la sécurité doit-elle accompagner les projets de Machine Learning ?
Yann Bilissor

Smart Business / MLSecOps : comment la sécurité doit-elle accompagner les projets de Machine Learning ?

Smart Business / MLSecOps : comment la sécurité doit-elle accompagner les projets de Machine Learning ?

La manipulation de données dans le cadre d’un projet d’Intelligence Artificielle ou de Machine Learning soulève un certain nombre de questions au sujet de la sécurité auxquelles toutes les entreprises doivent être en mesure de répondre. Dans cet article, nous allons aborder la sécurité sous différents angles sans trop rentrer dans les détails à propos du MLOps, mais en nous interrogeant sur la place que la sécurité doit occuper tout au long de la conception d’une solution de Machine Learning. Voici les principales questions auxquelles nous allons tenter de répondre :

  • Quels sont les principaux piliers sur lesquels repose la sécurité dans une architecture d’Intelligence Artificielle dans le Cloud moderne ?
  • Quelles sont les principales étapes d’un projet d’industrialisation du Machine Learning ou du MLOps ?
  • Quelles sont les fonctionnalités de sécurité à mettre en œuvre systématiquement dans toutes les solutions de Machine Learning ?
  • Comment protéger la valeur Business au fil du temps ?

 

Motivation

 

Le MLSecOps correspond à une nouvelle discipline qui réunit le MLOps et la sécurité de façon agile. Si le MLOps vise à développer les pratiques DevOps dans l’univers de l’Intelligence Artificielle, le MLSecOps nous rappelle pourquoi nous devons toujours penser de façon intelligente, nous adapter vite et surmonter les obstacles rapidement lorsque nous manipulons des données d’entreprise en interne ou en externe.

 

Architecture IA dans le cloud : et si nous parlions de l’approche PPT ?

 

PPT signifie « People, Processus et Technologies ». Il s’agit d’une approche qu’il est recommandé de toujours mettre en œuvre lors du développement d’une architecture (dans le Cloud), quelle qu’elle soit, ou lors de la conception d’un modèle d’exploitation cible d’une plateforme. La question est la suivante : pourquoi est-il important de prendre en compte l’approche PPT d’un point de vue de la sécurité ? Avant tout parce que la plupart des activités des entreprises sont réalisées, ou du moins déclenchées, par des personnes qui utilisent des processus mis en place et qui s’appuient sur des technologies à des fins d’efficacité. Ces 3 composants peuvent donc jouer un rôle essentiel en termes de faille de sécurité et par conséquent doivent être traités aux différents niveaux.

 

People

 

Vous devez clairement identifier les rôles et les responsabilités de l’ensemble des personnes ou des objets ayant des interactions avec votre plateforme de façon à ce que les risques, qu’ils soient faibles ou élevés, puissent être mesurés et considérés comme acceptables ou non. Par exemple, il peut être déterminant d’autoriser un data scientist à effectuer plus d’actions dans un certain champ d’application que ce dont il a besoin ou que ce qu’il devrait. Dans Azure par exemple, le rôle de contributeur est trop permissif pour des environnements critiques (comme la production). Les profils les plus courants des personnes intervenant sur des projets IA sont les suivants : data engineer, AI engineer, MLOps engineer ou data scientist. Vous devez clairement identifier les responsabilités de ces personnes en tant qu’« actions » qu’elles sont autorisées ou non à effectuer dans un périmètre  spécifique et au fil du temps. Pour contrôler cela, vous devez vous appuyer sur les technologies et les processus, mais vous devez surtout réfléchir dans un premier temps à la façon de concevoir ce cadre.

 

Technologies

 

Choisissez les technologies avec le plus grand soin, car elles vous aideront à mettre en œuvre la valeur commerciale que vous recherchez à obtenir des contraintes de sécurité que vous ou votre entreprise avez conçues. Que ce soit dans un contexte de Cloud ou non, les technologies modernes doivent mettre à votre disposition au moins deux composants de sécurité principaux :

  • Authentification : décliner votre identité lors de l’accès à la plateforme
  • Autorisation: définir ce que vous pouvez et ne pouvez pas faire sur la plateforme

 

Grâce à ces deux éléments, vous pouvez contrôler toutes les interactions des personnes ou des objets avec les technologies que vous avez mises en place. Dans Microsoft Azure par exemple, vous pouvez exploiter l’Azure Active Directory pour intégrer cette couche de sécurité à votre plateforme. D’ailleurs, si vous regardez d’un peu plus près les solutions IA disponibles auprès de ce fournisseur Cloud, telles que les solutions Azure Machine Learning ou Azure Databricks, vous remarquerez qu’elles prennent toutes en charge cette approche de la sécurité. Selon différents niveaux de maturité, certes, mais elles la prennent en charge tout de même. N’hésitez donc pas non plus à y avoir recours !

La journalisation est également un composant de sécurité clé, qui doit toujours être présent sur l’une des couches de votre architecture. Un composant très utile lorsque les membres du service d’audit viennent vous rendre visite et vous demandent d’y avoir accès. Normalement, vous devriez pouvoir être en mesure de savoir :

  • Qui s’est connecté, qu’est-ce que cet utilisateur a fait et comment le système a réagi.
  • Dans quelle mesure les personnes ou les objets respectent les mécanismes de sécurité que vous avez mis en place.
  • Si la « valeur » attendue ne faiblit pas au fil du temps.
  • Dans quelle mesure la rétro-ingénierie de votre valeur Business peut avoir un impact sur votre entreprise ? Par exemple, est ce qu’il est possible qu’un outil externe soit en capacité de prédire les sorties de vos modèles machines Learning et donc d’apprendre la fonction sous-jacente ? Vous devez donc contrôler cela soit lors les phases d’entraînement du model (en introduisant du bruit par exemple) ou en rajoutant un rate limiter lorsque vous exposez les modèles via APIs.

 

Voici les 3 principales couches que vous devez prendre sérieusement en compte lorsque vous vous intéressez à la sécurité :

Smart Business - 3 main layers

 

En somme, comme vous exposez des données dans des applications hébergées sur diverses infrastructures, la sécurisation de chaque couche est donc capitale dans le design d’architecture envisagée.

 

Process

 

Les personnes ou les objets interagissent avec les technologies en utilisant (ou non) des process. Contrôler la façon dont s’effectuent ces interactions permet déjà d’éviter certaines failles de sécurité. Par exemple, les discussions avec l’équipe de data scientists sont l’occasion d’aborder un grand nombre de sujets :

  • Comment les data scientists découvrent-ils les données d’une entreprise ?
  • Comment peuvent-ils avoir accès à la base de données ou au Data lake d’une entreprise ?
  • Quelles données peuvent-ils voir ou non à partir de cette base de données ?
  • Comment peuvent-ils utiliser les données et partager des informations avec l’entreprise ?
  • Comment peuvent-ils offrir une valeur Business aux clients externes ?
  • Et ainsi de suite…

 

Le fait de noter par écrit toutes ces questions vous obligera à définir et à concevoir les processus d’interaction entre les personnes et les technologies.

 

interactions between Smart Business - People and Technologies

 

 

MLSecOps : les 5 principaux défis techniques à relever

 

Le MLOps correspondent à une discipline récente qui s’appuie sur la pratique DevOps pour développer et exécuter une solution de Machine Learning. Contrairement aux applications traditionnelles, les applications de Machine Learning sont un peu délicates à développer, car elles s’appuient principalement sur des données et, comme vous le savez peut-être, les données changent en permanence. Vous devez donc régulièrement vous assurer que la valeur business que vous proposez avec votre modèle de Machine Learning ne faiblit pas au fil du temps. Voici un parcours de Machine Learning classique :

Smart Business - MLops main Steps

Principales étapes des MLOps

 

Découvrons maintenant pourquoi vous devez toujours prendre en compte la sécurité lorsque vous concevez une solution de Machine Learning.

 

Rassembler les données

 

Du point de vue de la sécurité, il est essentiel de fournir les données qui seront utilisées pour entraîner le processus de Machine Learning. En tant qu’architecte de la sécurité, vous devez donc toujours pouvoir répondre aux questions suivantes :

  • Qui demande à accéder aux données ? Cette question vous aide à identifier les rôles et les responsabilités
  • À quel type de données l’utilisateur souhaite-t-il accéder ? Cette question vous aide à identifier l’ampleur, ainsi que les impacts techniques et business potentiels.
  • Que peut-il faire avec ces données ? Cette question vous aide à définir approximativement le niveau de conformité que l’équipe projet ou les data scientists doivent respecter avant de lancer une solution. Par exemple, l’utilisateur utilise-t-il des données personnelles pour offrir une valeur commerciale ?
  • À quelle fréquence les données doivent-elle être fournies ? Si l’exportation des données a lieu régulièrement, leur mise à disposition va impliquer un processus technique, ce qui signifie que vous devez identifier ce processus et savoir comment le sécuriser.

 

Entraîner

 

C’est là que la magie de l’Intelligence Artificielle opère. Par conséquent, soyez prudent, car l’entraînement est une étape très gourmande en ressources qui, pour faire simple, transforme des données en informations en utilisant des algorithmes complexes exécutés sur de (gros) ordinateurs. Vous devez donc contrôler sur quels ordinateurs les données de l’entreprise seront traitées et de quelle façon. Dans un environnement Cloud par exemple, veillez à ce que la machine virtuelle ou les clusters soient suffisamment sécurisés pour exécuter cette charge de travail. Voici quelques points à vérifier :

 

  1. Les machines virtuelles qui exécutent la charge de travail du Machine Learning sont-elles protégées d’un point de vue réseau ? Cette question vous permet d’empêcher tout accès externe et toute fuite de données éventuelle.
  2. Quelles identités (utilisateurs, groupe d’utilisateurs ou d’applications) peuvent accéder à ces machines virtuelles ou clusters ? Cette question vous permet d’empêcher toute action ou accès indésirable aux données manipulées par ces machines virtuelles.
  3. Quelles sont les autres dépendances du système (stockage, fichier journal, API…) impliquées à cette étape ? Cette question vous aide à identifier et à gérer le trafic entrant et sortant.

 

Packager

 

Il est important d’entraîner les algorithmes de Machine Learning, mais il est parfois relativement difficile de packager le modèle qui en découle, car vous devez connaître le format du package cible et savoir comment il fonctionne. Les data scientists peuvent opter pour un format ou un autre car il en existe plusieurs, mais il relève de votre responsabilité d’évaluer l’ensemble des risques potentiels que présente le modèle choisi. Les plus populaires sont les formats pickle, ONNX, zip… et chacun d’eux présente ses propres spécifications. Le modèle le plus utilisé est le format pickle (.pkl), car il s’agit de simple exécution de codes, qui ont été sérialisés sur disque ou toute autre solution de stockage et qu’il est possible de réexécuter facilement.

Néanmoins, si ces codes contiennent une faille de sécurité, vous risquez de la propager en phase de production si vous n’y faites pas vraiment attention. Les solutions SAST et DAST peuvent vous simplifier la tâche, dans un premier temps, mais gardez à l’esprit que ces « lignes de codes » combinées à vos « données » offrent de la valeur business, c’est pourquoi vous devez suivre cela de près ! 

 

Déployer

 

Vous avez entraîné et packagé votre modèle de Machine Learning. Vous êtes donc maintenant prêt à procéder à son déploiement. Qu’est-ce que cela signifie ? À ce stade, vous devez choisir le type de compute sur lequel votre modèle sera exécuté. Il peut s’agir d’une machine virtuelle, d’un cluster de calcul, d’un composant PaaS… Chaque déploiement cible peut présenter différentes contraintes, mais voici les questions que j’ai l’habitude de poser :

  • Où le modèle packagé est-il enregistré ? Cette question vous aide à soulever des problématiques liées à la sécurité de l’emplacement d’enregistrement des modèles (par exemple, registre des modèles dans AzureML ou Databricks).
  • À quelle fréquence sera-t-il amené à être modifié (de façon approximative bien entendu) ? Cette question vous aide à définir le niveau d’automatisation, les technologies, puis le processus à sécuriser afin de pouvoir charger/décharger les modèles.
  • Comment l’environnement d’exécution devra-t-il charger le modèle ? Cette question vous aide à identifier le trafic entrant et sortant. Par trafic, j’entends l’emplacement source et cible, le protocole utilisé pour les communications réseau et le statut (autorisé ou refusé).

 

L’un des formats de déploiement les plus souvent utilisés dans ce domaine est une image Docker. Elle offre un certain niveau de flexibilité, de cohérence, de résilience et de nombreux autres avantages. Mais étant donné que l’image Docker a recours à des images d’OS, si vous en utilisez une par défaut, vous risquez de rencontrer des problèmes de sécurité à différents niveaux.

Par exemple, il est possible que les packages Python utilisés pour développer le modèle ne soient pas autorisés d’un point de vue des normes de l’entreprise, que des certificats d’entreprise ne soient pas utilisés lors de l’exposition d’APIs au moyen d’images Docker Flask ou FastAPI de base, etc. Vous devez donc rester également vigilant sur ce point.

 

Servir

 

Enfin, à cette étape, vous pouvez partager votre modèle en interne ou en externe. Il existe différentes façons d’exposer un modèle de Machine Learning auprès d’utilisateurs ou d’autres applications, mais dans tous les cas, vous souhaitez que le vôtre soit exécuté sur des données. Voici quelques exemples de questions que vous devez vous poser :

  • Qui peut appeler votre modèle et comment ? Cette question vous aide à définir le concept d’« identité » dans votre contexte. Gardez à l’esprit qu’une identité représente tout élément pouvant être authentifié, tel qu’un utilisateur, un groupe d’utilisateurs ou d’applications. La façon d’appeler le modèle a également son importance. Par exemple, le transfert d’un fichier JSON ou binaire vers un modèle via une API ne présente pas les mêmes problèmes de sécurité. Soyez donc vigilant !
  • À quelle fréquence une identité bien précise effectue des appels auprès du modèle et quel en est l’impact ? Cette question vous aide à identifier toute attaque potentielle par rétro-ingénierie et à protéger votre valeur Business.

 

One Last thing

 

Gardez à l’esprit que le Machine Learning est une discipline qui génère des informations à partir de données d’entreprise au moyen de codes écrits la plupart du temps en Python ou R. Il s’agit d’un élément important, si bien que vous devez rester attentif à un grand nombre d’aspects, tels que les suivants :

 

  • La façon dont les personnes internes et externes interagissent avec la plateforme en explorant et en concevant la notion d’identité au niveau de l’entreprise. Là encore, nous appelons identité tout objet pouvant être authentifié, tel qu’un utilisateur, un groupe d’utilisateurs ou d’applications.
  • Les outils ou les technologies qu’elles utiliseront pour générer la valeur business. Il existe des outils dans ce domaine, tels qu’Azure Machine Learning ou Azure Databricks, qui sont en mesure de gérer un workload Machine Learning. N’hésitez pas à les utiliser si vous travailler dans un environnement Azure, par exemple.
  • Une image Docker est un format de déploiement intéressant, mais peut être à l’origine de nombreuses failles de sécurité. N’utilisez pas nécessairement l’image par défaut avec des paramètres par défaut. Vous devez vérifier les packages qui y sont installés, ainsi que le niveau d’accès des utilisateurs. Il est recommandé de regénérer l’image d’une entreprise en y intégrant toutes les exigences déjà configurées (certificats, connexion au référentiel…)
  • La volonté d’augmenter la valeur business conduit les entreprises à développer des algorithmes complexes dans le but de mieux comprendre les données. Vous devez donc veiller à ce que la valeur cible ne faiblisse pas et que personne ne puisse procéder à la rétro-ingénierie du modèle que vous proposez. Contrôlez les interventions et les comportements pour détecter et qualifier les menaces le plus tôt possible. Utilisez également certaines techniques pour empêcher le modèle de dériver en cas de DataDrift ou ConceptDrift.

 

Cellenza aide les entreprises à résoudre leurs problèmes de sécurité dans le cloud. Vous souhaitez en savoir plus sur notre offre « Cloud Security » ? Contactez-nous !

Nos autres articles
Commentaires
Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Restez au courant des dernières actualités !
Le meilleur de l’actualité sur le Cloud, le DevOps, l’IT directement dans votre boîte mail.