Uno sguardo pratico su come Jay Chaudhry e Zscaler hanno usato sicurezza cloud, zero trust e distribuzione tramite partner per costruire una società di sicurezza enterprise leader.
Questa non è una biografia di Jay Chaudhry. È una storia pratica su come Zscaler ha contribuito a rimodellare la sicurezza enterprise — e perché le sue scelte (tecniche e commerciali) hanno contato.
Imparerai due cose in parallelo:
La sicurezza enterprise moderna è l’insieme di controlli che permette ai dipendenti di usare internet e le app interne in modo sicuro, senza presumere che qualcosa sia sicuro solo perché si trova “dentro” una rete aziendale. È meno costruire un muro più grande attorno a un data center e più verificare chi si connette, a cosa si connette e se la connessione dovrebbe essere consentita — ogni volta.
Alla fine sarai in grado di spiegare la scommessa fondamentale di Zscaler in una frase, riconoscere dove lo zero trust sostituisce il pensiero dell’era VPN e vedere perché la strategia di distribuzione può contare quanto il design del prodotto.
Jay Chaudhry è un imprenditore seriale noto soprattutto come fondatore e CEO di Zscaler, una società che ha spinto la sicurezza enterprise da “proteggi la rete aziendale” a “metti in sicurezza utenti e app ovunque si trovino”. Prima di Zscaler ha fondato e venduto più startup di sicurezza, esperienza che gli ha dato una visione privilegiata di come il comportamento degli attaccanti e l’IT aziendale stessero cambiando rapidamente.
La focalizzazione di Chaudhry con Zscaler era semplice: man mano che lavoro e applicazioni si spostavano fuori dalla rete aziendale (verso internet pubblico e servizi cloud), il vecchio modello di instradare tutto attraverso un data center centrale per l’ispezione iniziava a rompersi.
Questo cambiamento ha creato un doloroso compromesso per i team IT:
La premessa alla base di Zscaler era che la sicurezza dovesse seguire l’utente, non l’edificio.
Ciò che risalta è come la visione del prodotto, guidata dal fondatore, abbia influenzato la strategia dell’azienda fin dall’inizio:
Non era un vezzo di marketing; ha guidato decisioni di prodotto, partnership e il modo in cui Zscaler spiegava il “perché” a buyer aziendali conservatori. Col tempo, quella chiarezza ha aiutato a trasformare “sicurezza erogata dal cloud” e “zero trust” da idee a voci di budget — qualcosa che le grandi aziende potevano comprare, distribuire e standardizzare.
Per anni la sicurezza enterprise è stata costruita attorno a un’idea semplice: tenere le “cose buone” dentro la rete aziendale e mettere un muro attorno a essa. Quel muro era solitamente uno stack di appliance on‑premise — firewall, proxy web, intrusion prevention — collocati in pochi data center. I dipendenti remoti entravano tramite VPN, che effettivamente “estendeva” la rete interna ovunque si trovassero.
Quando la maggior parte delle app risiedeva nei data center aziendali, questo funzionava abbastanza bene. Il traffico web e applicativo scorreva attraverso gli stessi punti di strozzatura, dove i team di sicurezza potevano ispezionare, registrare e bloccare.
Ma il modello presupponeva due cose che hanno cominciato a non essere più vere:
Con la mobilità degli impiegati e l’accelerazione dell’adozione SaaS, i pattern di traffico si sono capovolti. Persone in caffè avevano bisogno di accesso veloce a Office 365, Salesforce e decine di strumenti basati su browser — spesso senza toccare mai un data center aziendale.
Per continuare a far rispettare le policy, molte aziende hanno “inoltrato” il traffico: inviare le richieste internet e SaaS di un utente prima in sede, ispezionarle e poi reinviarle. Il risultato era prevedibile: prestazioni lente, utenti insoddisfatti e crescente pressione per aprire buchi nei controlli.
La complessità è salita (più appliance, più regole, più eccezioni). Le VPN si sono sovraccaricate e sono diventate rischiose quando concedevano accessi di rete ampi. Ogni nuova filiale o acquisizione significava un altro rollout hardware, più capacity planning e un’architettura più fragile.
Quel divario — la necessità di una sicurezza coerente senza costringere tutto attraverso un perimetro fisico — ha creato lo spazio per la sicurezza erogata dal cloud che può seguire l’utente e l’applicazione, non l’edificio.
La scommessa distintiva di Zscaler era facile da dire ma difficile da eseguire: erogare la sicurezza come servizio cloud, posizionata vicino agli utenti, invece che come appliance dentro la rete dell’azienda.
In questo contesto, “sicurezza cloud” non significa proteggere soltanto server cloud. Significa che la sicurezza stessa gira nel cloud — così un utente in filiale, a casa o su mobile si connette a un punto di presenza (PoP) vicino e la policy viene applicata lì.
“Inline” è come far passare il traffico attraverso un posto di controllo di sicurezza sulla via della destinazione.
Quando un dipendente va su un sito o su un’app cloud, la sua connessione viene instradata prima attraverso il servizio. Il servizio ispeziona ciò che può (secondo le policy), blocca destinazioni rischiose, scansiona per minacce e poi inoltra il traffico consentito. L’obiettivo è che gli utenti non debbano “essere sulla rete aziendale” per ottenere protezione di livello corporate — la sicurezza viaggia con l’utente.
La sicurezza erogata dal cloud cambia la realtà quotidiana per IT e team di sicurezza:
Questo modello si allinea anche a come le aziende lavorano ora: il traffico spesso va direttamente a SaaS e internet pubblico, non “prima in sede”.
Mettere un terzo in linea solleva preoccupazioni reali che i team devono valutare:
La scommessa fondamentale, quindi, non è solo tecnica — è la fiducia operativa che un provider cloud può applicare policy in modo affidabile, trasparente e su scala globale.
Zero trust è un principio semplice: non dare mai per scontato che qualcosa sia sicuro solo perché è “nella rete aziendale”. Invece, verifica sempre chi è l’utente, su quale dispositivo sta accedendo e se dovrebbe avere accesso a una specifica app o dato — ogni volta che è importante.
Il pensiero tradizionale della VPN è come dare a qualcuno un badge che apre tutto l’edificio una volta passato l’ingresso. Dopo la connessione VPN, molti sistemi trattano quell’utente come “interno”, esponendo più di quanto previsto.
Lo zero trust ribalta quel modello. È più come dare a qualcuno l’accesso a una stanza per un compito. Non “entri nella rete” in maniera ampia; puoi raggiungere solo l’app per cui sei autorizzato.
Un contractor ha bisogno di accesso a uno strumento di project management per due mesi. Con lo zero trust, può essere autorizzato solo a quella singola app — senza ottenere involontariamente accesso a sistemi payroll o strumenti amministrativi interni.
Un dipendente usa BYOD (il proprio laptop) in viaggio. Le policy zero trust possono richiedere controlli di login più rigidi o bloccare l’accesso se il dispositivo è obsoleto, non criptato o mostra segni di compromissione.
Il lavoro remoto diventa più facile da mettere in sicurezza perché la decisione di sicurezza segue l’utente e l’app, non una rete fisica dell’ufficio.
Zero trust non è un prodotto singolo che compri e “accendi”. È un approccio di sicurezza implementato attraverso strumenti e policy.
Non significa nemmeno “non fidarsi di nessuno” in senso ostile. In pratica significa che la fiducia va guadagnata continuamente tramite controlli di identità, posture del dispositivo e il principio del minimo privilegio — così gli errori e le compromissioni non si propagano automaticamente.
Zscaler è più facile da comprendere come un “punto di controllo” cloud che si pone tra le persone e ciò che cercano di raggiungere. Invece di fidarsi di un confine di rete aziendale, valuta ogni connessione in base a chi è l’utente e a come appare la situazione, poi applica la policy giusta.
La maggior parte delle implementazioni si può descrivere con quattro elementi semplici:
Concettualmente, Zscaler divide il traffico in due corsie:
Questa separazione è importante: una corsia riguarda l’uso sicuro di internet; l’altra riguarda l’accesso preciso ai sistemi interni.
Le decisioni non si basano su un indirizzo IP di ufficio fidato. Si basano su segnali come chi è l’utente, lo stato del dispositivo (gestito vs non gestito, aggiornato vs obsoleto) e dove/come si connette.
Fatto bene, questo approccio riduce la superficie di attacco esposta, limita i movimenti laterali se qualcosa va storto e trasforma il controllo degli accessi in un modello di policy più semplice e coerente — specialmente quando il lavoro remoto e gli stack applicativi cloud-first diventano la norma.
Quando si parla di “sicurezza enterprise”, spesso la mente corre alle app private e alle reti interne. Ma gran parte del rischio risiede sul lato internet aperto: dipendenti che leggono notizie, cliccano link in email, usano strumenti basati su browser o caricano file su app web.
Un Secure Web Gateway (SWG) è la categoria pensata per rendere più sicuro quell’accesso quotidiano a internet — senza costringere il traffico di ogni utente a fare il giro lungo verso un ufficio centrale.
In termini semplici, uno SWG funge da punto di controllo tra gli utenti e il web pubblico. Invece di fidarsi di qualunque cosa raggiunga un dispositivo, il gateway applica policy e ispezioni così le organizzazioni possono ridurre l’esposizione a siti malevoli, download rischiosi e perdite accidentali di dati.
Protezioni tipiche includono:
Lo slancio è arrivato quando il lavoro si è spostato da uffici fissi verso SaaS, browser e dispositivi mobili. Se gli utenti sono ovunque e le app sono ovunque, inoltrare il traffico a un perimetro centrale aggiunge latenza e crea punti ciechi.
Lo SWG erogato dal cloud ha risposto a questa realtà: la policy segue l’utente, il traffico può essere ispezionato più vicino al punto di connessione e i team di sicurezza ottengono controllo coerente su sedi, filiali e lavoro remoto — senza trattare internet come un’eccezione.
Le VPN sono state costruite per un’epoca in cui “essere nella rete” significava poter raggiungere le app. Quel modello mentale si rompe quando le app vivono su più cloud, SaaS e un insieme sempre più ridotto di sistemi on‑prem.
L’accesso app-centrico ribalta il default. Invece di mettere l’utente nella rete interna (e poi sperare che le politiche di segmentazione reggano), l’utente viene connesso solo a una specifica applicazione.
Concettualmente funziona come una connessione brokerata: l’utente dimostra chi è e cosa può usare, e si crea un percorso breve e controllato verso quell’app — senza pubblicare range IP interni su internet e senza dare all’utente una visibilità interna ampia.
La segmentazione di rete è potente, ma fragile nelle organizzazioni reali: fusioni, VLAN piatte, app legacy ed eccezioni tendono ad accumularsi. La segmentazione per app è più facile da comprendere perché si mappa sull’intento di business:
Questo riduce la fiducia implicita e rende le policy leggibili: le puoi verificare per applicazione e gruppo utente invece di tracciare rotte e subnet.
La maggior parte dei team non elimina la VPN da un giorno all’altro. Un rollout pratico spesso somiglia a:
Quando l’accesso app-centrico è fatto bene, i benefici emergono in fretta: meno ticket legati alla VPN, regole di accesso più chiare che sicurezza e IT possono spiegare e un’esperienza utente più fluida — specialmente per dipendenti remoti e ibridi che vogliono semplicemente usare l’app senza “connettersi alla rete” prima.
Ottimi prodotti di sicurezza non diventano automaticamente standard enterprise. Nella pratica, “distribuzione” nella security enterprise significa l’insieme di rotte che un vendor usa per raggiungere, vincere e distribuire con successo dentro grandi organizzazioni — spesso tramite altre aziende.
Nella security, la distribuzione tipicamente comprende:
Questi non sono optional. Sono i tubi che collegano un vendor ai budget, ai decisori e alla capacità di implementazione.
Le grandi aziende comprano con cautela. I partner forniscono:
Per una piattaforma come Zscaler, l’adozione spesso dipende dal lavoro di migrazione reale — spostare utenti fuori dai pattern legacy VPN, integrare identità e tarare policy. I partner possono rendere quel cambiamento gestibile.
La delivery cloud sposta il business da installazioni una tantum a subscription, espansione e rinnovi. Questo cambia la distribuzione: i partner non sono solo “chiuditori di affare.” Possono essere partner di rollout continuo i cui incentivi si allineano ai risultati del cliente — se il programma è progettato correttamente.
Guardate da vicino gli incentivi per i partner, la qualità dell’enablement dei partner (training, playbook, supporto al co‑selling) e quanto fluide sono le consegne di customer success dopo la firma del contratto. Molte distribuzioni falliscono non perché il prodotto è debole, ma perché la ownership tra vendor, partner e cliente diventa poco chiara.
Gli acquisti in sicurezza raramente partono da “abbiamo bisogno di sicurezza migliore.” Di solito partono da un cambiamento di rete che rompe le vecchie assunzioni: più app migrano a SaaS, le filiali adottano SD‑WAN o il lavoro remoto diventa permanente. Quando il traffico non scorre più attraverso un ufficio centrale, il modello “proteggi tutto in sede” si trasforma in connessioni lente, eccezioni ingombranti e punti ciechi.
Zscaler è spesso citata insieme a SASE e SSE perché queste etichette descrivono uno spostamento nel modo in cui la sicurezza viene erogata:
Il vero “beneficio” non è l’acronimo ma operazioni più semplici: meno appliance on‑prem, aggiornamenti policy più facili e accesso diretto alle app senza inoltrare il traffico attraverso un data center.
Un’azienda tipicamente valuta approcci in stile SSE/SASE quando:
Quando questi trigger emergono, la categoria “arriva” naturalmente — perché la rete è già cambiata.
Comprare una piattaforma Zero Trust è di solito la parte facile. Farla funzionare attraverso reti disordinate, applicazioni ereditate e persone reali è dove i progetti hanno successo — o si bloccano.
Le app legacy sono il colpevole ricorrente. Sistemi più vecchi possono presumere “dentro la rete = trusted”, contare su allowlist IP hard‑coded o rompersi quando il traffico viene ispezionato.
Altri punti di attrito sono umani: change management, riprogettazione delle policy e dibattiti su “chi possiede cosa”. Passare da un accesso di rete ampio a regole precise a livello di app costringe i team a documentare come il lavoro avviene realmente — e questo può far emergere gap a lungo ignorati.
I rollout vanno meglio quando la sicurezza non prova a operare da sola. Aspettatevi di coordinare con:
Iniziate con un gruppo a basso rischio (es. un singolo reparto o un sottoinsieme di contractor) e definite metriche di successo in anticipo: meno ticket VPN, accesso alle app più veloce, riduzione misurabile della superficie di attacco esposta o maggiore visibilità.
Eseguite il pilot per iterazioni: migrate una categoria di app alla volta, affinate le policy e poi espandete. L’obiettivo è imparare rapidamente senza trasformare l’intera azienda in un ambiente di test.
Pianificate logging e troubleshooting fin dal giorno uno: dove risiedono i log, chi può interrogarli, per quanto tempo vengono conservati e come gli alert si integrano nella risposta agli incidenti. Se gli utenti non ricevono aiuto quando “l’app è bloccata”, la fiducia cala rapidamente — anche se il modello di sicurezza è solido.
Un acceleratore pratico (spesso trascurato) sono gli strumenti interni: portali semplici per richieste di eccezione, revisioni di accesso, inventari di app, tracciamento dei rollout e reporting. I team sempre più spesso costruiscono queste piccole “app collante” internamente invece di aspettare la roadmap del vendor. Piattaforme come Koder.ai possono aiutare i team a prototipare e mettere in produzione questi strumenti interni rapidamente tramite workflow chat-driven — utile quando serve una dashboard React con backend Go/PostgreSQL e iterazioni veloci mentre le policy e i processi maturano.
Spostare i controlli di sicurezza da appliance che possedete a una piattaforma cloud-delivered può semplificare le operazioni — ma cambia anche le scommesse. Una buona decisione non è “Zero Trust vs legacy” quanto capire i nuovi modi in cui le cose possono fallire.
Se una piattaforma fornisce sicurezza web, accesso ad app private, enforcement policy e logging, riduci lo sprawl degli strumenti — ma concentri anche il rischio. Una disputa contrattuale, un cambiamento di prezzi o una lacuna di prodotto può avere un raggio d’impatto più ampio rispetto a quando quei pezzi sono distribuiti tra più strumenti.
La sicurezza cloud aggiunge un salto in più tra utenti e app. Quando funziona bene, gli utenti quasi non se ne accorgono. Quando una regione ha un outage, un problema di instradamento o capacità, la “sicurezza” può sembrare “internet è giù”. Questo è meno un problema di un singolo vendor e più una realtà del dipendere da connettività sempre attiva.
Zero Trust non è una bacchetta magica. Policy mal definite (troppo permissive, troppo restrittive o incoerenti tra gruppi) possono aumentare l’esposizione o interrompere il lavoro. Più il motore di policy è flessibile, più disciplina serve.
I rollout a fasi aiutano: iniziate con un caso d’uso chiaro (es. un sottoinsieme di utenti o una categoria di app), misurate latenza e risultati di accesso, poi espandete. Definite le policy in linguaggio chiaro, implementate monitoraggio e alerting fin da subito e pianificate la ridondanza (instradamento multi‑regione, accesso break‑glass e percorsi di fallback documentati).
Sapete quali tipi di dati state proteggendo (regolamentati vs generali), allineate i controlli ai requisiti di compliance e programmate revisioni ricorrenti degli accessi. L’obiettivo non è comprare per paura — è fare in modo che il nuovo modello fallisca in modo sicuro e prevedibile.
La lezione ripetuta di Zscaler è il focus: spostare l’enforcement delle policy nel cloud e rendere l’accesso guidato dall’identità. Quando valutate vendor (o costruite uno), fate una domanda semplice: “Qual è la scommessa architetturale che rende tutto il resto più semplice?” Se la risposta è “dipende”, aspettatevi che la complessità emerga più tardi in costi, tempi di rollout ed eccezioni.
“Zero trust” ha funzionato perché si è tradotto in una promessa pratica: meno assunti di fiducia implicita, meno impianti di rete e miglior controllo mentre le app si spostavano off‑prem. Per i team significa comprare risultati, non parole alla moda. Scrivete i risultati desiderati (es. “nessun accesso inbound”, “minimo privilegio per le app”, “policy coerente per utenti remoti”) e mappateli a capacità concrete che potete testare.
La sicurezza enterprise si diffonde attraverso reti di fiducia: rivenditori, GSI, MSP e marketplace cloud. I founder possono imitarlo costruendo presto un prodotto pronto per i partner — packaging chiaro, margini prevedibili, playbook di deployment e metriche condivise. I leader della sicurezza possono sfruttare i partner: usateli per change management, integrazione identità e migrazioni a fasi invece di cercare di aggiornare ogni team internamente.
Iniziate con un caso d’uso ad alto volume (spesso l’accesso internet o una singola app critica), misurate prima/dopo ed espandete.
Domande chiave per il rollout:
Non limitatevi a “vendere sicurezza” — vendete un percorso di migrazione. La storia che vince è spesso: dolore → passo più semplice → vittoria misurabile → espansione. Costruite l’onboarding e il reporting che rendono visibile il valore in 30–60 giorni.
Un pattern amico dei founder è completare il prodotto core con companion app facili da costruire (workflow di assessment, tracker di migrazione, calcolatori ROI, portali partner). Se volete crearle senza ricostruire una pipeline dev legacy, Koder.ai è pensata per “vibe‑coding” di app full‑stack da chat — utile per mettere velocemente in produzione strumenti interni o per i clienti, poi iterare man mano che la vostra distribuzione evolve.
Se volete approfondire, vedi zero-trust-basics e sase-vs-sse-overview. Per idee di packaging, consulta pricing.
Zero trust è un approccio in cui le decisioni di accesso vengono prese per ogni richiesta basandosi su identità, stato del dispositivo e contesto, invece di presumere che qualcosa sia sicuro perché è “dentro la rete”. In pratica significa:
Un VPN tradizionale spesso mette l’utente “sulla rete”, esponendo potenzialmente più sistemi del necessario. L’accesso app-centrico ribalta il modello:
“Inline” significa che il traffico passa attraverso un punto di controllo di sicurezza prima di raggiungere internet o un’app cloud. In un modello cloud-delivered, quel checkpoint risiede in un vicino point of presence (PoP), così il provider può:
L’obiettivo è avere una sicurezza coerente senza costringere il traffico a tornare in sede.
Inoltrare il traffico di un utente remoto a un data center centrale per l’ispezione e poi reinviarlo verso internet spesso fallisce perché:
Un Secure Web Gateway (SWG) protegge gli utenti mentre navigano in internet e utilizzano app SaaS. Le capacità comuni di uno SWG includono:
È particolarmente utile quando la maggior parte del traffico è diretta verso internet e gli utenti non sono dietro un singolo firewall aziendale.
La sicurezza cloud-delivered può semplificare le operazioni, ma cambia le dipendenze. I principali trade-off da valutare sono:
Un pilot a basso rischio di solito funziona quando è limitato e misurabile:
L’obiettivo è imparare velocemente senza trasformare l’intera azienda in un ambiente di prova.
La misconfigurazione è comune perché passare da “accesso di rete” a “accesso per app/policy” costringe le squadre a definire l’intento in modo preciso. Per ridurre il rischio:
SSE sono controlli di sicurezza erogati dal cloud (come SWG e accesso ad app private) vicini agli utenti. SASE unisce quel modello di sicurezza alla parte di networking (spesso SD-WAN) così connettività e sicurezza sono progettate insieme.
In termini pratici:
Le grandi aziende spesso acquistano tramite partner e hanno bisogno di capacità di implementazione. Partner, SI e MSP aiutano:
Un ecosistema di partner solido può determinare se una piattaforma diventa uno standard o si arresta dopo una piccola implementazione.
