Impedire accesso non autorizzato ai dati delle tabelle

di il
28 risposte

Impedire accesso non autorizzato ai dati delle tabelle

Salve,
sono anni che tento di usare Microsoft Access ma ogni volta, quando valuto il punto sicurezza, mi fermo.
Non ho trovato nessun sistema che blocchi la possibilità di accedere in scrittura a qualsiasi campo di ogni tabella presente nel database Access.

Anche se uso il formato .accde, avviando con il tasto SHIFT premuto posso usare il Riquadro di spostamento ed accedere a ciò che voglio.

Anche se blocco l'uso del tasto SHIFT, posso sbloccarlo in qualsiasi momento.

Anche se non memorizzo la password delle tabelle e la inserisco tramite la chiamata ad una funzione, potrò accedere alle tabelle eseguendo questa funzione dopo aver avviato il database con il tasto SHIFT premuto.

Ho provato sia con tabelle importate che tabelle collegate ad altri database (per esempio ODBC MySql).

Naturalmente posso avere il codice compilato (file .accde) e quindi non accessibile ed il database protetto da password per la sua apertura.
Ma sono mere protezioni: se un utilizzatore lo desidera, potrà accedere a qualsiasi dato anche se non autorizzato e senza lasciare tracce.

Qualsiasi sistema che ho provato si è rilevato inefficace.
Sono arrivato alla conclusione che, per quanto riguarda la sicurezza dell'accesso ai vari dati, i database Microsoft Access possono essere usati solamente da una singola persona.

