Simon ChalifouxRecentemente, abbiamo scoperto che internamente c’era una certa confusione riguardo ai concetti di Zero Knowledge e Zero Trust. Alcune persone qui su Planet Devolutions utilizzavano i due termini in modo intercambiabile. Dopotutto, zero è zero, giusto? Ebbene, sì — e no!
È vero che sia la crittografia Zero-knowledge sia lo Zero Trust svolgono un ruolo significativo nella protezione dei dati e dell’infrastruttura di rete, specialmente negli ambienti cloud. Tuttavia, sebbene possano sembrare simili, si tratta di concetti distinti. Questo articolo confronta queste differenze, concentrandosi sulle loro applicazioni nei servizi cloud. Prima di tutto, però, dobbiamo comprendere le origini di questi termini apparentemente simili e gli scopi a cui rispondono.
Crittografia Zero-Knowledge: garantire la privacy dei dati con i provider cloud
La crittografia Zero-knowledge consente di mantenere la privacy dei propri dati, anche quando questi sono archiviati presso un fornitore di servizi cloud. Questo metodo garantisce che i dati vengano crittografati sul dispositivo dell’utente prima di essere inviati ai server del provider, rendendoli illeggibili a chiunque tranne che all’utente stesso. Questo perché solo l’utente possiede la chiave di decrittazione. Anche se i server del provider venissero compromessi o soggetti a un mandato delle forze dell’ordine, i dati dell’utente rimarrebbero al sicuro e privati.
Questo approccio è particolarmente prezioso nel contesto delle soluzioni basate sul cloud, dove il fornitore di servizi potrebbe avere accesso ai dati dell’utente. Utilizzando la crittografia Zero-knowledge, è possibile archiviare i propri dati nel cloud mantenendo comunque il controllo sulla loro privacy. Sebbene il provider cloud archivi e gestisca i dati crittografati, non può accedere al loro contenuto.
Ad esempio, Devolutions Cloud implementa la crittografia Zero-knowledge. I dati dei clienti (ad esempio le password) vengono crittografati sul LORO dispositivo prima di raggiungere la nostra infrastruttura. Nell’improbabile eventualità che la nostra infrastruttura venisse in qualche modo compromessa, questi dati archiviati risulterebbero semplicemente inutilizzabili. Recentemente, il nostro CSO Martin ha scritto un articolo a riguardo, e la incoraggiamo a leggerlo per approfondire il nostro standard di crittografia Zero-knowledge.
Zero Trust: garantire un livello adeguato di affidabilità nelle decisioni di controllo degli accessi
Come già discusso, la crittografia Zero-knowledge si concentra sulla protezione dei dati. I principi Zero Trust, invece, si concentrano sulla protezione dell’accesso ai dati — ancora una volta, specialmente nel contesto dei servizi cloud.
Il principio guida dello Zero Trust è “mai fidarsi, verificare sempre”. Ciò significa che ogni utente, dispositivo e applicazione DEVE essere autenticato e autorizzato — indipendentemente dalla posizione fisica — prima che venga concesso l’accesso alle risorse.
Si tratta di un cambiamento significativo rispetto ai modelli di sicurezza tradizionali, in cui la fiducia viene spesso concessa implicitamente a utenti e dispositivi all’interno del perimetro di rete, considerato affidabile per impostazione predefinita. Come abbiamo imparato da innumerevoli violazioni di alto profilo, questo approccio risulta inadeguato nel mondo interconnesso di oggi, in cui le minacce informatiche sono sempre in agguato e il tradizionale perimetro di rete è diventato sempre più sfumato.
Per implementare un modello Zero Trust, le organizzazioni utilizzano una combinazione di tecnologie e pratiche ben note, come:
- Autenticazione a più fattori (MFA)
- Accesso con privilegio minimo
- Micro-segmentazione
Tuttavia, la caratteristica distintiva di un modello Zero Trust risiede in un motore di policy che concede o nega l’accesso in base al livello di fiducia che può essere stabilito per un determinato utente. Questo livello di fiducia si basa su un’ampia gamma di variabili, come il comportamento dell’utente, il livello di sicurezza del dispositivo e informazioni contestuali come la posizione e l’orario.
Valutando continuamente questi segnali, il motore di policy regola dinamicamente il livello di fiducia, concedendo o negando l’accesso in base alla sensibilità delle azioni richieste e al rischio associato. Ciò garantisce che, anche se un aggressore riuscisse a ottenere un accesso iniziale alla rete, avrebbe grandi difficoltà a muoversi lateralmente per raggiungere risorse di maggior valore.
Si consideri questo esempio: Jenny è una manager delle risorse umane. In quanto tale, è autorizzata ad accedere a tutti i dati che l’organizzazione conserva per qualsiasi dipendente. In un contesto Zero Trust, Jenny dovrebbe dimostrare diversi livelli di fiducia a seconda delle azioni che intraprende o dei dati a cui richiede l’accesso. Ecco alcuni scenari possibili:
| Scenario | Livello di rischio/fiducia assegnato | Requisiti di accesso basati sul modello Zero Trust |
|---|---|---|
| In qualsiasi momento, Jenny può richiedere l’accesso al proprio profilo nel sistema HR. | Rischio basso — richiesto un livello di fiducia di base | Fornire le credenziali Completare la verifica MFA |
| Durante le sue attività quotidiane, Jenny deve accedere a vari profili di dipendenti per convalidare i loro dati di impiego e le schede orarie. | Rischio medio — richiesto un livello di fiducia elevato | Fornire le credenziali Completare la verifica MFA Deve accedere da un dispositivo gestito dall’azienda (nuovo) Deve trovarsi in una specifica area geografica (nuovo) |
| Meno frequentemente, Jenny necessita di accedere a informazioni personali di un dipendente, come lo stipendio o il codice fiscale. | Rischio alto — richiesto il massimo livello di fiducia | Fornire le credenziali Completare la verifica MFA Deve accedere da un dispositivo gestito dall’azienda Deve trovarsi in una specifica area geografica Deve accedere con una chiave di sicurezza fisica (nuovo) Deve accedere al sistema da una postazione o un ufficio molto specifico (nuovo) L’accesso è possibile solo durante il normale orario di lavoro (nuovo) |
Come possiamo notare, in sostanza il modello Zero Trust consiste nell’applicare un livello più elevato di verifica e affidabilità quando viene concesso l’accesso a dati e risorse privilegiati. La fiducia si guadagna e viene continuamente valutata, non concessa automaticamente e poi dimenticata!
Svelare i principi: distinguere la crittografia Zero-Knowledge dallo Zero Trust
Ora che abbiamo esplorato i fondamenti della crittografia Zero-knowledge e dello Zero Trust, ricapitoliamo le loro principali differenze. Questa tabella aiuterà a distinguere facilmente i due concetti e a comprendere le rispettive applicazioni nei servizi cloud:
| Zero Knowledge | Zero Trust | |
|---|---|---|
| Obiettivo | Riguarda principalmente la crittografia e la privacy dei dati, specialmente quando affidati a un fornitore di servizi cloud. | Protegge continuamente l’accesso ai dati e alle risorse. |
| Implementazione | Si basa su tecniche come la crittografia lato client per garantire la privacy dei dati, anche quando questi si trovano nelle mani di un fornitore di servizi cloud. | Comprende un insieme di tecnologie e pratiche come l’autenticazione a più fattori, l’accesso con privilegio minimo, la micro-segmentazione e un motore di policy che concede o nega l’accesso in modo dinamico in base a un’ampia gamma di variabili. |
| Accesso ai dati | Garantisce che il fornitore di servizi cloud non possa accedere al contenuto dei dati — solo l’utente può decrittarli e utilizzarli. | Verifica l’identità e le intenzioni di utenti e dispositivi che tentano di accedere ai dati o alle risorse, seguendo il principio “mai fidarsi, verificare sempre”. |
La parola finale
La prossima volta che si troverà di fronte a questi due principi fondamentali della cybersecurity, potrà utilizzare con sicurezza queste informazioni per distinguerli e comprendere le loro applicazioni nei servizi cloud. E se, nonostante i suoi sforzi, qualcuno sul posto di lavoro continua ANCORA a trattare questi concetti come intercambiabili, basterà indirizzarlo a questo articolo e la questione dovrebbe essere risolta!