FerrVault hérite des contrôles de base de la plateforme FerrLabs. Voir ferrlabs.com/fr/security pour l'identité, l'infrastructure, la divulgation de vulnérabilités et la notification de violation. Les addenda ci-dessous couvrent ce qui est spécifique à un gestionnaire de secrets : comment une valeur passe de votre CLI ou pod, à travers TLS, vers un stockage chiffré par enveloppe, puis ressort sous audit.

Transport

TLS 1.2+ uniquement. Profil Mozilla « Modern » pinné en bord de cluster : suites AEAD uniquement (AES-GCM, ChaCha20-Poly1305), courbes ECDH P-384/P-521, SNI strict. Note SSL Labs A+ à date.
Échange de clés hybride post-quantique. X25519MLKEM768 négocié avec les clients compatibles (Chrome 124+, Firefox 132+, Edge 124+). Défense contre les attaques « harvest now, decrypt later » où un adversaire enregistre le trafic chiffré aujourd'hui pour tenter de le déchiffrer plus tard avec un ordinateur quantique.
HSTS preload sur tous les sous-domaines FerrVault : max-age=31536000; includeSubDomains; preload, plus une redirection 301 sur www.ferrvault.com. Soumis aux listes preload Chrome / Firefox / Edge.
DNS CAA restreint l'émission de certificats à Let's Encrypt uniquement.
Compression de réponse désactivée sur les endpoints de révélation. Supprime le canal latéral théorique BREACH.
HTTP→HTTPS redirection permanente ; l'entrée HTTP ne sert aucun contenu réel.

Stockage et chiffrement

Chiffrement par enveloppe. Chaque version de secret est chiffrée avec une Data Encryption Key (DEK) unique de 256 bits générée par un CSPRNG. La DEK est elle-même enveloppée par une Key Encryption Key (KEK) par-vault détenue hors de la base applicative. Aucune DEK n'est jamais écrite sur disque en clair, et aucune KEK n'est écrite : seul l'identifiant KMS l'est.
AES-256-GCM avec un nonce aléatoire de 96 bits par écriture. Aucun couple (clé, nonce) n'est jamais réutilisé : chaque rotation génère une nouvelle DEK.
KEK gérée par KMS. La production tourne contre HashiCorp Vault Transit ; LocalKMS est explicitement refusé au démarrage quand FERRVAULT_ENVIRONMENT=production.
Rotation de KEK auditable ; les événements de rotation émettent une entrée dédiée kek.rotated.
Chiffrement au repos du volume Postgres sous-jacent.

Autorisation et isolation

Hiérarchie à trois niveaux : Vault → Environnement → Secret. Un token opérateur de staging ne peut littéralement pas déchiffrer un ciphertext de production. Le SAT est lié à un tuple unique (vault, environnement, rôle) et chaque requête SQL est scopée par environment_id.
Rôles RBAC : Viewer (lecture), Writer (lecture + rotation), Admin (complet + grants).
Allowlist IP par SAT. Chaque token de service peut déclarer une liste de CIDR / IP littérales (v4 + v6) en dehors desquels il est rejeté en 403.
Rate-limit par SAT + par IP. 60 requêtes / minute sur chaque axe ; un flood de tokens forgés ne peut pas contourner via rotation de bearer aléatoire.
Les tokens SAT sont hashés avec Argon2id au repos ; la lookup utilise un hash SHA-256 indexé pour rester O(1) sous charge.
L'auth JWT utilise des signatures ed25519 émises par l'IdP central FerrLabs.

Audit

Chaque lecture d'une valeur de secret est journalisée : c'est le produit, et un échec d'insertion d'audit bloque la lecture. Le plaintext ne quitte pas le process si la trace ne peut pas être persistée.
Chaque écriture, restauration de version, changement de grant, rotation de KEK et événement de cycle de vie d'environnement est également enregistré.
Les lignes d'audit portent l'org, le vault, le secret, l'acteur (JWT utilisateur ou ID SAT), l'action et des metadata structurées. Accessibles via l'API et l'UI web sous l'onglet Audit de chaque vault.
Audit anti-falsification (chaîne de hash append-only + export immuable) sur la roadmap.

Headers HTTP de sécurité

Appliqués à chaque réponse api.ferrvault.com, app.ferrvault.com, auth.ferrvault.com et ferrvault.com :

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Content-Security-Policy: frame-ancestors 'none' + X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()
Cross-Origin-Opener-Policy: same-origin
X-DNS-Prefetch-Control: off

Durcissement opérationnel

Plafond strict sur la taille des bodies entrants (1 MiB) : élimine les tentatives d'OOM par POST de taille arbitraire.
SQL entièrement paramétré ; aucune entrée utilisateur n'est jamais concaténée dans une string de requête.
ON DELETE CASCADE sur chaque clé étrangère scopée par vault : aucune référence pendante après suppression de vault ou d'environnement.
Les erreurs base de données sont mappées sur un body générique "Database error occurred" ; l'erreur complète est journalisée côté serveur uniquement.
Images de conteneur pulled depuis ghcr.io/ferrlabs/* ; pods en non-root avec root filesystem en lecture seule.

Ce que nous ne prétendons pas

FerrVault n'est pas encore certifié SOC 2 / ISO 27001. Suivi sur la roadmap compliance FerrLabs.
Aucun pentest externe n'a été conduit à date. Les contrôles ci-dessus sont le résultat d'une revue interne.
Le mTLS pour operator → API et l'audit append-only chaîné par hash sont sur la roadmap mais non shippés à date.

Contact

security@ferrlabs.com | Sécurité plateforme FerrLabs →