Le Blog Amazon Web Services

Comment utiliser AWS Secrets Manager pour stocker et faire la rotation des paires de clés SSH

AWS Secrets Manager assure une gestion complète du cycle de vie des secrets au sein de votre environnement. Dans cet article, nous allons vous montrer comment utiliser Secrets Manager pour stocker, fournir et faire la rotation des paires de clés SSH utilisées pour la communication au sein de cluster de calcul. La rotation de ces clés étant une bonne pratique en matière de sécurité, et parfois une exigence liée à la réglementation. Traditionnellement, ces paires de clés ont été associées à des véritables enjeux techniques et organisationnels, par exemple : synchroniser la rotation des clés au sein d’un cluster, activer la journalisation et l’audit détaillés, ou encore gérer les accès des utilisateurs afin de permettre la modification des secrets.

La rotation des paires de clés au sein des nœuds de clusters doit être effectuée de manière strictement coordonnée, afin de pallier aux risques de disponibilité. De plus, les paires de clés représentent elles-mêmes des informations hautement sensibles, qui doivent être soigneusement gérées à l’aide d’un contrôle fin des droits d’accès, d’une surveillance détaillée, et d’un journal d’audit. Ce sont précisément les types de défis qu’AWS Secrets Manger se propose de gérer pour vous.

Dans cet article, nous allons vous montrer comment sécuriser, faire la rotation et utiliser des paires de clés SSH pour la communication inter-cluster. Dans les étapes décrites, vous utiliserez un template AWS CloudFormation pour démarrer un cluster, et configurer Secrets Manager. Puis, nous vous montrerons comment utiliser Secrets Manager pour fournir une paire de clés au cluster, et l’utiliser pour des opérations de gestion, telles que la copie sécurisée d’un fichier entre les nœuds du cluster. Enfin, nous utiliserons Secrets Manager pour faire la rotation en toute transparence la paire de clés utilisée par le cluster sans aucune interruption. Dans cet article, nous utilisons des clusters de calcul, mais vous pouvez utiliser Secrets Manager pour appliquer cette méthode directement à n’importe quel cas d’utilisation basé sur SSH.

Présentation de la Solution

Le diagramme d’architecture suivant présente une vue d’ensemble de la solution :

 

Figure 1 : Architecture de la solution.

L’exemple d’architecture créée par AWS CloudFormation comprend un nœud principal, trois nœuds de type « nœud de travail », AWS Secrets Manager (qui utilise une fonction de rotation AWS Lambda) et AWS Systems Manager. La mise en place du cluster ne sera pas traitée dans cet article; dans la procédure décrite, nous nous allons nous concentrer plutôt sur l’architecture de rotation des paires de clés.

Secrets Manager utilise des étiquettes intermédiaires pour identifier les différentes versions d’un secret lors de la rotation. Une étiquette intermédiaire est une chaîne de caractères. Par exemple, par défaut, AWSCURRENT est liée à la version actuelle du secret, tandis que AWSPENDING sera liée aux nouvelles versions du secret avant qu’elles n’aient été vérifiées et déployées vers les ressources correspondantes.

Comme le montre le diagramme :

  1. Un secret est créé dans AWS Secrets Manager. Le secret contient la clé SSH que le nœud principal utilisera pour se connecter aux autres nœuds du cluster. Lors de la rotation des paires de clés, Secrets Manager invoquera une fonction Lambda (cf. 1.a dans le diagramme). La fonction Lambda effectuera quatre étapes :
  • b : createSecret— Afin de créer une nouvelle paire de clés SSH et de stocker la clé privée comme une nouvelle version du secret.
  • c : setSecret— Afin d’étiqueter la nouvelle version du secret avec l’étiquette AWSPENDING puis de copier la clé publique sur les nœuds de travail avec AWS Systems Manager Fonctionnalité Exécuter la commande.

