I motivi a favore del modello “Zero Trust” a livello locale

Di Sarang Warudkar - Responsabile tecnico senior PMM

13 novembre 2026 5 minuti di lettura

L'intelligenza artificiale è entrata a far parte della vostra rete. Il vostro SSE no.

L’approccio “zero trust” ha preso piede in modo significativo quando i lavoratori sono passati al telelavoro e le applicazioni sono state trasferite nel cloud. I Cloud Access Security Broker (CASB) e, successivamente, i mercati più ampi dell’ Security Service Edge (SSE) e del Secure Access Service Edge (SASE) hanno registrato una rapida crescita poiché rispondevano al rischio del momento: un malintenzionato in possesso di credenziali rubate in grado di accedere alle risorse cloud aziendali da qualsiasi luogo. Zero Trust Network Access (ZTNA) si è affermato allo stesso modo, quando i fornitori di soluzioni SSE hanno esteso le proprie piattaforme cloud per offrire un’alternativa più economica e meno vulnerabile alla VPN. Il principio era corretto e lo è tuttora: verificare l’utente, il dispositivo, la posizione e il contesto circostante, anziché affidarsi esclusivamente alle credenziali.

Ciò che è cambiato non è il principio, bensì il luogo in cui si svolge il lavoro.

Perché il lavoro è tornato all’interno

Quattro cambiamenti hanno determinato il ritorno di una quota sempre maggiore dell’attività aziendale sulle reti private.

1. I dipendenti sono tornati in ufficio. Secondo un sondaggio Gallup del maggio 2026, il 74% dei dipendenti lavora in ufficio o in modalità ibrida, di cui il 22% in sede a tempo pieno e il 52% in modalità ibrida per 2,3 giorni alla settimana. Oggi, più che in qualsiasi altro momento dal 2019, le sessioni aziendali iniziano e terminano sulla stessa rete aziendale.
2. L’IA li ha seguiti nell’infrastruttura aziendale. L’IA si è trasferita nell’infrastruttura aziendale poiché l’aumento dei costi dei token, le questioni relative al controllo e le preoccupazioni in materia di privacy dei dati spingono i carichi di lavoro verso l’interno. Quando un modello di IA viene addestrato su dati interni, quali quelli relativi alla ricerca e sviluppo, alla logica di determinazione dei prezzi e ai dati dei clienti, esso assorbe la proprietà intellettuale fondamentale dell’azienda e diventa di fatto una copia operativa dei suoi segreti commerciali. Poiché i consigli di amministrazione non sono disposti a lasciare tali risorse su server di terze parti, l’esecuzione di modelli privati e strumenti di IA interni all’interno di data center privati è ormai una pratica standard.
3. Gran parte delle azioni intraprese da questi sistemi non supera mai il perimetro. Gartner inserisce dati proprietari in 1 su 6 prompt di IA (Minaccia alla sicurezza informatica: compromissione delle applicazioni di IA, 2026), e tale proporzione non migliora affatto quando il modello è interno anziché pubblico. Un copilota interno non ha nulla da sottrarre. Accede all’archivio dei documenti, al sistema di ticket e al database dei clienti, poiché è proprio per questo che è stato progettato. Un agente a cui viene affidato un compito dispone di credenziali permanenti e agisce molto più rapidamente rispetto alla persona che lo ha autorizzato, nei confronti dei sistemi presenti nel proprio segmento di rete.
4. Anche la sovranità riporta in auge il modello operativo. Gartner prevede che entro il 2028 il 50% delle multinazionali, e oltre il 75% delle multinazionali non statunitensi, avrà requisiti di sovranità digitale (Analisi delle previsioni: Sovereign Cloud IaaS, a livello mondiale, 2025). Un’organizzazione che ha adottato un modello in-house proprio per mantenere il materiale soggetto a regolamentazione sotto la propria giurisdizione ha il diritto di sollevare dubbi su qualsiasi architettura che reindirizzi l’interazione altrove per sottoporla a ispezione.

Quando l’applicazione delle norme tramite il cloud non è più adeguata

L’integrazione di controlli di accesso basati sul modello “zero trust” in un servizio fornito via cloud è del tutto sensata quando l’utente si trova in remoto o l’applicazione è ospitata nel cloud. Diventa invece molto meno sensata quando entrambe le parti si trovano all’interno dello stesso edificio.

Indirizzare una sessione interna all’ufficio, ovvero il traffico generato dagli agenti che viaggia alla velocità della macchina, verso un punto di presenza nel cloud per l’ispezione e l’applicazione delle politiche, solo per poi rinviarlo direttamente a un’applicazione privata o a una fonte di dati situata due piani più in basso, non è sostenibile dal punto di vista architettonico. Ciò aggiunge latenza, consuma capacità WAN e crea una dipendenza dal circuito Internet per operazioni che non avrebbero mai dovuto lasciare la sede. La disponibilità diventa una scelta di sicurezza, il che raramente è l’obiettivo auspicato.

