En organisation som kör tre moln samtidigt har sällan tre lika bra säkerhetsteam. Oftast har den ett team som hinner granska ett moln ordentligt, och två andra som får kontroll när tiden räcker till. Det är precis det gapet som gör multi-cloud-miljöer så sårbara för felkonfigurationer just nu, och det är också anledningen till att ett gratis, öppet verktyg som ScoutSuite har blivit ett standardval för säkerhetsteam i Norden hösten 2026.

Den här guiden visar hur du installerar ScoutSuite, kopplar den mot AWS, Azure och Google Cloud, läser rapporterna den genererar och bygger in granskningen i ett automatiserat arbetsflöde. Du får kompletta kommandon, en färdig GitHub Actions-pipeline, en lista på vanliga fallgropar och åtta felsökningsscenarier du sannolikt stöter på förr eller senare. Målet är att du efter 90 minuter har en fungerande, upprepningsbar granskning av alla dina molnkonton, inte bara en engångskörning.

Guiden är skriven för dig som redan har grundläggande erfarenhet av kommandoraden och minst ett av de tre stora molnen, men den kräver inga tidigare kunskaper om just ScoutSuite. Räkna med runt 90 minuter för hela genomgången om du följer stegen i ordning och testar mot ett eget konto, kortare om du bara vill läsa igenom och längre om du väljer att också sätta upp den fullständiga automatiseringen mot flera konton samtidigt.

Varför molnfelkonfigurationer är 2026 års största säkerhetsproblem

Siffrorna från 2026 är entydiga. Enligt en analys baserad på Verizons Data Breach Investigations Report 2026 stod molnfelkonfiguration för 14 procent av alla globala dataintrång under första kvartalet 2026, upp från cirka 9 procent 2024 (CloudSwitched analys av DBIR 2026). SentinelOne räknar högre och skriver att över 31 procent av alla molnintrång 2026 beror på felkonfiguration och mänskliga misstag, med IAM-fel, exponerade API-nycklar och bristande övervakning som de vanligaste orsakerna (SentinelOne, Cloud Security Statistics 2026).

Exabeams sammanställning för 2026 landar på att 23 procent av alla molnsäkerhetsincidenter härrör direkt från felkonfiguration, och att hela 82 procent av dessa fel beror på den mänskliga faktorn snarare än buggar i molnplattformen (Exabeam, 64 Cloud Security Statistics 2026). IT Convergence går ännu längre och pekar på att så mycket som 90 procent av alla molnsäkerhetsmisslyckanden väntas bero på felkonfiguration under 2026, med publik lagringsexponering som den mest skadliga kategorin: 70 procent av granskade miljöer har minst en offentligt exponerad lagringsbucket (IT Convergence, Cloud Governance 2026).

Kostnaden stiger också. Ett intrång kopplat till felkonfiguration kostar i snitt runt 4,3 miljoner dollar att sanera, en ökning på ungefär 17 procent jämfört med föregående år, och multi-cloud-incidenter är genomgående dyrare att städa upp än incidenter i en enda molnmiljö. En genomsnittlig verksamhet kör dessutom över 3 000 felkonfigurerade molnresurser samtidigt utan att veta om det, enligt CybelAngels analys av exponerade molntillgångar, som också citerar Gartners prognos att 99 procent av alla molnsäkerhetsmisslyckanden fram till 2026 kommer att vara kundens eget fel, inte molnleverantörens (CybelAngel, Misconfigured Cloud Assets 2026).

Intruders Cloud Security Index för 2026 skannade omkring 3 000 organisationer och fann svaga IAM-kontroller eller obefintlig loggning i mellan 80 och 98 procent av alla molnkonton, beroende på leverantör. Rapporten delar in fynden i sex kategorier: svag IAM, saknad loggning, felkonfigurerade tjänster, för öppna brandväggar, exponerade tjänster och svag kryptering, en kategorisering som stämmer väl överens med det ScoutSuite letar efter i praktiken.

Brandväggsregler är ett eget kapitel för sig. En analys som hänvisar till Gartner konstaterar att 99 procent av alla intrång kopplade till brandväggar 2025 berodde på felkonfiguration snarare än en sårbarhet i själva brandväggsprodukten, och Fugues Cloud Security Report för 2026 fann att 73 procent av granskade organisationer hade minst en kritisk felkonfiguration vid granskningstillfället (Meewco, sammanställning av Gartner- och Fugue-data). Containermiljöer är inte heller undantagna: StationX rapporterar, med hänvisning till Red Hat, att 45 procent av alla säkerhetsincidenter i Kubernetes går tillbaka till en felkonfigurerad inställning, inte en exploaterad sårbarhet (StationX, Cloud Security Statistics 2026). Mönstret upprepar sig oavsett lager: infrastruktur, container eller applikation, den vanligaste boven är en inställning någon glömde eller aldrig förstod konsekvensen av.

ScoutSuite jämfört med Prowler och Security Command Center

Vi har tidigare gått igenom hur du granskar AWS med Prowler och hur du sätter upp GCP Security Command Center. Båda är utmärkta verktyg, men de har en gemensam begränsning: de är byggda för ett moln i taget. ScoutSuite, utvecklat av NCC Group och släppt som öppen källkod på GitHub, löser ett annat problem: att ge en enda rapport och ett enda gränssnitt för AWS, Azure, GCP, Alibaba Cloud och Oracle Cloud samtidigt (NCC Group, ScoutSuite på GitHub).

Skillnaden märks särskilt i nordiska organisationer, där it-avdelningar sällan har renodlat en molnleverantör. Ett bolag kör ofta produktion i AWS, samarbetsverktyg och identitetshantering i Azure via Microsoft 365, och data- eller ml-arbetslaster i GCP. Att köra tre separata verktyg med tre separata rapportformat gör det svårt att prioritera vad som faktiskt är farligast. ScoutSuite normaliserar fynden till samma allvarlighetsskala oavsett moln, vilket gör att en säkerhetschef kan se en enda lista sorterad efter risk istället för tre osammanhängande listor.

EgenskapScoutSuiteProwlerSecurity Command Center
MolnstödAWS, Azure, GCP, Alibaba, Oracle CloudPrimärt AWS (plus begränsat Azure/GCP-stöd)Endast GCP
LicensÖppen källkod (GPLv2)Öppen källkod (Apache 2.0)Del av Google Cloud, betalfunktioner i Premium-nivå
UtdataformatInteraktiv HTML-rapport, JSONCSV, JSON, HTML, CLI-tabellKonsol, Pub/Sub, Cloud Asset Inventory
DriftlägeKörs lokalt eller i CI/CD, agentlöstKörs lokalt eller i CI/CD, agentlöstMolnbaserad tjänst, kontinuerlig övervakning
Bäst förOrganisationer med flera moln som vill ha en enhetlig bildRenodlade AWS-miljöer med snabb CLI-arbetsgångRenodlade GCP-miljöer med behov av realtidsövervakning

ScoutSuite är inte tänkt att ersätta kontinuerlig övervakning som Security Command Center erbjuder. Det är snarare ett punktverktyg för periodiska revisioner, säkerhetsgranskningar inför en revision, eller en snabb hälsokontroll efter att ett nytt konto satts upp. Kombinerar man det med kontinuerlig loggning, till exempel via en SIEM-lösning som Wazuh, får man både djup och bredd.

Ett annat sätt att se på det: Prowler och Security Command Center är specialistverktyg som går på djupet i sitt respektive moln, med fler inbyggda regler och tätare integration mot molnleverantörens egna tjänster. ScoutSuite offrar en del av det djupet för bredd. Regeluppsättningen är gemensam och normaliserad över alla moln, vilket gör den lite mer generisk men samtidigt mycket enklare att jämföra rakt av mellan till exempel ett AWS-konto och en Azure-prenumeration. För ett team som redan har full koll på ett enda moln är ett specialistverktyg oftast bättre. För ett team som just nu inte har någon samlad bild alls av flera moln samtidigt är ScoutSuite den snabbaste vägen dit.

Förutsättningar: verktyg, konton och versioner

Innan du börjar behöver du tillgång till minst ett av de tre stora molnen, helst alla tre om du vill testa hela guiden. Du behöver också läsbehörighet, inte skrivbehörighet. ScoutSuite ska aldrig köras med ett konto som kan ändra något i din miljö, bara läsa konfiguration.

Verktyg och versioner som krävs för guiden
VerktygMinsta versionSyfte
Python3.9 eller senareKör ScoutSuite och dess beroenden
pipSenaste versionen som följer din Python-installationInstallerar ScoutSuite från PyPI
ScoutSuiteSenaste versionen på PyPI/GitHubSjälva granskningsverktyget
AWS CLIVersion 2.xAutentisering mot AWS-konton
Azure CLISenaste versionenAutentisering mot Azure-prenumerationer
Google Cloud SDK (gcloud)Senaste versionenAutentisering mot GCP-projekt
jq1.6 eller senareFiltrera JSON-utdata i terminalen

På kontosidan behöver du i AWS en IAM-roll eller användare med den inbyggda policyn SecurityAudit, i Azure rollen Reader på prenumerationsnivå, och i GCP rollen roles/viewer på projekt- eller organisationsnivå. Ingen av dessa roller ger skrivåtkomst, vilket gör dem säkra att dela ut till en granskningsprocess utan att öka din attackyta.

Om din organisation kör resurser i Stockholm-regionen (eu-north-1 i AWS, swedencentral i Azure eller europe-north1 i GCP) fungerar ScoutSuite precis likadant som mot vilken annan region som helst. Verktyget skiljer inte på regioner i sin regeluppsättning, det granskar hela kontot oavsett var resurserna faktiskt körs geografiskt, vilket är praktiskt för nordiska bolag som ofta har både en primär europeisk region och en sekundär för katastrofåterställning.

Steg 1-2: Installera ScoutSuite i en isolerad Python-miljö

Installera alltid ScoutSuite i en virtuell miljö. Verktyget drar in ett stort antal beroenden från molnens respektive SDK:er, och en global installation riskerar att krocka med andra Python-projekt på samma maskin.

python3 -m venv scoutsuite-env
source scoutsuite-env/bin/activate
pip install --upgrade pip
pip install scoutsuite
scout --version

När kommandot scout --version svarar utan fel har du en fungerande installation. Kör scout --help direkt efteråt för att se vilka underkommandon som finns tillgängliga, ett per molnleverantör: aws, azure, gcp, aliyun och oci. Guiden fokuserar på de tre första eftersom de täcker de allra flesta nordiska molnmiljöer.

Installationen drar med sig ett stort antal Python-paket, bland annat de officiella SDK:erna boto3 för AWS, azure-mgmt-familjen för Azure och google-api-python-client för GCP. Det är dessa bibliotek som gör det tunga jobbet, ScoutSuite är i grunden ett ramverk som anropar samma API:er du själv skulle kunna anropa manuellt, men som redan vet exakt vilka anrop som behövs och hur svaren ska tolkas mot kända säkerhetsregler. Räkna med att den första installationen tar en till två minuter beroende på nätverkshastighet, eftersom paketen tillsammans landar på några hundra megabyte.

Steg 3-4: Autentisera mot AWS och kör din första skanning

ScoutSuite återanvänder samma autentiseringskedja som AWS CLI. Enklast är att skapa en dedikerad profil med enbart läsbehörighet och peka ScoutSuite mot den profilen, istället för att återanvända ett konto med bredare rättigheter.

# Konfigurera en läsbehörig profil (görs en gång)
aws configure --profile sakerhetsgranskning

# Kör granskningen mot det kontot
scout aws --profile sakerhetsgranskning --report-dir ./rapporter/aws

Körningen tar allt från ett par minuter i ett litet konto till över en timme i en stor organisation med hundratals resurser per tjänst. ScoutSuite anropar de flesta av AWS API:er för att läsa konfiguration, vilket innebär att den räknas mot dina API-kvoter, ett skäl att alltid testa i en icke-produktionsmiljö innan du kör mot skarpa konton i stor skala.

Steg 5-6: Anslut Azure och granska båda molnen tillsammans

Vi har tidigare skrivit om hur du härdar IAM och lagring i Azure manuellt. ScoutSuite ger dig en automatiserad baslinje att jämföra mot innan du börjar det arbetet på riktigt, så att du vet exakt vilka konton och lagringskonton som redan avviker från grundkraven.

# Logga in interaktivt mot rätt prenumeration
az login
az account set --subscription "DIN-PRENUMERATION-ID"

# Kör granskningen
scout azure --cli --report-dir ./rapporter/azure

Flaggan --cli säger åt ScoutSuite att återanvända den redan inloggade Azure CLI-sessionen istället för att be om nya klientuppgifter. Om du hanterar flera prenumerationer kör du kommandot en gång per prenumeration och sparar varje rapport i en egen mapp, annars skriver senare körningar över tidigare resultat.

Steg 7-8: Lägg till GCP och hantera flera projekt

GCP skiljer sig från AWS och Azure genom att resurser nästan alltid är uppdelade i separata projekt snarare än ett enda konto. Det gör att du oftast behöver köra ScoutSuite en gång per projekt, eller ange en organisations-id om du vill täcka allt på en gång.

# Autentisera med ett tjänstekonto (service account)
gcloud auth activate-service-account --key-file=granskning-nyckel.json
gcloud config set project DITT-PROJEKT-ID

# Kör granskningen mot ett enskilt projekt
scout gcp --project-id DITT-PROJEKT-ID --report-dir ./rapporter/gcp

# Eller mot en hel organisation
scout gcp --organization-id DITT-ORG-ID --all-projects --report-dir ./rapporter/gcp-org

