Microsofts Rules of Engagement — vad gäller

Sedan juni 2017 behöver du inte längre skicka in en förfrågan till Microsoft innan du kör pentest mot dina egna Azure-resurser. Det var en stor förändring som tog bort en historisk flaskhals.

Men det finns tydliga gränser. Microsofts Penetration Testing Rules of Engagement förbjuder:

• DoS-attacker — du får inte stresstesta Azures infrastruktur
• Port scanning mot andra kunders resurser — enbart dina egna prenumerationer
• Social engineering mot Microsofts personal
• Försök att bryta hypervisor-isolering eller testa underliggande Azure-fabric
• Testning mot delade tjänster som DNS-servrar eller infrastrukturnoder

Vad du får göra: allt som riktar sig mot dina egna resurser inom dina prenumerationer. Det inkluderar nätverksskanning, exploatering av sårbarheter, lateral rörelse mellan dina egna tjänster, identitetsattacker mot din Entra ID-tenant och dataexfiltrering från dina egna Storage Accounts.

Praktiskt tips: dokumentera ditt scope noggrant innan teststart. Använd Azure Resource Tags för att säkerställa att testare enbart rör resurser inom scopet. Om ni har produktionsresurser i samma prenumeration som testmiljön, var extremt tydliga med avgränsningen.

Pentest-metodik anpassad för Azure

Rekognosering och informationsinsamling

Första fasen i ett Azure-pentest handlar om att kartlägga attackytan. Till skillnad från on-prem-miljöer finns mycket information publikt exponerad:

• DNS-enumeration: Azure-tjänster använder förutsägbara subdomäner (.azurewebsites.net, .blob.core.windows.net, .database.windows.net). Verktyg som MicroBurst eller SubFinder kan identifiera exponerade tjänster.
• Entra ID-enumeration: Med verktyg som AADInternals kan du identifiera giltiga användarnamn, tenantinformation och federationskonfiguration utan autentisering.
• Storage Account-discovery: Publikt exponerade blob-containers är fortfarande ett av de vanligaste fynden. Vi ser det regelbundet i Opsios dagliga drift — utvecklingsteam som skapar Storage Accounts med default-åtkomst och glömmer stänga ner dem.

Identitets- och åtkomsttestning

Det här är kärnan i ett modernt Azure-pentest. Identiteter är den nya perimetern — en komprometterad användare med Global Administrator-rättigheter ger full kontroll över hela miljön.

Centrala testområden:

• Lösenordspolicyer och MFA: Testar vi password spraying mot Entra ID? Fungerar Conditional Access-regler som tänkt? Finns det service accounts utan MFA?
• RBAC-roller: Har utvecklare Contributor-rättigheter på prenumerationsnivå istället för resursgruppsnivå? Finns det Custom Roles med oavsiktligt breda behörigheter?
• App Registrations och Service Principals: Har applikationsregistreringar kvarglömda hemligheter (secrets) med långa giltighetstider? Kan en komprometterad service principal eskalera till högre rättigheter?
• Conditional Access-bypass: Kan en angripare kringgå Conditional Access genom att använda legacy authentication protocols eller Device Code-flöden?

Vi har vid upprepade tillfällen sett miljöer där Conditional Access såg robust ut på pappret men där en enda undantagsregel — tillagd "tillfälligt" för felsökning — öppnade en bakdörr.

Nätverks- och tjänstesäkerhet

Även i en zero trust-modell spelar nätverkssegmentering roll i Azure:

• Network Security Groups (NSG): Finns det NSG:er med alltför generösa inbound-regler? Port 3389 (RDP) eller 22 (SSH) öppet mot internet?
• Azure Firewall och Application Gateway: Testar vi WAF-konfigurationen? Kan vi bypassa regler?
• Private Endpoints vs. publika endpoints: Använder tjänster som Azure SQL, Key Vault och Storage Accounts privata endpoints, eller är de exponerade mot internet med IP-baserade brandväggsregler?
• VNet Peering: Hur ser den laterala rörelseförmågan ut mellan VNets? Kan en komprometterad resurs i ett utvecklings-VNet nå produktionsresurser?

Dataskydd och kryptering

• Key Vault-åtkomst: Vem kan läsa hemligheter? Finns det access policies som ger breda rättigheter?
• Storage Account-kryptering: Används Customer Managed Keys (CMK) där det krävs? Är SAS-tokens tidsbegränsade och scopade?
• Disk Encryption: Är OS- och datadiskar på virtuella maskiner krypterade med Azure Disk Encryption?

Verktyg för Azure-pentest

En kombination av automatiserade verktyg och manuell expertis ger bäst resultat. Automatiserade verktyg fångar kända felkonfigurationer snabbt. Manuella tester krävs för att identifiera logikfel, kedja samman fynd till attackvägar och bedöma verklig affärspåverkan.

Vanliga fynd — vad Opsios SOC ser i praktiken

Baserat på de tester och incidenter vi hanterar finns tydliga mönster:

1. Överbredsatta RBAC-roller — Den absolut vanligaste bristen. Organisationer ger Contributor eller Owner på prenumerationsnivå för att "det ska fungera snabbt". Resultatet: en enda komprometterad identitet ger åtkomst till allt.

2. Exponerade Storage Accounts — Blob-containers med public access-nivå satt till "Container" eller "Blob" istället för "Private". Ofta utvecklingsresurser som hamnat i produktionsprenumerationer.

3. Saknad eller bristfällig Conditional Access — MFA konfigurerat men med undantag för service accounts, break-glass-konton utan tillräcklig övervakning, eller legacy authentication-protokoll som inte blockeras.

