Sécurité et serveur multi-utilisateur

Ce chapitre rassemble ce que fait OmniDB pour protéger les identifiants enregistrés et un serveur partagé, multi-utilisateur, et ce que cela implique pour vous en tant qu’administrateur ou utilisateur. Pour installer et exposer le serveur, voir Déployer omnidb-server ; pour la gestion des mots de passe en ligne de commande, voir Outil de configuration OmniDB.

Dans la suite, « mode serveur » désigne omnidb-server démarré sans -A — une instance multi-utilisateur à laquelle on se connecte depuis un navigateur, qu’elle n’écoute que sur la boucle locale ou sur une adresse réseau (-H). L’application de bureau est toujours mono-utilisateur.

Les mots de passe enregistrés sont chiffrés

Les mots de passe de base de données enregistrés dans une connexion, les mots de passe/phrases de passe SSH et les clés privées SSH sont chiffrés (AES-256-GCM) avant d’être écrits dans la base de données utilisateur d’OmniDB, omnidb.db. La clé de chiffrement n’est pas stockée dans ce fichier : elle est conservée dans le magasin de secrets du système d’exploitation — le trousseau macOS (Keychain), le Gestionnaire d’identification Windows ou le Secret Service de Linux — si bien qu’une copie de omnidb.db seule ne permet pas de les révéler.

Lorsqu’aucun magasin de secrets n’est accessible (typiquement sur un serveur Linux sans interface graphique), OmniDB conserve la clé dans un fichier nommé .connection_secret_key (lisible uniquement par son propriétaire), situé dans le répertoire personnel d’OmniDB ; dès que ce fichier existe, il est toujours utilisé. Dans ce cas :

sauvegardez le fichier de clé en même temps que omnidb.db, et protégez-les tous deux de la même façon ;
si la clé est perdue, les secrets stockés ne peuvent pas être récupérés — les connexions existent toujours, mais leurs mots de passe et clés SSH doivent être saisis à nouveau.

Les entrées non chiffrées existantes provenant d’anciennes versions sont chiffrées automatiquement au premier démarrage d’une version plus récente. Si vous préférez ne pas stocker de mot de passe du tout, laissez-le vide dans le formulaire de connexion : OmniDB le demande alors lorsque c’est nécessaire et le conserve uniquement en mémoire, pendant 30 minutes, pour votre session (voir Créer des utilisateurs et des connexions).

Le compte `admin` initial

Une nouvelle installation en mode serveur crée un superutilisateur, admin, avec un mot de passe aléatoire qui est affiché une seule fois dans la sortie de journal du serveur :

omnidb-server: initialized a new app database — initial login: admin / <password> (shown only once; change it under Settings, or run: omnidb-server --set-password admin)

Connectez-vous avec celui-ci et changez-le sous Paramètres > Mot de passe, ou définissez au préalable un mot de passe de votre choix depuis la ligne de commande :

omnidb-server --set-password admin [-d /path/to/homedir]

L’application de bureau n’affiche jamais de page de connexion ; elle se connecte automatiquement à son propre serveur local, limité à la boucle locale.

Protection de la connexion et sessions

Après 10 tentatives de connexion échouées pour le même nom d’utilisateur, ou depuis la même adresse cliente, en 15 minutes, les tentatives suivantes sont refusées avec le message Trop de tentatives de connexion échouées. Veuillez réessayer dans 15 minutes. Les compteurs sont conservés en mémoire et réinitialisés au redémarrage du serveur. Derrière un reverse proxy, l’adresse cliente est celle du proxy.
La suppression d’un utilisateur met fin immédiatement à toutes ses sessions, et le retrait du statut de superutilisateur prend effet immédiatement. Un changement de mot de passe (dans les paramètres ou avec --set-password) s’applique aussitôt aux nouvelles connexions ; un mot de passe changé dans les paramètres déconnecte également les autres sessions de cet utilisateur.

Restrictions en mode serveur

Comme chaque connexion d’un serveur multi-utilisateur est ouverte par le processus serveur, sur la machine serveur, certaines options de connexion qui liraient les propres fichiers du serveur sont restreintes :

Les connexions SQLite (une base de données SQLite est un fichier sur le serveur) ne peuvent être créées et utilisées que par les superutilisateurs d’OmniDB. Elles ne peuvent pas pointer à l’intérieur du répertoire personnel d’OmniDB, et les URI file: sont refusées.
Les chaînes de connexion PostgreSQL ne peuvent pas utiliser les paramètres passfile, servicefile, service, sslkey, sslcert, sslrootcert, sslcrl ni sslcrldir.

Ces restrictions ne s’appliquent pas à l’application de bureau, où les fichiers sont les vôtres.

Connexions publiques

Une connexion marquée Connexion publique ? peut être utilisée par tous les utilisateurs d’OmniDB du serveur, mais seul son propriétaire peut la modifier. Pour tous les autres :

le mot de passe enregistré n’est jamais envoyé à leur navigateur, et un mot de passe intégré à la chaîne de connexion est affiché masqué ;
Tester la connexion teste toujours le serveur, le port et la base de données enregistrés — modifier ces champs dans le formulaire au préalable ne redirige pas le mot de passe enregistré vers une autre destination.

Fichiers exportés

Les exports de requêtes et les exports DBML sont écrits dans le dossier temp du serveur sous des noms aléatoires et ne peuvent être téléchargés que par l’utilisateur qui les a créés. Ils sont supprimés automatiquement au bout de 24 heures.

Clés d’hôte SSH

Les tunnels SSH et les connexions de terminal SSH vérifient la clé d’hôte du serveur par rapport au fichier ~/.ssh/known_hosts de l’utilisateur du système d’exploitation qui exécute omnidb-server. Une clé d’hôte inconnue ou modifiée est refusée — OmniDB ne fait pas confiance silencieusement à un hôte lors de la première connexion. Ajoutez l’hôte une fois depuis ce compte, par exemple :

ssh [email protected]        # accepter la clé une fois
# ou
ssh-keyscan ssh-server.example.com >> ~/.ssh/known_hosts

Exposition réseau

Il n’y a pas de TLS intégré. Gardez omnidb-server sur 127.0.0.1 (la valeur par défaut) derrière un reverse proxy assurant la terminaison TLS plutôt que d’exposer du HTTP en clair avec -H 0.0.0.0 — voir Déployer omnidb-server. Tant qu’il est lié à la boucle locale, le serveur ne répond qu’aux requêtes adressées à 127.0.0.1, localhost ou [::1] avec son propre port, ce qui le protège contre les attaques de DNS rebinding provenant de pages web. Les cookies de session sont marqués Secure lorsque la requête arrive via TLS ou avec X-Forwarded-Proto: https, et toutes les requêtes modifiant l’état sont protégées contre la falsification de requêtes intersites (CSRF).