Molnsäkerhet med Prowler: 12 Steg, 60 Min [2026]

72 procent av alla molnmiljöer har publikt exponerade PaaS-databaser utan grundläggande åtkomstkontroller, enligt Wiz Cloud Data Security Snapshot 2025. Orca Security lägger till en siffra som borde få vem som helst att svettas: 93 procent av organisationer har minst ett molnkonto med alldeles för höga rättigheter. Det är inte exotiska nolldagarsattacker som dränker svenska och nordiska bolag i incidenter. Det är öppna S3-hinkar, glömda säkerhetsgrupper och IAM-roller som ingen vågar städa upp i, och de ligger där i månader innan någon upptäcker dem manuellt.

Den här guiden visar hur du hittar och fixar de felkonfigurationerna i AWS med Prowler, verktyget som enligt projektets egen GitHub-sida är världens mest använda open source-skanner för molnsäkerhet. Vi kör igenom installation, din första skanning, åtgärder för de vanligaste bristerna och hur du sätter upp kontinuerlig övervakning så att problemen inte bara försvinner tillfälligt. Totalt 12 steg, cirka 60 minuter aktiv tid om du följer med i en testmiljö parallellt med läsningen. I slutet bygger vi ihop allt till ett komplett saneringsprojekt du kan lägga i ett eget repo redan i dag, 21 augusti 2026.

Du behöver inte redan vara säkerhetsspecialist för att följa med. Guiden är skriven för utvecklare, DevOps-ingenjörer och it-ansvariga på mindre och medelstora bolag som sköter sin egen AWS-drift, ofta utan ett dedikerat säkerhetsteam. Har ni redan en incidentplan enligt NIS2 är den här typen av proaktiv skanning ett av de enklaste sätten att faktiskt minska antalet incidenter ni någonsin behöver rapportera.

Många team skjuter upp den här typen av granskning för att den låter tidskrävande. Verkligheten är att den tunga initiala genomgången tar en eftermiddag, medan resten av arbetet handlar om att automatisera bort behovet av att någonsin göra samma jobb manuellt igen. Betrakta den här guiden som en investering en gång, inte en återkommande uppgift ni måste komma ihåg att göra varje kvartal.

Molnfelkonfigurationer 2025-2026: siffrorna bakom problemet

Innan vi öppnar terminalen är det värt att se helheten. Orca Security beskriver läget rakt av: molnrisk 2025 drivs av identitet, hemligheter och trasiga pipelines snarare än enstaka isolerade misstag. Ett enda felkonfigurerat S3-objekt kan enligt samma rapport öppna upp till 165 142 olika attackvägar i det värsta fallet som analyserats. Det låter extremt, men det förklarar varför säkerhetsteam i Stockholm, Oslo och Helsingfors just nu prioriterar om sina granskningsrutiner.

Felkonfiguration	Andel drabbade organisationer	Källa
Publikt exponerade PaaS-databaser utan åtkomstkontroll	72%	Wiz, 2025
Över-privilegierade tjänstekonton	93%	Orca Security, 2025
Klartext-hemligheter i kodrepon	85%	Orca Security, 2025
Exponerade VM/serverless-instanser med känslig data	54%	Wiz, 2025
GitHub Actions med automatisk PR-godkännande	40%	Orca Security, 2025
Molntillgångar i eftersatt (neglected) tillstånd	32%	Orca Security, 2025

Öppna lagringshinkar är fortfarande den mest dokumenterade kategorin i faktiska intrång. Verktyg som TruffleHog och S3Scanner indexerar publika S3-hinkar kontinuerligt, och en nyöppnad hink hittas ofta inom timmar, inte veckor. Det är exakt den typen av tidsfönster Prowler är byggt för att stänga, genom att ni själva hittar problemet innan någon utomstående gör det.

Orca-rapporten pekar också på att riskerna sällan står ensamma. En över-privilegierad roll i kombination med en läckt nyckel och en öppen port bildar tillsammans en attackkedja som är mycket värre än varje del för sig. Just därför bygger den här guiden inte bara på att lista enskilda fel, utan på ett arbetsflöde där ni hittar, prioriterar och åtgärdar dem i rätt ordning.

Vad är Prowler och varför det blivit standardverktyget

Prowler är en open source-skanner som granskar AWS, Azure, GCP och Kubernetes mot ramverk som CIS Benchmarks, NIST och egna policyer. Projektet ligger på GitHub och beskrivs där som världens mest använda open source-verktyg för molnsäkerhetsbedömningar. Senaste versionen i skrivande stund är 5.36.0, släppt 24 juli 2026, efter tätt på varandra följande uppdateringar (5.35.0 den 17 juli, 5.33.0 den 7 juli). Julireleaserna 2026 lade till bättre tvärmoln-komplians och enklare onboarding för AWS-konton, samt en funktion kallad Autonomous Fixer som föreslår guidad åtgärd direkt utifrån fynden.