4. Kvarglömda App Registrations — Service Principals med secrets som inte roteras, ibland med rättigheter som överskrider vad applikationen behöver.

5. Bristande loggning — Azure Activity Log aktivt men Diagnostic Settings saknas för specifika resurser. Utan loggar kan du varken upptäcka intrång eller genomföra forensisk analys efteråt.

Azure-pentest och regelefterlevnad

NIS2-direktivet

NIS2 ställer krav på att väsentliga och viktiga entiteter genomför riskbedömningar och vidtar tekniska åtgärder för att hantera cybersäkerhetsrisker. Penetrationstestning är ett av de mest konkreta sätten att validera att era säkerhetsåtgärder faktiskt fungerar — inte bara på pappret utan i praktiken. Svenska organisationer som omfattas av NIS2 bör inkludera regelbundna pentest i sin säkerhetsplan.

GDPR och dataskydd

Om er Azure-miljö behandlar personuppgifter (vilket den med stor sannolikhet gör) är pentest ett effektivt verktyg för att verifiera att tekniska skyddsåtgärder enligt artikel 32 faktiskt håller. Integritetsskyddsmyndigheten (IMY) har i tillsynsbeslut betonat vikten av att organisationer aktivt testar sina säkerhetsåtgärder.

ISO 27001 och SOC 2

Båda ramverken kräver regelbunden säkerhetsbedömning. Pentest-rapporter fungerar som direkt evidens vid revisioner och visar att organisationen aktivt identifierar och åtgärdar sårbarheter.

Molnsäkerhet

Från pentest-rapport till faktisk förbättring

En pentest-rapport som samlar damm i en mapp har noll värde. Det kritiska steget är att omsätta fynd till åtgärder:

1. Prioritera efter affärspåverkan — inte bara teknisk allvarlighetsgrad. En medelstor sårbarhet i ett system som hanterar kunddata kan vara viktigare än en kritisk sårbarhet i en intern testmiljö.

2. Åtgärda rotorsaker — om problemet är att utvecklare skapar Storage Accounts med publikt åtkomst, inför Azure Policy som blockerar det som default. Fixa inte bara det enskilda fyndet.

3. Verifiera åtgärder — kör en omtest (retest) efter att åtgärder implementerats. Vi ser alltför ofta att "åtgärdat" i ett ärendehanteringssystem inte stämmer med verkligheten.

4. Integrera i kontinuerligt arbete — Använd pentest-fynd för att förbättra era Azure Policy-definitioner, Defender for Cloud-rekommendationer och IaC-templates.

Managerade molntjänster

Managerad DevOps

Kontinuerlig säkerhetsvalidering som komplement

Ett pentest ger en ögonblicksbild. Molnmiljöer förändras dagligen — nya resurser skapas, konfigurationer justeras, rättigheter ändras. Därför behöver penetrationstester kompletteras med:

• Microsoft Defender for Cloud Secure Score — kontinuerlig bedömning av säkerhetskonfiguration
• Azure Policy — förebyggande kontroller som stoppar felkonfigurationer innan de når produktion
• Automated Red Team-verktyg — verktyg som löpande testar specifika attackvägar
• SOC-övervakning — 24/7-monitorering som fångar upp anomalier i realtid

Cloud FinOps

Enligt Gartners Hype Cycle for Security Operations har continuous threat exposure management (CTEM) identifierats som en av de mest betydelsefulla trenderna inom säkerhet. Det handlar om att gå från periodiska tester till kontinuerlig validering — utan att för den skull sluta med riktiga penetrationstester utförda av kunniga testare.

Vanliga frågor

Behöver jag Microsofts godkännande för att pentesta i Azure?

Nej. Sedan juni 2017 kräver Microsoft inte längre förhandsgodkännande för penetrationstester mot dina egna Azure-resurser. Däremot gäller fortfarande deras Rules of Engagement — du får exempelvis inte testa mot andra kunders resurser, köra DoS-attacker eller försöka bryta dig ur hypervisor-isoleringen.

Hur ofta bör vi genomföra Azure-pentest?

En fullständig pentest bör göras minst årligen och vid större arkitekturförändringar. Komplettera med kontinuerlig sårbarhetsskanning och automatiserade säkerhetskontroller via Microsoft Defender for Cloud. Organisationer under NIS2 eller med höga krav enligt ISO 27001 bör överväga halvårsvis testning.

Vad är skillnaden mellan sårbarhetsskanning och pentest i Azure?

Sårbarhetsskanning är automatiserad och identifierar kända brister mot signaturdatabaser. Ett pentest går djupare — en säkerhetsspecialist försöker aktivt exploatera svagheter, kedja ihop fynd och bedöma verklig affärspåverkan. Båda behövs men fyller olika funktioner.

Vilka Azure-tjänster brukar ha flest sårbarheter?

Baserat på vad vi ser i Opsios SOC är de vanligaste problemområdena: Storage Accounts med för generösa åtkomstnycklar, App Services med default-konfigurationer, överbredsatta RBAC-roller i Entra ID, samt Key Vaults med bristfälliga åtkomstpolicyer.

Kan vi pentesta Azure AD / Entra ID?

Ja, identitetstestning är en central del av ett Azure-pentest. Du testar lösenordspolicyer, Conditional Access-regler, MFA-implementering och rollkonfigurationer. Det är ofta här de allvarligaste fynden dyker upp — en komprometterad identitet med för breda rättigheter kan ge åtkomst till hela miljön.