Cloud Custodian: Autofixa Molnfel i 13 Steg [2026]

En felkonfigurerad S3-bucket. En säkerhetsgrupp som släpper in hela internet på port 22. En IAM-roll med rättigheter ingen längre minns varför den fick. Det är sällan en avancerad exploit som öppnar dörren till ett dataintrång i molnet, utan ett enkelt misstag som ingen hann upptäcka. Enligt IBM:s Cost of a Data Breach Report 2025 kostar ett genomsnittligt dataintrång 4,44 miljoner dollar globalt, och intrång som sträcker sig över flera miljöer, alltså både moln och lokala system, kostar i snitt 5,05 miljoner dollar enligt samma rapport. Microsofts Digital Defense Report 2026 pekar på att exponerade molnresurser i genomsnitt attackeras inom 5,3 timmar efter att de blivit synliga på internet. Det lämnar nästan inget utrymme för manuell granskning av vem som glömde stänga vad.

Problemet växer snabbare än teamen som ska lösa det. Ett medelstort bolag kan ha tusentals molnresurser utspridda över flera konton, regioner och team, och varje ny tjänst som läggs till ökar ytan som kan misskonfigureras. Checklistor i kalkylblad och manuella kvartalsgenomgångar hinner helt enkelt inte med när en utvecklare kan skapa en ny, felaktigt öppen resurs klockan tre på natten utan att någon säkerhetsansvarig ser det förrän veckor senare. Det är precis det gapet som policy-as-code-verktyg som Cloud Custodian är byggda för att stänga.

Den här guiden visar hur du använder Cloud Custodian (c7n), ett verktyg med öppen källkod som skriver säkerhetsregler som kod och kan rätta avvikelser automatiskt i AWS, Azure och Google Cloud. Du går igenom 13 konkreta steg, från installation till ett komplett CI/CD-flöde som stoppar felkonfiguration innan den når produktion, plus ett scenario som visar hela kedjan från upptäckt till åtgärd i praktiken. Alla kommandon i den här artikeln är testade mot Cloud Custodian 0.9.52.0, den senaste huvudversionen i skrivande stund, publicerad 5 september 2026.

Molnfelkonfiguration och Cloud Custodian: bakgrund och hur policy-as-code fungerar

Verizons Data Breach Investigations Report 2026 analyserade över 22 000 bekräftade dataintrång i 145 länder, det största urvalet i rapportens 19-åriga historia. Sårbarhetsexploatering gick om stulna inloggningsuppgifter som vanligaste startpunkten och stod för 31 procent av intrången, medan tredjepartsrelaterade intrång ökade från 30 till 48 procent år över år. Siffrorna handlar om hela hotlandskapet, inte bara molnfelkonfiguration, men de visar varför säkerhetsteam behöver automatik snarare än manuella checklistor. Antalet resurser i ett modernt AWS- eller Azure-konto växer snabbare än antalet säkerhetsingenjörer som kan granska dem för hand.

Cloud Custodian beskrivs av sina egna utvecklare som ett verktyg som “unifies the dozens of tools and scripts most organizations use for managing their public cloud accounts into one open source tool”, enligt projektets officiella dokumentation. Istället för att skriva ett eget Python-skript för varje kontroll, uttrycker du regeln som en YAML-policy med tre delar: ett resource (vilken typ av resurs, till exempel en EC2-instans eller en S3-bucket), en lista filters (villkor som avgör vilka resurser som matchar) och en lista actions (vad som ska hända med de resurser som matchar, till exempel notifiera, tagga, stoppa eller radera). Dokumentationen beskriver motorn som “a stateless rules engine for policy definition and enforcement, with metrics, structured outputs and detailed reporting for clouds infrastructure”. Det är principen som kallas policy-as-code, samma tankesätt som Terraform och CloudFormation redan tillämpar på infrastruktur.

Det som gör Cloud Custodian mer än ett skanningsverktyg är exekveringsmodellen. En policy kan köras lokalt som en engångskontroll, periodiskt via cron, eller som en egen AWS Lambda-funktion som triggas av CloudTrail-händelser i realtid. Dokumentationen betonar att verktyget “integrates tightly with serverless runtimes to provide real time remediation/response with low operational overhead”. I praktiken betyder det att en policy kan upptäcka och åtgärda en felkonfigurerad resurs inom minuter efter att den skapades, långt innan Microsofts uppmätta 5,3 timmar till första attack hinner passera.

Till skillnad från rena skanningsverktyg som bara rapporterar vad som är fel, är Cloud Custodian byggt för att även utföra åtgärden. Den skillnaden spelar roll i praktiken. En lista med femhundra avvikelser som ingen hinner beta av är i princip lika värdelös som att inte ha listan alls. Genom att koppla varje fynd till en konkret action, från en enkel tagg till en fullständig borttagning av regeln som orsakade problemet, flyttar Cloud Custodian tyngdpunkten från rapportering till faktisk riskreduktion.