La fonction Lambda effectuera également deux étapes non indiquées dans le diagramme :

  • testSecret: Afin de vérifier que la nouvelle clé SSH aie été déployé avec succès en appelant une connexion SSH de test.
  • finishSecret: Afin de définir l’étiquette temporaire AWSCURRENT sur la nouvelle version du secret et de supprimer les anciennes clés des nœuds de travail. Cela définira également l’étiquette temporaire AWSPREVIOUS sur l’ancien secret, permettant à votre administrateur d’avoir le « dernier mot de passe connu » si quelque chose ne se passe pas comme prévu.

Une vue d’ensemble de la fonction de rotation Lambda est disponible dans le guide de l’utilisateur AWS Secrets Manager. Vous avez un contrôle total sur cette fonction de rotation afin que vous puissiez la personnaliser en fonction de vos besoins. Notez qu’aucune clé n’est installée sur le nœud principal. Au lieu de cela, la fonction récupère la clé privée de Secrets Manager uniquement lorsqu’elle a besoin de communiquer avec les nœuds. Cette clé privée n’est pas enregistrée sur le système de fichiers du nœud principal, mais plutôt dans la mémoire vive (selon les bonnes pratiques, la variable clé privée est remplacée après une authentification réussie, puis supprimée avant la fin du script) ; les détails sur la conservation des données dans la mémoire vive suivront plus loin dans cet article.

  1. Lorsque le nœud principal doit communiquer avec n’importe quel nœud de travail, il utilisera un SDK AWS (Python Boto3) pour lire la clé privée SSH à partir de Secrets Manager (2.a) et utilisera la clé privée pour établir un tunnel SSH avec les autres nœuds de travail (2.b). Le nœud principal est autorisé à lire la clé privée à partir de Secrets Manager car un rôle AWS Identity and Access Management (IAM) avec une stratégie lui permettant d’accéder au secret lui a été attaché. La clé publique correspondante a été déployée sur chacun des nœuds de travail pendant le processus de rotation de l’étape 1 ci-dessus.
  2. Les secrets détenus dans Secrets Managers sont chiffrés avec AWS Key Management System (KMS), et chaque version du secret est chiffrée avec une clé de chiffrement de donnée unique. La paire de clé SSH du cluster va périodiquement changer, selon un intervalle de temps, lequel sera configuré depuis la console Secrets Manager comme indiqué plus tard dans cet article. Chaque rotation suit les étapes décrites en paragraphe 1-2, afin d’obtenir une nouvelle version du secret. Chaque nouvelle version sera chiffrée à l’aide d’une nouvelle clé de donnée fournie par KMS, afin de fournir une couche additionnelle de sécurité.
  3. La fonctionnalité « Exécuter la commande » d’AWS Systems Manager utilisera l’étiquette RotateSSHKeys d’Amazon Elastic Compute Cloud (EC2) avec une valeur à « True » afin d’identifier les instances du cluster qui correspondent aux nœuds de travail. Notez que si vous vous fiez aux étiquettes en tant que contrôle de sécurité, vous devez impérativement gérer les utilisateurs qui disposent de droits de modifications des étiquettes -et de leurs valeurs- sur vos instances EC2.

Coût de la solution

Aujourd’hui, une telle solution déployée dans la région de Virginie du Nord coûtera 0,0914 USD de l’heure pour les quatre instances t2.micro EC2 et NAT Gateway qui composent le cluster test. Secrets Manager dispose d’une période d’essai -sans frais- de 30 jours, après quoi un secret coûtera 0,40 USD par mois et 0,05 USD tous les 10000 appels API. Enfin, Il n’y a pas de frais supplémentaires pour AWS Systems Manager.

Déploiement de la solution type

Dans cette section, vous déploierez une pile (stack) type qui illustre l’ensemble de la solution. Après le déploiement, vous allez vous connecter au nœud principal, puis vous irez copier de manière sécurisée un fichier vers l’un des nœuds de travail. Enfin, vous utiliserez Secrets Manager pour faire la rotation et déployer une nouvelle paire de clés SSH. Les templates CloudFormation et le code de rotation du secret sont disponibles dans le référentiel GitHub AWS.

