Guide de gestion des clés SSH multi-cloud

Alors que de plus en plus d'entreprises déplacent leurs opérations et leurs données dans des environnements multi-cloud, les questions autour de la gestion des clés SSH sont de plus en plus nombreuses. Mark Thompson, Senior Vice President, Product Management, et Ryan Sanders, Product Marketing Manager, à Keyfactor, ont répondu à ces questions lors de leur session commune à l'occasion du 2020 Critical Trust Virtual Summit.

Dans ce blog, je vais décomposer les concepts de base couverts dans notre session et fournir les meilleures pratiques pour la gestion des clés SSH multi-cloud.

SSH semble être partout. 84% des entreprises actuelles utilisent le protocole SSH dans une certaine mesure dans leur infrastructure.

Pourquoi ? Parce que SSH est un moyen pratique d'authentifier et de sécuriser les connexions, sans compter qu'il est intégré aux systèmes Linux et Unix. SSH est largement utilisé par les administrateurs de systèmes pour accéder à distance aux systèmes et, de plus en plus, dans le cadre de processus automatisés, tels que la copie et la sauvegarde sécurisées ou les transferts de fichiers sécurisés.

L'authentification par clé publique est le choix de facto pour l'accès SSH. Contrairement aux mots de passe, les clés SSH ne sont pas vulnérables aux attaques par force brute et ne nécessitent aucune interaction de la part de l'utilisateur pour permettre l'accès, ce qui les rend idéales pour les processus automatisés.

En raison de leurs avantages, la prolifération des clés SSH est sans précédent. Il n'est pas rare de découvrir 50 à 200 clés par serveur, ou de voir 1 million de clés dans une organisation.

Malgré l'accès privilégié qu'ils offrent, ils ne sont pas étroitement contrôlés dans de nombreuses situations. Cela crée une situation à haut risque. En l'absence de cadre de gestion, de plus en plus de clés sont passées sous le radar des auditeurs et des équipes de gestion de la sécurité et des risques.

Alors que la plupart des organisations sont familiarisées avec PKI et la gestion des certificats X.509, les défis liés aux clés SSH sont totalement différents.

