ediverse

Tapez pour rechercher dans les standards, messages, outils et glossaire.

ediverse Explorer la plateforme

À la une PEPPOL BIS Billing 3.0 L’obligation européenne d’e-invoicing arrive : France sept 2026, Belgique janv 2026, Allemagne 2025.

— 01

Fondamentaux

— 02

Standards

— 03

Messages phares

— 04

Outils

Secrets Management

Les secrets ne traînent pas en clair — jamais. Ils sont injectés à l'exécution, rotation programmée, accès journalisé.

Problème

Un secret en clair (mot de passe DB, clé API, certificat partenaire AS2) fuit beaucoup plus souvent qu'on ne pense : commit accidentel dans Git, journal CI/CD non chiffré, copie dans un wiki, screenshot d'un terminal, backup d'un .env. Une fois fuiteé, sa rotation est manuelle, lente, et oubliée. La compromission massive de TJX (2007), Uber (2016), CodeCov (2021) a été permise par des secrets non gérés.

Forces

  • Les secrets sont nombreux et hétérogènes (DB, API, clés signature, mots de passe partenaires AS2).
  • La rotation manuelle ne passe pas l'échelle — il faut de l'automatisme.
  • Le coût d'un coffre-fort spécialisé est élevé, mais le coût d'une fuite l'est davantage.
  • L'accès doit être audité : qui a lu quel secret, quand, depuis où.
  • Le coffre lui-même devient une cible critique — il faut HA, monitoring, restauration testée.

Solution

Centraliser les secrets dans un coffre dédié (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault) qui : (1) chiffre au repos avec une master key dérivée d'un HSM ; (2) accorde l'accès via une identité (rôle IAM, JWT, Kubernetes ServiceAccount) — pas de cred long-lived ; (3) génère des credentials dynamiques (Vault dynamic secrets) à durée limitée ; (4) automatise la rotation ; (5) journalise chaque lecture/écriture. Les applications ne stockent jamais le secret ; elles le récupèrent à l'init ou via sidecar (Vault Agent, CSI Secrets Store).

Cycle de vie

┌──────────────┐    rotate    ┌──────────────┐
│  Generation  │ ─────────────►│  Distribution │
└──────┬───────┘               └──────┬────────┘
       │ store                        │ fetch
       ▼                              ▼
┌──────────────┐    rotate    ┌──────────────┐
│   Storage    │ ◄─── audit ──┤  Application  │
│   (Vault)    │              │ (in-memory)   │
└──────┬───────┘               └──────┬────────┘
       │                              │ logout/expire
       │ revoke                       ▼
       ▼                       ┌──────────────┐
┌──────────────┐              │  Revocation   │
│  Audit log   │ ◄────────────┤   (manual or  │
└──────────────┘              │   automatic)  │
                              └──────────────┘

Implémentation EDI

Un hub EDI gère des dizaines de secrets : (a) certificats S/MIME / AS2 par partenaire — rotation tous les 12 mois (PEPPOL impose 2 ans max) ; (b) clés API ERP (SAP, Oracle, Workday) ; (c) creds SFTP partenaires sortants ; (d) tokens OAuth2 / OIDC pour les API REST CTC (Italie SDI, France Chorus Pro). Implémentation : Vault avec un mount KV-v2 par partenaire, accès via Kubernetes Vault Agent injector. Rotation auto via Vault rotate_period. La rotation des certificats AS2 est notoirement complexe (coordination avec le partenaire) — on doit traiter une fenêtre de chevauchement où les deux certs sont valides.

Anti-patterns

  • Secret en clair dans Git (même en repo privé) — fuiteure quasi certaine à terme.
  • Secret en variable d'environnement de pod sans coffre — visible via ps aux, /proc/.../environ.
  • Rotation manuelle « quand on aura le temps » — on n'a jamais le temps.
  • Vault sans HA — coffre down = applications down.
  • Pas d'audit log — impossible de répondre à un incident.
  • Politique d'accès Vault avec wildcard * — défait le principe de moindre privilège.

Patterns liés

Sources