För svenska och nordiska bolag som redan hanterar krav från NIS2-direktivet eller branschspecifika regelverk tillför automatiserad molnkontroll ett konkret bevis på att kraven efterlevs löpande, inte bara vid ett årligt revisionstillfälle. En logg över varje policy-körning, med tidsstämpel och vilka resurser som påverkades, blir i praktiken ett revisionsspår som går att visa upp direkt för en tillsynsmyndighet eller en extern revisor utan att någon behöver sätta ihop materialet manuellt i efterhand.

Förutsättningar: verktyg, versioner och behörigheter

Innan du börjar behöver du ett fåtal verktyg installerade och rätt behörigheter i molnkontot du vill skydda. Cloud Custodian är skrivet i Python och fungerar på Linux, macOS och Windows (via WSL rekommenderas för Windows). Tabellen nedan listar vad du behöver för att följa varje steg i den här guiden.

Verktyg	Version	Syfte
Python	3.9 eller senare	Krävs för att installera och köra c7n
Cloud Custodian (c7n)	0.9.52.0	Huvudpaketet med regelmotorn
c7n-gcp	0.4.52	Separat GCP-providerpaket
AWS CLI	v2	Autentisering mot AWS
Docker	senaste stabila	Alternativ körmiljö utan lokal Python-installation
Git	senaste stabila	Versionshantering av policyfiler
c7n-org	följer c7n-versionen	Körning mot flera konton samtidigt

Du behöver också en IAM-identitet (användare eller roll) med läsrättigheter till de tjänster policyerna granskar, plus skrivrättigheter till de actions du planerar att använda. Ett vanligt nybörjarfel är att ge full administratörsåtkomst för att “det ska fungera”. Gör i stället en dedikerad policy med exakt de rättigheter dina regler behöver, och utöka gradvis när du lägger till nya policyer. Om du planerar händelsedriven exekvering i steg 10 behöver du även rättigheter att skapa Lambda-funktioner, IAM-roller och EventBridge-regler.

En rimlig startpunkt för en läsande, icke-destruktiv roll ser ut ungefär så här. Lägg till skrivrättigheter (till exempel ec2:TerminateInstances eller s3:PutBucketEncryption) först när du faktiskt lägger till en action som behöver dem.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "s3:GetBucket*",
        "s3:ListBucket",
        "iam:GetRole",
        "iam:ListRoles",
        "cloudtrail:LookupEvents"
      ],
      "Resource": "*"
    }
  ]
}

Steg 1 och 2: Installera Cloud Custodian och koppla molnkontot

Det enklaste sättet att installera Cloud Custodian är via pip-paketet c7n i en egen virtuell miljö, så att paketets beroenden inte krockar med andra Python-projekt på din maskin. Källkoden och issue-trackern finns på projektets GitHub-repo, vilket är den bästa platsen att kolla om du stöter på en bugg eller vill se hur en specifik filtertyp är implementerad.

python3 -m venv custodian-env
source custodian-env/bin/activate
pip install c7n

# Verifiera installationen
custodian version

Föredrar du att inte installera Python-paket lokalt, finns en officiell Docker-image som ger samma funktionalitet utan att röra din värdmiljö.

docker pull cloudcustodian/c7n
docker run -v $(pwd):/home/custodian/policies -it cloudcustodian/c7n custodian version

Nästa steg är att koppla verktyget till ditt molnkonto. Cloud Custodian återanvänder samma autentisering som AWS CLI, Azure CLI och gcloud redan använder, så om du kan köra aws s3 ls i terminalen är du redo.

# AWS: konfigurera en profil med begränsade rättigheter
aws configure --profile custodian-prod
export AWS_PROFILE=custodian-prod
export AWS_DEFAULT_REGION=eu-north-1

# Testa att identiteten fungerar
aws sts get-caller-identity

Lägg policyfiler i en egen mapp från start, till exempel policies/aws/, så att strukturen håller när du lägger till fler moln senare i guiden. Projektets egen Getting Started-guide för AWS är en bra referens att ha öppen i en flik medan du följer resten av den här artikeln, särskilt om du stöter på en resurstyp som inte täcks här.

Steg 3 och 4: Skriv och validera din första YAML-policy

En Cloud Custodian-policy är i grunden bara en YAML-fil. Nedan är ett exempel som letar efter EC2-instanser med okrypterade EBS-volymer, ett klassiskt compliance-krav i både PCI DSS och ISO 27001.

policies:
  - name: encrypted-ebs-required
    resource: aws.ec2
    description: Hitta EC2-instanser med okrypterade EBS-volymer
    filters:
      - type: ebs
        key: Encrypted
        value: false
    actions:
      - type: notify
        template: default.html
        to:
          - [email protected]
        transport:
          type: sns
          topic: arn:aws:sns:eu-north-1:123456789012:custodian-alerts

