Cloud og identitet som scenarie: når kronjuvelerne ligger hos en udbyder

Når kundedata, mail og forretningssystemer ligger hos en cloududbyder, er netværkets yderkant ikke længere den grænse, et angreb skal over. Grænsen går ved identiteterne: hvem der kan logge ind, med hvilke rettigheder, og hvad der sker, når en konto bliver brugt af den forkerte. Et cloudscenarie hviler derfor på to ting, I selv skal have styr på før start: hvilken del af ansvaret der er jeres, og hvilke regler udbyderen har sat for at afprøve det.

Kort sagt giver scenariet mening, når jeres vigtigste data og processer kører i cloud, og når spørgsmålet til øvelsen er, om forsvaret ser og stopper misbrug af adgang dér. Det giver ikke mening som en afprøvning af udbyderens egen platform, for den del er ikke jeres at teste.

Ansvaret er delt, men identiteten er jeres

Microsoft beskriver i sin dokumentation om delt ansvar, at kunden uanset tjenestetype altid har ansvaret for data, endepunkter, konti og adgangsstyring. Udbyderen har ansvaret for de fysiske datacentre, netværket og værtsmaskinerne, og fordelingen af det, der ligger imellem, afhænger af, om tjenesten er infrastruktur, platform eller software.

For scenariet betyder det, at den del, I kan og bør afprøve, er den del, I selv konfigurerer og overvåger. Det er her, de interessante spørgsmål ligger:

Identiteter og roller · hvem har adgang til kronjuvelerne, og er der flere privilegerede konti end nødvendigt?
Konfiguration · er indstillingerne i jeres tenant i overensstemmelse med jeres egne politikker?
Tværgående adgang · hvordan hænger den lokale katalogtjeneste, cloudidentiteten og tredjepartsapplikationer sammen?
Synlighed · sender cloudtjenesterne de logs, som jeres overvågning har brug for, og bliver de læst?
Reaktion · ved forsvaret, hvordan en kompromitteret cloudkonto spærres og undersøges?

Udbyderens regler sætter rammen

Hver udbyder har sine egne vilkår for sikkerhedstest, og de gælder ved siden af jeres egen tilladelse. Microsofts regler for sikkerhedstest af Microsofts onlinetjenester forbyder bl.a. test af andre kunders data, overbelastningstest og social engineering rettet mod Microsofts medarbejdere. Reglerne lægger samtidig op til, at kunder afprøver deres egen sikkerhedsovervågning og detektion i egen tenant. AWS kræver, at bestemte typer simulerede hændelser, herunder red team-øvelser, anmeldes på forhånd.

Gennemgangen af den slags vilkår hører hjemme i planlægningen og skal gentages for hver øvelse, fordi reglerne kan ændre sig. → Driftsleverandører og cloududbydere i øvelsen

Rules of engagement skal desuden sige, at holdet holder sig inden for jeres egne tenants og abonnementer, og hvad der sker, hvis holdet støder på noget, der tilhører udbyderen eller en anden kunde. Det korte svar er: stop, notér og kontakt white team. → Rules of engagement i red teaming

Flag, der kan bevises uden at røre data

I et cloudscenarie er det fristende at lade flaget være adgang til en bestemt dataopsamling eller en bestemt postkasse. Overvej i stedet flag, der viser kontrol uden at kræve, at holdet åbner rigtige oplysninger:

Et aftalt dokument · placeret af white team i det område, scenariet skal nå.
En testkonto med en aftalt rolle · som holdet skal kunne tildele sig selv eller bruge.
En markør i konfigurationen · som kun kan sættes med de rettigheder, scenariet handler om.

Flagene skal være dokumenteret i scope, og white team skal kunne bekræfte, at de er nået, ud fra jeres egne logs. → Målet for øvelsen

Udgangspunktet: udefra eller med en konto

Et cloudscenarie kan begynde på to måder. Enten skal holdet selv skaffe sig den første adgang, eller white team stiller en almindelig brugerkonto til rådighed som udgangspunkt. Den første variant siger noget om, hvor godt identiteterne er beskyttet mod at blive overtaget. Den anden springer det spørgsmål over og bruger tiden på det, der sker bagefter: kan en almindelig konto bevæge sig mod kronjuvelerne, og bliver det set?

