IaC-säkerhet

Misconfiguration scanning analyserar IaC-filer efter mönster som är kända för att skapa säkerhetsrisker när de driftsätts. Scanningen körs mot Terraform HCL, CloudFormation YAML, Kubernetes-manifest och andra infrastrukturdefinitionsformat utan att köra någon driftsättning. Fynden representerar felkonfigurationer i koden som skulle bli live-säkerhetsbrister om de tillämpades.

De stora open source IaC-skanningsverktygen är Checkov, tfsec och KICS. Checkov stöder det bredaste utbudet av IaC-format med över 1 000 inbyggda kontroller och stöder anpassade policyer skrivna i Python eller YAML. tfsec är ett Terraform-fokuserat verktyg skrivet i Go som är tillräckligt snabbt för att köras vid varje spara i en utvecklares editor. KICS är ett open source-projekt av Checkmarx med bred formatsupport designad för CI-integrering.

Integrering av skannerverktyg i CI-pipelinen säkerställer att ingen IaC-ändring kan slås ihop utan att klara en grundläggande säkerhetskontroll. Skannern körs som ett pipelinesteg vid varje pull request och resultaten publiceras som PR-kommentarer eller pipelinestatuskontroller. Att ange en feltolerans förvandlar skannern från ett rådgivande verktyg till en verkställande gate.

Ett vanligt misstag är att bara köra IaC-scanning i CI och inte i utvecklarens lokala miljö. Utvecklare som bara ser skanningsresultat efter att ha pushat en commit får långsammare återkoppling. IDE-plugin och pre-commit hooks som kör skannern lokalt ger omedelbar återkoppling vid det tidigast möjliga tillfället. Samma regler bör gälla på båda ställena.

Policy as code uttrycker säkerhets- och styrningsregler som maskinexekverbar logik som kan köras automatiskt i pipelinen. I stället för att förlita sig på mänskliga granskare för att komma ihåg varje säkerhetskrav varje gång kodas reglerna en gång och tillämpas konsekvent. En policy som säger att alla S3-buckets måste ha server-side-kryptering aktiverad fångar den felkonfigurationen på varje PR.

Open Policy Agent (OPA) är den mest använda policyverktyget för infrastrukturpolicy. OPA använder Rego-språket för att uttrycka policyer som logiska regler. Conftest är ett verktyg som kapslar OPA och gör det enkelt att tillämpa Rego-policyer på strukturerade dataformat inklusive Terraform plan-utdata och Kubernetes YAML. HashiCorp Sentinel är ett liknande ramverk inbyggt i Terraform Cloud.

Bra policy as code är precis, läsbar och direkt kopplad till ett konkret säkerhets- eller compliance-krav. En policy bör specificera exakt vad den kontrollerar, varför kontrollen är viktig och hur en godkänd konfiguration ser ut. Vaga policyer som är svåra att uppfylla urholkar förtroendet för policysystemet.

Den mest effektiva användningen av policy as code i IaC-flöden är att tillämpa den vid både plan-tid och under PR-granskning. Att köra policyer mot plan-utdata fångar problem som uppstår från resursinteraktioner som inte är synliga i koden enbart. En policy som kontrollerar om någon IAM-policy beviljar wildcard-behörigheter är mer tillförlitlig när den körs mot plan-tidens representation.

Terraform state-filen innehåller mer känslig information än de flesta utövare inser. Den lagrar varje resurs-ID, ARN, IP-adress och attributvärde för varje resurs som Terraform förvaltar. En angripare med läsåtkomst till state-filen har en detaljerad karta över hela infrastrukturen och potentiellt de autentiseringsuppgifter som behövs för att komma åt den.

State måste lagras i en fjärrbackend med kryptering och strikt åtkomstkontroll. För AWS är standardmönstret en S3-bucket med server-side-kryptering, versionshantering aktiverat, publik åtkomst blockerad och en bucket-policy som bara tillåter CI/CD-rollen och utsågda operatörer att läsa eller skriva state. State-backenden bör inte vara tillgänglig från utvecklarlaptops.

Åtkomst till state bör följa minsta privilegium och granskas. CI/CD-pipelinen som kör terraform plan och apply behöver läs- och skrivåtkomst till state-backenden. Ingen bör ha åtkomst till state som de inte behöver. State-åtkomsthändelser bör loggas i CloudTrail eller motsvarande.

State-filexporter och nedladdningar är en vanlig källa till oavsiktlig exponering. Ingenjörer som kör terraform state pull för att inspektera state skapar en lokal kopia av en känslig fil. Dessa lokala kopior bör behandlas med samma omsorg som produktionsautentiseringsuppgifter och raderas omedelbart efter användning. Att committa en state-fil till ett git-repositorium bör behandlas som en säkerhetsincident.

