Steampipe: Stoppa AWS-Felkonfiguration i 12 Steg [2026]

Publika S3-buckets, IAM-policyer med jokertecken och säkerhetsgrupper öppna mot hela internet är fortfarande den vanligaste vägen in i molnmiljöer 2026. Enligt Orca Securitys State of Cloud Security-rapport har 17 procent av organisationerna minst en IaC-artefakt som konfigurerar en S3-bucket för publik läsåtkomst, och andelen IAM-roller som inte använts på 90 dagar eller mer har ökat med 6 procentenheter år över år. Den här guiden visar hur du bygger ett eget skanningsflöde med Steampipe och Checkov som hittar dessa hål innan en angripare gör det, och håller dem borta med automatiserad skanning i CI/CD.

Du behöver inga dyra licenser. Båda verktygen är öppen källkod, och du kan ha ett fungerande skanningsflöde igång på under 90 minuter. Guiden går igenom installation, tolv konkreta steg för att hitta felkonfigurationer i S3, IAM och säkerhetsgrupper, hur du kompletterar med statisk analys av Terraform-kod, och hur du automatiserar hela kedjan i GitHub Actions.

Guiden är skriven för utvecklare, plattformsteam och säkerhetsansvariga som redan har ett AWS-konto i drift och vill veta vad som faktiskt är felkonfigurerat i det, inte bara i teorin. Du behöver inga tidigare kunskaper i SQL utöver att kunna läsa ett enkelt select-uttryck, och samtliga kommandon i guiden går att köra på en vanlig bärbar dator utan särskild serverkapacitet.

Varför molnfelkonfigurationer är 2026 års vanligaste väg in

Gartner har länge räknat med att nästan alla misslyckanden i molnsäkerhet fram till 2026 orsakas av kunden själv, inte av molnleverantören, vilket i praktiken betyder felkonfigurerad lagring, för breda IAM-rättigheter och exponerade nätverksregler. Det mönstret bekräftas av nyare data. En analys från augusti 2026, refererad av Help Net Security, visar att svaga IAM-kontroller och saknad loggning påverkar mellan 80 och 98 procent av molnkonton oavsett leverantör, och att 76 procent av AWS-konton i undersökningen hade minst en publikt exponerad tjänst, jämfört med 64 procent för Azure och 8 procent för Google Cloud.

Kostnaden för att missa detta är hög. Flera 2026-rapporter, bland annat en sammanställning från Help Net Security i augusti 2026, uppger att en genomsnittlig molnfelkonfiguration som leder till intrång kostar omkring 4,3 miljoner dollar att städa upp efter, och att den genomsnittliga tiden innan en felkonfiguration upptäcks fortfarande ligger på över 180 dagar. Det är exakt det gapet Steampipe och Checkov är byggda för att stänga: kontinuerlig, billig, skriptbar kontroll i stället för en manuell genomgång en gång per kvartal.

För svenska och nordiska organisationer finns en extra dimension. Orca Securitys data visar att över hälften av alla granskade lagringskonton innehåller känslig eller personligt identifierbar information, vilket gör varje publik S3-bucket eller motsvarande Azure Blob till en potentiell GDPR-incident, inte bara ett tekniskt problem. Det är ett av skälen till att fler nordiska säkerhetsteam nu bygger in molnkonfigurationskontroller som en del av sitt löpande NIS2-arbete snarare än som ett årligt revisionsmoment.

Utöver kostnaden ökar också trycket från angripare som medvetet riktar in sig på molnmiljöer. Så kallade cloud-conscious intrusions, alltså attacker riktade specifikt mot molnkonfiguration och molntjänster, ökade med 37 procent år över år under 2025, efter en ökning på 26 procent året innan. Automatiserade skannrar letar kontinuerligt efter exakt de mönster den här guiden lär dig hitta själv: öppna portar, publika buckets och IAM-policyer med jokertecken. Skillnaden mellan ett intrång och ett stängt fynd handlar till slut om vem som hittar hålet först, ditt team eller en skanner som körs dygnet runt från ett helt annat land.

Statistik	Värde	Källa
Andel cloud-incidenter orsakade av felkonfiguration (2025)	23 %	CybelAngel, 2026
Konton med svag IAM eller saknad loggning	80–98 %	Help Net Security, aug 2026
AWS-konton med minst en publikt exponerad tjänst	76 %	Help Net Security, aug 2026
Organisationer med IaC som ger publik S3-läsåtkomst	17 %	Orca Security, 2025
Genomsnittlig kostnad för en felkonfigurationsincident	4,3 miljoner USD	Branschrapporter, 2026
Genomsnittlig upptäcktstid för felkonfiguration	180+ dagar	Branschrapporter, 2026

