Varför traditionell säkerhet inte räcker

Organisationer som försöker applicera perimeterbaserad säkerhet på cloud native-miljöer stöter på tre grundläggande problem:

Efemära arbetsbelastningar. Containrar startas och stoppas kontinuerligt. Agentbaserade verktyg som behöver installeras och konfigureras per instans hinner inte med. Du behöver säkerhet som är deklarativ — definierad i kod och automatiskt tillämpad vid varje deploy.

Mikrotjänstkommunikation. I en monolitisk applikation sker interna anrop inom processen. I en mikrotjänstarkitektur sker de över nätverket, ofta via HTTP/gRPC. Utan mTLS (mutual TLS) via ett service mesh som Istio eller Linkerd kan angripare som tagit sig in i klustret avlyssna och manipulera trafik mellan tjänster.

Delat ansvar. AWS, Azure och GCP ansvarar för säkerheten av molnet. Du ansvarar för säkerheten i molnet. Det innebär att en felkonfigurerad S3-bucket, en alltför bred IAM-roll eller en Kubernetes-pod som körs som root är ditt problem — inte leverantörens.

Molnsäkerhet med Opsio

Shift-left: säkerhet i CI/CD-pipelinen

Det mest kostnadseffektiva sättet att hantera säkerhet i cloud native-miljöer är att flytta den åt vänster — att fånga problem tidigt i utvecklingsprocessen istället för i produktion. Konkret innebär det:

Steg 1: Scanning av container images

Varje container image som byggs i CI-pipelinen ska skannas mot kända sårbarheter (CVE:er). Verktyg som Trivy, Grype eller Snyk Container integreras direkt i pipeline-steget. Bygg som innehåller kritiska sårbarheter ska blockeras automatiskt.

Steg 2: Infrastructure as Code-validering

Terraform-moduler och Helm-charts ska valideras mot säkerhetspolicyer innan de appliceras. Open Policy Agent (OPA) med Rego-policyer eller Checkov kan verifiera att exempelvis inga Security Groups tillåter 0.0.0.0/0 på port 22, eller att alla RDS-instanser har kryptering aktiverat.

Steg 3: Software Bill of Materials (SBOM)

NIS2-direktivet ställer krav på supply chain-säkerhet. Genom att generera en SBOM för varje release har du full spårbarhet över vilka beroenden som ingår — och kan snabbt identifiera vilka system som påverkas nästa gång en kritisk sårbarhet som Log4Shell dyker upp.

Steg 4: Secrets management

Hårdkodade nycklar och lösenord i kod eller miljövariabler är fortfarande en av de vanligaste orsakerna till intrång. Använd HashiCorp Vault, AWS Secrets Manager eller Azure Key Vault med automatisk rotation.

Managerad DevOps

Runtime-skydd: när shift-left inte räcker

Hur bra din pipeline än är kommer det finnas hot som först manifesterar sig i runtime: zero-day-exploits, komprometterade beroenden som klarar scanning, eller insiderhot. Runtime-skydd är det sista försvarslagret.

Falco (open source, CNCF-projekt) övervakar systemanrop i Kubernetes-pods och larmar vid avvikande beteende — till exempel om en container plötsligt startar en shell-process eller försöker läsa /etc/shadow. Vi på Opsio kör Falco som standardkomponent i våra managerade Kubernetes-miljöer, med larm direkt till vårt SOC.

eBPF-baserade verktyg som Cilium och Tetragon ger djup nätverks- och processvisibilitet utan overhead. Cilium ersätter traditionella Kubernetes Network Policies med identitetsbaserade policyer och ger full observerbarhet av öst-väst-trafik.

Admission controllers som Kyverno eller OPA Gatekeeper hindrar osäkra arbetsbelastningar från att ens starta i klustret. Typiska policyer: inga privilegierade containrar, inga containrar som körs som root, krav på resource limits, krav på specifika labels.

Compliance: NIS2, GDPR och molnbaserade arkitekturer

Regulatoriska krav är inte ett separat spår — de ska vara inbäddade i arkitekturen. Två regelverk är särskilt relevanta:

NIS2-direktivet (tillämpligt sedan oktober 2024) utökar kretsen av organisationer som omfattas av cybersäkerhetskrav och skärper kraven på incidentrapportering, riskhantering och supply chain-säkerhet. För cloud native-miljöer innebär det:

• Dokumenterad riskanalys av Kubernetes-infrastrukturen
• Incidentrapportering till berörd myndighet inom 24 timmar
• Verifierbar supply chain-säkerhet (SBOM, signerade images)

GDPR ställer krav på dataskydd by design och by default (artikel 25). I en mikrotjänstarkitektur där persondata kan flöda mellan tjänster i olika regioner kräver det medveten design: kryptering av data i transit och at rest, åtkomstkontroll per tjänst, och loggning av alla dataåtkomster.

