Best practice gestione password per responsabili IT

Sette misure. Questo è il numero minimo di interventi che un responsabile IT deve completare per portare la gestione delle credenziali aziendali a un livello accettabile di sicurezza, secondo le indicazioni di ENISA e del Garante Privacy. Eccole in ordine di priorità:

• Abilitare MFA su tutti gli accessi critici e integrare SSO dove possibile, riducendo la superficie di attacco senza aumentare il carico sugli utenti.
• Adottare un password manager aziendale approvato e vietare formalmente il riuso delle credenziali tra account diversi.
• Imporre passphrase lunghe (minimo 15 caratteri per autenticazione a singolo fattore) e bloccare le password presenti in liste di compromissione note.
• Introdurre le passkeys sulle applicazioni compatibili e pianificare una roadmap di migrazione graduale.
• Applicare funzioni di hashing resistente (Argon2, bcrypt, PBKDF2) con salt univoco per ogni credenziale, in conformità con le indicazioni del Garante e di ACN.
• Definire e testare il processo di risposta alla compromissione: cambio immediato, revoca token, notifica interna e, se necessario, al Garante.
• Avviare formazione anti-phishing obbligatoria con simulazioni periodiche e istituire audit regolari sulle pratiche di gestione delle credenziali.

Un consiglio: Prima di qualsiasi altra azione, verificate se le credenziali aziendali compaiono in database di violazioni note, usando strumenti come Have I Been Pwned o servizi equivalenti integrati nel vostro password manager. È il punto di partenza più rapido per valutare l’esposizione reale.

Punti chiave

Le best practice di gestione delle password in azienda richiedono l’integrazione di controlli tecnici, governance documentata e formazione continua, con MFA obbligatoria e hashing resistente come misure non negoziabili.

Indice

• Quali criteri definiscono una password forte in contesto aziendale?
• Le passkeys convengono già? Come introdurle in azienda
• Come scegliere e governare un password manager aziendale
• Come implementare l’MFA in modo che funzioni davvero
• Come ridurre il rischio umano: phishing e igiene digitale
• Dispositivi e sessioni: configurazioni che non si possono ignorare
• Risposta alla compromissione: cosa fare nelle prime ore
• Policy aziendale sulle credenziali: contenuto operativo
• Cosa prescrivono ENISA e il Garante sulla conservazione delle password
• Checklist operativa per responsabili IT: implementazione su 90–365 giorni
• Perché le misure tecniche da sole non bastano: il punto di vista di Securityhub
• Securityhub supporta la vostra implementazione dalla policy alla certificazione
• Fonti

Quali criteri definiscono una password forte in contesto aziendale?

Le regole di complessità tradizionali, quelle che impongono maiuscole, numeri e simboli su password di otto caratteri, producono un effetto controproducente: gli utenti le aggirano con pattern prevedibili (“Password1!”) e le riusano su più account. Le linee guida NIST SP 800-63B hanno abbandonato questo approccio: la lunghezza è il parametro che conta, non la composizione forzata.

Parametri minimi raccomandati

• Lunghezza minima: 15 caratteri per autenticazione a singolo fattore; 8 caratteri quando MFA è attiva e obbligatoria.
• Passphrase: quattro o più parole casuali non correlate (“cielo-treno-lampada-fiume”) sono più sicure e più memorabili di “P@ssw0rd2024”.
• Blocklist obbligatoria: ogni nuova password deve essere confrontata con liste di credenziali compromesse (ad esempio il dataset Have I Been Pwned, aggiornato periodicamente) e con un dizionario di password comuni.
• Nessuna scadenza periodica automatica: NIST e ENISA concordano che la rotazione forzata senza motivo specifico incentiva scelte deboli. Il cambio va imposto solo in caso di sospetta compromissione.
• Accettazione di caratteri Unicode e spazi: ampliare il set di caratteri accettati aumenta l’entropia senza richiedere regole aggiuntive.

Come implementare la blocklist tecnicamente