GDPR, NIS2 och varför felkonfiguration inte bara är ett IT-problem

En publik S3-bucket som innehåller personuppgifter är juridiskt sett ingen driftstörning, det är en potentiell personuppgiftsincident som kan kräva anmälan till Integritetsskyddsmyndigheten inom 72 timmar enligt GDPR, oavsett om någon faktiskt hann läsa datan eller ej. Det gör molnkonfigurationsarbete till något som säkerhetschefer, jurister och infrastrukturteam behöver dela ägarskap över, i stället för att lämna helt till den enskilda utvecklare som råkade skapa bucketen.

NIS2, som redan gäller för tusentals svenska organisationer inom väsentliga och viktiga sektorer, ställer dessutom krav på att ha processer för att identifiera och hantera risker i leverantörskedjan, vilket i praktiken omfattar den egna molninfrastrukturen. Att kunna visa en revisor eller tillsynsmyndighet att organisationen har en löpande, dokumenterad process för att upptäcka och åtgärda molnfelkonfigurationer, i stället för en manuell genomgång en gång om året, är precis det den här guiden bygger. Ett skanningsflöde med tydlig historik i GitHub Actions-loggar fungerar dessutom som konkret bevis vid en revision, utan att någon behövt skapa ett separat rapportsystem för det syftet.

Det ekonomiska argumentet är minst lika starkt som det juridiska. Att sätta upp Steampipe och Checkov enligt den här guiden kostar inget i licensavgifter och tar en eftermiddag. Att städa upp efter ett läckt kundregister, betala eventuella sanktionsavgifter och hantera det förtroendetapp som följer kostar, som tidigare nämnts, i snitt miljontals kronor och veckor av arbete. Den kalkylen brukar vara lätt att förklara för en budgetägare som annars ser säkerhetsarbete som en ren kostnad utan synlig avkastning.

Steampipe och Checkov: så kompletterar de varandra

Steampipe, dokumenterat i detalj i Steampipes officiella dokumentation och utvecklat av Turbot, är motorn som visar dig vad som faktiskt är sant i din miljö just nu. Den fungerar som en Postgres-databas där varje molnresurs (S3-bucket, IAM-roll, säkerhetsgrupp, EC2-instans) exponeras som en vanlig SQL-tabell. Du skriver en fråga, får ett resultat, och kan koppla ihop den med vilket BI-verktyg eller dashboard-system som helst eftersom det bara är SQL. Det gör Steampipe till ett detekteringsverktyg: det berättar vad som redan är fel i produktion.

Checkov, som ägs av Palo Alto Networks via Bridgecrew/Prisma Cloud, gör motsatt jobb. Det är ett statiskt analysverktyg som läser din Terraform-, CloudFormation- eller Kubernetes-kod innan den deployas, och stoppar en felkonfiguration innan den ens skapas. Checkov levereras med över tusen inbyggda policyer och kan köras lokalt, i en pre-commit-hook eller i en CI/CD-pipeline. Läs mer i Checkovs officiella quickstart-dokumentation.

Tillsammans bildar de en detektera-och-förhindra-loop. Checkov stoppar nya fel i kodgranskningen. Steampipe hittar det som redan smugit sig igenom, gammal infrastruktur som skapades innan reglerna fanns, manuella ändringar gjorda direkt i AWS-konsolen, eller resurser som kommer från ett annat team som inte kör samma pipeline. Ingen av dem ersätter den andra. En organisation som bara kör Checkov missar allt som redan finns i produktion. En organisation som bara kör Steampipe upptäcker problem för sent, efter att de redan är live.

Steampipe jämfört med Prowler och ScoutSuite

Om du redan känner till Prowler eller ScoutSuite kanske du undrar var Steampipe passar in. Prowler och ScoutSuite är färdiga skanningsverktyg: du kör ett kommando, och de levererar en rapport mot ett fast regelverk, till exempel CIS-benchmarken. Steampipe är i stället ett frågespråk snarare än en färdig rapport. Det levereras med rådata i tabellform som du själv formulerar frågor mot, vilket ger mer flexibilitet men kräver att du vet vad du letar efter. Fördelen märks tydligast när ett behov är specifikt för din egen organisation, till exempel “vilka S3-buckets saknar taggen dataklass men har ordet kund i namnet”, en fråga en färdig benchmarkrapport aldrig kan svara på. I praktiken kombinerar många säkerhetsteam alla tre verktygen: en färdig scanner för en snabb baslinje mot kända ramverk, Steampipe för skräddarsydda frågor, och Checkov för att stoppa nya fel innan de når produktion.

Förutsättningar: det här behöver du innan du börjar

