Sårbarhetshantering i molnet: så skyddar du din infrastruktur
Group COO & CISO
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
Sårbarhetshantering i molnet: så skyddar du din infrastruktur
Sårbarhetshantering i molnet är den systematiska processen att kontinuerligt inventera, skanna, prioritera och åtgärda säkerhetsbrister i molnbaserad infrastruktur, applikationer och konfigurationer. Till skillnad från traditionella datacenter kräver molnets dynamiska natur och delade ansvarsmodell en helt annan approach — med realtidsövervakning, API-driven upptäckt och riskbaserad prioritering som centrala byggstenar. Denna guide ger dig praktiska metoder och verktyg för att bygga ett robust program.
Viktiga slutsatser
- Kontinuerlig tillgångsinventering är grunden – du kan inte skydda det du inte ser
- Delat ansvar innebär att din molnleverantör inte patchar dina applikationer eller rättar dina felkonfigurationer
- Riskbaserad prioritering slår "fixa allt direkt" – fokusera på exponerade, affärskritiska system först
- NIS2-direktivet och GDPR ställer konkreta krav på proaktiv sårbarhetshantering för svenska organisationer
- Automatisering via IaC och CI/CD-pipelines gör säkerhet till en del av utvecklingsflödet, inte en efterhandskontroll
Varför molnmiljöer kräver en annan modell för sårbarhetshantering
I ett traditionellt datacenter äger du hela stacken. Du vet vilka servrar som finns, vilka portar som är öppna och vem som har fysisk åtkomst. I molnet ser verkligheten annorlunda ut.
En typisk AWS-miljö hos en medelstort svenskt företag kan ha hundratals resurser — EC2-instanser, Lambda-funktioner, S3-buckets, RDS-databaser, IAM-roller — som skapas, ändras och rivs varje dag. Varje resurs är en potentiell attackvektor. Varje IAM-policy med för breda behörigheter är en latent sårbarhet som ingen CVE-skanner hittar.
Från Opsios NOC i Karlstad ser vi tre mönster som återkommer hos nästan varje ny kund:
1. Felkonfigurationer snarare än zero-days. Majoriteten av molnsäkerhetsincidenter beror inte på sofistikerade attacker utan på publikt exponerade S3-buckets, databasinstanser utan kryptering eller security groups som tillåter 0.0.0.0/0 på port 22.
2. Skugg-IT i molnet. Utvecklare snurrar upp resurser för tester som aldrig rivs ner. Dessa "glömda" resurser saknar patchning, övervakning och härdning.
3. IAM-komplexitet. Behörighetspolicyer växer organiskt tills ingen har överblick över vem som kan göra vad. Principen om minsta privilegium är mer undantag än regel.
Flexeras State of the Cloud har år efter år visat att säkerhet och governance konsekvent rankas bland de största molnutmaningarna — och det stämmer med vad vi ser i praktiken.
Vill ni ha expertstöd med sårbarhetshantering i molnet?
Våra molnarkitekter hjälper er med sårbarhetshantering i molnet — från strategi till implementation. Boka ett kostnadsfritt 30-minuters rådgivningssamtal utan förpliktelse.
Den delade ansvarsmodellen: vad som faktiskt är ditt ansvar
Alla tre stora molnleverantörer — AWS, Azure och Google Cloud — bygger på en delad ansvarsmodell. Leverantören ansvarar för säkerheten av molnet (fysisk infrastruktur, hypervisor, nätverksfabrik). Du ansvarar för säkerheten i molnet (data, applikationer, konfigurationer, identiteter).
| Lager | AWS/Azure/GCP ansvarar | Du ansvarar |
|---|---|---|
| Fysisk infrastruktur | ✅ Datacenter, nätverk, hårdvara | — |
| Hypervisor/Compute-plattform | ✅ Patchning av underliggande plattform | — |
| Operativsystem (IaaS) | — | ✅ Patchning, härdning |
| Runtime/Middleware (PaaS) | ✅ Delvis | ✅ Applikationskonfiguration |
| Applikationskod | — | ✅ Kodsäkerhet, beroenden |
| Data | — | ✅ Kryptering, åtkomstkontroll |
| Identiteter och behörigheter | — | ✅ IAM-policyer, MFA, federation |
| Nätverkskonfiguration | — | ✅ Security groups, NACLs, WAF |
Det här innebär att din molnleverantör inte skickar ett larm när din applikation har en SQL-injektion eller när en utvecklare skapar en IAM-roll med :-behörigheter. Det är ditt jobb — eller din managerade tjänsteleverantörs.
Fem byggstenar i ett moget program för sårbarhetshantering
1. Kontinuerlig tillgångsinventering
Du kan inte skydda det du inte vet finns. Det låter självklart, men i praktiken har de flesta organisationer sämre överblick över sin molnmiljö än de tror.
En fungerande inventering kräver:
- API-driven resursdiscovery via AWS Config, Azure Resource Graph eller Google Cloud Asset Inventory
- Taggningspolicyer som tvingar fram metadata (ägare, miljö, kostnadscenter, dataklassificering) på varje resurs
- Automatisk drift-detektion som larmar när resurser skapas utanför godkända IaC-pipelines
Opsios SOC använder realtidsinventering som korreleras med säkerhetsfynd. En sårbarhet i en internetexponerad produktionsdatabas med kunddata prioriteras radikalt annorlunda jämfört med samma CVE i en isolerad testmiljö.
2. Sårbarhetsskanning i flera lager
Molnmiljöer kräver skanning i flera dimensioner samtidigt:
| Skanningstyp | Vad den hittar | Verktygsexempel |
|---|---|---|
| CSPM (Cloud Security Posture Management) | Felkonfigurationer, policyavvikelser | AWS Security Hub, Prisma Cloud, Wiz |
| Infrastruktursårbarhet | CVE:er i OS och paket | Amazon Inspector, Qualys, Rapid7 |
| Containerskanning | Sårbara basimages, beroenden | Trivy, Snyk Container, ECR Scanning |
| IaC-skanning | Osäkra konfigurationer innan deploy | Checkov, tfsec, KICS |
| DAST/SAST | Applikationssårbarheter | Burp Suite, SonarQube, Semgrep |
Det kritiska är att dessa skanningar körs kontinuerligt, inte som en kvartalsvis övning. I vår erfarenhet har en genomsnittlig molnmiljö hundratals konfigurationsändringar per vecka. En månatlig skanning missar majoriteten av den faktiska risken.
3. Riskbaserad prioritering
En färsk skanning av en medelstort molnmiljö genererar typiskt tusentals fynd. Att försöka åtgärda alla samtidigt är omöjligt och kontraproduktivt. Riskbaserad prioritering är vad som skiljer mogna program från kaotiska.
Effektiv prioritering väger ihop:
- CVSS-poäng — men aldrig som enda faktor
- Exploaterbarhet — finns det aktiva exploits i the wild? (CISA KEV-katalogen är en utmärkt källa)
- Exponering — är resursen internetexponerad eller isolerad i ett privat subnät?
- Affärskritikalitet — hanterar systemet kunddata, betalningar eller kritiska processer?
- Kompensierande kontroller — finns det WAF, nätverkssegmentering eller andra skyddslager framför?
I Opsios SOC använder vi en fyrgradig prioriteringsmatris som kombinerar dessa faktorer. En kritisk CVE (CVSS 9.8) i en internetexponerad produktionstjänst med kunddata får en SLA på 24 timmar. Samma CVE i en isolerad utvecklingsmiljö bakom VPN hanteras inom 30 dagar.
4. Automatiserad åtgärd och patchhantering
Manuell patchning skalas inte i molnet. De organisationer som lyckas bäst automatiserar så mycket som möjligt:
- Golden AMIs/Container Images — förbyggda, härdade och patchade basimages som uppdateras veckovis
- Immutable infrastructure — istället för att patcha en server, ersätter du den med en ny instans från senaste image
- Automatisk remediation via AWS Systems Manager, Azure Update Management eller Ansible
- Policy-as-Code med Open Policy Agent (OPA) eller AWS SCP:er som förhindrar osäkra konfigurationer från att överhuvudtaget driftsättas
Det bästa sättet att hantera en sårbarhet är att förhindra den från att nå produktion. IaC-skanning i CI/CD-pipelinen fångar felkonfigurationer innan de deployar. Container image-skanning blockerar sårbara images från att pushas till registret.
5. Rapportering, spårning och efterlevnad
Utan dokumentation och spårbarhet är ditt sårbarhetshanteringsprogram osynligt för ledning och revisorer. Ett moget program inkluderar:
- Dashboard i realtid med aktuell riskbild, trender och SLA-efterlevnad
- Ägarskap per fynd — varje sårbarhet har en ansvarig person eller team med tydlig deadline
- Undantagshantering — formell process för att acceptera risker som inte kan åtgärdas omedelbart, med dokumenterad motivering och tidsbegränsning
- Revisionslogg — fullständig historik över fynd, åtgärder och beslut
NIS2-direktivet (artikel 21) kräver explicit att organisationer implementerar policyer för hantering av sårbarheter, inklusive "disclosure" av sårbarheter. GDPR (artikel 32) kräver tekniska åtgärder som är lämpliga för risknivån. Utan ett dokumenterat program riskerar du inte bara intrång — du riskerar regulatoriska sanktioner.
Multicloud-utmaningen: konsistens över plattformar
Enligt Flexeras State of the Cloud använder majoriteten av företag mer än en molnplattform. Det skapar en direkt utmaning för sårbarhetshantering: varje plattform har egna säkerhetsverktyg, egna konfigurationsmodeller och egna terminologier.
AWS Security Hub, Azure Defender for Cloud och Google SCC är alla bra verktyg — men de ser bara sin egen plattform. En organisation med arbetsbelastningar på både AWS (eu-north-1, Stockholm) och Azure (Sweden Central) behöver antingen:
1. Ett övergripande CSPM-verktyg som Wiz, Prisma Cloud eller Orca som normaliserar fynd över plattformar
2. En managerad SOC-tjänst som Opsios, där analytiker korrelerar och prioriterar fynd oavsett plattform
Det farliga alternativet — att köra separata program per plattform — leder oundvikligen till inkonsistenta policyer, duplicerat arbete och säkerhetsluckor i gränsytan mellan plattformarna.
Vanliga misstag vi ser i produktion
Efter att ha hanterat hundratals molnmiljöer har Opsios team identifierat återkommande anti-mönster:
"Vi skannar, men åtgärdar inte." Organisationen har verktygen, genererar rapporter, men saknar processer och ägarskap för att faktiskt fixa problemen. Resultatet är en växande backlog av kända sårbarheter som aldrig krymper.
"Allt är kritiskt." Utan riskbaserad prioritering behandlas alla fynd lika, vilket leder till utmattning hos utvecklingsteamen. De slutar lyssna på säkerhetsteamets larm.
"Säkerhet kommer sist." Sårbarhetsskanning sker först efter driftsättning istället för att vara integrerad i CI/CD-pipelinen. Det är dyrare, långsammare och mer riskfyllt att fixa saker i produktion.
"Vi litar på att molnleverantören fixar det." En missförståelse av delat ansvar som vi fortfarande stöter på regelbundet. Din molnleverantör patchar inte din applikationskod, konfigurerar inte dina security groups och hanterar inte dina IAM-policyer.
Komma igång: en pragmatisk plan i tre faser
Om du inte har ett strukturerat program idag, börja inte med att köpa ett dyrt CSPM-verktyg. Börja med grunderna:
Fas 1 (vecka 1–4): Synlighet
- Aktivera AWS Config / Azure Resource Graph
- Implementera taggningspolicy
- Aktivera inbyggd skanning (Amazon Inspector, Azure Defender)
- Kartlägg dina internetexponerade resurser
Fas 2 (månad 2–3): Process
- Definiera prioriteringsmatris och SLA:er per allvarlighetsgrad
- Tilldela ägarskap för åtgärder till utvecklingsteam
- Integrera IaC-skanning i CI/CD-pipelines
- Inför veckovis genomgång av kritiska fynd
Fas 3 (månad 4–6): Mognad
- Implementera automatiserad remediation för vanliga felkonfigurationer
- Bygg dashboard med KPI:er (MTTD, MTTR, öppna fynd per allvarlighetsgrad)
- Formalisera undantagshantering och riskaceptansprocess
- Utvärdera CSPM-verktyg eller managerad SOC-tjänst för 24/7-övervakning
Opsios perspektiv
Sårbarhetshantering i molnet är inte ett verktyg — det är en process, en kultur och ett åtagande. Verktyg är nödvändiga men aldrig tillräckliga. Det som skiljer organisationer som faktiskt minskar sin risk från de som bara genererar rapporter är tre saker: tydligt ägarskap, riskbaserad prioritering och en genuin vilja att åtgärda — inte bara dokumentera — sina brister.
Från vårt 24/7 SOC ser vi att de organisationer som har mest framgång med sin molnsäkerhet är de som integrerar sårbarhetshantering i sitt dagliga arbetsflöde, inte behandlar det som en separat aktivitet som hanteras kvartalsvis. Molnet rör sig snabbt. Din säkerhet måste göra det också.
Vanliga frågor
Vad skiljer sårbarhetshantering i molnet från traditionell on-prem?
Molnmiljöer är dynamiska: resurser skapas och rivs inom minuter, ansvaret delas med leverantören och attackytan inkluderar API:er, IAM-policyer och konfigurationer som inte finns i traditionella datacenter. Det kräver agentlösa skanningsmetoder, API-integrationer och kontinuerlig inventering istället för schemalagda nätverksskanningar.
Hur ofta bör vi skanna vår molnmiljö efter sårbarheter?
Kontinuerligt — inte veckovis eller månadsvis. Molnresurser lever i minuter till timmar. Opsios SOC kör realtidsskanning via CSPM-verktyg som reagerar på konfigurationsändringar direkt. Komplettera med djupare applikationsskanningar minst veckovis och penetrationstester kvartalsvis.
Räcker det med molnleverantörens inbyggda säkerhetsverktyg?
AWS Security Hub, Azure Defender och Google SCC ger en bra grund, men de täcker bara sin egen plattform. I en multicloud-miljö behöver du ett övergripande verktyg eller en managerad SOC-tjänst som korrelerar fynd över alla miljöer och prioriterar utifrån affärskontext.
Vilka regelverk ställer krav på sårbarhetshantering?
NIS2-direktivet (artikel 21) kräver att väsentliga och viktiga entiteter hanterar sårbarheter proaktivt. GDPR (artikel 32) kräver lämpliga tekniska åtgärder. ISO 27001 (Annex A.12.6) och SOC 2 har explicita kontroller. Efterlevnad kräver dokumenterade processer, inte bara verktyg.
Vad kostar det att inte ha strukturerad sårbarhetshantering?
Enligt IBM Cost of a Data Breach Report är intrång i molnmiljöer konsekvent dyrare än on-prem-incidenter. Lägg till regulatoriska böter under NIS2 (upp till 10 miljoner EUR eller 2 % av global omsättning) och GDPR, och kostnaden för passivitet överstiger snabbt kostnaden för proaktivt skydd.
Om författaren
Group COO & CISO at Opsio
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
Editorial standards: This article was written by a certified practitioner and peer-reviewed by our engineering team. We update content quarterly to ensure technical accuracy. Opsio maintains editorial independence — we recommend solutions based on technical merit, not commercial relationships.