Sécuriser les systèmes d'IA – IAM, chiffrement et vulnérabilités spécifiques

Bonne lecture et bon apprentissage ! Junior TSAFACK – 11/09/2026 ⏱️ Temps de lecture estimé : 15 minutes

Sécuriser un système d’IA combine deux couches : les fondamentaux de la sécurité cloud (IAM, chiffrement, réseau) qui s’appliquent à n’importe quelle charge de travail AWS, et des vulnérabilités spécifiques à l’IA qu’il faut connaître pour les anticiper. Ce chapitre couvre le premier énoncé de tâche du domaine 5 (14 % de l’examen AIF-C01).

Le modèle de responsabilité partagée appliqué à l’IA

Sur AWS, la sécurité est une responsabilité partagée : AWS sécurise « le cloud » (l’infrastructure physique, les centres de données, le matériel), le client sécurise « ce qu’il met dans le cloud » (configuration des services, données, contrôle d’accès). Le niveau de responsabilité du client varie selon le service :

Sur Amazon EC2, vous êtes responsable du système d’exploitation, des correctifs, de la sécurité applicative.
Sur SageMaker Serverless Inference, AWS gère l’intégralité de l’infrastructure sous-jacente — votre responsabilité se limite à la configuration et aux données.

IAM : la base du contrôle d’accès

AWS Identity and Access Management (IAM) gère qui peut faire quoi sur vos ressources AWS. Quatre concepts s’articulent :

Concept	Rôle
Utilisateur racine (root)	Accès complet, créé avec le compte — à protéger (MFA obligatoire) et à n’utiliser que pour de rares opérations (facturation). Ne jamais l’utiliser au quotidien.
Utilisateur IAM	Identité individuelle, sans autorisation par défaut — les autorisations sont accordées explicitement.
Groupe IAM	Regroupe des utilisateurs pour leur appliquer une politique commune (ex. « développeurs », « QA », « administrateurs »). Un groupe ne peut pas appartenir à un autre groupe.
Rôle IAM	Identité empruntée temporairement (par un utilisateur, un service AWS, ou un fournisseur d’identité externe) — des identifiants temporaires qui expirent automatiquement. Préférable aux identifiants durables associés à un utilisateur, plus exposés en cas de fuite (par exemple oubliés dans du code partagé).

Le principe directeur : le moindre privilège — n’accorder que les autorisations strictement nécessaires. Une politique IAM est un document JSON qui autorise ou refuse des actions sur des ressources :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["ec2:StartInstances", "ec2:StopInstances"],
      "Resource": "*"
    }
  ]
}

Pour les organisations gérant de nombreux comptes AWS, AWS IAM Identity Center permet de fédérer l’authentification via un fournisseur externe (Active Directory…) et de gérer les autorisations de façon centralisée, avec des identifiants temporaires — la bonne pratique recommandée par AWS plutôt que la gestion manuelle d’utilisateurs IAM par compte.

Pour auditer les actions effectuées, AWS CloudTrail capture tous les appels d’API d’un compte (y compris ceux de SageMaker) : qui a fait quoi, quand, depuis quelle adresse IP.

Enfin, Amazon SageMaker Role Manager simplifie la création de rôles IAM adaptés au ML, via des « personas » préconfigurés (data scientist, opérateur ML, calcul SageMaker) avec des autorisations prédéfinies pour les activités courantes.

Chiffrement : au repos, en transit, et sous votre contrôle

Le chiffrement rend une donnée illisible sans les clés adéquates, même si un accès non autorisé aux données brutes survient.

Chiffrement par défaut : Amazon S3, DynamoDB et SageMaker chiffrent vos données automatiquement, sans configuration — mais avec des clés appartenant au service, pas à vous.
AWS Key Management Service (KMS) vous permet d’utiliser vos propres clés, avec un contrôle fin via des politiques IAM : même si quelqu’un obtient accidentellement un accès en lecture à un compartiment S3, il ne pourra pas déchiffrer les données sans autorisation sur la clé KMS associée.
TLS sécurise systématiquement les échanges avec les API AWS (S3, SageMaker) via HTTPS.
Chiffrement inter-nœuds : pour l’entraînement distribué SageMaker (plusieurs nœuds de calcul), le trafic entre nœuds n’est pas chiffré par défaut — une option existe pour l’activer, au prix d’un allongement du temps d’entraînement (notamment pour le Deep Learning).

Amazon Macie surveille en continu vos compartiments S3 pour repérer des données sensibles (PII) via le Machine Learning et la correspondance de motifs — utile pour s’assurer qu’aucune donnée personnelle ne se retrouve, par erreur, dans un jeu de données d’entraînement.

Isoler le réseau : VPC et accès public

Par défaut, les instances SageMaker Studio et les instances de notebook peuvent accéder directement à Internet — pratique pour télécharger des paquets, mais risqué (code malveillant, exfiltration de données). La bonne pratique consiste à lancer ces ressources dans votre propre VPC, en mode « VPC uniquement », et à utiliser des points de terminaison d’interface VPC (via AWS PrivateLink) pour que tout le trafic vers S3, CloudWatch ou l’API SageMaker reste sur un réseau privé.