Se till att tjänstekontot bara har rollen roles/viewer, inte roles/editor eller roles/owner. Ett vanligt misstag är att återanvända ett tjänstekonto som redan finns i en CI/CD-pipeline och som råkar ha bredare rättigheter än nödvändigt, vilket vi återkommer till i avsnittet om fallgropar.

Steg 9: Läsa och tolka HTML-rapporten

Varje körning genererar en fristående HTML-fil i den mapp du angav med --report-dir. Öppna den i en webbläsare lokalt, ScoutSuite kräver ingen server för att visa rapporten. Rapporten är uppdelad i tre nivåer: en översiktspanel med antal fynd per allvarlighetsgrad, en lista per tjänst (till exempel S3, IAM, EC2 i AWS-rapporten), och en detaljvy per enskild resurs där du ser exakt vilken regel som slog till och varför.

Ett typiskt utdrag ur konsolen medan skanningen kör ser ut ungefär så här:

$ scout aws --profile sakerhetsgranskning --report-dir ./rapporter/aws

[2026-09-07 10:12:03] Fetching data from AWS APIs
[2026-09-07 10:12:03] Fetching IAM config
[2026-09-07 10:13:41] Fetching S3 config
[2026-09-07 10:14:52] Fetching EC2 config
[2026-09-07 10:16:20] Fetching CloudTrail config
[2026-09-07 10:17:05] Running rules
[2026-09-07 10:17:09] Report generated: ./rapporter/aws/scoutsuite-report.html

Varje regel i rapporten har en allvarlighetsgrad: danger, warning eller info. En publik S3-bucket med skrivrättigheter för alla klassas nästan alltid som danger, medan en saknad taggningskonvention klassas som info. Det är den skalan du prioriterar efter i nästa steg.

Rapportens sökfunktion är ofta det mest underskattade verktyget i gränssnittet. I stället för att bläddra igenom varje tjänst manuellt kan du söka på ett resursnamn, ett kontonummer eller en specifik regelbeteckning och direkt hoppa till rätt rad. Det blir särskilt värdefullt i stora konton där en enskild tjänst som IAM eller S3 kan generera hundratals rader, och där du annars hade behövt scrolla länge för att hitta just den resurs ett annat team frågade om.

Steg 10: Filtrera och prioritera fynd efter allvarlighetsgrad

Med tre rapporter (en per moln) och potentiellt tusentals rader riskerar du snabbt att drunkna i data. Prioritera enligt de kategorier som forskningen faktiskt visar orsakar flest verkliga intrång: publik lagringsexponering, för generösa IAM-behörigheter, saknad loggning, öppna brandväggsregler och obligatorisk kryptering som saknas.

Vanligaste felkonfigurationskategorierna och varför de spelar roll
KategoriVad ScoutSuite letar efterVarför det är farligt
Publik lagringsexponeringS3-buckets, Azure Blob-containrar, GCP Cloud Storage-buckets öppna för allmän åtkomstDirekt dataläcka utan att en angripare behöver bryta sig in i något alls
Överdrivna IAM-behörigheterRoller/policyer med wildcard-behörigheter (*:*)Ett komprometterat konto kan då eskalera till full kontroll över hela miljön
Saknad loggningCloudTrail, Azure Activity Log eller Cloud Audit Logs som är avstängda eller ofullständigaIngen möjlighet att i efterhand se vad en angripare gjorde
Öppna brandväggsreglerSäkerhetsgrupper/NSG:er som tillåter trafik från 0.0.0.0/0 på känsliga portarOnödig exponering av interna tjänster mot hela internet
Svag eller saknad krypteringDiskar, databaser och lagring utan kryptering i vilaData i klartext om lagringsmediet stjäls eller felkonfigureras

En praktisk regel: åtgärda alla danger-fynd i publik lagring och IAM inom en vecka, alla warning-fynd inom en månad, och samla info-fynd i en backlogg som städas kvartalsvis. Det håller åtgärdstakten rimlig utan att teamet fastnar i att jaga varje enskild lågriskvarning.

Det är också värt att skilja på ett fynd som är farligt i teorin och ett fynd som är farligt i din specifika miljö. En öppen brandväggsregel mot port 22 är allvarlig om servern faktiskt kör SSH mot internet, men i praktiken ofarlig om samma regel gäller en instans som redan ligger bakom ett separat, strikt nätverkslager du styr på annat håll. ScoutSuite känner inte till den kontexten automatiskt, det är därför den mänskliga bedömningen i triageprocessen fortfarande behövs. Verktyget gör grovjobbet med att hitta kandidaterna, teamet gör slutbedömningen om varje kandidat faktiskt utgör en risk i just er arkitektur.