Innan du kör någonting skarpt ska policyn alltid valideras och testas i torrkörningsläge. Validering kontrollerar att syntaxen och resurstyperna faktiskt existerar, medan en dry-run visar exakt vilka resurser som skulle påverkas utan att röra något.

custodian validate policies/aws/encrypted-ebs.yml
custodian run --dryrun -s out policies/aws/encrypted-ebs.yml

En lyckad validering ger bara tyst utskrift eller ett kort “No errors found”, medan en dry-run skriver loggrader liknande detta i terminalen:

2026-10-08 09:14:02,381: custodian.policy:INFO policy:encrypted-ebs-required resource:aws.ec2 region:eu-north-1 count:3 time:1.42
2026-10-08 09:14:02,402: custodian.output:INFO Policy encrypted-ebs-required (dryrun) matched 3 resources

Siffran “count:3” betyder att tre instanser matchade filtret. Om du i stället får “count:0” finns ingen omedelbar risk för just den policyn, vilket inte är samma sak som att inget är fel, bara att den här specifika regeln inte slog till.

Vanliga filteroperatorer att känna till

Filtren är hjärtat i varje policy, och de flesta policyfel kommer från ett filter som inte beter sig som skribenten trodde. Några operatorer du kommer att använda om och om igen:

value – jämför ett fält i resursens JSON mot ett värde, med op som eq, ne, gt, lt eller regex.
and / or / not – kombinerar flera filter till mer avancerad logik. Nästlingen avgör utfallet, ett extra not-block på fel nivå är den vanligaste orsaken till att ett filter ger motsatt resultat av det tänkta.
age (via value_type: age) – räknar dagar sedan ett datumfält, användbart för regler om “äldre än X dagar”.
tag-count – filtrerar på hur många taggar en resurs har, praktiskt för att hitta resurser som helt saknar ägartaggning.
marked-for-op – hittar resurser som redan är markerade av en tidigare mark-for-op-action, så att du kan bygga uppföljande policyer som kollar om varseltiden har löpt ut.

Steg 5 och 6: Köra policyn skarpt och tolka output

När dry-runen visar förväntat resultat tar du bort flaggan --dryrun för att faktiskt köra actions.

custodian run -s out policies/aws/encrypted-ebs.yml

Mappen out (angiven med -s) fylls nu med tre viktiga filer per policy: custodian-run.log (textloggen), resources.json (fullständig JSON-dump av varje matchad resurs) och metrics.json (räknare för hur många resurser som matchades och hur lång tid körningen tog). Ett utdrag ur resources.json kan se ut så här:

[
  {
    "InstanceId": "i-0a1b2c3d4e5f67890",
    "Tags": [{"Key": "Name", "Value": "webserver-prod-02"}],
    "c7n:MatchedFilters": ["ebs"]
  }
]

Fältet c7n:MatchedFilters är särskilt användbart när en policy har flera filter, eftersom det visar exakt vilket villkor som gjorde att resursen plockades upp. Spara alltid output-mappen i din CI-pipeline som en artefakt, det är den enklaste revisionsspåret du kan ha när en granskare frågar varför en resurs ändrades en specifik natt.

metrics.json är den fil som är lättast att bygga en instrumentpanel runt. Den innehåller bland annat ResourceCount (antal matchade resurser per körning), ResourceTime (hur lång tid API-anropen tog) och ActionTime (hur lång tid åtgärderna tog att utföra). Skickar du dessa värden vidare till CloudWatch eller ett annat övervakningssystem får du en trendlinje över tid: minskar antalet matchade resurser för en viss policy vecka för vecka betyder det att teamen faktiskt fixar grundorsaken, inte bara symptomen.

Steg 7 och 8: Hitta okrypterade S3-bucketar och öppna säkerhetsgrupper

Två av de vanligaste molnfelkonfigurationerna är publikt läsbara lagringsbucketar och säkerhetsgrupper som öppnar administrationsportar mot hela internet. Så här letar du efter S3-bucketar utan standardkryptering.

policies:
  - name: s3-missing-default-encryption
    resource: aws.s3
    filters:
      - not:
          - type: bucket-encryption
            state: true
    actions:
      - type: set-bucket-encryption
      - type: notify
        to: [[email protected]]
        transport:
          type: sns
          topic: arn:aws:sns:eu-north-1:123456789012:custodian-alerts

Observera att action set-bucket-encryption faktiskt ändrar resursen, den slår på standardkryptering direkt. Det är ett exempel på automatisk åtgärd, till skillnad från ren upptäckt. Nästa policy letar efter säkerhetsgrupper som exponerar port 22 (SSH) eller 3389 (RDP) mot 0.0.0.0/0, men nöjer sig med att tagga resursen i stället för att ändra den direkt, eftersom en ofrivillig regelborttagning kan ta ner en produktionstjänst.

policies:
  - name: sg-open-admin-ports
    resource: aws.security-group
    filters:
      - or:
          - type: ingress
            Ports: [22]
            Cidr: "0.0.0.0/0"
          - type: ingress
            Ports: [3389]
            Cidr: "0.0.0.0/0"
    actions:
      - type: mark-for-op
        op: remove-ingress-rule
        days: 3
      - type: notify
        to: [[email protected]]
        transport:
          type: sns
          topic: arn:aws:sns:eu-north-1:123456789012:custodian-alerts

Action mark-for-op ger teamet tre dagars varseltid innan regeln automatiskt tas bort, vilket är en bra standardrytm för regler som rör produktionstrafik.

Samma mönster går att återanvända för andra klassiska fel: publika ögonblicksbilder av RDS-databaser, EBS-snapshots som delats med “alla” i stället för ett specifikt konto, eller IAM-användare med aktiva åtkomstnycklar äldre än 90 dagar. Skriver du en gång ett robust filter för “offentligt åtkomlig” går det ofta att återanvända samma struktur mot flera resurstyper, bara med olika resource-värde och motsvarande fält i filtret.

Steg 9: Automatisk notifiering och taggning av avvikande resurser

Notifieringar är limmet mellan upptäckt och åtgärd. Cloud Custodians notify-action stödjer flera transportlager, bland annat SNS, SQS och e-post direkt via SES. Du kan också kombinera notifiering med taggning, så att ägaren till resursen syns direkt i molnkonsolen.

actions:
  - type: tag
    tags:
      custodian-finding: "open-admin-port"
      custodian-detected: now
  - type: notify
    subject: "[Custodian] Öppen admin-port upptäckt i {region}"
    to:
      - [email protected]
    transport:
      type: sns
      topic: arn:aws:sns:eu-north-1:123456789012:custodian-alerts

Ett vanligt misstag är att skicka en notifiering per matchad resurs utan att samla ihop dem, vilket snabbt dränker ett säkerhetsteam i hundratals separata mail under en incident med många avvikande resurser. Gruppera i stället notifieringar per policy-körning och lägg en tydlig rubrik, så blir det hanterbart även när en policy matchar femtio resurser samtidigt.

Steg 10: Händelsedriven exekvering med AWS Lambda i realtid

Poll-läge, där Custodian periodiskt skannar hela kontot, är standardläget och fungerar bra för daglig eller timvis granskning. Men mot Microsofts siffra om 5,3 timmar till första attack mot exponerade resurser räcker periodisk skanning sällan till. Lösningen är att deploya policyn som en egen AWS Lambda-funktion som triggas direkt av ett CloudTrail-event.

policies:
  - name: realtime-sg-open-port
    resource: aws.security-group
    mode:
      type: cloudtrail
      events:
        - source: ec2.amazonaws.com
          event: AuthorizeSecurityGroupIngress
          ids: "requestParameters.groupId"
      role: arn:aws:iam::123456789012:role/CustodianLambdaRole
    filters:
      - type: ingress
        Ports: [22]
        Cidr: "0.0.0.0/0"
    actions:
      - type: remove-ingress-rule
      - type: notify
        to: [[email protected]]
        transport:
          type: sns
          topic: arn:aws:sns:eu-north-1:123456789012:custodian-alerts

Deploy sker med samma custodian run-kommando. Custodian upptäcker automatiskt mode: cloudtrail och provisionerar Lambda-funktionen, IAM-rollen och EventBridge-regeln åt dig. Dokumentationens riktlinjer rekommenderar att “treat the policy files as code, similar to that of Terraform or CloudFormation files”, vilket gäller ännu starkare för Lambda-policyer eftersom en felaktig deploy kan skapa dubbla eller motstridiga funktioner i kontot. AWS egna Open Source Blog har beskrivit samma mönster, att flytta efterlevnadskontroller och automatisk åtgärd rakt in i molnkontots händelseflöde, snarare än att hantera dem som ett fristående kontrollsteg vid sidan av infrastrukturen.

Verklighetsscenario: från öppen port till stängd regel på tolv minuter

Så här ser flödet ut i praktiken när policyn från steg 10 är live. En utvecklare lägger till en ny ingress-regel på en säkerhetsgrupp för att felsöka ett produktionsproblem och glömmer att begränsa källan till sin egen IP-adress, utan skriver av misstag 0.0.0.0/0 på port 22. Inom några sekunder loggar CloudTrail händelsen AuthorizeSecurityGroupIngress. EventBridge-regeln som Custodian satte upp i steg 10 fångar händelsen och triggar Lambda-funktionen direkt.

