IAM: den viktigaste kontrollen du har

Identity and Access Management (IAM) är den enskilt mest effektiva säkerhetskontrollen i en molnmiljö. Ändå ser vi regelbundet miljöer med root-konton som saknar MFA, IAM-roller med :-behörigheter och service accounts vars nycklar inte har roterats på över ett år.

Minsta privilegium i praktiken

Principen om minsta privilegium (least privilege) är enkel att förstå men svår att implementera konsekvent. Så här gör vi det hos Opsios kunder:

1. Utgå från noll behörigheter. Varje ny roll eller användare startar utan åtkomst.

2. Använd policyer kopplade till grupper, inte individer. Det minskar konfigurationsspridning dramatiskt.

3. Inför tidsbegränsad åtkomst (just-in-time). AWS IAM Access Analyzer och Azure PIM (Privileged Identity Management) gör det möjligt att bevilja admin-åtkomst i begränsade tidsfönster.

4. Granska oanvända behörigheter kvartalsvis. AWS IAM Access Advisor och liknande verktyg visar vilka behörigheter som faktiskt används.

MFA är inte valfritt

Multifaktorautentisering (MFA) bör vara aktiverat på samtliga mänskliga konton – utan undantag. För service accounts och automatisering är alternativet korta sessionstokens och regelbunden rotation av credentials. Vi rekommenderar hårdvarubaserade FIDO2-nycklar för privilegierade konton; SMS-baserad MFA har kända svagheter via SIM-swap-attacker.

Kryptering: i vila, under transport och i användning

Kryptering är en hygienfaktor som bör vara påslagen överallt – inte något man aktiverar selektivt. De tre molnjättarna erbjuder alla kryptering som standard för de flesta tjänster, men "standard" betyder inte alltid "tillräckligt".

Kryptering i vila: Använd Customer Managed Keys (CMK) via AWS KMS, Azure Key Vault eller Google Cloud KMS. Det ger dig kontroll över nyckelrotation och möjlighet att återkalla åtkomst oberoende av leverantören.

Kryptering under transport: TLS 1.3 som minimum. Interna tjänst-till-tjänst-kommunikationer bör också krypteras – inte bara trafik mot internet. Service mesh-lösningar som Istio hanterar detta transparent.

Kryptering i användning: Confidential Computing (AMD SEV, Intel SGX) erbjuds nu av alla tre stora molnleverantörer. Det är relevant för känsliga arbetsbelastningar inom finans och hälso- och sjukvård, men overhead i prestanda gör det ännu inte till standard överallt.

Svensk datalagring och GDPR

För svenska organisationer som lyder under GDPR och potentiellt NIS2-direktivet är kryptering inte bara god praxis – det är ett juridiskt krav under artikel 32 (GDPR). Att köra arbetsbelastningar i eu-north-1 (Stockholm) eller Sweden Central minskar latens och förenklar efterlevnad, men det är kryptering och åtkomstkontroll som avgör om ni faktiskt uppfyller kraven. Molnsäkerhet

Nätverkssäkerhet: segmentering slår perimeterskydd

Det gamla tankesättet med en hård perimeter och mjuk insida fungerar inte i molnet. Varje VPC, subnät och säkerhetsgrupp bör konfigureras enligt zero trust-principen: verifiera varje anslutning, oavsett om den kommer inifrån eller utifrån.

Praktiska åtgärder

• Privata subnät som standard. Databaser och backend-tjänster ska aldrig ha publika IP-adresser. Använd NAT-gateways eller VPC-endpoints för utgående trafik.
• Säkerhetsgrupper med explicit allow-list. Undvik 0.0.0.0/0 på ingress. Vi har sett hundratals exponerade RDP-portar (3389) och SSH-portar (22) i kundmiljöer vi tar över.
• Centraliserad utgående filtrering. AWS Network Firewall, Azure Firewall eller en tredjeparts NGFW ger kontroll över vilka domäner och IP-adresser era arbetsbelastningar får kommunicera med – avgörande för att stoppa data-exfiltration.
• VPC Flow Logs / NSG Flow Logs aktiverade. Utan loggar finns det inget att utreda vid en incident.

Kontinuerlig övervakning: SOC dygnet runt

Punktvisa penetrationstest och årliga revisioner har sitt värde, men de fångar ögonblicksbilder. Moderna molnmiljöer förändras dagligen – nya resurser skapas via IaC-pipelines, auto-scaling adderar instanser, och utvecklare pushar konfigurationsändringar. Utan kontinuerlig övervakning hinner felkonfigurationer existera i timmar eller dagar innan de upptäcks.

Vad vi övervakar i Opsios SOC

Vårt SOC i Karlstad och Bangalore korrelerar händelser från flera källor dygnet runt:

• CloudTrail / Azure Activity Log / GCP Audit Logs – vem gjorde vad, när, från vilken IP
• GuardDuty / Defender for Cloud / Security Command Center – hotdetektering baserad på beteendeanalys
• SIEM-plattform – korrelation av molnhändelser med endpoint-data och nätverksloggar
• Automatiserade playbooks – vid bekräftad incident kan vi isolera resurser och rotera credentials inom minuter

