Når IT-afdelingen bygger servere, netværk, roller og lagerplads fra skabeloner i stedet for at klikke dem op i hånden, ændrer det betydningen af et fund. En svaghed i et cloudmiljø, der er bygget fra kode, er ikke nødvendigvis en enkeltstående fejl. Den er en linje i en skabelon, og den findes derfor alle de steder, skabelonen er brugt. En penetrationstest tester ikke skabelonerne direkte, men den finder fejlene i det, skabelonerne har bygget. Svaret på titlens spørgsmål er derfor, at testen kan pege på skabelonerne, og at rettelsen skal ind dér for at holde.
Hvad infrastruktur som kode betyder for driften
Microsoft beskriver infrastruktur som kode som en måde at definere netværk, virtuelle maskiner og forbindelser i versionsstyrede filer, så den samme beskrivelse giver det samme miljø hver gang. Formålet er at undgå, at miljøer glider fra hinanden, fordi de er sat op i hånden. I stedet for at ændre i miljøet ændrer man i beskrivelsen og udruller igen.
For sikkerheden er det både en fordel og en risiko. Fordelen er, at en god opsætning gentages trofast. Risikoen er, at en dårlig opsætning gentages lige så trofast, og at en rettelse i det kørende miljø forsvinder ved næste udrulning.
Hvordan et testfund peger på en skabelon
Testeren ser det færdige miljø, ikke koden. Fundet beskriver derfor fx en rolle med for brede rettigheder, en netværksregel, der er åben for alle, eller et lagerområde med offentlig adgang. Det er driftens opgave at finde ud af, om fundet stammer fra en skabelon. Tre spørgsmål hjælper:
- Er ressourcen bygget fra kode? · eller er den oprettet eller ændret i hånden bagefter?
- Hvilken skabelon kom den fra? · og hvor ellers er samme skabelon brugt?
- Er fejlen i skabelonen eller i de værdier, den fik? · samme skabelon kan give forskellige resultater med forskellige indstillinger.
Svaret afgør, hvor rettelsen skal ske. Har testeren fundet fejlen i ét miljø, findes den måske i både test, produktion og hos andre afdelinger, der bruger samme skabelon. → Rettigheder i AWS
Hvad I kan bede testen om
En almindelig penetrationstest afprøver miljøet. Hvis I bruger infrastruktur som kode, kan I gøre testen mere nyttig ved at give testeren adgang til skabelonerne som baggrund. Det gør det lettere at vurdere, hvor udbredt et fund er, og hvilke fund der hænger sammen.
Det kan også være relevant at få gennemgået skabelonerne selv. Det er nærmere en gennemgang af opsætningen end en penetrationstest, og det giver bredde, mens afprøvningen af miljøet giver dybde. De to supplerer hinanden. → Konfigurationsgennemgang eller penetrationstest af cloud
Tre ting skal afklares, før testeren får adgang til skabelonerne:
- Hemmeligheder · ligger der adgangskoder eller nøgler i skabelonerne eller deres historik, er det et fund i sig selv. → Nøgler og hemmeligheder i cloud
- Læseadgang · testeren skal kunne læse, men ikke ændre eller udrulle.
- Afgrænsning · hvilke skabeloner der hører til de miljøer, testen omfatter.
Fundtyper, der kan stamme fra skabeloner
- Åbne netværksregler · en regel, der blev skrevet bredt for at komme i gang, og som nu findes i alle miljøer.
- Brede roller · tilladelser, der er kopieret fra et eksempel og aldrig indsnævret.
- Manglende logning eller kryptering · fordi skabelonen ikke slår det til, og ingen har tilføjet det.
- Testmiljøer, der ligner produktion for meget · samme adgange og nogle gange samme data, men svagere overvågning.
- Miljøer, der er glidet væk fra skabelonen · nogen har rettet i hånden, og miljøet ligner ikke længere beskrivelsen.
Den sidste fundtype er vigtig at kende. Hvis miljøet ikke svarer til skabelonen, kan en rettelse i skabelonen enten overskrive en bevidst ændring eller lade en fejl stå.
Rettelser, der holder
Rettelser i et miljø bygget fra kode skal ind i koden. Ellers bliver de overskrevet. Microsoft beskriver netop princippet om at ændre i beskrivelsen og ikke i målet. → Gør rettelserne permanente
- Ret skabelonen · og genudrul de miljøer, der bruger den, i en planlagt rækkefølge.
- Tjek de andre brugere af skabelonen · fundet gælder sandsynligvis også dér.
- Indfør sikre standardværdier · så nye miljøer bygges med den strammere opsætning fra start.
- Kontrollér skabelonerne før udrulning · fx med automatiske kontroller af kendte fejl i opsætningen.
- Hold øje med afvigelser · så ændringer i hånden opdages og enten føres tilbage i koden eller fjernes.
En akut rettelse i det kørende miljø kan være nødvendig, hvis fundet er alvorligt. Men den skal følges op af en rettelse i skabelonen, ellers er den kun midlertidig. Registrer begge dele i opgavesystemet, så den ene ikke lukkes uden den anden. → Fra fund til opgave
Når skabelonerne ejes af en anden
Skabelonerne er ikke altid IT-afdelingens egne. En driftsleverandør kan have bygget miljøet fra sit eget bibliotek af skabeloner, eller en udviklingsafdeling kan stå for dem, mens IT står for driften. Så ligger rettelsen hos en anden end den, der modtager rapporten.
Afklar før testen, hvem der ejer skabelonerne, og hvem der må ændre dem. Er det leverandøren, så spørg, om samme skabelon bruges hos andre kunder. Et fund hos jer kan være et fund hos flere, og leverandøren har en interesse i at rette det ét sted. Aftal også, hvordan en rettelse i skabelonen godkendes og udrulles, så den følger den normale ændringsstyring og ikke bliver en hastesag uden for processen. → Rettelser uden at stoppe driften
Er skabelonerne versionsstyret, kan I bagefter se, hvornår den fejlbehæftede linje kom ind, og hvilke miljøer der er bygget siden. Det gør det lettere at vurdere, hvor langt fundet rækker. Historikken viser også, om fejlen kom ind ved en bevidst ændring, der havde en begrundelse, eller ved en kopi fra et eksempel, som ingen gennemgik. Den forskel betyder noget for, hvordan I undgår den næste.
Det skal I lade være med
- At rette i miljøet og ikke i koden. Rettelsen forsvinder ved næste udrulning.
- At rette ét miljø og glemme resten. Samme skabelon har bygget flere.
- At give testeren skriveadgang til skabelonerne. Læseadgang er nok.
- At lade hemmeligheder ligge i koden. De bliver i historikken, også når de slettes.
- At antage, at miljøet ligner skabelonen. Ændringer i hånden er almindelige.
Hvad kan og ikke kan konkluderes
En penetrationstest af et miljø bygget fra kode viser, hvordan det færdige miljø holdt på testtidspunktet. Den kan ikke i sig selv vise, at skabelonerne er fejlfri, og en skabelon, der ikke er brugt i de testede miljøer, er ikke dækket. Til gengæld giver den driften et konkret grundlag for at rette i skabelonerne, så den samme fejl ikke kommer igen i de næste miljøer.
Kilder
- Microsoft Learn: What is infrastructure as code (IaC)?: definition af infrastruktur som kode, at den samme beskrivelse giver det samme miljø, problemet med miljøer, der glider fra hinanden, og princippet om at ændre i beskrivelsen og ikke i målet.
- Microsoft Learn: Security best practices for IaaS workloads in Azure: skabeloner til at mindske variation i opsætningen af virtuelle maskiner og til at genudrulle dem i opdateret form.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Containere og Kubernetes i driften · Nøgler og hemmeligheder i cloud
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
