Una politica password e MFA deve stabilire come le persone accedono ai servizi, come recuperano un account e come vengono revocati i privilegi. La lunghezza della password è solo una delle decisioni. Un secondo fattore può perdere efficacia se il servizio di assistenza lo disattiva sulla base di informazioni facilmente reperibili, oppure se un’applicazione mantiene un accesso alternativo meno protetto.
Il documento ANSSI sull’autenticazione multifattore e le password propone una valutazione collegata al contesto d’uso. L’articolo 32 GDPR richiede misure adeguate al rischio: non prescrive una password identica per ogni sistema. Questa guida permette di costruire una policy e collegarla alle impostazioni effettive delle applicazioni.
Preparare una scheda per ogni percorso di accesso
Censite applicazione, utenti, dati accessibili e modalità di autenticazione. Distinguete accesso ordinario, accesso privilegiato, integrazione automatica e procedura di emergenza. Due percorsi verso gli stessi dati possono avere garanzie molto diverse: il portale usa MFA, mentre un vecchio protocollo accetta ancora soltanto una password.
Per ciascun percorso annotate chi gestisce l’identità, dove viene conservata la credenziale e come si interrompe una sessione. Verificate anche gli accessi federati e quelli locali. La disabilitazione nell’identità centrale potrebbe non revocare una chiave applicativa creata in precedenza. Il lavoro si collega alla mappatura dei sistemi, che consente di individuare le dipendenze meno visibili.
L’output iniziale è una tabella con percorso, popolazione, esposizione, misura attiva e lacuna. Usatela per discutere le priorità con i responsabili dei servizi. Un account che gestisce tutti gli utenti merita un trattamento diverso da un accesso limitato a una prenotazione; anche la disponibilità del servizio e le conseguenze di un blocco devono essere considerate.
Scrivere regole comprensibili sulle password
Indicate come generare credenziali robuste, evitare il riutilizzo e custodirle. Un gestore di password può aiutare a utilizzare segreti distinti, ma richiede scelte su recupero, autorizzazioni e condivisione. Non basta distribuirlo: spiegate quali credenziali vi appartengono, come gestire un cambio di ruolo e chi può recuperare un archivio aziendale in caso di assenza.
La soglia minima deve essere definita sulla base del meccanismo completo: tentativi consentiti, esposizione online, presenza di fattori ulteriori e resistenza alla compromissione dell’archivio. Evitate di presentare una cifra come requisito generale del GDPR. Registrate la fonte tecnica scelta e la versione cui si riferisce, perché raccomandazioni di organismi diversi possono adottare ipotesi differenti.
Definite gli eventi che richiedono una sostituzione immediata: sospetta divulgazione, compromissione del servizio, condivisione impropria o uscita di una persona che conosce un segreto comune. Una rotazione periodica indiscriminata non sostituisce questi controlli e può incentivare variazioni prevedibili. Se una regola di rotazione deriva da un vincolo specifico, documentatene origine e ambito.
Scegliere e verificare il secondo fattore
MFA combina fattori di categorie differenti. Valutate resistenza al phishing, facilità di utilizzo, disponibilità dei dispositivi e accessibilità per il personale. La scelta deve tenere conto delle modalità reali di lavoro: assistenza da remoto, assenza di copertura telefonica, dispositivi condivisi o limitazioni nell’uso di telefoni personali.
Per gli accessi più sensibili considerate meccanismi resistenti al phishing e riducete le alternative che permettono di aggirarli. Verificate che l’obbligo copra tutti i gruppi previsti e che l’esenzione abbia una motivazione. Una schermata che mostra «MFA disponibile» non dimostra che ogni accesso la richieda.
La politica di sicurezza informatica dovrebbe stabilire chi approva le eccezioni; la procedura tecnica ne descrive configurazione e riesame. Un’esenzione temporanea deve avere un responsabile, una scadenza e una misura compensativa, soprattutto quando riguarda account amministrativi o accessi dall’esterno.
Progettare il recupero come parte della sicurezza
Elencate le situazioni previste: password dimenticata, dispositivo perso, numero telefonico cambiato, chiave fisica danneggiata, persona non raggiungibile. Per ogni situazione stabilite come verificare l’identità e chi può autorizzare il recupero. Evitate domande le cui risposte siano ricavabili da social network o documenti pubblici.
Il canale di recupero non dovrebbe dipendere esclusivamente dal medesimo account bloccato. Proteggete codici di emergenza e fattori di riserva, limitate chi può consultarli e registrate il loro utilizzo. Se l’assistenza può rimuovere MFA, questa operazione deve essere riconoscibile e sottoposta a controlli coerenti con il rischio.
Una prova utile consiste nel simulare la perdita del fattore con una persona autorizzata e un account di esercitazione. Misurate quali informazioni vengono richieste, chi decide e quali sessioni restano aperte dopo il recupero. L’obiettivo è ottenere un percorso utilizzabile senza creare una scorciatoia sfruttabile da chi impersona un collega.
Separare credenziali umane e segreti applicativi
Le integrazioni possono utilizzare chiavi, certificati o identità di servizio. Non applicate automaticamente le stesse regole delle password personali. Censite proprietario, privilegi, ambiente, luogo di conservazione e procedura di sostituzione di ciascun segreto. Una chiave priva di referente tende a rimanere attiva perché nessuno sa quale processo interromperebbe revocandola.
Evitate segreti nel codice sorgente, nei documenti condivisi e nei log. Per le password gestite da un’applicazione, la conservazione deve utilizzare tecniche appropriate di derivazione e protezione, secondo lo stato dell’arte. La guida alla cifratura e alle chiavi aiuta a distinguere cifratura reversibile e protezione delle password: sono problemi diversi.
Preparate una procedura di rotazione che includa distribuzione del nuovo segreto, verifica del servizio, revoca del precedente e controllo delle copie. Una sostituzione incompleta lascia credenziali valide negli ambienti di sviluppo o nei sistemi di assistenza, anche quando il servizio principale appare aggiornato.
Applicare una traccia di policy
La seguente struttura può essere utilizzata come indice da completare, senza trasformarla in una dichiarazione di conformità precostituita.
| Sezione | Contenuto da decidere |
|---|---|
| Identità | Account personali, gruppi e approvazione iniziale |
| Autenticazione | Metodi ammessi per ciascuna classe di servizio |
| Custodia | Gestore autorizzato e divieti di condivisione |
| Recupero | Verifiche, autorizzazioni e fattori di riserva |
| Privilegi | Separazione degli account amministrativi |
| Eccezioni | Motivazione, compensazioni e scadenza |
| Cessazioni | Revoca di account, sessioni e segreti collegati |
| Verifiche | Campioni, anomalie e responsabilità di correzione |
Accompagnate le regole con istruzioni brevi per gli utenti: come segnalare una richiesta sospetta di autenticazione, come riconoscere il canale di assistenza e cosa fare se hanno comunicato una credenziale. Un messaggio chiaro può ridurre il ritardo tra errore e contenimento, soprattutto quando il dipendente teme conseguenze per aver chiesto aiuto.
Controllare il comportamento effettivo
Verificate utenti ordinari, amministratori, collaboratori e account di emergenza con un campione motivato. Provate un accesso esterno, un dispositivo nuovo, una sessione persistente e il recupero del fattore. Raccogliete evidenze prive di segreti e annotate limiti del campione: un controllo su una sola applicazione non dimostra la copertura dell’intera organizzazione.
I log di sicurezza dovrebbero permettere di ricostruire cambi di fattore, recuperi e modifiche dei privilegi, senza registrare password o codici temporanei. Quando una persona lascia l’organizzazione, controllate anche token, deleghe e account locali; la sola rimozione dalla rubrica non interrompe necessariamente l’accesso.
Infine misurate eccezioni scadute, accessi alternativi ancora presenti, recuperi anomali e account senza proprietario. Per i dispositivi utilizzati in mobilità, coordinate le decisioni con la gestione MDM e privacy. La policy resta efficace se nuove applicazioni e modifiche organizzative riaprono la valutazione, prima che il percorso meno protetto diventi quello ordinario.
Per rendere sostenibile il controllo, assegnate un responsabile anche alle applicazioni acquistate direttamente dalle funzioni aziendali. Un servizio attivato dal marketing o da un singolo reparto può contenere dati personali pur essendo assente dal catalogo informatico. Inserite quindi una domanda sull’autenticazione nel processo di acquisto e richiedete la dimostrazione delle impostazioni prima dell’uso con dati reali. In caso di funzionalità non disponibili nel piano contrattuale scelto, la decisione deve essere esplicita: modificare l’offerta, adottare un controllo alternativo adeguato oppure scegliere un’altra soluzione. Il limite commerciale non elimina il rischio e deve essere visibile a chi autorizza il trattamento.
Esempio di baseline compilata
Per un’organizzazione ipotetica, la policy può scegliere password di almeno 15 caratteri insieme a MFA per gli accessi remoti, consentire almeno 64 caratteri come lunghezza massima accettata, bloccare scelte note come compromesse e limitare i tentativi. La sezione 3.1.1.2 del NIST SP 800-63B-4 prevede 15 caratteri per password usate come unico fattore e consente un minimo di 8 soltanto quando la password è parte di MFA; non prescrive regole arbitrarie di composizione o cambi periodici senza evidenza di compromissione. Si tratta di un riferimento tecnico, non di una soglia imposta dal GDPR o dalla legge italiana.
Nell’esempio, gli amministratori usano un’identità distinta e un fattore resistente al phishing; il recupero richiede verifica dell’identità e autorizzazione registrata. Un’applicazione che accetta meno caratteri entra nel registro delle eccezioni con proprietario, limite e piano di sostituzione. La decisione diventa così una configurazione verificabile, con condizioni precise per i percorsi che non possono ancora rispettarla.