Du behöver ett AWS-konto med behörighet att skapa en dedikerad IAM-användare eller -roll för skanning, samt en dator som kör Linux, macOS eller Windows med WSL. Använd aldrig dina administratörsuppgifter för skanningskontot. Skapa i stället en separat roll med enbart läsrättigheter enligt principen om minsta möjliga behörighet, vilket beskrivs i AWS egna riktlinjer för IAM-säkerhet.

Om du planerar att köra skanningen i en CI/CD-miljö som GitHub Actions i stället för på din egen dator, behöver du dessutom lagra AWS-uppgifterna som krypterade hemligheter i repot, och helst byta ut långlivade åtkomstnycklar mot en federerad roll via OIDC. Det ligger utanför den här guidens grundflöde men är värt att planera för direkt, eftersom det är betydligt enklare att sätta upp rätt från början än att migrera bort från nyckelbaserad autentisering senare.

Verktyg	Version	Syfte i den här guiden
Steampipe CLI	v2.4.6	Kör SQL-frågor mot din faktiska AWS-miljö
Steampipe AWS-plugin	1.32.0	Ger SQL-tabeller för S3, IAM, EC2, VPC med mera
Checkov	3.2.451 (senaste på PyPI)	Statisk analys av Terraform/CloudFormation
Python	3.9–3.13	Krävs för att installera och köra Checkov
AWS CLI	v2 (senaste versionen)	Autentisering och profilhantering mot AWS
Terraform	senaste versionen	Om du vill skanna egen IaC-kod med Checkov

Om du inte redan har IaC-kod att skanna räcker det att följa S3-, IAM- och säkerhetsgrupps-stegen med Steampipe. Checkov-delen är fristående och kräver bara en katalog med Terraform-filer, vilket gör att du kan testa den mot en enda liten fil innan du kopplar in hela infrastrukturen.

Räkna med att hela guiden tar omkring 90 minuter första gången, betydligt snabbare vid varje efterföljande körning eftersom kommandona då redan är kända.

Del av guiden	Tidsåtgång	Vad du får ut
Steg 1–2: Installation och kontoanslutning	~15 min	Fungerande Steampipe kopplat till ett läsbehörigt AWS-konto
Steg 3–4: Plugin och första frågan	~10 min	Bekräftad anslutning mot rätt AWS-konto
Steg 5: S3-skanning	~10 min	Lista över publika eller okrypterade buckets
Steg 6–7: IAM-skanning	~15 min	Överprivilegierade policyer och oanvända roller
Steg 8: Säkerhetsgrupper	~10 min	Öppna portar mot internet identifierade
Steg 9–10: Checkov mot IaC	~15 min	Fynd i Terraform-koden innan deploy
Steg 11–12: Dashboard och automation	~15 min	Kontinuerlig skanning i GitHub Actions

Steg 1–2: Installera Steampipe och anslut till ditt AWS-konto

Steg 1: Installera Steampipe. På Linux och macOS installeras Steampipe med ett enda installationsskript. På Windows kör du samma kommando inuti WSL2, eftersom Steampipe inte har någon nativ Windows-binär.

# Linux/macOS (och WSL2 på Windows)
sudo /bin/sh -c "$(curl -fsSL https://steampipe.io/install/steampipe.sh)"

# Verifiera installationen
steampipe -v
# Förväntad utdata: steampipe version 2.4.6

Steg 2: Skapa ett läsbehörigt AWS-konto för skanningen. Skapa en IAM-policy som enbart tillåter läsning av S3-metadata, IAM-konfiguration och nätverksregler. Undvik att koppla den till ett konto med skrivrättigheter, även tillfälligt.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetBucket*",
        "s3:ListAllMyBuckets",
        "iam:Get*",
        "iam:List*",
        "iam:GenerateCredentialReport",
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeInstances",
        "ec2:DescribeVpcs"
      ],
      "Resource": "*"
    }
  ]
}

Konfigurera sedan en dedikerad AWS CLI-profil för skanningskontot, så att du aldrig av misstag skannar med fel identitet: aws configure --profile steampipe-scan. Steampipe läser samma profiler som AWS CLI, vilket gör det enkelt att växla mellan konton senare.

Namnge profilen tydligt och undvik att återanvända namnet default, eftersom det annars är lätt att av misstag köra ett annat kommando mot skanningskontot senare. Om du hanterar flera AWS-konton (till exempel ett per miljö: dev, test och produktion) skapar du en profil per konto redan nu, så att grunden för aggregerad skanning över flera konton, som beskrivs längre ner i guiden under avancerade tips, redan finns på plats.

Steg 3–4: Installera AWS-pluginet och kör din första fråga

Steg 3: Installera AWS-pluginet. Steampipes pluginarkitektur betyder att kärnan förblir liten, och du installerar bara stöd för de moln du faktiskt använder.

steampipe plugin install aws
steampipe plugin list
# Bekräfta att "aws" står med i listan innan du fortsätter

Steg 4: Kör din första fråga. Starta ett interaktivt skal med steampipe query och testa att anslutningen fungerar innan du går vidare till de mer avancerade frågorna.

steampipe query "select account_id, account_alias from aws_account;"

Ett lyckat svar ser ut ungefär så här:

+----------------+-------------------------+
| account_id     | account_alias           |
+----------------+-------------------------+
| 123456789012   | mitt-foretag-produktion |
+----------------+-------------------------+

Får du i stället ett autentiseringsfel, dubbelkolla att miljövariabeln AWS_PROFILE=steampipe-scan är satt i samma terminal, eller att du pekar Steampipe mot rätt profil via connection-konfigurationen i ~/.steampipe/config/aws.spc.

Steampipe-tabell	Vad den visar	Typisk fråga
aws_s3_bucket	Alla S3-buckets och deras policyer	Är den publik? Är den krypterad?
aws_iam_policy	Alla hanterade och inbäddade IAM-policyer	Tillåter den * på *?
aws_iam_role	IAM-roller och när de senast användes	Är rollen oanvänd sedan 90+ dagar?
aws_vpc_security_group	Säkerhetsgrupper och deras regler	Är port 22 eller 3389 öppen mot 0.0.0.0/0?
aws_iam_access_key	Åtkomstnycklar och deras ålder	Finns nycklar äldre än 90 dagar?

Steg 5: Hitta publika S3-buckets och saknad kryptering

S3 är fortfarande den enskilt vanligaste källan till molnläckor. En S3-analys från 2026 av 2,1 miljoner publikt nåbara buckets fann att 87 procent hade någon form av felkonfiguration, och 73 procent hade IAM-policyer som gav åtkomst till fler principaler än vad som faktiskt behövdes. Följande fråga listar varje bucket som antingen har en policy som gör den publik, eller som saknar spärren mot publika ACL:er.

select
  name,
  region,
  bucket_policy_is_public,
  block_public_acls,
  server_side_encryption_configuration is not null as har_kryptering
from
  aws_s3_bucket
where
  bucket_policy_is_public = true
  or block_public_acls = false
order by
  bucket_policy_is_public desc;

Ett typiskt fynd i en oskannad miljö ser ut så här, där har_kryptering är false är minst lika allvarligt som att bucketen är publik, eftersom data i klartext då blir läsbar för vem som helst som får ett läckt objekt-URL:

+------------------------+------------+--------------------------+--------------------+----------------+
| name                   | region     | bucket_policy_is_public  | block_public_acls  | har_kryptering |
+------------------------+------------+--------------------------+--------------------+----------------+
| kundexport-2024-arkiv  | eu-north-1 | true                     | false               | false          |
| statisk-webbplats-cdn  | eu-west-1  | true                     | true                | true           |
+------------------------+------------+--------------------------+--------------------+----------------+

Innan du låser ner en bucket, kontrollera vad den faktiskt används till. En bucket som hostar en statisk webbplats eller är ursprung för CloudFront ska vara publik av design, medan en bucket med kundexport aldrig ska vara det. Läs mer om hur spärren fungerar i AWS dokumentation om Block Public Access innan du ändrar inställningar i produktion.

Det vanligaste undantaget att hantera manuellt är buckets som ligger bakom en CloudFront-distribution. Rätt lösning där är oftast inte att göra bucketen publik, utan att använda en Origin Access Control så att endast CloudFront kan läsa objekten direkt, medan alla andra besökare måste gå via CDN-lagret. Steampipe-frågan ovan fångar även dessa buckets eftersom den bara tittar på policy och ACL, så en manuell genomgång av träfflistan innan du ändrar något är alltid klokt, särskilt för äldre buckets skapade innan Origin Access Control blev standard.

Steg 6–7: Upptäck överprivilegierade IAM-policyer och oanvända roller

Steg 6: Hitta policyer med jokerrättigheter. IAM-policyer som tillåter "Action": "*" mot "Resource": "*" är i praktiken administratörsrättigheter, oavsett vad policyn heter. De uppstår oftast av bekvämlighet under ett utvecklingsprojekt och glöms sedan bort.

select
  name,
  arn,
  is_aws_managed
from
  aws_iam_policy,
  jsonb_array_elements(policy_std -> 'Statement') as stmt
where
  stmt ->> 'Effect' = 'Allow'
  and stmt -> 'Action' ? '*'
  and stmt -> 'Resource' ? '*'
  and is_aws_managed = false;

