Le Blog Amazon Web Services

Sécurité et Conformité des applications basées sur l’apprentissage machine (Machine Learning)

Cet article accompagne le podcast Français du même titre publié le 27 Mai 2022. Il présente 4 catégories de risques associés aux applications de Machine Learning et les techniques pour les maîtriser :

  • Les risques liés à la confidentialité tel que le reverse-engineering et l’exfiltration des données d’entraînement et de test,
  • Les risques de non intégrité tel que la corruption des modèles (qui peut se faire en injectant de mauvaises données dans le dataset d’entraînement),
  • Le manque de précision (« Accuracy »en anglais) ou la probabilité d’avoir une mauvaise réponse du modèle,
  • les risques juridiques (droit à l’explication, à l’oubli et l’usage des données personnelles).

La maîtrise des risques se fait par :

  • L’utilisation de solutions génériques à toute application : contrôle d’accès, protection des données, usage de pipelines de développement, sauvegarde et ségrégation des droits et des comptes AWS de développement et de production,
  • L’utilisation de solutions spécifiques aux applications d’apprentissage machine : indexation des données et des modèles de données pour pouvoir les supprimer et les ré-entraîner, utilisation de données synthétiques, prévention du reverse-engineering, utilisation des modèles en série ou en parallèle, détection de biais.

Les risques associés aux applications utilisant le Machine Learning

Une évaluation des risques s’impose pour les applications Machine Learning au même titre que tout autre type d’application. On en retiendra 4 catégories:

  • Les risques liés à la confidentialité tel que le reverse-engineering et l’exfiltration des données d’entraînement et de test,
  • Les risques de non intégrité tel que la corruption des modèles (qui peut se faire en injectant de mauvaises données dans le data set d’entraînement)
  • Le manque de précision (« Accuracy » en anglais). Dans les modèles de classification où on évaluera la probabilité d’avoir une mauvaise réponse du modèle.
  • Enfin, en fonction de l’usage du modèle, il existe des risques juridiques tels que la nécessité d’explication des décisions, obligation de suppression des données et la modification des algorithmes qui en dérivent et l’usage des données personnelles. Cet article n’a pas vocation à donner de conseil juridique : nous invitons nos clients à étudier ces questions avec leur conseillers juridiques et de rester au courant des évolutions réglementaires.

Se protéger du risque d’exfiltration des données

La maîtrise du risque d’exfiltration des données nécessite la mise en place de mécanismes de protection et d’autorisation d’accès aux services (Identity and Acesss Management  et Service Control Policies) . Les services AWS utilisés pour le Machine Learning tels que Amazon Textract, Amazon Lex, Amazon Rekognition  intègrent dans leur API de contrôle les mécanismes habituels de protection (TLS et Sigv4). Ils peuvent également être associés à AWS PrivateLink pour sécuriser l’accès depuis un  Amazon Virtual Private Cloud (VPC). Par exemple, Amazon SageMaker peut être isolé dans un VPC, et utiliser AWS PrivateLink, mais également être restreint à accéder aux données d’entraînement situés dans un compartiment  (bucket) Amazon S3 accessible via  un point de terminaison (endpoint). On peut également protéger de la même façon les logs émanant de Amazon SageMaker vers Amazon CloudWatch . On peut utiliser AWS Direct Connect et les les points de terminaisons du VPC d’un cluster Amazon SageMaker afin accéder, entre autres aux Jupyter Notebooks d’Amazon SageMaker Studio . Enfin, Amazon SageMaker Studio peut également être configuré pour utiliser des URL’s signés pour l’accès à la console.

Pour la partie infrastructure de Machine Learning, les nœuds d’un cluster d’entraînement ou d’inférence Amazon SageMaker peuvent utiliser AWS Key Management Service (KMS) pour gérer les clefs de chiffrement des données au repos.  Ces nœuds peuvent utiliser TLS 1.2 pour protéger les données qui transitent entre eux. Amazon SageMaker utilise un proxy pour authentifier et autoriser l’accès aux cluster et les nœuds peuvent être associés à à des groupes de sécurité (Security Groups). L’accès à Internet depuis un notebook Amazon Sage Maker Studio est optionnel et peut être désactivé et contrôlé automatiquement en activant une règle AWS config . Enfin, les journaux peuvent être envoyés à Amazon CloudWatch.

Pour les clients utilisant des modèles achetés sur AWS Marketplace, il existe une fonctionnalité  permettant d’exécuter ces modèles dans un compte AWS dédié. Ce compte doit être différent des comptes AWS du client (acheteur) et du fournisseur (vendeur) pour permettre une double protection : d’une part des donnés du client et d’autre part de la propriété intellectuelle du fournisseur du modèle.

