Azures säkerhetsverktyg: vad de gör — och inte gör

Microsoft investerar enormt i Azures säkerhetsplattform. Men verktygen är möjliggörare, inte automatiska lösningar. Här är en ärlig bedömning av de viktigaste:

Det här är verkligheten: verktygen finns, men utan processer och kompetens att driva dem blir de dyr shelfware. Molnsäkerhet med Opsio

Zero Trust i Azure — från princip till produktion

Zero Trust har blivit ett modeord, men principen är sund och direkt tillämpbar i Azure. "Lita aldrig, verifiera alltid" innebär i praktiken fyra saker:

Identitetsverifiering överallt

Varje åtkomstförsök — oavsett om det kommer inifrån företagsnätverket eller från en kafélaptop — ska verifieras. I Azure innebär det:

• MFA som standard via Entra ID, utan undantag för "interna" användare
• Conditional Access-policyer som väger in enhetsstatus, plats, risknivå och applikationskänslighet
• Privileged Identity Management (PIM) för just-in-time-åtkomst till administrativa roller

Minsta möjliga privilegium

Vi ser regelbundet Azure-prenumerationer där utvecklare har Contributor-rättigheter på hela prenumerationen, eller där service principals har Owner-roll "för att det funkar". Det är inte Zero Trust — det är en tidsfråga innan det blir en incident.

Opsios metod: vi kartlägger samtliga roller och rättigheter, identifierar överprivilegierade konton och implementerar RBAC (Role-Based Access Control) med granulär scopning ner till resursgruppsnivå.

Mikrosegmentering av nätverk

Platta nätverk i molnet är en angripares dröm. Azure Virtual Networks med NSG:er, Application Security Groups och Azure Firewall ger verktygen — men segmenteringen måste spegla verksamhetens riskbild, inte bara IT-avdelningens nätverksdiagram.

Kontinuerlig beteendeanalys

Microsoft Sentinel och Defender for Cloud ger anomalidetektering, men signalerna måste tolkas av människor dygnet runt. Det är här skillnaden mellan att ha ett SIEM och att ha en SOC blir avgörande. Opsios 24/7 SOC/NOC i Karlstad och Bangalore innebär att anomalier utreds inom minuter — inte nästa arbetsdag. Managerade molntjänster

Dataskydd och kryptering i praktiken

Kryptering i Azure är inte komplicerat att aktivera — det komplicerade är att göra det konsekvent och att hantera nycklarna korrekt.

Kryptering i vila (at rest): Azure krypterar som standard med plattformshanterade nycklar. Men för organisationer under NIS2 eller med känsliga data rekommenderar vi kundhanteradeenycklar (CMK) via Azure Key Vault, med HSM-skydd (Hardware Security Module) för de mest kritiska arbetsbelastningarna.

Kryptering under transport: TLS 1.2 som minimum — TLS 1.3 där det stöds. Vi ser fortfarande Azure-miljöer med TLS 1.0 aktiverat "för bakåtkompatibilitet". Det är en risk som sällan motiverar den kompatibilitet det ger.

Kryptering under bearbetning: Azure Confidential Computing med DCsv3-serien ger kryptering även under bearbetning via Intel SGX- eller AMD SEV-SNP-enklaver. Det här är relevant för organisationer som hanterar särskilt känsliga data — exempelvis inom hälso- och sjukvård eller finanssektorn.

Nyckelhanterings-disciplin: Key Vault med RBAC-åtkomstmodellen (inte den äldre Access Policy-modellen), automatisk nyckelrotation och fullständig loggning via Azure Monitor. Vi ser konsekvent att organisationer som hanterar nycklar manuellt eller spritt i kod har sämre säkerhetspostur.

NIS2 och GDPR — vad Azure-konfiguration faktiskt innebär

Regelverk är inte abstrakta — de har konkreta tekniska konsekvenser för er Azure-miljö.

NIS2-direktivet kräver bland annat:

• Dokumenterad riskanalys och riskhantering (mappas mot Azure Policy och Defender for Cloud)
• Incidentrapportering inom 24 timmar (kräver fungerande SOC-process och Sentinel-integration)
• Leveranskedjesäkerhet (granskning av tredjepartstjänster och marknadsplatsappar i Azure)
• Ledningsansvar (tekniska rapporter som styrelsen faktiskt kan agera på)