Il validator di password deve interrogare la blocklist in fase di creazione e di modifica. Un approccio pratico prevede l’integrazione di un’API k-anonimato (come quella di Have I Been Pwned) che invia solo i primi cinque caratteri dell’hash SHA-1 della password, senza trasmettere la credenziale in chiaro. Questo schema è compatibile con qualsiasi stack applicativo e non richiede la memorizzazione locale del dataset completo.

Un consiglio: Evitate di comunicare agli utenti quale regola specifica ha rifiutato la loro password. Un messaggio generico (“la password non è accettata, sceglierne un’altra”) non fornisce informazioni utili a un attaccante.

Le passkeys convengono già? Come introdurle in azienda

Una passkey è una coppia di chiavi crittografiche asimmetriche: la chiave privata rimane sul dispositivo dell’utente (protetta da biometria o PIN locale), quella pubblica è registrata sul server. Non esiste una password da trasmettere, da memorizzare sul server o da intercettare. Il risultato pratico è l’eliminazione del phishing delle credenziali per gli account che le adottano.

Quando la migrazione è conveniente

Le passkeys sono mature per il deployment aziendale quando:

• Le applicazioni target supportano WebAuthn/FIDO2 (la maggior parte dei browser moderni e delle piattaforme mobile lo fa nativamente).
• Gli utenti usano dispositivi con autenticazione biometrica integrata (smartphone, laptop con Windows Hello o Touch ID).
• L’infrastruttura IAM supporta la registrazione e la gestione di più autenticatori per account.

Fasi di implementazione

1. Proof of concept (settimane 1–4): selezionate un’applicazione interna a basso rischio, abilitate WebAuthn, registrate un gruppo pilota di 10–20 utenti e misurate il tasso di adozione e i problemi di usabilità.
2. Rollout per gruppi pilota (mesi 2–3): estendete alle applicazioni critiche (VPN, email aziendale, portali cloud), mantenendo la password come fallback autenticato da MFA.
3. Estensione e governance (mesi 4–6): integrate la gestione delle passkeys nel vostro sistema IAM, definite la procedura di revoca in caso di furto dispositivo e aggiornate la policy aziendale.

Il fallback alla password deve restare disponibile solo se protetto da MFA obbligatoria. Un fallback non protetto annulla i vantaggi della passkey.

Un consiglio: Documentate nel vostro IAM quanti autenticatori ha registrato ogni utente. Un account con un solo autenticatore è un rischio operativo: se il dispositivo viene perso, l’utente perde l’accesso. Imponete la registrazione di almeno due autenticatori per gli account privilegiati.

Come scegliere e governare un password manager aziendale

Un password manager aziendale non è solo un vault condiviso: è un sistema di controllo degli accessi alle credenziali. La scelta sbagliata, o una governance assente, trasforma il vault in un singolo punto di fallimento critico.

Requisiti minimi tecnici

• Cifratura end-to-end con chiave derivata dalla master password dell’utente (architettura zero-knowledge): il provider non deve poter accedere ai segreti in chiaro.
• Controllo degli accessi granulare: permessi per cartella, per team, per singola voce; separazione tra lettura, modifica e condivisione.
• Audit trail completo: ogni accesso, modifica, condivisione e cancellazione deve essere registrato con timestamp e identità dell’utente.
• Integrazione SSO e IAM: il login al vault deve passare per il provider di identità aziendale (SAML 2.0 o OIDC), non per una credenziale separata.
• Piani di backup e recovery: definite chi può eseguire il recovery del vault in caso di perdita della master password e come viene autenticato quel processo.

Governance operativa

1. Definite una policy che specifica quali tipologie di segreti possono essere conservate nel vault aziendale (credenziali applicative, chiavi API, certificati) e quali no.
2. Assegnate la proprietà di ogni cartella a un responsabile nominato. Nessuna cartella deve essere “di tutti” senza un owner identificato.
3. Integrate il processo di off-boarding: alla cessazione di un rapporto di lavoro, le credenziali condivise con quell’utente devono essere ruotate entro 24 ore.
4. Per i service account, usate vault separati con accesso limitato al team operativo responsabile e rotazione automatica delle credenziali dove il sistema target lo supporta.