Spero qualcuno possa dire che mi sbaglio e mi indichi una via per poter essere sicuro che nessuno potrà accedere ai dati delle varie tabelle (avendo comunque l'eventuale password del database).

Grazie.

28 Risposte

  • Re: Impedire accesso non autorizzato ai dati delle tabelle

    Access, che tradotto significa?

  • Re: Impedire accesso non autorizzato ai dati delle tabelle

    24/10/2023 - zio3d ha scritto:


    Ho provato sia con tabelle importate che tabelle collegate ad altri database (per esempio ODBC MySql).

    Naturalmente posso avere il codice compilato (file .accde) e quindi non accessibile ed il database protetto da password per la sua apertura.
    Ma sono mere protezioni: se un utilizzatore lo desidera, potrà accedere a qualsiasi dato anche se non autorizzato e senza lasciare tracce.

    Se l'utilizzatore lo desidera : in che modo può accedere alle tabelle (mi riferisco espressamente a base dati tipo MySQL o equivalente)?

    Se la base dati è MySQL (ma anche SQLServer & company) chi è che deve gestire la sicurezza tramite apposite permissions? Access o l'RDBMS?

    Se colleghi le tabelle dopo il login alla base dati e le scolleghi alla chiusura di Access (e diciamo che il front-end di Access è pure compilato come accde) cosa riesci a fare sulle tabele remote (sempre MySQL o altri RDBMS)? Ovvio che se hai accesso al server di MySQL e ti autentichi come utente tramite un qualsiasi altro client (i.e phpmyadmin) allora puoi fare quello che ti è concesso dalle permissions dell'utente con il quale sei autenticato … ma Access in questo caso non centra nulla.

    Ovviamente se il back-end è Access è possibile che bypassare la sua sicurezza non sia così difficile … per questo esistono le Basi Dati (e tra queste includerci Access è una forzatura) !

  • Re: Impedire accesso non autorizzato ai dati delle tabelle

    Non esiste.

    Qualsiasi cosa tu ti possa inventare, una volta entrati in access, qualsiasi utente ha eccesso completo.

  • Re: Impedire accesso non autorizzato ai dati delle tabelle

    Ciao,

    argomento trattato molteplici volte…. 

    Se trovi lo smanettone di turno, le protezioni al database vengono bypassate … ed in ogni caso, soprattutto con access, una volta che ti sei autenticato è festa grande.

  • Re: Impedire accesso non autorizzato ai dati delle tabelle

    Access non nasce per questo. È uno strumento di produttività personale. Per questo non ha una vera gestione utenti e permission che puoi trovare in un RDBS.

    Addirittura, per potere scrivere e leggere normalmente si ha anche accesso al file con i dati che puoi anche eliminare senza problemi. 

    Se la tua necessità è questa, usa un RDBMS. 

  • Re: Impedire accesso non autorizzato ai dati delle tabelle

    24/10/2023 - oregon ha scritto:


    Access non nasce per questo. È uno strumento di produttività personale. Per questo non ha una vera gestione utenti e permission che puoi trovare in un RDBS.

    Appunto. Access come front-end e back-end ha delle evidenti limitazioni (che poi lasciano il tempo che trovano in ambito db personale o poco più - in fondo il prodotto quello deve/può fare).

    Con Access come front-end e RDBMS come back-end le cose cambiano : l'implementazione delle permissions avviene lato RDBMS quindi l'utente fa quello gli è concesso fare … nulla di più.

  • Re: Impedire accesso non autorizzato ai dati delle tabelle

    24/10/2023 - max.riservo ha scritto:


    Se l'utilizzatore lo desidera : in che modo può accedere alle tabelle (mi riferisco espressamente a base dati tipo MySQL o equivalente)?

    Se la base dati è MySQL (ma anche SQLServer & company) chi è che deve gestire la sicurezza tramite apposite permissions? Access o l'RDBMS?

    Se colleghi le tabelle dopo il login alla base dati e le scolleghi alla chiusura di Access (e diciamo che il front-end di Access è pure compilato come accde) cosa riesci a fare sulle tabele remote (sempre MySQL o altri RDBMS)? Ovvio che se hai accesso al server di MySQL e ti autentichi come utente tramite un qualsiasi altro client (i.e phpmyadmin) allora puoi fare quello che ti è concesso dalle permissions dell'utente con il quale sei autenticato … ma Access in questo caso non centra nulla.

    Ovviamente se il back-end è Access è possibile che bypassare la sua sicurezza non sia così difficile … per questo esistono le Basi Dati (e tra queste includerci Access è una forzatura) !

    Per accedere alle tabelle collegate, basta avviare il database (anche .accde) con il tasto SHIFT premuto ed usare il riquadro di spostamento.

    Se si ha accesso alle tabelle solo dopo il login in quanto solo lì verrà eseguito il codice per la memorizzazione della password, per esempio:

    db.TableDefs("cliente").Connect = "ODBC;DSN=sql204153_1;UID=Sql204153;PWD=74wkxwph3c"

    , si potrà accedere alle tabelle tra il login e la chiusura del database sempre dal riquadro di spostamento.

    A mio avviso l'unica soluzione è rendere invisibile e non apribile il riquadro di spostamento. Se in qualche modo si riesce a non renderlo più visibile, l'utente non sarà più in grado di accedere alle varie tabelle e altri vari strumenti (macro, query, ecc.).

  • Re: Impedire accesso non autorizzato ai dati delle tabelle

    24/10/2023 - max.riservo ha scritto:


    24/10/2023 - oregon ha scritto:


    Access non nasce per questo. È uno strumento di produttività personale. Per questo non ha una vera gestione utenti e permission che puoi trovare in un RDBS.

    Appunto. Access come front-end e back-end ha delle evidenti limitazioni (che poi lasciano il tempo che trovano in ambito db personale o poco più - in fondo il prodotto quello deve/può fare).

    Con Access come front-end e RDBMS come back-end le cose cambiano : l'implementazione delle permissions avviene lato RDBMS quindi l'utente fa quello gli è concesso fare … nulla di più.

    Anche se si gestisse il Granting column level permissions ("https://dev.mysql.com/doc/refman/8.0/en/grant.html#grant-column-privileges") in modo da avere i permessi della singola colonna (campo) assegnati per ogni utente per ogni tabella in modo che sia MySql a gestirli,
    comunque si avranno dei problemi in quanto qualsiasi utente su Access potrà sì accedere solamente ai campi a lui permessi (sempre tramite le tabelle del riquadro di spostamento),
    ma lo potrà fare in modo non controllabile: modifica diretta dei dati sul database senza nessuna possibilità di controllo dei dati inseriti tramite eventi appositi (per esempio before_insert, before_update, ecc.) e quindi neanche la possibilità di salvare il LOG delle modifiche “Chi fa cosa” attraverso l'ausilio di tali eventi.

  • Re: Impedire accesso non autorizzato ai dati delle tabelle

    25/10/2023 - zio3d ha scritto:


    ma lo potrà fare in modo non controllabile: modifica diretta dei dati sul database senza nessuna possibilità di controllo dei dati inseriti tramite eventi appositi (per esempio before_insert, before_update, ecc.) e quindi neanche la possibilità di salvare il LOG delle modifiche “Chi fa cosa” attraverso l'ausilio di tali eventi.

    Ciao,

    infatti è quello che accennavo… una volta loggato è festa grande ;-)

  • Re: Impedire accesso non autorizzato ai dati delle tabelle

    Ricordo un programmino scaricato con modem a 14.4 che dandogli in pasto un file word, excell access, ecc… protetti da password su un amd k6 (se non ricordo male giusto per capire la velocità di elaborazione) con windows 98 in 10 secondi tirava fuori le password e ti chiedeva se rimuoverla o modificarla…

    Fai tu.

  • Re: Impedire accesso non autorizzato ai dati delle tabelle

    25/10/2023 - By65Franco ha scritto:


    Ciao,

    infatti è quello che accennavo… una volta loggato è festa grande ;-)

    È un bel po' che avevo anch'io questa convinzione, ma non volevo crederci.
    Basterebbe che il formato .accde non mostrasse il riquadro di spostamento e non permettesse l'uso dei tasti speciali, tutto si risolverebbe.
    Che si traduce nel bloccare per sempre e che non sia ripristinabile la possibilità di usare il tasto SHIFT al suo avvio combinandolo con la non memorizzazione delle password dei collegamenti delle tabelle in chiaro nel database (questa è cosa che già si può fare).
    Non sarà così possibile accedere in nessun modo alle varie tabelle ed usare così Access in sicurezza con multiutenza (almeno non ho trovato altre scappatoie che potrebbe permettere ciò).

    Ho provato, riuscendovi, a nascondere con VBA il riquadro di spostamento all'avvio della form iniziale in concomitanza con l'inserimento (sempre tramite VBA) delle password dei collegamenti delle tabelle. Però basta la semplice pressione del tasto F11 per farlo riapparire.

    Sono riuscito tramite una macro anche a fare in modo che premendo il tasto F11 non succeda niente, però è facilmente aggirabile semplicemente modificando o eliminando la macro avviando il database con il tasto SHIFT.

    Presumibilmente, quello di permettere anche nei file .accde di poter usare il riquadro di spostamento e poter usare anche il tasto SHIFT è una loro consapevole scelta interna in quanto l'implementazione da parte dei programmatori Microsoft Access per bloccare riquadro di spostamento o l'uso del tasto SHIFT dovrebbe impegnare veramente poco tempo. Anche se non ne capisco il motivo, a parte far andare gli sviluppatori verso altre strade Microsoft (che non so quali siano).

  • Re: Impedire accesso non autorizzato ai dati delle tabelle

    25/10/2023 - sihsandrea ha scritto:


    Ricordo un programmino scaricato con modem a 14.4 che dandogli in pasto un file word, excell access, ecc… protetti da password su un amd k6 (se non ricordo male giusto per capire la velocità di elaborazione) con windows 98 in 10 secondi tirava fuori le password e ti chiedeva se rimuoverla o modificarla…

    Fai tu.

    Si, mi ricordo, ne avevo usato uno anch'io.
    Infatti c'ero rimasto male, mi ero detto: e la sicurezza dov'è?
    Non so se anche allora, ma oggi mi sembra usi la sola forza bruta per il loro recupero.

  • Re: Impedire accesso non autorizzato ai dati delle tabelle

    25/10/2023 - zio3d ha scritto:


    Per accedere alle tabelle collegate, basta avviare il database (anche .accde) con il tasto SHIFT premuto ed usare il riquadro di spostamento.

    Io, con db accde, gestisco queste proprietà al primo avvio del front-end :

        Application.CurrentDb.Properties("AllowFullMenus").Value = False
        Application.CurrentDb.Properties("AllowToolBarChanges").Value = False
        Application.CurrentDb.Properties("AllowBuiltInToolBars").Value = False
    
        Application.CurrentDb.Properties("AllowSpecialKeys").Value = False
    
        '
        ' gestione menù scelta rapida (DX mouse)
        '
        Application.CurrentDb.Properties("AllowShortCutMenus").Value = False
    
        '
        ' permetti interruzione codice con ctrl+break : true/false
        'Application.CurrentDb.Properties("AllowBreakIntoCode").Value = False
    
        '
        ' permetti utilizzo tasto shift all'avvio : proprietà da creare
        ' Application.CurrentDb.Properties("AllowByPassKey").Value = true/false
        Dummy = CreateChangeDbProperty("AllowByPassKey", False)
    
        Application.CurrentDb.Properties.Refresh
    
        '
        ' Non visualizza le icone nel taskbar
        '
        Application.SetOption "ShowWindowsInTaskbar", False

    Dopo l'impostazione di queste proprietà è necessario riavviare l'applicazione.  Non so quanto sia facile accedere al sorgente di Access (accde) e/o quanto sia ancora facile riuscire a riabilitare il tasto shitf … in tutti i casi accetto che sia fattibile (e magari sia anche  facile). Nel caso qualcuno sappia come fare, per ovvi motivi, non lo scriva in questo forum.

    25/10/2023 - zio3d ha scritto:


    Se si ha accesso alle tabelle solo dopo il login in quanto solo lì verrà eseguito il codice per la memorizzazione della password, per esempio:

    db.TableDefs("cliente").Connect = "ODBC;DSN=sql204153_1;UID=Sql204153;PWD=74wkxwph3c"

    , si potrà accedere alle tabelle tra il login e la chiusura del database sempre dal riquadro di spostamento.

    Io ho un form di login dove impostare utente/pwd, dopo creo la connessione alle tabelle tramite l'oggetto Tabledefs (non ho memorizzato la stringa di connessione completa di UID e PWD nel sorgente di Access). Utilizzando Access2013, io non ho trovato il modo di vedere la stringa di connessione completa (ovvero la stringa di connessione è presente ma senza UID e PWD) : non dubito che qualcuno riesca a trovare dove eventualmente UID e PWD siano salvati.

    Ovviamente se riesco ad accedere al progetto Access e riesco ad avere la stringa di connessione posso collegare le tabelle (o trovarle già collegate) poi posso fare quello che mi viene permesso dal RDBMS.

    25/10/2023 - zio3d ha scritto:


    Anche se si gestisse il Granting column level permissions ("https://dev.mysql.com/doc/refman/8.0/en/grant.html#grant-column-privileges") in modo da avere i permessi della singola colonna (campo) assegnati per ogni utente per ogni tabella in modo che sia MySql a gestirli,
    comunque si avranno dei problemi in quanto qualsiasi utente su Access potrà sì accedere solamente ai campi a lui permessi (sempre tramite le tabelle del riquadro di spostamento),
    ma lo potrà fare in modo non controllabile: modifica diretta dei dati sul database senza nessuna possibilità di controllo dei dati inseriti tramite eventi appositi (per esempio before_insert, before_update, ecc.) e quindi neanche la possibilità di salvare il LOG delle modifiche “Chi fa cosa” attraverso l'ausilio di tali eventi.

    Io non sarei così sicuro di quanto scrivi : esistono i trigger sulla modifica dei dati. Io gestisco nelle tabelle, a livello di record, sfruttando i trigger, user e data inserimento, user e data modifica. Certamente si possono implementare gestioni ancora più complesse, però sono gestioni da delegare a MySQL e non ad Access. Ribadisco : se accedi a MySQL tramite phpmyadmin puoi fare le stesse cose che fai con Access (direi anche di più) quindi il problema è il Client (Access/phpmyadmin/etc) oppure è l'insufficiente gestione delle permissions nel server (RDBMS)?

    In merito al LOG di chi fa che cosa credo sia disponibile un modulo apposito di mySQL ma forse non è utilizzabile nella versione community ma solo in quelle enterprise.

  • Re: Impedire accesso non autorizzato ai dati delle tabelle

    25/10/2023 - sihsandrea ha scritto:


    Ricordo un programmino scaricato con modem a 14.4 che dandogli in pasto un file word, excell access, ecc… protetti da password su un amd k6 (se non ricordo male giusto per capire la velocità di elaborazione) con windows 98 in 10 secondi tirava fuori le password e ti chiedeva se rimuoverla o modificarla…

    Fai tu.

    In realtà con A97 bastava aprire con un Editor esadecimale ed andare nel posto giusto e la PWD era in chiaro… oggi è criptata, e, come qualsiasi altro sistema che usa PWD Criptate, quindi credo sia un male comune a tanti… c'è sempre modo di … 

Devi accedere o registrarti per scrivere nel forum
28 risposte