Chiffrement de l’espace de travail
Vérifiez le chiffrement applicable à votre version et conservez les clés de récupération des identifiants et du contenu.
Configurer le chiffrement et conserver ses clés
Les options --encryption de l’installateur et du bootstrap décrites ici sont livrées avec l’outillage de cette version. L’installateur et le bootstrap de la v0.11.0 ne les acceptent pas. Le runtime de cette version reconnaît MINDDY_CONTENT_ENCRYPTION_ENABLED ; le service Compose de référence charge le fichier protégé via env_file. Une modification explicite du flag nécessite donc de recréer le service de l’application avec le même environnement, puis de vérifier le schéma et le comportement réel. Une clé MINDDY_DATA_ROOT_KEY générée ne prouve pas que le contenu de l’espace est chiffré. Utilisez un outillage et une configuration correspondants, explicitement vérifiés pour la version choisie, avant d’accueillir des utilisateurs ou de modifier une instance existante.
Les nouvelles installations locales et serveur activent le chiffrement par défaut et génèrent une MINDDY_DATA_ROOT_KEY dédiée. Pour un nouveau serveur, indiquez au besoin --encryption enabled ou --encryption disabled. Les deux choix conservent le chiffrement des identifiants et produisent une racine indépendante ; l’option concerne le contenu de l’espace de travail. Pour le desktop local, préparez la configuration choisie avec la commande ci-dessous avant d’ouvrir le clone. La racine aléatoire de 32 octets est encodée en exactement 64 caractères hexadécimaux et reste hors de PostgreSQL.
pnpm bootstrap:supabase -- --minimal --app-url http://localhost:6463 --encryption enabled
Traiter les données existantes et relances
Une configuration existante sans flag reste désactivée jusqu’à modification volontaire. Les relances conservent flag et racine ; un choix contradictoire échoue. Ne générez jamais une autre clé pour réparer une instance activée : retrouvez l’originale. Appliquez schéma et vérification avant tout import. La maintenance par lots avance la conversion des anciennes données et la rotation ; activer le flag ne prouve pas que tout l’historique ou les copies conservées ont été convertis. Désactiver le flag ne déchiffre pas les données protégées et n’autorise pas l’écriture en clair dans les périmètres activés.
Préserver la récupération
Le serveur déchiffre pour les utilisateurs autorisés et l’IA : il s’agit d’un chiffrement au repos, pas d’un secret de bout en bout face à l’opérateur. Emails de connexion et métadonnées de routage restent lisibles ; fournisseurs externes et exports nécessitent leur propre protection. Gardez racines actuelles et anciennes pour les sauvegardes retenues. Chiffrez et contrôlez l’accès à une sauvegarde contenant configuration et données. Répétez une restauration base plus Storage avec clés correspondantes. Changer de racine impose un réenveloppement hors ligne protégé, applications arrêtées ; remplacer simplement la variable rend le contenu illisible.