Vai al paragrafo

Cos'è l'approccio zero trust?

Copia URL

Zero trust è un approccio alla progettazione di architetture per la sicurezza basato sul presupposto che ogni interazione inizia in condizioni di non attendibilità. Questo approccio è in netto contrasto con la filosofia che regge le architetture tradizionali, secondo cui qualunque comunicazione che abbia inizio all'interno di un firewall è da ritenersi affidabile. Nello specifico, zero trust si prefigge di colmare le lacune nelle architetture di sicurezza che si basano su modelli di attendibilità impliciti e autenticazione temporanea.

Adottato in maniera sempre più diffusa per rispondere all'evoluzione delle minacce globali, zero trust mette in discussione postulati di lunga data in merito all'affidabilità intrinseca delle attività all'interno di una rete. La criminalità informatica organizzata è in grado di reclutare delle "talpe" all'interno delle organizzazioni e continuare a sperimentare nuove tecniche di penetrazione delle architetture di sicurezza tradizionali. Inoltre ora gli strumenti di hacking sofisticati e le piattaforme di ransomware-as-a-service disponibili in commercio sono sempre più diffusi, il che semplifica notevolmente il lavoro di nuovi tipi di terroristi informatici e criminali mossi da motivazioni economiche. Tutte queste minacce possono portare alla sottrazione di dati preziosi, interferire su business e attività e influire sulla vita in generale.

Alla luce del nuovo contesto delle minacce, il Governo Federale degli Stati Uniti ha emanato un provvedimento esecutivo per promuovere l'adozione di un'architettura zero trust e molte aziende stanno valutando i pro e i contro di questo approccio.

In un noto report di Forrester Research del 2010 dedicato allo zero trust, John Kindervag richiamava l'attenzione sulla necessità di convertire l'allora comune approccio "fidati ma verifica" alla sicurezza della rete in una strategia "verifica e non fidarti mai". Kindervag metteva in discussione quella che era allora la metafora prevalente, secondo la quale: "Vorremmo che la nostra rete fosse come un M&M, con un guscio esterno croccante e un morbido cuore al centro". Per decenni le aziende erano state progettate con questa struttura, con una rete interna o attendibile (il cuore morbido) separata dal mondo esterno da un perimetro di firewall e altre misure di difesa della sicurezza (il guscio croccante). Le persone o gli endpoint entro il perimetro, o connessi tramite metodi remoti, godevano di un livello di attendibilità più elevato rispetto a chi era esterno al perimetro.

Questo approccio alla progettazione della sicurezza basato su una netta bipartizione tra "interno/esterno" al perimetro di rete non si è mai rivelato un modello efficace, eppure persiste anche oggi. Le architetture di questo tipo permettono di attraversare la rete interna una volta entrati; gli utenti, i dispositivi, i dati e le altre risorse sono separati da linee di difesa minime. Anche gli attacchi informatici si avvantaggiano di questa struttura, accedendo come prima cosa a uno o più endpoint interni o ad altre risorse per poi muoversi lateralmente nella rete, sfruttando le vulnerabilità, esfiltrando informazioni controllate e sferrando ulteriori attacchi.

Queste architetture insufficienti, oltre ad essere suscettibili agli attacchi informatici sofisticati diventano più deboli a mano a mano che le reti si espandono per includere un maggior numero di endpoint, con utenti che richiedono l'accesso remoto da più posizioni e a più risorse con servizi sempre più dettagliati. Il tema dell'affidabilità ha catturato l'attenzione anche in seguito alla pandemia di COVID-19, con una forza lavoro sempre più remota e la crescita continua dei carichi di lavoro negli ambienti cloud.

Per gestire le vulnerabilità di questo ambiente, le aziende passano dalle reti private virtuali o VPN, che consentono l'accesso sicuro all'intera rete, a un modello ZTNA (Zero Trust Network Access), che segmenta l'accesso e limita le autorizzazioni utente ad applicazioni e servizi specifici. Questo approccio di microsegmentazione consente di limitare il movimento laterale degli hacker, può ridurre la superficie di attacco e contenere l'impatto delle violazioni dei dati. Per adottare un modello zero trust è tuttavia indispensabile che le organizzazioni applichino la filosofia del "verifica e non fidarti mai" a ogni aspetto della loro architettura di sicurezza.

La sicurezza zero trust si fonda sulla de-perimetrizzazione e sul principio dell'accesso con privilegi minimi, per proteggere dati sensibili, risorse e servizi dalle vulnerabilità associate al perimetro di rete e alle architetture con attendibilità implicita.

De-perimetrizzazione: non è più possibile definire le aziende in base ai loro perimetri geografici. Gli utenti operano da numerose posizioni ed endpoint, accedono alle risorse da uno o più ambienti operativi, tra cui cloud e soluzioni Software-as-a-Service (SaaS), che spesso non sono né controllate né di proprietà del reparto IT aziendale. La de-perimetrizzazione rappresenta questa separazione tra attendibilità e posizione.