Un consiglio: Vietate esplicitamente i vault personali non approvati (fogli Excel, note sul telefono, gestori del browser non gestiti centralmente). La policy deve elencare gli strumenti approvati e dichiarare non conformi tutti gli altri.

Come implementare l’MFA in modo che funzioni davvero

Dove rendere MFA obbligatoria

• Tutti gli accessi remoti (VPN, desktop remoto, portali cloud).
• Account amministrativi e privilegiati, senza eccezioni.
• Accesso a sistemi che trattano dati personali o sensibili (requisito GDPR).
• Applicazioni SaaS aziendali con accesso a dati critici.

Rollout e gestione delle eccezioni

1. Censite tutti gli account attivi e classificateli per livello di privilegio.
2. Abilitate MFA in modalità “report-only” per due settimane: raccogliete dati su chi non riesce ad autenticarsi e perché.
3. Attivate l’enforcement per gli account privilegiati nella terza settimana.
4. Estendete a tutti gli utenti entro il mese successivo, con un processo di enrollment assistito per chi ha difficoltà.
5. Definite una procedura di recovery sicuro: mai via SMS non verificato, sempre con verifica dell’identità tramite un canale alternativo approvato.

Come ridurre il rischio umano: phishing e igiene digitale

Il phishing rimane il vettore di compromissione delle credenziali più diffuso. Le linee guida ENISA sulle pratiche di sicurezza delle password indicano che i controlli tecnici e i processi di risposta devono affiancare le policy, non sostituirle.

Programma di formazione continua

• Sessioni di formazione obbligatoria almeno due volte l’anno, con contenuti aggiornati alle tecniche di attacco correnti (spear phishing, QR code phishing, attacchi via SMS).
• Simulazioni di phishing mensili o bimestrali con metriche tracciate: tasso di click, tasso di segnalazione, tempo medio tra ricezione e segnalazione.
• Feedback immediato agli utenti che cliccano su un link simulato: un micro-training contestuale è più efficace di una sessione generica successiva.
• Formazione specifica per i ruoli ad alto rischio (finance, HR, dirigenza).

Controlli tecnici complementari

1. Filtraggio email con analisi degli allegati e dei link in sandbox prima della consegna.
2. URL rewriting e ispezione dei link al momento del click (non solo alla ricezione).
3. Blocco automatico degli account dopo un numero definito di tentativi falliti, con alert al team di sicurezza.
4. Procedura di segnalazione rapida: un pulsante “Segnala phishing” nel client email riduce il tempo di risposta e fornisce dati per migliorare i filtri.

La metrica più utile non è il tasso di click sulle simulazioni, ma il tempo medio tra la ricezione di un messaggio sospetto e la sua segnalazione al team di sicurezza. Un tempo di segnalazione sotto i 30 minuti indica una cultura della sicurezza matura.

Dispositivi e sessioni: configurazioni che non si possono ignorare

La sicurezza delle credenziali dipende anche dalla sicurezza del dispositivo su cui vengono usate. Un endpoint non gestito o una sessione mai scaduta annullano qualsiasi politica sulle password.

Configurazioni minime per endpoint

• Blocco schermo automatico dopo breve periodo di inattività, con autenticazione richiesta per lo sblocco.
• Cifratura del disco completa (BitLocker su Windows, FileVault su macOS) abilitata e verificata centralmente.
• Patch management automatico con finestre di manutenzione definite: nessun sistema critico deve rimanere senza aggiornamenti di sicurezza per più di 72 ore dalla disponibilità della patch.

Gestione delle sessioni

1. Timeout di sessione per le applicazioni web previsto in un intervallo limitato di minuti in base alla sensibilità dei dati trattati.
2. Binding della sessione al dispositivo e all’indirizzo IP (dove tecnicamente praticabile) per rilevare session hijacking.
3. Revoca immediata di tutti i token attivi quando un account viene compromesso o un dipendente lascia l’azienda.
4. Logout forzato centralizzato: il sistema IAM deve poter terminare tutte le sessioni attive di un utente in meno di cinque minuti.

BYOD vs dispositivi aziendali