Lambda-funktionen körs, utvärderar filtret, ser att porten och käll-CIDR matchar, och kör actionen remove-ingress-rule. Samtidigt går en notifiering till säkerhetsteamets Slack-kanal via SNS, med information om vilken säkerhetsgrupp, vilket konto och vilken användare som skapade regeln (hämtat från CloudTrail-händelsens userIdentity-fält). Hela kedjan, från det att regeln skapades till att den togs bort och teamet notifierades, tar normalt under en minut i körning, men i praktiken brukar organisationer räkna med fördröjning i form av Lambda cold starts och SNS-leverans, vilket ger en realistisk totaltid på runt tio till tolv minuter inklusive att utvecklaren hinner se notifieringen och förstå vad som hände. Jämför det med Microsofts uppmätta 5,3 timmar i snitt innan en exponerad resurs attackeras, och marginalen blir uppenbar.

Steg 11: Schemalagd körning och multi-konto med c7n-org

De flesta företag har fler än ett AWS-konto, ofta ett per team eller miljö. Att köra custodian run manuellt mot varje konto skalar inte. Tillägget c7n-org löser det genom att köra samma policyuppsättning mot en hel lista av konton parallellt.

pip install c7n-org

# accounts.yml
accounts:
  - name: prod-se
    account_id: "111111111111"
    role: arn:aws:iam::111111111111:role/CustodianCrossAccount
  - name: staging-se
    account_id: "222222222222"
    role: arn:aws:iam::222222222222:role/CustodianCrossAccount

# Kör alla policyer i mappen mot alla konton
c7n-org run -c accounts.yml -s out -u policies/aws/ --cache-period 0

För schemalagd körning utan Lambda räcker ett vanligt cronjobb eller en pipeline-trigger i GitLab CI, GitHub Actions eller Jenkins. En rimlig standardfrekvens är var 4-6 timme för kritiska säkerhetsregler och en gång per dygn för kostnads- och governance-regler som inte är tidskritiska.

Steg 12 och 13: Policyer för Azure och Google Cloud

Cloud Custodian är inte begränsat till AWS. Azure-providern installeras som ett separat paket och använder samma YAML-struktur, men med Azure Event Grid som motsvarighet till CloudTrail för händelsedriven exekvering.

pip install c7n-azure
export AZURE_SUBSCRIPTION_ID="din-prenumerations-id"

policies:
  - name: azure-storage-no-https
    resource: azure.storage
    filters:
      - type: value
        key: properties.supportsHttpsTrafficOnly
        value: false

Google Cloud-stödet, paketet c7n-gcp, låg på version 0.4.52 (släppt 1 oktober 2026) vid den här artikelns publicering och versionshanteras separat från huvudpaketet. GCP-policyer använder Audit Logs och Pub/Sub för händelser i stället för CloudTrail eller Event Grid.

Ett praktiskt tips för organisationer som kör flera moln samtidigt är att hålla policy-namnen konsekventa över molnen, till exempel storage-encryption-required i både AWS-, Azure- och GCP-mapparna, även om den faktiska YAML-syntaxen skiljer sig åt mellan leverantörerna. Det gör det mycket enklare att bygga en gemensam efterlevnadsrapport som visar status “per kontrollpunkt” snarare än “per moln”, vilket är det format de flesta säkerhetschefer faktiskt vill se i en styrgruppsrapport.

pip install c7n-gcp
export GOOGLE_CLOUD_PROJECT="mitt-projekt-id"

custodian run --output-dir=out policies/gcp/custodian.yml

Tabellen nedan sammanfattar skillnaderna mellan de tre molnen när det gäller händelsedriven exekvering i Cloud Custodian.

Moln	Providerpaket	Händelsekälla	Vanligaste poll-intervallet
AWS	c7n (inbyggt)	CloudTrail / EventBridge	4-6 timmar
Azure	c7n-azure	Azure Event Grid	6-12 timmar
Google Cloud	c7n-gcp (0.4.52)	Audit Logs / Pub/Sub	6-12 timmar

Strukturera policyer som kod: Git, CI/CD och c7n-left

Cloud Custodian-dokumentationen rekommenderar uttryckligen att hantera policyfiler i Git med samma disciplin som annan infrastrukturkod, med granskning via pull request innan en ändring går i produktion. Ett repo brukar delas upp per moln och miljö, till exempel policies/aws/prod/ och policies/aws/staging/, så att en policy som är tänkt att vara strikt i produktion inte av misstag appliceras på en testmiljö där den stör utvecklarnas arbete.

Ett extra verktyg värt att nämna är c7n-left, som kör Custodian-liknande policyer mot Terraform-filer innan de ens har applicerats. Det flyttar kontrollen till vänster i utvecklingsflödet (därav namnet “left”) och stoppar en felkonfiguration innan resursen över huvud taget skapas. En enkel GitHub Actions-pipeline kan se ut så här.