Privilegio minimo: ogni interazione che non possa ereditare l'attendibilità dal nome o dalla posizione deve essere considerata sospetta. Decidere di consentire qualsiasi interazione è quindi una decisione aziendale rispetto alla quale occorre considerare i pro e i contro. Con privilegio minimo ci si riferisce alla pratica di limitare l'accesso alle sole risorse assolutamente imprescindibili per lo svolgimento di un'attività. Ogni richiesta di accesso a una risorsa dovrà essere convalidata in modo dinamico utilizzando la gestione delle identità e controlli di accesso basati sul rischio e sensibili al contesto.

Per adottare un'architettura zero trust non è necessario sostituire completamente le reti esistenti o acquistare nuove tecnologie. La struttura di base dovrebbe, invece, consolidare le procedure e gli strumenti di sicurezza esistenti. Molte organizzazioni dispongono già delle basi su cui realizzare un'architettura zero trust e seguono procedure che la supportano nelle loro attività quotidiane.

Ad esempio, i componenti critici necessari per un'efficace adozione della strategia sono spesso già presenti in un'architettura di sicurezza convenzionale:

  • gestione delle identità e degli accessi

  • autorizzazioni

  • decisioni automatizzare correlate alle policy

  • verifica dell'applicazione delle patch alle risorse

  • monitoraggio continuo con transazioni registrate e analizzate

  • massima automazione delle attività ripetitive soggette a errori

  • analisi comportamentale e intelligence sulle minacce per migliorare la sicurezza delle risorse

Oggi l'approccio zero trust è già applicato a vari livelli e in numerosi ambienti. I tenant principali richiedono innanzitutto l'applicazione delle procedure di sicurezza esistenti, e di controlli e processi organizzativi. Organizzazioni come il Dipartimento statunitense della difesa, il Dipartimento della sicurezza interna e l'Intelligence Community, contesti in cui la sicurezza è un pilastro culturale fondante, hanno già compiuto passi significativi verso l'adozione di un modello di sicurezza zero trust.

Per venire incontro alle esigenze aziendali e rendere più veloce la trasformazione digitale, in molte organizzazioni lo sviluppo software si basa su componenti open source e strumenti di terzi. Tuttavia, eventuali malintenzionati che volessero infiltrarsi nella catena di distribuzione del software potrebbero compromettere la sicurezza dei componenti open source e le dipendenze già durante il ciclo di vita dello sviluppo, aprendo le porte agli attacchi informatici e a ritardi nel rilascio delle applicazioni. Un approccio zero trust è fondamentale per la protezione della catena di distribuzione del software e garantisce l'identificazione tempestiva dei problemi, quando i costi per la loro correzione sono ancora contenuti.

Le organizzazioni possono ridurre il rischio di attacchi alla catena di distribuzione utilizzando codice open source sicuro, integrando la sicurezza nelle immagini dei container, rafforzando la pipeline CI/CD e monitorando le applicazioni in fase di runtime.

Come modello di sicurezza, zero trust è spesso descritto in termini astratti, in opposizione a modelli di accesso controllato più formali come quello denominato Bell-LaPadula. Diversi gruppi o entità di standardizzazione espongono set differenti di componenti. Un set di componenti tipici potrebbe essere:

  • Unica sorgente di identità per utenti ed enti diversi dalle persone fisiche

  • Autenticazione utenti e sistemi

  • Contesto aggiuntivo, come conformità alle policy e integrità dei dispositivi

  • Policy di autorizzazione per accedere a un'applicazione o risorsa

  • Policy di controllo dell'accesso da un'app

Questi componenti sono fortemente incentrati su come adottare le policy di accesso basate sull'identità con eccezione predefinita "nega tutto" e "concedi per eccezione".

Limite di trust

Definiamo limite di trust qualsiasi separazione logica tra componenti in cui i soggetti che partecipano all'interazione cambiano il proprio stato di attendibilità, alternando in genere tra "attendibile" e "non attendibile". La transizione da non attendibile ad attendibile richiede due elementi:

  • autenticazione: verifica e/o convalida dell'identità dei soggetti. 

  • autorizzazione: verifica e/o convalida del diritto e della necessità di accedere a una risorsa (dati, sistemi e altro).

Affinché siano conformi ai principi zero trust, i limiti di trust devono essere il più possibile contenuti, poiché per definizione, all'interno del perimetro di trust tutti i soggetti sono considerati attendibili e i controlli di accesso possono essere omessi, ignorati o altrimenti limitati. Essendo l'autorizzazione concessa solo per funzioni di business specifiche, qualsiasi limite che consenta l'accesso ad altre funzioni dovrebbe essere ristretto.