En ce qui concerne les pipelines de développement (Machine Learning Operations ou MLOps) Il est préférable d’utiliser une copie locale et validée des librairies externes dans AWS CodeArtifact pour éviter de les récupérer sur Internet sans validation de sécurité. Ceci permet également la maîtrise du périmètre de risque associé aux vulnérabilités des librairies. Nous vous recommandons d’éviter, en dehors de situations exceptionnelles, tout accès non-automatisé aux environnement de production . Ceci inclut l’obtention d’une copie des données (épurées des données personnelles) à l’usage de vos Data Scientists.

Pour la partie stockage des données, Il est conseillé d’utiliser les mécanismes de protection et d’accès et d’autorisation avec Amazon S3; à savoir : les Buckets Policies, les politiques IAM, SCP et les endpoints VPC . Les requêtes d’accès aux données peuvent être analysés avec IAM Access Analyser. Vous pouvez également utiliser les règles AWS config pour détecter la non-conformité de vos buckets Amazon S3. Une des techniques habituelles est de rendre les contenus des buckets Amazon S3 non modifiables en utilisant des SCP au niveau “Organisation” ou de mettre des verrous sur les objects (object locks).  Il faut noter que l’immutabilité des objets peut être incompatible avec le risque juridique de conformité au droit à l’oubli traité dans le paragraphe suivant. Par association, l’utilisation de AWS Key Management Service est également recommandée pour la gestion des clés de chiffrement / déchiffrement des données stockées sur Amazon S3.

Enfin pour maîtriser le risque d’exfiltration des données et modèles par action manuelle (copier/coller) nous conseillons l’utilisation de machines de travail Workspaces pour restreindre les opérations en dehors du périmètre de ces machines.

Se prémunir du risque Juridique

Mise en Garde : N’étant pas juristes, les auteurs tiennent à rappeler que ce qui est fourni dans cet article est leur interprétation générale de la réglementation en terme d’impact technologique et d’exigences de contrôles de sécurité. Le cas spécifique du lecteur doit être examiné par un juriste qualifié.

Ce que dit la réglementation Européenne

La RGPD et la réglementation européenne en préparation sur l’usage de l’intelligence artificielle peut engendrer un certain nombre de complications.  En dehors des aspects d’exportation des données en dehors de l’Union Européenne qui évolue au rythme des accords et des décisions de justice européenne, le point de vigilance principal est le “droit à l’oubli“ défini au chapitre III section 3, article 7 :

RÈGLEMENT (UE) 2016/ 679 DU PARLEMENT EUROPÉEN ET DU CONSEIL – du 27 avril 2016 – relatif à la protection des personnes physiques à l’égard du traitement des données à caractère personnel et à la libre circulation de ces données, et abrogeant la directive 95/ 46/ CE (règlement général sur la protection des données) Article 17 Droit à l’effacement («droit à l’oubli») 1. La personne concernée a le droit d’obtenir du responsable du traitement l’effacement, dans les meilleurs délais, de données à caractère personnel la concernant et le responsable du traitement a l’obligation d’effacer ces données à caractère personnel dans les meilleurs délais…. 

La définition de ce qui n’est ou n’est pas des données personnelles est décrit au chapitre I article 4 de la même réglementation :

RÈGLEMENT (UE) 2016/ 679 DU PARLEMENT EUROPÉEN ET DU CONSEIL – du 27 avril 2016 – relatif à la protection des personnes physiques à l’égard du traitement des données à caractère personnel et à la libre circulation de ces données, et abrogeant la directive 95/ 46/ CE (règlement général sur la protection des données)
«données à caractère personnel», toute information se rapportant à une personne physique identifiée ou identifiable (ci-après dénommée «personne concernée»); est réputée être une «personne physique identifiable» une personne physique qui peut être identifiée, directement ou indirectement, notamment par référence à un identifiant, tel qu’un nom, un numéro d’identification, des données de localisation, un identifiant en ligne, ou à un ou plusieurs éléments spécifiques propres à son identité physique, physiologique, génétique, psychique, économique, culturelle ou sociale; 

Un des autres points importants est ce que les auteurs de cet article choisissent d’appeler “le droit à l’explication” décrit au Chapitre III Section 2 Article 13 Clause 2f :

