Et Azure-miljø kan vokse hurtigere end overblikket. Et projekt opretter en ressourcegruppe, en leverandør får en rolle for at sætte en tjeneste op, og en testserver bliver stående efter afleveringen. En Azure-test afprøver, hvad der kan nås i jeres abonnementer ud fra et aftalt udgangspunkt: roller og rettigheder, netværk, data, nøgler og de tjenester, der vender ud mod internettet. Svaret på, hvad der må testes, hviler på Microsofts regler for test af deres onlinetjenester og på jeres egen skriftlige tilladelse.
Rammen: regler og delt ansvar
Microsoft oplyser, at der ikke længere kræves forudgående godkendelse for at teste egne ressourcer i Azure, men at testen skal følge Microsofts fælles regler for penetrationstest. Eksterne testere må teste, når ejeren af ressourcerne har givet udtrykkelig skriftlig tilladelse, og Microsoft giver ikke tilladelsen på kundens vegne. Test af overbelastning er forbudt under alle omstændigheder.
Hvad I selv skal teste, følger af den delte ansvarsmodel. I en ren infrastrukturtjeneste står I for virtuelle maskiner, styresystemer og netværk. I platformstjenester overtager Microsoft mere af stakken, men I står stadig for data, identiteter, adgangsstyring og opsætning. Køberens side af ansvarsdelingen og bestillingen er beskrevet på penetrationtest.dk.
For IT-afdelingen betyder det, at testen handler om jeres egne valg, også dem, der er truffet af en leverandør på jeres vegne: hvem der har hvilke roller, hvad der er åbent mod internettet, og hvordan data og nøgler er beskyttet.
Fem områder i en Azure-test
En Azure-test samler sig typisk om disse områder:
- Roller og rettigheder · hvem der er ejer eller bidragyder, på hvilket niveau, og om tildelingerne arves længere ned, end nogen har tænkt. → Roller i Azure
- Netværk og eksponering · hvilke tjenester og maskiner der kan nås fra internettet, og hvordan netværkene er adskilt.
- Data · lagerkonti og databaser, der er tilgængelige for flere end tilsigtet. → Lagerkonti og databaser i Azure
- Nøgler og hemmeligheder · hvor adgangsnøgler og adgangskoder ligger, og hvem der kan læse dem. → Nøgler og hemmeligheder i cloud
- Identiteter for tjenester · programmer og tjenester med egne identiteter og deres rettigheder.
Virtuelle maskiner i Azure er en del af billedet, men hærdningen af selve maskinerne ligner det lokale arbejde og behandles for sig. → Virtuelle maskiner i Azure og AWS
Udgangspunktet afgør svaret
Det vigtigste valg i opdraget er udgangspunktet. Tre er almindelige:
- Udefra · testeren har ingen adgang og ser kun på det, der vender ud mod internettet.
- Med en almindelig konto · testeren har en konto med de roller, en typisk udvikler eller driftsmedarbejder har, og ser, hvor langt den rækker.
- Med læseadgang · testeren kan læse opsætningen i hele miljøet og vurderer den systematisk.
Et fjerde udgangspunkt er en tjenesteidentitet eller en adgangsnøgle, som tænkes at være kommet i forkerte hænder. Det svarer på, hvad et lækket script eller en kompromitteret integration kan nå, og er relevant, hvis I har mange automatiserede løsninger.
De tre første giver forskellige svar. Udefra svarer på eksponering. Den almindelige konto svarer på, hvad en kompromitteret medarbejder eller leverandør kan nå. Læseadgangen giver bredde. Mange IT-afdelinger kombinerer en læsekonto med en afprøvning fra en almindelig konto. → Konfigurationsgennemgang eller penetrationstest af cloud
Det, IT-afdelingen gør klar
- Liste over abonnementer i scope · og hvilke der bevidst holdes udenfor.
- Testkonti · med de roller, udgangspunktet kræver, oprettet i jeres egen Entra ID.
- Skriftlig tilladelse · fra den, der ejer abonnementerne, så den kan fremvises, hvis Microsofts automatiske overvågning reagerer på aktiviteten.
- Overblik over leverandører · hvem der har roller i miljøet, og hvem der skal kende testvinduet.
- Skrøbelige ressourcer · produktionssystemer, der ikke tåler forstyrrelser, og som skal behandles forsigtigt. → Skrøbelige systemer
- Logning · kontrollér, at aktivitetslog og relevante ressourcelogs er slået til og gemmes. → Logning i Microsoft 365, Azure og AWS
Microsoft beskriver, at legitim test af og til bliver opfanget af den automatiske overvågning. Har I tilladelsen klar, er det lettere at svare, hvis Microsoft henvender sig.
Under testen
Azure er et miljø, hvor mange ændringer sker automatisk. Skabeloner opretter ressourcer, politikker retter indstillinger, og leverandører udruller nye versioner. Aftal derfor, at der ikke laves større ændringer i de abonnementer, der testes, mens testen står på, eller at testeren får besked, når det sker. Ellers kan et fund forsvinde eller opstå undervejs, og rapporten bliver svær at genkende bagefter.
Hav en kontaktperson, der kan svare på spørgsmål om ressourcer, testeren ikke kan placere. En database uden navn og ejer er måske et glemt projekt, måske et produktionssystem. Det skal afklares, før testeren går videre.
Typiske fund og hvem der retter
Fund i Azure kan fordele sig på flere ejere. Roller og rettigheder ejes af den, der administrerer abonnementerne. Netværk og eksponering ejes af drift eller en leverandør. Data og nøgler kan være ejet af det projekt eller den afdeling, der har bygget løsningen.
Mange fund opstår, fordi ressourcer er oprettet uden fælles regler. Det peger på et styringsspørgsmål ud over de konkrete rettelser: hvem må oprette ressourcer, efter hvilke skabeloner, og hvem godkender undtagelser?
Fordel fundene efter ejer, før de lægges i opgavesystemet. Et fund om en lagerkonto, der er åben, hører hos dem, der bruger kontoen. Et fund om, at for mange er ejere af hele abonnementet, hører hos IT-ledelsen.
Typiske rettelser på begrebsniveau er færre ejere og bidragydere på abonnementsniveau, tildelinger på det laveste niveau, der dækker behovet, færre tjenester med offentlig adgang, identiteter i stedet for adgangsnøgler, og central opbevaring af hemmeligheder. → Mindst mulig adgang
Det skal I lade være med
- At teste uden skriftlig tilladelse fra ejeren. Microsoft giver den ikke for jer.
- At give testeren ejerrollen på hele abonnementet. Testen viser så kun, hvad en ejer kan.
- At glemme ressourcer, som leverandører har oprettet. De ligger i jeres abonnement og er jeres ansvar.
- At lukke offentlig adgang uden at kende afhængighederne. Integrationer kan stoppe.
- At lade testkonti og testroller blive. Fjern dem, når testen er slut.
Hvad kan og ikke kan konkluderes
Testen viser, hvad udgangspunktet kunne nå i de abonnementer og ressourcer, der var i scope, på testtidspunktet. Den siger ikke noget om Microsofts egen platform, og den dækker ikke ressourcer, der blev oprettet efter testen. Azure-miljøer ændrer sig hurtigt. Et resultat uden alvorlige fund er derfor et øjebliksbillede, der skal suppleres med løbende kontrol af opsætningen.
Tjekliste før Azure-testen
- ☐ Er abonnementerne i scope skrevet ned?
- ☐ Er udgangspunktet for testen valgt?
- ☐ Er testkontiene oprettet med de rigtige roller?
- ☐ Ligger den skriftlige tilladelse klar?
- ☐ Kender leverandører med roller testvinduet?
- ☐ Er skrøbelige ressourcer markeret?
- ☐ Er logningen kontrolleret før start?
Kilder
- Microsoft Learn: Penetration testing (Azure): ingen forudgående godkendelse, krav om at følge Microsofts regler, skriftlig tilladelse fra ejeren, forbud mod test af overbelastning, legitim test kan blive opfanget.
- Microsoft Learn: Shared responsibility in the cloud: fordelingen af ansvar i infrastruktur- og platformstjenester, og at kunden altid står for data, identiteter og adgangsstyring.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: AWS-test · Flere cloudmiljøer i samme test
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
