Les informations d'authentification sont toutes les données secrètes qui permettent de prouver une identité et d'obtenir un accès aux systèmes. L'ISO 27002 mesure 5.17 recommande cinq contrôles principaux :

• Stockage sécurisé : ne jamais stocker les secrets en clair, utiliser le chiffrement fort et les coffres-forts numériques (vaults)
• Distribution sécurisée : transmettre les informations d'authentification par des canaux sécurisés, jamais par email ou messagerie instantanée non chiffrée
• Protection contre la compromission : détecter rapidement les fuites de credentials, forcer le changement immédiat, révoquer les accès
• Rotation régulière : changer périodiquement les secrets, surtout pour les comptes à privilèges et les clés d'API critiques
• Séparation des secrets : utiliser des credentials différents pour chaque système et environnement (développement, test, production

Ces contrôles visent à garantir que même si un secret est compromis, les dégâts restent limités et détectables rapidement.

Mots de passe utilisateurs

Les mots de passe des comptes utilisateurs standards et administrateurs. Un mot de passe compromis donne accès à tout ce que l'utilisateur peut faire : lire ses emails, accéder à ses fichiers, utiliser les applications métier avec ses droits.

Protection : stockage hashé avec sel (bcrypt, Argon2, PBKDF2), jamais en clair même dans les bases de données, politique de complexité et longueur minimale (12 caractères minimum), authentification multi-facteurs pour les comptes à privilèges.

Clés API et tokens d'accès

Les clés API permettent aux applications de s'authentifier auprès de services externes (API de paiement, services cloud, intégrations SaaS). Un token d'accès OAuth compromis donne accès temporaire aux ressources autorisées.

Protection : stockage dans des variables d'environnement ou coffres-forts (jamais en dur dans le code source), rotation régulière des clés (tous les 90 jours pour les clés critiques), limitation des permissions par clé (principe du moindre privilège), révocation immédiate si compromission suspectée.

Certificats et clés privées

Les certificats SSL/TLS et leurs clés privées associées sécurisent les communications HTTPS, VPN, signatures numériques. Une clé privée SSL compromise permet d'intercepter et déchiffrer tout le trafic, de se faire passer pour le serveur légitime (attaque man-in-the-middle).

Protection : clés privées stockées avec permissions restrictives (lecture uniquement par le service qui en a besoin), protection par mot de passe des clés quand possible, utilisation de HSM (Hardware Security Module) pour les clés les plus critiques, rotation avant expiration des certificats (renouvellement 30 jours avant expiration minimum).

Secrets d'infrastructure

Mots de passe administrateurs des bases de données, credentials root des serveurs, clés SSH des administrateurs, mots de passe des équipements réseau (routeurs, switches, pare-feu). Ces secrets donnent un contrôle total sur l'infrastructure.

Protection : stockage dans des coffres-forts d'entreprise (HashiCorp Vault, CyberArk, Azure Key Vault), accès tracé et enregistré (qui a récupéré quel secret quand), rotation après chaque utilisation pour les comptes les plus critiques (mots de passe à usage unique), accès conditionnel (nécessite validation managériale pour les secrets critiques).

Mots de passe utilisateurs

Les mots de passe des comptes utilisateurs standards et administrateurs. Un mot de passe compromis donne accès à tout ce que l'utilisateur peut faire : lire ses emails, accéder à ses fichiers, utiliser les applications métier avec ses droits.

Protection : stockage hashé avec sel (bcrypt, Argon2, PBKDF2), jamais en clair même dans les bases de données, politique de complexité et longueur minimale (12 caractères minimum), authentification multi-facteurs pour les comptes à privilèges.

Clés API et tokens d'accès

Les clés API permettent aux applications de s'authentifier auprès de services externes (API de paiement, services cloud, intégrations SaaS). Un token d'accès OAuth compromis donne accès temporaire aux ressources autorisées.

Protection : stockage dans des variables d'environnement ou coffres-forts (jamais en dur dans le code source), rotation régulière des clés (tous les 90 jours pour les clés critiques), limitation des permissions par clé (principe du moindre privilège), révocation immédiate si compromission suspectée.

Certificats et clés privées

Les certificats SSL/TLS et leurs clés privées associées sécurisent les communications HTTPS, VPN, signatures numériques. Une clé privée SSL compromise permet d'intercepter et déchiffrer tout le trafic, de se faire passer pour le serveur légitime (attaque man-in-the-middle).

Protection : clés privées stockées avec permissions restrictives (lecture uniquement par le service qui en a besoin), protection par mot de passe des clés quand possible, utilisation de HSM (Hardware Security Module) pour les clés les plus critiques, rotation avant expiration des certificats (renouvellement 30 jours avant expiration minimum).

Secrets d'infrastructure

Mots de passe administrateurs des bases de données, credentials root des serveurs, clés SSH des administrateurs, mots de passe des équipements réseau (routeurs, switches, pare-feu). Ces secrets donnent un contrôle total sur l'infrastructure.

Protection : stockage dans des coffres-forts d'entreprise (HashiCorp Vault, CyberArk, Azure Key Vault), accès tracé et enregistré (qui a récupéré quel secret quand), rotation après chaque utilisation pour les comptes les plus critiques (mots de passe à usage unique), accès conditionnel (nécessite validation managériale pour les secrets critiques).

Ne JAMAIS stocker en clair

Interdit absolu : fichiers texte contenant des mots de passe (config.txt, passwords.xlsx), scripts avec credentials en dur (`password = "Admin123"`), notes post-it sur les écrans, emails contenant des mots de passe, documentation wiki avec secrets visibles

Stockage des mots de passe : deux cas distincts

Côté serveur (authentification) : les mots de passe ne doivent JAMAIS être stockés de manière réversible (chiffrés avec possibilité de déchiffrement). Utiliser exclusivement des fonctions de hachage avec sel : bcrypt (recommandé, adaptable en complexité), Argon2 (plus récent, résistant aux attaques GPU), PBKDF2 (acceptable si correctement configuré), SHA-256 simple (INTERDIT, trop rapide à casser).

Le sel (salt) rend chaque hash unique même pour des mots de passe identiques, empêchant les attaques par rainbow tables.

Pourquoi hash et pas chiffrement ? Le serveur n'a pas besoin de connaître le mot de passe réel, seulement de vérifier qu'il est correct. Lors de la connexion, le serveur hache le mot de passe saisi et compare avec le hash stocké.

Côté client (gestionnaires de mots de passe) : le chiffrement réversible est nécessaire et légitime. Les gestionnaires de mots de passe (1Password, Bitwarden, Dashlane, KeePass) stockent les mots de passe chiffrés avec AES-256, protégés par un master password robuste. L'utilisateur peut ainsi récupérer ses mots de passe pour se connecter automatiquement aux sites et applications.

Règle simple : le système qui vérifie l'authentification utilise le hash irréversible ; le système qui stocke pour l'utilisateur utilise le chiffrement réversible.

Coffres-forts numériques (vaults)

Pour tous les autres secrets (clés API, certificats, mots de passe admin), utiliser des solutions de gestion centralisée des secrets : HashiCorp Vault (open source, très complet), Azure Key Vault (pour environnements Microsoft cloud), AWS Secrets Manager (pour infrastructure AWS), CyberArk (solution entreprise pour secrets critiques).

Avantages : chiffrement automatique, accès tracé et auditable, rotation automatisée possible, contrôle d'accès granulaire (qui peut accéder à quel secret), révocation instantanée, intégration avec les applications (récupération dynamique des secrets).

Remise initiale des credentials

Jamais par email : l'email transite en clair (ou chiffrement faible) par de multiples serveurs, reste stocké indéfiniment dans les boîtes de réception.

Méthodes sécurisées : génération d'un mot de passe temporaire à usage unique (expire après 24h ou première utilisation), lien de réinitialisation à usage unique envoyé par email (l'utilisateur choisit son propre mot de passe), communication hors bande (appel téléphonique pour comptes critiques), coffre-fort partagé temporaire (le mot de passe est déposé dans un vault accessible temporairement).

