IaC-scanning: En fantastisk, overset læringsmulighed

Alt, hvad du læser om infrastruktur som kode (IaC) er fokuseret på, hvordan det fungerer, eller hvorfor du vil sikre dig, at det faktisk bygger, som du vil have det til at bygge.

Det er kritiske områder. Men tænker vi nok over, hvordan vi bruger denne tilgang i vores organisation?

As Melinda Marks fra ESG udtaler i en virksomhedsrapport, "83 % af organisationerne oplevede en stigning i IaC-skabelonfejlkonfigurationer", da de fortsætter med at adoptere teknologien.

Vi ved fra arbejde udført af Cloud Security Alliance (“Toptrusler mod cloud computing: Egregious Eleven“) og andre, er fejlkonfigurationer fortsat en toprisiko i skyen.

IaC er understøttet til reducere
fejlkonfigurationer ved at systematisere oprettelsen af ​​infrastruktur, tilføje et niveau af stringens og proces, der sikrer, at teams bygger det, de vil have, og kun det, de ønsker. Hvis ~83 % af holdene ikke ser det, er der et dybere problem på spil.

På mindre hold, et hvor Dev- og Ops-delene af DevOps-filosofien er sammen, giver det mening. IaC giver disse små teams mulighed for at bruge det samme sprog - kode - til at beskrive alt, hvad de laver.

Det er derfor, vi ser abstraktioner på endnu højere niveau end værktøjer som Terraform eller AWS CloudFormation i AWS CDK og projekter som cdk8s. Disse abstraktioner på højt niveau er mere behagelige for udviklere.

Et ops/SRE/platform perspektiv for en cloud-tjeneste vil være meget anderledes fra et udviklerperspektiv af den samme tjeneste. En udvikler vil se på en køtjeneste og dykke ned i dens grænseflade - et enkelt slutpunkt at tilføje og et at læse? Solgt. Det er en nem integration.

Dette operationelle perspektiv har til formål at finde kanterne. Så hvornår når denne kø sin grænse? Er ydelsen konstant eller ændrer den sig radikalt under belastning?

Ja, der er overlappende bekymringer. Og ja, dette er en forenklet opfattelse. Men ideen holder. IaC løser en masse problemer, men det kan også skabe og forstærke afbrydelsen mellem teams. Endnu vigtigere kan det fremhæve kløften mellem intentionen med det, du forsøger at bygge, og virkeligheden af ​​det, du har bygget.

Som følge heraf er det her, sikkerhedsproblemerne ofte eskalerer.

Det meste værktøj - kommercielt eller open source - er fokuseret på at identificere ting, der er galt med infrastrukturskabelonerne. Denne
er en god konstruktion. Fremstilling denne
ville være dårligt. Disse værktøjer sigter mod at generere disse resultater som en del af pipeline for kontinuerlig integration/kontinuerlig levering (CI/CD).

Det er en god start. Men det afspejler det samme sprogspørgsmål.

Hvem taler og hvem lytter?

Når et IaC-værktøj fremhæver et problem, hvem vil så løse det? Hvis det er udviklingsteamet, har det så nok information til at vide, hvorfor dette blev markeret som et problem? Hvis det er operationsteamet, er konsekvenserne af problemet så beskrevet i rapporten?

For udviklere er det, der ofte sker, at de simpelthen vil justere konfigurationen for at få IaC-testen til at bestå.

For operationer er det typisk et spørgsmål om, hvorvidt prøverne består. Hvis de er, så videre til næste opgave. Det er ikke et slag på begge hold; snarere fremhæver den forskellen mellem forventninger og virkelighed.

Det, der er brug for, er kontekst. IaC-sikkerhedsværktøj giver overblik over, hvad der (forhåbentlig) skal bygges. Målet er at stoppe problemer før de kommer i produktion.

Dagens IaC-sikkerhedsværktøj fremhæver virkelige problemer, der skal løses. At tage outputtet fra disse værktøjer og berige det med yderligere kontekst, der er specifik for det team, der er ansvarlig for koden, er en perfekt mulighed for noget tilpasset automatisering.

Dette vil også være med til at bygge bro over sprogkløften. Outputtet fra dit værktøj er i det væsentlige på et tredje sprog - bare for at gøre tingene mere komplicerede - og skal kommunikeres på en måde, der giver mening for enten et udviklings- eller et driftspublikum. Ofte begge dele.

For eksempel, når en scanning markerer, at en sikkerhedsgrupperegel ikke har en beskrivelse, hvorfor betyder det så noget? Bare det at få en advarsel, der siger "Tilføj en beskrivelse til kontekst", hjælper ikke nogen med at bygge bedre.

Denne type flag er en fantastisk mulighed for at uddanne de hold, der bygger i skyen. Tilføjelse af en forklaring om, at sikkerhedsgruppereglerne skal være så specifikke som muligt, reducerer muligheden for ondsindede angreb. Giv referencer til eksempler på stærke regler. Ring det uden at kende hensigten, og andre teams kan ikke teste gyldigheden af ​​sikkerhedsbekræftelsen.

Sikkerhed er alles ansvar, så anerkendelse af sproggabet mellem udviklere og operationer vil fremhæve muligheder som denne for at tilføje simple automatiseringer, der giver indsigt til dine teams. Dette vil hjælpe med at forbedre det, de bygger, og som et resultat vil det føre til bedre sikkerhedsresultater.

Om forfatteren

Jeg er retsmediciner, foredragsholder og teknologianalytiker, der prøver at hjælpe dig med at forstå den digitale verden og dens indflydelse på os. For hverdagsbrugere hjælper mit arbejde med at forklare, hvad der er udfordringer i den digitale verden. Hvor stor en indflydelse har brugen af ​​sociale medier på dit privatliv? Hvad betyder det, når teknologier som ansigtsgenkendelse begynder at blive brugt i vores lokalsamfund? Jeg hjælper med at besvare spørgsmål som dette og mere. For mennesker, der bygger teknologi, hjælper jeg dem med at anvende en sikkerheds- og privatlivslinse på deres arbejde, så de kan sætte brugere i stand til at træffe klarere beslutninger om deres information og adfærd. Der er et bjerg af forvirring, når det kommer til privatliv og sikkerhed. Det burde der ikke være. Jeg gør sikkerhed og privatliv lettere at forstå.