Par exemple, les certificats font l'objet d'une attention particulière en ce qui concerne leur renouvellement avant leur expiration (afin d'éviter les pannes). Cependant, les clés SSH n'expirent pas, ce qui crée le risque inverse d'informations d'identification périmées et d'accès non autorisé.

Vous trouverez ci-dessous une ventilation des principales différences :

Le plus grand risque auquel les entreprises sont confrontées est la prolifération des clés SSH. La cause principale de la prolifération des clés SSH est l'absence de gestion centralisée des clés et des accès :

• Manque de contrôle : Les administrateurs s'approvisionnent eux-mêmes en clés, les copient et les partagent sans aucune restriction.
• Pas d'expiration : Les clés SSH n'expirent pas et sont laissées sans gestion sur les systèmes pendant des années.
• Absence de politique : L'accès à la racine est souvent accordé même s'il n'est pas nécessaire.
• Visibilité limitée : Il n'y a pas de visibilité centralisée des clés autorisées et privées.
• Lenteur des mesures correctives : Les équipes de sécurité hésitent à révoquer ou à changer les clés.

Une autre cause de la prolifération des clés SSH est la rotation du personnel. Bien qu'il existe des processus standardisés pour supprimer les personnes qui quittent l'Active Directory, ces processus n'incluent souvent pas les clés SSH qui leur sont associées. Le réseau complexe de relations de confiance entre les clés, les utilisateurs et les machines rend le processus de suppression ou de rotation des clés incroyablement pénible et risqué.

Selon les conclusions de l'étude 2020 Global Encryption Trends Study réalisée par nCipher et Ponemon, 57 % des équipes de sécurité admettent que la gestion des clés SSH est pénible ou très pénible.

Sous l'impulsion des initiatives commerciales visant à migrer les opérations et les données vers le nuage, les clés SSH sont confrontées à une nouvelle norme. Plusieurs raisons expliquent l'utilisation accrue des clés SSH sur les plates-formes en nuage :

• 90 % de toutes les charges de travail des nuages publics fonctionnent aujourd'hui sous Linux (dont SSH est un composant essentiel).
• Plusieurs équipes utilisent SSH dans les nuages et les outils de gestion de la configuration (par exemple, les nœuds de contrôle Ansible, les serveurs d'infrastructure Chef, etc.)
• Les ingénieurs DevOps utilisent SSH pour se connecter aux dépôts Git, aux charges de travail distantes, etc.

Signe des temps, GitHub a récemment annoncé l'abandon des mots de passe au profit des clés SSH. À mesure que les développeurs utilisent les clés SSH dans des environnements hautement automatisés et distribués, les risques ne cessent de croître.

Ces développements soulignent que la gestion et la protection des clés SSH dans le nuage sont essentielles pour les entreprises d'aujourd'hui. Toutefois, les différences entre les fournisseurs de cloud augmentent la complexité de la gestion des clés SSH, en particulier lorsque les entreprises adoptent des stratégies multi-cloud.

• Google Cloud, AWS et Azure permettent tous aux utilisateurs de générer de nouvelles clés ou d'utiliser des clés ssh existantes.
• L'accès SSH est configuré et géré différemment dans chaque environnement cloud (voir ci-dessous).
• Les clés SSH sont faciles à générer, mais il est difficile de tenir à jour un inventaire des clés et des relations de confiance.

Il est important de se rappeler que, même si certaines responsabilités en matière de sécurité sont passées de l'utilisateur au fournisseur de services en nuage, c'est toujours à l'utilisateur qu'il incombe de gérer et de conserver ses clés SSH. Il est essentiel d'assurer la cohérence du contrôle, des politiques et de la visibilité sur toutes les plates-formes en nuage.

Malgré leur importance, les personnes ne manipulent pas les clés SSH de manière appropriée. Si l'on ajoute à cela les mauvaises configurations de l'informatique en nuage et des charges de travail, on obtient une surface de menace accrue. Les attaques impliquant une mauvaise utilisation de SSH et des clés SSH sont devenues monnaie courante. Elles sont devenues plus sophistiquées chaque jour, les logiciels malveillants connus étant modifiés pour cibler les clés SSH.

Voici quelques exemples :

• Microsoft Azure a révélé une attaque basée sur Linux qui utilise la force brute pour les connexions SSH basées sur un mot de passe afin de compromettre les machines virtuelles.
• Une attaque contre les serveurs Exim (serveurs de messagerie Linux) télécharge un script shell qui ajoute une clé SSH au compte root.
• Le logiciel malveillant GoLang est une campagne de crypto-minage qui cible les serveurs Linux et utilise les clés SSH découvertes pour cibler d'autres hôtes et se propager.
• Le logiciel malveillant TrickBot a mis à jour son système d'extraction de mots de passe pour cibler OpenSSH et OpenVPN.
• Le botnet FritzFrog force l'accès à des millions d'adresses IP SSH et insère une clé ssh publique appartenant à l'attaquant dans le fichier des clés autorisées pour un accès permanent.
• Le logiciel malveillant Lemon_Duck utilise le balayage de ports pour trouver des machines écoutant sur le port 22 (SSH) et lance des attaques par force brute sur le nom d'utilisateur root et une liste de mots de passe codés en dur.

La question qui se pose est de savoir comment atténuer ces attaques basées sur SSH. Heureusement, il existe des recommandations faciles à mettre en œuvre.

Désactiver l'accès à la racine

La connexion à la racine est autorisée sur la plupart des systèmes Linux/Unix. Bien que cette recommandation semble contre-intuitive, si l'authentification par mot de passe et le mot de passe racine sont activés, le risque d'attaque est élevé.

Utiliser l'authentification par clé publique

Les connexions par mot de passe sont vulnérables aux attaques par force brute. L'authentification par clé est plus rapide et plus sûre (à condition que les utilisateurs soient formés et que les clés soient gérées correctement).

Utiliser une phrase de passe forte pour les clés

Les clés privées doivent toujours être protégées par une phrase de passe. Utilisez les meilleures pratiques pour les mots de passe et protégez le stockage et l'utilisation des clés privées.

Définir un port SSH personnalisé

Le port 22 est largement connu des attaquants et des logiciels malveillants de balayage de ports. Obscurcissez les services SSH en configurant un nouveau port, si possible.

Maintenir SSH à jour

Maintenez les paquets de votre serveur à jour (on n'insistera jamais assez sur ce point). Cela inclut les correctifs d'OpenSSH contre les nouvelles vulnérabilités.

En outre, il est recommandé de limiter le nombre de paires de clés SSH par utilisateur. Ce point est également essentiel car la plupart des utilisateurs ont tendance à réutiliser les phrases de passe de leur clé SSH privée. Une seule clé compromise peut être la porte d'accès à toutes les ressources critiques de l'entreprise.

La clé (sans jeu de mots) pour réduire votre exposition au risque est une gestion solide des clés. Cette gestion est essentielle, en particulier dans les environnements multi-cloud. Il n'est pas surprenant que cela commence par un inventaire de ce que vous possédez.

Découvrir les fichiers authorized_keys sur les serveurs et cartographier les relations de confiance entre les clés et les utilisateurs et les serveurs. Cela ne peut se faire efficacement qu'en recourant à un inventaire centralisé et automatisé.

Sur la base de l'inventaire des clés, vous pouvez repérer et analyser les risques liés aux serveurs SSH et aux accès utilisateurs non autorisés, aux clés avec accès root et aux clés faibles ou périmées. Les clés inutilisées, inconnues et orphelines peuvent être des clés de porte dérobée attendant d'être exploitées par des adversaires.

Pour limiter ces risques, supprimez toutes les clés inutilisées et orphelines. Effectuez une rotation ou remplacez les clés périmées ou faibles, et assurez des niveaux d'accès minimaux pour les utilisateurs.

Déployer de nouvelles clés dans le cadre d'un processus contrôlé. Permettre aux administrateurs et aux développeurs de travailler en libre-service. Automatiser le déploiement des clés. Stocker les clés privées dans un emplacement centralisé.

Restez attentif à la rotation des clés ssh. Définissez des règles pour la durée de vie maximale des clés et avertissez les utilisateurs qu'ils doivent procéder à la rotation avant l'"expiration". En outre, faites en sorte que la rotation des clés soit simple pour les utilisateurs afin de minimiser les frictions.

Une fois que vous avez mis en place un environnement contrôlé, il est plus facile d'identifier les clés malveillantes créées en dehors de la bande. Vérifiez régulièrement les types de clés, leur rotation et leur utilisation, et veillez à ce que le licenciement d'un employé s'accompagne de la révocation et du retrait des clés SSH correspondantes.

Legestionnaire de clés SSH Keyfactor est conçu pour relever les défis de la gestion des clés SSH dans les environnements multi-cloud et DevOps modernes. L'outil permet une gestion évolutive et automatisée du cycle de vie des clés SSH, même dans les déploiements les plus complexes.

Consultez notre eBook sur les 6 étapes pour reprendre le contrôle de vos clés SSH.