Comment gérer en toute sécurité les clés privées des paires de clés gérées par EC2?

Pour lancer une instance EC2, vous avez besoin d'une paire de clés. Comment gérez-vous la situation où un ingénieur ayant accès à la clé privée pour cette paire de clés quitte l'entreprise? Cela fonctionnerait-il pour ajouter un accès ssh individuel et annuler l'autorisation de la paire de clés initiale, immédiatement après le lancement de l'instance?

Lorsqu'un employé ou un entrepreneur quitte l'entreprise, vous devez désactiver tout accès privilégié dont il disposait aux ressources de l'entreprise. Cela inclut (mais n'est pas limité à) vos principales préoccupations ssh:

1. Supprimez la clé publique ssh de tous les fichiers authorized_keys sur toutes les instances en cours d'exécution. Remplacez-les par une clé ssh publique nouvellement générée qui n'est connue que des personnes qui devraient y avoir accès.

2. Supprimez toutes les entrées de paires de clés dans EC2 qui étaient connues par les disparus afin que de nouvelles instances ne puissent pas être démarrées avec ces paires de clés. Remplacez-les par de nouvelles entrées de paire de clés, peut-être avec les mêmes noms si votre

La méthode alternative que vous proposez est également bonne et j'utilise celle-ci: désactivez la clé ssh initiale et ajoutez des clés ssh publiques individuelles pour chaque développeur afin qu'il puisse se connecter avec sa clé ssh privée normale. Cela peut être fait pour se connecter à un compte partagé ou avec chaque développeur obtenant son propre compte utilisateur individuel (mon préféré).

Après le départ d'un employé, vous devrez non seulement nettoyer les serveurs en cours d'exécution, mais également le processus qui ajoute les clés ssh aux nouveaux serveurs. Et, lorsqu'un employé se joint à vous, vous devrez faire l'inverse: ajouter des clés ssh aux serveurs en cours d'exécution et mettre à jour le nouveau processus de serveur.

Cela peut être un peu plus de travail pour maintenir de nombreuses clés ssh sur de nombreux serveurs, mais c'est là que l'automatisation entre en jeu.

Vous ne devez jamais donner cette clé privée aux utilisateurs finaux. Les utilisateurs finaux doivent disposer de leurs propres moyens de connexion, tels que l'authentification par clé publique (à l'aide de leur propre clé privée protégée par mot de passe), suivis d'une autorisation LDAP.

La distribution de la clé privée qui vous est donnée par ec2 rend impossible le déclassement des utilisateurs. C'est exactement pourquoi l'utilisation des informations d'identification partagées est complètement interdite par toutes les réglementations de sécurité et de conformité.

Lorsque vous autorisez l'utilisation d'informations d'identification partagées:

• Il est impossible d'utiliser des journaux pour savoir qui est / était réellement sur un hôte
• Il est impossible de déprovisionner un utilisateur sans déprovisionner tous les utilisateurs (y compris l'accès d'urgence, à quoi sert vraiment cette clé privée EC2)

Consultez la documentation d'Amazon sur la rotation des informations d'identification d'accès .

Utilisez quelque chose comme un marionnette ou un script ssh solide pour courir et remplacer toutes les instances de l'ancienne clé si vous ne voulez pas tout relancer ... ou tout simplement relancer tout.