Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

IMDSv2

cloud

Définition

IMDSv2 (Instance Metadata Service v2) est la version sécurisée du service de métadonnées d'instance AWS, introduit en 2019 pour remédier aux vulnérabilités SSRF permettant à des attaquants d'accéder aux credentials IAM des instances EC2. IMDSv2 utilise un schéma d'authentification par token de session (session-oriented) qui rend les attaques SSRF classiques inefficaces. L'endpoint de métadonnées d'instance (http://169.254.169.254) est accessible uniquement depuis l'instance EC2 elle-même et fournit des informations critiques : identité de l'instance, région, credentials IAM temporaires du rôle associé (Instance Profile), données utilisateur (user data), clés SSH, et bien d'autres métadonnées. Ces informations sont essentielles pour de nombreuses applications cloud-native, mais aussi pour les attaquants. Avec IMDSv1, n'importe quelle requête HTTP GET vers l'endpoint de métadonnées retourne immédiatement les informations demandées, y compris les credentials IAM. Une vulnérabilité SSRF dans une application web permettait donc à un attaquant de voler ces credentials en faisant effectuer la requête par le serveur vulnérable. IMDSv2 résout ce problème en requérant : 1. Une requête PUT vers l'endpoint pour obtenir un token de session (TTL 1s à 21600s) 2. Ce token dans chaque requête GET suivante (header X-aws-ec2-metadata-token) Les attaques SSRF classiques utilisent généralement des requêtes GET ; la requête PUT bidirectionnelle initiale n'est pas possible dans la majorité des scénarios SSRF, bloquant ainsi le vol de credentials. La migration vers IMDSv2 nécessite la mise à jour des applications utilisant l'ancien endpoint IMDS. Les AWS SDKs récents supportent IMDSv2 automatiquement. La désactivation forcée d'IMDSv1 peut être réalisée instance par instance, via le compte AWS (ModifyInstanceMetadataDefaults), ou via des SCP/AWS Config Rules pour imposer IMDSv2 à l'échelle de l'organisation.

Fonctionnement technique d'IMDSv2

Pour accéder aux métadonnées avec IMDSv2 : 1) PUT vers http://169.254.169.254/latest/api/token avec header X-aws-ec2-metadata-token-ttl-seconds : 21600 → reçoit un token ; 2) GET vers http://169.254.169.254/latest/meta-data/... avec header X-aws-ec2-metadata-token : . Le token expire après le TTL défini. Les applications utilisant aws-sdk récent (boto3 >= 1.16, AWS SDK Java >= 1.12, etc.) supportent IMDSv2 automatiquement via credential provider chain.

Déploiement IMDSv2 à l'échelle

Utilisez AWS Config Rule ec2-imdsv2-check pour détecter les instances n'imposant pas IMDSv2. Forcez IMDSv2 via modify-instance-metadata-options en masse avec AWS Systems Manager Run Command sur toutes les instances actives. Pour les nouveaux déploiements, ajoutez MetadataOptions.HttpTokens: required dans vos templates CloudFormation/Terraform. Les SCP peuvent interdire le lancement d'instances sans IMDSv2 requis.

Cas d'usage légitimes de l'IMDS

L'IMDS fournit également : les données utilisateur (user data) pour le bootstrapping, l'identité de l'instance (instance ID, région), les événements de maintenance planifiés (spot instance interruption), les métadonnées de réseau (IP, MAC). Assurez-vous que vos scripts de bootstrapping sont compatibles IMDSv2 avant de désactiver IMDSv1.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis