En molnpenetrationstestare granskar hur molnplattformar skyddar affärskritiska system, identiteter, dataflöden och utvecklingsmiljöer när dessa miljöer numera bär en central del av verksamheten.
En molnpenetrationstestare arbetar med godkända säkerhetstester av molnmiljöer för att hitta sårbarheter, felkonfigurationer och angreppsvägar innan de kan utnyttjas av obehöriga aktörer. Rollen ligger nära etisk hackning, men kräver också djup förståelse för molnleverantörernas säkerhetsmodeller, identitetsstyrning, loggning, nätverk, containrar och juridiska ramar.
I Sverige växer behovet eftersom fler organisationer kör känsliga arbetslaster i Azure, AWS och Google Cloud samtidigt som kraven på riskhantering skärps. GDPR har redan gjort spårbarhet, personuppgiftsskydd och incidenthantering till ledningsfrågor. NIS2 förstärker detta ytterligare för många samhällsviktiga och digitala verksamheter genom tydligare krav på styrning, riskbedömning och rapportering.
Det gör yrket bredare än klassisk penetrationstestning av webbapplikationer. En molnpenetrationstestare behöver förstå hur en till synes liten behörighetsmiss kan bli en kedja av åtkomst, hur metadata-tjänster kan exponera identiteter, hur öppna lagringsytor leder till dataläckage och hur Kubernetes-konfigurationer kan ge angripare rörelseutrymme. Den som vill in i rollen behöver därför kombinera offensiv metodik med molnarkitektur, dokumentation och förmågan att översätta fynd till åtgärder.
Vad rollen innebär i praktiken
En vanlig arbetsdag börjar sällan med exploatering. Den börjar med scope, tillstånd och förståelse för kundens miljö. I moln är avgränsningen svårare än i traditionella miljöer eftersom resurser kan skapas och raderas snabbt, miljöer kan vara multi-tenant och leverantörernas användarvillkor kan påverka vilka tester som får genomföras utan särskild förhandsanmälan.
Ett välplanerat uppdrag definierar vilka konton, prenumerationer, projekt, domäner, IP-intervall, API:er och identiteter som ingår. Det anger även testfönster, kontaktvägar vid incident, regler för rate limits och vilka aktiviteter som är förbjudna eftersom de kan störa produktion. Denna formalia är inte administrativt brus. Den skyddar både testaren och organisationen, och den gör resultatet användbart när tekniska fynd senare ska kopplas till risk, ansvar och åtgärdsplan.
När testet väl startar kombineras manuell analys med automatiserade verktyg. Prowler och ScoutSuite kan ge en bred bild av molnkonfigurationer, medan Pacu kan användas i godkända AWS-labb för att förstå identitets- och eskaleringsvägar. I container- och Kubernetes-miljöer förekommer verktyg som kube-bench och kube-hunter i kontrollerade sammanhang, tillsammans med granskning av RBAC, nätverkspolicys och pod-säkerhet. Leverantörernas egna CLI-verktyg för Azure, AWS och Google Cloud är samtidigt centrala, eftersom verkliga uppdrag kräver att testaren kan läsa konfigurationer, validera åtkomst och följa spår i loggar.
Typiska angreppsvägar handlar ofta om kedjor snarare än enskilda brister. En server-side request forgery-sårbarhet kan ge åtkomst till en Instance Metadata Service om skydden är svaga eller felkonfigurerade. En publik S3-bucket eller Blob-container kan exponera data som i sin tur innehåller hemligheter eller konfigurationsfiler. En alltför bred IAM-policy kan göra det möjligt att anta en roll, skapa nya nycklar eller röra sig vidare mellan tjänster. I Kubernetes kan ett exponerat API, svaga RBAC-regler eller otillräckliga PodSecurity-inställningar ge åtkomst som aldrig var avsedd.
En mogen molnpenetrationstestare dokumenterar dessa kedjor så att de går att reproducera utan att uppmuntra till otillåten åtkomst. Det innebär tydliga bevis, tidsstämplar, påverkade resurser, riskbeskrivning, affärskonsekvens och konkreta rekommendationer. I EU-kontext bör rapporten även hjälpa organisationen att visa hur testet stödjer riskarbete, spårbarhet och förbättringar enligt GDPR och, där det är relevant, NIS2.
Skillnaden mellan molnpenetrationstest och molnsäkerhetsgranskning
Molnpenetrationstestning och säkerhetsgranskning blandas ofta ihop, men de ger olika typer av värde. Ett penetrationstest undersöker om en angripare kan utnyttja sårbarheter inom ett godkänt scope och skapa faktisk påverkan. En arkitektur- eller konfigurationsgranskning bedömer i stället om miljön är byggd enligt god praxis, policyer och ramverk.
I praktiken behövs båda. Ett penetrationstest kan visa att en felaktig rolltilldelning faktiskt leder till privilege escalation, medan en granskning kan visa att organisationen saknar en hållbar modell för least privilege, loggretention eller separation mellan miljöer. CIS Benchmarks, OWASP:s molnrelaterade vägledning, ENISA:s rekommendationer och leverantörernas egen dokumentation används ofta som referenspunkter, men testaren behöver alltid anpassa dem till organisationens verkliga riskbild.
För den som väljer karriärspår är skillnaden viktig. Personer med bakgrund i systemadministration, nätverk eller SOC-analys kan ibland gå snabbare mot cloud security engineering och därefter in i offensiva tester. Den som redan kan webbsäkerhet eller exploitutveckling behöver i stället bygga molnförståelse, särskilt IAM, loggning och plattformsspecifika tjänster. Ett enkelt valramverk är att utgå från den starkaste molnplattformen, välja om målet är offensiv testning eller arkitektur, bevisa färdigheten i ett verklighetsnära labb med rapport och sedan omvärdera planen var tredje månad.
Färdigheter som bygger trovärdighet
Teknisk bredd är nödvändig, men rollen belönar särskilt de personer som kan följa samband. En kandidat som kan visa hur en exponerad hemlighet leder till en roll, hur rollen ger åtkomst till lagring och hur loggarna visar händelseförloppet framstår starkare än en kandidat som bara kan köra ett skanningsverktyg.
Grunden består av nätverk, Linux, webbsäkerhet, identitet, skriptning och molnarkitektur. Därefter kommer leverantörsspecifika kunskaper: Azure-prenumerationer och Entra ID, AWS IAM och Organizations, Google Cloud IAM och projektstruktur, samt hur loggning fungerar i respektive ekosystem. För containermiljöer krävs förståelse för Kubernetes, images, secrets, service accounts, ingress och nätverkspolicys.
Kommunikation är lika viktig som exploatering. En rapport som bara säger att en policy är ”för bred” hjälper sällan en verksamhet att prioritera. En bättre rapport visar vilka åtgärder som bör tas först, vilken risk som minskar, vilka beroenden som finns och hur organisationen kan verifiera att åtgärden fungerar. Detta är särskilt viktigt i svenska organisationer där säkerhet ofta behöver förankras hos systemägare, dataskyddsansvariga, inköp, juridik och drift.
Certifieringar utan att överskatta deras betydelse
Certifieringar kan hjälpa en kandidat att strukturera sin inlärning och visa en grundnivå för rekryterare. De ersätter däremot inte praktisk evidens. För juniora ansökningar väger en publik portfölj med två eller tre välbeskrivna molnlabb ofta tyngre än en lista med certifikat utan tillämpning.
En rimlig väg är att kombinera en bred säkerhetsgrund med molnspecifik kunskap. CompTIA Security+ kan vara relevant för den som saknar grundläggande cybersäkerhetsram. CEH kan ge introduktion till etisk hackning, även om den behöver kompletteras med praktiska labbar. CISSP och CCSP är mer lämpade för personer med bredare erfarenhet av säkerhetsstyrning, risk och molnarkitektur. För den som arbetar nära Microsoft-miljöer kan Azure-relaterade certifieringar ge värdefull struktur, medan AWS- och Google Cloud-spår kan fylla motsvarande funktion i andra miljöer.
Readynez kan vara ett stöd när en kandidat behöver en strukturerad utbildningsväg mot relevanta säkerhets- eller molncertifieringar, men karriärutvecklingen bör alltid kopplas till praktiska projekt. Certifikatet visar att kunskapen har prövats i ett format; portföljen visar hur kunskapen används när miljön är ofullständig, rörig och verklighetsnära.
En praktisk 90-dagars plan
Den som vill bli molnpenetrationstestare behöver en plan som ger synliga resultat. Tre månader räcker inte för att bli senior, men det räcker för att bygga en tydlig riktning, skapa portföljmaterial och upptäcka vilka kunskapsluckor som är mest akuta.
- Välj en primär molnplattform och bygg en säker labbmiljö med separata testkonton eller prenumerationer.
- Skapa ett scenario med felkonfigurerad lagring och dokumentera hur exponeringen upptäcks, verifieras och åtgärdas.
- Bygg ett IAM-labb där en överdriven behörighet leder till en kontrollerad eskaleringskedja.
- Testa ett Kubernetes-labb med svaga RBAC-regler och jämför resultatet mot hårdare policyer.
- Skriv en rapport för varje labb med scope, metod, fynd, bevis, risk, åtgärd och verifiering.
- Publicera kod, konfigurationer och sanerade rapporter i en portfölj utan hemligheter eller verkliga kunddata.
Det viktiga är inte att labben ser avancerade ut. De ska vara begripliga, etiska och reproducerbara. En rekryterare eller teknisk intervjuare bör kunna se hur kandidaten tänker, hur risk prioriteras och om rekommendationerna går att omsätta i drift.
Hur svenska arbetsgivare bedömer kandidater
Vid rekrytering till juniora och medior roller tittar arbetsgivare ofta på tre signaler: praktisk problemlösning, säkerhetsomdöme och kommunikationsförmåga. Det räcker sällan att säga att man kan AWS eller Azure. Kandidaten behöver visa hur kunskapen används i ett avgränsat test, hur slutsatser dras och hur risk hanteras utan att orsaka skada.
Caseuppgifter kan handla om att granska en IAM-policy, hitta varför en lagringsresurs är publik, resonera kring loggar efter misstänkt åtkomst eller förklara hur ett Kubernetes-kluster bör härdas. Intervjuerna testar ofta om kandidaten förstår gränsen mellan tillåten testning och otillåten åtkomst. Ett bra svar börjar därför med scope och tillstånd innan tekniken diskuteras.
En anonymiserad portföljrapport kan vara mer övertygande än ett långt CV. Ett exempel kan beskriva en sårbar IAM-policy som tillät en testidentitet att anta en roll med bredare åtkomst än avsett. En stark rapport visar vilken policyrad som skapade risken, vilken åtgärd som begränsade behörigheten, vilka loggar som bekräftade beteendet och hur teamet kan testa att felet inte återkommer. Den typen av evidens visar mognad utan att avslöja känslig information.
Etik, juridik och ansvar
Molnpenetrationstestning får endast ske mot system där det finns uttryckligt tillstånd. Det gäller även till synes oskyldiga kontroller mot publika resurser. En öppen bucket, en exponerad endpoint eller en felkonfigurerad inloggningssida innebär inte att extern testning är tillåten.
I Sverige och EU behöver testaren förstå hur tekniska aktiviteter påverkar personuppgifter, loggar och incidentprocesser. Testdata bör vara kontrollerad, åtkomst till personuppgifter ska undvikas eller minimeras, och rapporteringen bör ge organisationen underlag för riskbedömning. Om känslig data exponeras under ett godkänt test ska hanteringen följa uppdragets rapporteringsvägar och organisationens incidentrutiner.
Den juridiska ramen påverkar även bevisinsamling. Skärmbilder, loggutdrag och kommandon måste vara tillräckliga för att styrka fyndet, men inte samla in mer data än nödvändigt. En professionell testare bevisar risk med minsta möjliga påverkan och lämnar en revisionsbar kedja av vad som gjorts, när det gjordes och varför det låg inom scope.
Vanliga misstag på vägen in i rollen
Ett vanligt misstag är att lägga för mycket tid på verktyg och för lite tid på molnmodellen. Verktyg kan peka på risker, men den som inte förstår identitet, nätverk och tjänstedesign kommer att missa hur fynden hänger ihop. Ett annat misstag är att bygga labbar som saknar rapport. I arbetslivet är fyndet bara halva leveransen; den andra halvan är att göra det begripligt och åtgärdbart.
Många underskattar också hur snabbt plattformarnas detaljer förändras. Råd om metadata-tjänster, standardbehörigheter eller Kubernetes-säkerhet kan bli föråldrade. Därför bör lärandet kopplas till aktuell dokumentation från AWS, Microsoft Azure, Google Cloud och Kubernetes, samt till ramverk som OWASP, CIS Benchmarks, MITRE ATT&CK for Cloud och ENISA:s vägledning.
Slutligen bör kandidater undvika att beskriva otillåtna tester som ”research”. Seriös säkerhetskompetens syns i förmågan att avgränsa, dokumentera och respektera ansvar. Det är särskilt viktigt i moln, där en felriktad testaktivitet kan påverka delade tjänster, kostnader eller andra miljöer.
En hållbar väg in i yrket
Karriären som molnpenetrationstestare byggs bäst genom en kombination av teknisk grund, molnförståelse, praktiska labbar och tydlig rapportering. Certifieringar kan ge struktur, men de bör fungera som stöd för praktisk förmåga snarare än som slutmål.
Den mest effektiva nästa steget är att välja en molnplattform, bygga ett avgränsat labb och skriva en rapport som om den skulle lämnas till en riktig kund. När den cykeln upprepas med lagring, IAM, metadata, loggning och Kubernetes växer både kompetensen och portföljen. Readynez kan passa in som en strukturerad del av den resan, särskilt för den som vill koppla praktiska projekt till erkända moln- och säkerhetscertifieringar.
