Sicherheit und Mehrbenutzer-Server

Dieses Kapitel fasst zusammen, was OmniDB zum Schutz gespeicherter Zugangsdaten und eines gemeinsam genutzten Mehrbenutzer-Servers unternimmt und was das für Sie als Administrator oder Benutzer bedeutet. Zur Installation und Veröffentlichung des Servers siehe omnidb-server bereitstellen; zur Passwortverwaltung auf der Kommandozeile siehe OmniDB-Konfigurationstool.

„Server-Modus“ bedeutet im Folgenden omnidb-server, gestartet ohne -A — eine Mehrbenutzer-Instanz, an der man sich über einen Browser anmeldet, unabhängig davon, ob sie nur auf Loopback oder auf einer Netzwerkadresse (-H) lauscht. Die Desktop-App ist immer ein Einzelbenutzer-System.

Gespeicherte Passwörter sind verschlüsselt

In einer Verbindung gespeicherte Datenbankpasswörter, SSH-Passwörter/-Passphrasen und private SSH-Schlüssel werden verschlüsselt (AES-256-GCM), bevor sie in die Benutzerdatenbank von OmniDB, omnidb.db, geschrieben werden. Der Schlüssel liegt nicht in dieser Datei: Er wird im Geheimnisspeicher des Betriebssystems aufbewahrt — im macOS-Schlüsselbund, in der Windows-Anmeldeinformationsverwaltung oder im Linux Secret Service —, sodass eine Kopie von omnidb.db allein sie nicht preisgibt.

Wo kein Geheimnisspeicher erreichbar ist (typischerweise auf einem Linux-Server ohne grafische Oberfläche), legt OmniDB den Schlüssel stattdessen in einer Datei namens .connection_secret_key (nur für den Eigentümer lesbar) im OmniDB-Home-Verzeichnis ab; sobald diese Datei existiert, wird sie immer verwendet. In diesem Fall gilt:

Sichern Sie die Schlüsseldatei zusammen mit omnidb.db und schützen Sie beide gleichermaßen;
geht der Schlüssel verloren, lassen sich die gespeicherten Geheimnisse nicht wiederherstellen — die Verbindungen existieren weiterhin, aber ihre Passwörter und SSH-Schlüssel müssen erneut eingegeben werden.

Vorhandene unverschlüsselte Einträge aus älteren Versionen werden beim ersten Start einer neueren Version automatisch verschlüsselt. Wenn Sie ein Passwort lieber gar nicht speichern möchten, lassen Sie es im Verbindungsformular leer: OmniDB fragt dann bei Bedarf danach und hält es nur im Arbeitsspeicher, für 30 Minuten, für Ihre Sitzung (siehe Benutzer und Verbindungen erstellen).

Das anfängliche Konto `admin`

Eine neue Installation im Server-Modus legt einen Superuser admin mit einem Zufallspasswort an, das einmalig in die Log-Ausgabe des Servers geschrieben wird:

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)

Melden Sie sich damit an und ändern Sie es unter Einstellungen > Passwort, oder legen Sie vorab auf der Kommandozeile ein Passwort Ihrer Wahl fest:

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

Die Desktop-App zeigt nie eine Anmeldeseite; sie meldet sich automatisch an ihrem eigenen lokalen, nur auf Loopback lauschenden Server an.

Anmeldeschutz und Sitzungen

Nach 10 fehlgeschlagenen Anmeldeversuchen für denselben Benutzernamen oder von derselben Client-Adresse innerhalb von 15 Minuten werden weitere Versuche mit Zu viele fehlgeschlagene Anmeldeversuche. Bitte versuchen Sie es in 15 Minuten erneut. abgewiesen. Die Zähler werden im Arbeitsspeicher gehalten und beim Neustart des Servers zurückgesetzt. Hinter einem Reverse Proxy ist die Client-Adresse die des Proxys.
Das Löschen eines Benutzers beendet sofort alle seine Sitzungen, und das Entziehen des Superuser-Status wirkt sofort. Eine Passwortänderung (in den Einstellungen oder mit --set-password) gilt sofort für neue Anmeldungen; ein in den Einstellungen geändertes Passwort meldet zusätzlich die anderen Sitzungen dieses Benutzers ab.

Einschränkungen im Server-Modus

Da jede Verbindung eines Mehrbenutzer-Servers vom Serverprozess auf dem Serverrechner geöffnet wird, sind einige Verbindungsoptionen eingeschränkt, mit denen sich eigene Dateien des Servers lesen ließen:

SQLite-Verbindungen (eine SQLite-Datenbank ist eine Datei auf dem Server) können nur von OmniDB-Superusern angelegt und verwendet werden. Sie dürfen nicht in das eigene Home-Verzeichnis von OmniDB zeigen, und file:-URIs werden abgelehnt.
PostgreSQL-Verbindungszeichenfolgen dürfen die Parameter passfile, servicefile, service, sslkey, sslcert, sslrootcert, sslcrl und sslcrldir nicht verwenden.

Für die Desktop-App gelten diese Einschränkungen nicht, dort sind die Dateien Ihre eigenen.

Öffentliche Verbindungen

Eine als Öffentliche Verbindung? markierte Verbindung kann von jedem OmniDB-Benutzer auf dem Server verwendet, aber nur von ihrem Eigentümer bearbeitet werden. Für alle anderen gilt:

Das gespeicherte Passwort wird nie an ihren Browser gesendet, und ein in der Verbindungszeichenfolge eingebettetes Passwort wird maskiert angezeigt;
Verbindung testen prüft immer den gespeicherten Server, Port und die gespeicherte Datenbank — wer diese Felder zuvor im Formular ändert, lenkt das gespeicherte Passwort damit nicht an ein anderes Ziel um.

Exportierte Dateien

Abfrage-Exporte und DBML-Exporte werden unter zufälligen Namen in den Ordner temp des Servers geschrieben und können nur von dem Benutzer heruntergeladen werden, der sie erstellt hat. Sie werden nach 24 Stunden automatisch gelöscht.

SSH-Hostschlüssel

SSH-Tunnel und SSH-Terminalverbindungen prüfen den Hostschlüssel des Servers gegen die Datei ~/.ssh/known_hosts des Betriebssystembenutzers, unter dem omnidb-server läuft. Ein unbekannter oder geänderter Hostschlüssel wird abgelehnt — OmniDB vertraut einem Host beim ersten Kontakt nicht stillschweigend. Fügen Sie den Host einmalig von diesem Konto aus hinzu, zum Beispiel:

ssh [email protected]        # accept the key once
# or
ssh-keyscan ssh-server.example.com >> ~/.ssh/known_hosts

Netzwerkzugriff

Es gibt kein eingebautes TLS. Lassen Sie omnidb-server auf 127.0.0.1 (der Voreinstellung) hinter einem TLS-terminierenden Reverse Proxy laufen, statt einfaches HTTP mit -H 0.0.0.0 zu veröffentlichen — siehe omnidb-server bereitstellen. Solange der Server an Loopback gebunden ist, beantwortet er nur Anfragen, die an 127.0.0.1, localhost oder [::1] mit seinem eigenen Port gerichtet sind, was ihn vor DNS-Rebinding-Angriffen aus Webseiten schützt. Sitzungs-Cookies werden als Secure markiert, wenn die Anfrage über TLS oder mit X-Forwarded-Proto: https eintrifft, und alle zustandsändernden Anfragen sind gegen Cross-Site Request Forgery geschützt.