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é.