Gestion des clés et des secrets : bonnes pratiques

Les meilleurs algorithmes du monde ne servent à rien si la clé est laissée sur un post-it, publiée par erreur dans un dépôt de code ou envoyée par e-mail. Dans la pratique, la grande majorité des défaillances de la cryptographie ne viennent pas des mathématiques mais de la gestion des clés et des secrets. Cette dernière leçon du chapitre rassemble les bons réflexes, utiles autant aux utilisateurs qu'aux futurs professionnels.

Vous avez vu dans les leçons précédentes que tout repose sur le secret d'une clé : la clé AES, la clé privée RSA, la clé privée d'un certificat. Un secret, au sens large, regroupe toute information dont la divulgation donnerait un accès indu : mots de passe, clés de chiffrement, clés SSH, jetons d'accès, clés d'API, chaînes de connexion à une base de données.

Les erreurs les plus fréquentes

• Un secret en clair dans le code source, puis publié dans un dépôt de code. C'est l'une des fuites les plus courantes, et les attaquants parcourent en permanence les dépôts publics pour y repérer des secrets.
• Un secret dans l'historique d'un dépôt : même supprimé de la dernière version, il reste récupérable dans les anciennes versions.
• Un secret transmis par un canal non sûr : e-mail, messagerie de groupe, capture d'écran partagée.
• Une clé unique pour tout : la même clé utilisée pour le développement et la production, ou partagée par toute l'équipe.
• Des secrets qui ne changent jamais, donc exposés pour toujours en cas de fuite non détectée.
• Des droits trop larges : une clé d'API qui permet de tout faire alors que l'usage n'en demande qu'une partie.

Les principes de base

1. Ne jamais écrire un secret dans le code ni dans un fichier suivi par le gestionnaire de versions. On le charge au démarrage depuis l'extérieur (variable d'environnement, fichier de configuration non versionné, service dédié).
2. Un secret par usage. Une clé par application, par environnement (développement, test, production), par personne ou par service. Si l'une fuit, l'impact est limité et l'on sait d'où elle vient.
3. Le moindre privilège. Chaque clé ne doit autoriser que ce qui est strictement nécessaire : lecture seule si l'usage est la lecture, un seul service, une seule ressource.
4. Une durée de vie limitée et une rotation régulière. Plus un secret est ancien, plus il a eu de chances de fuiter. Prévoyez dès le départ un moyen de le changer sans tout casser.
5. Un stockage protégé. Les secrets humains (mots de passe) vont dans un gestionnaire de mots de passe. Les secrets techniques vont dans un coffre-fort de secrets (vault) ou le service équivalent de votre plateforme, qui chiffre, contrôle les accès et journalise les consultations.
6. Une traçabilité. On doit savoir qui a accédé à quel secret et quand.

Les variables d'environnement : un pas, pas une solution complète

Pour éviter de coder un secret en dur, on le fournit souvent via une variable d'environnement :

# Dans le terminal, avant de lancer le programme
export API_KEY="valeur-de-test-pour-le-labo"

# Dans un script bash
echo "Clé chargée : ${#API_KEY} caractères"

C'est mieux que d'écrire la valeur dans le code, mais ce n'est pas parfait : les variables d'environnement peuvent apparaître dans des journaux, dans des rapports d'erreur, dans la liste des processus ou être héritées par des sous-programmes. Pour des besoins sérieux, on préfère un coffre-fort de secrets qui distribue les secrets de façon temporaire et contrôlée. Si vous utilisez un fichier de configuration local (souvent nommé .env), ajoutez-le immédiatement au fichier .gitignore pour qu'il ne soit jamais versionné :

echo ".env" >> .gitignore
echo "*.pem" >> .gitignore
echo "*.key" >> .gitignore

Les clés SSH : un exemple concret

SSH permet de se connecter à distance à un serveur. Plutôt qu'un mot de passe, on peut utiliser une paire de clés : la clé publique est installée sur le serveur, la clé privée reste sur votre machine. Avantages : pas de mot de passe qui circule, impossible à deviner par essais répétés. Pour créer une paire de clés moderne dans votre laboratoire :

ssh-keygen -t ed25519 -C "labo" -f ~/.ssh/id_labo
ls -l ~/.ssh/id_labo*
chmod 600 ~/.ssh/id_labo

La commande vous demande une phrase de passe : ne la laissez pas vide, car elle chiffre la clé privée sur votre disque. Ainsi, quelqu'un qui copierait le fichier n'obtiendrait pas immédiatement l'accès. Le fichier id_labo est la clé privée (jamais partagée, droits 600), id_labo.pub est la clé publique (que l'on peut copier sur les serveurs). Les clients SSH refusent d'utiliser une clé privée dont les permissions sont trop ouvertes : c'est une protection du principe de moindre privilège que vous avez vu au chapitre 4.

Générer de l'aléa de qualité

Un secret doit être imprévisible. Un mot de passe inventé « à la main » ou une clé calculée à partir de la date ne le sont pas. On utilise le générateur d'aléa cryptographique du système :

openssl rand -hex 32          # 32 octets aléatoires, affichés en hexadécimal
head -c 32 /dev/urandom | base64

Les bibliothèques sérieuses des langages de programmation proposent des fonctions dédiées (à ne pas confondre avec les fonctions de nombres aléatoires ordinaires, prévisibles). Ne bricolez pas.

Protéger le matériel de clé

Pour les clés les plus critiques (clé privée d'une autorité de certification, clés de signature), on utilise du matériel dédié : un module de sécurité matériel (HSM), ou à plus petite échelle une carte à puce, une clé de sécurité physique ou la puce de sécurité (TPM) de votre ordinateur. La clé est générée et reste à l'intérieur du composant : on peut lui demander de signer, mais jamais de livrer la clé elle-même. Une clé qui ne peut pas être copiée ne peut pas être volée par une simple intrusion logicielle.

Sauvegarde, perte, vol : prévoir avant

• Sauvegardez vos clés de chiffrement : une clé perdue rend les données définitivement illisibles. La sauvegarde doit elle-même être protégée (chiffrée, séparée, avec accès contrôlé).
• Documentez la procédure de remplacement : qui peut révoquer un certificat, régénérer une clé, redéployer ?
• Préparez la révocation : savoir invalider un secret rapidement est aussi important que de savoir le créer.

À vous de jouer

1. Créez une paire de clés SSH ed25519 dans votre laboratoire, avec une phrase de passe. Vérifiez les droits de la clé privée.
2. Créez un dossier de projet de test avec un fichier .env contenant une fausse clé (« clé factice »). Ajoutez .env à un fichier .gitignore.
3. Cherchez des secrets potentiels dans un de vos propres dossiers de projet avec une recherche simple (grep -rniE "password|secret|api_key" ~/labo-linux). Qu'avez-vous trouvé ?
4. Rédigez en trois lignes la procédure que vous suivriez si votre fausse clé fuitait.

Vous avez maintenant les briques techniques : réseau, Linux, Windows, cryptographie. Le dernier chapitre rassemble tout cela vers l'objectif du parcours : le test d'intrusion. Il commence, comme il se doit, par ce qui est permis et ce qui ne l'est pas.