Valget afhænger af, hvad I allerede ved. Hvis tidligere test og jeres egen overvågning har givet et klart billede af beskyttelsen ved login, kan det være mere lærerigt at starte indenfor. Hvis I ikke ved det, er indgangen i sig selv et relevant spørgsmål. Under alle omstændigheder skal kontoen, rettighederne og den person, kontoen tilhører, være aftalt og godkendt på forhånd. → Assumed breach som scenarie

Logs hos en anden

Meget af det, der skal bruges til at måle opdagelse, ligger i udbyderens logs og ikke på jeres egne servere. Det rejser praktiske spørgsmål, der skal besvares før start: hvilke logs er slået til, hvor længe gemmes de, og har jeres overvågning adgang til dem i tide? Hvis en log kun gemmes kort, kan den være væk, når blue team skal skrive sin rapport.

Aftal derfor, at white team kan bede om at få relevante logs sikret ved afslutningen. Hvis overvågningen ligger hos en SOC-leverandør, skal leverandøren vide, hvilke cloudkilder den forventes at dække, før øvelsen begynder. → Detektionsdækning

Hvem skal kende til øvelsen

Et cloudmiljø kan have flere administratorer i forskellige funktioner. IT-drift, udviklingsteams, en driftsleverandør og måske en partner med administratoradgang kan alle have hænderne i samme tenant. Beslut, hvem der skal kende til øvelsen, så ingen af dem i god tro ændrer noget, der ødelægger scenariet, og så ingen af dem kan afsløre øvelsen for blue team.

Hvis den tekniske afprøvning af konfigurationen i sig selv er formålet, er en almindelig test af cloudmiljøet et bedre valg end en red team-øvelse. Testområderne i dybden er beskrevet for IT-afdelinger på penetration-test.dk.

Det skal I lade være med

At teste udbyderens platform · scenariet handler om jeres egen del af ansvaret.
At springe udbyderens vilkår over · de gælder ved siden af jeres tilladelse.
At bruge rigtige data som flag · aftalte markører viser det samme med mindre risiko.
At glemme logopbevaringen · det, der ikke gemmes, kan ikke måles bagefter.
At overse partnere med administratoradgang · de er en del af både angrebsfladen og forsvaret.
At lade scenariet blive en konfigurationsgennemgang · det er et andet spørgsmål med en anden testform.

Hvad kan og ikke kan konkluderes

Et cloudscenarie kan vise, om forsvaret opdager og reagerer på misbrug af identiteter og rettigheder i jeres egne cloudmiljøer, og om de nødvendige logs findes og bliver brugt. Det kan ikke vise, om udbyderens platform er sikker, og det giver ikke et fuldt billede af konfigurationen. Resultatet gælder de tenants og tjenester, der var med, på det tidspunkt øvelsen fandt sted; cloudmiljøer ændrer sig hurtigt, og det skal stå i rapporten.

Tjekliste før scenariet

☐ Er det beskrevet, hvilke tenants, abonnementer og tjenester der er med?
☐ Er udbydernes vilkår for sikkerhedstest læst, og er en eventuel anmeldelse sendt?
☐ Er flagene aftalt som markører frem for rigtige data?
☐ Er logopbevaring og adgang til cloudlogs afklaret med overvågningen?
☐ Ved alle med administratoradgang, om de er i eller uden for den lille kreds?

Kilder

Microsoft Learn, Shared responsibility in the cloud: kunden har altid ansvaret for data, endepunkter, konti og adgangsstyring; fordelingen af resten afhænger af tjenestetype.
Microsoft, Cloud Penetration Testing Rules of Engagement: forbud mod test af andre kunders data, overbelastningstest og social engineering mod Microsofts medarbejdere; test i egen tenant.
AWS, Penetration Testing: red team-øvelser og andre simulerede hændelser skal anmeldes på forhånd.

Senest gennemgået: oktober 2026.