Lancez le déploiement en sélectionnant le bouton de lancement de la pile AWS CloudFormation ci-dessous ; par défaut, la pile sera déployée dans la région us-east-1 (Virginie du Nord).

Le template CloudFormation crée un Amazon Virtual Private Cloud (VPC), des sous-réseaux privés et publics, des instances EC2 (pour le nœud principal, et le cluster simulé), ainsi que le rôle IAM et les stratégies utilisés par les instances EC2.

  1. Sélectionnez votre paire de clés SSH EC2 et entrez votre plage IP en tant que paramètres de la pile. Dans le champ YourIPRange, entrez uniquement le CIDR de votre machine ou réseau, car seuls les hôtes de votre réseau peuvent accéder au serveur principal. Vous pouvez laisser tous les autres paramètres par défaut. Ce template CloudFormation lance quatre instances t2.micro dans un nouveau VPC. Une instance sera marquée avec l’étiquette MasterServer et le reste sera marqué avec les étiquettes WorkerServer1-3.

Remarque : La paire de clés SSH référencée ici sera utilisée pour se connecter à partir de votre ordinateur local au nœud principal. Il est différent de la paire utilisée par le nœud principal pour se connecter aux nœuds de travail.

Figure 2 : Entrez le CIDR de votre machine ou réseau.

Important : Par souci de simplicité, le nœud principal que vous allez créer dans cette procédure est dans un sous-réseau public, le rendant accessible à partir du CIDR que vous avez fourni à l’étape 2. Cependant, il ne s’agit pas de l’approche la plus sécurisée possible. Suivez les instructions de la documentation Amazon EC2 VPC pour configurer en toute sécurité votre cluster dans un sous-réseau privé en suivant le principe de « défense en profondeur ».

  1. Surveillez le statut de la pile. Lorsque le statut est à CREATE_COMPLETE, le déploiement est prêt. Sélectionnez l’onglet Sorties pour trouver des informations sur les ressources nouvellement créées, puis notez la valeur du DNS public du nœud principal et l’adresse IP d’un nœud de travail. Vous aurez besoin des deux valeurs plus tard dans ce billet.
  2. Cliquez sur le bouton Launch Stack (Lancer pile) ci-dessous pour lancer le template AWS CloudFormation qui déploiera la fonction Lambda utilisée par Secrets Manager dans la région us-east-1, puis, acceptez les valeurs par défaut. Ce template est conçu pour être réutilisé ; il peut être appliqué à n’importe quel cas de figure de rotation de paire de clés SSH.

Ensuite, créez et configurez un nouveau secret à partir de la console Secrets Manager pour stocker la paire de clés SSH dédiée à la communication du cluster.

Configuration d’un secret dans AWS Secrets Manager

Le template CloudFormation n’a pas déployé de secret. Suivez donc ces étapes pour créer un secret à partir de la console ainsi qu’une configuration de fonction de rotation. Pour créer un nouveau secret:

  1. Ouvrez la console AWS Secrets Manager et sélectionnez Stocker un nouveau secret.
  2. Sélectionnez Autre type de secrets (par ex., clé d’API), puis sélectionnez l’onglet Texte brut
  3. Comme illustré à la figure 3, entrez {} pour créer une valeur JSON vide sans propriétés. Cette valeur sera initialement renseignée avec une paire de clés par la fonction Lambda de rotation