RÈGLEMENT (UE) 2016/ 679 DU PARLEMENT EUROPÉEN ET DU CONSEIL – du 27 avril 2016 – relatif à la protection des personnes physiques à l’égard du traitement des données à caractère personnel et à la libre circulation de ces données, et abrogeant la directive 95/ 46/ CE (règlement général sur la protection des données)
 2 : En plus des informations visées au paragraphe 1, le responsable du traitement fournit à la personne concernée, au moment où les données à caractère personnel sont obtenues, les informations complémentaires suivantes qui sont nécessaires pour garantir un traitement équitable et transparent : 
…..
f)l’existence d’une prise de décision automatisée, y compris un profilage, visée à l’article 22, paragraphes 1 et 4, et, au moins en pareils cas, des informations utiles concernant la logique sous-jacente, ainsi que l’importance et les conséquences prévues de ce traitement pour la personne concernée. 

La maîtrise du risque juridique

Pour l’aspect pratique et sans vouloir se substituer à votre juriste, on pourrait comprendre le règlement de la manière suivante :  si vous traitez des données à caractère personnel, vous devez mettre en place des mécanismes pour effacer celles-ci suite à une demande d’un utilisateur. Ceci peut avoir un impact important sur la technologie et le processus de gouvernance des données que vous utilisez pour stocker ou archiver les données.

Selon l’usage de votre modèle et les données utilisées pour son entraînement, vous pouvez éviter que le modèle soit sensible aux données à caractère personnel. Ceci peut-être fait lors de la phase de préparation des données et du “feature engineering” de votre processus de développement :

  •  Pour les données textuelles, la méthode la plus simple est l’anonymisation des données avec des fonctions arithmétiques qui ne permettent pas d’en retrouver l’origine (forward hash)
  • Pour les données non textuelles (les images et les vidéos) c’est plus compliqué car il faut détecter et enlever des éléments qui identifient une personne (comme le visage) à moins que ça soit l’objectif du modèle

Au cas où l’usage des données personnelles est inévitable , on peut indexer l’emplacement de ces données dans une bases de données comme Amazon DynamoDB : Au cas où une requête d’oubli ou de modification est reçue, le repérage de ces données est facilité et peut être couplé avec un processus de ré-entrainement du modèle en utilisant Amazon SageMaker Model Building Pipelines. Il existe sur GitHub des solutions intéressantes comme S3 find and Forget et sur notre blog consacré architecture: Integrating Redaction of FinServ Data into a Machine Learning Pipeline (article en anglais).

Si l’usage des données personnelles pour l’entraînement du modèle est inacceptable juridiquement il existe plusieurs alternatives :

  • L’usage des données synthétiques,
  • Le concept de “differential privacy” qui modifie les données à caractère personnel pour les détacher des sujet et rendre leur identification impossible. Ceci peut bien entendu affecter la précision du modèle,
  • Enfin on peut utiliser des moyennes pour anonymiser les données mais ceci peut affecter fortement la précision du modèle voire le rendre inexploitable.

Le droit à l’explication. Il convient de temps en temps comme indiqué par la réglementation de fournir une explication des décisions prises par un système automatisé. Pour cela, la méthode SHAP ( SHapley Additive exPlanations) pour caractériser l’influence des données fournies en entrée du modèle sur la réponse obtenue. Cette méthode est utilisée par Amazon Sagemaker Clarify. Bien connue dans les cercles  ML, la méthode SHAP n’est toutefois pas applicable à tout type de modèle.

Maîtriser la précision et la robustesse du modèle (Accuracy)

Afin de maîtriser le risque d’erreur d’inférence du modèle, vous pouvez, lors de la phase de test utiliser plusieurs techniques pour comprendre ses limites :

Se protéger contre le vol et l’empoisonnement d’un Modèle ML

Un bon modèle ML avec une grande précision est très convoité. Pour le protéger contre l’exfiltration et la corruption, plusieurs options sont envisageables :

  • L’utilisation des Service Control Policies (SCP) au niveau Organisation vous permet de restreindre les opération de copie de modification ou de suppression des modèles en utilisant les API de la console AWS (modulo les contrôles permettant de garantir le droit à l’oubli),
  • Il est possible de deviner le fonctionnement du modèle par une attaque dite d’inversion : imaginons que nous ayons un modèle de classification simple représenté par une courbe 2D. Si votre modèle retourne une mesure de précision de la classification, il est possible de la déduire en envoyant des requêtes proches de la zone d’incertitude (ou la précision est dégradée). Pour y remédier on peut protéger le modèle Amazon Sagemaker par un endpoint Amazon API Gateway et une fonction AWS  Lambda pour contrôler le taux (incidence) des requêtes. Ceci est à équilibrer avec le flux de requêtes légitimes à votre modèles,
  • Une autre technique consiste à  injecter intentionnellement du bruit dans la métrique de précision en retour du modèle pour ‘cacher’ la zone d’incertitude et rendre une attaque d’inversion plus difficile.