GDPR och datalokalitet: Azure Sweden Central (Gävle/Sandviken) och Azure eu-north-1 i AWS-termer innebär att data kan lagras i Sverige. Men datalokalitet handlar om mer än var VM:en står — supportärenden, telemetri och backup-replikering måste också kartläggas. IMY:s tillsynspraxis sedan Schrems II gör detta till en reell risk, inte en teoretisk fråga.

Opsio hjälper organisationer att mappa regulatoriska krav mot konkreta Azure-konfigurationer — inte som en engångsövning utan som en löpande process. Cloud FinOps och styrning

Opsios metod: från granskning till dygnet-runt-skydd

Vi tror inte på säkerhet som ett projekt med start och slut. Vår metod för Azure-säkerhet följer en cykel:

1. Säkerhetsgranskning. Systematisk genomgång av er Azure-miljö mot CIS Azure Foundations Benchmark, Microsofts egna säkerhetsriktlinjer och relevanta regulatoriska krav. Resultatet är en prioriterad åtgärdslista — inte en PDF som ingen läser.

2. Arkitektur och härdning. Implementering av rekommenderade åtgärder: Zero Trust-arkitektur, nätverkssegmentering, identitetsstyrning, kryptering. Vi arbetar i Terraform och Bicep för att säkerställa att all konfiguration är reproducerbar och versionshanterad (Infrastructure as Code). Managerad DevOps

3. Kontinuerlig övervakning. Integration med Opsios 24/7 SOC/NOC via Microsoft Sentinel. Incidenthantering med definierade runbooks, eskaleringsvägar och SLA:er. Det är här de flesta interna team tappar tempo — dygnet-runt-bemanning är dyrt och svårt att rekrytera till.

4. Löpande optimering. Kvartalsvis säkerhetsgenomgång, uppdatering av policyer efter nya hot och Azure-funktioner, och kontinuerlig utbildning av kundens team. Molnmigrering

Vanliga frågor

Vad ingår i en Azure-säkerhetsgranskning?

En granskning omfattar typiskt identitets- och åtkomstkonfiguration, nätverkssegmentering, krypteringsstatus, Defender for Cloud Secure Score, efterlevnadsgap mot relevanta regelverk (NIS2, GDPR, ISO 27001) samt en prioriterad åtgärdsplan. Hos Opsio kompletterar vi med insikter från vår 24/7 SOC-drift.

Räcker Microsoft Defender for Cloud som säkerhetslösning?

Defender for Cloud är ett starkt fundament för synlighet och policyhantering, men det är inte en komplett säkerhetslösning i sig. Det kräver korrekt konfiguration, kontinuerlig uppföljning av rekommendationer och integration med SOC-processer för incidenthantering. Många organisationer behöver kompletterande verktyg och expertis.

Hur påverkar NIS2 vår Azure-miljö?

NIS2-direktivet, som gäller inom EU sedan oktober 2024, ställer krav på riskhantering, incidentrapportering och leveranskedjesäkerhet för väsentliga och viktiga entiteter. I praktiken innebär det att ni behöver dokumenterad säkerhetsarkitektur, regelbundna granskningar och bevisad övervakning — oavsett om ni kör i Azure eller annan molnplattform.

Vad är skillnaden mellan Azure-säkerhet och generell molnsäkerhet?

Grundprinciperna (Zero Trust, minsta privilegium, kryptering) är desamma, men Azure har sina egna verktyg, terminologier och konfigurationsfallgropar. Entra ID, NSG-regler, Key Vault-policyer och Defender for Cloud kräver Azure-specifik expertis för att implementeras korrekt.

Varför räcker det inte med ett internt team för Azure-säkerhet?

Interna team har ofta djup kunskap om verksamheten men begränsad kapacitet för dygnet-runt-övervakning, och kompetensen att hålla jämna steg med Azures snabba utvecklingstakt kräver dedikerade resurser. En managerad säkerhetstjänst kompletterar det interna teamet med SOC-bemanning, specialistkunskap och processer som är svåra att bygga upp på egen hand.