Modellen för delat ansvar — på riktigt

Alla tre stora molnleverantörer (AWS, Azure, GCP) arbetar efter en modell för delat ansvar. Konceptet är enkelt: leverantören ansvarar för säkerheten av molnet (fysisk infrastruktur, hypervisor, nätverk), medan ni ansvarar för säkerheten i molnet (data, applikationer, identiteter, konfiguration).

I praktiken är gränsen luddigare än vad leverantörernas diagram antyder, och den varierar beroende på tjänstemodell.

Notera att identitet och data alltid är kundens ansvar. Det spelar ingen roll om ni kör serverless Lambda-funktioner eller fullblåsta EC2-instanser — hur ni hanterar åtkomst och skyddar data är ert problem.

En managerad molnsäkerhetstjänst tar inte över ert ansvar. Den ger er specialistkompetens och verktyg för att uppfylla det ansvaret. Den distinktionen är avgörande, inte minst ur ett NIS2-perspektiv där ledningsansvaret inte kan delegeras bort.

Managerade molntjänster

De fyra pelarna i managerad molnsäkerhet

1. Kontinuerlig övervakning och hotdetektion (SOC)

En Security Operations Center (SOC) är hjärtat i managerad säkerhet. Kärnfunktionen är enkel: samla in loggar och telemetri från hela er molnmiljö, korrelera händelser i realtid, och eskalera det som kräver mänsklig bedömning.

I praktiken innebär det:

• SIEM-plattform (t.ex. Microsoft Sentinel, Splunk, eller Elastic) som aggregerar loggar från CloudTrail, VPC Flow Logs, GuardDuty, Defender for Cloud och applikationslager
• SOAR-automation som hanterar kända händelsetyper utan manuell inblandning — exempelvis isolering av en komprometterad instans eller blockering av en känd skadlig IP
• Analysttriage dygnet runt — larm klockan 03:00 en lördagsnatt hanteras med samma hastighet som klockan 10:00 en tisdag

Opsio driver SOC/NOC från Karlstad och Bangalore, vilket ger äkta dygnet-runt-kapacitet utan att förlita sig på jour-personal som väcks mitt i natten. Skillnaden i responstid är mätbar och betydande.

2. CSPM — Cloud Security Posture Management

CSPM-verktyg skannar er molnmiljö kontinuerligt mot definierade säkerhetspolicyer och flaggar avvikelser. Tänk på det som en automatisk revisor som aldrig sover.

Konkreta saker CSPM fångar:

• Okrypterade EBS-volymer eller RDS-instanser
• S3-buckets med publikt läsbara policyer
• IAM-roller utan MFA-krav
• Resurser som inte taggats enligt er governance-policy
• Avvikelser från CIS Benchmarks eller er organisations egna baseline

Verktyg som AWS Security Hub, Azure Defender for Cloud och tredjepartslösningar som Prisma Cloud eller Wiz ger god täckning. Det kritiska är inte vilket verktyg ni väljer — det är att någon faktiskt agerar på resultaten. CSPM utan uppföljning är bara en dyr lista på problem.

3. Identitets- och åtkomsthantering (IAM)

Identitetsbaserade attacker dominerar hotbilden. Enligt CrowdStrikes Global Threat Report har attackmetoder som bygger på stulna eller svaga autentiseringsuppgifter ökat kraftigt de senaste åren. Att få bukt med IAM handlar om tre principer:

Minsta privilegium (least privilege): Varje användare, tjänstekonto och roll ska ha exakt de rättigheter som krävs — inte fler. I AWS innebär det att ni slutar använda *-wildcards i IAM-policyer och börjar med deny-by-default.

Multifaktorautentisering (MFA): MFA ska vara obligatoriskt för alla interaktiva konton, utan undantag. Speciellt root-konton och breakglass-konton. Helst hårdvarunycklar (FIDO2/WebAuthn), i andra hand push-baserad autentisering. SMS-baserad MFA är bättre än inget men bör fasas ut.

Tidsbegränsad åtkomst: Privilegierad åtkomst bör beviljas just-in-time med automatisk återkallelse. AWS IAM Identity Center, Azure PIM (Privileged Identity Management) och verktyg som CyberArk eller HashiCorp Boundary stödjer detta mönster.

4. Incidenthantering och katastrofåterställning

Att ha en incidenthanteringsplan (IRP) är ett krav under NIS2. Att den faktiskt fungerar kräver regelbunden övning.

Incidenthanteringsprocessen bör följa NIST CSF:s faser:

1. Identifiera — upptäck och triagera händelsen

2. Skydda — begränsa spridning (isolera drabbade resurser)

3. Upptäcka — bekräfta omfattning och attackvektor

4. Svara — eliminera hotet och återställ

5. Återhämta — verifiera integritet och återgå till normal drift

NIS2-specifika krav: Tidig varning till berörd CSIRT inom 24 timmar, fullständig incidentnotifiering inom 72 timmar. Er MSP bör ha dokumenterade runbooks som stödjer dessa tidsramar.

Katastrofåterställning: Backuper som aldrig testats är en illusion av säkerhet. Kör fullständiga DR-övningar minst kvartalsvis. Verifiera att RTO (Recovery Time Objective) och RPO (Recovery Point Objective) håller i praktiken, inte bara på papper.

Molnsäkerhet

Efterlevnad: NIS2, GDPR och branschstandarder

Svenska organisationer som rör sig i molnet möter ett allt tätare regulatoriskt landskap. De viktigaste ramverken att förhålla sig till:

Integritetsskyddsmyndigheten (IMY) har de senaste åren visat att man menar allvar med GDPR-tillsynen. Sanktionsavgifter mot svenska organisationer har ökat, och Schrems II-problematiken kring tredjelandsöverföringar är fortfarande relevant om ni använder amerikanska SaaS-tjänster.

