Aller au contenu principal

DMV — Checklist de rotation des secrets

Date : 2026-06-07
Statut : checklist opérationnelle
Usage : préprod et production

1. Objectif​

Cette checklist sert à gérer proprement un secret DMV :

  • secret exposé dans un chat ;
  • secret suspecté compromis ;
  • rotation préventive planifiée ;
  • changement de fournisseur ou d’environnement.

Elle doit être utilisée sans improvisation, avec une logique de continuité de service.

2. Règles obligatoires​

  • Ne jamais republier le secret compromis.
  • Ne jamais commiter un secret réel.
  • Ne jamais conserver un ancien secret “au cas où” au-delà de la fenêtre de transition prévue.
  • Toujours documenter :
    • quel secret a été tourné ;
    • sur quels systèmes ;
    • à quelle date ;
    • par qui ;
    • avec quel impact.
  • Toujours vérifier la propagation avant révocation finale si une rotation sans coupure est possible.

3. Classification des secrets DMV​

Niveau critique​

  • SUPABASE_SERVICE_ROLE_KEY
  • SUPABASE_DB_PASSWORD
  • SUPABASE_JWT_SECRET
  • APP_KEY
  • STRIPE_SECRET
  • STRIPE_WEBHOOK_SECRET
  • RESEND_API_KEY
  • OPENAI_API_KEY ou autre clé provider IA
  • secrets webhook entrants

Niveau important​

  • SUPABASE_ANON_KEY
  • NEXT_PUBLIC_* non sensibles mais structurants
  • tokens d’intégration tiers non critiques

Niveau opérationnel​

  • mots de passe IMAP/SMTP
  • secrets Cloudflare Worker
  • secrets cron / automation

4. Procédure standard​

Étape 1 — Identifier​

  • Identifier précisément le secret concerné.
  • Identifier son niveau de criticité.
  • Identifier où il est utilisé :
    • api/.env*
    • dmv-public/.env*
    • dmv-workspace/.env*
    • Cloudflare Pages
    • Cloudflare Workers
    • Supabase Edge Functions
    • VPS
    • GitHub Actions / CI
    • machine locale

Étape 2 — Cartographier l’impact​

  • Déterminer si le secret est utilisé :
    • côté serveur uniquement ;
    • côté frontend ;
    • dans un Worker ;
    • dans une Edge Function ;
    • dans un webhook tiers.
  • Déterminer si une rotation sans coupure est possible.
  • Identifier les flux à tester après rotation.

Étape 3 — Générer le nouveau secret​

  • Générer un nouveau secret depuis le provider concerné.
  • Vérifier immédiatement qu’il est stocké dans l’outil de secret management ou dans les variables d’environnement appropriées.
  • Ne jamais le coller dans un fichier versionné.

Étape 4 — Déployer le nouveau secret​

  • Mettre à jour les variables sur tous les environnements concernés :
    • préprod ;
    • prod ;
    • CI/CD ;
    • workers ;
    • edge functions ;
    • cron VPS ;
    • outils d’administration.
  • Re-déployer uniquement les services concernés.

Étape 5 — Vérifier​

  • Vérifier les flux critiques impactés :
    • auth ;
    • API ;
    • envoi email ;
    • IA ;
    • webhooks ;
    • paiements ;
    • workers ;
    • edge functions.
  • Vérifier aussi :
    • logs d’erreur ;
    • statuts HTTP ;
    • timeouts ;
    • permissions provider.

Étape 6 — Révoquer l’ancien secret​

  • Révoquer l’ancien secret chez le provider.
  • Vérifier qu’aucun service ne dépend encore de l’ancien.
  • Contrôler les erreurs post-révocation.

Étape 7 — Clôturer​

  • Documenter la rotation.
  • Noter la cause :
    • exposition accidentelle ;
    • suspicion de fuite ;
    • rotation périodique ;
    • départ collaborateur ;
    • incident infra.
  • Ouvrir un correctif structurel si nécessaire.

5. Checklist exécutable​

A. Constat​

  • Le secret concerné est identifié.
  • Le niveau de criticité est évalué.
  • L’exposition est confirmée ou suspectée.

B. Cartographie​

  • Les usages dans api sont listés.
  • Les usages dans dmv-public sont listés.
  • Les usages dans dmv-workspace sont listés.
  • Les usages Cloudflare sont listés.
  • Les usages Supabase sont listés.
  • Les usages VPS / cron / scripts sont listés.
  • Les usages CI/CD sont listés.

C. Rotation​

  • Un nouveau secret valide a été généré.
  • Le nouveau secret a été injecté en préprod.
  • Le nouveau secret a été injecté en production si nécessaire.
  • Les services concernés ont été redéployés.

D. Validation​

  • Les routes critiques répondent correctement.
  • Les logs applicatifs ne montrent pas d’erreur d’auth.
  • Les webhooks impactés répondent correctement.
  • Les emails impactés partent correctement.
  • Les providers externes impactés répondent correctement.

E. Révocation​

  • L’ancien secret a été révoqué.
  • Aucun fallback caché vers l’ancien secret ne subsiste.
  • Une vérification post-révocation a été faite.

F. Documentation​

  • La rotation a été notée dans le journal d’exploitation.
  • La cause a été documentée.
  • Un ticket structurel a été créé si la fuite venait d’un problème de process.

6. Vérifications spécifiques DMV​

Supabase​

  • vérifier :
    • SUPABASE_URL
    • SUPABASE_ANON_KEY
    • SUPABASE_SERVICE_ROLE_KEY
    • SUPABASE_JWT_SECRET
  • revalider :
    • auth frontend ;
    • échanges Sanctum ;
    • Edge Functions ;
    • RLS / accès API admin dépendants

Laravel API​

  • vérifier :
    • APP_KEY
    • secrets Supabase
    • secrets Stripe
    • secrets email
    • secrets IA
  • revalider :
    • auth ;
    • webhooks ;
    • jobs ;
    • endpoints critiques

Cloudflare​

  • vérifier :
    • variables Pages ;
    • variables Workers ;
    • secrets webhook ;
    • domaines / proxy si concernés
  • revalider :
    • redirects ;
    • proxy workspace ;
    • workers entrants

Email​

  • vérifier :
    • RESEND_API_KEY
    • identifiants IMAP/SMTP
    • secrets inbound webhook
  • revalider :
    • contact équipe ;
    • contact acteur ;
    • réponse support ;
    • réception des replies

IA​

  • vérifier :
    • clés provider ;
    • plafonds et quotas
  • revalider :
    • génération ;
    • amélioration ;
    • tags ;
    • onboarding

7. Post-incident obligatoire​

Après exposition d’un secret, il faut toujours se poser ces questions :

  • Pourquoi le secret a-t-il pu être exposé ?
  • Était-il trop accessible ?
  • Était-il utilisé au mauvais endroit ?
  • Était-il manipulé dans un outil non adapté ?
  • Faut-il :
    • réduire les accès humains ;
    • ajouter de la détection de secrets ;
    • revoir les prompts/outils ;
    • revoir les procédures de debug ;
    • sortir certains traitements du frontend/edge ?

8. Conditions minimales avant clôture​

La rotation n’est considérée terminée que si :

  • le nouveau secret est en place partout ;
  • l’ancien est révoqué ;
  • les flux critiques testés sont OK ;
  • les logs ne montrent pas d’échec résiduel ;
  • la documentation a été mise à jour.