Votre application sur EC2 s'authentifie auprès d'AWS à l'aide d'une clé d'accès à longue durée de vie intégrée à l'AMI. Quel est le meilleur modèle ?

Cette question distingue les candidats qui gèrent les secrets de ceux qui les éliminent. Une clé à longue durée de vie intégrée à une AMI est un anti-modèle classique, et la bonne réponse supprime le secret au lieu de le surveiller.

Pourquoi les rôles d'instance sont le meilleur modèle

Lorsque vous attachez un rôle IAM via un profil d'instance, l'instance EC2 récupère des identifiants temporaires depuis le service de métadonnées d'instance. AWS les renouvelle automatiquement, plusieurs fois par jour, et ils expirent d'eux-mêmes. Il n'y a aucune clé à intégrer à l'image, aucune clé à voir fuiter dans un instantané, aucune clé à faire tourner à la main. Si l'instance est mise hors service, les identifiants cessent simplement d'être émis. Cela réduit à la fois la probabilité d'exposition et la durée de toute exposition qui surviendrait.

Pourquoi les distracteurs sont plus faibles

• Rotation manuelle tous les 90 jours. La rotation réduit la fenêtre, mais entre deux rotations vous avez toujours un secret à longue durée de vie intégré. Quiconque copie l'AMI, un instantané ou le disque en cours d'exécution obtient une clé valide pendant des mois. Cela dépend en plus du fait qu'un humain pense à le faire.
• La stocker dans une variable d'environnement. Cela change l'endroit où vit la clé statique, pas le fait qu'elle soit statique, intégrée et susceptible de fuiter. Les variables d'environnement sont même plus faciles à exfiltrer (listes de processus, journaux de plantage, processus enfants).
• L'envoyer par e-mail à l'ops. Le secret vit désormais dans des boîtes de réception, des dossiers d'envoi et des archives mail chez plusieurs personnes. Cela multiplie la surface d'exposition et figure parmi les pires choses à faire avec un identifiant.

Ce que recherchent les examinateurs

L'instinct de supprimer l'identifiant à longue durée de vie au lieu de le protéger, plus la compréhension du mécanisme : profil d'instance vers rôle, identifiants temporaires depuis les métadonnées, rotation automatique. Point bonus pour un plan de migration réaliste — attacher le rôle, basculer le SDK sur la résolution d'identifiants par défaut, confirmer que cela fonctionne, puis révoquer et supprimer l'ancienne clé.