I dispositivi personali non devono mai accedere direttamente ai sistemi aziendali critici senza un livello di segregazione (containerizzazione MDM, VPN con posture check). Per i dispositivi BYOD, definite esplicitamente quali applicazioni e quali dati sono accessibili e con quali controlli.

Un consiglio: Verificate periodicamente l’elenco dei dispositivi registrati nel vostro MDM. I dispositivi non più in uso ma ancora autorizzati sono un vettore di accesso non monitorato.

La revoca delle credenziali deve essere un processo automatizzato, non manuale. Ogni minuto tra la cessazione di un rapporto di lavoro e la disattivazione dell’account è un rischio misurabile.

Risposta alla compromissione: cosa fare nelle prime ore

La velocità di risposta è il fattore che determina l’entità del danno in caso di compromissione delle credenziali. Un playbook definito in anticipo riduce il tempo di reazione da ore a minuti.

Azioni immediate (prima ora)

1. Isolamento dell’account: disabilitate l’account compromesso e revocate tutti i token di sessione attivi.
2. Forzatura MFA: se non già attiva, abilitate MFA obbligatoria prima di qualsiasi ripristino dell’accesso.
3. Reset della password: generate una nuova credenziale temporanea con scadenza immediata, comunicata all’utente tramite un canale alternativo verificato.
4. Analisi dell’accesso: esaminate i log delle ultime 72 ore per identificare quali sistemi sono stati raggiunti con le credenziali compromesse.
5. Notifica interna: avvisate il team di sicurezza, il responsabile dell’utente e il DPO se i dati acceduti includono informazioni personali.

Trigger per escalation

• Account privilegiati o amministrativi: escalation immediata al CISO e al DPO.
• Accesso a dati personali di terzi: valutazione obbligatoria per notifica al Garante entro 72 ore dall’identificazione della violazione (art. 33 GDPR).
• Compromissione di service account: audit completo dei sistemi accessibili con quelle credenziali.

Il provvedimento congiunto Garante–ACN chiarisce gli obblighi di notifica per i soggetti che trattano grandi insiemi di credenziali, inclusi gestori SPID, banche e pubbliche amministrazioni.

Un consiglio: Conservate il playbook di risposta in un sistema accessibile anche quando le credenziali aziendali principali sono compromesse. Un documento salvato solo nel portale aziendale non è raggiungibile se l’account dell’amministratore è bloccato.

Ogni compromissione è anche un’opportunità di audit: documentate cosa ha funzionato e cosa no nel processo di risposta, e aggiornate il playbook entro sette giorni dall’incidente.

Policy aziendale sulle credenziali: contenuto operativo

Una policy sulle password che non specifica chi la fa rispettare e con quali strumenti tecnici è un documento inutile. Il playbook ENISA Secure by Design è esplicito: identità uniche, divieto di account condivisi e gestione delle credenziali per azioni privilegiate non sono raccomandazioni opzionali.

Principi fondamentali da includere nella policy

• Identità uniche: ogni persona fisica o sistema deve avere credenziali proprie. Gli account condivisi sono vietati, salvo eccezioni documentate e approvate.
• Privilegio minimo: ogni account accede solo alle risorse necessarie per il proprio ruolo. I diritti vengono revocati automaticamente al cambio di ruolo o alla cessazione.
• Deny-by-default: l’accesso a qualsiasi risorsa è negato per impostazione predefinita e concesso esplicitamente.
• Session expiry: tutte le sessioni hanno una durata massima definita, indipendentemente dall’attività dell’utente.
• Change-on-compromise: qualsiasi sospetto di compromissione attiva immediatamente il reset delle credenziali, senza attendere conferma.

Ciclo di vita delle credenziali

1. Creazione: generata dal password manager aziendale, mai scelta dall’utente per account di sistema.
2. Assegnazione: comunicata tramite canale cifrato, con obbligo di cambio al primo accesso per gli account utente.
3. Uso: monitorato tramite logging centralizzato; accessi anomali generano alert automatici.
4. Rotazione: solo su compromissione confermata o sospetta, non a scadenza periodica automatica.
5. Cancellazione: disattivazione immediata alla cessazione del rapporto, cancellazione definitiva dopo il periodo di retention definito dalla policy e conforme alle indicazioni del Garante Privacy.