Communication des secrets entre systèmes

Les applications ont besoin de récupérer des secrets (clés API, mots de passe de base de données). Méthodes sécurisées : récupération dynamique depuis un vault (l'application interroge le vault au démarrage), variables d'environnement sécurisées (injectées au moment du déploiement, jamais stockées dans le code), fichiers de configuration chiffrés (déchiffrés au runtime avec une clé maître), secrets montés comme volumes (Kubernetes Secrets, Docker Secrets).

Méthodes interdites : secrets codés en dur dans le code source, fichiers de configuration en clair versionnés sur Git, secrets dans les paramètres d'URL ou les logs applicatifs.

Rotation périodique

Changer régulièrement les secrets réduit la fenêtre d'exploitation en cas de compromission non détectée : mots de passe administrateurs : tous les 90 jours, clés API critiques : tous les 90 jours ou à chaque changement de projet, certificats SSL : renouvellement 30 jours avant expiration, clés SSH administrateurs : tous les 180 jours, secrets d'infrastructure critique : après chaque utilisation (idéalement).

Rotation automatisée

Automatiser la rotation évite les oublis et réduit la charge opérationnelle : les solutions de vault peuvent générer automatiquement de nouveaux secrets selon un calendrier, notifier les équipes concernées avant expiration, mettre à jour automatiquement les systèmes consommateurs (si intégration API).

Rotation d'urgence

Changer immédiatement un secret en cas de : compromission confirmée ou suspectée, départ d'un employé qui connaissait le secret, fin d'un contrat prestataire ayant eu accès, système infecté par un malware susceptible d'avoir exfiltré des credentials, divulgation accidentelle (secret apparu dans un log, email, chat).

Surveillance des fuites

Surveiller activement les fuites de credentials sur Internet : bases de données de fuites publiques (Have I Been Pwned API pour vérifier si des emails/mots de passe de l'organisation sont apparus dans des leaks), repositories publics (GitHub, GitLab) : scanner automatiquement les dépôts publics pour détecter des secrets accidentellement commités, dark web monitoring : services qui surveillent les forums et marketplaces du dark web pour détecter des ventes de credentials volés.

Détection d'usage anormal

Détecter les utilisations suspectes de credentials valides : tentatives de connexion depuis des pays inhabituels, horaires anormaux (connexion administrateur à 3h du matin), échecs multiples suivis d'une réussite (force brute réussie), utilisation simultanée d'un même compte depuis plusieurs localisations (impossible physiquement), accès à des ressources jamais consultées auparavant.

Honeytokens

Créer des credentials factices (honeytokens) placés volontairement dans des endroits stratégiques. Si quelqu'un les utilise, c'est forcément une compromission car ces credentials n'ont aucune utilisation légitime. Placer des honeytokens dans : des fichiers de configuration abandonnés, des anciens scripts non utilisés, des documentations internes, des repositories de code archivés.

Toute utilisation d'un honeytoken déclenche une alerte immédiate et une investigation.

Environnements séparés

Utiliser des secrets différents pour chaque environnement : développement : secrets factices ou anonymisés (jamais de vraies données de production), test/staging : secrets dédiés avec permissions limitées, production : secrets réels avec protection maximale. Jamais de réutilisation de credentials de production dans des environnements moins sécurisés.

Exclusion du contrôle de version

Configurer Git pour ignorer systématiquement les fichiers contenant des secrets : fichier `.gitignore` incluant `*.env`, `config/secrets.yml`, `credentials.*`, scanner automatique pré-commit qui bloque si des patterns de secrets sont détectés (regex pour clés API, mots de passe), audit régulier de l'historique Git pour détecter d'anciens commits contenant des secrets.

Secrets dans les pipelines CI/CD

Les pipelines de déploiement ont besoin d'accéder à des secrets. Utiliser les fonctionnalités natives sécurisées : GitHub Actions Secrets : secrets chiffrés au niveau du repository, injectés comme variables d'environnement, GitLab CI/CD Variables : secrets protégés, masqués dans les logs, Azure DevOps Secure Files : fichiers chiffrés stockés séparément, Variables de pipeline chiffrées : jamais en clair dans les fichiers de configuration.

Règles simples pour les utilisateurs

Former tous les utilisateurs aux règles de base : ne jamais écrire son mot de passe sur papier ou post-it, ne jamais envoyer un mot de passe par email ou chat, ne jamais réutiliser son mot de passe professionnel ailleurs, utiliser un gestionnaire de mots de passe (1Password, Bitwarden, Dashlane), signaler immédiatement toute suspicion de compromission.

Règles renforcées pour les développeurs

Les développeurs manipulent des secrets applicatifs et doivent respecter des règles strictes : jamais de commit de secrets dans Git (vérifier systématiquement avant commit), utiliser des variables d'environnement ou vaults, tester uniquement avec des données anonymisées ou factices, rotation des clés API de test régulièrement, ne jamais partager des secrets via chat ou documentation publique.

• Secrets dans le code source : coder en dur des mots de passe ou clés API est l'erreur la plus fréquente et dangereuse. Utiliser systématiquement des variables d'environnement ou vaults.
• Email pour transmettre des mots de passe : l'email n'est pas sécurisé. Utiliser des liens de réinitialisation à usage unique ou des communications hors bande.
• Pas de rotation : garder les mêmes secrets pendant des années augmente le risque. Rotation trimestrielle minimum pour les comptes à privilèges
• Secrets partagés entre environnements : réutiliser les credentials de production en développement expose à des fuites. Toujours séparer les secrets par environnement.

Les informations d'authentification (mots de passe, clés API, certificats, tokens) sont les clés d'accès aux systèmes et doivent être protégées avec le plus grand soin. Le stockage sécurisé utilise le hachage avec sel (bcrypt, Argon2) pour les mots de passe et des coffres-forts numériques (vaults) pour les autres secrets. La distribution s'effectue uniquement par canaux sécurisés (liens de réinitialisation, communication hors bande, injection automatisée).

La rotation régulière des secrets (90 jours pour comptes à privilèges) limite l'impact d'une compromission non détectée. La détection de compromission combine surveillance des fuites publiques, analyse des comportements anormaux, et utilisation de honeytokens. Les secrets sont strictement séparés par environnement (développement, test, production) et exclus du contrôle de version. La formation des utilisateurs et développeurs aux bonnes pratiques complète le dispositif.