Penetrationstest i molnet: så testar du AWS, Azure och GCP
Group COO & CISO
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
Penetrationstest i molnet: så testar du AWS, Azure och GCP
Penetrationstest mot molninfrastruktur kräver ett annat angreppssätt än klassiska on-prem-tester. Delat ansvarsmodellen, dynamiska resurser och leverantörsspecifika begränsningar gör att du inte kan köra samma Nmap-scan som mot ett eget datacenter och förvänta dig relevanta resultat. Den här guiden går igenom hur du planerar, genomför och agerar på penetrationstester i AWS, Azure och GCP – baserat på vad vi ser i Opsios SOC/NOC-drift varje dag.
Viktiga slutsatser
- Molnmiljöer har unika attackytor – IAM-felkonfigurationer, öppna API:er och delat ansvar gör traditionella pentester otillräckliga
- AWS, Azure och GCP har alla specifika regler för tillåten säkerhetstestning som måste följas
- Kombinera automatiserad sårbarhetsskanning med manuella tester för att fånga kedjeproblem som verktyg missar
- Koppla alltid tekniska fynd till affärsrisk – annars hamnar rapporten i en låda
- Regelbundna tester är ett krav i NIS2, PCI DSS och ISO 27001 – inte ett engångsprojekt
Varför molnet kräver en egen teststrategi
Många organisationer behandlar penetrationstest i molnet som en enkel förlängning av befintliga on-prem-rutiner. Det fungerar inte. Anledningen är den delade ansvarsmodellen (shared responsibility model) som alla tre stora leverantörer bygger sina tjänster kring.
I en IaaS-miljö ansvarar du för operativsystem, applikationer och data – men leverantören ansvarar för hypervisor och fysisk infrastruktur. I PaaS och SaaS skjuts gränsen ytterligare, och du tappar kontroll över allt fler lager. Det innebär att din attackyta ser annorlunda ut beroende på vilken typ av tjänst du kör.
Från Opsios SOC ser vi tre återkommande mönster som traditionella pentester missar:
- IAM-spridning (privilege escalation via IAM): En utvecklare med för breda rättigheter i AWS IAM kan eskalera till admin-åtkomst via en kedja av assume-role-policyer. Det här fångas sällan av nätverksbaserade skanners.
- Felkonfigurerad lagring: Publikt exponerade S3-buckets och Azure Blob-containers är fortfarande en av de vanligaste vägarna in. Enligt Datadogs State of Cloud har en betydande andel organisationer minst en publikt tillgänglig lagringsresurs.
- Serverless-blindfläckar: Lambda-funktioner, Azure Functions och Cloud Functions körs utan traditionell infrastruktur – och faller därmed utanför det de flesta skanningsverktyg täcker.
Det här betyder inte att traditionella tekniker är värdelösa. Du behöver fortfarande testa webbapplikationer, nätverkssegmentering och autentiseringsmekanismer. Men du måste utöka scope till att inkludera molnspecifika attackvektorer.
Vill ni ha expertstöd med penetrationstest i molnet: så testar du aws, azure och gcp?
Våra molnarkitekter hjälper er med penetrationstest i molnet: så testar du aws, azure och gcp — från strategi till implementation. Boka ett kostnadsfritt 30-minuters rådgivningssamtal utan förpliktelse.
Leverantörsregler: vad får du testa?
Innan du startar ett penetrationstest mot molninfrastruktur måste du förstå vad respektive leverantör tillåter. Att bryta mot dessa regler kan leda till avstängning av konton.
| Aspekt | AWS | Azure | GCP |
|---|---|---|---|
| Förhandsgodkännande | Krävs inte sedan 2023 för de flesta tester | Krävs inte – följ Rules of Engagement | Krävs inte |
| Tillåtna tester | Port scanning, sårbarhetsskanning, applikationstester mot egna resurser | Pentester mot egna tjänster/subscriptions | Tester mot egna projekt |
| Förbjudet | DNS zone walking, DDoS-simulering, Route 53-attacker | Tester som påverkar andra kunder, DDoS | DDoS, tester mot infrastruktur du inte äger |
| Anmälan | Formulär finns men krävs normalt inte | Inget formulär – följ policy | Inget formulär |
| Vanlig region | eu-north-1 (Stockholm) | Sweden Central | europe-north1 (Finland) |
Vår rekommendation: Dokumentera alltid att ni har läst och följer leverantörens aktuella testpolicy innan ni startar. Spara skärmdumpar av policyn – den kan ändras, och vid en tvist vill ni visa vad som gällde vid testtillfället.
Steg-för-steg: så genomför du ett penetrationstest i molnet
1. Scope-definition och rekognosering
Scope-definitionen är det steg som avgör om testet blir värdefullt eller meningslöst. Vi ser regelbundet uppdrag där scope är antingen för brett ("testa allt i vårt AWS-konto") eller för smalt ("testa bara den här appen").
En effektiv scope-definition bör inkludera:
- Tjänstetyper: Vilka IaaS-, PaaS- och SaaS-tjänster ingår?
- Konton och subscriptions: Exakt vilka AWS-konton, Azure-subscriptions eller GCP-projekt?
- Miljöer: Produktion, staging, utveckling?
- Testtyper: Black-box, grey-box eller white-box?
- Undantag: Vad får inte testas (t.ex. tredjepartstjänster)?
Rekognoseringen i molnet handlar inte bara om att skanna portar. Använd verktyg som ScoutSuite, Prowler (AWS) eller AzureHound för att kartlägga IAM-strukturer, nätverkstopologi och tjänstekonfigurationer innan de manuella testerna börjar.
2. Automatiserad sårbarhetsskanning
Automatiserade verktyg ger baslinje och bredd. De fångar kända CVE:er, felkonfigurationer och policy-avvikelser. Men de ersätter inte manuella tester – de kompletterar dem.
Verktyg vi använder i Opsios testprocesser:
- Prowler / AWS Security Hub – konfigurationsgranskning mot CIS Benchmarks
- ScoutSuite – multi-cloud konfigurationsanalys
- Checkov / tfsec – IaC-scanning av Terraform och CloudFormation innan deployment
- Nuclei / Burp Suite – applikationstester mot exponerade endpoints
- Pacu – AWS-specifikt exploateringsramverk för IAM-kedjor
Automatiserade skanningar genererar ofta hundratals fynd. Utan prioritering blir resultatet oanvändbart. Vi kategoriserar alltid fynd efter exploaterbarhet i just den miljön – inte bara efter CVSS-poäng.
3. Manuell testning och kedjeproblem
Här sker det verkliga värdeskapandet. Manuella tester avslöjar kedjeproblem – situationer där flera låg- eller medel-sårbarheter tillsammans ger en kritisk attackväg.
Exempel från en verklig Opsio-bedömning: En kund hade en Lambda-funktion med läsrättigheter till en DynamoDB-tabell. Funktionen triggas av en API Gateway utan autentisering. Ingen av dessa var "kritisk" isolerat. Men i kedja innebar det att en anonym angripare kunde läsa kunddata via ett enkelt HTTP-anrop. Automatiserade verktyg flaggade ingen av delarna som kritisk.
Typiska manuella testområden i molnet:
- IAM privilege escalation – kan en användare med begränsade rättigheter nå admin?
- Cross-account access – finns trust relationships som ger oavsiktlig åtkomst?
- Metadata-tjänster – kan SSRF-attacker nå IMDSv1 och hämta credentials?
- Container breakout – i EKS/AKS/GKE, kan en komprometterad pod nå node-nivå?
4. Rapportering med affärskontext
En pentestrapport som bara listar CVE:er och CVSS-poäng har begränsat värde för beslutsfattare. Vi kopplar varje kritiskt fynd till konkret affärspåverkan:
- Vad kan en angripare uppnå? (dataläckage, tjänstavbrott, lateral rörelse)
- Vilka system och data påverkas? (kunddata, finansiella system, IP)
- Hur lång tid tar exploatering? (minuter vs. dagar)
- Vad är åtgärdskostnaden kontra riskkostnaden?
Den här typen av rapportering gör att säkerhetsteamet kan argumentera för budget och prioritering – inte bara skicka en PDF som ingen läser.
Regulatoriska krav som driver pentesting
NIS2-direktivet
NIS2, som trädde i kraft 2024, ställer explicita krav på att väsentliga och viktiga entiteter genomför regelbundna säkerhetstester, inklusive penetrationstester. Svenska organisationer som omfattas måste kunna visa att de testar sina molnmiljöer systematiskt – inte bara sina on-prem-system.
PCI DSS 4.0
PCI DSS 4.0 kräver penetrationstest minst årligen och efter signifikanta förändringar. I molnmiljöer där infrastruktur ändras dagligen via IaC blir definitionen av "signifikant förändring" avgörande. Vi rekommenderar att koppla pentester till CI/CD-pipelinen snarare än till kalendern.
ISO/IEC 27001
ISO 27001 Annex A kräver teknisk sårbarhetsbedömning. Penetrationstest är det mest konkreta sättet att visa efterlevnad, särskilt i kombination med kontinuerlig konfigurationsgranskning.
Kontinuerlig testning vs. engångsprojekt
Molninfrastruktur är inte statisk. En Terraform-ändring kan introducera en ny sårbarhet på minuter. Därför räcker det inte med ett årligt penetrationstest – även om det uppfyller minimikrav.
Vi rekommenderar en trestegsmodell:
1. Kontinuerlig konfigurationsgranskning (daglig) – automatiserade verktyg som Prowler, AWS Config Rules eller Azure Policy som flaggar avvikelser i realtid
2. Kvartalsvis sårbarhetsskanning – bredare automatiserad testning inklusive applikationslager
3. Årligt eller halvårligt penetrationstest – djupgående manuell testning med fokus på kedjeproblem och nya attackvektorer
Denna kombination ger både bredd och djup, och säkerställer att ni inte bara hittar problem utan också fångar regressioner.
Vanliga misstag vi ser
Testa bara applikationslagret. Många organisationer beställer webbapplikationstester men missar helt IAM, nätverkskonfiguration och lagringsrättigheter. Det är som att låsa ytterdörren men lämna garageöppet.
Använda bara automatiserade verktyg. Verktyg som Prowler och ScoutSuite är utmärkta för bredd, men de kan inte resonera om kedjeproblem. Manuell kompetens är oersättlig.
Ignorera staging-miljöer. Staging-miljöer har ofta samma konfiguration som produktion men sämre övervakning. Angripare vet detta.
Rapporten hamnar i en låda. Det spelar ingen roll hur bra testet är om ingen agerar på resultaten. Säkerställ att det finns en dokumenterad process för åtgärdsuppföljning med tidsramar och ansvariga.
Vanliga frågor
Vad skiljer ett penetrationstest i molnet från ett traditionellt pentest?
I molnet testar du inte bara operativsystem och applikationer utan även IAM-policyer, nätverkssegmentering via security groups, lagringsrättigheter (S3/Blob), serverless-funktioner och API-gateways. Du arbetar dessutom inom leverantörens acceptanspolicy, vilket begränsar vilka tester du får köra utan förhandsgodkännande.
Behöver jag tillstånd från molnleverantören för att köra penetrationstest?
AWS kräver sedan 2023 inte längre förhandsgodkännande för de flesta tester mot egna resurser, men förbjuder fortfarande DNS zone walking och DDoS-simulering. Azure tillåter tester mot egna tjänster utan anmälan så länge du följer deras Rules of Engagement. GCP kräver inget godkännande men förbjuder tester som påverkar andra kunder. Kontrollera alltid aktuell policy.
Hur ofta bör vi genomföra penetrationstest i vår molnmiljö?
Minst årligen för att uppfylla krav i ISO 27001 och PCI DSS, men vi rekommenderar kvartalsvis eller vid varje större infrastrukturförändring. Molnmiljöer förändras snabbare än traditionell infrastruktur – en ny IAM-roll eller ett ändrat security group kan skapa en kritisk sårbarhet över en natt.
Vad kostar ett penetrationstest mot molninfrastruktur?
Kostnaden varierar med scope, men ett fokuserat test mot en enskild AWS-miljö med 20–50 resurser ligger typiskt mellan 80 000 och 200 000 SEK. Mer omfattande tester som inkluderar flera molnleverantörer, applikationstester och social engineering hamnar högre. Det viktiga är att definiera scope tydligt – ett dåligt avgränsat test ger varken bra resultat eller rimlig kostnad.
Kan vi köra penetrationstest mot produktionsmiljön?
Ja, men med försiktighet. Vi rekommenderar att starta mot staging-miljöer och sedan utöka till produktion med tydliga regler för eskalering och nödstopp. I molnet kan du snurra upp en speglad miljö via Infrastructure as Code, vilket ger realistiska tester utan risk för kundpåverkande avbrott.
For hands-on delivery in India, see disaster recovery for enterprise.
For hands-on delivery in India, see gcp managed for enterprise.
Relaterade artiklar
Om författaren
Group COO & CISO at Opsio
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
Editorial standards: This article was written by a certified practitioner and peer-reviewed by our engineering team. We update content quarterly to ensure technical accuracy. Opsio maintains editorial independence — we recommend solutions based on technical merit, not commercial relationships.