Un consiglio: Inserite nella policy una clausola che definisce esplicitamente le credenziali di default come non conformi. Qualsiasi sistema consegnato con credenziali predefinite deve essere riconfigurato prima della messa in produzione.

La policy sulle password è efficace solo se è tecnicamente enforced. Una regola che dipende esclusivamente dalla buona volontà degli utenti non è una misura di sicurezza: è un auspicio.

Cosa prescrivono ENISA e il Garante sulla conservazione delle password

La conservazione delle password sui sistemi server-side è un’area dove gli errori tecnici hanno conseguenze dirette sulla compliance. Le linee guida del Garante Privacy e di ACN indicano requisiti precisi per chi tratta credenziali di terzi.

Requisiti tecnici essenziali

• Hashing resistente: le password non devono mai essere conservate in chiaro o con algoritmi reversibili (MD5, SHA-1 senza iterazioni sono esplicitamente inadeguati).
• Salt univoco: ogni password deve essere hashata con un salt casuale generato per quell’account specifico, di lunghezza minima 16 byte.
• Key Derivation Function (KDF) memory-hard: Argon2id è la scelta preferita per nuovi sistemi; bcrypt e PBKDF2 sono accettabili con work factor adeguato.
• Work factor incrementabile: la configurazione deve permettere di aumentare il costo computazionale senza invalidare le credenziali esistenti (re-hashing al prossimo login).
• Separazione delle chiavi: le chiavi di cifratura non devono essere conservate nello stesso sistema che contiene gli hash.

Parametri pratici consigliati

Le linee guida ENISA sulle pratiche di base per le password specificano che le organizzazioni devono usare hashing con salt e iterazioni, e non conservare le password in chiaro. Questo requisito si applica sia ai provider di servizi sia alle organizzazioni che gestiscono credenziali interne.

Quando è obbligatoria la notifica al Garante

Una violazione che coinvolge password hashate con algoritmi deboli (MD5, SHA-1 senza salt) è trattata come una violazione di dati in chiaro ai fini della notifica, perché il rischio di cracking è elevato. Se l’algoritmo è adeguato e il salt è corretto, la valutazione del rischio può portare a una notifica interna senza comunicazione agli interessati, ma la documentazione dell’incidente rimane obbligatoria.

Un consiglio: Pianificate il versioning degli algoritmi di hashing nella vostra architettura fin dall’inizio. Aggiornare l’algoritmo su un sistema con milioni di account senza un meccanismo di re-hashing progressivo è un’operazione complessa e rischiosa.

Checklist operativa per responsabili IT: implementazione su 90–365 giorni

L’implementazione delle best practice di gestione delle credenziali non richiede un big bang. Una sequenza strutturata su tre fasi riduce il rischio operativo e permette di misurare i progressi.

Fase 1: priorità alte (giorni 1–90)

1. Censimento completo di tutti gli account attivi, privilegiati e di servizio.
2. Abilitazione MFA obbligatoria per tutti gli account amministrativi e privilegiati.
3. Adozione del password manager aziendale approvato e migrazione delle credenziali critiche.
4. Implementazione della blocklist per le nuove password.
5. Definizione e pubblicazione della policy aziendale sulle credenziali.
6. Prima sessione di formazione anti-phishing obbligatoria per tutti gli utenti.

Fase 2: consolidamento (giorni 91–180)

• Estensione MFA a tutti gli utenti, con processo di enrollment assistito.
• Audit degli account inattivi: disattivazione di tutti gli account non usati da più di 90 giorni.
• Verifica della configurazione di hashing su tutti i sistemi che conservano credenziali.
• Prima simulazione di phishing con metriche tracciate.
• Proof of concept passkeys su almeno un’applicazione interna.

Fase 3: maturità (giorni 181–365)

• Rollout passkeys sulle applicazioni critiche.
• Integrazione completa del password manager con il sistema IAM.
• Revisione annuale della policy e aggiornamento dei parametri di hashing.
• Test del playbook di risposta alla compromissione con un esercizio simulato.
• Audit esterno o assessment di conformità ISO 27001.