Skillnaden mot att bara klicka runt i AWS-konsolen är hastighet och upprepbarhet. Prowler kör hundratals kontroller på minuter, taggar varje fynd med allvarlighetsgrad och kan köras om automatiskt varje natt. Det gör verktyget lika användbart för ett enmansteam på ett litet SaaS-bolag i Göteborg som för en säkerhetsavdelning med femtio AWS-konton. Varje kontroll är kopplad till en unik identifierare och en kort motivering, vilket gör det enkelt att slå upp exakt varför något flaggats och vad AWS rekommenderar som åtgärd.

Utöver de tekniska kontrollerna kan Prowler också mappa fynd direkt mot efterlevnadsramverk som ISO 27001, SOC 2 och GDPR-relaterade kontroller. Det gör att en enda skanning kan svara på flera frågor samtidigt: är vi säkra, och kan vi visa upp det för en revisor eller en tillsynsmyndighet utan att bygga en separat rapport för varje ramverk.

Autonomous Fixer, funktionen som lades till under 2026, går ett steg längre än ren rapportering. Den analyserar varje fynd och föreslår ett konkret, körbart kommando eller en Terraform-ändring som löser exakt det problemet, i stället för att bara peka på ett dokument. Team som testat funktionen beskriver den som ett bra sätt att korta ner tiden mellan fynd och åtgärd för de enklaste, mest repetitiva felkonfigurationerna, medan mer komplexa fynd som rör flera sammankopplade resurser fortfarande kräver mänsklig bedömning innan något ändras.

Förkunskaper och verktyg du behöver

Du behöver inte vara AWS-certifierad för att följa den här guiden, men grundläggande erfarenhet av AWS CLI och IAM gör allt enklare. Räkna med följande innan du börjar.

Verktyg	Version	Syfte i den här guiden
Prowler	5.33.0 eller senare (5.36.0 aktuell)	Huvudskanner för AWS-felkonfigurationer
Python	3.11 eller senare	Krävs för att installera och köra Prowler via pip
AWS CLI	v2 (senaste)	Autentisering och verifiering av fynd
Trivy	0.71.0 (Aqua Security, juni 2026)	Skanna IaC-mallar och containrar innan driftsättning
Checkov	senaste version från pip	Policykontroller på Terraform/CloudFormation
Docker	valfritt, senaste stabila	Alternativ körning av Prowler utan lokal Python-miljö

Du behöver också ett AWS-konto med rättigheter att skapa en IAM-roll, samt tillgång till en testmiljö. Kör aldrig din första skanning direkt i produktion utan att ha läst igenom hela guiden först. Skapa antingen ett separat säkerhetskonto inom er AWS Organization, eller testa i ett konto med begränsad blastradie, så att du hinner förstå fynden innan du rör något som faktiskt är i drift. Behöver ni skanna flera konton samtidigt, som är standard i de flesta lite större AWS-organisationer, går det bra att antingen köra Prowler mot varje konto separat eller sätta upp en central roll som kan anta motsvarande roll i varje undercontot.

Kostnad och tidsåtgång: vad detta faktiskt kräver av teamet

En vanlig invändning innan man börjar är att det här låter som ett veckolångt projekt. I praktiken går den initiala installationen och första triagen på en dryg arbetsdag, medan resten av tiden går till att åtgärda de fynd som faktiskt finns i just ert konto. Tabellen nedan ger en realistisk uppskattning per fas, baserad på ett medelstort konto med några hundra resurser fördelat på tre-fyra AWS-regioner.

Fas	Uppskattad tidsåtgång	Vem gör det
Installation och IAM-roll (steg 1-2)	15-20 minuter	En utvecklare eller DevOps-ingenjör
Första skanning och triage (steg 3-4)	30-45 minuter	Samma person, eventuellt med säkerhetsansvarig
Åtgärda kritiska fynd (steg 5-8)	2-6 timmar, beroende på antal fynd	Teamet som äger respektive resurs
Automatisering och CI/CD (steg 9-11)	1-2 timmar engångsarbete	DevOps-ingenjör
Löpande drift efter lansering	15-30 minuter per vecka	Roterande ansvar inom teamet

