IaC-skanning: En fantastisk, förbisedd inlärningsmöjlighet

Allt du läser om infrastruktur som kod (IaC) är fokuserat på hur det fungerar eller varför du vill försäkra dig om att det faktiskt bygger som du vill att det ska byggas.

Dessa är kritiska områden. Men tänker vi tillräckligt mycket på hur vi använder detta tillvägagångssätt i vår organisation?

As Melinda Marks från ESG konstaterar i en företagsrapport, "83 % av organisationerna upplevde en ökning av felkonfigurationer av IaC-mall" när de fortsätter att använda tekniken.

Vi vet från arbete utfört av Cloud Security Alliance (“Topphoten mot Cloud Computing: Egregious Eleven“) och andra, fortsätter felkonfigurationer att vara en stor risk i molnet.

IaC stöds till minska
felkonfigurationer genom att systematisera skapandet av infrastruktur, lägga till en nivå av rigoritet och process som säkerställer att team bygger vad de vill ha och bara vad de vill. Om ~83 % av lagen inte ser det, finns det en djupare fråga på spel.

I mindre team, ett där Dev- och Ops-delarna av DevOps-filosofin är tillsammans, är det vettigt. IaC tillåter dessa små team att använda samma språk – kod – för att beskriva allt de gör.

Det är därför vi ser abstraktioner på ännu högre nivå än verktyg som Terraform eller AWS CloudFormation i AWS CDK och projekt som cdk8s. Dessa abstraktioner på hög nivå är mer bekväma för utvecklare.

Ett ops/SRE/plattformsperspektiv för en molntjänst kommer att vara väldigt annorlunda från ett utvecklarperspektiv för samma tjänst. En utvecklare kommer att titta på en kötjänst och dyka in i dess gränssnitt — en enkel slutpunkt att lägga till och en att läsa? Såld. Det är en enkel integration.

Detta verksamhetsperspektiv syftar till att hitta kanterna. Så när når denna kö sin gräns? Är prestandan konstant eller förändras den radikalt under belastning?

Ja, det finns överlappande bekymmer. Och ja, detta är en förenklad uppfattning. Men tanken håller. IaC löser många problem, men det kan också skapa och förstärka kopplingen mellan team. Ännu viktigare, det kan belysa klyftan mellan avsikten med det du försöker bygga och verkligheten av det du har byggt.

Som ett resultat är det här som säkerhetsproblemen ofta eskalerar.

De flesta verktyg – kommersiella eller öppen källkod – är fokuserade på att identifiera saker som är fel med infrastrukturmallarna. Denna
är en bra konstruktion. Tillverkning detta
skulle vara dåligt. Dessa verktyg syftar till att generera dessa resultat som en del av pipeline för kontinuerlig integration/kontinuerlig leverans (CI/CD).

Det är en bra början. Men det återspeglar samma språkfråga.

Vem pratar och vem lyssnar?

När ett IaC-verktyg lyfter fram ett problem, vem ska ta itu med det? Om det är utvecklingsteamet, har det tillräckligt med information för att veta varför detta flaggades som ett problem? Om det är operationsteamet, anges konsekvenserna av frågan i rapporten?

För utvecklare är det som ofta händer att de helt enkelt kommer att justera konfigurationen för att få IaC-testet att passera.

För operationer handlar det vanligtvis om om proven är godkända. Om de är det, gå vidare till nästa uppgift. Det är inte en knock på något av lagen; snarare belyser det skillnaden mellan förväntningar och verklighet.

Vad som behövs är sammanhang. IaC-säkerhetsverktyg ger insyn i vad som (förhoppningsvis) är på väg att byggas. Målet är att stoppa problem innan de kommer i produktion.

Dagens IaC-säkerhetsverktyg belyser verkliga problem som måste åtgärdas. Att ta utdata från dessa verktyg och berika det med ytterligare sammanhang som är specifikt för teamet som ansvarar för koden är ett perfekt tillfälle för lite anpassad automatisering.

Detta kommer också att hjälpa till att överbrygga språkklyftan. Resultatet från dina verktyg är i huvudsak på ett tredje språk - bara för att göra saker mer komplicerade - och måste kommuniceras på ett sätt som är vettigt för antingen en utvecklings- eller verksamhetspublik. Ofta båda.

Till exempel, när en skanning flaggar att en säkerhetsgruppregel inte har en beskrivning, varför spelar det någon roll? Bara att få en varning som säger "Lägg till en beskrivning för sammanhang" hjälper inte någon att bygga bättre.

Den här typen av flagga är ett utmärkt tillfälle att utbilda teamen som bygger i molnet. Att lägga till en förklaring om att säkerhetsgruppsregler ska vara så specifika som möjligt minskar möjligheten för skadliga attacker. Ge referenser till exempel på starka regler. Ring det utan att veta avsikten, och andra team kan inte testa giltigheten av säkerhetsbekräftelsen.

Säkerhet är allas ansvar, så att erkänna språkgapet mellan utvecklare och verksamheter kommer att lyfta fram möjligheter som denna att lägga till enkla automatiseringar som ger insikter till dina team. Detta kommer att bidra till att förbättra det de bygger och, som ett resultat, kommer att leda till bättre säkerhetsresultat.

Om författaren

Jag är en kriminaltekniker, talare och teknikanalytiker som försöker hjälpa dig att förstå den digitala världen och dess inverkan på oss. För vardagliga användare hjälper mitt arbete att förklara vilka utmaningar den digitala världen har. Hur stor inverkan har användningen av sociala medier på din integritet? Vad betyder det när tekniker som ansiktsigenkänning börjar användas i våra samhällen? Jag hjälper till att svara på frågor som denna och mer. För människor som bygger teknik hjälper jag dem att använda en säkerhets- och integritetslins i sitt arbete, så att de kan göra det möjligt för användare att fatta tydligare beslut om sin information och sitt beteende. Det finns ett berg av förvirring när det kommer till integritet och säkerhet. Det borde inte finnas. Jag gör säkerhet och integritet lättare att förstå.