[OT] Firebird 1.5 Protezione DB

[Enrico Giudici]

Buongiorno a tutti e già che ci sono ne approfitto per augurare un meraviglioso 2024 a tutti gli iscritti al ng.
Scusate l'off-topic ma non riesco a trovare una soluzione soddisfacente al problema ( anche se poi non so se lo è ).
Mio cognato ( sempre lui ) ha preso accordi con uno studio associato per utilizzare il mio programma, che è quello che mio cognato utilizza da anni.
lasciamo perdere il discorso licenza e quant'altro ma veniamo al dunque; la persona che ha l'accesso al programma e di conseguenza al db ( tramite il programma ) potrebbe in teoria, ma anche nella pratica accedere al db tramite un client qualsiasi ( FlameRobin, IBExpert, etc ) senza passare dal mio programma.
Secondo voi come potrei proteggere l'accesso al db, attualmente l'accesso è sempre con SYSDBA ( user ) e masterkey ( password ), informazioni standard che questa persona può recuperare via internet.
Tutte le tabelle, store procedure sono state create ai tempi con l'utenza di cui sopra.
Ho pensato di creare un nuovo user via SQL ma :
1) come faccio a portare tabelle, store procedure, trigger ed altro sotto questo nuovo user ?
2) Accedendo con SYSDBA l'utente potrebbe vedere tutto anche se gli oggetti sono associati al nuovo user ?
Scusate la prolissità ma volevo essere più chiaro possibile.
Un ringraziamento a tutti.
Ciao da Enrico Giudici c/o Anthelios.

[Luigis]

Il 27/12/2023 17:03, Enrico Giudici ha scritto:
> Secondo voi come potrei proteggere l'accesso al db, attualmente l'accesso è sempre con SYSDBA ( user ) e masterkey ( password ), informazioni standard che questa persona può recuperare via internet.

Chi ha fisicamente il file del database in mano può accedere liberamente
senza alcun limite :(
Puoi provare a crittografare i dati del database

Ciao.

[Enrico Giudici]

Ciao Luigi,
per me sarebbe un lavoro enorme, inoltre accedendo con personalmente con IBExpert non saprei come decriptare le info.
Grazie 1000 per il tuo supporto

[Luigis]

Il 27/12/2023 17:22, Enrico Giudici ha scritto:

> per me sarebbe un lavoro enorme, inoltre accedendo con personalmente con IBExpert non saprei come decriptare le info.
>

Non so aiutarti più di tanto :(
Dalla versione 3 di firebird è supportata la funzionalità di criptare i
dati del database, leggi qui:
<https://www.firebirdsql.org/file/documentation/release_notes/html/en/3_0/rnfb30-security-encryption.html>

Cercando in rete: forse trovi qualche spunto qui (non conosco)
<https://firebird21.wordpress.com/2014/08/28/encriptando-columnas-de-una-tabla/>
e qui:
<https://firebird21.wordpress.com/2014/01/30/un-stored-procedure-para-encriptar-y-desencriptar-datos/>

Ciao.

[ENRICO GIUDICI]

Ciao Luigi,
ho guardato i tuoi link ma purtroppo la strada di crypt dei dati non è percorribile, dovrei rivedere tutte le parti dove accedo al db, un bagno di sangue.
Ho visto che è possibile cambiare la password di SYSDBA, tramite il comando GSEC, ho provato e funziona molto bene, ma ci sarebbe una falla, questa persona, di cui mi sembra molto interessata ai dati di mio cognato, essendo un pò sgamato potrebbe copiarsi il db su una sua macchia e installare sempre sulla stessa Firebird, a questo punto si potrebbe collegare sempre con SYSDBA e masterkey.
La mia idea era quella di creare il nuovo user tramite SQL ( fatto ) ma non so come associare tutti gli oggetti ( table, store procedure, trigger, etc ) al nuovo user, però mi sorge una domandina, ma poi lo user SYSDBA vedrebbe lo stesso tutti gli oggetti dell'altro user ?
Grazie 1000 per tutto.

[Enrico Bianchi]

On 2023-12-27, Enrico Giudici <enrico....@gmail.com> wrote:

> Mio cognato ( sempre lui ) ha preso accordi con uno studio associato per
> utilizzare il mio programma, che è quello che mio cognato utilizza da anni.

In che senso possono usarlo? Gli fornisce un accesso o una copia del
programma? Nel secondo caso, penso che ti convenga sentire un avvocato,
perché mi sembra che ci sia un abuso di diritti

> lasciamo perdere il discorso licenza e quant'altro ma veniamo al dunque; la
> persona che ha l'accesso al programma e di conseguenza al db ( tramite il
> programma ) potrebbe in teoria, ma anche nella pratica accedere al db
> tramite un client qualsiasi ( FlameRobin, IBExpert, etc ) senza passare dal
> mio programma.

Anche qua, dipende da come hanno accesso al programma. Considera comunque che
una "mitigazione" è usare Firebird in modalità client/server, che permette di
avere un margine di controllo sull'accesso al database

> Secondo voi come potrei proteggere l'accesso al db, attualmente l'accesso è
> sempre con SYSDBA ( user ) e masterkey ( password ), informazioni standard
> che questa persona può recuperare via internet.

Ecco, sicuramente un primo punto è cambiare la password di SYSDBA, e
successivamente creare un utente dedicato all'accesso

> Tutte le tabelle, store procedure sono state create ai tempi con l'utenza di
> cui sopra.

Non è un problema, Firebird, come molti database, permette una gestione
multiutente, con grant e revoke appositi.

> Ho pensato di creare un nuovo user via SQL ma :
> 1) come faccio a portare tabelle, store procedure, trigger ed altro sotto
> questo nuovo user ?

