Gérer la 2FA d’un compte AWS partagé

Personne ne devrait se connecter à AWS avec un identifiant partagé. L’accès quotidien relève d’identités par personne via IAM Identity Center, et l’automatisation relève de rôles plutôt que de quoi que ce soit qu’un humain tape.

Reste l’utilisateur racine, qui est vraiment un identifiant unique par compte. Ce qu’il est utile de savoir, c’est que vous n’avez pas non plus à en partager le second facteur : AWS permet d’enregistrer plusieurs appareils MFA sur l’utilisateur racine, donc deux ou trois administrateurs peuvent chacun enrôler le leur. Copier un secret TOTP est une solution de repli pour les cas où ce n’est pas possible, pas le choix par défaut.

Trois identifiants différents

« Notre compte AWS » veut en général dire l’une de ces trois choses, et elles ont des réponses différentes.

L’utilisateur racine. Un par compte, identifié par une adresse e-mail, capable de tout faire, y compris fermer le compte et changer la facturation. Pas fait pour le travail quotidien.

Les identités par personne. Utilisateurs d’IAM Identity Center, ou utilisateurs IAM sur les configurations plus anciennes. C’est là que le travail se fait vraiment, et là que chacun a son propre second facteur.

Les clés d’accès. Des identifiants à longue durée de vie pour l’accès programmatique. Ce n’est pas une connexion, ce n’est pas protégé par la MFA comme les gens le supposent, et c’est ce qu’on retrouve le plus souvent dans un vieux dépôt.

La plupart des questions sur la « 2FA AWS partagée » portent en réalité sur le premier, et se posent parce que les deux autres n’ont jamais été mis en place.

Travail quotidien : des identités par personne

IAM Identity Center donne à chacun sa propre connexion, sa propre MFA, et des identifiants à durée limitée sur les comptes et les rôles auxquels il a droit. L’accès est accordé par affectation plutôt qu’en remettant quoi que ce soit, et retirer quelqu’un est une action à un seul endroit, quel que soit le nombre de comptes AWS que vous exploitez.

Si vous êtes encore sur des utilisateurs IAM, le minimum est un utilisateur par personne, chacun avec son appareil MFA, et aucun utilisateur partagé pour l’équipe. Un utilisateur IAM partagé a tous les problèmes d’un utilisateur racine partagé sans aucune de ses raisons d’être.

Pour une agence qui travaille dans le compte d’un client, l’équivalent de « invitez-moi » est un rôle inter-comptes : le client garde la propriété et peut le révoquer à un seul endroit, et personne n’envoie d’identifiants par e-mail.

Automatisation : des rôles, pas des connexions

Tout ce qui tourne sans surveillance devrait endosser un rôle plutôt que de se connecter. Sur AWS même, ça veut dire des profils d’instance, des rôles de tâche ou une fédération OIDC depuis votre fournisseur de CI. Ce sont des identifiants à durée limitée, sans secret à stocker et sans rien qu’un humain ait à taper.

Si un script demande un code à six chiffres à quelqu’un, c’est qu’il utilise l’identité d’un humain, et il cassera le jour où cet humain s’en ira.

Les clés d’accès à longue durée de vie sont l’autre moitié du sujet. Elles sont révocables et renouvelables individuellement, ce qui est un vrai avantage sur un secret TOTP, mais ce sont aussi les identifiants qui fuitent dans les commits. Gardez-en peu et faites-les tourner selon un calendrier que vous respectez vraiment.

L’utilisateur racine : le vrai compte partagé

La racine existe, plusieurs personnes doivent pouvoir l’atteindre, et elle ne doit pas dépendre du téléphone d’une seule personne.

Enregistrez plus d’un appareil MFA

C’est la réponse propre à AWS, et elle supprime entièrement la question du partage. Enrôlez l’application ou la clé matérielle de chaque administrateur qui doit pouvoir agir en tant que racine. Chaque appareil détient son propre secret, et aucun secret n’est jamais copié. Un départ, c’est le désenregistrement d’un appareil, pas la réinitialisation de la 2FA du compte et le réenrôlement de tout le monde.

Là où une clé matérielle est envisageable, c’est ici qu’elle vaut son prix : le second facteur ne peut être ni capturé en image, ni transféré, ni synchronisé.

