Comment partager des cles SSH et certificats en toute securite avec votre equipe

"Envoie-moi la cle SSH sur Slack." Une phrase banale dans les equipes de developpement. L'acces au serveur est urgent, un nouveau membre doit configurer son environnement, le deploiement approche et la cle manque.

Mais cette demande anodine peut declencher un incident de securite majeur.

Pourquoi les cles SSH sont particulierement dangereuses

Une cle SSH n'est pas un simple mot de passe. Elle donne un acces complet au serveur.

Critere	Mot de passe	Cle SSH
Portee	Compte specifique	Serveur entier
Impact en cas de fuite	Ce compte	Toutes les donnees du serveur
Difficulte de rotation	Changement immediat	Regenerer + mettre a jour tous les serveurs
Authentification a deux facteurs	Disponible	La cle est l'authentification

Une cle SSH compromise signifie que tous les fichiers, bases de donnees et codes du serveur sont accessibles.

Situations ou l'equipe doit partager des cles

• Acces serveur partage : serveurs staging et production auxquels toute l'equipe a besoin d'acceder
• Cles de deploiement : cles utilisees par les pipelines CI/CD
• Certificats SSL : transfert lors du changement de responsable
• Secrets API : integration avec des services tiers
• Identifiants de base de donnees : reponse aux incidents urgents

Methodes dangereuses de partage

1. Messages prives Slack/Discord

L'historique des conversations est stocke indefiniment sur les serveurs. N'importe qui peut retrouver une cle en cherchant "ssh" ou "key".

2. Email

Archive en permanence sur les serveurs de messagerie. Un seul transfert et le controle est perdu.

3. Google Drive/Notion partage

Le controle d'acces granulaire est difficile. Les copies locales persistent apres la synchronisation.

4. Commit dans un depot Git

La methode la plus dangereuse. La cle reste pour toujours dans l'historique Git, meme apres suppression du fichier.

Methodes securisees de partage

Methode 1 : Note secrete LOCK.PUB (ideale pour un transfert unique)

1. Creer une note secrete sur LOCK.PUB
2. Coller le contenu de la cle SSH ou du certificat
3. Definir un mot de passe fort
4. Configurer l'expiration la plus courte possible (1-4 heures)
5. Envoyer le lien par Slack, communiquer le mot de passe par telephone
6. Apres sauvegarde de la cle par le destinataire, le lien expire

Avantages :

• La cle n'est jamais stockee en clair sur un serveur
• Acces impossible apres expiration
• Aucune trace de la cle dans l'historique de chat

Methode 2 : Gestionnaire de secrets (pour les grandes equipes)

HashiCorp Vault, AWS Secrets Manager, Google Secret Manager.

Methode 3 : Autorite de certification SSH (solution a long terme)

Exploiter une CA SSH qui delivre des certificats individuels a chaque utilisateur.

Methode 4 : Cles individuelles (la plus recommandee)

Principe : Cle partagee < Cles individuelles
Fuite de cle partagee → Toute l'equipe impactee
Fuite de cle individuelle → Seul cet utilisateur impacte

Liste de controle en cas de partage necessaire

Avant le transfert

• Les permissions de la cle sont-elles au minimum requis ?
• Une cle en lecture seule suffirait-elle ?
• Des restrictions IP peuvent-elles etre appliquees ?

Pendant le transfert

• La cle et le mot de passe transitent-ils par des canaux differents ?
• L'expiration est-elle la plus courte possible ?

Apres le transfert

• Confirmation que le destinataire a stocke la cle en securite
• Verification que le lien ou la note a expire
• Surveillance des journaux d'utilisation de la cle

Calendrier de rotation des cles

Type de cle	Rotation recommandee
Cles de serveur de production	90 jours
Cles de deploiement	90 jours
Certificats SSL	A chaque renouvellement
Secrets API	90 jours
Cles dev/staging	180 jours

Liste de securite pour les equipes DevOps

• Des cles SSH individuelles sont-elles utilisees pour tous les serveurs ?
• Les cles partagees ont-elles des restrictions IP ?
• Les cles des employes partants sont-elles desactivees immediatement ?
• Un calendrier de rotation des cles est-il en place ?
• Des cles SSH n'ont-elles jamais ete commitees dans Git ?
• Aucune cle en clair ne subsiste-t-elle dans les historiques de chat ?
• Un canal avec expiration est-il utilise pour transmettre des secrets ?

Conclusion

Les cles SSH et les certificats sont le pilier de la securite serveur. Les envoyer par Slack ou email revient a afficher la cle de votre maison sur un panneau public. Delivrez des cles individuelles autant que possible. Quand le partage est inevitable, utilisez une note secrete avec l'expiration la plus courte.

Creez une note secrete maintenant pour transmettre vos cles SSH en toute securite.

Creer une Note Secrete