Non devi portarle, ma devi dare i giusti grant. Fai riferimento a questo, è
per Firebird 3 ma dovrebbe andare bene anche per 1.5:
https://www.firebirdsql.org/file/documentation/chunk/en/refdocs/fblangref30/fblangref30-security.html

> 2) Accedendo con SYSDBA l'utente potrebbe vedere tutto anche se gli oggetti
> sono associati al nuovo user ?

Sì, perché SYSDBA è l'utente DBA del database, e come tale ha accesso a
tutto. Tieni comunque conto che per come la vedo, il problema è un altro:
questo studio consociato deve accedere a tutti i dati? Se no, il problema
diventa di privacy, e non è banale da risolvere, soprattutto perché tu, da
come ho capito, hai scritto un'applicazione pensata per essere usata da un
singolo utente

Enrico
P.S. un'alternativa per risolvere il problema alla radice è che svuoti le
tabelle e gli dai l'applicazione con un database vuoto con solo le strutture
P.P.S. ti conviene aggiornare Firebird, l'ultima versione è la 4 che porta
parecchie novità (una su tutte, l'aggiunta di funzioni dedicate alla
criptazione dei dati)

[Enrico Giudici]

Ciao Enrico,
intanto ti ringrazio per la risposta e mi scuso per risponderti solo ora ma quest'anno l'influenza mi ha centrato in pieno.

> In che senso possono usarlo? Gli fornisce un accesso o una copia del
> programma? Nel secondo caso, penso che ti convenga sentire un avvocato,
> perché mi sembra che ci sia un abuso di diritti

lo studio in questione, tramite il suo sistemista, accede al server dove è presente il db ed il programma, per cui tutto ok.

> Anche qua, dipende da come hanno accesso al programma. Considera comunque che
> una "mitigazione" è usare Firebird in modalità client/server, che permette di
> avere un margine di controllo sull'accesso al database

Dalla postazione della persona interessata accede al programma che è posto sul server e poi di conseguenza procede all'accesso al db.

> Ecco, sicuramente un primo punto è cambiare la password di SYSDBA, e
> successivamente creare un utente dedicato all'accesso

