Penetrationstest i molnet: så testar ni 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 ni AWS, Azure och GCP
Penetrationstest i molnmiljöer skiljer sig fundamentalt från traditionella infrastrukturtester. Den delade ansvarsmodellen, dynamiska resurser och plattformsspecifika IAM-system skapar attackytor som kräver specialiserad metodik. Den här guiden beskriver hur ni planerar, genomför och agerar på resultaten av penetrationstest i AWS, Azure och GCP — baserat på vad Opsios SOC-team faktiskt ser i kunders produktionsmiljöer.
Viktiga slutsatser
- Molnens delade ansvarsmodell innebär att er organisation äger säkerheten för konfiguration, IAM och applikationer — inte leverantören
- Varje hyperscaler (AWS, Azure, GCP) har egna regler för penetrationstest som måste följas för att undvika kontostängning
- Felkonfigurerade lagringstjänster, överprivilegierade IAM-roller och exponerade API:er utgör de vanligaste fynden vi ser i produktion
- Penetrationstest i molnet kräver en kombination av automatiserade verktyg och manuell expertis — enbart scanning räcker inte
- NIS2-direktivet och GDPR ställer explicita krav på regelbunden säkerhetstestning för organisationer som hanterar känsliga data i EU
Varför penetrationstest i molnet inte är samma sak som traditionella tester
I en klassisk on-premise-miljö testar ni nätverkssegmentering, brandväggsregler och fysiska servrar. I molnet existerar inget av det på samma sätt. Resurser skapas och förstörs programmatiskt, nätverket är mjukvarudefinierat och identitet har ersatt nätverksperimetern som primärt försvarslager.
Det innebär att penetrationstestaren behöver förstå tre saker som saknas i traditionell metodik:
IAM som attackyta. I AWS har en enda IAM-roll med sts:AssumeRole-behörighet mot ett annat konto potential att bli en lateral movement-vektor som aldrig syns i en nätverksskanning. I Azure är Managed Identities knutna till resurser — en komprometterad App Service kan ge tillgång till Key Vault-hemligheter utan att ett enda lösenord exponeras.
Kontrollplanets exponering. Molnens API-lager (AWS API Gateway, Azure Resource Manager, GCP Cloud API) utgör en attackyta som inte existerar on-premise. Felkonfigurerade API-policies eller avsaknad av service control policies (SCP) i AWS Organizations kan ge en angripare möjlighet att skapa nya resurser, exfiltrera data eller inaktivera loggning.
Delat ansvar i praktiken. Enligt AWS Shared Responsibility Model ansvarar leverantören för säkerheten av molnet (fysisk infrastruktur, hypervisor), medan ni ansvarar för säkerheten i molnet (konfiguration, data, åtkomst). Opsios SOC ser regelbundet att organisationer missar denna gränsdragning — man förlitar sig på att "AWS sköter säkerheten" utan att inse att en öppen S3-bucket är kundens ansvar.
Vill ni ha expertstöd med penetrationstest i molnet: så testar ni aws, azure och gcp?
Våra molnarkitekter hjälper er med penetrationstest i molnet: så testar ni aws, azure och gcp — från strategi till implementation. Boka ett kostnadsfritt 30-minuters rådgivningssamtal utan förpliktelse.
Den delade ansvarsmodellen i detalj
| Lager | Molnleverantörens ansvar | Er organisations ansvar |
|---|---|---|
| Fysisk infrastruktur | Datacenter, nätverk, hårdvara | — |
| Hypervisor/värdoperativsystem | Patchning, härdning | — |
| Nätverkskonfiguration | Underliggande SDN | VPC-design, Security Groups, NACLs |
| Identitet & åtkomst | IAM-tjänstens tillgänglighet | IAM-policies, roller, MFA-krav |
| Data | Lagringstjänstens tillgänglighet | Kryptering, åtkomstkontroll, klassificering |
| Applikationer | — | Kod, beroenden, konfiguration |
| Regelefterlevnad | Certifieringar (SOC 2, ISO 27001) | Er egen efterlevnad inom GDPR, NIS2 |
Denna uppdelning avgör vad som ingår i scopet för ert penetrationstest. Ni kan inte testa leverantörens hypervisor — och ni ska inte heller göra det. Fokusera på det ni äger: konfiguration, IAM, nätverkspolicies, applikationslogik och datahantering.
Metodik: fem faser för penetrationstest i molnet
Fas 1: Scope och förutsättningar
Innan ett enda paket skickas behöver ni definiera:
- Vilka konton och prenumerationer som ingår (produktion, staging, utveckling)
- Vilka tjänster som är i scope (compute, lagring, databaser, serverless, Kubernetes)
- Testtyp: black-box (ingen förkunskap), grey-box (begränsad åtkomst) eller white-box (full insyn i arkitekturen)
- Plattformens regler — mer om detta i nästa avsnitt
- Tidsfönster och eskaleringsrutiner vid kritiska fynd
Grey-box-tester ger generellt mest värde per investerad krona i molnmiljöer. Ren black-box missar ofta interna konfigurationsbrister, medan white-box riskerar att bli en konfigurationsaudit snarare än ett realistiskt angreppstest.
Fas 2: Rekognosering och OSINT
Molnresurser läcker information på sätt som traditionell infrastruktur inte gör:
- DNS-poster avslöjar CNAME-records som pekar mot S3-buckets, CloudFront-distributioner eller Azure Blob Storage
- Certificate Transparency Logs visar alla SSL-certifikat utfärdade för era domäner — inklusive interna miljöer
- GitHub och GitLab — vi hittar regelbundet hårdkodade AWS-nycklar, connection strings och Terraform state-filer i publika repositories
- Shodan och Censys indexerar exponerade molntjänster, inklusive Elasticsearch-kluster och Kubernetes API-servrar
Verktyg som cloud_enum, MicroBurst (Azure) och Pacu (AWS) är specialbyggda för att identifiera molnspecifika attackytor under rekognoseringsfasen.
Fas 3: Sårbarhetsbedömning och exploatering
Här skiljer sig molntestning mest från traditionella tester. De vanligaste fyndkategorierna vi ser hos Opsios kunder:
Felkonfigurerad lagring. Öppna S3-buckets, Azure Blob-containrar med publik åtkomst, eller GCS-buckets med allUsers-behörighet. Enligt Datadogs State of Cloud-rapport är felkonfigurerade lagringstjänster konsekvent bland de vanligaste säkerhetsbristerna i molnmiljöer.
Överprivilegierade IAM-roller. Roller med AdministratorAccess eller :-policies på resurser som bara behöver läsbehörighet till en specifik tjänst. Vi ser detta i praktiskt taget varje AWS-konto vi testar.
Exponerade metadata-tjänster. SSRF-sårbarheter (Server-Side Request Forgery) som ger tillgång till instansens metadata-endpoint (169.254.169.254) och därigenom temporära IAM-credentials. IMDSv2 mitigerar detta i AWS men är fortfarande inte aktiverat överallt.
Serverless-specifika brister. Lambda-funktioner med hårdkodade hemligheter i miljövariabler, överprivilegierade exekveringsroller och event injection via otillräckligt validerade triggers.
Kubernetes-felkonfigurationer. Anonymt åtkomliga API-servrar, pods som körs som root, avsaknad av Network Policies och exponerade Kubernetes Dashboards. Managerad Kubernetes-säkerhet
Fas 4: Dokumentation och rapportering
En penetrationstestrapport som bara listar CVE:er är värdelös. Rapporten ska innehålla:
- Attackkedjor — inte enskilda fynd utan hur de hänger ihop till ett realistiskt angreppsscenario
- Affärspåverkan — vad en angripare faktiskt kan uppnå (dataexfiltrering, serviceavbrott, lateral rörelse till andra konton)
- Prioritering baserad på exploaterbarhet OCH affärskonsekvens, inte bara CVSS-poäng
- Konkreta åtgärdsförslag med referens till plattformens egna best practices (AWS Well-Architected Framework, Azure Security Benchmark, GCP Security Command Center)
Fas 5: Verifiering och re-test
Åtgärder utan verifiering är önsketänkande. Planera alltid in ett omtest av kritiska och höga fynd inom 30–60 dagar. Automatisera det som kan automatiseras: implementera Prowler eller ScoutSuite i er CI/CD-pipeline för att fånga regressioner.
Plattformsspecifika regler: vad ni måste veta
AWS
Sedan 2023 tillåter AWS penetrationstest mot de flesta egna resurser utan förhandsanmälan. Det inkluderar EC2, RDS, Lambda, API Gateway, CloudFront och Lightsail. Dock är DDoS-simulering, DNS zone walking via Route 53 och test mot AWS-infrastruktur (inte era resurser) fortfarande förbjudet. Läs alltid den aktuella versionen av AWS Customer Support Policy for Penetration Testing.
Azure
Microsoft kräver att ni följer deras Rules of Engagement for Penetration Testing men har tagit bort kravet på formellt godkännande via supportärende. Ni får testa era egna resurser inom er prenumeration. DDoS-testning kräver separat överenskommelse via Azure DDoS Testing Partners.
GCP
Google Clouds policy liknar AWS — ni behöver inget godkännande för att testa resurser ni äger. Undvik att generera trafik som kan tolkas som abuse, och läs Googles Acceptable Use Policy samt Terms of Service innan teststart.
| Aspekt | AWS | Azure | GCP |
|---|---|---|---|
| Förhandsanmälan krävs | Nej (de flesta tjänster) | Nej (sedan 2023) | Nej |
| DDoS-test tillåtet | Nej (utan AWS Shield-avtal) | Via partner | Nej |
| Sociala ingenjörstester | Ej mot AWS-personal | Ej mot Microsoft-personal | Ej mot Google-personal |
| Test av delade tjänster | Förbjudet | Förbjudet | Förbjudet |
Verktyg vi använder och rekommenderar
Plattformsspecifika:
- Prowler (AWS) — automatiserad säkerhetsaudit mot CIS Benchmarks och AWS best practices
- ScoutSuite (multicloud) — konfigurationsgranskning för AWS, Azure och GCP
- Pacu (AWS) — exploateringsramverk specifikt för AWS-miljöer
- MicroBurst (Azure) — rekognosering och exploatering av Azure-tjänster
- Checkov — statisk analys av Terraform, CloudFormation och Kubernetes-manifestfiler
Generella:
- Burp Suite Professional — webbapplikationstestning av molnhostade applikationer
- Nuclei — mallbaserad sårbarhetsskanning
- kubectl + kube-hunter — Kubernetes-specifik säkerhetstestning
Verktyg är bara så bra som analytikern som tolkar resultaten. Automatiserade skanningar genererar falska positiver och missar logiska brister. Manuell expertis är inte förhandlingsbar.
Regelefterlevnad: NIS2, GDPR och ISO 27001
NIS2-direktivet, som gäller i EU sedan oktober 2024, ställer explicita krav på riskhantering och incidentrapportering för väsentliga och viktiga entiteter. Penetrationstest är ett centralt verktyg för att uppfylla kravet på "regelbunden testning och utvärdering av säkerhetsåtgärder" (Artikel 21). Organisationer som träffas av NIS2 bör dokumentera sina penetrationstest som del av sin riskhanteringsprocess.
GDPR (Artikel 32) kräver "ett förfarande för att regelbundet testa, undersöka och utvärdera effektiviteten hos tekniska och organisatoriska åtgärder". Integritetsskyddsmyndigheten (IMY) har i flera tillsynsärenden refererat till avsaknad av penetrationstest som en brist i den tekniska säkerheten.
ISO/IEC 27001:2022 (Annex A, kontroll A.8.8) anger explicit "teknisk sårbarhetsinformation" och testning som kontrollmål. Penetrationstest är en naturlig del av ett certifierat ISMS.
SOC 2 Type II inkluderar penetrationstest som ett vanligt bevis under Common Criteria CC7.1 (organisationen upptäcker och åtgärdar sårbarheter). Många revisorer kräver det explicit.
Vad Opsios SOC ser i produktion
Baserat på vår 24/7-drift i Karlstad och Bangalore ser vi återkommande mönster som penetrationstest konsekvent fångar:
1. IAM-roller som inte följer minsta privilegium. Utvecklare skapar roller med breda behörigheter "för att det ska fungera" — och ingen tar bort dem.
2. Avsaknad av loggning och övervakning. CloudTrail är aktiverat men ingen analyserar loggarna. Utan GuardDuty, Microsoft Sentinel eller SIEM-integration blir loggarna meningslösa.
3. Bortglömda resurser. Staging-miljöer som aldrig stängdes ned, temporära EC2-instanser med publika IP-adresser, testdatabaser med produktionsdata.
4. Bristande nätverkssegmentering. Platta VPC:er utan Network ACLs eller Security Groups som tillåter all intern trafik.
5. Avsaknad av kryptering i transit. Intern trafik mellan tjänster som inte använder TLS, trots att det ofta är enkelt att aktivera.
Dessa fynd är inte exotiska zero-days. De är grundläggande konfigurationsbrister som existerar för att säkerhet inte var med från start i molnarkitekturen.
Cloud FinOps och kostnadsoptimering
Så bygger ni en löpande teststrategi
Ett penetrationstest per år räcker inte när er infrastruktur förändras dagligen via Terraform-pipelines och CI/CD-deploys. Bygg istället en modell med tre nivåer:
Nivå 1: Kontinuerlig automatiserad scanning — Prowler, ScoutSuite och Checkov i CI/CD-pipelinen. Fångar konfigurationsavvikelser innan de når produktion. Kör dagligen.
Nivå 2: Kvartalsvis riktad testning — fokuserade tester mot nya tjänster, nyligen ändrade arkitekturkomponenter och högriskområden. Kombinera automatiserade verktyg med manuell analys.
Nivå 3: Årligt fullskaligt penetrationstest — komplett grey-box- eller white-box-test av hela molnmiljön, inklusive attackkedjor, privilegieeskalering och lateral rörelse. Dokumenteras för revisorer och NIS2-efterlevnad.
Denna modell ger er kontinuerlig synlighet utan att spräcka budgeten. Automatiseringen fångar lågt hängande frukt, medan manuella tester hittar de komplexa brister som verktyg missar.
Vanliga frågor
Behöver vi tillstånd från molnleverantören för att köra penetrationstest?
Det beror på plattform. AWS tillåter sedan 2023 de flesta testtyper utan förhandsanmälan mot specifika egna resurser. Azure kräver att ni följer deras Rules of Engagement men inte längre formellt godkännande. GCP har liknande riktlinjer. Testa aldrig infrastruktur ni inte äger, och läs alltid leverantörens aktuella policy innan teststart.
Hur ofta bör vi genomföra penetrationstest i vår molnmiljö?
Minst årligen som baslinje, men kvartalsvis eller vid varje större arkitekturförändring är bättre praxis. NIS2 och ISO 27001 förväntar sig regelbunden testning. Infrastructure-as-Code-pipelines gör att miljön förändras kontinuerligt — ett test som är sex månader gammalt speglar sällan verkligheten.
Räcker det med automatiserade skanningsverktyg istället för manuella penetrationstest?
Nej. Verktyg som Prowler, ScoutSuite och Checkov fångar konfigurationsavvikelser effektivt, men de missar logiska brister, komplexa attackkedjor och affärslogikfel. Manuell testning behövs för att verifiera vad som faktiskt är exploaterbart och för att simulera en verklig angripares beteende.
Vad händer om penetrationstestet hittar en kritisk sårbarhet i produktion?
En seriös testleverantör rapporterar kritiska fynd omedelbart — inte först i slutrapporten. Hos Opsio eskalerar vi kritiska sårbarheter till er säkerhetsansvarig inom timmar via en separat kanal, med konkret åtgärdsförslag och stöd vid eventuell incidenthantering.
Vad kostar ett penetrationstest i molnet?
Kostnaden varierar kraftigt beroende på scopets storlek — antal konton, tjänster och miljöer. En fokuserad test av ett enskilt AWS-konto med ett par tjänster kan ligga på 50 000–150 000 SEK, medan en fullständig multicloud-granskning med flera hundra resurser kostar betydligt mer. Begär alltid en scope-workshop innan offert.
For hands-on delivery in India, see Opsio's disaster recovery.
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.
