AWS Pentest: Så testar svenska företag sin molnsäkerhet
Group COO & CISO
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
AWS Pentest: Så testar svenska företag sin molnsäkerhet
Ett AWS-penetrationstest simulerar verkliga angrepp mot er molnmiljö — inte för att hitta teoretiska risker, utan för att bevisa vilka attackkedjor som faktiskt fungerar mot just er konfiguration. Med Shared Responsibility-modellen ansvarar ni för säkerheten i molnet, medan AWS skyddar infrastrukturen under det. De flesta sårbarheter vi hittar i kundmiljöer handlar om felkonfigurationer, inte brister i AWS plattform.
Viktiga slutsatser
- AWS tillåter penetrationstester utan förhandsgodkännande för de flesta tjänster — men med tydliga villkor
- Shared Responsibility-modellen innebär att felkonfigurationer i IAM, S3 och nätverkssegmentering är ert ansvar att testa
- NIS2-direktivet ställer krav på regelbunden säkerhetstestning för organisationer i väsentliga och viktiga sektorer
- Automatiserade sårbarhetsskanningar är inte samma sak som penetrationstester — manuell verifiering avslöjar de verkliga attackkedjorna
- Kombinera AWS-native verktyg (GuardDuty, Inspector, Security Hub) med extern testning för heltäckande bild
Shared Responsibility — och varför det avgör testningens scope
AWS Shared Responsibility Model är inte ett marknadsföringsbegrepp. Det är den kontraktsmässiga gränsen som bestämmer vad ni måste testa och vad AWS redan hanterar.
AWS ansvarar för: Fysisk säkerhet i datacenter, hypervisor-lagret, globalt nätverksbackbone, och grundläggande tjänsteinfrastruktur (hårdvara, firmware, patching av den underliggande plattformen).
Ni ansvarar för: Allt ovanför det — operativsystemkonfiguration på EC2-instanser, IAM-policies och rollstrukturer, säkerhetsgrupper och NACL:er, S3-bucket-policies, krypteringsnyckelhantering via KMS, applikationskod, och hur ni kopplar samman tjänster.
I praktiken innebär detta att ett AWS-penetrationstest fokuserar på er del av stacken. Vi på Opsio ser regelbundet miljöer där kunderna litar på att "AWS sköter säkerheten" — men där IAM-roller har wildcard-behörigheter, S3-buckets exponerar data via felaktiga bucket policies, och säkerhetsgrupper tillåter all trafik från 0.0.0.0/0 på portar som aldrig borde vara öppna.
Vill ni ha expertstöd med aws pentest: så testar svenska företag sin molnsäkerhet?
Våra molnarkitekter hjälper er med aws pentest: så testar svenska företag sin molnsäkerhet — från strategi till implementation. Boka ett kostnadsfritt 30-minuters rådgivningssamtal utan förpliktelse.
AWS regler för penetrationstester
Sedan 2019 tillåter AWS penetrationstester mot era egna resurser utan att ni behöver skicka in en förhandsbegäran. Det är en viktig förenkling jämfört med hur det fungerade tidigare, men det finns tydliga gränser.
Tillåtna tjänster
Enligt AWS Customer Support Policy for Penetration Testing får ni testa bland annat:
- Amazon EC2-instanser, NAT Gateways, Elastic Load Balancers
- Amazon RDS
- Amazon CloudFront
- Amazon Aurora
- Amazon API Gateway
- AWS Lambda och Lambda Edge
- Amazon Lightsail
- Amazon Elastic Beanstalk
Uttryckligen förbjudet
- DDoS-simulering (använd istället AWS DDoS Simulation Testing via godkända partners)
- DNS zone walking mot Route 53 Hosted Zones
- Port flooding och protokoll-flooding
- Trafik som medvetet överbelastar AWS infrastruktur
Bryter ni mot dessa villkor riskerar ni att AWS stänger av ert konto. Vi har sett det hända — det är inte ett teoretiskt hot.
Praktiskt tips
Även om förhandsgodkännande inte krävs rekommenderar vi att ni dokumenterar testningens scope, tidsperiod och ansvarig part skriftligt. Det skyddar er internt, mot er revisionsfunktion, och utgör bevisunderlag vid NIS2-tillsyn.
Vad ett AWS-penetrationstest faktiskt testar
Ett kompetent penetrationstest mot en AWS-miljö handlar inte om att köra nmap mot publika IP-adresser. De verkliga riskerna sitter djupare.
IAM — den vanligaste attackytan
IAM-konfigurationer är den enskilt viktigaste attackytan i AWS. Här ser vi återkommande problem:
| Sårbarhet | Vad det innebär i praktiken | Allvarlighetsgrad |
|---|---|---|
Wildcard-policies ("Action": "*") | En komprometterad roll ger full kontroll över kontot | Kritisk |
| Saknad MFA på root-konto | Angripare med stulna credentials kan ta över hela organisationen | Kritisk |
| Överflödiga cross-account roles | Lateral movement mellan konton utan begränsning | Hög |
| Långlivade access keys utan rotation | Läckta nycklar på GitHub ger persistent åtkomst | Hög |
| Överdrivna Lambda-exekveringsroller | Funktioner med AdministratorAccess — vanligare än ni tror | Medel–Hög |
I Opsios SOC ser vi varje månad larm från AWS GuardDuty som pekar på just dessa mönster: credentials som används från ovanliga geolokaliseringar, API-anrop mot tjänster som en roll normalt inte berör, och S3-åtkomst från IP-adresser utanför organisationens kända intervall.
S3-buckets och dataexponering
S3-felkonfigurationer har orsakat några av de mest uppmärksammade dataläckorna globalt. Problemet är sällan att bucketen är "public" i AWS-konsolens mening — det handlar oftare om:
- Bucket policies som tillåter
s3:GetObjectför"Principal": "*"på specifika prefix - ACL:er som ärvts från äldre konfigurationer
- Cross-account access som inte reviderats efter organisationsförändringar
- Presigned URLs med orimligt lång giltighetstid
Nätverkssegmentering och VPC-konfiguration
Vi testar hur väl er VPC-arkitektur isolerar olika tjänster och miljöer. Vanliga fynd inkluderar:
- Avsaknad av privata subnät för databaser — RDS-instanser i publika subnät med säkerhetsgrupper som enda skydd
- VPC Peering utan restriktiv routning, vilket möjliggör lateral movement mellan miljöer
- Säkerhetsgrupper som refererar till
0.0.0.0/0istället för specifika CIDR-block eller prefix lists - Avsaknad av VPC Flow Logs, vilket försvårar forensisk analys efter en incident
Metadata-tjänsten (IMDS)
Instance Metadata Service (IMDS) på EC2 har historiskt varit en av de mest exploaterade attackvektorerna i AWS. SSRF-sårbarheter (Server-Side Request Forgery) i applikationer har använts för att stjäla temporära credentials via http://169.254.169.254.
AWS lanserade IMDSv2 som kräver session-tokens, men vi ser fortfarande miljöer som kör med IMDSv1 aktiverat. Ett penetrationstest ska verifiera att IMDSv2 är påtvingat (HttpTokens: required) på samtliga EC2-instanser.
Skillnaden mellan sårbarhetsskanning och penetrationstest
Förväxlingen mellan dessa två är den vanligaste missuppfattningen vi möter hos svenska organisationer.
| Aspekt | Sårbarhetsskanning | Penetrationstest |
|---|---|---|
| Metod | Automatiserade verktyg (Nessus, Qualys, AWS Inspector) | Manuell testning av certifierade specialister |
| Djup | Identifierar kända CVE:er och felkonfigurationer | Kedjar samman sårbarheter till faktiska attackvägar |
| Verifiering | Rapporterar potentiella risker utan att verifiera exploaterbarhet | Bevisar att en sårbarhet kan utnyttjas i er specifika miljö |
| Frekvens | Kontinuerligt / veckovis | Minst årligen + vid större förändringar |
| Utfall | Lista med sårbarheter och CVSS-poäng | Detaljerad rapport med attacknarrativer och affärsriskbedömning |
| Kostnad | Låg (verktygsbaserad) | Högre (specialistkompetens) |
En sårbarhetsskanning kan hitta att en EC2-instans kör en föråldrad Apache-version. Ett penetrationstest bevisar att den sårbarheten, i kombination med en öppen säkerhetsgrupp och en Lambda-funktion med överdrivna IAM-behörigheter, ger en angripare full åtkomst till produktionsdatabasen inom 20 minuter.
Båda behövs. De kompletterar varandra.
NIS2-direktivet och krav på säkerhetstestning
NIS2-direktivet, som trädde i kraft i EU under 2024 och som medlemsstaterna ska ha implementerat i nationell lagstiftning, ställer explicita krav på riskhantering och incidenthantering för organisationer i väsentliga och viktiga sektorer.
Artikel 21 i NIS2 specificerar att organisationer ska vidta "lämpliga och proportionella tekniska, operativa och organisatoriska åtgärder" för att hantera risker. Penetrationstester är inte uttryckligen namngivna i direktivtexten, men de är den mest etablerade metoden för att uppfylla kravet på att "testa och utvärdera effektiviteten" i säkerhetsåtgärder.
Vad detta innebär för svenska organisationer
- Dokumentationskrav: Resultaten från penetrationstester bör dokumenteras strukturerat och kunna uppvisas vid tillsyn
- Regelbundenhet: Engångstester räcker inte — NIS2 förutsätter löpande utvärdering
- Scope: Testningen bör omfatta hela den infrastruktur som stödjer väsentliga tjänster, inklusive molnmiljöer
- Leverantörskedjor: NIS2 adresserar även tredjepartsrisker, vilket innebär att era molnleverantörers säkerhet också ska utvärderas
Utöver NIS2 kan ISO/IEC 27001 (kontrollerna i Annex A, särskilt A.8 — teknologiska kontroller) och SOC 2 Type II kräva regelbunden penetrationstestning som del av er säkerhetsstyrning.
Molnmigrering med säkerhetsfokus
Metodiskt tillvägagångssätt: Så ser ett AWS-pentest ut i praktiken
1. Scoping och förberedelse
Innan testet börjar definieras exakt vad som ska testas. Ett avgränsat scope ger bättre resultat än ett vagt "testa allt". Typiska frågor:
- Vilka AWS-konton ingår?
- Vilka tjänster och regioner?
- Finns multi-account-setup via AWS Organizations?
- Vilken testtyp — black box, grey box eller white box?
- Ska social engineering ingå?
- Vilka tidsperioder och eskaleringsvägar gäller?
2. Rekognosering
Kartläggning av den externa attackytan: DNS-poster, publika S3-buckets, exponerade API:er, metadata i certifikat, och information som läckt via GitHub, Docker Hub eller andra publika källor.
3. Sårbarhetsbedömning och exploitation
Identifiering av sårbarheter genom både automatiserade verktyg och manuell analys. De sårbarheter som bedöms som exploaterbara testas kontrollerat — alltid med möjlighet att avbryta om risken för produktionspåverkan bedöms som för hög.
4. Lateral movement och privilegieeskalering
Det mest värdefulla steget: att bevisa hur långt en angripare kan komma. Kan en komprometterad Lambda-funktion i dev-kontot nå produktionsdatabasen? Kan en IAM-användare med read-only-behörighet eskalera till administratör via en felkonfigurerad iam:PassRole?
5. Rapportering
Rapporten ska vara användbar — inte bara en lista med CVE-nummer. Den bör innehålla:
- Exekutiv sammanfattning för ledningen
- Teknisk detaljbeskrivning av varje fynd med steg-för-steg-reproduktion
- Riskbedömning kopplad till affärspåverkan
- Prioriterade åtgärdsrekommendationer
- Bevisunderlag (skärmdumpar, loggar, kommandon)
6. Verifieringstest
Efter att åtgärder genomförts bör ett verifieringstest utföras för att bekräfta att sårbarheterna faktiskt är åtgärdade. Vi ser alltför ofta att patchar appliceras men inte verifieras.
Vanliga misstag vi ser hos svenska organisationer
Testar bara produktionsmiljön. Angripare tar ofta vägen via dev- eller staging-miljöer som har svagare skydd men nätverksåtkomst till produktion.
Kör pentest en gång och bockar av. Molnmiljöer förändras kontinuerligt — en konfigurationsändring i Terraform kan öppna en attackväg som inte fanns förra veckan.
Blandar ihop pentest med compliance-scanning. AWS Config Rules och Security Hub Compliance Standards är bra för baslinje, men de simulerar inte en angripare.
Ignorerar IaC-lagret. Om era Terraform-moduler eller CloudFormation-templates innehåller felkonfigurationer kommer de att reproduceras vid varje deployment. Granska IaC som en del av säkerhetstestningen.
Managerad DevOps med säkerhetsintegration
AWS-native verktyg som komplement
Penetrationstester ger ögonblicksbilder. Mellan testerna behöver ni kontinuerlig övervakning:
- AWS GuardDuty — hotdetektering baserad på VPC Flow Logs, CloudTrail och DNS-loggar
- AWS Security Hub — aggregerad vy av säkerhetsfynd från Inspector, GuardDuty, Macie och Config
- AWS Inspector — automatiserad sårbarhetsskanning av EC2-instanser och Lambda-funktioner
- AWS CloudTrail — revisionslogg för alla API-anrop, grundläggande för forensik
- AWS Config — konfigurationshistorik och regelbaserad compliance-kontroll
Dessa verktyg ersätter inte penetrationstester, men de säkerställer att ni inte flyger blint mellan testomgångarna. I Opsios NOC integrerar vi dessa signaler i vår SIEM-plattform för att korrelera molnhändelser med övrig infrastruktur.
Cloud FinOps — optimera molnkostnader
Att välja rätt testpartner
Inte alla penetrationstestare förstår AWS. En duktig nätverkspentestare är inte automatiskt kompetent att testa IAM-policies eller serverless-arkitekturer. Sök efter:
- AWS-specifik erfarenhet — fråga efter referenscase från liknande miljöer
- Relevanta certifieringar — OSCP, OSWE, AWS Certified Security Specialty, CREST
- Transparent metodik — testaren ska kunna förklara sitt tillvägagångssätt innan testet börjar
- Rapportkvalitet — be om anonymiserade exempelrapporter
- Efterstöd — hjälp med åtgärdsarbetet, inte bara en rapport som lämnas över
Vanliga frågor
Behöver jag AWS godkännande innan jag kör ett penetrationstest?
Sedan 2019 kräver AWS inte längre förhandsgodkännande för penetrationstester mot de flesta tjänster (EC2, RDS, Lambda, API Gateway med flera). Däremot är DDoS-simulering, DNS zone walking och tester som genererar extrem trafik uttryckligen förbjudna utan separat avtal. Kontrollera alltid AWS Customer Support Policy for Penetration Testing för senaste villkor.
Hur ofta bör vi genomföra AWS-penetrationstester?
Minst årligen, samt efter större infrastrukturändringar — exempelvis nya VPC-peerings, migrering av tjänster eller förändringar i IAM-strukturen. Organisationer som omfattas av NIS2 bör överväga kvartalsvis testning av de mest kritiska systemen och dokumentera resultaten för tillsynsmyndigheten.
Vad kostar ett AWS-penetrationstest för ett svenskt medelstort företag?
Priset varierar kraftigt beroende på scope. En avgränsad test av en enskild applikation i AWS kan ligga på 80 000–150 000 SEK, medan en fullskalig test av en komplex multi-account-miljö med IaC-granskning kan kosta 300 000 SEK eller mer. Avgörande är att scopet definieras tydligt innan arbetet börjar.
Räcker det med AWS Security Hub och GuardDuty istället för penetrationstest?
Nej. AWS-native verktyg är utmärkta för kontinuerlig övervakning och konfigurationskontroll, men de testar inte hur sårbarheter kan kedjas samman till faktiska attackvägar. Ett penetrationstest simulerar en verklig angripare som kombinerar flera svagheter — något automatiserade verktyg inte gör.
Vilka AWS-tjänster är vanligast att testa?
IAM-konfigurationer (roller, policies, federation), S3-buckets (publika eller felkonfigurerade), EC2-instanser och säkerhetsgrupper, Lambda-funktioner med överdrivna behörigheter, samt RDS-databaser med nätverksexponering. Vi ser också allt fler tester av EKS-kluster och API Gateway-konfigurationer.
For hands-on delivery in India, see drift 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.
