De centrala säkerhetsstandarderna i praktiken

ISO/IEC 27001 — det breda ramverket

ISO/IEC 27001 är den internationellt mest erkända standarden för informationssäkerhetsledningssystem (ISMS). Den specificerar inte tekniska kontroller direkt utan kräver att ni identifierar risker, implementerar kontroller och löpande förbättrar ert säkerhetsarbete.

Varför det är relevant för molnet: Certifieringen tvingar er att dokumentera och hantera risker kopplade till molntjänster specifikt — leverantörsberoenden, datalokalisation, incidenthantering över organisationsgränser. Tillägget ISO/IEC 27017 ger molnspecifik vägledning och ISO/IEC 27018 adresserar skydd av personuppgifter i publika moln.

Alla tre stora hyperscalers (AWS, Azure, GCP) är ISO 27001-certifierade för sin infrastruktur. Men er användning av infrastrukturen faller utanför deras certifieringsomfattning. Ni behöver ert eget ISMS.

SOC 2 Type II — bevis på att kontroller fungerar över tid

SOC 2 (Service Organization Control 2) utvecklades av AICPA och utvärderar en organisation mot fem Trust Service Criteria: säkerhet, tillgänglighet, behandlingsintegritet, konfidentialitet och dataskydd.

Skillnaden mellan Type I (kontroller existerar vid en given tidpunkt) och Type II (kontroller fungerade under en granskningsperiod, vanligtvis 6–12 månader) är avgörande. Kräv alltid Type II från era molnleverantörer och SaaS-partners.

CSA STAR — molnspecifik certifiering

Cloud Security Alliance (CSA) Security Trust Assurance and Risk (STAR) är det mest molnfokuserade ramverket. Det bygger på CSA:s Cloud Controls Matrix (CCM) och erbjuder tre nivåer:

CSA STAR är särskilt värdefullt vid leverantörsutvärdering — ni kan jämföra leverantörers CAIQ-svar sida vid sida.

CIS Benchmarks — konkreta konfigurationsstandarder

Medan ISO 27001 och SOC 2 är ramverk på ledningsnivå, ger CIS (Center for Internet Security) Benchmarks konkreta, tekniska konfigurationsriktlinjer per plattform. Det finns dedikerade CIS Benchmarks för AWS, Azure, GCP, Kubernetes, Docker och specifika operativsystem.

I Opsios NOC kör vi CIS Benchmark-skanningar som del av vår baslinjeövervakning. Det är det snabbaste sättet att hitta missar som öppna portar, avsaknad av loggning eller IAM-policyer utan MFA-krav.

Regulatoriska krav som styr standardvalet

GDPR — personuppgifter i molnet

GDPR (General Data Protection Regulation) är inte en säkerhetsstandard i sig, men ställer krav som direkt påverkar hur ni konfigurerar molntjänster:

• Artikel 32: Krav på lämpliga tekniska och organisatoriska åtgärder — kryptering, pseudonymisering, löpande testning
• Artikel 28: Krav på personuppgiftsbiträdesavtal (DPA) med molnleverantören
• Artikel 33: Anmälningsskyldighet till IMY (Integritetsskyddsmyndigheten) inom 72 timmar vid personuppgiftsincident

Praktiskt: Använd eu-north-1 (Stockholm) eller Sweden Central som primär region. Se till att backups och disaster recovery inte replikerar data till regioner utanför EU/EES utan rättslig grund. Efter Schrems II-domen räcker inte Privacy Shield — ni behöver Standard Contractual Clauses (SCCs) och en Transfer Impact Assessment om data berör USA-baserade tjänster.

NIS2-direktivet — ny verklighet från 2025

NIS2 utvidgar kretsen av organisationer som omfattas jämfört med det ursprungliga NIS-direktivet. Svenska organisationer inom sektorer som energi, transport, hälsa, digital infrastruktur, offentlig förvaltning och tillverkning berörs direkt.

Centrala krav som påverkar molnsäkerheten:

• Riskhantering: Dokumenterade policies för riskanalys och informationssäkerhet
• Incidentrapportering: Tidig varning inom 24 timmar, fullständig rapport inom 72 timmar
• Leverantörskedjan: Ni måste hantera säkerhetsrisker i er leverantörskedja — inklusive molnleverantörer och MSP:er
• Sanktioner: Böter upp till 10 miljoner euro eller 2 % av global omsättning

Det innebär att ert val av molnleverantör och managerad tjänsteleverantör blir en compliance-fråga, inte bara en teknisk fråga.

PCI DSS 4.0 — för organisationer som hanterar kortdata

Om ni processar, lagrar eller överför kortuppgifter gäller PCI DSS oavsett om ni kör on-premises eller i molnet. Version 4.0 introducerar hårdare krav på kryptering, MFA och löpande säkerhetstestning. I molnmiljöer krävs extra dokumentation som visar var kortdata kan finnas och hur ansvarsfördelningen ser ut.

Implementering i praktiken — vad vi ser i produktion

Steg 1: Kartlägg vilka standarder som faktiskt gäller er

Börja inte med att implementera allt. Kartlägg:

1. Vilka regulatoriska krav gäller (GDPR alltid, NIS2 sannolikt, PCI DSS om kortdata)?

2. Vilka kontraktuella krav ställer era kunder (SOC 2 Type II är vanligt i B2B SaaS)?

3. Vilken risknivå har era arbetsbelastningar?

Steg 2: Automatisera compliance-kontroller

Manuella granskningar en gång per år är otillräckliga. Använd:

• AWS Security Hub med CIS AWS Foundations Benchmark
• Azure Policy med inbyggda regeluppsättningar för ISO 27001 och CIS
• GCP Security Command Center för automatiserad hotdetektering
• Tredjepartsverktyg som Prisma Cloud, Wiz eller Lacework för multi-cloud

Steg 3: Implementera minsta privilegium-principen (least privilege) på riktigt

Det räcker inte att ha IAM. Granska aktivt:

• Ta bort oanvända roller och användare
• Använd kortlivade credentials (AWS STS, Azure Managed Identities)
• Kräv MFA för alla konsolinloggningar och privilegierade API-anrop
• Implementera Service Control Policies (SCPs) i AWS Organizations eller Management Groups i Azure

Steg 4: Kryptera allt — men hantera nycklarna rätt

Kryptering i vila och transit är baslinje. Det som avgör säkerheten är nyckelhanteringen:

• Använd kundhanterade nycklar (CMK) via AWS KMS, Azure Key Vault eller GCP Cloud KMS
• Rotera nycklar automatiskt
• Separera nyckelhantering från dataåtkomst i IAM-policyer

Steg 5: Logga, övervaka, agera

En standard utan övervakning är ett dokument, inte ett skydd. Minimum:

• Aktivera CloudTrail (AWS), Activity Log (Azure) eller Cloud Audit Logs (GCP)
• Centralisera loggar (SIEM-lösning)
• Definiera alerting-regler för säkerhetskritiska händelser
• Ha en dokumenterad och testad incidentresponsplan

Molnsäkerhet med Opsio

Jämförelse: Standarder och ramverk i överblick

Vanliga misstag vi åtgärdar

Från Opsios SOC/NOC vill vi lyfta de vanligaste bristerna vi ser när organisationer migrerar till molnet utan att ha standarderna på plats:

1. "Vi är compliant för att leverantören är certifierad" — Nej. Er konfiguration är ert ansvar.

2. Överdriven användning av root/admin-konton — Brott mot samtliga standarders åtkomstkontrollkrav.

3. Loggar som ingen tittar på — Terabyte i S3 utan alerting är inte övervakning.

4. Ingen testning av incidentresponsplan — NIS2 kräver inte bara att ni har en plan, utan att den fungerar.

5. Dataöverföringar till tredjeland utan rättslig grund — Fortfarande förvånansvärt vanligt.

Molnmigrering med rätt säkerhetsgrund

Hur Opsio arbetar med säkerhetsstandarder

Som managerad tjänsteleverantör med 24/7 SOC/NOC integrerar vi standardefterlevnad direkt i driften. Det innebär att compliance inte är ett årligt projekt utan en del av varje deployment, varje konfigurationsändring och varje incidentrespons.

Vi hjälper organisationer att:

• Kartlägga vilka standarder som gäller baserat på bransch, geografi och datatyper
• Implementera automatiserade compliance-kontroller i AWS, Azure och GCP
• Köra kontinuerliga CIS Benchmark-skanningar med åtgärdsflöden
• Hantera incidentrespons i linje med NIS2:s tidskrav
• Producera revisionsunderlag för ISO 27001 och SOC 2-granskningar

Managerade molntjänster

Säkerhetsstandarder är inte ett mål ni uppnår en gång — de är en process ni upprätthåller varje dag. Organisationer som behandlar dem som en pappersövning kommer obönhörligen att upptäcka bristerna vid en incident eller en IMY-granskning. Organisationer som bygger in standarderna i sin driftsmodell sover bättre om natten — och det gör deras kunder också.

Vanliga frågor

Vilken säkerhetsstandard är viktigast för molntjänster?

Det beror på bransch och regelverk, men ISO/IEC 27001 är den bredaste och mest internationellt erkända standarden. För organisationer som hanterar personuppgifter inom EU är GDPR-efterlevnad ett juridiskt krav, inte valfritt. SOC 2 Type II är särskilt relevant om ni köper SaaS-tjänster från amerikanska leverantörer.

Vad innebär delat ansvar i molnet?

Molnleverantören ansvarar för säkerheten av infrastrukturen — fysiska datacenter, hypervisor, nätverksryggrad. Ni ansvarar för säkerheten i molnet: konfiguration, åtkomstkontroll, krypteringsnyckelhantering, patchning av OS och applikationer. De flesta säkerhetsincidenter vi ser i Opsios SOC beror på kundens felkonfiguration, inte leverantörens brister.

Hur påverkar NIS2 svenska organisationer som använder molntjänster?

NIS2 utvidgar kretsen av organisationer som omfattas och ställer krav på riskhantering, incidentrapportering inom 24 timmar samt säkerhet i leverantörskedjan. Det innebär att ni måste kunna visa att era molnleverantörer och MSP:er uppfyller kraven — inte bara lita på att de gör det.

Räcker det att molnleverantören är certifierad?

Nej. AWS, Azure och Google Cloud är certifierade för sin del av ansvarsmodellen. Er konfiguration, era IAM-policyer och era arbetsbelastningar omfattas inte av leverantörens certifiering. Ni behöver egen compliance-validering, antingen internt eller via en managerad tjänsteleverantör.

Hur ofta bör vi granska vår molnsäkerhet mot standarderna?

Kontinuerligt, inte årligen. Automatiserade verktyg som AWS Security Hub, Azure Policy och tredjepartslösningar bör köras dygnet runt. Formella revisioner — interna eller externa — bör ske minst kvartalsvis, med fullständig extern audit årligen.