Newsgroup: it.comp.lang.delphi
Titolo: [OT] Firebird 1.5 Protezione DB

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.

 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.


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


 
Ciao.


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.


 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)

 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.


 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