Säkerhetsskanning av infrastruktur som kod

Verktyg för Infrastructure as Code (IaC), som Terraform, AWS CloudFormation, Ansible och Helm, gör det möjligt att definiera infrastruktur i versionshanterade konfigurationsfiler. Detta medför stora fördelar – repeterbarhet, granskningsbarhet och automatisering – men också en kritisk säkerhetsrisk: felkonfigurationer i IaC-filer skapar osäker infrastruktur i stor skala. En enda felkonfigurerad Terraform-modul som driftsätts i 50 miljöer skapar 50 sårbara system samtidigt. Säkerhetsskanning av IaC hanterar detta genom att kontrollera konfigurationsfiler innan de tillämpas och på så sätt flytta säkerheten tidigare i utvecklarens arbetsflöde.

Säkerhetsskanningsverktyg letar efter de vanligaste IaC-felkonfigurationerna som finns i verkliga molnmiljöer: S3-buckets med offentlig åtkomst aktiverad eller utan kryptering i vila; säkerhetsgrupper med inkommande regler från 0.0.0.0/0 på känsliga portar (22, 3389, 1433); databaser utan kryptering eller med offentlig åtkomst; IAM-policyer med resurs- eller åtgärdsjokertecken som *; CloudTrail inaktiverat i en region; KMS-nycklar utan nyckelrotation; samt lastbalanserare med HTTP-lyssnare i stället för HTTPS. Dessa fynd motsvarar i hög grad kontrollerna i molnsäkerhetsriktlinjer som CIS AWS Foundations.

Checkov (från Bridgecrew/Prisma Cloud) är ett populärt verktyg för statisk analys av IaC med öppen källkod som stöder Terraform, CloudFormation, Kubernetes-manifest, Helm-diagram och Dockerfiler. Det levereras med över 1 000 inbyggda policyer som är kopplade till riktlinjerna CIS, GDPR, SOC 2 och HIPAA. När checkov -d . körs genomsöks alla IaC-filer i den aktuella katalogen och en färgkodad rapport skapas med godkända, misslyckade och överhoppade kontroller samt resurssökvägar och vägledning för åtgärder. Checkov kan integreras i CI/CD-pipelines för att blockera distributioner när kritiska kontroller misslyckas.

tfsec (numera en del av Trivys IaC-skanningsfunktion) är en specialiserad säkerhetsskanner för Terraform som har djup förståelse för HCL-syntax, vilket gör att den kan spåra värden mellan moduler och variabelfiler. Till skillnad från enklare skannrar kan tfsec upptäcka felkonfigurationer där problemet sträcker sig över flera filer – exempelvis en säkerhetsgruppsregel som verkar säker isolerat men är kopplad till en resurs i en annan fil. tfsec genererar fynd med allvarlighetsnivåer (CRITICAL, HIGH, MEDIUM, LOW), CWE-ID:n och direkta länkar till dokumentation om åtgärder, vilket gör fynden användbara för utvecklare.

Ett av de mest kritiska säkerhetsproblemen i IaC är hårdkodade hemligheter i konfigurationsfiler – lösenord, API-nycklar, privata TLS-nycklar och databasanslutningssträngar som läggs in i Git. Eftersom IaC-arkiv ofta delas mellan team och lagras i versionshistorik är en hemlighet som har lagts in ens en enda gång i praktiken permanent röjd (Git-historik är oföränderlig). Verktyg som Checkov, detect-secrets, git-secrets och TruffleHog söker efter mönster som identifierar hemligheter. Lösningen är att använda indatavariabler som hämtas från miljövariabler eller hemlighetslagringar, aldrig hårdkodade värden.

Ramverk för Policy as Code (PaC) gör det möjligt för säkerhetsteam att skriva anpassade regler i kod och tillämpa dem konsekvent. Open Policy Agent (OPA) med Conftest gör det möjligt att skriva Rego-policyer som validerar strukturerade data av alla slag – Terraform-planer, Kubernetes-manifest och Helm-värden – i CI/CD-pipelines. HashiCorp Sentinel är inbyggt i Terraform Enterprise och Cloud och gör det möjligt att tillämpa policyer som ”alla S3-buckets måste ha kryptering aktiverad” redan vid planeringen, så att alla apply-åtgärder som skulle bryta mot policyn blockeras. Dessa verktyg gör det möjligt att uttrycka säkerhetskrav som kod och versionshantera dem tillsammans med den infrastruktur de styr.