Pointez l’e-mail racine vers une boîte que deux personnes peuvent lire

La récupération de la racine passe par cette adresse. La boîte personnelle d’un fondateur rend le compte irrécupérable le jour où il n’est plus là : utilisez une liste de diffusion ou une boîte partagée, et assurez-vous que ceux qui peuvent la lire sont des gens à qui vous confieriez la récupération du compte, parce que fonctionnellement c’est ce que cette adresse accorde.

Supprimez les clés d’accès racine

Il ne devrait y en avoir aucune. S’il en existe, ce sont des identifiants partagés sans aucune MFA devant eux, ce qui est pire que tout le reste de cet article.

Surveillez les connexions racine

CloudTrail les enregistre, et une alarme sur l’usage de la racine est une pratique courante. Sur un compte sain, les connexions racine sont rares et explicables, ce qui les rend peu coûteuses à surveiller et précieuses à voir.

Quand un secret TOTP partagé reste la réponse

Les appareils MFA multiples couvrent la plupart des cas. Quelques-uns résistent :

• Le compte d’un client que vous n’administrez pas, où l’on vous remet des identifiants sans que vous puissiez rien restructurer.
• Des consoles anciennes ou tierces autour d’AWS (un portail de facturation, un panneau de revendeur, un prestataire de supervision) qui n’acceptent exactement qu’un enrôlement TOTP.
• Un identifiant de bris de glace que votre procédure exige que plusieurs personnes puissent utiliser rapidement, là où des appareils individuels ne sont pas praticables.

Pour ceux-là, les exigences sont celles de n’importe quel compte partagé : une garde unique du secret, un accès aux codes accordé par personne, un journal de qui a lu un code, et des codes de récupération rangés hors du compte qu’ils récupèrent. Le raisonnement est dans comment partager des codes 2FA en équipe en toute sécurité, et la comparaison des mécanismes dans les meilleures façons de gérer la 2FA d’un compte partagé. Le même raisonnement appliqué à un prestataire de paiement est dans gérer la 2FA d’un compte Stripe partagé.

Une procédure de bris de glace qui mérite d’être écrite

Pour la racine, et pour tout ce qui ne sert qu’en cas d’urgence :

1. Qui peut s’en servir, nommément, et ce qui le déclenche.
2. Où vivent l’identifiant et son second facteur, et combien de personnes peuvent atteindre chacun.
3. Où sont les codes de récupération, hors du compte qu’ils récupèrent.
4. Ce qui déclenche une alerte lors de l’usage, c’est-à-dire l’alarme CloudTrail ci-dessus.
5. Ce qui se passe ensuite : qui est prévenu, ce qui est revu, ce qui est éventuellement renouvelé.
6. Quand elle a été testée pour la dernière fois. Une procédure jamais répétée sera découverte le soir où quelqu’un en a besoin.

Le départ de quelqu’un sur un compte AWS

1. Retirez ses affectations Identity Center ou supprimez son utilisateur IAM.
2. Désactivez et supprimez ses clés d’accès, y compris celles utilisées par ses outils.
3. Désenregistrez son appareil MFA racine, s’il en avait un.
4. S’il a détenu un jour un secret TOTP partagé, réinitialisez cette 2FA et changez le mot de passe associé. Le secret ne quitte pas son téléphone tout seul.
5. Vérifiez s’il peut encore lire l’adresse e-mail racine.
6. Relisez CloudTrail autour de son départ, à la recherche de l’inattendu.

L’étape 5 est celle qu’on oublie. Accéder à la boîte racine, c’est accéder au compte racine, quoi que vous ayez révoqué par ailleurs.

Où Share Auth se place

De façon étroite, et délibérément. Pour les comptes de la section ci-dessus, c’est-à-dire la console d’un client, un panneau tiers qui n’accepte qu’un enrôlement ou un identifiant de bris de glace : le secret est saisi une fois et chiffré au repos, les personnes qui ont besoin des codes voient le code et son décompte plutôt que le secret, les permissions sont par membre, et chaque consultation est journalisée.

Pour un utilisateur racine AWS que vous administrez, enregistrer un second appareil MFA vaut mieux que tout ce qu’un coffre peut faire, le nôtre compris. Faites ça d’abord.