Steg 11: Exportera resultat till JSON och bygg egna regler

Utöver HTML-rapporten skriver ScoutSuite alltid en maskinläsbar JSON-fil i samma katalog. Den är användbar när du vill bearbeta resultaten programmatiskt, till exempel skicka bara danger-fynd vidare till ett ärendehanteringssystem.

# Räkna antal fynd per allvarlighetsgrad med jq
cat ./rapporter/aws/scoutsuite-results.json \
  | jq '.services | to_entries[] | .value.findings // {} | to_entries[] | {rule: .key, level: .value.level}' \
  | jq -s 'group_by(.level) | map({level: .[0].level, antal: length})'

Vill du undanta specifika regler som inte är relevanta för din miljö, till exempel en tagg-regel du medvetet inte följer, skapar du en exception-fil i JSON-format och pekar ScoutSuite mot den med --exceptions:

{
  "aws": {
    "s3-bucket-no-mfa-delete": {
      "produktionsbucket-loggar": "Loggbucket, MFA-delete hanteras via annan kontroll"
    }
  }
}

Detta gör att teamet slipper klicka bort samma godkända undantag manuellt varje gång rapporten genereras på nytt, vilket är avgörande när granskningen körs automatiskt varje natt.

Tänk på att en exception-fil i sig är en säkerhetsrelevant konfiguration. Varje undantag bör motiveras skriftligt, precis som i exemplet ovan, och gås igenom av någon annan än den som lade till det, annars riskerar filen att växa till en papperskorg där riktiga problem gömmer sig bakom gamla, aldrig omprövade godkännanden. Ett enkelt mönster är att granska hela exception-filen en gång per kvartal och ta bort undantag för resurser som inte längre finns kvar i miljön.

Steg 12-13: Automatisera granskningen med GitHub Actions

En engångsskanning ger en ögonblicksbild. Verkligt värde uppstår när granskningen körs regelbundet och avvikelser flaggas automatiskt. Nedan är ett komplett, fungerande arbetsflöde som kör alla tre moln varje natt och sparar rapporterna som byggartefakter.

name: molnsakerhetsgranskning

on:
  schedule:
    - cron: '0 3 * * *'
  workflow_dispatch: {}

jobs:
  scoutsuite-granskning:
    runs-on: ubuntu-latest
    steps:
      - name: Installera ScoutSuite
        run: pip install scoutsuite

      - name: Konfigurera AWS-uppgifter
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: eu-north-1

      - name: Granska AWS
        run: scout aws --report-dir ./rapporter/aws

      - name: Granska Azure
        env:
          AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }}
          AZURE_CLIENT_SECRET: ${{ secrets.AZURE_CLIENT_SECRET }}
          AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
        run: scout azure --report-dir ./rapporter/azure

      - name: Granska GCP
        run: |
          echo "${{ secrets.GCP_SA_KEY }}" > gcp-nyckel.json
          gcloud auth activate-service-account --key-file=gcp-nyckel.json
          scout gcp --project-id ${{ secrets.GCP_PROJECT_ID }} --report-dir ./rapporter/gcp

      - name: Spara rapporter
        uses: actions/upload-artifact@v4
        with:
          name: molnsakerhetsrapporter
          path: rapporter/

Lägg alla kontouppgifter som hemligheter (secrets) i GitHub-repots inställningar, aldrig i klartext i workflow-filen. Vill du ha en notis istället för att behöva öppna rapporten manuellt varje morgon, lägg till ett sista steg som parsar JSON-filen med jq och postar en sammanfattning till en Slack-webhook när antalet danger-fynd överstiger noll.

Nordisk kontext: NIS2 och kravet på dokumenterad granskning

För svenska och nordiska bolag som täcks av NIS2-direktivet handlar en molnrevision inte bara om att hitta problem, den handlar också om att kunna visa upp en dokumenterad process för en tillsynsmyndighet. En ScoutSuite-rapport, sparad tillsammans med datum och vilket konto som granskades, fungerar som just den typen av bevis. Det är skillnaden mellan att säga “vi har koll på våra moln” och att faktiskt kunna lägga fram en tidsstämplad rapport som styrker påståendet.

Google Cloud har själva noterat en positiv trend i sin Cloud Threat Horizons-rapport för första halvåret 2026: andelen intrång där en angripare fick sitt första fotfäste via en felkonfiguration sjönk från 29,4 procent under första halvåret 2025 till 21 procent under andra halvåret samma år. Det är en förbättring, men den beror sannolikt på att fler organisationer redan har börjat granska sina miljöer regelbundet, inte på att problemet har försvunnit. En siffra på 21 procent betyder fortfarande att ungefär vart femte intrång börjar med något en verktygsbaserad granskning som ScoutSuite hade kunnat flagga i förväg.

