Une clé d’accès AWS se compose de deux chaînes qui, ensemble, permettent à un programme d’agir en tant qu’utilisateur IAM : l’ID de clé d’accès, qui identifie la clé, et la clé d’accès secrète, qui prouve sa possession. En anglais, on les cherche sous trois noms (access key and secret key, secret access key, ou simplement AWS secret key), mais il s’agit toujours de la même paire. On la retrouve dans les configurations de la CLI, dans les pipelines de CI et, bien trop souvent, dans un message Slack.
Ce guide explique ce que sont les deux moitiés, comment les créer et les configurer, comment faire une rotation sans interruption de service, que faire en cas de fuite, et répond à la question qui revient à chaque arrivée d’un développeur ou d’un prestataire : comment transmettre une clé secrète à une personne sans la mettre dans un e-mail.
ID de clé d’accès et clé d’accès secrète
| ID de clé d’accès | Clé d’accès secrète | |
|---|---|---|
| Format | AKIAIOSFODNN7EXAMPLE (20 caractères) | 40 caractères, majuscules, minuscules et symboles |
| Rôle | Indique quelle clé signe la requête | Signe la requête et prouve la possession |
| Secrète ? | Non, à traiter comme un nom d’utilisateur | Oui, à traiter comme un mot de passe |
| Visible plus tard ? | Oui, dans la console IAM | Jamais après la création |
Les clés à long terme commencent par AKIA. Les identifiants
temporaires délivrés par STS, qui s’accompagnent aussi d’un jeton de
session, commencent par ASIA et expirent d’eux-mêmes. Une clé ASIA
dans un fichier de configuration cessera de fonctionner en quelques
heures : c’est voulu.
Aucune des deux moitiés n’accorde de droits. La clé authentifie un utilisateur IAM, et ce sont les stratégies attachées à cet utilisateur qui décident de ce que cette identité peut faire. Une clé divulguée sur un utilisateur en lecture seule est un problème. Une clé divulguée sur un administrateur est un incident.
Avez-vous vraiment besoin d’une clé à long terme ?
Honnêtement, moins souvent qu’on ne le croit.
- Les charges de travail sur AWS (EC2, Lambda, ECS, EKS) doivent utiliser des rôles IAM. Le SDK récupère automatiquement des identifiants de courte durée, et il n’y a rien à renouveler ni à laisser fuiter.
- Les personnes doivent se connecter via IAM Identity Center ou un
SSO fédéré et obtenir des identifiants temporaires avec
aws sso login. - Les systèmes de CI comme GitHub Actions peuvent assumer un rôle via OIDC, sans clé stockée.
- Les clés à long terme restent pour les cas qui ne peuvent rien faire de tout cela : un outil sur un ordinateur portable sans prise en charge du SSO, un service tiers qui n’accepte que des clés statiques, une tâche ancienne que vous n’avez pas encore migrée.
Si vous en avez besoin, créez-la sur un utilisateur IAM dédié, avec la stratégie la plus restreinte qui permet de faire le travail, et jamais sur le compte administrateur d’une personne.
Créer et configurer une clé
Dans la console IAM, ouvrez l’utilisateur, choisissez « Security credentials », puis « Create access key ». Choisissez le cas d’usage demandé par AWS, lisez l’alternative qu’il propose, puis continuez. Le secret ne s’affiche qu’une seule fois. Enregistrez-le directement dans votre gestionnaire de secrets ou votre gestionnaire de mots de passe, ou téléchargez le CSV et supprimez-le après l’importation. Chaque utilisateur IAM peut avoir au plus deux clés à la fois, et c’est ce qui rend la rotation possible.
Sur une machine, configurez un profil nommé plutôt que le profil par défaut :
aws configure --profile deploy-tool
# AWS Access Key ID [None]: AKIA...
# AWS Secret Access Key [None]: ...
# Default region name [None]: eu-west-1
Cette commande écrit ~/.aws/credentials et ~/.aws/config. Limitez
l’accès au fichier à votre utilisateur avec chmod 600. Pour les
conteneurs et la CI, injectez AWS_ACCESS_KEY_ID et
AWS_SECRET_ACCESS_KEY en tant que secrets depuis le coffre de la
plateforme, pas en variables en clair dans un fichier YAML, et ne les
passez jamais en ligne de commande, où elles finissent dans
l’historique du shell.
Faire une rotation sans rien casser
La rotation se fait en quatre étapes, grâce à la limite de deux clés.
- Créez la deuxième clé sur le même utilisateur.
- Basculez tout ce qui l’utilise sur la nouvelle clé : configurations, secrets de CI, entrée du gestionnaire de secrets. La console IAM affiche la date de dernière utilisation de chaque clé, ce qui vous indique si vous avez oublié quelque chose.
- Désactivez l’ancienne clé. Attendez un jour ou un cycle de déploiement. Si quelque chose casse, réactivez-la, corrigez le service concerné et recommencez.
- Supprimez l’ancienne clé une fois que plus rien ne l’utilise.
Faites-le selon un calendrier pour les clés qui doivent exister, et à chaque événement pour toutes : un départ, un changement de fournisseur, un ordinateur perdu, un soupçon de fuite. AWS Config et IAM Access Analyzer peuvent signaler les clés plus anciennes que ce que votre politique autorise.
Quand une clé a été exposée
Considérez comme compromise toute clé apparue dans un dépôt, un journal, un ticket ou une messagerie, même si elle a été supprimée une minute plus tard. Les scanners trouvent les secrets poussés en quelques secondes.
- Désactivez la clé dans IAM, tout de suite. N’attendez pas d’avoir créé la clé de remplacement, sauf si l’interruption de service serait pire que l’exposition.
- Créez une clé de remplacement et mettez à jour ce qui l’utilisait.
- Lisez CloudTrail pour chaque action effectuée avec cet ID de clé d’accès depuis l’exposition. Cherchez de nouveaux utilisateurs ou clés IAM, de nouvelles instances, des stratégies de bucket modifiées et des régions inhabituelles.
- Vérifiez la facture et Cost Explorer pour repérer des pics qui ressemblent à du minage de cryptomonnaie.
- Retirez le secret du code, des journaux et de l’historique git.
AWS peut attacher lui-même la stratégie
AWSCompromisedKeyQuarantineà l’utilisateur quand il détecte une fuite publique ; laissez-la en place jusqu’à la fin du nettoyage. - Supprimez l’ancienne clé, puis trouvez comment elle s’est retrouvée là et fermez cette voie.
Comment transmettre une clé secrète AWS à une personne
Parfois, la clé doit parvenir à un humain : un prestataire qui en a besoin pour un outil de déploiement, un développeur qui rejoint un projet avant la mise en place du SSO, l’intégration d’un fournisseur qui demande de la coller dans son tableau de bord. L’e-mail, Slack et les tickets gardent tous des copies, et un secret de 40 caractères y reste lisible pendant des années.
La méthode sûre prend une minute :
- Créez une clé pour cette personne sur un utilisateur IAM dédié, avec la stratégie dont sa tâche a besoin et rien de plus. Ne partagez pas une clé que quelque chose d’autre utilise.
- Collez uniquement la clé d’accès secrète dans un lien secret à usage unique. Elle est chiffrée dans votre navigateur avant d’être stockée, la copie stockée est détruite dès la première ouverture du lien, et le lien expire au bout d’une heure, d’un jour ou d’une semaine si personne ne l’ouvre.
- Envoyez le lien avec une ligne de contexte. Envoyez l’ID de clé d’accès, la région et le nom du profil dans un message séparé ; aucun de ces éléments n’est secret à lui seul.
- Ajoutez une phrase de passe avec un compte Pro pour tout ce qui dépasse la lecture seule, et transmettez-la par SMS ou lors d’un appel.
- Vérifiez que la personne l’a ouvert. Si le lien indique qu’il a déjà été consulté alors qu’elle ne l’a pas ouvert, désactivez la clé et recommencez.
- Désactivez la clé à la fin de la mission, puis supprimez-la.
Le guide sur les clés API applique la même méthode aux autres fournisseurs, et le guide partage de liens sécurisé pour les développeurs explique comment automatiser la transmission lors de l’intégration des nouveaux arrivants.