Zero trust per accessi aziendali più sicuri

Un account Microsoft 365 compromesso, una VPN configurata anni fa o un portatile non aggiornato possono diventare il punto d’ingresso per bloccare un’intera azienda. Il modello zero trust parte da qui: nessun utente, dispositivo o servizio viene considerato affidabile per default, nemmeno se si trova dentro la rete aziendale.

Per una PMI, non significa acquistare una nuova piattaforma e delegare il problema a un prodotto. Significa rivedere il modo in cui identità, applicazioni, server e dati si scambiano autorizzazioni. L’obiettivo è semplice: ridurre la superficie esposta e limitare i danni quando una credenziale o un dispositivo viene compromesso.

Cos’è il modello zero trust, in pratica

Per anni la sicurezza informatica ha seguito un modello perimetrale: una volta superati firewall, VPN o rete aziendale, l’utente veniva trattato come interno e quindi affidabile. Questo approccio funzionava meglio quando applicazioni, file e persone operavano nello stesso ufficio e sugli stessi sistemi.

Oggi i confini sono molto meno definiti. I dipendenti lavorano da sedi diverse, i software SaaS trattano dati aziendali, fornitori esterni accedono a gestionali e ambienti cloud, mentre applicazioni personalizzate comunicano con API e servizi terzi. In questo contesto, la domanda corretta non è più “questa richiesta arriva dalla rete interna?”, ma “chi sta facendo questa richiesta, da quale dispositivo, verso quale risorsa e con quale autorizzazione?”.

Zero trust non equivale a sfiducia indiscriminata. È un modello di verifica continua. Ogni accesso viene valutato sulla base dell’identità, del ruolo, dello stato del dispositivo, della posizione, del rischio e della risorsa richiesta. Un amministratore che accede al pannello di un server non deve ricevere gli stessi permessi di un operatore che consulta gli ordini nel gestionale.

Il principio operativo può essere sintetizzato in tre regole: verificare esplicitamente ogni richiesta, concedere solo il privilegio necessario e assumere che una violazione possa già essere in corso. La terza è quella che cambia davvero le priorità tecniche: non si progetta soltanto per impedire l’accesso, ma anche per contenerlo.

Perché il perimetro non basta più

Un firewall ben configurato resta necessario, così come segmentazione di rete, antivirus gestiti, backup verificati e aggiornamenti regolari. Ma nessuno di questi controlli è sufficiente se un attaccante utilizza credenziali valide. È una situazione frequente: phishing, password riutilizzate, sessioni rubate o token API esposti in un repository consentono di presentarsi ai sistemi come utenti legittimi.

In un’architettura basata solo sul perimetro, un singolo accesso può aprire molte porte. Un account compromesso può consultare file che non gli servono, collegarsi a servizi interni, raggiungere database o muoversi verso account con privilegi più elevati. Questo movimento laterale è uno dei fattori che trasformano un incidente circoscritto in un fermo operativo esteso.

Il modello zero trust riduce questa possibilità imponendo confini anche all’interno dell’infrastruttura. Un’applicazione web non deve poter accedere liberamente a tutti i database. Un container non deve ereditare privilegi del sistema host. Un utente commerciale non deve avere accesso alle funzioni amministrative di un CRM. Sono separazioni che richiedono progettazione, ma che rendono più difficile sfruttare un singolo punto debole.

Per le PMI il rischio non riguarda solo la riservatezza dei dati. Un ransomware, un e-commerce alterato o un gestionale non disponibile incidono direttamente su vendite, assistenza, logistica e reputazione. La sicurezza va quindi valutata anche come continuità operativa.

Le identità sono il primo controllo

La maggior parte dei progetti di sicurezza dovrebbe iniziare dagli account. Se l’identità non è gestita correttamente, anche i controlli infrastrutturali più avanzati perdono efficacia.

L’autenticazione a più fattori deve essere obbligatoria per email, VPN, pannelli cloud, gestionali, repository di codice e accessi amministrativi. Non basta renderla disponibile: deve essere applicata con criteri coerenti, soprattutto per gli utenti con privilegi elevati. Dove possibile, sono preferibili app di autenticazione, chiavi hardware o passkey rispetto agli SMS.

Il secondo tema è la gestione dei ruoli. Ogni persona dovrebbe ricevere autorizzazioni coerenti con la funzione svolta, non con la comodità del momento. Dare privilegi amministrativi permanenti a chi deve eseguire una singola attività è un errore diffuso. In molti casi è più corretto prevedere accessi temporanei, approvati e tracciati.

Anche gli account tecnici meritano attenzione. API key, credenziali di integrazione, utenze di servizio e token di deploy spesso rimangono attivi senza scadenza e con permessi eccessivi. Devono essere separati dagli account personali, custoditi in sistemi dedicati, ruotati e limitati alle sole risorse necessarie. Inserire una password nel codice sorgente o in un file di configurazione non protetto crea un rischio evitabile.

Zero trust nelle applicazioni e nell’infrastruttura

