Una collaboratrice apre dal portatile di casa il gestionale che contiene fatture e dati dei clienti: la password è corretta, ma il dispositivo potrebbe essere privo di aggiornamenti. Con un approccio zero trust, l’identità da sola di solito non basta, anche se il livello di controllo dipende dal rischio della risorsa e dalle condizioni di accesso.
L’accesso va valutato per ogni risorsa e per ogni richiesta
- Nessuna fiducia implicita: la rete aziendale o una connessione VPN non rendono automaticamente sicura una richiesta.
- Controlli combinati: identità, stato del dispositivo, autorizzazioni e contesto concorrono alla decisione.
- Partenza pragmatica: si può iniziare da un’applicazione sensibile e ampliare i controlli senza bloccare i processi di lavoro.
- Eccezioni visibili: sistemi legacy e account tecnici richiedono regole esplicite, monitoraggio e verifiche periodiche.
La rete interna non basta a rendere affidabile una richiesta
Un tempo, entrare nella rete dell’ufficio poteva sembrare sufficiente. Oggi dati e applicazioni si trovano spesso tra servizi cloud, sedi diverse e dispositivi personali; perciò la posizione di chi si connette dice poco sulla sicurezza della richiesta. Zero trust sposta il controllo sulla singola risorsa: ogni accesso va autorizzato in base a chi lo chiede, da quale dispositivo e in quali condizioni.
Il riferimento architetturale più noto è la NIST SP 800-207, che descrive il modello e i suoi principi. In pratica, l’organizzazione definisce regole per concedere l’accesso necessario a una risorsa, può rivalutarlo durante la sessione e registra gli eventi utili a ricostruire ciò che è successo. La fiducia non deriva dal fatto che una persona si trovi “dentro” la rete aziendale.
Questo non significa chiedere una nuova autenticazione a ogni clic. Una policy può consentire un accesso fluido da un dispositivo gestito e richiedere un controllo aggiuntivo quando cambiano il rischio, la risorsa o il contesto. Il bersaglio è il privilegio eccessivo, quello che permette a un account compromesso di raggiungere molti sistemi senza un altro ostacolo.
Identità, dispositivo e privilegio devono concordare
La collaboratrice dell’esempio iniziale presenta credenziali valide, ma l’azienda deve ancora capire se il suo portatile è aggiornato e se il ruolo richiede davvero l’accesso alle fatture. Io partirei da queste verifiche prima di acquistare un nuovo strumento: senza un elenco affidabile di persone, dispositivi e permessi, anche una piattaforma sofisticata applica regole alla cieca.
Una decisione di accesso può combinare autenticazione multifattore, stato di sicurezza del dispositivo, ruolo dell’utente e sensibilità dell’applicazione. Per gli amministratori, si può aggiungere l’accesso temporaneo: il privilegio elevato viene concesso per l’attività necessaria e poi revocato, invece di restare attivo in permanenza.
La NIST SP 1800-35, guida pratica pubblicata nel 2025, presenta 19 implementazioni di esempio sviluppate con 24 collaboratori. Il dato è utile perché mostra che l’architettura può assumere configurazioni diverse: non esiste un singolo prodotto che, installato da solo, trasformi tutta l’azienda in un ambiente zero trust.
Un accesso bloccato va trattato come un segnale da diagnosticare
Quando una regola ferma un’attività, la reazione più rapida è spesso concedere un’eccezione permanente. È anche il modo più semplice per svuotare la policy. La tabella aiuta a distinguere un problema di identità da un dispositivo non conforme o da un’applicazione che non supporta i controlli moderni.
| Situazione | Probabile causa o effetto | Cosa fare |
|---|---|---|
| Credenziali corrette, ma dispositivo non aggiornato | La policy rileva un endpoint non conforme e può impedirgli l’accesso ai dati sensibili. | Verificare inventario e aggiornamenti; consentire l’accesso solo dopo il ripristino dello stato richiesto. |
| Una persona può consultare archivi non necessari al proprio ruolo | Permessi troppo ampi aumentano l’impatto di un account compromesso. | Rivedere i gruppi e restringere l’autorizzazione alle risorse richieste dal lavoro. |
| Un’applicazione legacy non supporta l’autenticazione moderna | Un blocco immediato può interrompere un processo aziendale; un’eccezione senza scadenza mantiene il rischio. | Isolare l’applicazione, limitare chi può raggiungerla, registrare gli accessi e pianificare una migrazione o un controllo compensativo. |
| Un fornitore accede per manutenzione | Un account esterno permanente può restare utilizzabile oltre l’intervento previsto. | Autorizzare una finestra di accesso circoscritta e revocarla al termine del lavoro. |
Per i sistemi legacy, la gradualità è una scelta operativa, non una scusa per lasciare tutto com’è. Un’eccezione utile ha un responsabile, un perimetro e una data di revisione; se nessuno sa chi l’ha approvata o perché esiste, è diventata un accesso permanente di fatto.
I dati italiani suggeriscono di controllare anche gli account compromessi
Una password rubata può sembrare una richiesta legittima se il sistema controlla soltanto il nome utente. Per questo l’autenticazione forte va collegata a permessi limitati, verifiche sul dispositivo e registrazione degli accessi. La Relazione annuale 2025 dell’Agenzia per la cybersicurezza nazionale riporta 2.729 eventi cyber e 615 incidenti con impatto confermato in Italia nel corso del 2025; l’Agenzia segnala anche 2.457 tentativi di phishing comunicati alle vittime.
Questi numeri descrivono fenomeni diversi: un evento cyber non equivale automaticamente a un incidente con impatto confermato. La distinzione è utile anche per un’impresa: non basta contare gli avvisi, occorre capire quali accessi hanno esposto dati o compromesso account e correggere la regola che ha consentito il passaggio.
Per ridurre l’attrito, conviene sperimentare i controlli su un’applicazione importante ma gestibile, misurando accessi negati, eccezioni aperte e richieste di supporto. Se il personale trova spesso blocchi ingiustificati, la policy va corretta prima di estenderla. La sicurezza perde efficacia quando spinge le persone a cercare scorciatoie.
Il primo passo è proteggere una risorsa che l’azienda non può perdere
Se l’impresa lavora con servizi cloud e dispositivi distribuiti, comincerei dall’applicazione che custodisce i dati più delicati: identificare chi vi accede, rimuovere i permessi superflui e verificare lo stato dei dispositivi. Se invece il processo dipende da software legacy, isolerei prima quel sistema e renderei tracciabili le eccezioni, senza fingere che sia già integrato con controlli moderni.
Questo approccio evita di trasformare la sicurezza in un acquisto di strumenti sovrapposti e aiuta a contenere sprechi di licenze, attività manuali e interruzioni. Una buona architettura zero trust cresce insieme ai processi digitali: ogni nuova regola deve proteggere una risorsa precisa e restare comprensibile a chi la usa.