Prends soin de tes clés d'accès AWS

Tout d'abord, il faut expliquer brièvement la différence entre "l'accès programmatique" et "l'accès à la console de gestion". L'accès programmatique est utilisé lorsqu'un utilisateur ou une machine a besoin d'accéder à l'interface de ligne de commande (CLI) AWS, aux SDK AWS ou à des appels directs HTTPS aux API pour des services AWS individuels. Des outils comme Ansible ou Terraform sont des exemples typiques de ce type d'accès.

Ensuite, il y a l'accès à la console de gestion. En général, une personne se connecte à la console de gestion via un navigateur web. L'utilisateur s'authentifie avec un nom d'utilisateur et un mot de passe (et, espérons-le, un deuxième facteur) pour avoir accès à l'IUG de gestion des ressources.

A partir de maintenant, cet article se concentrera uniquement sur l'accès programmatique. Les données d'accès pour l'accès programmatique sont appelées clés d'accès. Les clés d'accès se composent de deux éléments: une ID de clé d'accès et une clé d'accès secrète. Elles pourraient se présenter comme suit:

• Access Key ID: AKIAJ[……..]VVSUIS
• Secret Access Key: 9sDXP9aLws[……..]GxCPurPzCKo2stXPIB

Pour tester ce qui se passe exactement lorsque les données de connexion sont publiées, différentes mesures de sécurité ont été mises en place. Entre autres, un utilisateur sans aucune autorisation a été utilisé et l'authentification multifactorielle (MFA) a été activée pour tous les utilisateurs de ce compte. Le compte a également été surveillé de très près afin que les incidents suspects puissent être détectés immédiatement.

Nous avons testé les mesures de sécurité à plusieurs reprises pour nous assurer qu'elles fonctionnaient comme prévu. Nous devions être sûrs qu'aucune action ne pouvait être effectuée avec les clés d'accès publiées et que les entrées du journal étaient écrites comme prévu.

Enfin, nous avons publié les clés d'accès sur GitHub. Un simple playbook pour Ansible a été utilisé avec le contenu suivant:

La réaction à la publication des données de mandat a été absolument stupéfiante pour nous. En moins d'une minute, des partis étrangers ont essayé d'exploiter les données d'accès qui avaient fuité. Dans les 6 minutes où les données d'accès étaient valables, nous avons reçu des connexions de différents réseaux d'anonymisation et de Chine.

AWS a remarqué le problème tout aussi rapidement et nous a immédiatement informés. Juste après la fuite, un e-mail est arrivé dans notre boîte de réception pour nous informer du problème. On nous a dit que les clés d'accès étaient toujours valables. Pour protéger le compte, AWS a temporairement limité la possibilité de créer des ressources AWS.

Des acteurs malveillants surveillent activement le code publié sur GitHub (et d'autres dépôts de code source). Avec l'API que GitHub propose, c'est facile à faire. Si une clé est publiée par inadvertance, quelqu'un essaiera immédiatement d'en tirer profit. Il existe des outils automatisés qui tirent profit en quelques secondes des données d'accès qui ont fuité. AWS a réagi de manière exemplaire et a immédiatement pris des mesures de protection pour le compte compromis.

Avec ce test, nous voulions sensibiliser les gens. Access Keys(ouvre une nouvelle fenêtre) sont des composants critiques qui doivent être particulièrement protégés. Sur le site d'AWS, on trouve une description détaillée de la manière dont les clés d'accès sont gérées et comment les protéger en conséquence. Swisscom est également prête à répondre aux questions de sécurité spécifiques concernant l'IAM ou Amazon Web Services en général.

Tu veux en savoir plus sur le portefeuille et les services de Swisscom sur Amazon Web Services (AWS) ? Contacte nos experts. Coc.aws@swisscom.com ou visite swisscom.ch/aws