Aller au contenu

Modèle de sécurité

Sujet Comment Tenax le traite
Données au repos Chiffrement age côté client de chaque objet de données, vers des destinataires que vous contrôlez. Le bucket et son fournisseur ne voient jamais de texte en clair.
Clés L'identité de sauvegarde (clé privée) n'est lue que par les Jobs de restauration. Gardez-en une copie hors ligne : sans elle, rien ne peut être restauré. Une clé catalogue distincte permet à la console de lire les inventaires et les aperçus masqués, mais pas les dumps ni le WAL (ADR 0009).
Accès aux bases Un utilisateur au moindre privilège par base, jamais un administrateur : il lit les données pour les dumps et réplique pour le flux (Utilisateurs de base de données).
Accès à Kubernetes Lecture des ressources propres à Tenax à l'échelle du cluster ; dans les namespaces cibles, lecture des seuls secrets tenax-*. Les pods tournent sans root, avec un système de fichiers racine en lecture seule et sans capabilities.
Console et API Vérification du JWT Cloudflare Access, quatre rôles (viewer, operator, restorer, restorer-admin), portées org/projet facultatives, et un journal d'audit de chaque écriture et de chaque requête. Les requêtes sont validées par rapport au document OpenAPI.
Bacs à sable Leur propre namespace, une NetworkPolicy, des identifiants générés et un TTL. Exposés uniquement via Cloudflare Tunnel derrière Access, si vous l'activez.
Secrets dans les logs Jamais journalisés : le logger masque les mots de passe, jetons, identités et en-têtes d'autorisation.

La revue complète, points ouverts compris, se trouve dans Revue de sécurité.