Sikkerhetsskanning av Infrastructure as Code

Infrastructure as Code (IaC)-verktøy som Terraform, AWS CloudFormation, Ansible og Helm gjør det mulig å definere infrastruktur i versjonskontrollerte konfigurasjonsfiler. Dette gir enorme fordeler – repeterbarhet, revisjonssporbarhet og automatisering – men også en kritisk sikkerhetsrisiko: feilkonfigureringer i IaC-filer produserer usikker infrastruktur i stor skala. Én feilkonfigurert Terraform-modul som distribueres i 50 miljøer, oppretter 50 sårbare systemer samtidig. IaC-sikkerhetsskanning håndterer dette ved å kontrollere konfigurasjonsfiler før de tas i bruk, slik at sikkerheten flyttes til et tidligere trinn i utviklerarbeidsflyten.

Sikkerhetsskanningsverktøy ser etter de vanligste IaC-feilkonfigureringene som finnes i virkelige skymiljøer: S3-bucketer med offentlig tilgang aktivert eller uten kryptering i hvile; sikkerhetsgrupper med innkommende regler fra 0.0.0.0/0 på sensitive porter (22, 3389, 1433); databaser uten kryptering eller med offentlig tilgjengelighet; IAM-policyer med jokertegnene * for ressurser eller handlinger; CloudTrail deaktivert i en region; KMS-nøkler uten nøkkelrotasjon; og lastbalansere med HTTP-lyttere i stedet for HTTPS. Disse funnene samsvarer i stor grad med kontrollene som utføres av sikkerhetsstandarder for skytjenester, for eksempel CIS AWS Foundations.

Checkov (fra Bridgecrew/Prisma Cloud) er et populært verktøy for statisk analyse av IaC med åpen kildekode, og støtter Terraform, CloudFormation, Kubernetes-manifester, Helm-diagrammer og Docker-filer. Det leveres med over 1 000 innebygde policyer som er knyttet til CIS-referanseverdier, GDPR, SOC 2 og HIPAA. Når De kjører checkov -d ., skannes alle IaC-filer i gjeldende katalog, og det genereres en fargekodet rapport over kontroller som er bestått, mislykket eller hoppet over, med ressursstier og veiledning for utbedring. Checkov kan integreres i CI/CD-pipelines for å blokkere utrullinger når kritiske kontroller mislykkes.

tfsec (nå en del av Trivys funksjonalitet for IaC-skanning) er en spesialutviklet sikkerhetsskanner for Terraform som har inngående forståelse av HCL-syntaks, slik at den kan spore verdier på tvers av moduler og variabelfiler. I motsetning til enklere skannere kan tfsec oppdage feilkonfigurasjoner der problemet går på tvers av flere filer – for eksempel en sikkerhetsgrupperegel som ser trygg ut isolert, men er koblet til en ressurs i en annen fil. tfsec genererer funn med alvorlighetsnivåer (CRITICAL, HIGH, MEDIUM, LOW), CWE-ID-er og direkte lenker til dokumentasjon om utbedring, slik at utviklere kan iverksette tiltak basert på funnene.

Et av de mest kritiske sikkerhetsproblemene i IaC er hardkodede hemmeligheter i konfigurasjonsfiler – passord, API-nøkler, private TLS-nøkler og tilkoblingsstrenger til databaser som er lagret i Git. Ettersom IaC-repositorier ofte deles mellom team og lagres i versjonskontrollhistorikken, er en hemmelighet som lagres én eneste gang, i praksis permanent kompromittert (Git-historikken kan ikke endres). Verktøy som Checkov, detect-secrets, git-secrets og TruffleHog skanner etter mønstre for hemmeligheter. Løsningen er å bruke inndatavariabler som hentes fra miljøvariabler eller hemmelighetslagre, og aldri hardkodede verdier.

Rammeverk for Policy as Code (PaC) gjør det mulig for sikkerhetsteam å skrive egendefinerte regler i kode og håndheve dem på en konsekvent måte. Open Policy Agent (OPA) med Conftest gjør det mulig å skrive Rego-policyer som validerer strukturerte data av enhver type – Terraform-planer, Kubernetes-manifester og Helm-verdier – i CI/CD-pipelines. HashiCorp Sentinel er innebygd i Terraform Enterprise og Cloud, og gjør det mulig å håndheve policyer som «alle S3-bøtter må ha kryptering aktivert» ved planlegging, slik at en apply som bryter med policyen, blokkeres. Disse verktøyene gjør det mulig å uttrykke sikkerhetskrav som kode og versjonskontrollere dem sammen med infrastrukturen de styrer.

