Cloudflare Zero Trust för SMB: Ersätt VPN på en eftermiddag

Det traditionella företags-VPN:et bygger på en föråldrad idé: en gång inne på nätverket är du betrodd. Det gör VPN till både en flaskhals för prestanda och en risk för säkerhet, eftersom ett kapat konto ofta får tillgång till hela det interna nätet. För ett mindre bolag finns det idag ett enklare och säkrare alternativ, identitetsbaserad åtkomst per applikation, som med Cloudflare Zero Trust kan sättas upp på en eftermiddag.

Jag hjälper mindre bolag att gå från VPN till identitetsbaserad åtkomst inom cybersäkerhet, och det här är en konkret beskrivning av hur det går till och varför det är värt bytet. Cloudflare är inte det enda alternativet, det finns motsvarande lösningar från flera leverantörer, men det är ett pragmatiskt val för en SMB, eftersom det har en generös instegsnivå och inte kräver att ni river ut befintlig infrastruktur. Resonemanget i den här artikeln gäller i grunden oavsett vilken leverantör ni väljer; det är modellen som är poängen.

Varför VPN inte längre räcker

Problemet med VPN är inte tekniken i sig utan modellen. När en användare ansluter får hen i praktiken en plats på det interna nätverket, med bred räckvidd. Blir kontot kapat, eller ansluter en infekterad enhet, sprider sig problemet lätt. Dessutom skalar VPN dåligt med distansarbete och blir snabbt en supportbörda. Det här är samma grundproblem som hela Zero Trust-tänket adresserar, vilket jag går igenom bredare i Zero Trust-arkitektur för SMB.

Modellen: åtkomst per applikation, inte per nätverk

Alternativet vänder på logiken. Istället för att släppa in användaren på nätverket exponeras varje intern applikation individuellt bakom en åtkomstkontroll. Användaren autentiserar med er befintliga identitetsleverantör, och Cloudflare släpper bara igenom till de specifika applikationer hen har rätt till. Det interna nätverket exponeras aldrig. En tunnel-anslutning från er sida betyder att ni inte behöver öppna inkommande portar i brandväggen alls.

Den arkitektoniska skillnaden är värd att stanna vid. Med VPN flyttas gränsen för förtroende till nätverkskanten: är du innanför, är du betrodd. Med åtkomst per applikation flyttas gränsen ända fram till varje enskild tjänst, och beslutet fattas på nytt vid varje anrop utifrån vem du är och vilken enhet du använder. En angripare som lyckas kapa ett konto når i den modellen bara exakt de applikationer det kontot hade rätt till, inte ett helt internt nät att röra sig fritt i. Det är skillnaden mellan att ge bort en huvudnyckel och att ge bort en nyckel till ett enda rum.

Var modellen kommer från

Tankesättet är inte nytt eller exotiskt, det är samma princip som stora teknikbolag tillämpat internt i åratal under namn som beskriver att man slutat lita på det interna nätverket och i stället verifierar varje åtkomst individuellt. Det som hänt är att verktygen för att göra detta blivit tillgängliga och prisvärda även för mindre bolag, så att man inte längre behöver ett eget plattformsteam för att bygga det. Cloudflare och liknande tjänster paketerar i praktiken en enterprise-arkitektur till något en SMB kan sätta upp själv. Det är därför bytet är moget att göra nu, även för bolag som tidigare avfärdat det som för avancerat.

Eftermiddagen i praktiken

• Koppla in identitetsleverantören. Anslut Microsoft 365 eller Google Workspace så att inloggning sker mot konton ni redan hanterar.
• Etablera en utgående tunnel från er miljö, så att inga inkommande portar behöver öppnas.
• Definiera applikationer och regler. För varje intern tjänst anger ni vilka grupper som får åtkomst.
• Lägg till villkor. Kräv MFA, och begränsa vid behov till hanterade enheter eller vissa länder.
• Testa och fasa ut VPN. Verifiera åtkomsten för varje roll innan ni stänger det gamla.

Här gör jag mid-vägs alltid en inventering av vilka interna tjänster som faktiskt nås via VPN idag. Listan är ofta kortare än man tror, vilket gör bytet snabbare. Vill ni ha den gjord ingår det i cybersäkerhetsuppdraget.

Vad ni vinner

Resultatet är konkret: snabbare åtkomst eftersom trafiken inte tvingas genom en enda VPN-koncentrator, mindre attackyta eftersom inget nätverk exponeras, och bättre spårbarhet eftersom varje åtkomst loggas per användare och applikation. För de flesta SMB är det dessutom billigare än att underhålla och skala en VPN-lösning. Den här typen av loggning och åtkomstkontroll stödjer också kraven i NIS2 artikel 21.

Vad modellen inte löser

Det är viktigt att vara ärlig om gränserna. Att ersätta VPN med åtkomst per applikation tar bort det breda nätverksförtroendet, men det gör inte er applikation säker i sig, en sårbar tjänst är fortfarande sårbar för den som har behörighet till den. Modellen ersätter inte heller behovet av enhetshantering, av att hålla system uppdaterade, eller av en genomtänkt behörighetsstruktur. Tänk på det som att byta ut en dålig ytterdörr mot en bra: det är en stor förbättring, men ni behöver fortfarande lås på de inre dörrarna. Bytet är ett steg i en bredare Zero Trust-ansats, inte hela den.

Var jag brukar börja

Börja med en enda applikation, inte hela parken. Sätt upp åtkomst per applikation för en intern tjänst, verifiera flödet, och rulla sedan ut resten med samma mönster. Att försöka migrera allt på en gång är det vanligaste sättet att göra ett enkelt byte onödigt stressigt. En bra första kandidat är ett internt verktyg som idag bara nås via VPN och som har en avgränsad användargrupp, då blir både uppsättningen och utvärderingen enkel, och ni får en mall att kopiera för resten. Se hur jag lägger upp liknande migreringar i kundcase.

Relaterat

• Schrems II och dataöverföring till USA 2026: Status och alternativ
• SBOM med Syft + Grype: Sårbarhetshantering i CI/CD
• Passkeys i produktion: Implementera WebAuthn i Next.js

Vill du ta det vidare?

Jag hjälper mindre bolag att ersätta VPN med identitetsbaserad åtkomst, ofta på en eftermiddag per första applikation. Boka ett samtal så ser vi över er åtkomst.