Faire le ménage dans les AWS Access Keys pour répondre à l’ISMS : retour sur une migration vers une authentification basée sur les rôles

Cet article revient sur une expérience de migration vers une authentification basée sur les rôles, entamée lors d’un audit des Access Keys accumulées dans un compte AWS dans le cadre du suivi post-audit ISMS.

Contexte de mise en place

• En regardant la console IAM, les Access Keys étaient dispersées à plusieurs endroits (CI/CD, scripts de déploiement, développement local, etc.), et il était difficile de savoir où et comment elles étaient utilisées
• Les Access Keys restent valides sans expiration, et en cas de compromission, les autorisations accordées sont exposées telles quelles, ce qui augmentait fortement le risque
• AWS recommande également d’utiliser des identifiants temporaires (rôles/STS) plutôt que des identifiants de longue durée (Access Key)

Problème

• Comme les clés étaient copiées et utilisées un peu partout, il était difficile de répondre à la question : « si cette clé est compromise, jusqu’où va l’impact ? »
• Pour faire une rotation, il fallait modifier en même temps des configurations éparpillées, et comme plusieurs usages étaient regroupés sur un même IAM User, il était difficile d’appliquer le principe du moindre privilège
• À l’époque, un seul IAM User dédié au CI/CD cumulait à la fois les autorisations de déploiement ECR/S3/SSM/ECS, entre autres

Méthode de migration retenue (résumé)

• Assume Role : méthode consistant à emprunter temporairement les autorisations d’un autre Role uniquement au moment où elles sont nécessaires
• OIDC Web Identity : méthode consistant à obtenir un Role à partir de l’identité d’un système externe, comme GitHub Actions ou EKS (=IRSA)
• Instance Profile : méthode consistant à attacher directement un Role à EC2/Lambda pour lui attribuer automatiquement les autorisations

Déroulement concret de la migration

• Étape 1 : séparation des autorisations de l’IAM User doté de politiques larges en plusieurs Role selon l’usage (push/pull ECR, déploiement ECS, cache S3, etc.)
• Étape 2 : mise en place d’OIDC sur GitHub Actions (enregistrement de l’Identity Provider → restriction du périmètre du repo via les conditions de la Trust Policy → utilisation de configure-aws-credentials dans le workflow)

Effets obtenus

• Suppression des Access Keys du code et des secrets ; comme le système repose sur des jetons temporaires, même en cas de compromission, l’impact reste limité par l’expiration
• Disparition de la charge liée à la rotation des clés, et meilleure traçabilité des autorisations par workflow ou par tâche

Points d’attention

• Ne pas définir des conditions trop larges dans la Trust Policy ; limiter le périmètre au strict minimum (org/repo, et si possible jusqu’à la branche)
• Ne pas supprimer immédiatement les Access Keys existantes ; après la migration, prévoir une période de désactivation et de vérification avant la suppression