Profils d'instance pour les charges de travail EC2

Les applications sur EC2 doivent souvent appeler des API AWS, mais intégrer des clés d’accès est dangereux. La solution consiste à donner à l’instance sa propre identité au moyen d’un profil d’instance, qui fournit automatiquement des identifiants de rôle temporaires. Il s’agit de l’un des modèles les plus fréquemment testés pour éliminer les secrets à longue durée de vie des charges de travail.

Un profil d’instance est un conteneur pour un rôle IAM que vous associez à une instance EC2. Bien que vous attribuiez conceptuellement un rôle, EC2 associe en réalité le profil d’instance qui contient ce rôle. Lorsque vous créez un rôle pour EC2 dans la console, un profil d’instance du même nom est créé automatiquement ; avec la CLI ou l’API, vous devrez peut-être le créer explicitement.

Une fois le profil d’instance associé, l’instance peut récupérer des identifiants temporaires auprès de l’Instance Metadata Service (IMDS), un point de terminaison local à l’instance accessible à l’adresse 169.254.169.254. Le SDK AWS et la CLI récupèrent et renouvellent ces identifiants de manière transparente, de sorte que le code de l’application ne manipule jamais les clés.

Les identifiants sont stockés sous un chemin de métadonnées associé au nom du rôle. Les SDK l'interrogent automatiquement, mais comprendre ce chemin vous aide à diagnostiquer pourquoi une instance possède des permissions inattendues. La commande ci-dessous indique où les identifiants sont exposés sur l'instance.

L'un des principaux avantages est que les identifiants IMDS sont automatiquement renouvelés bien avant leur expiration. Il n'y a rien à stocker, aucune clé risquant d'être divulguée de manière permanente et aucun processus de rotation à créer. C'est pourquoi AWS recommande les profils d'instance plutôt que tout mécanisme plaçant des clés statiques sur un serveur.

Le service de métadonnées d'origine (IMDSv1) pouvait être détourné par des attaques de SSRF (falsification de requêtes côté serveur) afin de voler les identifiants du rôle. IMDSv2 exige d'abord un jeton de session obtenu au moyen d'une requête PUT, ce qui bloque la plupart des attaques SSRF. Pour l'examen, vous devez imposer IMDSv2 et, idéalement, définir la limite de sauts sur 1 afin d'empêcher les conteneurs de l'atteindre.

Le rôle du profil d'instance doit respecter le principe du privilège minimal : accordez uniquement les actions et ressources précises dont la charge de travail a besoin. Un rôle EC2 trop permissif est dangereux, car toute compromission de l'instance, notamment par SSRF, expose ces permissions. Restreignez soigneusement la portée des politiques et utilisez des conditions pour limiter l'ampleur des dommages.

Si vous trouvez des clés d'accès statiques inscrites en dur dans une application ou un fichier d'identifiants sur une instance, la mesure corrective consiste à associer un profil d'instance et à supprimer les clés. L'examen présente souvent cela comme la correction d'une constatation : la bonne réponse supprime le secret à long terme et s'appuie sur les identifiants fondés sur le rôle fournis par IMDS.

Une instance EC2 ne peut avoir qu'un seul profil d'instance associé à la fois, et donc un seul rôle. Si une charge de travail nécessite différents ensembles de permissions, concevez des rôles distincts et utilisez soit des instances distinctes, soit une application qui assume des rôles supplémentaires via STS selon les besoins, plutôt que d'élargir excessivement le rôle unique associé.

Comme les identifiants du rôle apparaissent dans CloudTrail sous la forme d'actions effectuées par une session de rôle assumé, vous pouvez auditer exactement ce qu'une instance a fait. Si une instance est compromise, prendre un instantané et consulter CloudTrail pour la session de ce rôle permet de savoir à quelles ressources l'attaquant a accédé. Une portée de rôle restrictive associée à la visibilité de CloudTrail constitue la combinaison sécurisée privilégiée à l'examen.

Pour sécuriser l'accès à EC2 : associez un profil d'instance contenant un rôle à privilège minimal, imposez IMDSv2, définissez la limite de sauts des métadonnées sur 1 et supprimez toutes les clés statiques. L'instance récupère des identifiants temporaires depuis IMDS et les renouvelle automatiquement, offrant ainsi une identité sécurisée aux ressources de calcul sans secret que vous deviez gérer.

Vérifiez vos connaissances sur les profils d'instance.

Un profil d'instance contient un rôle IAM et l'associe à EC2, en fournissant des identifiants temporaires renouvelés automatiquement via le service de métadonnées d'instance. Cela supprime entièrement les clés statiques. Imposez IMDSv2 et une limite de sauts de 1 pour bloquer le vol d'identifiants par SSRF, appliquez le privilège minimal au rôle et auditez ses sessions dans CloudTrail.