Notera att den tunga initiala kostnaden är en engångsinsats. Så fort automatiseringen i steg 9-11 är på plats krymper det löpande arbetet till att bara hantera nya fynd som dyker upp, snarare än att göra om hela granskningen från grunden varje gång.

Räkna också in kostnaden för själva AWS-anropen. Prowler kör enbart läsoperationer mot AWS API:er, och de flesta av dessa ingår i det fria kvoten för API-anrop som AWS erbjuder alla konton. För ett konto i normalstorlek brukar en fullständig nattlig skanning inte synas som en märkbar post på fakturan, även om extremt stora konton med tiotusentals resurser kan behöva ta hänsyn till API-begränsningar snarare än direkta kronor och ören.

Steg 1-4: Installation och din första skanning

Steg 1: Installera Prowler

Enklaste vägen är via pip. Kontrollera versionen direkt efter installation så du vet att du kör 5.33.0 eller nyare, eftersom äldre versioner saknar de senaste komplianskartorna och en del av kontrollerna för nyare AWS-tjänster.

pip install prowler
prowler --version
# Förväntad utskrift: Prowler 5.36.0

Föredrar du att slippa lokala Python-beroenden går det lika bra via Docker, vilket också är smidigare i CI-miljöer senare i guiden, eftersom du slipper hantera Python-versioner i byggagenten.

docker pull toniblyx/prowler:latest
docker run -v ~/.aws:/root/.aws toniblyx/prowler:latest aws --version

Steg 2: Skapa en säker, skrivskyddad IAM-roll

Kör aldrig Prowler med administratörsrättigheter. Verktyget behöver bara läsa, inte skriva. AWS har en färdig hanterad policy för detta, SecurityAudit, som du kompletterar med några läsrättigheter Prowler behöver utöver standardomfånget för att kunna kontrollera saker som lösenordspolicy och krypteringsinställningar på djupet.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetBucketPolicy",
        "s3:GetBucketAcl",
        "s3:GetEncryptionConfiguration",
        "iam:GenerateCredentialReport",
        "iam:GetAccountPasswordPolicy"
      ],
      "Resource": "*"
    }
  ]
}

Bifoga policyn ovan tillsammans med den AWS-hanterade arn:aws:iam::aws:policy/SecurityAudit på en dedikerad IAM-roll som Prowler antar via sts assume-role snarare än att köra på en delad utvecklarnyckel. Se guiden för AWS-onboarding i Prowlers officiella dokumentation om ni kör flera konton via AWS Organizations, där det finns färdiga CloudFormation StackSets för att rulla ut rollen till alla konton samtidigt.

Steg 3: Kör din första fullständiga skanning

När rollen är på plats och AWS CLI är konfigurerad mot den, kör en fullständig skanning av kontot. Första körningen tar allt från tre till femton minuter beroende på hur många resurser kontot har, och betydligt längre om ni skannar flera regioner samtidigt.

prowler aws --output-formats csv json-ocsf html --output-directory ./prowler-report

# Exempel på utskrift under körning:
# -> Scanning S3... 42 checks executed
# -> Scanning IAM... 38 checks executed
# -> Scanning EC2 Security Groups... 26 checks executed
# -> Report generated: prowler-report/prowler-output.html

Steg 4: Tolka resultaten och allvarlighetsgrader

Öppna HTML-rapporten. Varje fynd har en status (PASS/FAIL), en allvarlighetsgrad (critical, high, medium, low) och en hänvisning till vilket ramverk kontrollen kommer från, till exempel CIS AWS Foundations Benchmark. Ett enskilt fynd i JSON-formatet kan se ut ungefär så här, vilket gör det enkelt att bearbeta resultaten programmatiskt i egna skript senare i guiden.

{
  "check_id": "s3_bucket_public_access",
  "status": "FAIL",
  "severity": "critical",
  "resource_id": "mitt-foretags-bucket",
  "region": "eu-north-1",
  "compliance": ["CIS-1.5", "ISO27001-A.13.1"],
  "remediation": "Enable S3 Block Public Access at bucket and account level"
}

Börja alltid med critical och high, sortera sedan efter tjänst så att ni kan åtgärda flera relaterade fynd i samma arbetspass. En rimlig första triage tar 20-30 minuter för ett medelstort konto med några hundra resurser, längre om kontot är gammalt och aldrig städats.

Rapportens förstasida sammanfattar resultatet i en enkel siffra per allvarlighetsgrad, till exempel “14 critical, 38 high, 112 medium, 67 low” för ett typiskt mellanstort konto som aldrig granskats tidigare. Det är helt normalt att första körningen visar hundratals fynd. De flesta bolag som kör sin första skanning blir förvånade över volymen, men merparten brukar visa sig vara lågriskfynd som saknad taggning eller föråldrade lösenordspolicyer snarare än akuta säkerhetshål.

