Finalmente posso dirmi soddisfatto di quanto da me cercato.
Non sono riuscito a bloccare la possibilità di non usare il tasto SHIFT.
Sono però riuscito ad ottenere un file .accde che non permetta l'accesso diretto alle varie tabelle a nessun utente.
Più sotto, nelle mie varie risposte che finalmente sono riuscito a scrivere, spiegherò come.
24/10/2023 - fratac ha scritto:
Non esiste.
Qualsiasi cosa tu ti possa inventare, una volta entrati in access, qualsiasi utente ha eccesso completo.
Ha sì accesso completo alle macro e potrà eliminare i vari elementi (machere, macro, collegamenti alle tabelle, ecc.) ma non potrà modificare i record dalle tabelle collegate in quanto non essendoci la password del collegamento memorizzata, non potrà accedere a nessun dato. Anche le query non funzionerannbo in quanto non avranno accesso alle tabelle su cui fare le elaborazioni. L'importante è non avere tabelle importate o collegate senza password, allora sì avranno accesso completo.
24/10/2023 - By65Franco ha scritto:
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.
Mi definisco smanettone di turno, ma con la mia soluzione non vedo (e spero non ci sia) soluzioni per aggirare l'accesso.
24/10/2023 - oregon ha scritto:
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.
Infatti ho sempre ipotizzato di non usare direttamente Access per i dati ma solamente per le query, le maschere ed i report. Lì sì lo trovo velamente veloce e pratico (sia pe rlo sviluppatore che per l'utente utilizzatore). Di usaro solo come Front-end e non come Back-end.
25/10/2023 - By65Franco ha scritto:
infatti è quello che accennavo… una volta loggato è festa grande ;-)
Penso di essere riuscito ad evitare la festa grande :-)
25/10/2023 - max.riservo ha scritto:
Io, con db accde, gestisco queste proprietà al primo avvio del front-end :
Grazie della lista delle proprietà, vedrò di applicarle anche ai miei prossimi database.
25/10/2023 - max.riservo ha scritto:
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
Per l'accesso ai sorgenti non ho idea, presumo se compilati con .accde, l'unico sistema sia la decompilazione, ma penso che questo lo si ha con tutti i linguaggi di programmazione.
Per il tasto SHIFT, purtroppo confermo che è rimovibile.
25/10/2023 - max.riservo ha scritto:
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.
Per la stringa di connessione non metterei la mano sul fuoco che attraverso un editor esadecimale non riuscirei a vedere la stringa in chiaro…
Meglio usare qualche funzione o concatenazioni di testo per ‘mimetizzare’ la vera stringa.
25/10/2023 - max.riservo ha scritto:
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.
Grazie per l'informazioni dei trigger. Usando un MySql gestito da una ditta esterna, questi erano nascosti e non accessibili e mi ero dimenticato della loro esistenza… Terrò in mente la possibilità di usarli su un nuovo server MySql.
26/10/2023 - @Alex ha scritto:
Come FE credo possa ancora dire al sua in termini di Tempo/Risultati, pur riconoscendo che non è al passo con i tempi ed ha grossi limiti di operatività sulla rappresentazione dei dati e la grafica, se vogliamo entrare nel tecnico anche sulla Sicurezza ci sono più pregiudizi che consapevolezza.
Sono completamente d'accordo su questa affermazione.
26/10/2023 - @Alex ha scritto:
Senza PWD salvate e distruggendo le Linked alla chiusura vorrei qualcuno mi spiegasse tecnicamente in modo chiaro senza tanto fumo, dove è possibile bypassare sicurezze che altri Client sviluppati con linguaggi più evoluti invece non consentono…
Su Microsoft Access semplicemente avviando il database con il tasto SHIFT premuto, si avvia la maschera di autenticazione che avrà il compito di far connettere le tabelle collegate. Poi basta accedere alle varie tabelle dal riquadro di spostamento. Anche se la maschera di autenticazione nascondesse il riquadro di spostamento, basterebbe farlo riapparire premendo F11.
La mia soluzione è quella di verificare la presenza della variabile ‘AllowBypassKey’ e che questa valga ‘False’ prima di inserire le credenziali delle tabelle.
Function GetAllowBypassKey() As Boolean
On Error GoTo GestioneErrore
Dim bAllowBypassKey As Boolean
bAllowBypassKey = CurrentDb.Properties("AllowBypassKey")
GetAllowBypassKey = bAllowBypassKey
Exit Function
GestioneErrore:
GetAllowBypassKey = True
End Function
Al momento dell'inserimento delle credenziali, farò:
Dim bAllowBypassKey As Boolean
bAllowBypassKey = GetAllowBypassKey()
If bAllowBypassKey = False Then
Dim db As Database
Set db = CurrentDb
db.TableDefs("cliente").Connect = "ODBC;DSN=sql204153_1;UID=Sql204153;PWD=74wkxwph3c"
db.TableDefs("cliente").RefreshLink
Else
MsgBox "Spiacente, l'uso del tasto SHIFT non è bloccato!"
End If
Questo su un database .accde e tabelle collegate tramite password non memorizzata in fase di collegamento.
Spero, confido, che questo codice non sia attaccabile,
fatemi sapere cosa ne pensate.