Kör du i eu-north-1 (Stockholm) eller Azure Sweden Central har du dataresidency i Sverige, men GDPR-compliance handlar om mer än var datan lagras. Det handlar om vem som har åtkomst, hur den skyddas och att du kan bevisa det.

Molnsäkerhet och compliance

Jämförelse: säkerhetsverktyg för cloud native-miljöer

Opsios perspektiv: vad vi ser i produktion

Från vårt SOC/NOC, som bemannas dygnet runt i Karlstad och Bangalore, har vi identifierat återkommande mönster hos organisationer som migrerar till cloud native-arkitekturer:

1. Kubernetes-kluster med default-konfiguration. Majoriteten av nya kluster vi granskar saknar Network Policies, kör pods som root och har överdimensionerade RBAC-roller. Det är som att flytta in i ett nytt hus och lämna alla dörrar olåsta.

2. Ingen centraliserad loggning. Utan centraliserad, oföränderlig loggning (exempelvis till en separat AWS-account via CloudTrail + S3 Object Lock) kan angripare radera sina spår. Vi konfigurerar alltid loggar som skickas till en separat säkerhetsaccount som produktionsteamet inte har skrivrättigheter till.

3. Bristande FinOps-koppling. Säkerhet och kostnad hänger ihop. Överflödiga resurser betyder fler angreppsytor. Oanvända IAM-roller och stale access keys är både en säkerhetsrisk och ett tecken på bristande styrning.

Cloud FinOps

4. Avsaknad av incidentresponsplan för containermiljöer. Många har en generell IR-plan men den täcker inte scenarion som komprometterad container image i registry, lateral movement mellan pods, eller cryptomining i ett namnutrymme med lösa resource limits.

Kom igång: en praktisk checklista

Om du vill stärka säkerheten i din cloud native-miljö, börja här:

• [ ] Aktivera Kubernetes audit logging och skicka till centraliserad SIEM
• [ ] Implementera Network Policies som default-deny mellan namespaces
• [ ] Skanna alla container images i CI/CD med automatisk blockering av kritiska CVE:er
• [ ] Konfigurera Pod Security Standards (restricted) som baseline
• [ ] Implementera mTLS mellan tjänster via service mesh
• [ ] Generera SBOM för varje produktionsrelease
• [ ] Testa incidentresponsplanen kvartalsvis — inklusive container-specifika scenarion
• [ ] Granska IAM-roller och ta bort oanvända behörigheter månadsvis

Molnmigrering med säkerhet från start

Vanliga frågor

Vad skiljer cloud native security från traditionell molnsäkerhet?

Traditionell molnsäkerhet applicerar befintliga verktyg — brandväggar, agenter, perimeterbaserat skydd — ovanpå molnresurser. Cloud native security är designad för efemära containrar, mikrotjänster och deklarativ infrastruktur. Säkerheten är inbakad i arkitekturen via policy-as-code, service mesh och automatiserad scanning i CI/CD-pipelinen, inte tillagd i efterhand.

Behöver vi cloud native security om vi redan kör i AWS eller Azure?

Ja. Molnleverantörerna ansvarar för säkerheten av molnet (hypervisor, fysisk infrastruktur), men du ansvarar för säkerheten i molnet — konfiguration, IAM, nätverkspolicyer, container images och applikationskod. En felkonfigurerad Security Group eller en alltför bred IAM-roll är ditt ansvar.

Hur påverkar NIS2 vår cloud native-strategi?

NIS2-direktivet kräver bland annat riskbaserad säkerhetsstyrning, incidentrapportering inom 24 timmar och supply chain-säkerhet. För cloud native-miljöer innebär det dokumenterade policyer för container-scanning, SBOM-generering (Software Bill of Materials) och kontinuerlig övervakning — alla delar som bör automatiseras i CI/CD-pipelinen.

Vad kostar det att implementera cloud native security?

Kostnaden varierar beroende på miljöns storlek och mognad. Open source-verktyg som Falco, Trivy och OPA är gratis men kräver kompetens att drifta. En managerad SOC-tjänst som övervakar Kubernetes-miljöer startar typiskt från några tiotusentals SEK per månad. Investeringen är dock betydligt lägre än kostnaden för ett dataintrång — och ofta ett krav för att uppfylla NIS2.

Kan vi hantera cloud native security internt utan extern partner?

Tekniskt ja, men det kräver djup kompetens inom Kubernetes-säkerhet, plattformsspecifika skyddsmekanismer och dygnet-runt-bevakning. Enligt CNCFs Annual Survey är kompetensbrist konsekvent den största utmaningen kring Kubernetes-adoption. Många organisationer väljer en hybridmodell: en managerad tjänsteleverantör (MSP) hanterar SOC/NOC och baseline-säkerhet, medan det interna teamet äger arkitekturbeslut och applikationssäkerhet.