En managerad säkerhetstjänst bör hjälpa er med kontinuerlig efterlevnadsövervakning — inte bara en engångsrevision som är inaktuell veckan efter den slutförs.

Molnsäkerhet

Att välja rätt MSP för molnsäkerhet

Alla managerade tjänsteleverantörer är inte skapade lika. Här är de frågor som avslöjar skillnaden mellan en mogen säkerhetspartner och en som bara säljer vidare ett SIEM-verktyg:

Operativ mognad:

• Har de ett eget SOC med analytiker, eller förlitar de sig på en fjärdepartsplattform?
• Hur ser eskaleringskedjan ut klockan 02:00 en söndag?
• Kan de visa dokumenterade incidenthanteringsprocesser?

Teknisk bredd:

• Stödjer de er specifika molnplattform (eller multicloud-miljö)?
• Har de erfarenhet av er branschs regulatoriska krav?
• Arbetar de med Infrastructure as Code (IaC) för säkerhetskonfiguration, eller klickar de manuellt i konsoler?

Transparens:

• Får ni tillgång till era egna loggar och dashboards, eller är ni beroende av deras rapporter?
• Hur mäter och rapporterar de SLA:er?
• Vad händer med era data och konfigurationer om ni avslutar avtalet?

Kostnad och värde:

• Förstår de FinOps-aspekten — att säkerhet inte ska kosta mer än värdet den skyddar?
• Kan de hjälpa er optimera säkerhetskostnader utan att sänka skyddsnivån?

Managerad DevOps

Implementering i praktiken: en fasad approach

Att gå från noll till fullständig managerad molnsäkerhet över en helg är en fantasi. En realistisk implementering ser ut ungefär så här:

Fas 1 — Inventering och baseline (vecka 1–4)

Kartlägg befintlig molnmiljö, identifiera alla konton och prenumerationer, aktivera grundläggande loggning (CloudTrail, Azure Activity Log), kör en initial CSPM-skanning och genomför en IAM-revision.

Fas 2 — Grundläggande skydd (vecka 4–8)

Implementera MFA överallt, härda IAM-policyer enligt minsta privilegium, aktivera kryptering i vila och transit, konfigurera nätverkssegmentering, och börja mata loggar till SIEM.

Fas 3 — Proaktiv övervakning (vecka 8–12)

SOC-integration med ert larmflöde, SOAR-automation för kända scenarion, CSPM-policyer anpassade efter er organisations krav, och regelbundna sårbarhetsskanningar.

Fas 4 — Mognad och optimering (löpande)

Incident-övningar och tabletop exercises, DR-tester, FinOps-optimering av säkerhetskostnader, löpande anpassning till nya hot och regulatoriska förändringar.

Molnmigrering

Kostnaden för att inte göra något

Diskussionen om managerad molnsäkerhet landar ofta i en kostnadsdiskussion. "Vad kostar det?" är en rimlig fråga, men den intressanta motfrågan är: "Vad kostar det att inte ha det?"

Flexeras State of the Cloud har konsekvent visat att molnkostnader generellt är en av organisationers största utmaningar, och säkerhetsincidenter kan multiplicera dessa kostnader dramatiskt. En ransomware-attack som krypterar produktionsdata innebär inte bara lösensumman — det är stillestånd, förlorade intäkter, kundbortfall, regulatoriska böter (NIS2 och GDPR), och den långsiktiga reputationsskadan som är svårast att kvantifiera.

Opsio ser regelbundet organisationer som spenderar mer på akut incidenthantering under en enda vecka än vad ett helt år av managerad säkerhet hade kostat. Det är en dyr form av lärande.

Cloud FinOps

Vanliga frågor

Vad ingår i en managerad molnsäkerhetstjänst?

Typiskt ingår 24/7 SOC-övervakning, SIEM/SOAR-integration, sårbarhetsskanning, CSPM, incidenthantering, efterlevnadsrapportering och rådgivning kring arkitektur. Omfattningen varierar mellan leverantörer — det viktigaste är att avtalet tydligt definierar vem som ansvarar för vad i den delade ansvarsmodellen.

Kan en MSP garantera att vi inte drabbas av intrång?

Nej, ingen seriös leverantör lovar det. Däremot minskar en kompetent MSP sannolikheten dramatiskt genom proaktiv övervakning, snabb incidentrespons och kontinuerlig härdning. Målet är att göra er till ett svårare mål och att begränsa skadan om något ändå sker.

Hur påverkar NIS2-direktivet vårt val av säkerhetsleverantör?

NIS2 ställer hårdare krav på incidentrapportering (24 timmar för tidig varning, 72 timmar för full rapport), leverantörskedjans säkerhet och ledningsansvar. Er MSP bör kunna visa dokumenterade processer för dessa krav och ha erfarenhet av att stödja NIS2-omfattade organisationer.

Vad är skillnaden mellan CSPM och SIEM?

CSPM (Cloud Security Posture Management) skannar kontinuerligt er molnmiljö efter felkonfigurationer och regelbrott — det handlar om förebyggande. SIEM (Security Information and Event Management) samlar in och korrelerar loggar i realtid för att upptäcka aktiva hot. Ni behöver båda: CSPM minskar attackytan, SIEM fångar det som tar sig igenom.

Hur snabbt kan en managerad SOC svara på en incident?

Med rätt automation och SOAR-plattform kan en mogen SOC triagera och eskalera en kritisk händelse inom minuter. Opsios SOC/NOC i Karlstad och Bangalore arbetar dygnet runt, vilket innebär att inga larm hamnar i en obevakad inkorg klockan tre på natten.