Figure 3 : Création d’une valeur JSON vide sans propriétés.

  1. Conservez la clé de chiffrement par défaut et sélectionnez Suivant. Nous conservons la clé de chiffrement par défaut par souci de simplicité dans cet exemple, mais les meilleures pratiques en matière de sécurité suggèrent d’utiliser une Customer Master Key (CMK) que vous pouvez créée au préalable.
  2. Dans l’étape 2 : Nom et description du secret, nommez le secret /dev/ssh. Le chemin d’accès d’un secret peut être utilisé dans la stratégie IAM du secret pour restreindre l’accès des utilisateurs et des rôles à un secret ou une hiérarchie de secrets. Par exemple, la stratégie IAM peut inclure /dev/* ou /prod/* pour contrôler l’accès aux secrets depuis les environnements de développement ou de production, respectivement.
  3. Ajoutez une description, puis sélectionnez Suivant.

Figure 4 : Ajouter une description.

  1. À l’étape 3 : Configurer la rotation automatique, choisissez Activer la rotation automatique et activez un intervalle de rotation de votre choix, vous pouvez le configurer à l’aide de la liste déroulante prévue à cet effet.
  2. Sélectionnez Choisir une fonction AWS Lambda et choisissez RotateSSH. Il s’agit de la fonction Lambda qui a été déployée par le template CloudFormation.
  3. Sélectionnez Suivant, puis passez en revue votre configuration et sélectionnez Stocker. Lorsque la nouvelle configuration de secrets est stockée, la fonction Lambda de rotation est immédiatement appelée, remplissant la valeur du secret.

Figure 5: Configurer la rotation automatique.

Test de la solution type

Dès lors que la configuration du secret est terminée et que les instances EC2 sont en cours d’exécution, vous allez maintenant copier avec SCP un fichier du nœud principal vers l’un des nœuds de travail, en utilisant la clé SSH stockée dans Secrets Manager pour valider la solution.

  1. Connectez-vous au nœud principal via SSH à l’aide de la clé EC2 que vous avez spécifiée dans le template CloudFormation dans les étapes précédentes.
  2. Une fois connecté, copiez en toute sécurité un fichier du nœud maître vers le nœud de travail à l’aide de SCP (secure copy protocol) en utilisant la commande suivante. Remplacer <private-ip-of-> par l’IP du nœud de travail que vous avez copiée à l’étape 3 :
python copy_file.py ec2-user <private-ip-of-worker>

La figure 6 montre la connexion ssh au nœud principal et la commande copy_file.py au nœud de travail.

Figure 6: Connexion ssh au nœud principal, et la commande du script copy_file.py.

Pendant l’exécution, le script python utilisera l’API get_secret_value API de Secrets Manager pour récupérer le secret, qui inclut la clé privée. Il utilisera ensuite cette clé pour établir une connexion SSH sécurisée avec les nœuds de travail, sans conserver la clé privée sur un emplacement de stockage du nœud principal.

Vous pouvez consulter le fichier copy_file.py sur le nœud principal ou sur GitHub. Dans la fonction get_private_key(), vous pouvez lire la valeur du secret, qui inclut la clé privée :

get_secret_value_response = client.get_secret_value(
    SecretId=secret_name)

Dans la fonction copy_file, nous créons un tunnel SSH sécurisé afin de copier un fichier en utilisant la clé privée depuis la mémoire, en utilisant Paramiko, une implémentation Python de SSHv2.

private_key_str = io.StringIO()
# Write private key to a memory file
private_key_str.write(private_key)
    
# Create key object
key = paramiko.RSAKey.from_private_key(private_key_str)
    
# Open a channel and authenticate 
trans = paramiko.Transport(ip, 22) 
trans.start_client()
trans.auth_publickey(user, key)
del key

Pour démontrer la rotation de la paire de clés SSH, vous allez maintenant appeler manuellement la fonction de rotation :

  1. Retournez à la console Secrets Manager, sélectionnez votre secret /dev/ssh, puis choisissez Récupérer la valeur du secret pour afficher la paire de clés.
  2. Sélectionnez Effectuer Immédiatement une rotation du secret. Dans la fenêtre contextuelle, confirmez votre choix en sélectionnant Effectuer une rotation.

Figure 7: Paramétrer “Valeur du secret” et “Configuration de la rotation”.

  1. Sélectionner Effectuer une rotation une dernière fois afin de compléter la rotation.

Figure 8: Séléection de “Effectuer une rotation”.

  1. Cliquez sur le bouton Close pour actualiser la vue, puis choisissez à nouveau Récupérer la valeur du secret.
  2. Une fois la rotation terminée, vous pouvez vérifier la nouvelle paire de clés via la console Secrets Manager. Retournez au terminal et exécutez le même script python pour copier un fichier à l’aide de SCP. Remplacer <private-ip-of-worker> par votre propre IP de nœud de travail:
python copy_file.py ec2-user <private-ip-of-worker>

Le fichier a dorénavant été transféré avec succès à l’aide d’une nouvelle paire de clés, sans aucune mise à jour requise.

Audit et Surveillance

Vous pouvez monitorer et auditer toutes les appels API utilisées pour créer et faire la rotation de vos clés dans Secrets Manager via AWS CloudTrail. Pour afficher les événements CloudTrail, procédez comme suit :

  1. Ouvrez la console CloudTrail et sélectionnez Historique des événements.
  2. Dans le champ déroulant Attributs de recherche, sélectionnez Source de l’événement, entrez secret dans le champ filtre, puis sélectionnez secretsmanager.amazonaws.com dans le menu déroulant.
  3. À partir de là, vous pouvez consulter les événements de Secrets Manager, tels que GetSecretValue, PutSecretValue, UpdateSecretVersionStage(qui modifie les étiquettes attachées à une version d’un secret) et RotationSucceeded, dans l’historique des événements CloudTrail. Ces journaux d’événements aident à auditer la configuration, la rotation et l’accès aux secrets.

Figure 9: La fenêtre “Historique des événement”.

En outre, Secrets Manager peut utiliser CloudWatch Events pour déclencher des alertes lorsque des opérations spécifiées par l’administrateur se produisent dans une organisation (par exemple, pour vous avertir d’une tentative de suppression d’un secret).

Nettoyage du Template CloudFormation

Pour supprimer toute la pile CloudFormation :

  1. Sélectionnez le template nommé RotateSSH dans la console CloudFormation.
  2. Sélectionnez Supprimer . Cela supprimera toutes les ressources AWS créées par le template.
  3. Répétez les étapes précédentes pour supprimer le template nommée MasterWorkers.
  4. À partir de la console AWS Secrets Manager, supprimez le secret /dev/ssh. Pour en savoir plus sur la suppression et la restauration d’un secret, consultez le Guide de l’utilisateur AWS Secrets Manager.

Conclusion

Dans cet article, nous avons montré comment vous pouvez utiliser AWS Secrets Manager pour stocker, faire tourner et donner accès à des paires de clés SSH afin de sécuriser les communications au sein d’un cluster de calcul. Les clés sont chiffrées et stockées en toute sécurité dans AWS Secrets Manager, ce qui permet également de faire la rotation des clés et d’en installer les clés publiques sur tous les nœuds, à votre place. En utilisant cette méthode, vous n’aurez pas à déployer manuellement les clés SSH sur les différentes instances EC2 ou à les faire leur rotation manuellement. Les API associées à la gestion des secrets et à la rotation sont enregistrées dans CloudTrail à des fins d’audit et de surveillance. Cette solution de rotation de clés est sans serveur. Il ne nécessite aucun serveur à maintenir et peut évoluer rapidement.

 

Si vous avez des commentaires sur cet article de blog, partagez-les dans la section Commentaires ci-dessous. Si vous avez des questions sur cet article, lancez un nouveau fil de discussion sur le forum AWS Secrets Manager.

Vous souhaitez plus d’informations sur la sécurité AWS ? Suivez-nous sur Twitter.

Article original rédigé en anglais par Assaf Namer et Ananth Vaidyanathan, Solutions Architects chez AWS, et traduit par Sébastien Butreau, Partner Solutions Architect dans l’équipe AWS France, LinkedIn.