Ett återkommande mönster i nordiska organisationer är att säkerhetsansvaret för molnet delas mellan en central it-säkerhetsfunktion och flera decentraliserade utvecklingsteam som var och ett äger sitt eget AWS-konto eller sin egen Azure-prenumeration. Utan ett gemensamt verktyg som ScoutSuite blir det i praktiken omöjligt för den centrala funktionen att få en samlad bild. Genom att köra granskningen centralt, med läsbehörighet mot alla konton via en gemensam roll, kan säkerhetsteamet leverera en portföljöversikt till ledningen utan att behöva be varje enskilt team om en manuell statusrapport.

Det praktiska rådet till en säkerhetsansvarig i en svensk organisation är därför ganska konkret: be inte utvecklingsteamen om en muntlig statusuppdatering på nästa möte, kör istället en egen, oberoende granskning med ett skrivskyddat konto och jämför resultatet mot vad teamen själva rapporterar. Skillnaden mellan de två bilderna säger ofta mer om det faktiska säkerhetsläget än någon av bilderna gör på egen hand.

Vanliga fallgropar när du kör ScoutSuite i produktion

  • Att köra granskningen med ett administratörskonto. Det fungerar, men bryter mot principen om minsta möjliga behörighet och skapar en onödigt kraftfull uppsättning autentiseringsuppgifter som i sig blir ett mål för angripare.
  • Att återanvända ett CI/CD-tjänstekonto med breda rättigheter. Många team tar genvägen att peka ScoutSuite mot samma tjänstekonto som redan används för driftsättning, vilket ger granskningsverktyget mycket mer åtkomst än det behöver.
  • Att ignorera API-hastighetsgränser vid stora konton. En organisation med tusentals resurser kan trigga throttling hos molnleverantören, vilket gör att skanningen antingen tar orimligt lång tid eller avbryts halvvägs.
  • Att drunkna i info-nivåfynd istället för att prioritera. Utan en tydlig triageprocess blir rapporten en lång lista ingen orkar läsa, och de allvarligaste fynden riskerar att försvinna i mängden.
  • Att aldrig jämföra mot föregående körning. Utan historik vet du inte om ett fynd är nytt (och kanske akut) eller har legat olöst i sex månader (och kräver en annan eskaleringsväg).
  • Att glömma undanta godkända avvikelser. Utan en exception-fil enligt steg 11 klickar teamet bort samma “kända och accepterade” varning manuellt varje gång, vilket leder till granskningströtthet och att riktiga nya fynd missas.
  • Att lagra rapporterna okrypterat på en delad disk. En ScoutSuite-rapport är i praktiken en karta över din molnmiljös svagheter. Sparas den öppet tillgänglig på ett nätverksdelat område blir den själv ett attraktivt mål, precis den typ av “neglected asset” som CybelAngels analys varnar för.
  • Att bara granska produktionsmiljön. Test- och stagingmiljöer får ofta lösare regler för att utvecklingsarbetet ska gå snabbare, och de har vanligtvis samma nätverksanslutning mot resten av organisationen som produktionen. En angripare bryr sig inte om att en miljö är “bara” test.

Felsökning: åtta vanliga fel och hur du löser dem

De flesta problemen med ScoutSuite handlar inte om buggar i själva verktyget, utan om behörigheter, nätverk och miljöskillnader mellan din lokala dator och den plattform granskningen till slut ska köras på, till exempel en CI/CD-körare. Nedan är de åtta felen vi stöter på oftast när vi hjälper team att sätta upp sin första automatiserade granskning, i ungefär den ordning de brukar dyka upp.

  1. “ModuleNotFoundError” vid start. Du har troligen inte aktiverat den virtuella miljön. Kör source scoutsuite-env/bin/activate igen innan du startar scout.
  2. “AccessDenied” på enskilda AWS-tjänster. IAM-policyn SecurityAudit saknar läsrättigheter till ett fåtal nyare tjänster. Lägg till en kompletterande policy med enbart List*– och Describe*-behörigheter för den specifika tjänsten.
  3. Azure svarar “Insufficient privileges to complete the operation”. Kontrollera att rollen Reader faktiskt är tilldelad på rätt scope, prenumerationsnivå snarare än bara en enskild resursgrupp.
  4. GCP-fel “Quota exceeded” mitt i skanningen. Stora organisationer med många projekt kan slå i API-kvoter. Begär högre kvot i Google Cloud Console eller kör granskningen projekt för projekt istället för hela organisationen på en gång.
  5. Rapporten öppnas men visar noll fynd. Kontrollera att kontot faktiskt har läsrättigheter till de tjänster du förväntar dig fynd ifrån. En alltför snäv policy ger en “ren” rapport som i själva verket bara betyder att inget kunde läsas, vilket är farligare än en rapport full av varningar eftersom den ger falsk trygghet.
  6. Skanningen hänger sig utan felmeddelande. Vanligtvis nätverksrelaterat i en CI/CD-miljö utan utgående åtkomst till molnets API-slutpunkter. Kontrollera brandväggsregler för byggagenten.
  7. HTML-rapporten renderas tom i webbläsaren. Vissa webbläsare blockerar det inbäddade JavaScript när filen öppnas direkt från disk. Öppna filen via python3 -m http.server i rapportkatalogen och besök localhost istället.
  8. “Permission denied” när rapporten ska skrivas till disk. Kontrollera att katalogen i --report-dir existerar och att det körande användarkontot har skrivrättigheter dit, särskilt vanligt i containerbaserade CI/CD-körare med read-only filsystem som standard.

