Cloudmiljøer er i dag den normale driftsplatform for mange danske organisationer efter et årti, hvor de gik fra at være et alternativ til eget datacenter.
En Cloud Penetration Tester undersøger sikkerheden i cloudbaserede systemer med skriftligt mandat, klare spilleregler og et mål om at finde sårbarheder, før de bliver udnyttet. Rollen ligger i krydsfeltet mellem traditionel penetrationstest, cloudarkitektur, identitetsstyring, compliance og teknisk rapportering.
Arbejdet handler sjældent om at “hacke skyen” i bred forstand. En cloudtest foregår inden for en defineret konto, tenant, organisation eller applikation, hvor testeren vurderer, om konfigurationer, rettigheder, netværk, containere, serverløse funktioner, CI/CD-pipelines og datalagre kan misbruges. Det kræver forståelse for både angrebsteknikker og for den delte ansvarsmodel, hvor cloududbyderen beskytter platformens underliggende infrastruktur, mens kunden typisk er ansvarlig for identiteter, data, workloads og konfigurationer.
Hvad laver en Cloud Penetration Tester i praksis?
En Cloud Penetration Tester planlægger, udfører og dokumenterer sikkerhedstests af cloudmiljøer i AWS, Microsoft Azure, Google Cloud eller hybride opsætninger. Opgaven begynder normalt med scope, tilladelser og Rules of Engagement, før den tekniske test starter. Det er især vigtigt i cloud, fordi en forkert test kan påvirke produktionsressourcer, udløse alarmer, bryde en udbyders vilkår eller skabe unødvendig risiko for data.
Teknisk adskiller cloud-penetrationstest sig fra klassisk on-premise test ved, at identitet ofte er den vigtigste angrebsflade. En enkelt overprivilegeret rolle, en lækket adgangsnøgle, en svagt afgrænset managed identity eller en fejlagtig trust policy kan give mere adgang end en åben netværksport. Derfor bruger cloudtestere meget tid på IAM, adgangsstier, servicekonti, policyer, secrets, logging og datalagre.
Derudover er cloudmiljøer dynamiske. Ressourcer bliver oprettet af udviklere, deployment pipelines, Infrastructure as Code og automatiserede services. En penetrationstest skal derfor tage højde for, at det relevante angrebsmål ikke kun er en virtuel maskine eller en webapplikation, men også byggesystemer, containerregistre, Kubernetes RBAC, serverløse funktioner, storage buckets, key vaults og cloud-native netværkskontroller.
Hvor rollen passer ind i danske og europæiske organisationer
I Danmark er cloud-penetrationstest relevant i både private virksomheder, offentlige organisationer, finans, energi, sundhed, SaaS, telekommunikation og konsulenthuse. Fælles for sektorerne er, at cloudplatforme ofte bærer forretningskritiske systemer og persondata. Derfor bliver en cloudtest ikke kun vurderet som en teknisk øvelse, men også som en del af risikostyring, leverandørkontrol og dokumenteret sikkerhedsarbejde.
GDPR har betydning, når testen kan berøre personoplysninger, logdata eller miljøer med produktionsdata. Testeren skal kende scope, databehandlerforhold, behandlingsgrundlag og krav til håndtering af beviser, så screenshots, eksportfiler og logs ikke skaber nye datarisici. Datatilsynets vejledninger og organisationens egne politikker bør indgå i planlægningen, især når testresultater viser eksponerede data eller svage adgangskontroller.
NIS2-direktivet skærper samtidig forventningen om ledelsesforankret cybersikkerhed, risikostyring og hændelseshåndtering for omfattede sektorer. Det betyder ikke, at hver penetrationstest bliver en juridisk complianceøvelse, men det påvirker, hvordan scope, rapportering, prioritering og opfølgning bør formuleres. En god cloudrapport viser ikke kun, at en fejl findes; den forklarer sandsynlig angrebsvej, forretningspåvirkning, evidens, anbefalet afhjælpning og hvordan organisationen kan verificere rettelsen.
Cloudtest kræver andre vaner end klassisk penetrationstest
En erfaren netværks- eller webtester har et godt udgangspunkt, men cloud kræver nogle nye arbejdsvaner. Først og fremmest skal testeren respektere cloududbyderens retningslinjer og kundens mandat. AWS, Azure og Google Cloud har hver deres dokumentation for tilladt sikkerhedstest, misbrugshåndtering og rapportering. Der kan også være begrænsninger på belastningstest, phishing, social engineering, DoS-lignende aktiviteter og tests mod delte platformskomponenter.
Den anden forskel er telemetri. Cloudmiljøer producerer store mængder logs fra eksempelvis CloudTrail, Azure Activity Logs, Microsoft Entra ID, Google Cloud Audit Logs, Defender for Cloud, Security Command Center og SIEM-platforme. En dygtig tester forstår, hvordan angrebsaktivitet ser ud i loggene, og kan hjælpe blue team med at validere detektionsregler. Det gør testen mere værdifuld end en ren sårbarhedsliste.
Den tredje forskel er, at angrebsveje ofte går gennem konfigurationer og rettigheder. Eksempler kan være offentligt tilgængelige storage buckets, brede IAM-roller, mulighed for privilege escalation via en tjeneste, adgang til secrets fra en serverløs funktion, misbrug af en App Service managed identity, svag Kubernetes RBAC eller CI/CD-tokens med adgang til produktion. Frameworks som OWASP ASVS, OWASP Top 10, OWASP Cloud-Native Application Security, MITRE ATT&CK og Cloud Security Alliance Cloud Controls Matrix kan hjælpe med at strukturere vurderingen, men de erstatter ikke forståelsen af den konkrete arkitektur.
De færdigheder arbejdsgivere typisk leder efter
Danske arbejdsgivere og konsulenthuse leder sjældent efter en person, der kun kan køre værktøjer. De ser efter evnen til at læse arkitekturdiagrammer, forstå cloudkonti og tenants, finde realistiske angrebsveje, forklare risiko uden drama og foreslå afhjælpning, som en platform- eller DevOps-gruppe faktisk kan implementere. Den skriftlige rapport er derfor en central del af jobbet.
Det tekniske fundament bør omfatte netværk, Linux, Windows, webapplikationer, scripting, identitet, kryptografi på praktisk niveau og grundlæggende incident response. Oven på det kommer cloudspecifik viden: IAM, storage, nøglestyring, logging, netværkssegmentering, managed services, containers, Kubernetes, serverless, CI/CD og Infrastructure as Code. Kendskab til Terraform eller Bicep er nyttigt, fordi mange fejl i cloudmiljøer fødes i templates og pipelines snarere end i klik i portalen.
Kommunikation betyder lige så meget som teknik. Et godt fund beskriver forudsætningen, udnyttelsen, konsekvensen, evidensen og en prioriteret løsning. Et svagt fund siger kun, at “en bucket er offentlig” eller “en rolle har for mange rettigheder”. En Cloud Penetration Tester skal kunne forklare, hvad en angriber faktisk kan gøre, hvilke data eller systemer der er i fare, og hvordan rettelsen kan testes uden at stoppe forretningen.
Et praktisk læringsmiljø uden at teste ulovligt
Den mest robuste vej ind i rollen er at bygge et kontrolleret lab. Det kan være en personlig AWS-konto, en Azure-tenant og eventuelt et Google Cloud-projekt med gratis niveauer og stramme budgetalarmer. Målet er ikke at efterligne en stor virksomhed fuldt ud, men at skabe realistiske fejlkonfigurationer, angribe dem med tilladelse og dokumentere læringen.
Infrastructure as Code gør labbet langt mere værdifuldt. Med Terraform kan en studerende eksempelvis oprette en storage bucket, en IAM-rolle, en serverløs funktion og en simpel CI/CD-identitet, teste konsekvensen af svage rettigheder og derefter rette koden. Det lærer både angreb og afhjælpning. Samtidig giver det artefakter til en portfolio: repository, rapportskabelon, fundbeskrivelser, før- og efterkonfigurationer og korte writeups.
Værktøjer bør bruges som læringsforstærkere, ikke som erstatning for forståelse. Pacu kan bruges til AWS-scenarier som IAM-privilege-escalation i et godkendt lab. Prowler og ScoutSuite kan hjælpe med at identificere cloudkonfigurationsproblemer på tværs af kontroller. kube-bench kan bruges til Kubernetes CIS-baserede kontroller. I Azure kan praktiske øvelser handle om Storage Account-konfigurationer, App Service managed identities, Key Vault-adgang og Entra ID-roller. I Google Cloud kan øvelser fokusere på brede IAM-roller, service accounts og Cloud Storage ACLs.
Roadmap fra fundament til første cloudtest
En karrierevej bliver mere realistisk, når den opdeles i milepæle. Mange begynder for bredt og forsøger at lære alle udbydere, alle værktøjer og alle certificeringer samtidig. En bedre strategi er at vælge én primær cloudplatform, bygge et stærkt sikkerhedsfundament og derefter udvide.
- Start med netværk, Linux, webapplikationer og grundlæggende sikkerhedstest, så cloudbegreberne får et teknisk fundament.
- Vælg én primær cloudplatform og lær identitet, logging, storage, netværk, nøgler og managed services i dybden.
- Byg et lab med Infrastructure as Code, budgetgrænser og bevidst sårbare konfigurationer.
- Gennemfør små testscenarier med skriftligt scope, evidens og rapportering, som om det var en kundeopgave.
- Udvid til containers, Kubernetes, serverless og CI/CD, når de basale cloudangrebsveje sidder fast.
- Dokumentér arbejdet i en portfolio med anonymiserede writeups, rapporteksempler og rettede konfigurationer.
Den første professionelle mulighed kan komme fra flere retninger. En junior SOC-analytiker kan bevæge sig mod cloud detection og derefter offensive tests. En DevOps-profil kan specialisere sig i sikker cloudkonfiguration og red team-samarbejde. En traditionel penetrationstester kan begynde med cloud review og gradvist tage mere komplekse identitets- og platformsscenarier. I alle tilfælde er demonstrerbare artefakter ofte mere overbevisende end en liste over værktøjer.
Certificeringer der giver mening
Certificeringer kan hjælpe, men de bør vælges efter nuværende niveau og ønsket retning. En generel penetrationstestcertificering kan være nyttig for en person uden offensivt fundament, mens en cloud- eller sikkerhedsarkitekturcertificering ofte passer bedre til personer, der allerede arbejder med Azure, AWS, Google Cloud eller DevOps. Readynez kan indgå som træningspartner for struktureret forberedelse, men værdien af en certificering afhænger i praksis af, om den kombineres med hands-on erfaring.
| Udgangspunkt |
Certificeringsretning |
Hvornår den passer |
| Ny i sikkerhed |
eJPT eller CEH |
Når målet er at lære grundlæggende penetrationstest, metodik og rapportering før cloudspecialisering. |
| Azure-, AWS- eller DevOps-baggrund |
AZ-500, AWS Certified Security – Specialty eller Google Professional Cloud Security Engineer |
Når målet er at forstå cloudkontroller, identitet, logging, netværk og platformsspecifik sikkerhed. |
| Arkitektur, governance eller policy |
(ISC)² CCSP |
Når rollen kræver cloud governance, risikostyring, compliance og sikkerhedsarkitektur mere end ren exploitation. |
Der findes ikke én rigtig rækkefølge for alle. En Azure-administrator, der vil ind i cloud-penetrationstest, får ofte mere ud af AZ-500 og praktiske Azure-labs end af en generel begynderpakke. En person uden offensiv erfaring kan derimod have brug for et bredere penetrationstestfundament, før cloudspecifikke eksamener giver mening. En erfaren sikkerhedsarkitekt kan vælge CCSP for at styrke governance- og risikodelen, men bør stadig kunne demonstrere, hvordan fejlkonfigurationer udnyttes og rettes i praksis.
Metode, etik og rapportering
Cloud-penetrationstest uden skriftligt mandat er ikke træning; det er en juridisk risiko. Professionel praksis begynder med en aftale, der definerer scope, tidspunkter, kontaktpersoner, tilladte teknikker, datahåndtering, stopkriterier og rapporteringskrav. PTES, OWASP-metodik og organisationens egne sikkerhedsprocesser kan bruges som ramme for planlægning, udførelse og dokumentation.
Reglerne skal være særligt tydelige ved produktionsmiljøer. Testeren bør vide, om privilege escalation må forsøges, om data må læses eller kun bevises indirekte, om scanning må køre mod alle ressourcer, og hvordan utilsigtet adgang til persondata håndteres. Evidens bør være minimal, relevant og beskyttet. Det er sjældent nødvendigt at eksportere store datamængder for at bevise en alvorlig sårbarhed.
En moden rapport gør det nemt for organisationen at handle. Den bør adskille kritiske angrebsveje fra lavrisikoobservationer, beskrive teknisk årsag, forretningsmæssig konsekvens og praktisk afhjælpning samt give forslag til detektion. I cloud kan det eksempelvis være en policyændring, en Terraform-rettelse, en alert i SIEM, en ændring i Entra ID Conditional Access eller en mere restriktiv service account.
Udfordringer i jobbet
Den største faglige udfordring er hastigheden i cloudplatformenes udvikling. Nye services, rettighedsmodeller og integrationer ændrer angrebsfladen løbende. Derfor skal en Cloud Penetration Tester kunne læse udbyderdokumentation, forstå release notes og teste hypoteser sikkert i et lab.
En anden udfordring er scoping i multi-cloudmiljøer. Mange organisationer har både Azure, AWS, SaaS-platforme, Kubernetes, eksterne identitetsudbydere og CI/CD-systemer. Et for bredt scope giver overfladiske resultater, mens et for snævert scope kan overse den egentlige angrebsvej. Praktisk erfaring viser sig her som evnen til at afgrænse testen efter risiko: identiteter, eksponerede data, privilegerede workloads og forbindelser mellem miljøer.
Endelig er der udfordringen med at skabe ændring efter testen. Det er ikke nok at finde fejl. Testeren skal formulere fund, så sikkerhed, platform, udvikling og ledelse kan prioritere dem. En teknisk korrekt rapport uden tydelig risiko og gennemførlig afhjælpning får ofte mindre effekt end en kortere rapport med skarpere forklaring.
Sådan bygger du en holdbar vej ind i rollen
Cloud Penetration Testing er en specialisering, hvor praktisk disciplin vægter tungt. Den, der vil ind i feltet, bør kombinere cloudfundament, offensive teknikker, rapportering, lovligt mandat og forståelse for dansk og europæisk regulering. Det giver et mere realistisk karrieregrundlag end at jagte mange værktøjer på én gang.
Det mest effektive næste skridt er at vælge én platform, bygge et lille lab, gennemføre en kontrolleret test og skrive en rapport, der kunne læses af både en cloud engineer og en risikoejer. Derefter kan certificeringer, mere avancerede labs og eventuel træning hos Readynez bruges til at strukturere progressionen og dokumentere kompetencerne. For a deeper dive, see Bedste PMP-forberedelseskurser: Din guide til at blive en.