Ci avevo pensato ma anche cambiando la password di SYSDBA ( come ho già fatto ), questa persona, pensando male, potrebbe copiare il db in locale da lui, installare Firebird e su internet trovare che con SYSDBA e masterkey si può accedere senza problemi.

> Non è un problema, Firebird, come molti database, permette una gestione
> multiutente, con grant e revoke appositi.

Ok, però se creo un nuovo utente e poi il tizio, come già detto sopra accede con SYSDBA vede lo stesso tutto.

> Sì, perché SYSDBA è l'utente DBA del database, e come tale ha accesso a
> tutto. Tieni comunque conto che per come la vedo, il problema è un altro:
> questo studio consociato deve accedere a tutti i dati? Se no, il problema
> diventa di privacy, e non è banale da risolvere, soprattutto perché tu, da
> come ho capito, hai scritto un'applicazione pensata per essere usata da un
> singolo utente

Purtroppo ha l'accesso a tutti i dati contenuti nel db.

> P.S. un'alternativa per risolvere il problema alla radice è che svuoti le
> tabelle e gli dai l'applicazione con un database vuoto con solo le strutture
> P.P.S. ti conviene aggiornare Firebird, l'ultima versione è la 4 che porta
> parecchie novità (una su tutte, l'aggiunta di funzioni dedicate alla
> criptazione dei dati)

Purtroppo non è possibile farlo.
Per il passaggio alla versione 4 mi risulta molto difficoltoso, oltre al tempo che non ho, inoltre i componenti che utilizzo ( FibPlus ) non credo funzionino con la nuova versione di Firebird.

A questo punto spero solo nella buona fede del tizio in questione.

Grazie ancora per tutto il tuo preziosissimo supporto.

[Enrico Bianchi]

On 2024-01-09, Enrico Giudici <enrico....@gmail.com> wrote:

> intanto ti ringrazio per la risposta e mi scuso per risponderti solo ora ma
> quest'anno l'influenza mi ha centrato in pieno.

Va beh, l'influenza è un male inevitabile, ci sta pernsare ad altro

> Dalla postazione della persona interessata accede al programma che è posto
> sul server e poi di conseguenza procede all'accesso al db.

Allora, qua la questione è un po' "particolare", nel senso che mi viene da
dire che tu stia usando Firebird in modalità embedded. Questo perché, se fosse
in modalità client/server, il programma sarebbe distribuito sui client e non
ci sarebbe bisogno di aprirlo direttamente dal server. In questo caso, quello
che puoi fare, è cambiare modalità di accesso (da embedded a client/server),
che ti permette di attivare un server Firebird. Questo ti risolve anche il
punto successivo, ovvero servendo il database tramite client/server, non c'è
bisogno che il file di database sia allegato assieme all'eseguibile del
programma, e quindi solo un sistemista avrebbe accesso al file di database

> Purtroppo ha l'accesso a tutti i dati contenuti nel db.

Questo non è bene, perché ai fini della privacy, ci potrebbero essere problemi

> Per il passaggio alla versione 4 mi risulta molto difficoltoso, oltre al
> tempo che non ho, inoltre i componenti che utilizzo ( FibPlus ) non credo
> funzionino con la nuova versione di Firebird.

A vedere la documentazione dei componenti, dovrebbe bastare cambiare la
stringa di connessione usando i parametri per una connessione di tipo TCP/IP.
Per quanto riguarda il supporto, da quello che leggo nella documentazione è
supportato fino a Firebird 2.0, anche se un tentativo lo farei (tra le issue
vedo che sono citate anche versioni successive alla 2.0)

> A questo punto spero solo nella buona fede del tizio in questione.

Io non ci spererei, perché il problema non è tanto l'accesso ai dati ma la
questione legale che questo comporta. Fossi in te, comincerei a pensare
seriamente a questo aspetto, in quanto è la fonte principale di problemi che
ti devi aspettare

Enrico