Où stocker les secrets - Guide de décision par contexte

La question "où stocker un secret ?" revient tous les jours en production et n'a pas de réponse unique : un mot de passe admin cloud, une clé API Stripe, un secret HMAC de webhook, un certificat TLS privé, une clé SSH de déploiement, un token OAuth, un mot de passe DB applicatif - chacun a son contexte et sa solution appropriée. Mal répondue, cette question cause la majorité des fuites documentées : 23 millions de secrets détectés en 2024 dans les repos publics GitHub (GitGuardian), infostealers qui scrapent les machines des développeurs, tokens oubliés dans Slack 5 ans. Ce guide couvre les anti-patterns universels, la hiérarchie de stockage par contexte, les outils recommandés en 2026, et la tendance de fond : éliminer les secrets long-lived au profit de workload identity et tokens éphémères.

1. Qu'est-ce qu'un secret

1.1 Définition pratique

Un secret est une information qui ne doit jamais fuiter et qui, si compromise, donne à un attaquant les moyens d'emprunter une identité, accéder à des ressources, ou déchiffrer des données.

1.2 Taxonomie

1.3 Principe de base

Le meilleur secret est celui qui n'existe pas. Chaque secret long-lived est une dette sécurité qui s'accumule : stockage, rotation, révocation, audit. La tendance moderne est d'éliminer le maximum de secrets via workload identity et tokens éphémères.

2. Le modèle de menace secret

2.1 Qui peut accéder à un secret

Par ordre de probabilité en 2026 :

• Infostealers sur postes développeurs (RedLine, Vidar, StealC) qui exfiltrent tokens stockés localement.
• Leaks accidentels dans des repos Git publics via git push trop large.
• Screenshots collés dans Slack / tickets / documentation.
• Logs applicatifs qui capturent inadvertamment des credentials.
• Backups non chiffrés qui contiennent fichiers de config.
• Attaquant interne : employé curieux ou malveillant.
• Compromission d'un outil tiers qui stocke des secrets (Codecov 2021, CircleCI 2023, Okta 2022-2023).

2.2 Ce qu'un attaquant fait d'un secret

• Pivot : le secret donne accès à un service, d'où on trouve d'autres secrets, etc.
• Exfiltration de données : accès direct aux bases de données, buckets S3, stockage.
• Fraude financière : API Stripe compromise = remboursements frauduleux.
• Cryptomining : credentials cloud → spawn instances GPU de minage.
• Ransomware : credentials admin → prise de contrôle → chiffrement.
• Espionnage long terme : silent access persistant.

Le cas AWS credentials : en moyenne 60 secondes entre push d'un repo public et début d'exploitation par bots scanner (GitGuardian 2024).

3. Les 10 anti-patterns à ne JAMAIS faire

3.1 Commit dans le code source

Classique. Secret en dur dans config.py, application.yml, .env commité par erreur.

Une fois dans l'historique Git, jamais vraiment supprimé (force push ne supprime pas des clones existants ni des backups GitHub). Rotation immédiate obligatoire si détecté.

Mitigation : gitleaks / trufflehog en pre-commit, GitHub Secret Scanning activé, review obligatoire des PR.

3.2 Fichiers de config pushed en clair

config.production.json avec tokens, committé par mégarde.

Mitigation : .gitignore strict, utiliser des fichiers .example sans valeurs réelles, templates avec variables nommées.

3.3 Variables d'environnement non protégées

Env var DATABASE_URL=postgres://user:password@host/db visible dans :

• /proc/<pid>/environ lisible par les processus du même user.
• Core dumps, crash reports, monitoring.
• Output de debug (printenv, env).
• Outputs CI/CD non masqués.

Mitigation : env vars issues d'un secret manager au runtime, jamais stockées telles quelles dans les CI config. Masquage des logs.

3.4 Screenshots dans Slack / Teams / Zoom

"J'ai capturé l'écran pour te montrer le problème", capture inclut terminal avec credential.