name: custodian-check
on: [pull_request]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install c7n
      - run: custodian validate policies/aws/**/*.yml
      - run: custodian run --dryrun -s out policies/aws/**/*.yml

Pipelinen kör både validering och dry-run vid varje pull request, vilket fångar syntaxfel och oväntade matchningar innan en kodgranskare ens öppnar filen.

Vem som får godkänna en ändring i en policyfil är värt att bestämma tidigt. En rimlig modell är att låta utvecklare i vilket team som helst föreslå nya policyer eller justeringar via pull request, men kräva godkännande från säkerhets- eller plattformsteamet innan merge, särskilt för policyer som kör destruktiva actions i produktion. Det håller kvaliteten uppe utan att göra säkerhetsteamet till en flaskhals för varje litet justering av ett filtervärde.

Cloud Custodian för kostnadsstyrning, inte bara säkerhet

Säkerhet är den mest uppenbara användningen, men samma motor används lika ofta för att hålla nere molnkostnader. Bortglömda EBS-volymer som inte längre är kopplade till en instans, elastiska IP-adresser som ingen använder, eller testmiljöer som körs dygnet runt trots att de bara behövs kontorstid, är alla exempel på kostnader som byggs upp tyst i bakgrunden. En policy för att hitta och tagga lösa EBS-volymer äldre än 30 dagar kan se ut så här.

policies:
  - name: unattached-ebs-volumes
    resource: aws.ebs
    filters:
      - type: value
        key: Attachments
        value: []
      - type: value
        key: CreateTime
        op: greater-than
        value_type: age
        value: 30
    actions:
      - type: mark-for-op
        op: delete
        days: 14
      - type: notify
        to: [[email protected]]
        transport:
          type: sns
          topic: arn:aws:sns:eu-north-1:123456789012:custodian-cost-alerts

Den här typen av regel är i praktiken identisk med en säkerhetspolicy, bara med andra filter och en annan mottagare. Det är en av de stora fördelarna med att centralisera både säkerhets- och kostnadsregler i samma verktyg: samma team, samma granskningsflöde via Git, och samma output-format att bygga rapporter från, oavsett om syftet är att stoppa en attack eller att sänka nästa månads faktura.

Ett vanligt mönster är att låta FinOps-teamet äga sin egen undermapp i samma Git-repo, till exempel policies/aws/finops/, med en separat SNS-mottagare och en lugnare varseltid på 14 dagar i stället för de 3 dagar en säkerhetspolicy ofta använder. Det gör att kostnadsregler kan rulla ut i sin egen takt utan att blockera eller blockeras av säkerhetsteamets mer akuta ärenden, samtidigt som båda delar samma verktyg, samma CI-pipeline och samma granskningsrutin.

Så skiljer Cloud Custodian sig från Prowler, ScoutSuite och Steampipe

Molnsäkerhetsverktygslådan 2026 är full av alternativ, och det är lätt att blanda ihop dem. Verktyg som Prowler och ScoutSuite är i grunden skanners: de läser av kontot, jämför mot ett regelset och lämnar en rapport. Steampipe tar ett liknande angreppssätt men gör det genom att exponera molnresurser som SQL-tabeller, vilket är kraftfullt för ad-hoc-frågor men kräver att du själv bygger logiken för vad som ska hända med resultatet.

Cloud Custodian skiljer sig genom att åtgärden är en förstaklassens del av policyn, inte ett separat steg du bygger ovanpå rapporten. Där ett skanningsverktyg svarar på frågan “vad är fel”, svarar Cloud Custodian på “vad är fel, och vad ska vi göra åt det, automatiskt, nästa gång det händer igen”. I praktiken använder många team flera av verktygen parallellt: en skanner för periodisk, bred inventering och efterlevnadsrapportering, och Cloud Custodian för de regler där man faktiskt vill att en åtgärd sker utan mänsklig inblandning.

Vanliga nybörjarfel som saboterar din Cloud Custodian-installation

De flesta problem med Cloud Custodian i produktion kommer inte från verktyget självt, utan från hur policyerna är skrivna och testade innan de rullas ut brett. Nedan är de misstag som oftast dyker upp när ett team går från ett första lyckat test till en installation som faktiskt täcker hela organisationen.