Steg 5-8: Hitta och åtgärda de vanligaste felen

Steg 5: Öppna S3-buckets

Publikt exponerad S3-lagring är fortfarande den mest dokumenterade molnfelkonfigurationen i faktiska intrångsrapporter. Filtrera Prowler-rapporten på kontrollen s3_bucket_public_access för att se exakt vilka hinkar som är öppna och varför, eftersom orsaken kan vara antingen en bucket-policy, en gammal ACL, eller en kombination av båda. Fixen är oftast att aktivera Block Public Access på kontonivå och per hink.

aws s3api put-public-access-block \
  --bucket mitt-foretags-bucket \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

Vill du sätta samma skydd på alla framtida hinkar i kontot i ett svep räcker det att köra samma kommando mot kontots standardinställning istället för en specifik bucket, vilket AWS rekommenderar som förstahandsåtgärd för alla konton som inte medvetet behöver publika hinkar.

Steg 6: Överprivilegierade IAM-roller

93 procent av organisationer har minst ett över-privilegierat tjänstekonto enligt Orca. Prowler flaggar roller med jokertecken ("Action": "*" eller "Resource": "*"), men de farligaste rollerna är ofta inte de mest uppenbara. Gå igenom varje flaggad roll, ta bort behörigheter som inte använts på 90 dagar (synligt via IAM Access Analyzer) och byt ut breda policyer mot scoped sådana som bara täcker exakt de tjänster och resurser rollen faktiskt behöver.

Ett bra sätt att prioritera är att fråga sig vilka roller som både är över-privilegierade och kopplade till internetexponerade resurser, till exempel en Lambda-funktion bakom en publik API-gateway. Den kombinationen är precis den typ av “toxisk kombination” som Wiz och Orca lyfter fram som störst risk, snarare än en isolerad överprivilegierad roll som bara körs internt.

Ett vanligt scenario i praktiken är en CI/CD-pipeline där byggagenten fått en bred deploy-roll för att “det var enklare” när projektet startade. Sådana roller lever ofta kvar långt efter att den ursprungliga anledningen försvunnit, eftersom ingen vill riskera att en snävare policy plötsligt bryter en pipeline som fungerar. Testa alltid en föreslagen strängare policy i en separat testpipeline innan ni byter ut den skarpa rollen, så att ni upptäcker eventuella saknade rättigheter innan det stoppar en riktig driftsättning.

Steg 7: Öppna säkerhetsgrupper

Säkerhetsgrupper som tillåter SSH eller RDP från 0.0.0.0/0 är ett klassiskt fynd som ändå dyker upp i nästan varje konto Prowler rör vid, ofta kvarglömt från en tidig testmiljö. Fixen är att låsa in trafiken till kända IP-intervall eller, ännu hellre, kräva åtkomst via AWS Systems Manager Session Manager istället för öppna portar, så att ni slipper hantera bastion-värdar och SSH-nycklar överhuvudtaget.

aws ec2 revoke-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp --port 22 --cidr 0.0.0.0/0

Steg 8: Okrypterad lagring i vila

Prowlers kontroller för EBS, RDS och S3 fångar upp volymer och databaser utan kryptering. Aktivera KMS-baserad kryptering som standard på kontonivå så nya resurser skyddas automatiskt, och migrera befintliga volymer via snapshot-och-återskapa istället för att försöka kryptera dem i drift, vilket i praktiken inte går för redan skapade EBS-volymer.

aws ec2 enable-ebs-encryption-by-default --region eu-north-1

Steg 9-12: Automatisering och kontinuerlig övervakning

Steg 9: Skanna infrastruktur som kod före driftsättning

Prowler granskar det som redan är driftsatt. För att stoppa nya felkonfigurationer innan de ens når AWS behöver du skanna Terraform-koden själv, med Checkov och Trivy 0.71.0 (Aqua Security, släppt 1 juni 2026 med bland annat förbättrat stöd för .NET-sårbarheter och CycloneDX 1.6). Det här steget är det som faktiskt förhindrar att samma fel upprepas nästa gång någon skriver ny infrastrukturkod.

Tänk på Prowler och IaC-skannrarna som två olika skyddslager snarare än konkurrenter. Checkov och Trivy stoppar nya problem innan de når produktion, medan Prowler fångar upp allt som redan finns där, inklusive resurser som skapats manuellt i konsolen och aldrig gått igenom en pull request överhuvudtaget. De flesta konton har en blandning av båda, särskilt äldre konton som funnits i flera år innan infrastruktur som kod blev standard i organisationen.

