PricingLoginStart free
Cyber Security Academy · Leçon

Coffres-forts et magasins de secrets

Centraliser les secrets avec des outils comme Vault.

Leçon 2 sur 413 étapes

Coffres-forts et magasins de secrets est une leçon Cyber Security Academy gratuite sur CoddyKit. Ceci est la leçon 2 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Cyber Security Academy, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Cyber Security Academy comprend 4 leçons au total.

Ce qu’apporte un gestionnaire de secrets

Un gestionnaire de secrets (ou coffre-fort) est un service centralisé et renforcé dont l’unique rôle est de stocker les secrets, de contrôler les accès et d’en assurer la traçabilité. Il remplace les fichiers et variables d’environnement dispersés à l’origine de la prolifération.

Un bon gestionnaire de secrets fournit quatre fonctionnalités essentielles :

  • Stockage centralisé : une source de référence unique.
  • Contrôle des accès : des politiques détaillées définissant qui peut lire chaque secret et ce qui peut y accéder.
  • Journalisation des accès : un relevé de chaque accès pour la réponse aux incidents.
  • Chiffrement : des secrets chiffrés au repos et en transit.

Parmi les exemples figurent HashiCorp Vault, AWS Secrets Manager, Azure Key Vault et GCP Secret Manager.

Structure de HashiCorp Vault

HashiCorp Vault est un gestionnaire de secrets libre et populaire. Il organise ses fonctionnalités en moteurs de secrets enfichables, montés sur des chemins.

  • Moteur KV stocke des secrets statiques clé-valeur.
  • Moteur de base de données génère des identifiants de base de données dynamiques et à courte durée de vie.
  • Moteur PKI émet des certificats TLS à la demande.
  • Moteur Transit fournit le chiffrement en tant que service sans exposer les clés.

Vous interagissez avec Vault via une interface HTTP ou la CLI. Chaque chemin est régi par des politiques qui déterminent qui peut y lire ou y écrire.

# Enable a KV v2 secrets engine at the 'secret/' path
vault secrets enable -path=secret kv-v2

# Write and read a static secret
vault kv put secret/app/db password='S3cr3t' user='app'
vault kv get secret/app/db

Modèle de scellement et de déscellement

Vault protège ses données grâce à un mécanisme de scellement et de déscellement. Lorsque Vault démarre, il est scellé : il sait où se trouvent les données chiffrées, mais ne peut pas les déchiffrer.

La clé maîtresse qui déchiffre le stockage est elle-même chiffrée par une clé de déscellement. Avec le partage de secret de Shamir, cette clé de déscellement est divisée en plusieurs fragments distribués à différents opérateurs.

Un seuil configurable, par exemple 3 fragments sur 5, doit être fourni pour reconstituer la clé et desceller Vault. Aucune personne ne peut le desceller seule, ce qui protège contre une compromission interne.

# Initialize Vault: 5 key shares, threshold of 3 to unseal
vault operator init -key-shares=5 -key-threshold=3

# Each operator supplies one shard until threshold is met
vault operator unseal <shard-1>
vault operator unseal <shard-2>
vault operator unseal <shard-3>

Authentification : qui êtes-vous ?

Avant de lire un secret, un client doit s’authentifier pour obtenir un jeton. Vault prend en charge de nombreuses méthodes d’authentification adaptées à différentes identités :

  • AppRole pour les applications et les systèmes d’intégration continue, avec un ID de rôle et un ID de secret.
  • Kubernetes utilise le jeton du compte de service du pod.
  • AWS/GCP/Azure IAM fait confiance à l’identité de la plateforme infonuagique.
  • OIDC/LDAP pour les utilisateurs humains via SSO.

Le principe essentiel est le suivant : l’identité provient de la plateforme, et non d’un mot de passe à longue durée de vie. Un pod Kubernetes prouve son identité à l’aide de son propre jeton de compte de service : aucun secret d’amorçage à divulguer.

# App authenticates via AppRole to receive a token
vault write auth/approle/login \
  role_id="db-app-role" \
  secret_id="$WRAPPED_SECRET_ID"
# Response includes client_token used for subsequent reads

Autorisation avec des politiques

L’authentification prouve l’identité ; les politiques déterminent ce que cette identité peut faire. Les politiques Vault sont écrites en HCL et suivent le principe du moindre privilège : elles accordent uniquement les chemins et les capacités dont une charge de travail a besoin.