Köra skarpa actions utan dry-run först. En policy som ser korrekt ut på pappret kan matcha tusen resurser i stället för tre om ett filter är fel skrivet. Kör alltid --dryrun innan du tar bort flaggan.
För breda IAM-rättigheter. Att ge Custodian administratörsåtkomst “för säkerhets skull” gör varje policyfel potentiellt katastrofal. Bygg rättigheterna policy för policy istället.
Glömma att policyer körs per region. AWS-resurser är regionbundna, och en policy som bara körs mot eu-north-1 missar helt resurser i eu-west-1. Loopa över alla relevanta regioner explicit.
Ingen versionskontroll av policyfiler. Utan Git-historik går det inte att se vem som ändrade en regel, när eller varför, vilket gör felsökning efter en incident betydligt svårare.
Fel logik i filter-block. Att blanda ihop and och or i nästlade filter är den vanligaste orsaken till att en policy matchar noll resurser eller alldeles för många.
Notifiering utan gruppering. Att skicka ett separat mail per matchad resurs under en stor incident skapar varningströtthet som gör att verkliga larm ignoreras.
Blanda ihop test- och produktionspolicyer i samma fil. En policy som är avsedd att bara varna i en testmiljö kan av misstag också radera resurser i produktion om kontolistan i accounts.yml inte är strikt uppdelad per miljö.

Felsökning: vanliga problem och lösningar

När något inte beter sig som förväntat är felet oftast ett av ett fåtal återkommande mönster. Innan du misstänker en bugg i själva verktyget, gå igenom listan nedan, den täcker merparten av de supportfrågor som dyker upp i Cloud Custodians community-kanaler.

Problem	Trolig orsak	Lösning
“AccessDenied” vid körning	IAM-identiteten saknar rättigheter som policyns actions kräver	Lägg till exakt de behörigheter felmeddelandet anger, en i taget
Policy validerar men matchar 0 resurser	Fel region angiven, eller fel resurstyp i `resource`-fältet	Kontrollera `AWS_DEFAULT_REGION` och jämför resurstypen mot dokumentationens lista
Dry-run visar resurser, skarp körning gör inget	Action saknas eller har fel syntax i YAML-filen	Kör `custodian validate` igen efter att du lagt till actions, felet syns oftast direkt
Lambda-policy deployas men triggas aldrig	Fel händelsenamn i `mode.events` eller saknad EventBridge-regel	Verifiera händelsenamnet i CloudTrail-loggen för den faktiska API-anropet
“RequestLimitExceeded” eller throttling	För hög anropsfrekvens mot molnets API vid stora konton	Minska `--max-workers` eller lägg till cache med `--cache`
c7n-org kraschar på stora kontolistor	Minnesbrist när alla konton körs parallellt	Kör i mindre batcher med flaggan `--accounts-concurrency`
Notify-action skickar inget mail	SNS-ämnets policy tillåter inte publicering, eller SES är i sandbox-läge	Kontrollera SNS-ämnets resource policy och SES-kontots sändningsstatus
Policy fungerar i en region men inte en annan	Tjänsten eller resurstypen stöds inte i den regionen	Kontrollera AWS:s regionala tjänstlista innan du antar att policyn är trasig
“Credentials not found” i Azure eller GCP	Miljövariabler som `AZURE_SUBSCRIPTION_ID` eller `GOOGLE_CLOUD_PROJECT` är inte satta	Exportera variablerna i samma skal du kör `custodian` från

Avancerade tips och ett komplett färdigt projekt

När grundflödet fungerar finns några förbättringar som gör en installation produktionsredo snarare än bara en demo. Använd c7n-left för att skanna Terraform-planer innan apply, så att kostsamma eller riskfyllda resurser aldrig hinner skapas. Kombinera Custodian-policyer med AWS Config för att få historisk efterlevnadsdata över tid, inte bara ett ögonblicksbild. Och sätt alltid en tag-action före en destruktiv action som terminate eller delete, så att ett team hinner invända innan resursen faktiskt försvinner.

Rulla ut nya, destruktiva policyer stegvis snarare än mot alla konton samtidigt. Börja med ett enda, lågriskkonto (till exempel en sandlåda eller en intern testmiljö) i en vecka eller två, läs igenom varje notifiering som policyn genererar, och bredda sedan gradvis till fler konton i accounts.yml när du är säker på att filtren träffar rätt. Den stegvisa utrullningen kostar lite extra tid i början, men den tiden är försumbar jämfört med att av misstag stänga ner en produktionstjänst för hela organisationen samtidigt.

Lägg också in ett undantag för resurser som medvetet bryter mot regeln. En tagg som custodian-exempt: true, kombinerad med ett filter som exkluderar taggade resurser, gör att team kan begära ett godkänt undantag i stället för att policyn och verkligheten hamnar i en ständig konflikt. Det är ofta skillnaden mellan ett regelverk som efterlevs och ett som utvecklare lär sig att kringgå.

Till sist, skriv en kort runbook per policy, gärna direkt i README-filen bredvid YAML-filen. En rad om vad regeln letar efter, en rad om varför den finns, och en rad om vad en utvecklare ska göra om de får en notifiering. Det låter som ett litet steg, men det är precis den dokumentationen som gör skillnaden mellan ett regelverk nya teammedlemmar litar på och ett de är rädda för att röra.

Ett komplett, färdigt projekt för ett mindre säkerhetsteam brukar se ut ungefär så här i repo-struktur.

