Aller au contenu principal

Chiffrement de la base de données

Libre WebUI comprend un service de chiffrement au niveau de l’application pour protéger les valeurs sensibles avant leur écriture dans le stockage.

Méthode de chiffrement​

Le serveur dorsal utilise AES-256-GCM par l’intermédiaire du module de cryptographie de Node.js. La clé de chiffrement doit mesurer 32 octets et être représentée par une chaîne hexadécimale de 64 caractères :

ENCRYPTION_KEY=0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef

Générez une clé :

openssl rand -hex 32

Stockage de la clé​

Libre WebUI charge la clé dans l’ordre suivant :

  1. La variable d’environnement ENCRYPTION_KEY.
  2. Un fichier persistant .encryption_key situé dans le DATA_DIR sélectionné.
  3. Uniquement pour un nouveau stockage, une clé nouvellement générée et écrite de façon durable dans DATA_DIR/.encryption_key avant le démarrage de la base de données.

Si l’environnement et le fichier persistant fournissent tous deux une clé, elles doivent être identiques, faute de quoi le démarrage échoue. Un état chiffré existant privé de sa clé d’origine provoque également un échec sécurisé ; Libre ne génère jamais de clé de remplacement pour un stockage existant.

Règles importantes relatives aux clés​

  • Sauvegardez ENCRYPTION_KEY avec la base de données.
  • Ne renouvelez pas la clé sans disposer d’un plan de migration pour les valeurs chiffrées.
  • Si la clé est perdue, les valeurs chiffrées ne peuvent pas être récupérées.
  • Modifier la clé sans rechiffrer les données rendra les valeurs chiffrées existantes illisibles.

Éléments protégés​

Le chiffrement est appliqué par les chemins de code qui utilisent le service de chiffrement ou les fonctions auxiliaires de stockage chiffré. Il est destiné aux valeurs sensibles de l’application, telles que les identifiants et les données privées des utilisateurs traitées par ces fonctions.

Il ne s’agit ni d’un chiffrement complet du disque, ni d’un chiffrement des pages SQLite, ni d’un chiffrement de bout en bout entre les utilisateurs et le navigateur. Utilisez le chiffrement du disque et HTTPS pour ces couches.

Données Work​

Le chiffrement au niveau de l’application ne chiffre pas l’intégralité d’une tâche Work. Les fichiers sources et dépendances du projet Work sont des fichiers ordinaires dans des volumes Docker nommés propres à chaque tâche. Les conversations Work, résultats d’outils, sorties de commandes et métadonnées des tâches sont stockés dans SQLite. Ils ne sont pas automatiquement chiffrés du seul fait que certains chemins de stockage des identifiants utilisent le service de chiffrement.

Si nécessaire, protégez la racine de données Docker et DATA_DIR par des contrôles d’accès et un chiffrement du disque. Sauvegardez ensemble la base de données, ENCRYPTION_KEY et les volumes Work gérés. L’envoi d’une tâche Work à un modèle distant peut également divulguer au fournisseur le contexte de la conversation ainsi que les sorties de fichiers ou de commandes demandées ; le chiffrement du stockage ne modifie pas cette frontière réseau.

Docker et Kubernetes​

Définissez explicitement une clé stable pour la production :

ENCRYPTION_KEY=replace-with-64-hex-characters
DATA_DIR=/data

Montez DATA_DIR sur un stockage persistant. Dans Kubernetes, placez la clé dans un Secret et montez les données sur un PersistentVolume.

Dépannage​

Longueur de clé incorrecte

La clé doit comporter exactement 64 caractères hexadécimaux. Générez-en une nouvelle avec :

openssl rand -hex 32

Impossible de déchiffrer les données après un redéploiement

Vérifiez que la même valeur ENCRYPTION_KEY est utilisée et que le même volume DATA_DIR est monté.

Une nouvelle clé a été générée en développement

Conservez DATA_DIR/.encryption_key avec la base de données. Vous pouvez aussi définir la même valeur dans ENCRYPTION_KEY ; si les deux sources existent, elles doivent correspondre.

Documentation connexe​