Inibire l'accesso alle strutture di un DB

di il
5 risposte

Inibire l'accesso alle strutture di un DB

Saluti a tutti e ben trovati
Ho realizzato, soprattutto grazie ai Vs. aiuti, un DB per la gestione di lavorazioni che da diversi anni utilizzo in prima persona e quindi non mi sono mai posto problemi per l'accesso alle strutture del DB.
Adesso dovrei fare usare il DB ad un operatore esterno e desidererei che questo non potesse in alcun modo accedere alle strutture del DB ne tramite il riquadro di spostamento ne in alcun modo, al fine di evitare che erroneamente la persona possa modificare la struttura.
Premetto: 1) Desidererei che il DB sia trasportabile tramite chiavetta USB da un computer ad un altro;
2) Che io possa in qualsiasi momento operare sulle strutture del DB per modifiche e/o aggiornamenti.
Ringrazio fin d'ora per le risposte e Vi saluto cordialmente.

5 Risposte

  • Re: Inibire l'accesso alle strutture di un DB

    Non sono sicuro di darti la risposta più giusta e/o appropriata, ma prova a leggere qui
    https://support.office.com/it-it/article/dividere-un-database-di-access-3015ad18-a3a1-4e9c-a7f3-51b1d73498cc
  • Re: Inibire l'accesso alle strutture di un DB

    Ciao,

    la mia soluzione, molto grossolana e probabilmente non troppo sicura ma che per adesso non mi ha mai lasciato a piedi, è andare a dividere il database in front end e back end (come ti ha consigliato Osvaldo) e poi giocare con le proprietà delle maschere e direttamente di access per il database corrente.
    Altra cosa, proteggere il codice vba, nel caso ne avessi, con password e il gioco è fatto.
    Per riavere i dati, le tabelle le trovi nel back end e la struttura delle maschere la riattivi entrando i modalità debug (shift + doppio click sull'icona)

    Ben lo bloccassi da codice un qualcuno con un minimo di competenza lo bucherebbe in poco. Diciamo che access non è l'applicazione più sicura.

    Se lo dividi in fe e be (front end e back end) il trasporto su chiavetta diventa più difficoltoso. Io l'ho risolta così:
    - aggiungi un'unità di rete sul tuo pc e vai a inserire il be
    - sul db vai a dare la nuova directory per trovare le tabelle (be)
    - sul nuovo pc ri-aggiungi un'unità di rete con lo stesso nome è directory (ma ricordati di aggiornare il be!)
    - ed ecco risolto (non devi tutte le volte andare ad aggiornare la directory)

    buona giornata!
  • Re: Inibire l'accesso alle strutture di un DB

    Ciao e ben trovati,
    ringrazio innanzitutto per le risposte ricevute, mi scuso per il ritardo con il quale riprendo la discussione, ma purtroppo qualche problemino mi ha impedito di farlo.
    Ho provato a dividere il DB come mi avete suggerito, ma al primo utilizzo su un altro computer ho sicuramente combinato dei cas..., meno male che avevo conservato copia credo che non sono proprio riuscito a seguire le indicazioni di Gabry.
    "U fuiri è viriogna ma è sarvamientu ri vita" (la fuga è una vergogna ma certe volte salva la vita).
    Per timore di far danni e non saperli poi recuperare, ho deciso che per proteggere i dati, visto che l'operatore non ha alcun interesse a smanettare, mi accontento di bloccare la barra.
    Ringrazio ancora tutti per le risposte date
  • Re: Inibire l'accesso alle strutture di un DB

    Aggiungo poche cose, ma solo per chiarire aspetti che possono essere mal-interpretati dai suggerimenti che ho letto.

    1) Divisione FE-BE(possibilmente con Password, che ancorchè facilmente bucabile, scoraggia i meno svegli), assolutamente da fare se si lavora in RETE in struttura Client-Server, se invece si lavora in LOCALE e MONUTENZA è suggerito ma non indispensabile.
    2) Se si gestisce FE-BE le Linked TABLE si creano su APERTURA del CLIENT e si DISTRUGGONO su chiusura, NON SI LASCIANO MAI LINKATE.
    Se il BE(Server) cambia di Posto si prevede la possibilità di cercarlo con il FileDialog, e l'inputBox per la Password, altrimenti si può sfruttare il Registry per memorizzare in modo Criptato Connessione e PWD.

    3) Non si mette la PWD sul VBA, si genera una versione Compilata del CLIENT, quindi MDE o ACCDE, in questo modo non sarà più accessibile la modalità Design(Struttura)... ovviamente serve avere consapevolezza di questa cosa, perchè sviluppando a casa e poi trasferendo il CLIENT compilato... potreste avere brutte sorprese, magari nei RIFERIMENTI del VBA...
    4) Si sviluppa in logica LATEBINDING proprio per non avere problemi come da Punto 3.
    5) Disabilitare i Menù NATIVI, si creano Barre Strumenti e Menù Minimal ma personalizzati e controllabili, così anche per i Popup.
    6) Si eliminano tutti i sistemi di FILTRO ed Ordinamento da Menù
    7) SQL INJECTION... questo sconosciuto, metto solo il titolo perchè l'argomento è complesso e sottovalutato.

    Il punto 2 è indispensabile, perchè nonostante tutto la parte Server è debole come protezione e le Password o la Connection string viene salvata in chiaro in una Tabella di SISTEAMA, quindi se non la si cancella leggibile in 1 secondo... questo è il motivo per cui al LOGIN si fa il LINK, ed al LOGOUT il LINK-DESTROY

    Non aggiungo altro direi che questi sono già un passo che non tutti implementano adeguatamente.

    Saluti.
  • Re: Inibire l'accesso alle strutture di un DB

    Grazie per la ulteriore risposta Alex.

    @Alex ha scritto:


    3) Non si mette la PWD sul VBA, si genera una versione Compilata del CLIENT, quindi MDE o ACCDE, in questo modo non sarà più accessibile la modalità Design(Struttura)... ovviamente serve avere consapevolezza di questa cosa, perchè sviluppando a casa e poi trasferendo il CLIENT compilato... potreste avere brutte sorprese, magari nei RIFERIMENTI del VBA...
    La cosa che mi ha fatto cambiare idea sulla divisione del DB è stato proprio il fatto di trovarmi con sorprese, che poi non riesco a risolvere.
    Alla fine si tratta di un DB " Casalingo" per il quale non sono giustificate particolari protezioni. se non quella di errori materiali dell'operatore.
    ringrazio ancora per le risposte e saluto tutti
Devi accedere o registrarti per scrivere nel forum
5 risposte