Komplett arbetsflöde: wrapper-skript som kör alla tre moln och skickar en sammanfattning

GitHub Actions-workflowet i föregående steg fungerar utmärkt i CI/CD, men ibland vill du kunna köra samma granskning manuellt från en administratörs egen dator, eller från en schemalagd cron-tjänst på en intern server som inte har tillgång till GitHub. Nedan är ett fristående bash-skript som binder ihop installation, autentisering mot alla tre moln, granskning och en sammanfattning i terminalen, ett komplett litet projekt du kan spara som molngranskning.sh och lägga in i valfri schemaläggare.

#!/usr/bin/env bash
set -euo pipefail

DATUM=$(date +%Y-%m-%d)
UTKATALOG="./rapporter/${DATUM}"
mkdir -p "${UTKATALOG}/aws" "${UTKATALOG}/azure" "${UTKATALOG}/gcp"

echo "== Granskar AWS =="
scout aws --profile sakerhetsgranskning --report-dir "${UTKATALOG}/aws"

echo "== Granskar Azure =="
scout azure --cli --report-dir "${UTKATALOG}/azure"

echo "== Granskar GCP =="
scout gcp --project-id "${GCP_PROJEKT_ID}" --report-dir "${UTKATALOG}/gcp"

echo "== Sammanfattning =="
for moln in aws azure gcp; do
  ANTAL_DANGER=$(jq '[.services[].findings? // {} | to_entries[] | select(.value.level=="danger")] | length' \
    "${UTKATALOG}/${moln}"/scoutsuite-results_*.js 2>/dev/null || echo 0)
  echo "${moln}: ${ANTAL_DANGER} fynd med allvarlighetsgrad danger"
done

echo "Rapporter sparade i ${UTKATALOG}"

Gör skriptet körbart med chmod +x molngranskning.sh och lägg till det i crontab med till exempel 0 4 * * * /sokvag/molngranskning.sh >> /var/log/molngranskning.log 2>&1 för en daglig körning klockan fyra på natten. Kombinerat med jq-sammanfattningen från steg 11 har du ett fullständigt, upprepningsbart arbetsflöde: installation, autentisering, granskning av tre moln, prioritering efter allvarlighetsgrad och lagring av historik, allt i ett enda skript som varken kräver GitHub eller en betald tjänst.

Avancerade tips: flera konton, varningar och åtgärdsspårning

När grundflödet fungerar finns det tre naturliga nästa steg. Först, skala upp till flera AWS-konton via AWS Organizations genom att loopa scout aws över en lista av profiler, en per konto, och slå ihop JSON-resultaten innan de skickas vidare. Det ger en portfölj-nivå-bild istället för konto för konto.

För det andra, koppla resultaten till ett ärendehanteringsflöde. Ett enkelt skript som läser JSON-filen, filtrerar på danger, och skapar ett ärende per unikt fynd i din ärendehanteringsplattform gör att åtgärdsarbetet spåras precis som vilken annan bugg som helst, istället för att fastna i en PDF ingen öppnar igen.

För det tredje, komplettera ScoutSuites punktgranskning av redan driftsatt infrastruktur med granskning innan driftsättning. Vi går igenom det i detalj i vår guide till Terraform-säkerhet och IaC-skanning samt i guiden om containerskanning med Trivy. Tillsammans täcker de tre verktygen hela kedjan: kod före driftsättning, containerimage före publicering, och den faktiska molnmiljön efter att allt är på plats.

