IaC-skanning: En fantastisk, oversett læringsmulighet

Alt du leser om infrastruktur som kode (IaC) er fokusert på hvordan det fungerer eller hvorfor du vil forsikre deg om at det faktisk bygger slik du vil at det skal bygges.

Dette er kritiske områder. Men tenker vi nok på hvordan vi bruker denne tilnærmingen i organisasjonen vår?

As Melinda Marks fra ESG uttaler i en selskapsrapport, "83 % av organisasjonene opplevde en økning i feilkonfigurasjoner av IaC-maler" mens de fortsetter å ta i bruk teknologien.

Vi vet fra arbeid utført av Cloud Security Alliance (“Topptrusler mot Cloud Computing: Egregious Eleven“) og andre, feilkonfigurasjoner fortsetter å være en topprisiko i skyen.

IaC støttes til redusere
feilkonfigurasjoner ved å systematisere etableringen av infrastruktur, legge til et nivå av strenghet og prosess som sikrer at teamene bygger det de vil og bare det de vil. Hvis ~83 % av lagene ikke ser det, er det et dypere problem på spill.

På mindre team, et der Dev- og Ops-delene av DevOps-filosofien er sammen, er det fornuftig. IaC lar disse små teamene bruke samme språk – kode – for å beskrive alt de gjør.

Dette er grunnen til at vi ser abstraksjoner på enda høyere nivå enn verktøy som Terraform eller AWS CloudFormation i AWS CDK og prosjekter som cdk8s. Disse abstraksjonene på høyt nivå er mer komfortable for utviklere.

Et ops/SRE/plattform-perspektiv for en skytjeneste vil være veldig forskjellig fra et utviklerperspektiv for samme tjeneste. En utvikler vil se på en køtjeneste og dykke ned i grensesnittet – et enkelt endepunkt å legge til og ett å lese? Solgt. Det er en enkel integrering.

Dette operasjonelle perspektivet har som mål å finne kantene. Så når når denne køen sin grense? Er ytelsen konstant eller endres den radikalt under belastning?

Ja, det er overlappende bekymringer. Og ja, dette er et forenklet syn. Men ideen holder. IaC løser mange problemer, men det kan også skape og forsterke frakoblingen mellom teamene. Enda viktigere, det kan fremheve gapet mellom intensjonen med det du prøver å bygge og virkeligheten til det du har bygget.

Som et resultat er det her sikkerhetsbekymringene ofte eskalerer.

De fleste verktøy – kommersiell eller åpen kildekode – er fokusert på å identifisere ting som er galt med infrastrukturmalene. Dette
er en god konstruksjon. Lager denne
ville vært dårlig. Disse verktøyene tar sikte på å generere disse resultatene som en del av pipeline for kontinuerlig integrasjon/kontinuerlig levering (CI/CD).

Det er en flott start. Men det gjenspeiler det samme språkproblemet.

Hvem snakker og hvem lytter?

Når et IaC-verktøy fremhever et problem, hvem vil løse det? Hvis det er utviklingsteamet, har det nok informasjon til å vite hvorfor dette ble flagget som et problem? Hvis det er operasjonsteamet, er konsekvensene av problemet nedfelt i rapporten?

For utviklere er det som ofte skjer at de ganske enkelt vil justere konfigurasjonen for å få IaC-testingen til å bestå.

For operasjoner er det vanligvis et spørsmål om prøvene består. Hvis de er det, så videre til neste oppgave. Det er ikke en bank på noen av lagene; snarere fremhever det gapet mellom forventninger og virkelighet.

Det som trengs er kontekst. IaC-sikkerhetsverktøy gir innsyn i det som (forhåpentligvis) skal bygges. Målet er å stoppe problemer før du de kommer i produksjon.

Dagens IaC-sikkerhetsverktøy fremhever virkelige problemer som må løses. Å ta utdataene fra disse verktøyene og berike den med ekstra kontekst som er spesifikk for teamet som er ansvarlig for koden, er en perfekt mulighet for litt tilpasset automatisering.

Dette vil også bidra til å bygge bro over språkgapet. Resultatet fra verktøyet ditt er i hovedsak på et tredje språk – bare for å gjøre ting mer komplisert – og må kommuniseres på en måte som gir mening for enten et utviklings- eller driftspublikum. Ofte begge deler.

For eksempel, når en skanning flagger at en sikkerhetsgrupperegel ikke har en beskrivelse, hvorfor betyr det noe? Bare det å få et varsel som sier «Legg til en beskrivelse for kontekst» hjelper ingen å bygge bedre.

Denne typen flagg er en flott mulighet til å utdanne teamene som bygger i skyen. Å legge til en forklaring om at sikkerhetsgrupperegler bør være så spesifikke som mulig, reduserer muligheten for ondsinnede angrep. Gi referanser til eksempler på sterke regler. Ring det uten å vite intensjonen, og andre team kan ikke teste gyldigheten av sikkerhetsbekreftelsen.

Sikkerhet er alles ansvar, så å erkjenne språkgapet mellom utviklere og drift vil fremheve muligheter som dette for å legge til enkle automatiseringer som gir innsikt til teamene dine. Dette vil bidra til å forbedre det de bygger og vil som et resultat gi bedre sikkerhetsresultater.

om forfatteren

Jeg er en rettsmedisiner, foredragsholder og teknologianalytiker som prøver å hjelpe deg med å forstå den digitale verdenen og dens innvirkning på oss. For hverdagsbrukere hjelper arbeidet mitt med å forklare hvilke utfordringer den digitale verden har. Hvor stor innvirkning har bruk av sosiale medier på personvernet ditt? Hva betyr det når teknologier som ansiktsgjenkjenning begynner å bli brukt i våre lokalsamfunn? Jeg hjelper deg med å svare på spørsmål som dette og mer. For folk som bygger teknologi, hjelper jeg dem med å bruke en sikkerhets- og personvernlinse i arbeidet sitt, slik at de kan gjøre det mulig for brukere å ta klarere avgjørelser om informasjonen og oppførselen deres. Det er et fjell av forvirring når det kommer til personvern og sikkerhet. Det burde ikke være. Jeg gjør sikkerhet og personvern lettere å forstå.