Proteggere un database Access con password significa applicare la funzione di cifratura prevista da Microsoft per i database desktop in formato .accdb. La keyword proteggere password access viene spesso usata per cercare un semplice “blocco all’apertura”, ma nelle versioni moderne di Access la password del database è collegata alla cifratura del file: Access rende i dati illeggibili ad altri strumenti senza la password e richiede la credenziale per aprire il database.
La procedura è supportata da Access per Microsoft 365 e Access 2024, oltre alle versioni indicate nella documentazione Microsoft. È però importante capire i limiti: la password non sostituisce permessi Windows, controllo degli accessi alla cartella, backup, sicurezza SQL Server o gestione delle identità. Nei database .accdb non esiste la vecchia sicurezza a livello utente come sistema di account interni. Per altri approfondimenti consulta la categoria Guide Access.
Che cosa protegge la password di Access
Microsoft spiega che la funzione di cifratura rende i dati non leggibili da altri strumenti e imposta una password necessaria per usare il database. Questo è diverso dal semplice nascondere il riquadro di spostamento o distribuire un ACCDE.
La protezione interessa il file .accdb. Se qualcuno copia il file, dovrà comunque conoscere la password per aprirlo normalmente. Tuttavia, chi ha già accesso al database aperto può vedere i dati che l’applicazione gli mostra: la password non crea automaticamente ruoli diversi per reparto, utente o tabella.
Prerequisito: formato .accdb
La documentazione Microsoft corrente indica che la funzionalità di cifratura con password descritta si applica ai database in formato .accdb. I vecchi .mdb usano modelli e funzioni storiche differenti. Se gestisci un database legacy, pianifica con attenzione una eventuale conversione e testala prima della produzione.
Non convertire un file critico soltanto per aggiungere una password senza verificare VBA, riferimenti, query, maschere e integrazioni.
Prima di impostare la password: fai backup
Crea una copia completa del database e conservala in una posizione sicura. Se il database è split, salva front-end e back-end. Microsoft raccomanda backup regolari e ricorda che una password dimenticata non può essere recuperata da Microsoft.
Questo significa che il backup deve essere gestito insieme alla password: una copia cifrata senza credenziale valida non è un vero piano di disaster recovery.
Procedura passo passo per impostare la password
1. Chiudi il database. 2. Avvia Access. 3. Vai su File > Apri e seleziona il database. 4. Usa la freccia accanto al pulsante Apri e scegli Apertura esclusiva. 5. Vai su File > Informazioni. 6. Seleziona Crittografa con password. 7. Inserisci la password e ripetila nel campo di verifica. 8. Conferma. 9. Chiudi e riapri il file per verificare la richiesta.
L’apertura esclusiva è necessaria perché Access deve modificare la protezione del file senza altri utenti collegati.
Perché serve l’apertura esclusiva
Se il database è aperto da altri utenti non puoi cambiare in sicurezza la cifratura. In un ambiente multiutente pianifica una finestra di manutenzione. Verifica sessioni RDS, processi Access e file di locking prima di procedere.
Non eliminare il file .laccdb per simulare l’accesso esclusivo mentre utenti sono attivi.
Come scegliere una password forte
La pagina Microsoft consiglia password complesse con lettere maiuscole e minuscole, numeri e simboli. Indica almeno 8 caratteri e suggerisce una passphrase di 14 o più caratteri come scelta preferibile. In un ambiente aziendale applica una policy più rigorosa se necessario.
Evita nomi azienda, date, prodotto, “password123” o sequenze prevedibili. Una passphrase lunga e unica è generalmente più facile da gestire rispetto a una stringa corta e complicata.
Dove conservare la password
Usa un password manager aziendale o un sistema di gestione segreti. Non inserire la password in un file di testo accanto al database, in una nota sul desktop o nel codice VBA distribuito agli utenti.
Definisci chi può recuperarla, come viene ruotata e cosa succede quando cambia il responsabile.
La password non è recuperabile da Microsoft
Questo è uno dei punti più importanti della documentazione ufficiale. Se perdi la password di un database cifrato, Microsoft non può recuperarla e non puoi rimuovere la password senza conoscerla.
Per questo una policy di backup senza gestione delle credenziali è incompleta. Conserva la password in almeno un sistema aziendale affidabile con accessi controllati e procedure di emergenza.
Database split: front-end e back-end
Microsoft descrive una procedura specifica per i database divisi. Se vuoi cifrare l’intera applicazione, devi considerare sia front-end sia back-end. Dopo aver cifrato il back-end, il front-end deve ricollegare le tabelle e Access richiede la password.
La documentazione Microsoft suggerisce: cifrare il back-end; nel front-end eliminare e ricreare i collegamenti alle tabelle inserendo la password; poi cifrare anche il front-end se necessario.
Proteggere soltanto il back-end
In molte applicazioni il dato è il bene principale, quindi la protezione del back-end è prioritaria. Il front-end può essere ACCDE e distribuito localmente. Tuttavia, se la password del back-end deve essere memorizzata nei collegamenti o resa disponibile all’applicazione, valuta attentamente il modello di minaccia.
Una password condivisa da tutti gli utenti non equivale a identità individuali. Se servono ruoli, audit e permessi per utente, SQL Server è spesso più appropriato.
Password e ACCDE
ACCDE riduce la possibilità di modificare codice e oggetti di progettazione, ma non cifra automaticamente i dati. Password/cifratura e ACCDE risolvono problemi diversi. Puoi usare entrambe le misure in una strategia complessiva.
Conserva sempre il sorgente ACCDB protetto. L’ACCDE non deve diventare l’unica copia del progetto.
Password e Access Runtime
Microsoft 365 Access Runtime consente di eseguire applicazioni Access senza la versione completa. Un database cifrato può richiedere la password anche in questo scenario, ma devi progettare l’esperienza utente con attenzione.
Runtime non è una misura di sicurezza primaria. Microsoft specifica che runtime mode limita funzioni di progettazione e navigazione ma non va usato come principale mezzo per proteggere l’applicazione.
Password e cartelle Windows
Anche un database cifrato deve stare in una cartella con permessi corretti. Non concedere accesso al file a chi non ne ha bisogno soltanto perché “tanto c’è la password”. Il principio del privilegio minimo resta valido.
Su un back-end multiutente gli utenti autorizzati devono avere i permessi necessari per il locking e le operazioni previste, ma la condivisione non dovrebbe essere aperta a tutta la rete.
Password e backup
Un backup cifrato conserva la protezione, ma devi conservare anche la credenziale. Se crei backup prima e dopo l’introduzione della password, documenta quali copie sono cifrate e quali no.
Le copie non cifrate precedenti possono diventare il punto debole. Proteggile con permessi, cifratura dello storage o distruzione sicura quando la retention non le richiede più.
Password e OneDrive
Cifrare il file non rende OneDrive adatto a usarlo come back-end Access multiutente. La cifratura risolve l’accesso al contenuto, non i problemi di sincronizzazione e locking.
Per database condivisi usa una condivisione LAN appropriata, RDS o SQL Server.
Password e SQL Server
Se Access è front-end di SQL Server, i dati principali sono nel server e la sicurezza va progettata lì: autenticazione, ruoli, permessi, cifratura connessione e audit. La password dell’ACCDB protegge il front-end locale ma non sostituisce la sicurezza SQL Server.
La guida Access come front-end SQL Server approfondisce l’architettura.
Cosa succede quando apri un database protetto
Access mostra la finestra di richiesta password. Se la password è corretta, il file viene aperto. Se è errata, l’accesso viene negato.
In un’applicazione distribuita assicurati che gli utenti sappiano a chi rivolgersi e non condividano la credenziale attraverso canali non sicuri.
Come cambiare password
La strategia più semplice consiste nel rimuovere la password corrente conoscendola e poi applicarne una nuova, lavorando in esclusiva e seguendo la procedura Microsoft. Prima fai backup.
Se il database è split, pianifica anche il relink delle tabelle e la distribuzione del front-end aggiornato.
Come rimuovere la password
Microsoft indica di aprire il database in modalità esclusiva, andare su File > Informazioni e scegliere Decrittografa database, quindi inserire la password attuale. Questo processo rimuove la cifratura basata sulla password.
Una guida specifica è disponibile nell’articolo successivo della serie.
Errore: non posso aprire in esclusiva
Controlla che nessun utente o processo abbia il file aperto. In rete verifica sessioni e lock. Se hai il front-end aperto con tabelle collegate al back-end, chiudilo prima di tentare di cifrare il back-end.
Non forzare la procedura cancellando lock attivi.
Errore: la password non viene accettata
Verifica tastiera, layout lingua, Bloc Maiusc e caratteri speciali. Assicurati di stare aprendo il file corretto. Se la password è realmente dimenticata, Microsoft non fornisce un recupero.
Evita di caricare database aziendali su servizi online sconosciuti promettendo recupero password: potresti esporre dati sensibili.
Sicurezza a livello utente: attenzione ai vecchi tutorial
Molte guide storiche parlano di utenti e gruppi interni Access. Microsoft chiarisce che la sicurezza a livello utente non è disponibile nel formato .accdb. Non basare un nuovo progetto moderno su procedure pensate per vecchi MDB.
Per ruoli reali valuta Windows/SharePoint/SQL Server o una logica applicativa supportata da un back-end sicuro.
Nascondere il riquadro non equivale a proteggere
Disabilitare il riquadro di spostamento, nascondere ribbon o distribuire Runtime migliora l’esperienza e riduce modifiche accidentali, ma non cifra il database. Tratta queste funzioni come hardening dell’interfaccia.
Proteggere il codice VBA
ACCDE è più utile della sola password dell’editor VBA per distribuire codice compilato. La protezione del progetto VBA nell’editor non deve essere considerata un sistema di cifratura dei dati.
32 e 64 bit
La cifratura con password non dipende dal fatto che Access sia 32 o 64 bit nel senso della forza della password. Tuttavia l’applicazione deve comunque funzionare nell’architettura scelta, con driver e API compatibili.
Microsoft 365 e Access 2024
La pagina Microsoft “Encrypt a database by using a database password” indica esplicitamente Access per Microsoft 365 e Access 2024 tra i prodotti a cui si applica. Questo rende la procedura attuale per le versioni moderne desktop di Access su Windows.
Non inventare una versione Web o Mac equivalente: Access desktop resta un’applicazione Windows.
Checklist prima di proteggere il database
Backup; file .accdb; password manager pronto; utenti disconnessi; accesso esclusivo; front-end/back-end identificati; test di ripristino; procedura di relink; ambiente di test; responsabile credenziali.
Checklist dopo la protezione
Chiudi e riapri; verifica richiesta password; prova maschere e query; verifica tabelle collegate; testa Runtime; controlla backup; aggiorna documentazione; elimina copie temporanee non protette se consentito dalla retention.
Quando la password di Access non basta
Se servono utenti individuali, permessi per tabella, audit robusto, accesso remoto, elevata concorrenza o integrazione aziendale, considera SQL Server. Access può continuare come front-end, mentre il server gestisce sicurezza e dati.
Scenario PMI
Una piccola azienda usa Access per ordini interni. Il back-end è su server LAN e il front-end locale. La password del back-end può aggiungere protezione contro copie casuali del file, ma la cartella deve avere ACL Windows corrette e i backup devono essere cifrati. Se tutti condividono la stessa password, non puoi sapere chi ha effettuato una specifica operazione solo grazie alla password.
Scenario consulente
Se consegni un’app Access a un cliente, non usare una password segreta che solo tu conosci senza un accordo chiaro. Documenta gestione credenziali e consegna in modo sicuro. Il cliente deve poter gestire il proprio disaster recovery.
Scenario dati sensibili
Valuta classificazione dei dati, normativa, cifratura del disco, backup, accessi e logging. La password Access è solo uno strato. Per dati particolarmente sensibili un database server e controlli centralizzati possono essere più adatti.
FAQ
Posso mettere una password a un ACCDB?
Sì. La procedura moderna usa Crittografa con password in apertura esclusiva.
La password cifra davvero il file?
Sì, Microsoft descrive la funzione come cifratura che rende i dati illeggibili ad altri strumenti senza la password.
Posso recuperare una password dimenticata?
No tramite Microsoft. La documentazione ufficiale avverte che non è recuperabile.
Serve Access completo?
Per amministrare e impostare la cifratura è preferibile Access completo. Runtime è destinato all’esecuzione delle applicazioni.
Devo cifrare anche il front-end?
Dipende dal modello di sicurezza. Microsoft descrive come cifrare entrambi in un database split.
La password sostituisce i permessi Windows?
No. Usa entrambi i livelli in modo appropriato.
Conclusione
Proteggere un database Access con password è semplice dal punto di vista operativo ma richiede disciplina nella gestione della credenziale. Apri il file in modalità esclusiva, usa Crittografa con password, scegli una passphrase forte, conserva la password in un sistema sicuro e verifica backup e restore.
La fonte ufficiale è Microsoft Support – Crittografare un database usando una password. Per la manutenzione generale consulta anche backup e ripristino Access. Se il progetto richiede identità e ruoli più granulari, non forzare la password di file oltre il suo scopo: valuta un back-end server.