checkov -d ./terraform --framework terraform
trivy config ./terraform

# Exempel på utskrift:
# Check: CKV_AWS_18: "Ensure S3 bucket has access logging configured"
#   FAILED for resource: aws_s3_bucket.data
#   File: /main.tf:12-18

Steg 10: Automatisera skanningar med GitHub Actions

Lägg skanningen i pipelinen så att varje pull request granskas innan merge, och kör en fullständig kontoskanning schemalagt varje natt. Kör ni redan Checkov mot varje pull request kan du lägga till motsvarande jobb för Prowler som ett separat schemalagt arbetsflöde, så att det inte förlänger byggtiden för varje enskild kodändring.

name: prowler-nightly-scan
on:
  schedule:
    - cron: "0 3 * * *"
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Konfigurera AWS-uppgifter
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/prowler-readonly
          aws-region: eu-north-1
      - name: Kör Prowler
        run: |
          pip install prowler
          prowler aws --output-formats json-ocsf --output-directory ./report

Steg 11: Koppla till AWS Security Hub för kontinuerlig övervakning

Prowler kan skicka fynd direkt till AWS Security Hub via flaggan --security-hub, vilket ger er ett samlat läge om ni redan använder Security Hub eller GuardDuty. AWS har en färdig arkitekturguide för konsoliderade Prowler-rapporter över flera konton om ni kör en organisation med separata AWS-konton per team, vilket är standard hos de flesta bolag med mer än en handfull utvecklare.

Fördelen med den här kopplingen är att ni slipper bygga en egen dashboard från grunden. Security Hub visar redan fynd över tid, kan skicka notifieringar via Amazon SNS när nya critical-fynd dyker upp, och går att koppla vidare till samma Slack-kanal som resten av driftteamet redan bevakar. För mindre team utan ett dedikerat säkerhetsverktyg är det ofta den snabbaste vägen till en fungerande övervakningsprocess utan att behöva införa ytterligare ett fristående system.

Steg 12: Prioritera fynd utifrån attackvägar, inte antal

Ett vanligt misstag är att jaga det totala antalet fynd i stället för att fråga vilka som faktiskt går att kedja ihop till en riktig attackväg. Orca visar att 13 procent av organisationer har minst en tillgång som ensam öppnar över 1 000 attackvägar. Prioritera resurser som är delade mellan många team, internetexponerade och kopplade till känslig data, i den ordningen, snarare än att bara sortera på allvarlighetsgrad rakt av.

Bygg ett komplett saneringsprojekt

Sätt ihop stegen ovan till ett repo ni faktiskt kan använda måndag morgon. Strukturen nedan täcker skanning, IaC-kontroll och automatiserad rapportering i ett och samma projekt, och kan klonas rakt av som utgångspunkt för ert eget saneringsarbete.

prowler-remediation-pipeline/
├── .github/workflows/
│   └── prowler-nightly-scan.yml
├── iac/
│   └── terraform/            # infrastruktur som granskas av Checkov/Trivy
├── policies/
│   └── prowler-readonly-role.json
├── scripts/
│   ├── fix-public-buckets.sh
│   └── revoke-open-ports.sh
├── reports/                  # genererade HTML/JSON-rapporter, .gitignore:as
└── README.md

Skriptet fix-public-buckets.sh läser JSON-utdata från Prowler, filtrerar på kontrollen för publik S3-åtkomst och kör åtgärden automatiskt på varje träff, men bara efter att ha loggat vilka hinkar som påverkas så ni kan granska innan nästa körning låser dem permanent. En förenklad version av logiken ser ut så här.

#!/bin/bash
set -euo pipefail

REPORT="./prowler-report/prowler-output.json"
LOG="./reports/remediation-log-$(date +%F).txt"

jq -r '.[] | select(.check_id=="s3_bucket_public_access" and .status=="FAIL") | .resource_id' "$REPORT" \
| while read -r bucket; do
    echo "Åtgärdar publik åtkomst för: $bucket" | tee -a "$LOG"
    aws s3api put-public-access-block \
      --bucket "$bucket" \
      --public-access-block-configuration \
      BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
  done

Det är precis den här typen av hitta-logga-åtgärda-verifiera-loop som gör skillnaden mellan en engångsgranskning och ett saneringsprogram som faktiskt håller över tid. Kör skriptet manuellt de första veckorna, och koppla det sedan till samma nattliga GitHub Actions-jobb som redan kör skanningen, så att fynd och åtgärd hänger ihop utan extra manuellt steg.