Metriche di successo

Un consiglio: Assegnate un owner nominato per ogni KPI. Una metrica senza un responsabile identificato non viene misurata. Inserite i KPI nel report mensile del team di sicurezza.

Le procedure operative per la gestione delle password di Securityhub forniscono template di policy e checklist adattabili alle PMI italiane. Per l’integrazione con i sistemi di identità digitale, la guida pratica per PMI su IAM e SSO offre un percorso strutturato.

Perché le misure tecniche da sole non bastano: il punto di vista di Securityhub

La tentazione più comune nei progetti di sicurezza delle credenziali è concentrarsi sugli strumenti e trascurare la governance. Un password manager installato senza una policy di utilizzo, un sistema MFA abilitato senza procedure di recovery, un sistema di hashing aggiornato senza un piano di versioning: ognuno di questi scenari crea una falsa sensazione di sicurezza più pericolosa dell’assenza dello strumento stesso.

L’esperienza di Securityhub nei progetti di certificazione ISO 27001, ISO 27017 e ISO 27018 mostra un pattern ricorrente: le organizzazioni che affrontano la gestione delle credenziali come un problema tecnico isolato faticano a superare gli audit, perché i controlli tecnici non sono supportati da documentazione, responsabilità chiare e processi di verifica. Quelle che integrano le misure tecniche in un sistema di gestione strutturato, con policy, metriche e revisioni periodiche, ottengono risultati misurabili e sostenibili.

Il riferimento normativo europeo, tra GDPR, indicazioni ENISA e provvedimenti del Garante, non è un ostacolo burocratico: è una mappa che indica esattamente dove concentrare gli sforzi. Le organizzazioni che usano questa mappa come punto di partenza, invece di costruire la propria da zero, riducono i tempi di implementazione e aumentano la probabilità di superare un audit senza rilievi critici.

La priorità non è avere tutto perfetto subito. È avere un sistema che migliora in modo misurabile ogni trimestre, con responsabilità chiare e metriche che permettono di dimostrare il progresso a chi deve prendere decisioni.

Securityhub supporta la vostra implementazione dalla policy alla certificazione

Portare la gestione delle credenziali aziendali agli standard richiesti da ENISA, Garante e ISO 27001 richiede competenze tecniche, documentazione precisa e un metodo di implementazione collaudato. Securityhub affianca le organizzazioni italiane in ogni fase: dall’assessment iniziale delle credenziali e delle configurazioni di hashing, all’implementazione del password manager aziendale e dei programmi MFA, fino al supporto completo per la certificazione ISO 27001 e per gli standard cloud ISO 27017 e ISO 27018.

Il formato di intervento si adatta alle dimensioni e alla maturità dell’organizzazione, offrendo progetti strutturati, servizi gestiti o formazione interna a seconda delle esigenze. Per le PMI, il punto di partenza è spesso un assessment del sistema di gestione della sicurezza che identifica le lacune prioritarie e definisce un piano d’azione concreto. Richiedete un assessment: il team di Securityhub risponde entro un giorno lavorativo.

Fonti

Le fonti primarie da consultare per la compliance e l’approfondimento tecnico:

• Tips for secure user authentication | ENISA
• Conservazione delle password – Garante per la protezione dei dati personali
• Digital Identity Guidelines: Authentication and Authenticator Management (NIST SP 800-63B)

Per le violazioni che coinvolgono dati personali, il DPO deve essere coinvolto immediatamente nella valutazione del rischio. Per incidenti di portata significativa, il riferimento operativo è il CSIRT Italia (Computer Security Incident Response Team nazionale), raggiungibile tramite il sito di ACN.

Raccomandati

• 7 esempi pratici di politiche sicurezza informatica per PMI – Security Hub
• 7 esempi di policy sicurezza essenziali per PMI italiane – Security Hub
• Esempi di misure di sicurezza per PMI: guida 2026 – Security Hub
• Procedure gestione password sicure: Implementa il tuo sistema di sicurezza – Security Hub