Gestion des clés SSH : 7 bonnes pratiques pour 2026

Le problème des clés SSH

Les clés SSH sont la colonne vertébrale de l'accès aux serveurs. Elles sont plus sûres que les mots de passe, simples à mettre en place et supportées partout. Mais à mesure que votre équipe grandit, la complexité de leur gestion grandit aussi.

La plupart des équipes commencent avec une poignée de clés, en copiant manuellement les clés publiques sur les serveurs. En un an, vous avez des dizaines de clés disséminées entre les portables, les pipelines CI/CD et les dossiers partagés. Personne ne sait quelles clés donnent accès à quels serveurs. Quand quelqu'un part, révoquer l'accès consiste à se connecter sur chaque serveur individuellement.

7 bonnes pratiques

1. Centraliser la gestion des clés

Cessez de gérer les clés sur chaque serveur. Utilisez un système centralisé qui sert de source unique de vérité pour qui a accès à quoi. C'est ce qui rend l'audit possible et la révocation instantanée.

2. Mettre en place une rotation des clés

Les clés SSH doivent avoir une date d'expiration. Définissez une politique de rotation - 90 jours est un bon point de départ. La rotation automatisée élimine le syndrome du "on le fera plus tard" qui aboutit à des clés vieilles de plusieurs années toujours valides en production.

3. Utiliser l'authentification par certificats

Les certificats SSH sont supérieurs aux clés brutes en environnement d'équipe. Ils incluent des métadonnées (qui, quoi, quand, où) et peuvent être bornés dans le temps. Un certificat qui expire dans 8 heures est intrinsèquement plus sûr qu'une clé qui vit éternellement.

4. Imposer l'authentification multi-facteur

Les clés SSH seules sont une authentification à un seul facteur. Combinez-les avec TOTP, WebAuthn ou des clés de sécurité matérielles. Si une clé est compromise, le second facteur empêche l'accès non autorisé.

5. Auditer chaque connexion

Journalisez qui s'est connecté, quand, depuis où et ce qu'il a fait. Sans journaux d'audit complets, vous ne pouvez pas enquêter sur les incidents, prouver la conformité ni répondre à la question basique : "Qui a accédé à la production cette nuit ?"

6. Appliquer le principe du moindre privilège

Les développeurs n'ont pas besoin d'un accès root sur tous les serveurs. Définissez des politiques d'accès par rôle. Un développeur frontend a besoin d'accéder au serveur de staging, pas à la base de données de production.

7. Automatiser le offboarding

Quand quelqu'un part, la révocation d'accès doit être automatisée et instantanée. Les processus de offboarding manuels sont lents, sujets à erreur et constituent un risque de sécurité.

Comment SecurSSH aide

SecurSSH met en œuvre ces bonnes pratiques nativement : gestion centralisée des identifiants SSH dans un coffre chiffré, journal d'audit de 24 mois, RBAC à trois niveaux, et révocation instantanée par retrait de membre. La signature de certificats SSH, le 2FA TOTP sur le compte et la MFA d'équipe obligatoire sont sur la feuille de route 2026. Mise en place en 15 minutes.