20 okt. 2025·8 min
Jay Chaudhry & Zscaler: Nolltillit byggt för molnskala
En praktisk genomgång av hur Jay Chaudhry och Zscaler använde molnsäkerhet, nolltillit och partnerdistribution för att bygga ett ledande företagssäkerhetsbolag.
En praktisk genomgång av hur Jay Chaudhry och Zscaler använde molnsäkerhet, nolltillit och partnerdistribution för att bygga ett ledande företagssäkerhetsbolag.
Det här är inte en biografi över Jay Chaudhry. Det är en praktisk berättelse om hur Zscaler hjälpte till att omforma företags‑säkerhet — och varför deras val (tekniska och kommersiella) spelade roll.
Du kommer att lära dig två saker parallellt:
Modern företags‑säkerhet är de kontroller som låter anställda använda internet och interna appar säkert, utan att anta att något är säkert bara för att det ligger “innanför” ett företagsnätverk. Det handlar mindre om att bygga en större mur runt ett datacenter och mer om att kontrollera vem som kopplar upp sig, vad de kopplar upp sig mot och om anslutningen ska tillåtas — varje gång.
I slutändan kan du förklara Zscalers kärnspel i en mening, känna igen var nolltillit ersätter VPN‑tänkande och förstå varför distributionsstrategi kan vara lika viktig som produktdesign.
Jay Chaudhry är en serieentreprenör mest känd som grundare och VD för Zscaler, ett företag som bidrog till att flytta företags‑säkerhet från “skydda företagsnätverket” till “säkerställ användare och appar oavsett var de är”. Före Zscaler byggde och sålde han flera säkerhets‑startups, vilket gav honom förstahandsinsikt i hur snabbt angriparbeteende och företags‑IT förändrades.
Chaudhrys fokus med Zscaler var enkelt: när arbete och applikationer flyttade bort från företagsnätverket (mot det publika internet och molntjänster) började den gamla modellen att dirigera allt genom ett centralt datacenter för inspektion att falla sönder.
Denna förändring skapade en svår avvägning för IT‑team:
Zscalers grundantagande var att säkerheten måste följa användaren, inte byggnaden.
Det som sticker ut är hur den grundarledda produktvisionen tidigt påverkade företagets strategi:
Det här var inget marknadsföringstrick; det styrde produktval, partnerskap och hur Zscaler förklarade “varför” för konservativa företagsköpare. Med tiden hjälpte den tydligheten att göra “molnlevererad säkerhet” och “nolltillit” till budgetposter — något stora företag kunde köpa, driftsätta och standardisera.
Under år byggdes företags‑säkerhet kring en enkel idé: håll det “bra” innanför företagsnätverket och bygg en mur runt det. Den muren var oftast en stapel med lokala apparater — brandväggar, webproxyer, intrångsskydd — placerade i ett fåtal datacenter. Fjärranställda kom in via VPN, vilket i praktiken “utökade” det interna nätverket till var användaren än befann sig.
När de flesta appar bodde i företagets datacenter fungerade detta hyfsat. Webb‑ och apptrafik flödade genom samma flaskhalsar där säkerhetsteam kunde inspektera, logga och blockera.
Men modellen antog två saker som började bli osanna:
När anställda blev mer mobila och SaaS‑användningen accelererade vändes trafikmönstren. Personer i kaféer behövde snabb åtkomst till Office 365, Salesforce och dussintals webbaserade verktyg — ofta utan att någonsin röra ett företagsdatacenter.
För att fortsätta tillämpa policy backhaulade många företag trafiken: skicka en användares internet‑ och SaaS‑förfrågningar via HQ först, inspektera dem och skicka dem sedan vidare. Resultatet var förutsägbart: långsam prestanda, missnöjda användare och ökat tryck att skapa undantag i kontrollerna.
Komplexiteten sköt i höjden (fler apparater, fler regler, fler undantag). VPN blev överbelastade och riskfyllda när de gav bred nätverksåtkomst. Och varje nytt filialkontor eller förvärv krävde ytterligare hårdvaruutrullning, mer kapacitetsplanering och en skörare arkitektur.
Det gapet — behovet av konsekvent säkerhet utan att tvinga allt genom en fysisk perimeter — skapade utrymmet för molnlevererad säkerhet som kan följa användaren och applikationen, inte byggnaden.
Zscalers definierande satsning var enkel att säga men svår att genomföra: leverera säkerhet som en molntjänst, placerad nära användare, istället för som lådor inne i ett företags nätverk.
I det här sammanhanget betyder “molnsäkerhet” inte att bara skydda molnservrar. Det betyder att säkerheten självt körs i molnet — så en användare i ett filialkontor, hemma eller på mobilen kopplar upp sig mot en närliggande säkerhets‑point‑of‑presence (PoP) och policy tillämpas där.
“Inlining” är som att dirigera trafik genom en säkerhetskontroll på vägen till destinationen.
När en anställd går till en webbplats eller en molnapp styrs deras anslutning genom tjänsten först. Tjänsten inspekterar vad den kan (baserat på policy), blockerar riskfyllda destinationer, skannar efter hot och vidarebefordrar sedan tillåten trafik. Målet är att användare inte behöver vara “på företagsnätverket” för att få företagsklassat skydd — säkerheten följer användaren.
Molnlevererad säkerhet förändrar vardagen för IT‑ och säkerhetsteam:
Denna modell stämmer också överens med hur företag faktiskt arbetar nu: trafiken går ofta direkt till SaaS och det publika internet, inte “tillbaka till huvudkontoret” först.
Att sätta en tredje part inline väcker reella frågor som team måste utvärdera:
Kärnsatsningen är alltså inte bara teknisk — det är operativt förtroende för att en molnleverantör kan genomdriva policy pålitligt, transparent och i global skala.
Nolltillit är en enkel princip: anta aldrig att något är säkert bara för att det är ”inne i företagsnätverket”. Istället verifiera alltid vem användaren är, vilken enhet som används och om de ska få åtkomst till en specifik app eller data — varje gång det spelar roll.
Traditionellt VPN‑tänkande är som att ge någon ett passerkort som öppnar en hel byggnad när de kommit in genom dörren. Efter att VPN är uppkopplat behandlas många system användaren som “intern”, vilket kan exponera mer än avsett.
Nolltillit vänder på modellen. Det är mer som att ge någon åtkomst till ett rum för en uppgift. Du “går inte med i nätverket” brett; du får endast nå den app du är godkänd för.
En konsult behöver åtkomst till ett projekthanteringsverktyg i två månader. Med nolltillit kan de tillåtas in i just den appen — utan att av misstag få en väg till löne‑ eller administrativa system.
En anställd använder BYOD (egen laptop) på resa. Nolltillitspolicys kan kräva starkare inloggningskontroller eller blockera åtkomst om enheten är föråldrad, okrypterad eller visar tecken på kompromiss.
Fjärrarbete blir lättare att säkra eftersom säkerhetsbeslutet följer användaren och appen, inte ett fysiskt kontorsnätverk.
Nolltillit är inte en produkt du köper och “slår på”. Det är en säkerhetsmetod som implementeras genom verktyg och policys.
Det betyder inte heller att man “inte litar på någon” på ett fientligt sätt. I praktiken innebär det att förtroende förvärvas kontinuerligt via identitetskontroller, enhetsstatus och minsta‑privilegium — så misstag och intrång sprids inte automatiskt.
Zscaler är enklast att förstå som en molnkontrollpunkt som sitter mellan människor och det de försöker nå. Istället för att lita på en företagsnätverksgräns utvärderar den varje anslutning baserat på vem användaren är och hur situationen ser ut, och tillämpar sedan rätt policy.
De flesta utrullningar kan beskrivas med fyra enkla delar:
Konceptuellt delar Zscaler trafiken i två banor:
Den separationen är viktig: den ena banan handlar om säker internetanvändning; den andra om precis åtkomst till interna system.
Beslut baseras inte på en betrodd kontors‑IP. De baseras på signaler som vem användaren är, enhetens hälsa (hanterad kontra ohanterad, uppdaterad kontra föråldrad) och var/hur de ansluter.
Görs det väl minskar detta ytan som är exponerad för attacker, begränsar sidoförflyttning om något går fel och förvandlar åtkomstkontroll till en enklare, konsekvent policymodell — särskilt när fjärrarbete och moln‑först appar blir normen.
När folk pratar om “företags‑säkerhet” tänker de ofta på privata appar och interna nätverk. Men en stor del av risken sitter på den öppna internetsidan: anställda som surfar nyheter, klickar på länkar i mejl, använder webbaserade verktyg eller laddar upp filer till webbtjänster.
En Secure Web Gateway (SWG) är kategorin skapad för att göra den vardagliga internetåtkomsten säkrare — utan att tvinga all användartrafik att hårdroteras genom ett centralt kontor.
Enkelt sagt fungerar en SWG som en kontrollerad kontrollpunkt mellan användare och publika webben. Istället för att lita på vad en enhet når tillämpar gatewayen policy och inspektion så organisationer kan minska exponering mot skadliga sidor, riskfyllda nedladdningar och oavsiktliga dataläckor.
Typiska skydd inkluderar:
Momentumet kom när arbete flyttade bort från fasta kontor och mot SaaS, webbläsare och mobila enheter. Om användare är överallt och appar är överallt lägger backhauling till latens och skapar blinda fläckar.
Molnlevererad SWG matchade den nya verkligheten: policyn följer användaren, trafik kan inspekteras nära där de kopplar upp sig och säkerhetsteam får konsekvent kontroll över huvudkontor, filialer och fjärrarbete — utan att behandla internet som ett undantag.
VPN byggdes för en tid då “vara på nätverket” var samma sak som “kunna nå apparna”. Denna idé spricker när appar finns i flera moln, SaaS och ett krympande antal lokala system.
App‑centrerad åtkomst vänder standarden. Istället för att släppa in en användare i det interna nätverket (och hoppas att segmenteringspolicys håller) kopplas användaren endast till en specifik applikation.
Konceptuellt fungerar det som en förmedlad anslutning: användaren bevisar vem de är och vad de får använda, och sedan skapas en kort, kontrollerad väg till den appen — utan att publicera interna IP‑intervall till internet och utan att ge användaren bred intern synlighet.
Nätverkssegmentering är kraftfullt, men också skört i verkliga organisationer: fusioner, platta VLAN, legacy‑appar och undantag tenderar att ackumuleras. App‑segmentering är lättare att förstå eftersom den mappar till affärsavsikt:
Det här minskar implicit förtroende och gör åtkomstpolicys läsbara: du kan granska dem per applikation och användargrupp istället för att spåra rutter och subnät.
De flesta team ersätter inte VPN över en natt. En praktisk utrullning ser ofta ut så här:
När app‑centrerad åtkomst görs väl syns vinster snabbt: färre VPN‑supportärenden, tydligare åtaksregler som säkerhet och IT kan förklara, och en smidigare användarupplevelse — särskilt för fjärr‑ och hybridanställda som bara vill att appen ska fungera utan att först “koppla upp sig mot nätverket”.
Bra säkerhetsprodukter blir inte automatiskt företagsstandarder. I praktiken innebär “distribution” inom företags‑säkerhet de vägar en leverantör använder för att nå, vinna och framgångsrikt driftsätta i stora organisationer — ofta via andra företag.
Inom säkerhet omfattar distribution typiskt:
Det här är inte valfria tillägg. Det är rör som förbinder en leverantör till budgetar, beslutsfattare och implementeringskapacitet.
Stora företag köper försiktigt. Partners tillhandahåller:
För en plattform som Zscaler beror adoption ofta på verkligt migrationsarbete — flytta användare från legacy‑VPN‑mönster, integrera identitet och finjustera policys. Partners kan göra den förändringen hanterbar.
Molnleverans skiftar affären från engångsinstallationer till prenumeration, expansion och förnyelser. Det förändrar distributionen: partners blir inte enbart “deal closers”. De kan bli löpande utrullningspartners vars incitament stämmer överens med kundutfall — om programmet är väl utformat.
Granska noga partnerincitament, kvaliteten på partner‑enablement (utbildning, playbooks, co‑selling‑stöd) och hur tydliga kundsucceshandoffs fungerar efter kontraktsskrivning. Många utrullningar misslyckas inte för att produkten är svag, utan för att ägandeskap mellan leverantör, partner och kund blir oklart.
Säkerhetsköp börjar sällan med ”vi behöver bättre säkerhet”. Det börjar oftare med en nätverksförändring som bryter de gamla antagandena: fler appar flyttar till SaaS, filialer går över till SD‑WAN eller fjärrarbete blir permanent. När trafiken inte längre flödar genom ett centralt kontor blir modellen “skydda allt på huvudkontoret” långsam, full av undantag och med blinda fläckar.
Zscaler nämns ofta i samma diskussioner som SASE och SSE eftersom dessa etiketter beskriver ett skifte i hur säkerhet levereras:
Den verkliga nyttan är inte akronymen — det är enklare drift: färre lokala boxar, enklare policyuppdateringar och mer direkt åtkomst till appar utan backhauling.
Ett företag typiskt utvärderar SSE/SASE‑liknande angreppssätt när:
När dessa triggers dyker upp kommer kategorin naturligt — nätverket har redan förändrats.
Att köpa en nolltillitsplattform är oftast den enkla delen. Att få den att fungera över röriga nätverk, ärvda applikationer och riktiga människor är där projekt lyckas — eller stannar.
Legacy‑appar är den vanligaste boven. Äldre system kan anta “inne i nätverket = betrodd”, förlita sig på hårdkodade IP‑allowlists eller gå sönder när trafik inspekteras.
Andra friktionspunkter är mänskliga: förändringsledning, omdesign av policys och debatter om “vem äger vad”. Att gå från bred nätverksåtkomst till precisa app‑regler tvingar team att dokumentera hur arbetet faktiskt sker — och det kan blottlägga länge förbisedda luckor.
Utrullningar går smidigare när säkerhet inte försöker operera själv. Förvänta dig samordning med:
Börja med en låg‑riskgrupp (t.ex. en avdelning eller en subset av konsulter) och definiera framgångsmått i förväg: färre VPN‑ärenden, snabbare appåtkomst, mätbar minskning av exponerad attackyta eller förbättrad synlighet.
Kör piloten i iterationer: migrera en appkategori i taget, finjustera policys och expandera. Målet är att lära snabbt utan att göra hela företaget till en testmiljö.
Planera för loggning och felsökning från dag ett: var loggar finns, vem som kan fråga dem, hur länge de sparas och hur larm knyts till incidenthantering. Om användare inte kan få hjälp när “appen blockeras” sjunker förtroendet snabbt — även om säkerhetsmodellen är rätt.
En praktisk (och ofta förbisedd) accelerant är interna verktyg: enkla portaler för undantagsförfrågningar, åtkomstgranskningar, app‑inventarier, utrullningsspårning och rapportering. Team bygger ofta dessa lättvikts “lim‑appar” själva istället för att vänta på leverantörens roadmap. Plattformar som Koder.ai kan hjälpa team att prototypa och leverera dessa interna webbverktyg snabbt via ett chattstyrt arbetsflöde — användbart när du behöver en React‑dashboard med ett Go/PostgreSQL‑backend och snabba iterationer medan policys och processer mognar.
Att flytta säkerhetskontroller från apparater du äger till en molnlevererad plattform kan förenkla drift — men det ändrar också vad du satsar på. Ett bra beslut handlar mindre om “nolltillit vs legacy” och mer om att förstå de nya felmoderna.
Om en plattform erbjuder webbsäkerhet, privat app‑åtkomst, policy‑genomförande och loggning minskar du verktygsspridning — men du koncentrerar också risken. En avtalskonflikt, en prisändring eller ett produktgap kan få större konsekvenser än när funktionerna sprids över flera verktyg.
Molnsäkerhet lägger ett extra hopp mellan användare och appar. När det fungerar bra märker användare knappt något. När en region har driftstörning, routningsproblem eller kapacitetsbrist kan “säkerhet” se ut som “internet är nere”. Det är mindre fråga om enskild leverantör och mer om beroendet av alltid‑på‑anslutning.
Nolltillit är ingen magisk sköld. Felaktigt avgränsade policys (för generösa, för restriktiva eller inkonsekventa) kan öka exponeringen eller störa arbete. Ju mer flexibel policymotorn är, desto mer disciplin krävs.
Fasade utrullningar hjälper: starta med ett tydligt användningsfall (t.ex. en användargrupp eller en appkategori), mät latens och åtkomstutfall, och expandera. Definiera policys i klart språk, implementera övervakning och larm tidigt och planera redundans (multi‑region routing, break‑glass‑åtkomst och dokumenterade fallback‑vägar).
Veta vilka datatyper du skyddar (reglerade vs allmänna), anpassa kontroller till efterlevnadskrav och schemalägg återkommande åtkomstgranskningar. Målet är inte köp baserat på rädsla — utan att se till att den nya modellen fallerar säkert och förutsägbart.
Zscalers återkommande lärdom är fokus: flytta policygenomförande till molnet och gör åtkomst identitetsdriven. När du utvärderar leverantörer (eller bygger en) ställ en enkel fråga: “Vad är den ena arkitektoniska satsningen som förenklar allt annat?” Om svaret är “det beror på” — förvänta dig komplexitet senare i kostnad, utrullningstid och undantag.
“Nolltillit” fungerade eftersom det översattes till ett praktiskt löfte: färre implicita förtroenden, mindre nätverksplumbing och bättre kontroll när appar flyttade off‑prem. För team betyder det att köpa utfall, inte buzzwords. Skriv ner önskade utfall (t.ex. “ingen inbound‑åtkomst”, “minsta‑privilegium till appar”, “konsekvent policy för fjärranvändare”) och mappa varje mål till konkreta kapabiliteter ni kan testa.
Företags‑säkerhet sprids genom förtroendenätverk: återförsäljare, GSIs, MSPs och molnmarknadsplatser. Grundare kan kopiera detta genom att göra produkten partner‑redo tidigt — tydlig paketering, förutsägbara marginaler, utrullningsplaybooks och delade mätvärden. Säkerhetsledare kan också använda partners: använd dem för förändringsledning, identitetsintegration och fasade migreringar istället för att försöka uppgradera alla interna team samtidigt.
Börja med ett högvolymsanvändningsfall (ofta internetåtkomst eller en kritisk app), mät före/efter och expandera.
Viktiga frågor för utrullning:
Sälj inte bara “säkerhet” — sälj en migrationsväg. Den vinnande berättelsen är ofta: smärta → enklaste första steg → mätbar vinst → expansion. Bygg onboarding och rapportering som gör värdet synligt inom 30–60 dagar.
Ett grundarvänligt mönster är att komplettera kärnprodukten med snabbyggda följeappar (bedömningsarbetsflöden, migrationsspårare, ROI‑kalkylatorer, partnerportaler). Om du vill skapa dessa utan att bygga om hela en legacy‑utvecklingspipeline är Koder.ai utformat för “vibe‑kodning” av fullstack‑appar från chat — användbart för att snabbt få interna eller kundvända verktyg i produktion och sedan iterera när distributionsrörelsen utvecklas.
Om du vill fördjupa dig, se /blog/zero-trust-basics och /blog/sase-vs-sse-overview. För paketeringsidéer, besök /pricing.
Nolltillit är en strategi där åtkomstbeslut görs per förfrågan baserat på identitet, enhetsstatus och kontext, istället för att anta att något är säkert bara för att det är ”inne i nätverket”. I praktiken betyder det:
En traditionell VPN placerar ofta en användare “på nätverket”, vilket kan exponera fler system än nödvändigt. App‑centrerad åtkomst vänder modellen:
“Inline” betyder att trafik dirigeras genom en säkerhetskontroll innan den når internet eller en molnapp. I en molnlevererad modell finns den kontrollen i en närliggande PoP (point of presence), så leverantören kan:
Målet är konsekvent säkerhet utan att tvinga all trafik genom huvudkontoret.
Backhauling skickar en fjärranvändares webb- och SaaS‑trafik till ett centralt datacenter för inspektion och skickar den sedan ut igen. Det misslyckas ofta eftersom det:
En Secure Web Gateway (SWG) skyddar användare när de surfar och använder SaaS‑appar. Vanliga SWG‑funktioner inkluderar:
Det är särskilt användbart när majoriteten av trafiken går ut mot internet och användare inte sitter bakom en enda företagsbrandvägg.
Molnlevererad säkerhet kan förenkla drift, men det ändrar vad du blir beroende av. Nyckelavvägningar att utvärdera:
En låg‑riskpilot lyckas ofta när den är snävt avgränsad och mätbar:
Målet är att lära snabbt utan att göra hela företaget till en testmiljö.
Felkonfiguration är vanligt eftersom övergången från ”nätverksåtkomst” till ”app/policy‑åtkomst” tvingar team att definiera avsikt tydligt. För att minska risken:
SSE är molnlevererade säkerhetskontroller (som SWG och privat app‑åtkomst) levererade nära användaren. SASE kombinerar samma säkerhetsmodell med nätverkssidan (ofta SD‑WAN) så att uppkoppling och säkerhet designas tillsammans.
I köppraxis:
Stora företag köper ofta via partners och behöver leveranskapacitet. Kanalpartners, SIs och MSPs hjälper genom att:
Ett starkt partner‑ekosystem kan avgöra om en plattform blir en standard eller stagnerar efter en liten pilot.