20 okt 2025·8 min
Jay Chaudhry & Zscaler: Zero Trust, gebouwd voor cloud-schaal
Een praktische blik op hoe Jay Chaudhry en Zscaler cloudbeveiliging, zero trust en partnerdistributie gebruikten om een leidend enterprise-securitybedrijf op te bouwen.
Een praktische blik op hoe Jay Chaudhry en Zscaler cloudbeveiliging, zero trust en partnerdistributie gebruikten om een leidend enterprise-securitybedrijf op te bouwen.
Dit is geen biografie van Jay Chaudhry. Het is een praktisch verhaal over hoe Zscaler hielp bij het hervormen van enterprise-beveiliging — en waarom de keuzes (technisch en commercieel) ertoe deden.
Je leert twee dingen parallel:
Moderne enterprise-beveiliging is de set controles die medewerkers veilig het internet en interne apps laat gebruiken, zonder aan te nemen dat iets veilig is alleen omdat het “binnen” een bedrijfsnetwerk zit. Het gaat minder om het bouwen van een dikkere muur rond een datacenter en meer om het telkens controleren wie verbinding maakt, wat ze bereiken en of de verbinding toegestaan moet worden.
Aan het einde kun je Zscaler’s kernzet in één zin uitleggen, herkennen waar zero trust het VPN-denken vervangt en zien waarom distributiestrategie net zo belangrijk kan zijn als productontwerp.
Jay Chaudhry is een seriële ondernemer, vooral bekend als oprichter en CEO van Zscaler, een bedrijf dat enterprise-beveiliging verschoof van “bescherm het bedrijfsnetwerk” naar “beveilig gebruikers en apps waar ze ook zijn.” Voor Zscaler bouwde en verkocht hij meerdere security-startups, wat hem een front-row view gaf op hoe snel aanvallergedrag en enterprise-IT veranderden.
Chaudhry’s focus met Zscaler was helder: naarmate werk en applicaties van het bedrijfsnetwerk verhuisden (naar het publieke internet en cloudservices), begon het oude model van al het verkeer via een centraal datacenter routen voor inspectie te haperen.
Die verschuiving creëerde een pijnlijk compromis voor IT-teams:
Zscaler’s uitgangspunt was dat beveiliging de gebruiker moet volgen, niet het gebouw.
Wat opvalt is hoe de door de oprichter gedreven productvisie de strategie vroegtijdig beïnvloedde:
Dit was geen marketingtruc; het stuurde productbeslissingen, partnerschappen en hoe Zscaler het “waarom” uitlegde aan conservatieve enterprise-kopers. Mettertijd hielp die duidelijkheid om “cloud-delivered security” en “zero trust” van ideeën naar budgetregels te brengen — iets wat grote bedrijven konden kopen, uitrollen en standaardiseren.
Jarenlang was enterprise-beveiliging gebouwd rond één idee: houd de “goede spullen” binnen het bedrijfsnetwerk en zet er een muur omheen. Die muur bestond meestal uit een stapel on-prem appliances — firewalls, webproxies, intrusion prevention — in een paar datacenters. Externe medewerkers gingen via een VPN naar binnen, wat het interne netwerk effectief “uitbreidde” naar waar zij ook waren.
Wanneer de meeste apps in bedrijfsdatacenters draaiden, werkte dit redelijk goed. Web- en appverkeer stroomde door dezelfde choke points waar beveiligingsteams konden inspecteren, loggen en blokkeren.
Maar het model ging uit van twee aannames die onwaar begonnen te worden:
Naarmate werknemers mobieler werden en SaaS sneller werd aangenomen, keerde het verkeerspatroon om. Mensen in koffietentjes hadden snelle toegang nodig tot Office 365, Salesforce en tientallen browsergebaseerde tools — vaak zonder ooit een bedrijfsdatacenter te bereiken.
Om beleid te blijven afdwingen, "backhaulden" veel bedrijven verkeer: stuur iemands internet- en SaaS-verzoeken eerst via het hoofdkantoor, inspecteer het en stuur het dan weer terug. Het voorspelbare resultaat: trage performance, ontevreden gebruikers en groeiende druk om gaten in de controls te maken.
Complexiteit nam toe (meer appliances, meer regels, meer uitzonderingen). VPNs raakten overbelast en werden risicovol omdat ze brede netwerktoegang gaven. En elk nieuw filiaal of overname betekende weer een hardware-uitrol, meer capaciteitplanning en fragielere architectuur.
Die kloof — behoefte aan consistente beveiliging zonder alles door een fysieke perimeter te dwingen — creëerde ruimte voor cloud-delivered security die de gebruiker en de applicatie volgt, niet het gebouw.
Zscaler’s bepalende inzet was simpel te zeggen maar moeilijk uit te voeren: lever beveiliging als een cloudservice, gepositioneerd dicht bij gebruikers, in plaats van als boxes binnen het bedrijfsnetwerk.
In deze context betekent “cloud security” niet alleen het beschermen van cloud-servers. Het betekent dat de beveiliging zelf in de cloud draait — zodat een gebruiker in een filiaal, thuis of mobiel verbinding maakt met een nabijgelegen security point-of-presence (PoP) en beleid daar wordt afgedwongen.
"Inlining" is alsof je verkeer via een beveiligingscheckpoint leidt op weg naar de bestemming.
Wanneer een medewerker naar een website of cloud-app gaat, wordt de verbinding via de service gestuurd. De service inspecteert wat mogelijk is (op basis van beleid), blokkeert risicovolle bestemmingen, scant op bedreigingen en stuurt toegestaan verkeer door. Het doel is dat gebruikers niet "op het bedrijfsnetwerk" hoeven te zijn om bescherming op bedrijfsniveau te krijgen — beveiliging reist met de gebruiker mee.
Cloud-delivered security verandert de dagelijkse realiteit voor IT- en beveiligingsteams:
Dit model sluit ook aan bij hoe bedrijven nu werken: verkeer gaat vaak rechtstreeks naar SaaS en het publieke internet, niet eerst naar het hoofdkantoor.
Een derde partij inline plaatsen roept echte zorgen op die teams moeten evalueren:
De kernzet is dus niet alleen technisch — het is operationeel vertrouwen dat een cloudprovider beleid betrouwbaar, transparant en wereldwijd kan afdwingen.
Zero trust is een simpel principe: ga er nooit van uit dat iets veilig is alleen omdat het “binnen het bedrijfsnetwerk” zit. In plaats daarvan verifieer je altijd wie de gebruiker is, op welk apparaat ze zitten en of ze toegang tot een specifieke app of data zouden moeten hebben — elke keer dat het ertoe doet.
Traditioneel VPN-denken is alsof je iemand een pas geeft die een hele gebouwdeur opent zodra ze binnen zijn. Na de VPN-verbinding behandelen veel systemen die gebruiker als "intern", wat meer blootstelling kan veroorzaken dan bedoeld.
Zero trust keert dat om. Het is meer alsof je iemand toegang geeft tot één kamer voor één taak. Je “verbindt niet breed met het netwerk”; je mag alleen de app bereiken waarvoor je goedgekeurd bent.
Een aannemer heeft twee maanden toegang nodig tot een projectmanagementtool. Met zero trust kan die persoon alleen die ene app gebruiken — zonder per ongeluk toegang te krijgen tot payrollsystemen of interne admin-tools.
Een werknemer gebruikt BYOD tijdens reizen. Zero trust-beleid kan sterkere inlogcontroles vereisen of toegang blokkeren als het apparaat verouderd, niet-versleuteld of mogelijk gecompromitteerd is.
Remote werken wordt makkelijker te beveiligen omdat de veiligheidsbeslissing de gebruiker en de app volgt, niet een fysiek kantoornetwerk.
Zero trust is geen product dat je koopt en "aanzet." Het is een beveiligingsaanpak die je implementeert met tools en beleid.
Het betekent ook niet “vertrouw niemand” op een vijandige manier. In praktijk betekent het dat vertrouwen continu verdiend wordt via identiteitscontroles, apparaatpostuur en least-privilege-toegang — zodat fouten en inbreuken zich niet automatisch verspreiden.
Zscaler is het makkelijkst te begrijpen als een cloud “control point” tussen mensen en wat ze proberen te bereiken. In plaats van te vertrouwen op een corporate netwerkboundary, evalueert het elke verbinding op basis van wie de gebruiker is en hoe de situatie eruitziet, en past dan het juiste beleid toe.
De meeste implementaties zijn met vier simpele onderdelen te beschrijven:
Conceptueel splitst Zscaler verkeer in twee paden:
Die scheiding is belangrijk: het ene pad gaat over veilig internetgebruik; het andere over precieze toegang tot interne systemen.
Beslissingen zijn niet gebaseerd op een vertrouwd kantoors IP-adres. Ze zijn gebaseerd op signalen zoals wie de gebruiker is, apparaatgezondheid (managed vs unmanaged, gepatcht vs verouderd), en waar/hoe ze verbinden.
Goed uitgevoerd vermindert deze aanpak het blootgestelde aanvalsoppervlak, beperkt laterale beweging als er iets misgaat en maakt toegangstoezicht eenvoudiger en consistenter — vooral nu remote werken en cloud-first applicatiestacks de norm worden.
Wanneer mensen over “enterprise-beveiliging” praten, denken ze vaak aan private apps en interne netwerken. Maar een groot deel van het risico zit aan de open internetzijde: medewerkers die nieuwswebsites bezoeken, op links in e-mails klikken, browsergebaseerde tools gebruiken of bestanden naar webapps uploaden.
Een Secure Web Gateway (SWG) is de categorie die is opgebouwd om dat alledaagse internetgebruik veiliger te maken — zonder dat je het verkeer van elke gebruiker via een centraal kantoor hoeft te laten lopen.
Simpel gezegd fungeert een SWG als een gecontroleerd checkpoint tussen gebruikers en het publieke web. In plaats van te vertrouwen op wat een apparaat bereikt, past de gateway beleid en inspectie toe zodat organisaties blootstelling aan kwaadaardige sites, risicovolle downloads en onbedoelde datalekken kunnen verminderen.
Typische bescherming omvat:
De verschuiving kwam toen werk wegbewoog van vaste kantoren naar SaaS, browsers en mobiele apparaten. Als gebruikers overal zijn en apps overal zijn, voegt backhauling naar een centrale perimeter latentie toe en creëert blinde vlekken.
Cloud-delivered SWG paste bij de nieuwe realiteit: beleid volgt de gebruiker, verkeer kan dichter bij waar ze verbinden worden geïnspecteerd en beveiligingsteams krijgen consistente controle over hoofdkantoor, filialen en remote werk — zonder het internet als uitzondering te behandelen.
VPNs waren ontworpen voor een tijd waarin “op het netwerk zijn” gelijk stond aan “apps kunnen bereiken.” Dat mentale model valt uit elkaar wanneer apps verspreid zijn over meerdere clouds, SaaS en een krimpend aandeel on-prem systemen.
App-centrische toegang keert de standaard om. In plaats van een gebruiker op het interne netwerk te zetten (en dan te hopen dat segmentatiebeleid standhoudt), wordt de gebruiker alleen verbonden met een specifieke applicatie.
Conceptueel werkt het als een gebrokerde verbinding: de gebruiker bewijst wie ze zijn en wat ze mogen gebruiken, en dan wordt een korte, gecontroleerde route naar die app opgezet — zonder interne IP-bereiken aan internet te publiceren en zonder de gebruiker brede interne zichtbaarheid te geven.
Netwerksegmentatie is krachtig, maar fragiel in echte organisaties: fusies, vlakke VLANs, legacy-apps en uitzonderingen stapelen zich op. App-segmentatie is makkelijker te doorgronden omdat het aansluit op zakelijke intenties:
Dit vermindert impliciet vertrouwen en maakt beleidsregels leesbaar: je kunt ze auditen per applicatie en gebruikersgroep in plaats van routes en subnets te traceren.
De meeste teams vervangen VPN niet van de ene op de andere dag. Een praktische uitrol ziet er vaak zo uit:
Wanneer app-centrische toegang goed is uitgevoerd, tonen de voordelen zich snel: minder VPN-supporttickets, helderdere toegangsregels die security en IT kunnen uitleggen, en een soepelere gebruikerservaring — vooral voor remote en hybride medewerkers die gewoon willen dat de app werkt zonder eerst “op het netwerk” te hoeven verbinden.
Geweldige beveiligingsproducten worden niet automatisch enterprise-standaarden. In de praktijk betekent “distributie” in enterprise-beveiliging de routes die een leverancier gebruikt om grote organisaties te bereiken, winnen en succesvol uit te rollen — vaak via andere bedrijven.
In security omvat distributie doorgaans:
Dit zijn geen optionele add-ons. Het zijn de pijpleidingen die een leverancier verbinden met budgetten, beslissers en implementatiecapaciteit.
Grote ondernemingen kopen voorzichtig. Partners bieden:
Voor een platform als Zscaler hangt adoptie vaak af van echte migratiewerkzaamheden — gebruikers van legacy VPN-patronen halen, identiteit integreren en beleid tunen. Partners kunnen die verandering beheersbaar maken.
Cloud delivery verschuift het bedrijf van eenmalige installaties naar abonnementen, uitbreiding en renewals. Dat verandert distributie: partners zijn niet alleen "deal closers." Ze kunnen doorlopende rollout-partners worden wiens incentives aansluiten op klantresultaten — mits het programma goed is ontworpen.
Kijk goed naar partnerincentives, de kwaliteit van partner enablement (training, playbooks, co-selling support) en hoe schoon customer success handoffs verlopen na contractondertekening. Veel uitrols mislukken niet omdat het product zwak is, maar omdat eigenaarschap tussen leverancier, partner en klant onduidelijk wordt.
Beveiligingskoop start zelden met "we hebben betere beveiliging nodig." Het begint meestal met een netwerkverandering die oude aannames breekt: meer apps migreren naar SaaS, filialen schakelen naar SD-WAN of remote werken wordt permanent. Wanneer verkeer niet langer door een centraal kantoor stroomt, verandert het model "bescherm alles bij het hoofdkantoor" in trage verbindingen, rommelige uitzonderingen en blinde vlekken.
Zscaler wordt vaak in dezelfde gesprekken genoemd als SASE en SSE omdat die labels een verschuiving beschrijven in hoe beveiliging wordt geleverd:
De echte “vertaling van voordelen” is niet het acroniem — het is eenvoudiger: minder on-prem boxes, makkelijker beleid bijwerken en directer toegang tot apps zonder verkeer via een datacenter te hairpinnen.
Een bedrijf evalueert SSE/SASE-achtige benaderingen typisch wanneer:
Wanneer die triggers verschijnen, arriveert de categorie natuurlijk — omdat het netwerk al veranderd is.
Een Zero Trust-platform kopen is meestal het eenvoudige deel. Het werkend krijgen over rommelige netwerken, geërfde applicaties en echte mensen is waar projecten slagen — of vastlopen.
Legacy-apps zijn de herhaalde boosdoener. Oudere systemen gaan uit van "binnen het netwerk = vertrouwd", vertrouwen hard-coded IP-allowlists of breken wanneer verkeer wordt geïnspecteerd.
Andere friction points zijn menselijk: change management, beleidsontwerp en discussies over "wie is eigenaar van wat". Overschakelen van brede netwerktoegang naar precieze app-regels dwingt teams te documenteren hoe werk echt gebeurt — en dat kan lang genegeerde hiaten blootleggen.
Uitrols verlopen soepeler wanneer security niet alleen opereert. Verwacht coördinatie met:
Begin met een low-risk groep (bijv. één afdeling of een subset van aannemers) en definieer succesmetingen vooraf: minder VPN-tickets, snellere app-toegang, meetbare vermindering van blootgesteld aanvalsoppervlak of verbeterde zichtbaarheid.
Voer de pilot in iteraties uit: migreer één appcategorie tegelijk, stem beleid af en breid uit. Het doel is snel leren zonder van het hele bedrijf een testomgeving te maken.
Plan vanaf dag één voor logging en troubleshooting: waar logs staan, wie ze kan doorzoeken, hoe lang ze bewaard worden en hoe alerts in incident response passen. Als gebruikers geen hulp kunnen krijgen wanneer "de app geblokkeerd is", daalt het vertrouwen snel — zelfs als het beveiligingsmodel klopt.
Een praktisch (en vaak over het hoofd gezien) versneller is interne tooling: simpele portals voor uitzonderingsverzoeken, toegangsreviews, app-inventarissen, rollout-tracking en rapportage. Teams bouwen steeds vaker deze lichte “lijm-apps” zelf in plaats van op een vendor roadmap te wachten. Platforms zoals Koder.ai kunnen teams helpen om deze interne webtools snel te prototypen en te leveren via een chat-gedreven workflow — handig wanneer je een React-dashboard met een Go/PostgreSQL-backend nodig hebt, plus snelle iteraties naarmate beleid en processen rijpen.
Het verplaatsen van beveiligingscontrols van appliances die je bezit naar een cloud-delivered platform kan operaties vereenvoudigen — maar het verandert ook waar je op inzet. Een goede beslissing draait minder om “Zero Trust vs legacy” en meer om het begrijpen van nieuwe faalwijzen.
Als één platform webbeveiliging, private app-toegang, beleidafdwinging en logging levert, reduceer je tool-sprawl — maar concentreer je ook risico. Een contractdispuut, prijswijziging of productgap kan een grotere impact hebben dan wanneer die stukken over meerdere tools verdeeld waren.
Cloud security voegt een extra hop toe tussen gebruikers en apps. Wanneer het goed werkt, merken gebruikers er nauwelijks iets van. Wanneer een regio een storing, routeringsprobleem of capaciteitstekort heeft, kan “beveiliging” voelen als “het internet ligt eruit.” Dit is minder over een specifieke leverancier en meer over afhankelijkheid van always-on connectiviteit.
Zero Trust is geen magisch schild. Slecht gespecificeerde beleidsregels (te permissief, te restrictief of inconsistent) kunnen blootstelling vergroten of werk onderbreken. Hoe flexibeler de policy-engine, hoe meer discipline vereist is.
Gefaseerde uitrols helpen: begin met een duidelijk gebruiksgeval (bijv. een subset gebruikers of één appcategorie), meet latency en toegangsprestaties en breid daarna uit. Definieer beleid in eenvoudige taal, implementeer monitoring en alerting vroeg en plan redundantie (multi-region routing, break-glass toegang en gedocumenteerde fallbackpaden).
Weet welke datatypes je beschermt (gereguleerd vs algemeen), lijn controls uit op compliance-eisen en plan terugkerende toegangsreviews. Het doel is geen angst-gedreven aankoop — het is zorgen dat het nieuwe model veilig en voorspelbaar faalt.
Zscaler’s herhaalde les is focus: verplaats beleidafdwinging naar de cloud en maak toegang identiteit-gedreven. Bij het evalueren van leveranciers (of het bouwen van een product), stel één simpele vraag: “Wat is de ene architecturale inzet die alles eenvoudiger maakt?” Als het antwoord is “het hangt ervan af,” verwacht dan dat complexiteit later terugkomt in kosten, uitroltijd en uitzonderingen.
“Zero trust” werkte omdat het vertaald kon worden naar een praktisch belofte: minder impliciete vertrouwensaannames, minder netwerkplumbing en betere controle naarmate apps off-prem gingen. Voor teams betekent dit: koop uitkomsten, niet buzzwords. Schrijf je gewenste uitkomsten op (bijv. “geen inbound access”, “least-privilege naar apps”, “consistent beleid voor remote gebruikers”) en koppel elk aan concrete capabilities die je kunt testen.
Enterprise-beveiliging verspreidt zich via vertrouwensnetwerken: resellers, GSIs, MSPs en cloudmarktplaatsen. Founders kunnen dit kopiëren door vroeg een partner-ready product te bouwen — duidelijke verpakking, voorspelbare marges, deployment-playbooks en gedeelde metrics. Security-leiders kunnen partners ook inzetten: gebruik ze voor change management, identity-integratie en gefaseerde migraties in plaats van te proberen elk team intern bij te scholen.
Begin met één high-volume gebruiksgeval (vaak internettoegang of één kritieke app), meet voor/na en breid uit.
Belangrijke rolloutvragen:
Verkoop niet alleen “beveiliging” — verkoop een migratiepad. Het winnende verhaal is meestal: pijn → eenvoudigste eerste stap → meetbare winst → uitbreiding. Bouw de onboarding en rapportage die waarde zichtbaar maakt in 30–60 dagen.
Een founder-vriendelijk patroon is het aanvullen van het kernproduct met snel te bouwen companion-apps (assessments, migratietrackers, ROI-calculators, partnerportals). Als je dat zonder een volledig legacy dev-pijplijn wilt doen, is Koder.ai ontworpen voor het snel bouwen van full-stack apps vanuit chat — handig om interne of klantgerichte tooling snel in productie te krijgen en daarna te itereren naarmate je distributiemodel evolueert.
Als je dieper wilt gaan, zie /blog/zero-trust-basics en /blog/sase-vs-sse-overview. Voor verpakkingsideeën, zie /pricing.
Zero trust is een aanpak waarbij toegangsbeslissingen per verzoek worden genomen op basis van identiteit, apparaatstaat en context, in plaats van aan te nemen dat iets veilig is omdat het "binnen het netwerk" zit. Praktisch betekent dit:
Een traditioneel VPN plaatst een gebruiker vaak "op het netwerk", wat per ongeluk meer systemen dan nodig kan blootstellen. App-centrische toegang draait dat model om:
"Inline" betekent dat verkeer via een beveiligingscontrolepunt wordt gestuurd voordat het internet of een cloud-app bereikt. In een cloud-delivered model woont dat controlepunt in een nabijgelegen point of presence (PoP), zodat de leverancier kan:
Het doel is consistente beveiliging zonder het verkeer via het hoofdkantoor terug te sturen.
Backhauling stuurt het web- en SaaS-verkeer van een externe gebruiker naar een centraal datacenter voor inspectie en vervolgens terug naar het internet. Het faalt vaak omdat het:
Een Secure Web Gateway (SWG) beschermt gebruikers tijdens het browsen en bij gebruik van SaaS-apps. Veelvoorkomende SWG-mogelijkheden zijn:
Het is vooral nuttig wanneer het meeste verkeer naar het internet gaat en gebruikers niet achter één corporate firewall zitten.
Cloud-delivered security kan de operatie vereenvoudigen, maar het verandert waar je afhankelijkheid ligt. Belangrijke afwegingen:
Een laag-risico pilot slaagt meestal wanneer deze smal en meetbaar is:
Het doel is snel leren zonder het hele bedrijf tot testomgeving te maken.
Misconfiguratie is vaak omdat de verschuiving van “netwerktoegang” naar “app-/beleidstoegang” teams dwingt intent precies vast te leggen. Om risico te verminderen:
SSE zijn cloud-delivered beveiligingscontroles (zoals SWG en private app access) die dicht bij gebruikers worden geleverd. SASE combineert dat beveiligingsmodel met netwerkfuncties (vaak SD-WAN) zodat connectiviteit en beveiliging samen worden ontworpen.
In kooptermen:
Grote ondernemingen kopen vaak via partners en hebben implementatiecapaciteit nodig. Kanaalpartners, SIs en MSPs helpen door:
Een sterk partner-ecosysteem kan bepalen of een platform standaard wordt of vastloopt na een kleine uitrol.