Si vous utiliser un modèle à apprentissage continu (continuous machine learning):

Un point important pour les modèles à apprentissage continu serait de sauvegarder régulièrement des copies (snapshots) du modèle pour pouvoir revenir à celles-ci si votre modèle venait à être empoisonné.

Enfin l’approche qui consiste à utiliser plusieurs modèles en série ou en parallèle augmente la robustesse du résultat en général. Un modèle qui ne fait qu’une chose à la fois le rend plus robuste :  Selon une étude publiée dans Quanta magazine (en anglais), les chercheurs ont entraîné un modèle pour détecter plusieurs types d’objets dans une pièce. Le modèle semblait bien fonctionner jusqu’à ce que les auteurs insèrent l’image d’un éléphant dans l’environnement de la pièce. Ceci justifie d’entraîner les modèles pour répondre à un objectif limité quitte à les utiliser ensemble pour effectuer une prédiction complexe (une idée similaire au ensemble machine learning).

La séparation en plusieurs modèles vous permet également de monitorer chacune des étapes d’inférence. Si les modèles sont utilisés en série, ceci permet de générer une mesure d’incertitude combinée des différent modèles. si cette incertitude combinée est inacceptable vous pouvez rejeter la requête.

Si les modèles sont utilisés en parallèle, vous pouvez comparer les différences de décision entre les modèles pour un même input et utiliser une stratégie d’ensemble. Un peu comme le concept de redondance utilisé dans l’ingénierie des avions dans l’aéronautique.

Pour aller plus loin

Une grande partie des concepts évoqués dans cette article reprennent largement ce qui est articulé dans le Well-Architected Framework – AIML Lens. Une vidéo d’un événement DevDay (en anglais) reprend également la plupart des recommandations. Enfin vous trouverez ci-après  un résumé des recommandations à retenir pour se protéger des risques associés aux application d’apprentissage machine (Machine Learning):

  • Utiliser l’apprentissage machine uniquement quand une autre solution déterministe (programmée classiquement) ne répond pas au besoin,
  • Filtrer et indexer les données d’entraînement quand elles contiennent des données à caractère personnel,
  • Filtrer et tester les données en entrée et en sortie d’une inférence et, surtout si vous avez un modèle issue d’un apprentissage continu, sauvegarder des copies du modèle régulièrement,
  • Utiliser une approche d’ensemble dans la conception de vos modèles pour en améliorer la robustesse,
  • Garder un œil sur l’évolution de la législation de protection de données et impliquer votre service juridique dans l’évaluation de vos modèles.

Voici les liens vers les services, articles, vidéos et podcasts que nous avons évoqués dans cet article :

Article contribué par Alexandre Menai : Manager –  Solution Architecture pour la sécurité et la Conformité et David Walker, Principal Solutions Architect dans les équipes Sécurité et Conformité.

Alexandre Menai est actuellement responsable des architectes AWS  pour la sécurité et conformité couvrant les régions Europe, Moyen Orient et Afrique. Sa mission est d’aider les clients AWS à améliorer leur contrôles de sécurité cloud et leur conformité avec la réglementation.  Avant de travailler chez AWS, Alexandre était directeur des équipes de développement data chez Dailymotion en France et manager de plusieurs équipes de développement chez Akamai Technologies aux Etats-Unis. Il a commencé sa carrière en tant qu’architecte réseau à Orange Labs Lannion. Docteur et Ingénieur en informatique et Télécommunications, Alexandre est diplômé de l’université de technologie de Troyes et de la faculté de Génie de l’université libanaise.

David Walker est Architecte Principal  AWS pour la sécurité et conformité. Sa mission est d’aider les clients AWS à améliorer leurs contrôles de sécurité cloud et leur conformité avec les réglementation et normes de sécurité. Il intervient également auprès des client AWS pour analyser le modèle de risque et déterminer les moyens de le maîtriser. Avant de rejoindre AWS, David a travaillé sur l’élaboration de standards de sécurité pour des clients basés au Royaume-Uni et aux états-unis. Il a également occupé le poste d’expert sécurité chez Sun Microsystems et Acorn Computersand. Inventeur de plusieurs techniques de contrôle de sécurité Cloud, il détient une licence et une maîtrise en physique des composants électroniques de l’université de Bristol. David assure un rôle exécutif au “Conservative Science and Technology Forum” pour  e-Crime et contribue  aux projets de sécurité du  “British Computer Society” et  “Information Assurance Advisory Council”.