Det intressanta med Infrastructure as Code är hur snabbt teori möter drift: en kontroll måste fungera även när systemet uppdateras, felsöks och utsätts för fel. Infrastructure as Code gör moln- och nätverkskonfiguration granskningsbar före deployment, vilket skapar en naturlig plats för policykontroller och diffbaserad säkerhetsreview.
Infrastructure as Code i praktiken
Första byggstenen: Plan-output visar avsedd förändring innan den sker. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
En annan viktig del: State kan innehålla känslig data och behöver skyddas. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det tekniska ankaret: Moduler bör versionspinnas för reproducerbarhet. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det som ofta avgör kvaliteten: Policy-as-code kan stoppa riskabla resurser tidigt. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Så skulle jag testa det i en riktig miljö
- Håll IaC i versionskontroll med review.
- Skanna kod och plan efter publika exponeringar och bred IAM.
- Skydda remote state med stark accesskontroll.
- Separera miljöer och credentials.
- Kräv explicit planreview för känsliga ändringar.
För Infrastructure as Code håller jag därför införandet i små steg. Då går det att skilja ett säkerhetsproblem från ett rent driftfel och att rulla tillbaka just den ändring som gav ett oväntat resultat.
Praktiskt exempel
En storage-resurs som råkar bli publik bör helst stoppas i plansteget. Då blir incidenten en misslyckad pipeline i stället för en exponerad resurs som senare måste upptäckas externt.
Misstag som skapar falsk trygghet
- Att lagra secrets direkt i tfvars i repo.
- Att ge CI-kontot ägarbehörighet till hela cloudmiljön.
- Att applicera manuella ändringar utanför IaC så att drift uppstår.
Verifiering före stängning
För Infrastructure as Code vill jag avsluta med mätbara efterkontroller i stället för att nöja mig med att en statusruta visar ”enabled”. De viktigaste kontrollerna här är:
- Planen visar inga oväntade publika endpoints.
- State kan inte läsas av vanliga utvecklarkonton.
- Drift detection fångar manuella ändringar.
Ett negativt test hör också till Infrastructure as Code: den väg, identitet eller operation som inte ska vara tillåten ska misslyckas på ett förutsägbart sätt. Då kan nästa tekniker upprepa kontrollen och förstå både avsikten och gränsen.
Slutsats
Infrastructure as Code – säkerhetsgranska Terraform och liknande innan deploy handlar därför inte om att samla fler säkerhetsinställningar. Det handlar om att minska en konkret risk med en kontroll som har tydligt scope, tydlig ägare och ett verifierbart resultat. När före-läge, förändring och eftertest dokumenteras blir säkerhetsarbetet både säkrare och lättare att förvalta.