Slack, Teams, Zoom conservent ces contenus indéfiniment (ou jusqu'à purge), accessibles aux admins, parfois exfiltrés en cas de compromission de la plateforme.

Mitigation : formation équipe, workflow de partage sécurisé (1Password share), revue Slack periodique.

3.5 Email

Envoyer un credential par email = secret copié dans :

• Serveurs mail expéditeur et destinataire.
• Backups des serveurs mail.
• Archives sortantes.
• Indexé par les outils de search enterprise.

Mitigation : jamais de secret dans email clair. 1Password / Bitwarden / HashiCorp Vault Wrapped Response pour partage temporaire.

3.6 Wikis partagés (Notion, Confluence, Google Docs)

"Documentation de setup" avec credentials. Parfois partagés publiquement par erreur, toujours accessibles à tous les employés.

Mitigation : wikis internes ne doivent jamais contenir de secrets. Références à un secret store centralisé.

3.7 localStorage / sessionStorage (navigateur)

Tokens JWT stockés en localStorage = accessibles à tout JavaScript de la page. Une XSS = vol du token.

Mitigation : cookies HttpOnly Secure SameSite pour tokens sensibles. Voir gestion de session sécurisée.

3.8 Docker image layers

Dockerfile qui fait COPY .env /app/.env ou ARG API_KEY → les secrets se retrouvent dans les layers de l'image Docker. Même si tu supprimes le fichier plus tard, le layer historique contient toujours la valeur.

Mitigation : multi-stage builds, runtime secret injection (env vars non-persistées), jamais de secret en argument de build.

3.9 CI/CD avec secrets plaintext dans les configs

Pipeline GitLab CI avec DATABASE_PASSWORD: my_password dans .gitlab-ci.yml. Ou GitHub Actions avec secrets en clair.

Mitigation : toujours utiliser les features de masked secrets (GitHub Actions Secrets, GitLab CI variables masked, CircleCI contexts). Préférer OIDC pour éliminer totalement les secrets long-lived.

3.10 Tickets Jira / issues GitHub / emails de support

"Voici les credentials pour reproduire le bug" → tickets archivés pour des années, lisibles par de plus en plus de monde au fil du temps.

Mitigation : policy stricte, outils qui détectent et bloquent à la soumission.

4. Hiérarchie de stockage - où stocker selon le contexte

4.1 Pour un développeur individuel

Gestionnaire de mots de passe comme seule source :

• 1Password : référence, excellent UX, intégration CLI + SSH agent.
• Bitwarden : open source, self-hostable.
• Dashlane, LastPass : alternatives (LastPass a eu des incidents graves 2022, éviter).
• KeePassXC : local, pour utilisateurs avancés.

Ne jamais stocker dans :

• Notes Apple / Google.
• Fichiers texte.
• Navigateur (sans gestionnaire dédié).
• Clipboard persistant.

4.2 Pour une équipe qui collabore

• 1Password Teams / Business : shared vaults, permissions, audit.
• Bitwarden Teams : alternative open source.
• HashiCorp Vault : pour environnements plus techniques avec besoin de rotation / dynamic secrets.

Principe : un secret partagé dans un gestionnaire team, pas copié dans plusieurs vaults personnels.

4.3 Pour des applications en production

Hiérarchie des meilleures options :

Niveau 1 - Workload identity (le mieux) :

• Pas de secret stocké du tout. L'identité est attestée par la plateforme.
• AWS IAM Roles + IRSA (EKS) ou EC2 Instance Profile.
• GCP Workload Identity Federation.
• Azure Managed Identities.
• Kubernetes ServiceAccounts + OIDC vers cloud.
• GitHub Actions / GitLab CI OIDC vers cloud.

Voir service accounts : risques et bonnes pratiques.

Niveau 2 - Secret manager cloud avec dynamic secrets :

• AWS Secrets Manager + rotation automatique.
• Azure Key Vault + rotation.
• GCP Secret Manager + Cloud Scheduler.
• HashiCorp Vault avec dynamic database credentials.

Avantage : credentials courte durée générés à la demande.

Niveau 3 - Secret manager avec rotation :

• Vault / Cloud Secrets Manager avec rotation manuelle programmée (trimestrielle).
• Credentials long-lived mais avec processus de rotation.

Niveau 4 - Chiffrement applicatif (fallback) :

• Si contrainte technique impose de stocker le secret dans la config : chiffrer avec SOPS (Mozilla), sealed-secrets (Kubernetes), age.
• Clé de déchiffrement stockée dans un KMS.

4.4 Pour les clés cryptographiques critiques

HSM (Hardware Security Module) :

• Stockent les clés en hardware tamper-resistant.
• La clé ne sort jamais du HSM.
• Signature / chiffrement effectué dans le HSM.

Options :

• AWS CloudHSM : HSM dédié dans AWS.
• Azure Dedicated HSM / Managed HSM.
• GCP Cloud HSM.
• Google Cloud External Key Manager (EKM) : clés chez le client, référencées depuis GCP.
• Thales Luna Network HSM : on-prem ou cloud.
• Entrust nShield : équivalent.
• YubiHSM 2 : HSM compact (USB), pour petites PKIs.

Usage typique : Root CAs, clés de signing de release, clés de chiffrement master (KEK d'envelope encryption).

4.5 Pour CI/CD

Priorité 1 : OIDC workload identity vers le cloud cible. Pas de secret stocké dans le CI.

Priorité 2 : secrets du CI (GitHub Actions Secrets, GitLab CI Variables masked) + rotation régulière.

Priorité 3 : intégration avec un secret manager externe (Vault agent dans le runner).

4.6 Pour du code côté client (mobile, SPA)

Principe fondamental : pas de secrets côté client. Le client (mobile ou browser) est inspectable, décompilable, debuggable.

Si une clé API doit être exposée à un client mobile :

• Pour l'app mobile : stockage dans Keychain iOS / Android Keystore (secure enclave hardware).
• Pour le web : la clé n'existe pas côté client. Faire passer par un proxy backend.

Jamais de clé secrète dans :

• Code JavaScript servi.
• App mobile obfusquée (l'obfuscation ne résiste pas à 5 minutes d'analyse).
• Code embarqué IoT sans Secure Element.

5. Par type de secret - guide spécifique

5.1 Mot de passe utilisateur

• Côté user : gestionnaire de mots de passe personnel (1Password, Bitwarden).
• Côté serveur : jamais stocké en clair. Hash avec Argon2id (voir chiffrement symétrique).
• Transport : HTTPS strict + formulaire login (pas dans URL).

5.2 Clés API (Stripe, Twilio, OpenAI, etc.)

• Runtime : secret manager (Vault, Cloud Secrets Manager).
• Dev : gestionnaire de mots de passe + config locale dans fichiers non committés.
• Rotation : tous les 90 jours minimum, plus souvent si surface exposée.
• Scope : chaque service = sa clé dédiée (pas partagée entre environnements).

5.3 Credentials de base de données

• Préféré : dynamic secrets de Vault / Cloud Secrets Manager (credentials générés à la connexion, durée 1h-24h).
• Acceptable : secret statique dans secret manager + rotation mensuelle via Secrets Manager rotation.
• À éviter : credentials statiques en env vars long-lived.

IAM auth natif quand disponible (RDS IAM auth, Cloud SQL IAM, Cosmos DB AAD) pour éliminer le password complètement.

5.4 Secrets HMAC (webhooks, cookies, JWT HS256)

• Génération : os.urandom(32) (256 bits d'entropie).
• Stockage : secret manager.
• Rotation : annuelle ou sur incident.
• Distribution : séparée par service / endpoint, pas de secret global.

5.5 Clés de chiffrement (AES, ChaCha20)

• Envelope encryption : DEK locale, chiffrée par KEK dans KMS.
• Stockage KEK : KMS managé (AWS KMS, Cloud KMS, Azure Key Vault).
• Accès KEK : via IAM, jamais directement.
• Rotation KEK : automatique annuelle (AWS KMS propose par défaut).

5.6 Clés privées asymétriques (Ed25519, ECDSA, RSA)

Selon la criticité :

• Modeste (cert d'un microservice interne) : généré par le service, stocké en Kubernetes Secret chiffré.
• Moyenne (cert d'une API publique) : KMS cloud ou Vault.
• Haute (cert Root CA, clé de code signing) : HSM hardware.

La clé privée ne doit jamais traverser le réseau en clair. Signature et chiffrement effectués là où la clé est stockée (HSM / KMS).

5.7 Clés SSH

• Clé SSH personnelle : local + passphrase + SSH agent + Keychain OS. Jamais dans le cloud.
• Clé SSH de déploiement (CI/CD) : évitée au maximum, privilégier OIDC. Si nécessaire : secret manager du CI, scope restrictif.
• Clés SSH serveur (hostkeys) : générées localement, stockées en /etc/ssh/.

Outils modernes : SSH certificates via CA SSH (step, smallstep, Teleport) pour éviter les clés statiques.

5.8 Certificats TLS

• Certs publics Let's Encrypt : gérés par ACME client (certbot, cert-manager), rotation automatique.
• Certs internes : cert-manager + Issuer Vault / step-ca.
• Clé privée du cert : chiffrée au repos, accessible uniquement au processus qui termine TLS.

5.9 Tokens OAuth et refresh tokens

• Access token : stocké en mémoire, courte durée (15 min), pas persisté.
• Refresh token : stocké chiffré au repos (browser : cookie HttpOnly ; mobile : Keychain), rotation à chaque usage.
• Client secret : traité comme une clé API, secret manager.

5.10 Credentials cloud (AWS Access Keys, etc.)

Objectif 2026 : les éliminer.

• Remplacement par workload identity (IRSA, Workload Identity Federation, Managed Identity).
• OIDC pour CI/CD (GitHub Actions → AWS via OIDC).
• Si encore nécessaires : dans AWS IAM Identity Center avec sessions courtes via SSO.

6. Kubernetes - cas spécial

6.1 Kubernetes Secrets par défaut

Ressource Secret dans Kubernetes = base64 seulement (pas chiffré au repos par défaut).

Pour en faire un vrai secret store :

• Encryption at rest activée sur etcd (via KMS provider AWS/Azure/GCP, Vault KMS, ou secret box).
• RBAC strict sur accès aux Secrets.

6.2 Solutions spécialisées

• External Secrets Operator (ESO) : synchronise des secrets depuis Vault / AWS Secrets Manager / etc. vers des Kubernetes Secrets natifs. Le plus adopté.
• HashiCorp Vault Agent Injector : sidecar qui injecte les secrets dans le pod.
• Secrets Store CSI Driver : monte les secrets depuis un store externe comme volume.
• Sealed Secrets (Bitnami) : chiffre les secrets pour pouvoir les commit dans Git.
• SOPS (Mozilla) : chiffre les fichiers YAML avec KMS, committables dans Git.

6.3 Bonne architecture

• Source de vérité : Vault ou Cloud Secrets Manager externe.
• Synchronisation : ESO vers Kubernetes Secrets.
• Accès workload : via volume mount ou env var (pas via API K8s).
• Audit : logs Vault / Cloud Secrets Manager.
• Rotation : automatisée à la source, ESO rafraîchit les Secrets K8s.

7. Prévention des fuites - outillage

7.1 Pre-commit hooks

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.2
    hooks:
      - id: gitleaks
  - repo: https://github.com/zricethezav/gitleaks
    rev: v8.18.2
    hooks:
      - id: gitleaks

Intercepte les secrets avant commit local. Coût : installation une fois, bénéfice permanent.

7.2 Secret scanning côté serveur

• GitHub Secret Scanning : détecte des patterns connus (AWS keys, GCP service accounts, Stripe, Slack, etc.) dans les repos. Notification automatique aux émetteurs. Gratuit sur repos publics, Advanced Security payant sur privés.
• GitLab Secret Detection : équivalent GitLab Ultimate.
• Trufflehog, detect-secrets : scanners open source.

7.3 Detection proactive

Outils qui scannent en continu :

• GitGuardian : monitoring GitHub public + repos privés avec coverage large.
• Doppler : plateforme secret management avec detection.
• Spectral (CheckPoint) : scan code et SaaS pour secrets.

7.4 Processus en cas de détection

Quand un secret est trouvé committé :

1. Révocation immédiate du secret (pas "on va rotater bientôt", immédiatement).
2. Rotation : nouveau secret émis et distribué aux consommateurs légitimes.
3. Audit : logs d'utilisation du secret révoqué pour détecter exploitation.
4. Investigation : qui a committé, comment, y a-t-il d'autres secrets similaires.
5. Post-mortem : mitigation pour empêcher la récurrence.

Ne jamais se contenter de "force push pour supprimer" : l'historique Git est mirroré dans les clones, backups, forks.

8. Rotation des secrets

8.1 Pourquoi roter

• Limiter la fenêtre d'exploitation en cas de fuite non détectée.
• Forcer la discipline opérationnelle (automation).
• Conformité (SOC 2, ISO 27001 exigent).

8.2 Fréquences recommandées 2026

8.3 Rotation automatique

Quand possible : 100 % automatisée. Workflow :

1. Secret manager génère nouveau secret.
2. Distribue aux consommateurs legitimates.
3. Attente période de grâce (les deux secrets valides).
4. Révocation de l'ancien.

AWS Secrets Manager, Azure Key Vault, Vault font cela nativement pour les types standards (DB credentials, API keys).

8.4 Rotation sur incident

Si un secret pourrait être compromis (développeur parti, commit détecté, alerte anormale) : rotation immédiate, pas de délai.

9. Zero-trust appliqué aux secrets

9.1 Principes

• Aucune confiance implicite : un process qui demande un secret doit prouver son identité.
• Least privilege : chaque secret accessible uniquement aux identités qui en ont strictement besoin.
• Logs et audit : chaque accès à un secret est loggé, analysable rétroactivement.
• Courte durée de vie : préférer tokens éphémères à secrets statiques.

9.2 Architecture pratique

Workload (pod K8s)
  └── Workload identity (IRSA / IAM role)
        └── Authentication vers Vault ou KMS
              └── Vault délivre credentials dynamiques
                    └── Workload utilise pour durée courte
                          └── Audit log de l'accès et de l'usage

Aucun secret statique dans le workload. Tout dérivé à la demande.

9.3 ITDR pour les secrets

Identity Threat Detection and Response appliqué aux identités workload et aux accès aux secrets :

• Alertes sur accès anormaux (heures, volumes, secrets accédés).
• Détection de patterns d'exfiltration (mass download).
• Corrélation avec incidents.

Outils : Silverfort NHI, Entro, Astrix, Oasis Security.

10. Le cas particulier - partager un secret en équipe

10.1 Pour une distribution one-time

• 1Password Share : génère un lien d'un secret valable une seule vue.
• HashiCorp Vault Response Wrapping : wrap un secret pour transmission, unwrap côté receveur.
• One Time Secret (privatebin self-hostable) : message détruit après consultation.

10.2 Pour un accès récurrent d'équipe

• 1Password Teams / Business : shared vaults avec permissions granulaires.
• Bitwarden Teams : alternative open source.
• HashiCorp Vault avec policies.

10.3 Pour un accès partenaire B2B

• Secret dédié par partenaire (pas de secret global partagé).
• Rotation régulière négociée.
• Notification en cas de changement.
• Idéalement : API avec workload identity mutual (mTLS ou OIDC federation).

11. Outils recommandés 2026 - synthèse

12. Checklist - secrets management mature

Développement local

• Gestionnaire de mots de passe individuel
• Pas de secret dans le code, même temporairement
• Fichiers .env dans .gitignore
• Templates .example avec variables nommées non-secrets
• Pre-commit hooks (gitleaks) installés

Partage en équipe

• Gestionnaire de mots de passe team (1Password Business / Bitwarden Teams)
• Jamais de secret dans Slack / email / tickets
• Vault wrapping pour distribution temporaire

Production - runtime

• Workload identity privilégiée sur secrets statiques
• Secret manager central (Vault / Cloud Secrets Manager)
• Dynamic secrets quand possible (DB credentials courte durée)
• Envelope encryption avec KMS pour les données
• HSM pour les clés critiques (Root CA, code signing)

Kubernetes

• etcd encrypted at rest
• External Secrets Operator ou équivalent
• RBAC strict sur Secrets
• Pas de secret en ConfigMap

CI/CD

• OIDC vers cloud au maximum
• Secrets CI masked
• Pas de secret dans .gitlab-ci.yml ou workflow.yml
• Rotation des secrets CI restants

Mobile / Client

• Keychain iOS / Android Keystore pour secrets locaux
• Jamais de secret dans le code client
• Certificate pinning quand applicable

Processus

• Rotation planifiée selon type de secret
• Processus de révocation rapide documenté
• Secret scanning continu (GitHub, GitLab, external)
• Post-mortem systématique des fuites
• Audit annuel de l'inventaire secrets

Détection et réponse

• ITDR pour identités workload
• Alertes sur accès secrets anormaux
• Logs centralisés avec rétention 1 an minimum

13. Verdict et posture Zeroday

"Où stocker les secrets" n'a pas de réponse unique, mais a des règles universelles :

• Les anti-patterns (code, env non protégée, chat, wiki) sont connus et évitables.
• La hiérarchie des stockages sûrs est bien établie : gestionnaires de mots de passe → secret managers cloud → KMS → HSM.
• La tendance dominante 2026 est l'élimination des secrets long-lived au profit de workload identity et tokens éphémères.

Pour un développeur : la discipline la plus rentable est d'intégrer pre-commit hooks + gestionnaire de mots de passe dans le setup initial, et de considérer chaque nouveau secret long-lived comme un problème à minimiser.

Pour un AppSec : auditer où et comment les secrets sont stockés révèle rapidement la maturité d'une organisation. Anti-patterns dans les PRs, secrets dans Notion, env vars en clair → dette à résorber.

Pour une organisation : standardiser sur un secret manager (cloud natif si mono-cloud, Vault si hybride) et éliminer systématiquement les alternatives (fichiers de config, wikis, emails) est l'investissement qui produit les gains les plus durables. Une bonne discipline secrets est un signal fort de maturité dans tout audit SOC 2 / ISO 27001.

Pour approfondir : secrets management cloud pour le volet cloud provider spécifique, service accounts : risques et bonnes pratiques pour le remplacement des secrets par workload identity, qu'est-ce que la cryptographie pour le contexte général, PKI expliquée pour les certs et clés privées, qu'est-ce qu'une CSR pour les CSR et certificats.