Säkra standarder minskar risken att en ingenjör som skapar infrastruktur måste komma ihåg varje säkerhetsrelevant inställning på varje resurstyp. När plattformen, modulerna och mallarna tillhandahåller säkra standarder fokuserar ingenjören på affärskravet och säkerhetsegenskaperna hanteras automatiskt.

I praktiken implementeras säkra standarder på modulnivå. En delad modul för att skapa en S3-bucket bör ha kryptering aktiverat, publik åtkomst blockerad och loggning konfigurerad som standard. Om ett team behöver skapa en publik bucket skickar de ett explicit override till modulen. Det här mönstret gör det säkra valet till standard och det osäkra valet kräver avsiktlig åtgärd.

Cloud provider-tjänstekontrollpolicyer kan tillämpa standarder på konto- eller projektnivå, oberoende av IaC-konfiguration. En SCP som nekar att skapa okrypterade lagringsvolymer fungerar som ett säkerhetsnät även när IaC-scanning kringgås eller saknas. Att kombinera modulnivå-säkra standarder med kontopolsnivåpolicytillämpning skapar djupförsvar för infrastruktursäkerhet.

Ett vanligt misstag är att behandla säkra standarder som ett engångsbeslut. Molnleverantörer introducerar regelbundet nya tjänster och nya standardbeteenden. En modulbibliotek som var aktuellt för två år sedan kanske inte inkluderar kontroller för tjänster som introducerats sedan dess. Regelbunden granskning av modulbiblioteket mot aktuella säkerhetsriktlinjer är nödvändig.

Minsta privilegium i IaC-säkerhet innebär att varje identitet inblandad i IaC-flödet bara har de behörigheter den behöver för att utföra sitt specifika jobb. En CI-pipeline som kör terraform plan i en pull request-kontroll behöver läsåtkomst till state-backenden och möjligheten att anropa moln-API:er för att läsa befintliga resurskonfigurationer. Den behöver inte skrivåtkomst till någon molnresurs.

Överpermissiva IAM-roller för CI/CD-pipelines är en av de vanligaste och mest påverkningsfulla IaC-säkerhetsbristerna. En pipeline med AdministratorAccess kan, om den komprometteras, skapa godtyckliga resurser, exfiltrera data och ta bort produktionsinfrastruktur. Att begränsa CI/CD-behörigheter till minimum som krävs för den specifika konfigurationen eliminerar dessa risker.

Infrastrukturresurserna själva bör också följa minsta privilegium. IAM-roller tilldelade applikationsarbetslaster bör bara tillåta de specifika API-anrop som applikationen gör mot specifika resurser. Säkerhetsgrupper bör bara tillåta de portar och protokoll som applikationen använder. Dessa kontroller minskar skadeverkan av en komprometterad arbetsbelastning.

Least privilege-verkställning i IaC möjliggörs av policy as code. En policy som detekterar och avvisar IAM-policyer med Action: '*' eller Resource: '*' fångar de mest uppenbara överpermissionsmönstrena automatiskt. Verktyg som IAM Access Analyzer och Cloudsplaining kan analysera IAM-policyer i IaC-kod för överdrivna behörigheter och föreslå mer specifika ersättningar.

Guardrails är de kontroller som hindrar infrastrukturen från att glida in i osäkert territorium även när team rör sig snabbt och inte fokuserar på säkerhet. De skiljer sig från policyer och scanningsregler eftersom guardrails verkar på en högre abstraktionsnivå. De definierar gränserna inom vilka team kan verka fritt, snarare än att kontrollera individuella resurskonfigurationer.

Guardrails kan implementeras på flera nivåer. På modulnivå kan en modul tillämpa guardrails genom att vägra att skapa resurser utan specifika obligatoriska indata. På pipelinenivå kan ett policysteg blockera planer som inkluderar resurstyper utanför det godkända kuvertet. På molnkontonivå kan tjänstekontrollpolicyer förhindra hela kategorier av osäker konfiguration. Kombinationen av alla tre nivåer skapar ett skiktat säkerhetssystem.

Effektiva guardrails är utformade för att vara fasta men transparenta. Ingenjörer bör förstå varför en guardrail finns, vad den förhindrar och vad den godkända vägen framåt är. En guardrail som blockerar legitimt arbete utan att ge en tydlig lösningsväg driver team att hitta omvägar. Tydlig dokumentation av varje guardrail och en lättviktig undantagsprocess gör systemet troVärdigt.

Guardrail-täckning bör växa i takt med organisationens molnfotavtryck. Att börja med de mest påverkningsfulla kontrollerna och lägga till kontroller progressivt är mer hållbart än att försöka hantera varje möjlig felkonfiguration på en gång. En guardrail som inte är välförstådd eller som utlöses vid många legitima konfigurationer kommer att inaktiveras eller ignoreras.