Amazon S3 Block Public Access permet de bloquer, au niveau du compte entier, tout accès public à vos compartiments — présents et futurs — prenant le pas sur toute politique de bucket ou liste de contrôle d’accès existante.

Les vulnérabilités spécifiques aux systèmes d’IA

Au-delà des menaces classiques, les systèmes d’IA/ML exposent des surfaces d’attaque propres, qu’il faut connaître pour s’en prémunir :

Vulnérabilité	Principe	Exemple concret
Empoisonnement des données	Un attaquant accédant aux données d’entraînement y introduit des exemples malveillants pour biaiser les prédictions futures.	Étiqueter faussement des transactions frauduleuses comme « non frauduleuses » pour que le modèle les laisse passer.
Entrées contradictoires (adversarial inputs)	Modifications subtiles d’une entrée, invisibles à l’œil humain, qui trompent le modèle sans toucher aux données d’entraînement.	Altérer légèrement une photo pour qu’un système de reconnaissance faciale identifie la mauvaise personne.
Inversion de modèle	En observant de nombreuses paires entrée/sortie, un attaquant reconstitue des données d’entraînement ou un modèle équivalent.	Reconstituer l’image faciale d’un employé à partir des scores de confiance renvoyés par un modèle de reconnaissance.
Injection de prompt	Spécifique aux LLM — voir le chapitre sur l’ingénierie des prompts : des instructions malveillantes glissées dans l’entrée détournent le comportement attendu du modèle.	—

Les mesures d’atténuation combinent les principes déjà vus (moindre privilège, chiffrement, limitation de l’accès au modèle pour freiner la rétro-ingénierie) et des pratiques spécifiques au ML : entraîner avec des données contradictoires, réentraîner régulièrement pour corriger les dommages d’un empoisonnement, valider systématiquement les nouvelles données avant de les intégrer, et surveiller en continu les prédictions pour détecter tout écart par rapport au comportement historique.

Amazon SageMaker Model Monitor joue ici un rôle central : il compare en continu les données et le modèle en production à une référence, génère des statistiques envoyées à Amazon CloudWatch, et déclenche des alertes en cas d’écart significatif — qu’il s’agisse d’une dérive naturelle des données ou d’une attaque en cours.

Tracer et versionner : la clé de la reproductibilité

Pour répondre aux exigences réglementaires (et pour votre propre capacité à déboguer un incident), tous les artefacts d’un projet ML doivent être versionnés et traçables :

Artefact	Où et comment
Code (entraînement, inférence, notebooks)	Référentiels versionnés (GitHub, AWS CodeCommit)
Jeux de données	Amazon S3, partitionnés avec des préfixes uniques
Images de conteneurs	Amazon ECR, avec identifiant unique
Tâches d’entraînement	Suivi automatique par SageMaker (hyperparamètres, données, sortie)
Versions de modèles	SageMaker Model Registry
Documentation du cycle de vie	SageMaker Model Cards
Relations entre tous ces éléments	SageMaker ML Lineage Tracking (graphe automatique)
Vue d’ensemble centralisée	SageMaker Model Dashboard

Points clés à retenir

Le modèle de responsabilité partagée AWS s’applique aussi à l’IA : AWS sécurise l’infrastructure, vous sécurisez vos données, votre configuration et vos accès.
IAM repose sur le moindre privilège : utilisateurs individuels, groupes pour la gestion à grande échelle, rôles pour des accès temporaires plutôt que des identifiants durables.
Le chiffrement par défaut protège vos données, mais AWS KMS et vos propres clés offrent un contrôle plus fin ; le chiffrement inter-nœuds pour l’entraînement distribué n’est pas activé par défaut.
Les systèmes d’IA sont exposés à des vulnérabilités spécifiques (empoisonnement, entrées contradictoires, inversion de modèle, injection de prompt) qui exigent des mesures adaptées.
La traçabilité complète de tous les artefacts (code, données, conteneurs, modèles) est indispensable pour la conformité et la reproductibilité.

Glossaire

Terme	Définition
Moindre privilège	Principe consistant à n’accorder que les autorisations strictement nécessaires à une tâche.
Empoisonnement des données	Introduction de données malveillantes dans un jeu d’entraînement pour biaiser un modèle.
Entrée contradictoire	Modification subtile d’une entrée destinée à tromper un modèle sans toucher à son entraînement.
Inversion de modèle	Reconstitution de données d’entraînement ou d’un modèle équivalent à partir de ses sorties observées.
SageMaker Model Monitor	Service de surveillance continue de la qualité des données et des modèles en production.

Prochain chapitre

La sécurité technique ne suffit pas sans un cadre de gouvernance et de conformité réglementaire clair — c’est l’objet du dernier chapitre de ce parcours.

👉 Chapitre 2 : Gouvernance, conformité et réglementation des systèmes d’IA

Junior TSAFACK – 11/09/2026