Sicurezza e server multiutente

Questo capitolo raccoglie ciò che OmniDB fa per proteggere le credenziali salvate e un server condiviso multiutente, e che cosa significa per te come amministratore o utente. Per l’installazione e l’esposizione del server vedi Distribuzione di omnidb-server; per la gestione delle password da riga di comando vedi Strumento di configurazione OmniDB.

Di seguito, “modalità server” indica omnidb-server avviato senza -A — un’istanza multiutente a cui le persone accedono da un browser, sia che sia in ascolto solo su loopback sia su un indirizzo di rete (-H). L’app desktop è sempre monoutente.

Le password salvate sono cifrate

Le password dei database salvate in una connessione, le password/passphrase SSH e le chiavi private SSH vengono cifrate (AES-256-GCM) prima di essere scritte nel database utente di OmniDB, omnidb.db. La chiave di cifratura non è memorizzata in quel file: è conservata nell’archivio dei segreti del sistema operativo — il Portachiavi di macOS, Gestione credenziali di Windows o il Secret Service di Linux — quindi una copia del solo omnidb.db non le rivela.

Se non è raggiungibile alcun archivio dei segreti (tipicamente su un server Linux headless), OmniDB conserva invece la chiave in un file chiamato .connection_secret_key (leggibile solo dal proprietario) nella directory home di OmniDB; una volta che quel file esiste, viene sempre usato. In questo caso:

• esegui il backup del file della chiave insieme a omnidb.db e proteggili entrambi allo stesso modo;
• se la chiave va persa, i segreti memorizzati non possono essere recuperati — le connessioni esistono ancora, ma le loro password e chiavi SSH vanno inserite di nuovo.

Le voci non cifrate esistenti delle versioni precedenti vengono cifrate automaticamente al primo avvio di una versione più recente. Se preferisci non memorizzare affatto una password, lasciala vuota nel modulo della connessione: OmniDB la chiederà quando serve e la conserverà solo in memoria, per 30 minuti, per la tua sessione (vedi Creazione di utenti e connessioni).

L’account iniziale admin

Una nuova installazione in modalità server crea un superuser, admin, con una password casuale che viene stampata una sola volta nell’output di log del server:

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)

Accedi con essa e cambiala in Impostazioni > Password, oppure imposta in anticipo una password a tua scelta dalla riga di comando:

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

L’app desktop non mostra mai una pagina di accesso; accede automaticamente al proprio server locale, in ascolto solo su loopback.

Protezione dell’accesso e sessioni

• Dopo 10 tentativi di accesso falliti per lo stesso nome utente, o dallo stesso indirizzo del client, entro 15 minuti, gli ulteriori tentativi vengono rifiutati con Troppi tentativi di accesso non riusciti. Riprova tra 15 minuti. I contatori sono tenuti in memoria e si azzerano al riavvio del server. Dietro un reverse proxy, l’indirizzo del client è quello del proxy.
• L’eliminazione di un utente chiude immediatamente tutte le sue sessioni, e la revoca dello stato di superuser ha effetto immediato. Il cambio di una password (nelle Impostazioni o con --set-password) vale subito per i nuovi accessi; una password cambiata nelle Impostazioni chiude inoltre le altre sessioni di quell’utente.

Restrizioni in modalità server

Poiché ogni connessione di un server multiutente viene aperta dal processo del server, sulla macchina del server, alcune opzioni di connessione che leggerebbero file del server stesso sono limitate:

• Le connessioni SQLite (un database SQLite è un file sul server) possono essere create e usate solo dai superuser di OmniDB. Non possono puntare all’interno della directory home di OmniDB, e gli URI file: vengono rifiutati.
• Le stringhe di connessione PostgreSQL non possono usare i parametri passfile, servicefile, service, sslkey, sslcert, sslrootcert, sslcrl o sslcrldir.

Queste restrizioni non si applicano all’app desktop, dove i file sono i tuoi.

Connessioni pubbliche

Una connessione contrassegnata come Connessione pubblica? può essere usata da ogni utente OmniDB del server, ma solo il suo proprietario può modificarla. Per tutti gli altri:

• la password salvata non viene mai inviata al loro browser, e una password inclusa nella stringa di connessione viene mostrata mascherata;
• Prova connessione verifica sempre il server, la porta e il database memorizzati — modificare prima quei campi nel modulo non reindirizza la password memorizzata altrove.

File esportati

Le esportazioni delle query e le esportazioni DBML vengono scritte nella cartella temp del server con nomi casuali e possono essere scaricate solo dall’utente che le ha create. Vengono eliminate automaticamente dopo 24 ore.

Chiavi host SSH

I tunnel SSH e le connessioni al terminale SSH verificano la chiave host del server rispetto al file ~/.ssh/known_hosts dell’utente del sistema operativo che esegue omnidb-server. Una chiave host sconosciuta o cambiata viene rifiutata — OmniDB non si fida silenziosamente di un host al primo utilizzo. Aggiungi l’host una volta da quell’account, ad esempio:

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

Esposizione in rete

Non c’è TLS integrato. Mantieni omnidb-server su 127.0.0.1 (il valore predefinito) dietro un reverse proxy che termina il TLS, invece di esporre HTTP in chiaro con -H 0.0.0.0 — vedi Distribuzione di omnidb-server. Finché è collegato al loopback, il server risponde solo alle richieste indirizzate a 127.0.0.1, localhost o [::1] con la propria porta, il che lo protegge dagli attacchi di DNS rebinding provenienti da pagine web. I cookie di sessione vengono contrassegnati come Secure quando la richiesta arriva tramite TLS o con X-Forwarded-Proto: https, e tutte le richieste che modificano lo stato sono protette dalla falsificazione di richieste tra siti (CSRF).