README-filen i projektet bör dokumentera tre saker för nästa person som ärver repot: vilken IAM-roll som används och varför den har exakt de rättigheter den har, vilka kontroller som medvetet är tystade och varför, samt vem som äger respektive skript i mappen scripts/. Utan den dokumentationen blir saneringsprojektet snabbt en svart låda som ingen vågar röra, vilket i sig blir en ny typ av risk. Lägg gärna till en enkel CHANGELOG.md där varje ny automatiserad åtgärd loggas med datum och vem som godkände den, så att ni kan spåra tillbaka exakt vad som ändrats om något går fel.

Vanliga misstag när ni inför Prowler

Köra med administratörsrättigheter. Fresta inte att ge Prowler mer än SecurityAudit plus de extra läsrättigheterna från steg 2. Ett läckt access-token med adminrättigheter är värre än problemet ni försökte lösa i första läget.
Tysta fynd utan att dokumentera varför. Prowler låter er markera kontroller som muted för specifika resurser. Gör det utan en kommentar om varför, och om sex månader vet ingen längre om undantaget fortfarande är giltigt eller bara glömdes bort.
Skanna en gång och sedan aldrig igen. Ett konto som var rent i januari kan vara fullt av nya S3-hinkar i augusti. Schemalägg körningar, minst varje natt, helst kopplat till samma pipeline som er övriga drift.
Fixa i fyndordning istället för efter risk. 200 low-severity-fynd väger inte upp ett enda critical-fynd på en internetexponerad databas med kunddata, oavsett hur bra det känns att beta av en lång lista.
Glömma loggningslagret. En ren Prowler-rapport säger inget om vad som redan hänt. Koppla alltid ihop granskningen med CloudTrail och GuardDuty för att se om en felkonfiguration redan utnyttjats innan ni stänger den.
Testa remediering direkt i produktion. Kör åtgärdsskripten i en sandbox-miljö eller mot ett enda testkonto först, särskilt regler som ändrar säkerhetsgrupper eller IAM-policyer brett över flera team samtidigt.
Lita blint på standardkontrollerna utan att lägga till egna. CIS och NIST täcker det som är gemensamt för alla organisationer, men er egen arkitektur har sannolikt interna regler, till exempel krav på specifika taggar för kostnadsuppföljning, som ingen extern standard känner till. Bygg egna kontroller för dem istället för att anta att standardpaketet räcker.

Felsökning: 8 vanliga problem och lösningar

De flesta problem med Prowler handlar antingen om behörigheter, om att köra fel version, eller om att missförstå vad ett fynd faktiskt betyder. Tabellen nedan täcker de vanligaste supportärendena team stöter på under sina första veckor.

Problem	Trolig orsak	Lösning
“AccessDenied” under skanning	IAM-rollen saknar SecurityAudit-policyn	Bifoga `arn:aws:iam::aws:policy/SecurityAudit` och kör om
Skanningen hänger eller timeout	För många regioner skannas parallellt mot ett stort konto	Begränsa med `--region eu-north-1 eu-west-1`
Falska positiva för S3-åtkomst	Förväxling mellan bucket-policy och legacy-ACL	Kontrollera Block Public Access-inställningen separat från policyn
Prowler hittar inga resultat alls	Fel AWS-profil eller region konfigurerad lokalt	Kör `aws configure list` och verifiera aktivt konto-ID
Throttling-fel från AWS API:er	För hög samtidighet mot kontots API-gränser	Sänk parallellitet eller kör mot färre tjänster åt gången
Rapporten matchar inte CIS-baslinjen	Föråldrad Prowler-version med gamla regelmappningar	Uppgradera till minst 5.33.0 via `pip install --upgrade prowler`
GitHub Actions-jobbet misslyckas tyst	Saknade eller felaktiga repo-secrets för AWS-rollen	Verifiera `role-to-assume` och att OIDC-trust är korrekt satt
Checkov och Prowler ger motstridiga svar	Olika regeluppsättningar granskar samma resurs	Bestäm ett auktoritativt verktyg per regeltyp och dokumentera valet

Stöter ni på ett problem som inte täcks ovan, börja alltid med att köra skanningen i debug-läge (prowler aws --log-level DEBUG) innan ni felsöker vidare. De flesta konstiga fel visar sig vara ett tydligt AWS API-felmeddelande som bara syns när loggningen är mer detaljerad än standardläget.