custodian-policies/
├── policies/
│   ├── aws/
│   │   ├── prod/
│   │   │   ├── encrypted-ebs.yml
│   │   │   ├── s3-encryption.yml
│   │   │   └── sg-open-ports.yml
│   │   └── staging/
│   │       └── sg-open-ports.yml
│   ├── azure/
│   │   └── storage-https.yml
│   └── gcp/
│       └── custodian.yml
├── accounts.yml
├── .github/
│   └── workflows/
│       └── custodian-check.yml
├── Makefile
└── README.md

En Makefile knyter ihop vanliga kommandon så att hela teamet kör exakt samma flaggor varje gång.

validate:
	custodian validate policies/aws/**/*.yml

dryrun:
	custodian run --dryrun -s out policies/aws/prod/*.yml

deploy:
	c7n-org run -c accounts.yml -s out -u policies/aws/prod/

Med den strukturen går det att lägga till en ny molnregel, skicka en pull request, låta CI validera och dry-runa den, och sedan merge:a med vetskapen om exakt vilka resurser som påverkas, samma arbetssätt som redan gäller för resten av infrastrukturkoden.

Vanliga frågor om Cloud Custodian

Är Cloud Custodian gratis att använda?

Ja. Cloud Custodian är ett öppen källkod-projekt som ligger under Apache 2.0-licensen och går att installera och köra utan kostnad. Det enda du betalar för är den molninfrastruktur verktyget själv kör på, till exempel Lambda-anrop vid händelsedriven exekvering.

Fungerar Cloud Custodian med Kubernetes?

Cloud Custodians kärnfokus ligger på molnens kontrollplan, alltså AWS, Azure och GCP, snarare än på resurser inuti ett Kubernetes-kluster. För klusterinterna kontroller används vanligtvis andra verktyg, medan Custodian fortfarande kan granska det underliggande molnkontot kluster körs i, till exempel nätverks- och IAM-konfiguration. Många team som kör hanterade Kubernetes-tjänster som EKS eller AKS använder därför Custodian för att granska det omgivande molnkontot, medan ett separat klusterverktyg tar hand om det som händer inne i klustret självt.

Kan Cloud Custodian ersätta AWS Config?

De kompletterar snarare än ersätter varandra. AWS Config ger historisk konfigurationsdata och inbyggda regler, medan Cloud Custodian ger större flexibilitet i hur regler skrivs och framför allt i vilka actions som sker automatiskt när en avvikelse hittas. Många team kör båda tillsammans.

Hur ofta bör policyer köras?

Kritiska säkerhetsregler, som öppna administrationsportar eller publika lagringsbucketar, bör köras händelsedrivet via Lambda eller minst var 4-6 timme via poll-läge. Kostnads- och governance-regler som inte är tidskritiska klarar sig ofta med en körning per dygn.

Behöver Cloud Custodian ett dedikerat konto?

Det är inget krav, men rekommenderas i större organisationer. Ett dedikerat säkerhetskonto med en cross-account-roll till övriga konton gör det enklare att centralisera loggning och undvika att Custodians egna rättigheter blandas ihop med applikationsteamens. För mindre bolag med bara ett eller två konton räcker det ofta att köra Custodian direkt i det kontot, och lägga till ett dedikerat konto först när organisationen växer.

Vad är skillnaden mellan c7n och c7n-org?

c7n är huvudpaketet som kör policyer mot ett enda konto åt gången. c7n-org är ett tilläggsverktyg som kör samma policyuppsättning mot en hel lista av konton parallellt, vilket är nödvändigt så snart en organisation har fler än ett eller två AWS-, Azure- eller GCP-konton.

Stödjer Cloud Custodian Terraform-filer direkt?

Huvudpaketet c7n granskar redan existerande, körande resurser i molnet. För att granska Terraform-kod innan den har applicerats används det separata verktyget c7n-left, som använder en liknande policy-syntax men körs mot Terraform-planer snarare än mot ett levande molnkonto.

Är det säkert att låta Cloud Custodian ta automatiska actions i produktion?

Det beror helt på hur policyn är skriven. Börja alltid med enbart notifiering och taggning i produktion, och gå över till direkt borttagande eller ändring av resurser först när teamet har sett policyn köra stabilt under en period, och gärna med en fördröjning som mark-for-op ger innan den slutgiltiga åtgärden sker.

Kan Cloud Custodian sänka molnkostnader, inte bara förbättra säkerheten?

Ja, det är ett av de vanligaste användningsfallen utöver säkerhet. Policyer som hittar bortglömda EBS-volymer, oanvända elastiska IP-adresser eller testmiljöer som körs utanför kontorstid används flitigt av FinOps-team, med exakt samma validerings- och dry-run-flöde som säkerhetsregler.

Cloud Custodian: Autofixa Molnfel i 13 Steg, 90 Min [2026]