Lo ZTNA basato su cloud presenta un secondo punto debole, meno evidente. In genere garantisce l’accesso zero-trust alla rete piuttosto che alla singola applicazione di cui l’utente ha effettivamente bisogno. La sessione dispone di privilegi eccessivi sin dal momento in cui viene ammessa, e il movimento laterale all’interno di quel segmento non viene sottoposto ad alcun controllo. Un controllo introdotto per eliminare la fiducia implicita finisce per reintrodurla a un livello inferiore.

Nulla di tutto ciò è una novità per il team di rete. La segmentazione e la visibilità sul traffico est-ovest rappresentano da anni un obiettivo, ma garantire un modello “zero trust” a livello locale senza influire sul comportamento degli utenti e sui rischi si è rivelato un compito impegnativo. Purtroppo, le funzionalità SSE di nuova generazione, quali l’accesso a livello di applicazione, l’ispezione web e TLS e i controlli basati sui dati, sono state spesso fuori dalla portata necessaria per proteggere le reti interne. Si tratta di una lacuna di natura architettonica piuttosto che concettuale, motivo per cui colmarla rappresenta un’operazione ingegneristica piuttosto che una nuova dottrina.

Ora che i flussi di dati viaggiano alla velocità delle macchine attraverso le reti locali, il controllo degli accessi a livello di applicazione locale e l’ispezione in linea locale non sono più un semplice obiettivo, ma diventano un requisito progettuale ibrido. Essi proteggono i dati critici proprio dove questi sono effettivamente archiviati e circolano, e garantiscono la continuità operativa dell’azienda quando il percorso verso il cloud non è disponibile.

Cosa comporta effettivamente il trasferimento delle forze dell’ordine

La proliferazione dei dati locali diventa evidente. Gli strumenti interni di intelligenza artificiale vengono introdotti senza alcuna documentazione di acquisto e assumono un’importanza critica per l’azienda prima ancora che qualcuno ne effettui l’inventario. Copie di materiale soggetto a regolamentazione si accumulano in archivi vettoriali, set di ottimizzazione e unità condivise che nessun controllo orientato al cloud riesce mai a rilevare, poiché nulla in quel flusso di lavoro supera alcun confine. L’ispezione dell’infrastruttura locale e dei flussi di lavoro è l’unico strumento in grado di individuarle.

L'accesso viene limitato dalla rete all'applicazione. L’autorizzazione per singola applicazione sul punto di controllo locale elimina i privilegi eccessivi che la gestione a livello di rete lascia in sospeso, e lo fa per l’utente in sede, che attualmente è l’utente meno controllato dell’infrastruttura.

L’esposizione specifica per l’IA diventa indirizzabile. L’iniezione di prompt, i tentativi di jailbreak e il materiale proprietario incollato o digitato di nascosto in un prompt possono essere gestiti solo da un elemento situato lungo il percorso dell’interazione a livello di browser. Quando tale interazione non esce mai dal sito e nulla all’interno del sito si trova lungo il suo percorso, i controlli non hanno alcun elemento su cui agire. Reintegrare il traffico locale nell’ambito di applicazione è ciò che rende applicabile la sicurezza dell’IA, indipendentemente dal luogo in cui il controllo stesso venga infine eseguito.

La resilienza migliora anziché peggiorare. Un sito che applica le misure a livello locale continua a effettuare controlli e ad applicare le politiche di accesso anche quando il collegamento con il cloud risulta interrotto. Un’architettura esclusivamente basata sul cloud, di fronte alla stessa interruzione, deve scegliere se interrompere il lavoro o lasciarlo proseguire, e nessuno è in grado di prendere una decisione adeguata con così poco preavviso.

I settori in cui SSE deve recuperare terreno

Nulla di tutto ciò costituisce una previsione. Le persone si trovano già negli uffici. I modelli sono già in esecuzione sull’infrastruttura aziendale. Le autorità di regolamentazione stanno già sollevando questioni relative alla sovranità e non mostrano alcun segno di calo di interesse.

Ciò che non è stato ancora affrontato è la questione relativa alla collocazione dei controlli SSE. L’ispezione e l’applicazione delle misure SSE nel cloud continuano a presupporre che il rischio provenga dall’esterno dell’edificio, il che riflette sempre meno la realtà di trimestre in trimestre.

Chieda al Suo fornitore di aiutarLa a comprendere in che modo garantisce la sicurezza delle attività locali basate sull’intelligenza artificiale; quali controlli vengono eseguiti in loco, quali nel cloud e cosa accade a ciascuno di essi quando il collegamento tra di essi viene interrotto.

Scoprite come la nuova piattaforma Skyhigh Hybrid Mesh SSE stia estendendo il modello Zero Trust all’interno dell’ufficio per proteggere meglio l’intelligenza artificiale.

Torna ai blog