Ett återkommande mönster värt att nämna särskilt är team som byter AWS-profil lokalt utan att uppdatera sina skript, vilket gör att en skanning ser ut att lyckas men i själva verket kör mot fel konto. Lägg alltid till en verifieringsrad i era skript som skriver ut vilket konto-ID som faktiskt skannas innan resultaten sparas, så att ett sådant misstag upptäcks direkt istället för att upptäckas veckor senare när någon undrar varför ett känt fynd aldrig dyker upp i rapporten.

Avancerade tips för mogna säkerhetsteam

När grunderna sitter går det att skruva vidare. Bygg egna kontroller i Prowler för interna policyer som inte täcks av CIS eller NIST, till exempel krav på specifika taggningsscheman för kostnadsspårning eller ägarskap. Om organisationen växer förbi en handfull AWS-konton är det värt att titta på Prowler SaaS och funktionen Autonomous Fixer, som föreslår färdig remediering direkt kopplad till varje fynd istället för att teamet skriver egna skript för varje kontrolltyp.

Koppla resultaten till Slack eller Jira så att critical-fynd automatiskt skapar ett ärende med ägare och deadline, istället för att bara ligga kvar i en rapport ingen läser efter första veckan. Sätt även upp en enkel riskbaserad taggning, till exempel internet-facing och contains-pii, på era resurser i Terraform. Då kan ni filtrera Prowler-rapporter efter vilka fynd som faktiskt rör exponerade tillgångar med känslig data, istället för att gräva manuellt varje gång ni ska prioritera veckans arbete.

Ett annat effektivt grepp är att sätta upp ett separat, betydligt strängare regelset för produktionskonton jämfört med utvecklings- och testmiljöer. En öppen säkerhetsgrupp i en kortlivad testmiljö som rivs varje kväll är en helt annan risknivå än samma fynd i produktion, men standardinställningarna i de flesta skanningsverktyg gör ingen sådan skillnad automatiskt. Definiera separata Prowler-profiler per miljötyp, så slipper teamet drunkna i lågrisk-varningar från miljöer som ändå försvinner om några timmar.

För team med flera hundra konton blir det snabbt opraktiskt att läsa varje enskild rapport för hand. Exportera istället resultaten till en central datasjö eller ett dataset i till exempel Athena, och bygg en enkel dashboard som visar trend över tid per konto och team. Det gör det möjligt att se om ett teams molnhygien faktiskt förbättras månad för månad, snarare än att bara veta hur många fel som finns just i dag.

Verktygsjämförelse: Prowler, ScoutSuite, Trivy och Checkov

Ingen av verktygen ersätter de andra helt. De täcker olika delar av samma problem, och de flesta mogna säkerhetsteam kör minst tre av dem parallellt i olika delar av sin pipeline.

Ett vanligt startupplägg för ett team på fem till tio utvecklare är att köra Checkov och Trivy som en obligatorisk kontroll i varje pull request, medan Prowler körs som ett nattligt schemalagt jobb mot hela kontot. ScoutSuite lämpar sig bäst som ett komplement för den som vill dubbelkolla ett specifikt fynd från Prowler, snarare än som huvudverktyg, eftersom uppdateringstakten historiskt varit lägre än för Prowler.

Verktyg	Omfång	Styrka	Bäst för
Prowler	AWS, Azure, GCP, Kubernetes (körande konton)	Bredast komplians-täckning, CIS/NIST-mappning	Löpande granskning av driftsatta resurser
ScoutSuite	AWS, Azure, GCP, Alibaba Cloud	Snabb visuell översikt, enkel att starta med	En andra åsikt om nätverk och identitet
Trivy	Containrar, IaC, filsystem, SBOM	Snabb, integreras direkt i CI/CD	Skanna kod och images innan driftsättning
Checkov	Terraform, CloudFormation, Kubernetes-manifest	Policy-som-kod med tusentals färdiga regler	Blockera dåliga IaC-ändringar i pull requests

Så påverkar NIS2 och nordiska myndighetskrav ert schema

För bolag som omfattas av NIS2 är proaktiv skanning inte bara god praxis, det påverkar direkt hur snabbt ni kan hinna med de tidsfrister direktivet kräver vid en faktisk incident. En organisation som redan vet exakt vilka S3-hinkar och roller som är exponerade hinner betydligt lättare bedöma omfattningen av en incident inom de första kritiska timmarna, jämfört med ett team som måste kartlägga hela miljön från noll mitt under en pågående händelse.

Kör ni redan en dokumenterad incidentplan är det naturligt att lägga in schemalagd Prowler-skanning som en del av det förebyggande arbetet snarare än att bara luta sig mot planen när något redan gått fel. Många svenska myndigheter och tillsynsorgan efterfrågar dessutom dokumentation av regelbundna säkerhetsgranskningar vid revision, och en historik av dagliga Prowler-rapporter är betydligt enklare att visa upp än att förklara att granskningen sker “vid behov”.