Cette politique permet à un service de lire uniquement son propre secret de base de données et rien d’autre :

Les capacités correspondent aux verbes de l’interface de programmation : read, create, update, delete et list. Refusez par défaut ; accordez explicitement.

# policy: billing-app.hcl
path "secret/data/billing/*" {
  capabilities = ["read"]
}
path "database/creds/billing-readonly" {
  capabilities = ["read"]
}
# everything else is implicitly denied

Magasins de secrets infonuagiques

Si vous utilisez un seul environnement infonuagique, le gestionnaire de secrets géré par le fournisseur réduit la charge opérationnelle : pas de scellement ni de déscellement, pas de serveurs à maintenir à jour :

  • AWS Secrets Manager s’intègre à IAM et prend en charge des fonctions Lambda de renouvellement intégrées.
  • Azure Key Vault stocke les secrets, les clés et les certificats avec RBAC.
  • GCP Secret Manager fournit des secrets versionnés et protégés par des liaisons IAM.

L’accès est régi par l’IAM de la plateforme infonuagique : une charge de travail lit un secret avec son rôle existant, sans mot de passe distinct. Le compromis est la dépendance au fournisseur et une prise en charge plus faible de plusieurs environnements infonuagiques qu’avec Vault.

# Read a secret from AWS Secrets Manager (workload uses its IAM role)
aws secretsmanager get-secret-value \
  --secret-id prod/billing/db \
  --query SecretString --output text

# GCP equivalent
gcloud secrets versions access latest --secret=billing-db

Chiffrement en tant que service

Parfois, vous ne voulez pas stocker un secret du tout : vous voulez chiffrer les données de l’application sans que votre application ne détienne jamais la clé de chiffrement. Le moteur Transit de Vault fait exactement cela.

L’application envoie du texte en clair à Vault, récupère du texte chiffré et ne voit jamais la clé. Le déchiffrement fonctionne de la même manière. C’est ce qu’on appelle le chiffrement en tant que service.

L’avantage est que les clés ne résident qu’à l’intérieur de Vault, peuvent être renouvelées de manière centralisée et qu’une application compromise ne peut pas divulguer une clé qu’elle n’a jamais possédée.

# Encrypt data without the app ever seeing the key
vault write transit/encrypt/orders-key \
  plaintext=$(echo -n 'card=4111...' | base64)
# returns: ciphertext=vault:v1:abc123...

# Decrypt later
vault write transit/decrypt/orders-key ciphertext='vault:v1:abc123...'

Injecter des secrets dans les charges de travail

Un gestionnaire de secrets n’est utile que si les applications peuvent consommer les secrets sans inscrire en dur le chemin ou le jeton. Voici les méthodes d’injection courantes :

  • Conteneur auxiliaire/agent un agent Vault s’exécute à côté de l’application, s’authentifie et écrit les secrets dans un volume partagé en mémoire.
  • Pilote CSI Kubernetes monte les secrets sous forme de fichiers via le pilote Secrets Store CSI.
  • Récupération via le SDK l’application appelle directement l’interface du gestionnaire au démarrage.

Privilégiez le montage sur un système de fichiers en mémoire (tmpfs) plutôt que l’utilisation de variables d’environnement, et évitez d’écrire les secrets sur le disque, où ils pourraient persister.

# Vault Agent template renders a secret to an in-memory file
template {
  contents = "DB_PASS={{ with secret \"secret/app/db\" }}{{ .Data.data.password }}{{ end }}"
  destination = "/run/secrets/db.env"
}

Journalisation d’audit et responsabilité

Chaque événement de lecture, d’écriture et d’authentification dans un coffre doit être consigné dans un journal d’audit. C’est ce qui permet de justifier la gestion des secrets lors d’un incident.

Les journaux d’audit répondent aux questions essentielles : qui a accédé à quel secret, quand et depuis où. Le coffre hache les valeurs sensibles dans les journaux afin que le journal lui-même ne divulgue pas de secrets.

Transmettez les journaux d’audit à un système séparé et inviolable, dont toute altération est détectable (SIEM), afin qu’un pirate qui compromet l’hôte du coffre ne puisse pas aussi effacer les preuves de ce à quoi il a accédé.

# Enable a file audit device (HMAC-hashes secret values)
vault audit enable file file_path=/var/log/vault/audit.log