Konfigurasjonsavvik oppstår når den faktiske tilstanden til utrullet infrastruktur avviker fra IaC-definisjonen – ofte fordi noen har gjort en manuell endring via nettskykonsollen. En sikkerhetsgrupperegel som legges til manuelt for å «midlertidig» gi en utvikler tilgang, blir et permanent sikkerhetshull. Verktøy for avviksdeteksjon sammenligner kontinuerlig den ønskede tilstanden (IaC-filer) med den faktiske utrullede tilstanden og varsler om avvik. AWS Config, avviksdeteksjonen i Terraform Cloud og CSPM-verktøy (Prisma Cloud, Wiz) tilbyr alle denne funksjonaliteten. Sikkerhetsfeilkonfigurasjoner som oppstår gjennom endringer i konsollen, oppdages før angripere finner dem.

Uforanderlig infrastruktur betyr at servere og konfigurasjoner aldri endres på stedet. I stedet oppretter endringer nye ressurser (nye AMI-er, nye containerbilder) og erstatter de gamle. Kombinert med GitOps (der alle infrastrukturendringer må gå gjennom en pull request i Git, som utløser IaC-skanning og arbeidsflyter for godkjenning) eliminerer dette konfigurasjonsavvik gjennom selve utformingen: Hvis noe ikke kan endres manuelt, kan det heller ikke avvike. Verktøy som ArgoCD for Kubernetes og Atlantis for Terraform implementerer GitOps-arbeidsflyter der ethvert avvik utløser automatisk samsvar eller et varsel.

IaC-sikkerhetsskanning forveksles noen ganger med SAST (Static Application Security Testing), men de retter seg mot ulike artefakter. SAST analyserer kildekode for applikasjoner (Python, Java, JavaScript) for sårbarheter som SQL-injeksjon eller bufferoverflyt. IaC-skanning analyserer konfigurasjonsfiler for infrastruktur for sikkerhetsfeilkonfigurasjoner i nettskyen – ingen applikasjonskode er involvert. En komplett DevSecOps-pipeline omfatter begge deler: SAST av applikasjonskode og IaC-skanning av infrastrukturfiler. Begge kjøres i CI/CD før en utrulling. Enkelte enhetlige plattformer (Snyk IaC, Prisma Cloud) kombinerer skanning av applikasjoner og infrastruktur i ett verktøy.

Effektiv IaC-sikkerhetsskanning må være automatisert og håndhevet – ikke valgfri. En typisk CI/CD-integrering fungerer slik: Ved hver pull request kjøres Checkov og tfsec; pipelinen stoppes hvis det finnes funn med alvorlighetsgraden CRITICAL; funn publiseres som kommentarer i pull requesten slik at utviklerne blir oppmerksomme på dem; en liste over undertrykte funn vedlikeholdes med dokumenterte begrunnelser; og det kjøres en nattlig skanning av utrullede ressurser for å oppdage avvik. Pre-commit-kroker med verktøy som pre-commit og Checkov kan oppdage problemer før koden når pipelinen. Det er viktig å håndtere falske positive funn – utviklere som ser for mange irrelevante funn, begynner å ignorere dem.

Terraform sin tilstandsfil (terraform.tfstate) inneholder en fullstendig oversikt over alle administrerte ressurser, ofte også sensitiv informasjon fra output, for eksempel databasepassord, private TLS-nøkler og ID-er for IAM-tilgangsnøkler i klartekst. Tilstands-filer må aldri lagres i Git. Bruk i stedet en ekstern backend (AWS S3 med låsing via DynamoDB, Terraform Cloud eller GitLab-administrert tilstand) med kryptering på serversiden aktivert. Tilgang til tilstands-backenden må kontrolleres strengt gjennom IAM – alle som kan lese tilstandsfilen, kan kartlegge alle infrastrukturopplysninger og potensielt hente ut innebygde hemmeligheter.

I denne leksjonen har De lært at IaC-feilkonfigurasjoner som offentlige S3-bøtter, åpne sikkerhetsgrupper og hardkodede hemmeligheter automatisk oppdages av verktøy som Checkov og tfsec før utrulling, at rammeverk for policy som kode (OPA/Conftest, HashiCorp Sentinel) gjør det mulig å håndheve egendefinerte sikkerhetskrav i organisasjonen som automatiserte kontrollpunkter i pipelinen, og at Terraform-tilstandsfiler må lagres i krypterte eksterne backender med strenge tilgangskontroller, ettersom de kan inneholde sensitive ressursopplysninger. Neste gang utforsker vi livssyklusen til APT-er og hvordan avanserte trusler opprettholder tilstedeværelsen i nettverk.