Ett konkret sätt att koppla ihop de två arbetsflödena är att spara varje Prowler-rapport tillsammans med datumstämpel i samma system där ni redan dokumenterar incidenthantering. Vid en eventuell tillsyn eller revision kan ni då visa en obruten historik över tid, snarare än en enskild ögonblicksbild från dagen innan granskarna kom på besök. Det är också en bra utgångspunkt för att räkna ut mean-time-to-remediation för olika typer av fynd, ett mått som blir allt vanligare att redovisa internt i takt med att styrelser och ledningsgrupper ställer fler konkreta säkerhetsfrågor.

Sätter ni upp allt enligt de tolv stegen ovan har ni gått från att inte veta vad som är exponerat till att ha en dokumenterad, återkommande process som hittar nya problem innan de blir till incidenter. Det är den enskilt största skillnaden mellan bolag som drabbas hårt av en molnincident och de som upptäcker och stänger problemet samma dag det uppstår.

Vanliga frågor

Är Prowler gratis att använda?
Ja, kärnverktyget är open source under Apache 2.0-licens och kostar inget att köra själv, oavsett hur många konton eller regioner ni skannar. Det finns en betald SaaS-variant för team som vill slippa hantera infrastrukturen för skanningarna och rapporteringen själva.

Fungerar Prowler med Azure och GCP, inte bara AWS?
Ja. Den här guiden fokuserar på AWS eftersom det är den vanligaste startpunkten för de flesta nordiska bolag, men samma kommandostruktur (prowler azure, prowler gcp) fungerar mot övriga leverantörer med motsvarande autentisering och liknande IAM-liknande roller.

Hur ofta bör vi köra en fullständig skanning?
Minst en gång per dygn för produktionskonton, och alltid vid varje pull request som ändrar infrastruktur via Terraform eller CloudFormation. Konton med hög förändringstakt, till exempel utvecklingsmiljöer där resurser skapas och tas bort dagligen, kan med fördel skannas oftare än så.

Kan Prowler fixa problem automatiskt?
Grundverktyget rapporterar, det ändrar inget på egen hand. Funktionen Autonomous Fixer (lanserad 2026) föreslår guidad remediering, men att köra faktiska ändringar kräver egna skript eller manuellt godkännande, ungefär som i saneringsprojektet högre upp i den här guiden.

Behöver vi en AWS Support-plan för att använda Prowler?
Nej. Prowler pratar med samma publika AWS-API:er som AWS CLI, oavsett vilken supportnivå kontot har, och kräver ingen särskild licens från AWS för att fungera.

Hur skiljer sig detta från att bara använda AWS Security Hub?
Security Hub aggregerar fynd från AWS egna tjänster och tredjepartsverktyg, inklusive Prowler. De kompletterar varandra snarare än konkurrerar: Prowler gör den djupa granskningen med ett bredare regelbibliotek, Security Hub blir den samlade vyn över tid och över flera verktyg.

Är resultaten relevanta för GDPR-efterlevnad?
Indirekt, ja. Öppna databaser och lagringshinkar med personuppgifter är precis den typen av brist som utlöser anmälningsplikt vid en incident. Att stänga dem proaktivt minskar den risken avsevärt och gör det enklare att visa att ni vidtagit rimliga tekniska skyddsåtgärder.

Vad kostar det att växa från open source till Prowler SaaS?
Prissättningen varierar efter antal konton och är inte offentligt listad som ett fast belopp, så kontrollera aktuellt pris direkt hos leverantören innan ni budgeterar för en övergång från den kostnadsfria versionen.

Vilka AWS-tjänster täcker Prowler bäst?
Djupast täckning finns för IAM, S3, EC2, RDS, CloudTrail och GuardDuty, eftersom det är de tjänster flest kontroller historiskt byggts kring. Nyare tjänster får ofta stöd inom några månader efter att de blivit allmänt tillgängliga, men det är alltid värt att kontrollera changelogen om ni förlitar er på en mindre vanlig AWS-tjänst.

Kan vi använda Prowler i en flerkontostruktur med AWS Organizations?
Ja, och det är faktiskt det vanligaste sättet större team kör verktyget. Sätt upp den skrivskyddade rollen från steg 2 i varje medlemskonto, och antingen loopa igenom kontona i ert CI-jobb eller använd Prowlers inbyggda stöd för att skanna flera konton i samma körning via en lista av roll-ARN:er.