Steg 7: Hitta roller som inte använts på 90 dagar eller mer. En oanvänd roll med kvarvarande behörigheter är en tyst risk, särskilt om den en gång kopplades till ett tredjepartsverktyg som sedan togs bort. Kolumnen role_last_used_date ger dig svaret direkt.

select
  name,
  create_date,
  role_last_used_date,
  (current_date - role_last_used_date::date) as dagar_sedan_anvand
from
  aws_iam_role
where
  role_last_used_date is null
  or role_last_used_date < (current_date - interval '90 days');

Roller där role_last_used_date är null och rollen samtidigt skapades för mer än ett år sedan är de säkraste att ta bort helt. Roller som nyligen skapats men ännu inte använts bör du vänta med, de kan höra till ett projekt som ännu inte lanserats.

Steg 8: Skanna säkerhetsgrupper efter öppna portar mot internet

Säkerhetsgrupper som tillåter inkommande trafik från 0.0.0.0/0 på administrativa portar som SSH (22), RDP (3389) eller databasportar (3306, 5432) är fortfarande en av de mest utnyttjade felkonfigurationerna, eftersom automatiserade skannrar kontinuerligt letar efter exakt detta mönster över hela internet.

select
  sg.group_id,
  sg.group_name,
  ip_permission ->> 'FromPort' as port,
  ip_range ->> 'CidrIp' as kalla
from
  aws_vpc_security_group as sg,
  jsonb_array_elements(sg.ip_permissions) as ip_permission,
  jsonb_array_elements(ip_permission -> 'IpRanges') as ip_range
where
  ip_range ->> 'CidrIp' = '0.0.0.0/0'
  and (ip_permission ->> 'FromPort')::int in (22, 3389, 3306, 5432);

Åtgärden är sällan att helt ta bort regeln, utan att byta ut 0.0.0.0/0 mot ditt kontors IP-intervall eller ett VPN-intervall, och för produktionsdatabaser flytta åtkomsten helt in i det privata nätverket via en bastion-host eller Session Manager i stället för direkt exponering.

Så prioriterar du fynden när listan blir lång

En förstagångsskanning ger ofta hundratals rader i utdata. Utan en tydlig prioritering fastnar teamet i diskussioner om vilket fynd som är viktigast i stället för att faktiskt åtgärda något. En enkel modell är att gradera varje fynd efter hur allvarlig konsekvensen blir om resursen utnyttjas, och hur exponerad resursen redan är mot internet.

• Kritisk, åtgärda samma dag: publik S3-bucket med kunddata, IAM-policy med jokerrättigheter, säkerhetsgrupp med databasport öppen mot 0.0.0.0/0.
• Hög, åtgärda inom veckan: oanvänd IAM-roll med adminbehörighet, S3-bucket utan kryptering men utan publik åtkomst, åtkomstnyckel äldre än 180 dagar.
• Medel, planera in i sprintarbetet: saknad access-loggning, saknade taggar för dataklassificering, MFA ej påtvingat för enskilda IAM-användare.
• Låg, dokumentera och följ upp kvartalsvis: avsaknad av livscykelregler för lagring, läsrättighetsbegränsade roller som ändå är oanvända.

Poängen är inte att bygga ett perfekt poängsystem redan första dagen, utan att undvika att alla 200 fynd hamnar i samma "att göra"-hög. Ett team som åtgärdar de fem kritiska fynden samma vecka har gjort mer nytta än ett team som lägger en månad på att bygga ett dashboard ingen tittar på. Sätt också en regel för omskanning: kritiska och höga fynd bör verifieras som åtgärdade inom ett dygn efter att en fix har deployats, i stället för att vänta på nästa schemalagda körning. Det är enkelt att lägga till en manuell utlösare i samma GitHub Actions-jobb som redan finns för den dagliga skanningen, genom workflow_dispatch, som redan ingår i exemplet längre ner i guiden.

Steg 9–10: Installera Checkov och skanna din Terraform-kod

Steg 9: Installera Checkov. Checkov är skrivet i Python och installeras enklast via pip. Verifiera versionen efteråt så att du vet att pip3 pekar mot rätt Python-installation.

pip3 install checkov
checkov --version
# Förväntad utdata: 3.2.451 (eller senare)

Steg 10: Kör Checkov mot din Terraform-kod. Peka verktyget mot katalogen där din IaC-kod ligger. Checkov läser filerna statiskt, den behöver inga AWS-uppgifter alls för detta steg eftersom den bara analyserar kod, inte en levande miljö.

checkov -d ./terraform --framework terraform --compact

Utdata visar ett sammanfattat resultat per kontroll, med en tydlig referens till exakt fil och radnummer där problemet finns:

Check: CKV_AWS_18: "Ensure the S3 bucket has access logging enabled"
	FAILED for resource: aws_s3_bucket.data_export
	File: /main.tf:14-22

Check: CKV_AWS_20: "Ensure the S3 bucket does not allow READ permissions to everyone"
	PASSED for resource: aws_s3_bucket.data_export

Passed checks: 42, Failed checks: 3, Skipped checks: 0

Om listan med fynd känns överväldigande första gången, sortera efter allvarlighetsgrad och åtgärda alla CKV_AWS-kontroller kopplade till publik åtkomst och kryptering först. Resten, som loggningskontroller och taggningskrav, kan vänta till nästa sprint utan att öka den akuta risken nämnvärt. Checkov kan även köras med flaggan --framework cloudformation eller --framework kubernetes om din organisation använder andra IaC-format parallellt med Terraform, utan att du behöver installera något extra verktyg.

Steg 11–12: Bygg ett dashboard och automatisera i GitHub Actions

Steg 11: Bygg ett kontinuerligt dashboard. Steampipe stödjer så kallade "mods", färdiga paket med frågor och dashboards. AWS Compliance-modet ger dig en visuell översikt utan att du behöver skriva en enda SQL-rad själv.

mkdir aws-dashboard && cd aws-dashboard
steampipe mod init
steampipe mod install github.com/turbot/steampipe-mod-aws-compliance
steampipe dashboard
# Öppnas normalt på http://localhost:9194

Steg 12: Automatisera skanningen. Manuell skanning fångar bara ögonblicksbilden just då du kör kommandot. Lägg in Checkov som ett schemalagt jobb i GitHub Actions så att varje ändring i infrastrukturkoden kontrolleras automatiskt, och att en daglig körning fångar drift som skett utanför pipelinen.

name: molnkonfigurationsskanning
on:
  pull_request:
    paths: ["terraform/**"]
  schedule:
    - cron: "0 6 * * *"
  workflow_dispatch:

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Installera Checkov
        run: pip3 install checkov
      - name: Kör Checkov mot Terraform-kod
        run: checkov -d ./terraform --framework terraform --compact --soft-fail-on LOW

Flaggan --soft-fail-on LOW gör att jobbet fortsätter för lågriskfynd men fäller pipelinen röd för allvarligare kontroller, vilket är en rimlig balans när ett team fortfarande arbetar igenom en backlogg av äldre fynd.

Vanliga fallgropar att undvika

De flesta problem som uppstår med den här typen av skanningsflöde handlar inte om själva verktygen, utan om hur de sätts upp och underhålls över tid. Nedan är de misstag som oftast gör att ett i övrigt korrekt konfigurerat skanningsflöde ändå missar risker eller stör den löpande driften.

• Skanna med administratörsuppgifter. Om skanningskontot själv har fulla rättigheter blir det ett nytt högvärdesmål. Håll det strikt läsbehörigt enligt steg 2.
• Låsa ner allt utan att kontrollera användning. Att blockera publik åtkomst på en bucket som faktiskt hostar en webbplats slår ut produktionen direkt. Kontrollera alltid syftet innan du ändrar.
• Köra skanningen en gång och kalla det klart. En engångsrapport blir inaktuell samma dag ny infrastruktur skapas. Utan schemaläggning enligt steg 12 är arbetet i praktiken bortkastat inom veckor.
• Skippa hela kataloger i Checkov-konfigurationen. Ett brett skip-path i .checkov.yaml gömmer nya fel lika mycket som gamla. Undanta enskilda kontroller med motivering, inte hela mappar.
• Glömma regioner. Vissa Steampipe-frågor mot EC2 och säkerhetsgrupper körs bara mot en region i taget om inte connection-konfigurationen listar alla regioner explicit, vilket gör att resurser i till exempel eu-north-1 kan missas helt.
• Blanda ihop upptäckt med åtgärd. Ett verktyg som hittar problem är inte samma sak som ett verktyg som löser dem. Bygg alltid in ett steg där någon faktiskt äger och stänger varje fynd.

Felsökning: vanliga problem och lösningar

De flesta felmeddelanden från Steampipe och Checkov handlar antingen om behörigheter, nätverk eller cachad data. Gå igenom listan nedan innan du misstänker en bugg i själva verktyget, eftersom de allra flesta fall löser sig med en av dessa nio punkter.