Applicare zero trust a un’applicazione significa controllare l’autorizzazione lato server a ogni operazione significativa. Nascondere un pulsante nell’interfaccia non è un controllo di sicurezza: un utente può tentare direttamente una chiamata API o manipolare una richiesta. Il backend deve verificare identità, ruolo, contesto e proprietà dei dati richiesti.

In un gestionale multiutente, per esempio, non è sufficiente stabilire che l’utente sia autenticato. Occorre verificare se può visualizzare quel cliente, modificare quell’ordine, esportare quei documenti o accedere a dati di un’altra sede. Questi controlli devono essere parte dell’architettura applicativa, testati e mantenuti durante ogni evoluzione del software.

Sul piano infrastrutturale, il principio si traduce in segmentazione. Database, code, storage, pannelli di amministrazione e ambienti di sviluppo non dovrebbero essere esposti pubblicamente solo perché è più semplice collegarsi. Un database usato da un’applicazione Laravel o Node.js dovrebbe accettare connessioni esclusivamente dai servizi autorizzati, su reti e porte definite.

Docker aiuta a isolare i servizi, ma non garantisce automaticamente una configurazione sicura. Container avviati con privilegi eccessivi, immagini non aggiornate, segreti passati come variabili visibili o volumi condivisi senza criteri possono aggirare il beneficio dell’isolamento. La sicurezza dipende dalla configurazione concreta, dalla gestione delle immagini e dal monitoraggio nel tempo.

Lo stesso vale per Nginx e per i server VPS. Limitare le porte aperte, proteggere gli accessi SSH, applicare aggiornamenti, usare certificati corretti e separare gli ambienti sono attività di base. In un approccio zero trust, però, queste misure vengono collegate a una domanda ulteriore: se un componente viene compromesso, quali altre risorse può raggiungere? La risposta dovrebbe essere: il meno possibile.

Come introdurre zero trust senza bloccare l’operatività

Non esiste una migrazione istantanea, né sarebbe prudente applicare restrizioni generalizzate senza capire come lavorano persone e sistemi. La strada efficace è procedere per priorità, partendo dalle risorse che causerebbero il danno maggiore se compromesse: posta elettronica, amministrazione, dati clienti, repository di codice, backup, e-commerce e gestionali.

Il primo passo è mappare gli accessi reali. Bisogna sapere quali utenti entrano in quali sistemi, quali fornitori dispongono di credenziali, quali integrazioni usano token e quali server comunicano tra loro. Nelle aziende cresciute per stratificazione, questa fotografia rivela spesso account dimenticati, permessi duplicati e servizi raggiungibili senza una ragione operativa.

Segue la definizione di criteri minimi: MFA obbligatoria, account nominativi, revoca immediata degli accessi per chi cambia ruolo o lascia l’azienda, privilegi amministrativi separati dagli account quotidiani e registrazione degli eventi rilevanti. Sono interventi con un buon rapporto tra costo e riduzione del rischio.

Solo dopo ha senso affrontare segmentazione, accesso condizionale, gestione centralizzata dei dispositivi e revisione delle autorizzazioni applicative. La sequenza dipende dall’infrastruttura. Un’azienda che usa soprattutto servizi SaaS avrà priorità diverse rispetto a chi ospita applicazioni proprietarie su VPS e gestisce dati operativi in database interni.

Un aspetto spesso sottovalutato è l’esperienza utente. Un controllo troppo rigido, introdotto senza contesto, spinge le persone a cercare scorciatoie: password condivise, account generici, file copiati su servizi non autorizzati. La sicurezza efficace deve proteggere il lavoro reale, non ignorarlo. Questo richiede procedure chiare, strumenti adeguati e supporto quando un accesso viene bloccato per un motivo legittimo.

Monitoraggio, log e capacità di risposta

Verificare gli accessi non basta se nessuno osserva gli eventi. Un modello zero trust richiede log utili: accessi riusciti e falliti, modifiche ai privilegi, utilizzo di account amministrativi, chiamate API anomale, cambiamenti di configurazione e attività sui backup. I log devono essere conservati in modo affidabile e consultabili durante un incidente.

Non è necessario che una PMI costruisca subito un centro operativo di sicurezza interno. È però necessario definire chi riceve gli alert, quali eventi richiedono intervento e come vengono isolate credenziali o sistemi sospetti. Senza una procedura, anche il miglior avviso resta una notifica ignorata.

La verifica periodica è parte del modello. Nuovi dipendenti, nuovi fornitori, nuove integrazioni e nuove funzionalità applicative modificano il rischio. Un controllo corretto sei mesi fa può non esserlo più dopo una migrazione, un cambio di piattaforma e-commerce o l’apertura di una nuova sede.

Per molte imprese, il valore del zero trust non sta nell’etichetta architetturale. Sta nel sapere che un account compromesso non può diventare automaticamente accesso a tutto il resto. Partire dalle identità, dai privilegi e dai sistemi più critici permette di ottenere risultati concreti senza trasformare la sicurezza in un progetto infinito.