Non tutti i confini di sicurezza nell'architettura di un sistema devono adeguarsi ai criteri di un limite zero trust adeguato. I limiti ordinari, come i filtri agli indirizzi IP non desiderati, il permesso di accesso alla rete concesso ad alcuni protocolli o i vincoli d'uso dei social media, possono sovrapporsi ai metodi zero trust e conservare un ruolo importante nella strategia di sicurezza. La differenza fondamentale nell'adozione della strategia zero trust, tuttavia, è che i limiti ordinari non rientrano nel calcolo dell'attendibilità, come accadrebbe nelle architetture di rete tradizionali. Nella valutazione dell'attendibilità dovrebbero essere considerati solo i limiti che soddisfano i principi zero trust.

Zero trust richiede la separazione costante tra soggetti distinti; vale a dire che deve sempre essere presente un limite di trust tra due qualsiasi soggetti; di conseguenza ogni interazione richiede l'autenticazione a due fattori e l'autorizzazione diretta. Non esiste attendibilità implicita, anche quando i due soggetti si trovano sulla stessa rete (uno scenario molto comune) né se sono disponibili nella stessa posizione fisica, né se fanno parte della stessa linea di business o sistema integrato.

Un modello di sicurezza zero trust funziona applicando questi limiti di trust, ovvero interponendo un punto di applicazione tra tutte le potenziali interazioni con tutte le risorse. Tali interazioni cambiano nel tempo, così come le identità, gli stati delle risorse e altri aspetti di un sistema. Questa mutabilità continua richiede una altrettanto continua valutazione e monitoraggio di identità e risorse, e l'applicazione adattiva di autenticazione e autorizzazione.

Sono ancora numerosi gli ambiti in cui questi concetti sono semplicemente troppo limitati per essere adottati. L'utilizzo continuo di tecnologie tradizionali, processi aziendali immaturi, o la scarsa priorità attribuita alla sicurezza come funzione strategica per il business costituiscono ostacoli comuni.

L'approccio zero trust presuppone in genere un cambio di mentalità sia da parte della leadership che dei professionisti della sicurezza. I primi devono saper valutare quanto sia rischioso mantenere le architetture di sicurezza esistenti e obsolete. I professionisti dell'IT e della tecnologia operativa devono poter riconoscere dove cogliere i vantaggi degli investimenti esistenti per ridurre i costi di adozione di una strategia zero trust e quando dare priorità ai nuovi investimenti. È anche vero che alcuni protocolli e dispositivi non saranno mai adatti a questo approccio, e in questo caso è imprescindibile decidere se sostituirli o mantenerli. Inoltre, se alcuni sistemi non possono adottare appieno l'approccio zero trust, i professionisti OT devono poter individuare i possibili controlli di mitigazione e verificare se sia possibile applicare controlli di sicurezza alternativi per ridurre ulteriormente la loro esposizione.

Il passaggio all'"accesso negato per impostazione predefinita" o al "verifica sempre", che sono la premessa di base di zero trust, è da considerarsi compiuto con efficacia se adottato e mantenuto nel tempo dai team, e se si impedisce qualsiasi tentativo di elusione dell'architettura di sicurezza zero trust attraverso progetti di "shadow IT".

Red Hat può aiutarti nel percorso di adozione del modello zero trust. Un importante prerequisito all'impiego dell'approccio zero trust da parte delle aziende è la consapevolezza in materia di sicurezza informatica: occorre comprendere l'attuale contesto delle minacce e l'importanza delle pratiche di sicurezza esistenti, fondamentali eppure incomplete se non vengono applicati i principi zero trust. L'offerta Red Hat prevede opzioni di formazione con esperienze personalizzate, erogate tramite Red Hat Open Innovation Labs o altre attività specializzate dei Red Hat Services.

Keep reading

ARTICOLO

Cos'è la metodologia DevSecOps?

Per sfruttare tutta l'agilità e la reattività di un approccio DevOps, occorre tenere conto anche di un altro elemento cruciale dell'intero ciclo di vita delle tue applicazioni: la sicurezza IT.

ARTICOLO

La sicurezza nel cloud

I problemi di sicurezza hanno un impatto sia sui sistemi IT tradizionali che su quelli cloud. Scopri perché la sicurezza nel cloud è differente.

ARTICOLO

Cosa si intende con SOAR?

L'acronimo SOAR indica 3 capacità chiave utilizzate dai team che si occupano di sicurezza: gestione dei casi e dei flussi di lavoro, automazione delle attività e sistema centralizzato di accesso, query e condivisione dei dati di intelligence sulle minacce.

Scopri di più sulla sicurezza

Prodotti

Un framework di sicurezza progettato per gestire le identità utente e garantire la privacy delle comunicazioni.

Una soluzione, Kubernetes native ed enterprise ready, per la sicurezza dei container che permette di creare, distribuire ed eseguire applicazioni cloud native in modo più sicuro.

Un servizio di analisi predittiva per identificare e contrastare le minacce a sicurezza, prestazioni e disponibilità della tua infrastruttura Red Hat.

Una soluzione che permette di controllare cluster e applicazioni Kubernetes da una singola console dotata di criteri di sicurezza integrati.

Risorse