• "plugin not found" vid installation: Kontrollera internetanslutningen och att brandväggen tillåter utgående trafik till hub.steampipe.io, där plugin-paket laddas ner.
• Frågor svarar med tomt resultat trots kända resurser: Bekräfta att rätt AWS-profil och region är satta i ~/.steampipe/config/aws.spc, inte bara i din skalmiljö.
• AccessDenied på specifika tabeller: IAM-policyn från steg 2 saknar troligen en åtgärd. Lägg till den saknade rättigheten i policyn snarare än att bredda hela behörigheten.
• Query timeout mot stora konton: Begränsa frågan med en where region = '...'-klausul för att minska mängden data som hämtas i ett svep.
• Checkov hittar noll filer: Kontrollera att katalogsökvägen är relativ till där du kör kommandot, och att filerna faktiskt har ändelsen .tf.
• Dashboard startar inte på port 9194: Porten är troligen upptagen av en tidigare session. Stäng den gamla processen eller starta om med steampipe dashboard --dashboard-listen network --dashboard-port 9195.
• Föråldrad data i resultaten: Steampipe cachar resultat som standard. Kör steampipe query --cache=false för att tvinga fram en färsk hämtning mot AWS.
• Rate exceeded-fel vid stora skanningar: AWS API:er har egna anropsgränser. Sänk parallelliteten genom att sätta miljövariabeln STEAMPIPE_MAX_PARALLEL=2 innan du kör frågan igen.
• Checkov flaggar samma sak varje gång trots godkänt undantag: Lägg till en radkommentar #checkov:skip=CKV_AWS_XX:motivering direkt ovanför resursen i Terraform-filen i stället för att undanta globalt.

Avancerade tips för större molnmiljöer och flera konton

När en enda AWS-anslutning inte räcker längre kan Steampipe slå ihop flera konton till en aggregerad connection, så att en och samma fråga körs mot hela organisationen i ett svep i stället för konto för konto. Det är särskilt användbart för koncerner med separata AWS-konton per bolag eller miljö, ett vanligt upplägg bland svenska bolag som växt genom förvärv. Aggregeringen kräver bara att varje enskilt konto redan har en egen connection definierad i konfigurationen, sedan pekar du en samlad connection mot samtliga med ett enkelt wildcard-uttryck.

Kombinera gärna kontrollerna med AWS Organizations Service Control Policies (SCP), som stoppar vissa felkonfigurationer på organisationsnivå innan de ens kan skapas, oavsett vad en enskild kontoadministratör gör. Steampipe fungerar då som den oberoende verifieringen av att SCP-reglerna faktiskt håller, i stället för att bara lita på att de är korrekt konfigurerade.

För multimoln-miljöer följer Azure- och GCP-pluginen samma SQL-mönster som AWS-pluginet, vilket gör att en organisation som redan har byggt AWS-frågor kan återanvända samma logik med små justeringar för att täcka Azure Blob Storage eller Google Cloud Storage. Slutligen går det att koppla fynd till Slack eller Jira via Steampipes mod-system, så att ett kritiskt fynd genererar ett ärende automatiskt i stället för att bara synas i ett dashboard ingen tittar på.

Tänk också på anropskostnaden mot AWS API:erna när skanningen skalas upp. Ett konto med tiotusentals resurser kan ta betydligt längre tid att fråga igenom än ett litet testkonto, och för täta schemaläggningar (till exempel varje timme i stället för dagligen) bör du filtrera frågorna på specifika regioner eller resurstyper i stället för att alltid hämta allt. Det håller både körtiden och risken för att träffa AWS egna anropsgränser nere, samtidigt som du fortfarande får färsk data för de resurser som faktiskt förändras ofta.

Komplett exempelprojekt: säkerhetsbaslinje på en eftermiddag

Sätt ihop allt ovan till en enda mapp du kan checka in i versionshantering och återanvända på nästa projekt. Strukturen nedan samlar Steampipe-frågorna, Terraform-koden och CI/CD-jobbet på ett ställe.

molnsakerhet-baslinje/
├── .github/
│   └── workflows/
│       └── molnkonfigurationsskanning.yml
├── terraform/
│   └── main.tf
├── steampipe/
│   ├── aws.spc
│   └── queries/
│       ├── publika_buckets.sql
│       ├── iam_jokerrattigheter.sql
│       ├── oanvanda_roller.sql
│       └── oppna_sakerhetsgrupper.sql
├── .checkov.yaml
└── README.md

Lägg de fyra frågorna från steg 5 till 8 i respektive fil under steampipe/queries/, och kör dem samlat med ett litet skalskript som loopar igenom katalogen och sparar utdata till en logg varje natt. Kombinerat med GitHub Actions-jobbet från steg 12 har du då både den kontinuerliga detekteringen (Steampipe, kör manuellt eller schemalagt mot den levande miljön) och det förebyggande skyddet (Checkov, körs på varje pull request) i samma repo. Det är exakt den kombination Orca Securitys och Help Net Securitys rapporter pekar på som saknas i de flesta organisationer: inte avsaknad av verktyg, utan avsaknad av kontinuitet.