Konfigurationsdrift uppstår när det faktiska tillståndet för distribuerad infrastruktur avviker från IaC-definitionen – ofta för att någon har gjort en manuell ändring via molnkonsolen. En regel i en säkerhetsgrupp som manuellt lagts till för att ”tillfälligt” ge en utvecklare åtkomst blir ett permanent säkerhetsgap. Verktyg för driftdetektering jämför kontinuerligt det önskade tillståndet (IaC-filerna) med det faktiska distribuerade tillståndet och varnar vid avvikelser. AWS Config, Terraform Clouds driftdetektering och CSPM-verktyg (Prisma Cloud, Wiz) erbjuder alla denna funktion. Felkonfigurationer som införs genom ändringar i konsolen upptäcks innan angripare hittar dem.

Oföränderlig infrastruktur innebär att servrar och konfigurationer aldrig ändras på plats – i stället skapar ändringar nya resurser (nya AMI:er, nya containeravbildningar) som ersätter de gamla. Tillsammans med GitOps (där alla infrastrukturändringar måste gå via en pull request i Git, vilket utlöser arbetsflöden för IaC-skanning och godkännande) eliminerar detta konfigurationsdrift genom sin konstruktion: om något inte kan ändras manuellt kan det inte heller drifta. Verktyg som ArgoCD för Kubernetes och Atlantis för Terraform implementerar GitOps-arbetsflöden där alla avvikelser utlöser automatisk återställning till önskat tillstånd eller en varning.

Säkerhetsskanning av IaC förväxlas ibland med SAST (Static Application Security Testing), men de analyserar olika typer av artefakter. SAST analyserar programmets källkod (Python, Java, JavaScript) för sårbarheter som SQL-injektion eller buffertspill. IaC-skanning analyserar konfigurationsfiler för infrastruktur och söker efter felkonfigurationer som påverkar molnsäkerheten – ingen programkod berörs. En komplett DevSecOps-pipeline innehåller båda: SAST på applikationskod och IaC-skanning på infrastrukturfiler. Båda körs i CI/CD innan någon distribution sker. Vissa enhetliga plattformar (Snyk IaC, Prisma Cloud) kombinerar skanning av applikationer och infrastruktur i ett enda verktyg.

Effektiv IaC-säkerhetsskanning måste vara automatiserad och obligatorisk – inte valfri. En typisk CI/CD-integration ser ut så här: kör Checkov och tfsec vid varje pull request; misslyckas med pipelinen om det finns CRITICAL-fynd; publicera fynd som kommentarer i pull requesten så att utvecklarna ser dem; underhåll en lista över undertryckta fynd med dokumenterade motiveringar; och kör en nattlig skanning av distribuerade resurser för att upptäcka drift. Pre-commit-hookar med verktyg som pre-commit och Checkov kan upptäcka problem redan innan koden når pipelinen. Det är viktigt att hantera falska positiva resultat – utvecklare som ser för många irrelevanta fynd börjar ignorera dem.

Terraforms state-fil (terraform.tfstate) innehåller en fullständig förteckning över alla hanterade resurser och ofta även känsliga utdatavärden som databaslösenord, privata TLS-nycklar och ID:n för IAM-åtkomstnycklar i klartext. State-filer får aldrig läggas in i Git. Använd i stället en fjärrbackend (AWS S3 med låsning via DynamoDB, Terraform Cloud eller GitLab-hanterad state) med serverkryptering aktiverad. Åtkomsten till state-backenden måste strikt styras via IAM – alla som kan läsa state-filen kan kartlägga alla infrastrukturelement och potentiellt extrahera inbäddade hemligheter.

I den här lektionen har du lärt dig följande: felkonfigurationer i IaC, som offentliga S3-buckets, öppna säkerhetsgrupper och hårdkodade hemligheter, upptäcks automatiskt av verktyg som Checkov och tfsec före distribution; ramverk för Policy as Code (OPA/Conftest, HashiCorp Sentinel) gör det möjligt att tillämpa anpassade säkerhetskrav för organisationen som automatiserade spärrar i pipelinen; och Terraform state-filer måste lagras i krypterade fjärrbackends med strikt åtkomstkontroll eftersom de kan innehålla känsliga uppgifter om resurser. Nästa avsnitt handlar om APT-livscykeln och hur avancerade hot upprätthåller sin närvaro i nätverk.