# Forward to a SIEM/syslog endpoint for tamper resistance
vault audit enable syslog tag="vault" facility="AUTH"

Protéger le coffre lui-même

Un magasin centralisé concentre le risque : si le coffre tombe, tout tombe. Sécurisez-le comme votre actif le plus critique :

  • Utilisez TLS sur tous les points de terminaison ; n’exposez jamais l’interface de programmation sans chiffrement.
  • Conservez le coffre sur un réseau privé, derrière des règles de pare-feu strictes.
  • Activez le déscellage automatique au moyen d’un KMS infonuagique pour éviter de manipuler manuellement les fragments, mais protégez rigoureusement cette clé KMS.
  • Utilisez des TTL courts pour les jetons et des baux renouvelables afin que les jetons volés expirent rapidement.
  • Appliquez rapidement les correctifs et surveillez les journaux d’audit pour détecter les anomalies.

Le coffre remplace de nombreux points de défaillance par un seul point extrêmement bien protégé.

Choisir le bon magasin

Il n’existe pas d’outil universellement meilleur ; adaptez le magasin à votre environnement :

  • Un seul nuage, besoins simples : utilisez le gestionnaire natif (AWS/Azure/GCP) pour réduire au minimum la charge opérationnelle.
  • Multi-nuage ou sur site : le coffre HashiCorp fournit une abstraction cohérente et portable.
  • Besoin de secrets dynamiques ou de chiffrement en tant que service : les moteurs du coffre sont les plus performants.
  • Environnement fortement basé sur Kubernetes : combinez un magasin avec le pilote CSI ou un opérateur comme Secrets externes.

Quel que soit votre choix, l’objectif reste le même : une source de vérité unique, auditée et contrôlée par les droits d’accès, qui remplace les secrets dispersés en texte clair.

Vérification rapide

Testez votre compréhension du modèle de protection du coffre.

Réponds-y dans la leçon interactive

Récapitulatif&nbsp;: coffres et magasins de secrets

Vous avez appris à remplacer les secrets dispersés par un magasin centralisé et audité.

  • Un magasin de secrets fournit un stockage centralisé, un contrôle des accès, une journalisation d’audit et un chiffrement.
  • Le coffre HashiCorp utilise des moteurs de secrets enfichables et un modèle de scellement/déscellement protégé par le partage de secrets de Shamir.
  • Les méthodes d’authentification déduisent l’identité de la plateforme (Kubernetes, IAM, AppRole), et les politiques imposent le principe du moindre privilège.
  • Les magasins natifs du nuage (AWS, Azure, GCP) privilégient une faible charge opérationnelle au détriment de la portabilité.
  • Le moteur Transit fournit le chiffrement en tant que service afin que les applications ne détiennent jamais les clés.
  • Injectez les secrets au moyen d’agents ou de CSI dans un stockage en mémoire, consignez chaque accès et sécurisez le coffre comme votre actif le plus critique.

Ensuite, nous rendrons les secrets encore plus sûrs en les générant de manière dynamique et en leur donnant une courte durée de vie.

Gratuit pour commencer

Apprends Cyber Security Academy avec un tuteur IA — gratuit

Écris et exécute du vrai code dans ton navigateur, obtiens de l'aide instantanée d'un tuteur IA disponible 24h/24, et reprends là où tu t'es arrêté sur le web ou dans l'app.

Cours
76
Leçons
303
Commencer gratuitementVoir le cours complet

Questions Fréquemment Posées

La leçon « Coffres-forts et magasins de secrets » est-elle gratuite ?

Oui — le texte complet de « Coffres-forts et magasins de secrets » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Cyber Security Academy, passe à CoddyKit PRO. Le cours Cyber Security Academy comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Coffres-forts et magasins de secrets » ?

Centraliser les secrets avec des outils comme Vault. Tu pratiques Cyber Security Academy avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer Cyber Security Academy ?

Aucune expérience préalable n'est requise. Cyber Security Academy sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 2 sur 4.

Combien de temps prend la leçon « Coffres-forts et magasins de secrets » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon Cyber Security Academy ?

Oui. Chaque leçon Cyber Security Academy inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

  1. Le problème de la prolifération des secrets
  2. Coffres-forts et magasins de secrets
  3. Secrets dynamiques et attribution temporaire
  4. Rotation et détection des clés
← Retour à Cyber Security Academy