Checka in hela mappen i ett eget Git-repo, separat från applikationskoden, så att den kan återanvändas som mall för nästa AWS-konto eller nästa team. Det gör repot till ett bra onboarding-underlag också: en ny säkerhetsingenjör kan läsa igenom de fyra SQL-frågorna och GitHub Actions-jobbet på under en timme och förstå exakt vilka kontroller organisationen redan har på plats, i stället för att behöva fråga runt eller leta i ett gammalt Confluence-dokument som senast uppdaterades för ett år sedan.

Ett rimligt mål för första veckan är att gå från noll till en körande daglig Steampipe-skanning plus Checkov på varje pull request, och att ha en ägare utsedd för varje kategori av fynd (lagring, identitet, nätverk). Först då blir siffrorna i tabellen längre upp i artikeln något du aktivt sänker i din egen miljö, i stället för en beskrivning av läget hos andra.

Sammanfattning: från engångsgranskning till kontinuerlig kontroll

De tolv stegen i den här guiden löser samma grundproblem på två olika tidshorisonter. Steampipe svarar på frågan "vad är fel just nu" genom att fråga din levande AWS-miljö direkt i S3, IAM och säkerhetsgrupper. Checkov svarar på frågan "vad kommer att bli fel" genom att läsa Terraform-koden innan den ens deployas. Ingen enskild skanning, hur grundlig den än är, ersätter det faktum att molnmiljöer förändras varje dag. Nya utvecklare får nycklar, gamla integrationer glöms bort, och en enda snabb ändring i AWS-konsolen kan öppna en port som varit stängd i två år.

Det som skiljer en organisation som faktiskt sänker sin risk från en som bara samlar rapporter är automatiseringen i steg 11 och 12. En daglig schemalagd körning, en tydlig ägare per fyndkategori och en enkel prioriteringsmodell räcker långt, det krävs varken ett dyrt CSPM-abonnemang eller ett dedikerat säkerhetsteam på tio personer för att komma igång. Börja med de tre frågorna för S3, IAM och säkerhetsgrupper redan i dag, och lägg till Checkov i din pipeline innan nästa Terraform-ändring går till produktion.

Vanliga frågor

Är Steampipe gratis att använda?
Ja, Steampipe CLI och kärnpluginen, inklusive AWS-pluginet, är öppen källkod och kostnadsfria att installera och köra lokalt eller i egen CI/CD.

Behöver jag Terraform för att använda Checkov?
Nej. Checkov stödjer även CloudFormation, Kubernetes-manifest, Dockerfiles och flera andra format. Terraform är bara det vanligaste exemplet, inte ett krav.

Kan Steampipe skada min produktionsmiljö?
Nej, Steampipe utför bara skrivskyddade läsanrop mot molnets API:er. Så länge IAM-policyn du kopplar till skanningskontot enbart innehåller läsrättigheter, som i steg 2, kan verktyget inte ändra något i din miljö.

Hur ofta bör jag köra skanningen?
Checkov bör köras på varje pull request som rör infrastrukturkod. Steampipe-frågorna mot den levande miljön bör schemaläggas minst dagligen, eftersom manuella ändringar utanför IaC-pipelinen annars kan stå oupptäckta i veckor.

Fungerar samma metod för Azure och Google Cloud?
Ja. Steampipe har separata plugin för Azure och GCP med motsvarande tabeller, och Checkov stödjer IaC-format för samtliga tre stora molnleverantörer, så samma frågemönster går att återanvända med mindre justeringar.

Vad gör jag om jag hittar hundratals fynd på en gång?
Sortera efter allvarlighetsgrad och börja med publik åtkomst till data och jokerrättigheter i IAM, eftersom de utgör den akuta risken. Loggning, taggning och mindre kritiska policyfynd kan planeras in som löpande förbättringsarbete.

Kräver det här arbetet en NIS2-anmälan om jag hittar en publik bucket med kunddata?
Att hitta och åtgärda en felkonfiguration innan den utnyttjats är i sig inte en anmälningspliktig incident. Om loggar visar att data faktiskt lästs av en obehörig part förändras bedömningen, och då bör ni följa er interna incidentprocess enligt NIS2.

Är Steampipe och Checkov ett fullgott alternativ till en kommersiell CSPM-plattform?
För små och medelstora miljöer täcker kombinationen en stor del av samma behov till en bråkdel av kostnaden. Större organisationer med flera hundra konton väljer ofta att komplettera med en kommersiell plattform för sammanställd rapportering och regelefterlevnad över hela portföljen, men grundskanningen som beskrivs i den här guiden fungerar utmärkt som förstalinjeförsvar oavsett organisationens storlek.