Enligt Datadog State of Cloud har den genomsnittliga molnmiljöns komplexitet ökat markant de senaste åren, med fler tjänster per organisation och kortare livslängd per resurs. Det gör manuell granskning ohållbar. Managerad DevOps

Efterlevnad: NIS2, GDPR och branschspecifika krav

NIS2-direktivet

NIS2 trädde i kraft i EU och ställer krav på organisationer inom ett brett spektrum av sektorer – inte bara traditionell kritisk infrastruktur. För molnbaserade verksamheter innebär det:

• Riskhanteringsåtgärder som dokumenteras och implementeras
• Incidentrapportering inom 24 timmar till behörig myndighet (i Sverige: MSB och IMY beroende på typ)
• Leverantörskedjesäkerhet – ni behöver verifiera att er molnleverantör och MSP uppfyller kraven
• Ledningsansvar – styrelsen kan hållas personligt ansvarig

GDPR i molnkontext

GDPR:s artikel 28 kräver ett personuppgiftsbiträdesavtal med varje molnleverantör. Artikel 32 kräver tekniska och organisatoriska åtgärder – kryptering, åtkomstkontroll, loggning. Schrems II-domen påverkar fortfarande dataöverföringar till USA, även om EU-US Data Privacy Framework finns på plats. Vi rekommenderar att hålla persondata inom EU/EES som grundregel och vara medvetna om vilka support-verktyg från leverantören som eventuellt exponerar data utanför regionen.

Compliance-as-Code

Manuell efterlevnad skalas inte. Vi implementerar compliance-as-code med verktyg som AWS Config Rules, Azure Policy och Open Policy Agent (OPA) i Kubernetes-miljöer. Varje avvikelse genererar en automatisk alert till vårt SOC. Det innebär att efterlevnad verifieras kontinuerligt, inte vid årsrevision. Cloud FinOps

Policy-as-Code och IaC: förebygg istället för att reparera

Infrastructure as Code (IaC) via Terraform, Pulumi eller AWS CDK ger en unik möjlighet att bygga in säkerhet innan resurser når produktion. Det kräver dock att säkerhetsregler kodifieras:

• Pre-commit hooks som kör tfsec eller checkov och blockerar deploys med kända felkonfigurationer
• CI/CD-pipeline med säkerhetsgating – ingen merge till main utan godkänd säkerhetsscanning
• Drift-detektering – om någon ändrar en resurs manuellt i konsolen flaggas det omedelbart

Det här skiftet – från reaktiv incidenthantering till proaktiv förebyggande – är den mest effektiva investeringen en organisation kan göra i molnsäkerhet. Molnmigrering

Incidenthantering: planen du hoppas aldrig behöva

En incidenthanteringsplan (IRP) som aldrig testats är lika användbar som en brandsläckare utan tryck. Vi kräver att varje kund har en dokumenterad och övad plan med:

1. Detektering och triage – automatiserade alerts med severity-klassning

2. Inneslutning – isolering av drabbade resurser utan att förstöra forensiska bevis

3. Utredning – logganalys, root cause analysis

4. Återställning – från verifierade backups, med validering innan trafik återställs

5. Efteranalys – blameless post-mortem med konkreta åtgärder

Vi genomför tabletop-övningar kvartalsvis med våra managerade kunder. Det låter som overhead tills den dagen en incident faktiskt inträffar.

Vanliga frågor

Vem ansvarar för säkerheten i en molnmiljö?

Ansvaret delas mellan molnleverantören och kunden enligt shared responsibility-modellen. Leverantören säkrar den underliggande infrastrukturen, medan kunden ansvarar för konfiguration, identitetshantering, datakryptering och åtkomstkontroll. I praktiken är det kundens felkonfigurationer som orsakar de flesta incidenter.

Hur påverkar NIS2-direktivet vår molnsäkerhet?

NIS2 utökar kretsen av verksamheter som omfattas och ställer krav på riskhantering, incidentrapportering inom 24 timmar och leverantörskedjesäkerhet. Om ni kör arbetsbelastningar i molnet behöver ni dokumentera hur ert delade ansvar med molnleverantören uppfyller direktivets krav.

Räcker det med molnleverantörens inbyggda säkerhetsverktyg?

De inbyggda verktygen – som AWS GuardDuty, Azure Defender och Google Security Command Center – ger en bra grund. Men de kräver korrekt konfiguration, kontinuerlig uppföljning och korrelation mellan tjänster. De flesta organisationer behöver ett dedikerat SOC som övervakar, triagerar och agerar dygnet runt.

Vad är det vanligaste misstaget vid molnsäkerhet?

Felkonfigurerade S3-buckets, öppna säkerhetsgrupper och för breda IAM-roller. Problemet är sällan att rätt verktyg saknas – det är att ingen granskar konfigurationen löpande. Automatiserade guardrails via IaC och policy-as-code eliminerar de flesta av dessa misstag.

Hur ofta bör vi göra säkerhetsgranskningar av vår molnmiljö?

Kontinuerligt, inte kvartalsvis. Moderna molnmiljöer förändras för snabbt för periodiska revisioner. Kombinera automatiserad compliance-scanning (t.ex. AWS Config, Azure Policy) med regelbundna manuella genomgångar minst var sjätte månad.