# Antipatterns de la gestion des secrets sur un parc d’agence audité

> Passer en revue les erreurs classiques (secrets versionnés, partagés par email, jamais tournés) observées en audit externe.

- Auteur : WordPress Développement
- Publié le : 2024-01-11
- Mis à jour le : 2024-01-11
- Catégorie : Outils & workflow
- URL : https://www.wpmoderne.fr/outils/antipatterns-gestion-secrets-parc-agence-audite/

## L’essentiel

- Un secret versionné une seule fois reste compromis pour toujours
- Le partage par email laisse une trace impossible à effacer
- Une rotation jamais planifiée finit toujours par ne jamais avoir lieu

« Nous recommandons une revue immédiate de la gestion des secrets sur l'ensemble du parc, plusieurs occurrences de clés API en clair ayant été identifiées dans l'historique Git de projets actifs » : cette phrase, extraite du rapport d'un audit de sécurité externe mandaté sur notre parc de projets, a servi de déclencheur à une revue complète de nos pratiques de gestion des secrets. Quatorze clés ou identifiants sensibles ont été retrouvés versionnés en clair sur l'ensemble des dépôts audités, certains datant de plusieurs années.

Voici les quatre antipatterns identifiés par cet audit, avec pour chacun ce qui a été observé, pourquoi c'est un problème plus sérieux qu'il n'y paraît, et ce que nous avons changé depuis.

## Un secret versionné une seule fois reste compromis pour toujours

Ce qu'on observait : une clé d'API tierce (service d'envoi d'email, passerelle de paiement de test) committée dans un fichier de configuration, puis supprimée dans un commit ultérieur une fois l'erreur remarquée. L'équipe considérait alors le problème résolu, la clé n'apparaissant plus dans le code actuel.

**Pourquoi c'est un problème** : Git conserve l'intégralité de l'historique. Une clé supprimée du code actuel reste parfaitement accessible dans l'historique des commits, y compris pour quiconque a accès au dépôt, même après suppression du fichier concerné. Un dépôt rendu public par erreur, ou un accès compromis au dépôt privé, expose l'intégralité de cet historique, pas seulement l'état actuel du code.

**Quoi faire** : toute clé committée par erreur doit être considérée comme définitivement compromise et révoquée immédiatement auprès du service concerné, indépendamment de sa suppression du code. Une réécriture d'historique via `git filter-repo` peut compléter cette révocation mais ne la remplace jamais.

## Le partage par email ou messagerie laisse une trace impossible à effacer

Ce qu'on observait : des identifiants de connexion à un serveur ou à une base de données transmis par email entre collègues, ou collés dans une conversation de messagerie d'équipe, pratique habituelle pour transmettre rapidement un accès à un nouveau membre de l'équipe.

> L'essentiel à retenir : Un secret versionné une seule fois reste compromis pour toujours ; Le partage par email laisse une trace impossible à effacer ; Une rotation jamais planifiée finit toujours par ne jamais avoir lieu

**Pourquoi c'est un problème** : un email ou un message reste stocké indéfiniment dans des boîtes de réception, des archives, des sauvegardes de messagerie, hors du contrôle de l'équipe technique. Un accès compromis à une seule boîte email peut ainsi exposer des identifiants transmis des années plus tôt, toujours valides s'ils n'ont jamais été renouvelés depuis.

**Quoi faire** : un gestionnaire de secrets dédié (coffre-fort d'équipe avec partage temporaire et traçable) remplace tout partage par email ou messagerie, avec des liens de partage à expiration automatique plutôt que des identifiants collés en clair dans une conversation persistante.

### Une rotation jamais planifiée finit toujours par ne jamais avoir lieu

Ce qu'on observait : des identifiants de base de données et des clés d'API en production datant, pour certains, de la création initiale du projet plusieurs années auparavant, jamais renouvelés depuis faute de procédure formalisée déclenchant cette rotation.

**Pourquoi c'est un problème** : plus un secret reste stable dans le temps, plus la fenêtre pendant laquelle une fuite passée inaperçue reste exploitable s'allonge. Un ancien collaborateur ayant eu accès à un identifiant des années plus tôt, ou une fuite jamais détectée, conserve un accès valide indéfiniment en l'absence de rotation.

**Quoi faire** : une politique de rotation planifiée, avec une fréquence adaptée à la sensibilité du secret (tous les quatre-vingt-dix jours pour les accès de production, tous les ans a minima pour les clés de service tiers moins critiques), inscrite dans un calendrier suivi par l'équipe plutôt que laissée à la discrétion individuelle.

## Un fichier `.env` exclu du dépôt mais jamais vérifié

Ce qu'on observait : un fichier `.gitignore` correctement configuré pour exclure les fichiers `.env` sur la majorité des projets, mais sans vérification automatisée que cette exclusion fonctionnait réellement à chaque nouveau projet créé, certains ayant hérité d'une configuration de `.gitignore` incomplète copiée d'un ancien modèle.

```
# verification automatisee ajoutee a la chaine d'integration continue
if git ls-files | grep -qE '\.env$|\.env\.'; then
  echo "ECHEC : un fichier .env est present dans le depot"
  exit 1
fi
```

**Quoi faire** : un contrôle automatisé dans la pipeline d'intégration continue, qui vérifie explicitement qu'aucun fichier correspondant au motif d'un fichier de secrets n'est versionné, plutôt que de faire confiance uniquement à la configuration de `.gitignore`, qui peut être incomplète ou copiée d'un modèle obsolète.

> La gestion des secrets n'échoue presque jamais par manque de connaissance des bonnes pratiques ; elle échoue par absence de vérification automatisée qui rendrait l'erreur humaine impossible à ignorer.

## Notre retour d'expérience

Sur les quatorze secrets identifiés par l'audit, aucun n'était le fruit d'une méconnaissance des bonnes pratiques de la part de l'équipe ; chacun résultait d'un raccourci pris sous pression de délai, jamais corrigé faute de contrôle automatisé pour le signaler. La leçon retenue n'est pas de renforcer la formation, déjà correcte, mais d'ajouter des vérifications systématiques qui ne dépendent plus de la vigilance individuelle d'un jour chargé.