Ett sista tips: kör alltid en första skanning i en testmiljö eller ett sandlådekonto innan du pekar verktyget mot produktion. Det ger dig en känsla för hur lång tid en körning tar och hur många fynd du kan förvänta dig, utan risken att en ovanligt tung skanning stör produktionens API-kvoter mitt i arbetsdagen.

Fundera också på hur granskningens resultat ska presenteras för olika mottagare. En utvecklare vill se exakt vilken resurs och vilken rad i infrastrukturkoden som orsakade felet, medan en säkerhetschef eller styrelse hellre vill se en trend över tid: minskar antalet danger-fynd månad för månad, eller ligger de still trots att teamet säger sig arbeta med åtgärder? Spara därför alltid resultaten från varje körning i en egen daterad mapp, som i wrapper-skriptet ovan, så att du kan bygga ett enkelt diagram över utvecklingen utan att behöva någon extra mjukvara.

Slutligen, behandla ScoutSuite som en del av en större process snarare än ett engångsprojekt. Verktyget hittar inte allt, det saknar till exempel djupgående analys av applikationskod eller runtime-beteende i containrar. Det gör vad det är byggt för att göra: ge en snabb, agentlös och gratis baslinje över hur väl din molnkonfiguration följer kända bästa praxis, körbar om och om igen utan att kräva en dyr plattform eller ett långt upphandlingsprojekt.

Sammanfattningsvis är den svåraste delen av multi-cloud-säkerhet sällan tekniken, det är disciplinen att faktiskt köra granskningen regelbundet och agera på det den hittar. ScoutSuite tar bort ursäkten att det saknas verktyg, installationen tar minuter och kostar inget. Det som återstår är att bygga in granskningen i en process, sätta rimliga svarstider per allvarlighetsgrad, och se till att någon faktiskt läser rapporten varje gång den genereras, inte bara sparar den i en mapp ingen öppnar igen.

Vanliga frågor om ScoutSuite och multi-cloud-säkerhet

Är ScoutSuite gratis att använda?

Ja. ScoutSuite är öppen källkod under GPLv2-licens och kostar inget att ladda ner, installera eller köra, oavsett hur många konton eller moln du granskar.

Kan ScoutSuite ändra något i min molnmiljö?

Nej, verktyget är designat för att bara läsa konfiguration. Så länge du använder ett konto med enbart läsrättigheter (till exempel SecurityAudit i AWS eller Reader i Azure) kan ScoutSuite inte skriva, ändra eller radera resurser.

Ersätter ScoutSuite kontinuerlig molnövervakning?

Nej. ScoutSuite ger en ögonblicksbild vid körtillfället. För kontinuerlig upptäckt av nya felkonfigurationer i realtid behövs en tjänst som Security Command Center i GCP, eller en SIEM-lösning som samlar in loggar löpande. ScoutSuite fungerar bäst som en periodisk, schemalagd kompletterande kontroll.

Hur ofta bör man köra en ScoutSuite-granskning?

Ett vanligt mönster är en schemalagd körning per dygn för produktionsmiljöer och per vecka för mindre kritiska miljöer, kombinerat med en manuell körning direkt efter större infrastrukturförändringar eller nya kontons idrifttagning.

Fungerar ScoutSuite med Alibaba Cloud och Oracle Cloud också?

Ja, ScoutSuite har underkommandon för både Alibaba Cloud (scout aliyun) och Oracle Cloud Infrastructure (scout oci), utöver AWS, Azure och GCP som den här guiden fokuserar på.

Vad är skillnaden mellan ScoutSuite och Steampipe?

Steampipe (steampipe.io) frågar mot din molnmiljö med SQL och passar bättre för team som redan tänker i databastermer och vill bygga egna, mycket specifika frågor. ScoutSuite är mer färdigpaketerat med fördefinierade regler och en läsbar rapport direkt ur lådan, vilket gör det till ett snabbare förstahandsval för de flesta säkerhetsteam.

Behöver jag installera om ScoutSuite för varje moln?

Nej, en enda installation innehåller stöd för alla molnleverantörer. Du väljer moln genom vilket underkommando du kör (scout aws, scout azure eller scout gcp), inte genom separata installationer.

Var lagras rapporterna, och är det säkert att spara dem i CI/CD-artefakter?

Rapporterna sparas lokalt i den katalog du anger. Eftersom de innehåller detaljerad information om din faktiska molnkonfiguration, exakt den typ av information en angripare vill åt, bör de behandlas som känsliga och begränsas till samma åtkomstkontroll som resten av din säkerhetsdokumentation, snarare än att sparas som öppet läsbara byggartefakter.