IaC szkennelés: fantasztikus, figyelmen kívül hagyott tanulási lehetőség

Minden, amit az infrastruktúráról mint kódról (IaC) olvas, a működésére összpontosít, vagy arra, hogy miért szeretne megbizonyosodni arról, hogy valóban úgy épül fel, ahogyan szeretné.

Ezek kritikus területek. De vajon eleget gondolunk-e arra, hogyan alkalmazzuk ezt a megközelítést szervezetünkben?

As Marks Melinda Az ESG egy vállalati jelentésben kijelenti, hogy „a szervezetek 83%-a tapasztalta az IaC sablon hibás konfigurációinak növekedését”, miközben folytatják a technológia átvételét.

A Cloud Security Alliance által végzett munkából tudjuk (“A felhőalapú számítástechnika legfőbb veszélyei: Egregious Eleven“) és mások, a hibás konfiguráció továbbra is a legnagyobb kockázatot jelenti a felhőben.

Az IaC támogatott csökkenteni
hibás konfigurációkat az infrastruktúra létrehozásának rendszerezésével, olyan szigor és folyamat hozzáadásával, amely biztosítja, hogy a csapatok azt építsék fel, amit akarnak, és csak azt, amit akarnak. Ha a csapatok ~83%-a ezt nem látja, akkor egy mélyebb probléma van a játékban.

Kisebb csapatoknál, ahol a DevOps filozófia Dev és Ops részei együtt vannak, ennek van értelme. Az IaC lehetővé teszi ezeknek a kis csapatoknak, hogy ugyanazt a nyelvet – kódot – használják minden tevékenységük leírására.

Ezért látunk még magasabb szintű absztrakciókat, mint az olyan eszközök, mint a Terraform vagy az AWS CloudFormation. AWS CDK és hasonló projektek cdk8s. Ezek a magas szintű absztrakciók kényelmesebbek a fejlesztők számára.

Egy felhőszolgáltatás művelet/SRE/platform perspektívája merőben különbözik ugyanazon szolgáltatás fejlesztői perspektívájától. A fejlesztő megnézi a sorban állási szolgáltatást, és belemerül annak felületébe – egy egyszerű végpontot hozzáadhat és olvasnivalót? Eladott. Ez egy könnyű integráció.

Ez a működési perspektíva az élek megtalálását célozza. Szóval, mikor éri el ez a sor a határt? A teljesítmény állandó, vagy terhelés hatására gyökeresen megváltozik?

Igen, vannak átfedő aggodalmak. És igen, ez egy leegyszerűsített nézet. De az ötlet tart. Az IaC sok problémát megold, de létrehozhatja és felerősítheti a megszakadást a csapatok között. Ennél is fontosabb, hogy rávilágíthat arra a szakadékra, amely az építési szándék szándéka és az általad épített valóság között van.

Ennek eredményeként a biztonsági aggodalmak gyakran itt fokozódnak.

A legtöbb eszköz – kereskedelmi vagy nyílt forráskódú – az infrastruktúra-sablonokkal kapcsolatos hibás dolgok azonosítására összpontosít. Ezt
jó konstrukció. készítése ezt
rossz lenne. Ezek az eszközök a folyamatos integráció/folyamatos szállítás (CI/CD) folyamat részeként kívánják előállítani ezeket az eredményeket.

Ez egy nagyszerű kezdet. De ugyanazt a nyelvi problémát visszhangozza.

Ki beszél és ki hallgat?

Ha egy IaC-eszköz rávilágít egy problémára, ki foglalkozik vele? Ha a fejlesztőcsapatról van szó, elegendő információval rendelkezik ahhoz, hogy tudja, miért jelölték meg ezt problémaként? Ha a műveleti csapatról van szó, a probléma következményei szerepelnek a jelentésben?

A fejlesztők számára gyakran az történik, hogy egyszerűen módosítják a konfigurációt, hogy az IaC tesztelése sikeres legyen.

A műveleteknél jellemzően az a kérdés, hogy sikeresek-e a tesztek. Ha igen, akkor folytassa a következő feladattal. Ez egyik csapatnál sem kopogtat; inkább az elvárások és a valóság közötti szakadékot emeli ki.

Amire szükség van, az a kontextus. Az IaC biztonsági eszközök rálátást biztosítanak arra, hogy mi készül (remélhetőleg). A cél a problémák megállítása előtt termelésbe kerülnek.

A mai IaC biztonsági eszközök olyan valós problémákra hívják fel a figyelmet, amelyekkel foglalkozni kell. Ezen eszközök kimenetének átvétele és a kódért felelős csapatra jellemző további kontextusokkal való gazdagítás tökéletes alkalom az egyéni automatizálásra.

Ez is segít áthidalni a nyelvi szakadékot. A szerszámok kimenete lényegében egy harmadik nyelven van – csak hogy bonyolultabbá tegyük a dolgokat –, és úgy kell közölni, hogy az értelmes legyen akár a fejlesztési, akár a műveleti közönség felé. Gyakran mindkettőt.

Például, ha a vizsgálat azt jelzi, hogy egy biztonsági csoportszabályhoz nincs leírás, miért számít ez? Csak a „Adjon hozzá leírást a kontextushoz” üzenetet kapva senki sem segít jobbá tenni.

Ez a fajta zászló nagyszerű lehetőség a felhőben épülő csapatok oktatására. Azzal a magyarázattal, hogy a biztonsági csoportszabályoknak a lehető legpontosabbaknak kell lenniük, csökkenti a rosszindulatú támadások lehetőségét. Adjon hivatkozásokat erős szabályok példáira. Hívja ezt a szándék ismerete nélkül, és más csapatok nem tudják tesztelni a biztonsági megerősítés érvényességét.

A biztonság mindenki felelőssége, ezért a fejlesztők és a műveletek közötti nyelvi szakadék elismerése rávilágít az ehhez hasonló lehetőségekre, amelyek segítségével egyszerű automatizálásokat adhatunk, amelyek betekintést nyújtanak a csapatok számára. Ez elősegíti az általuk épített fejlesztések javítását, és ennek eredményeként jobb biztonsági eredményeket eredményez.

A szerzőről

Törvényszéki szakértő, előadó és technológiai elemző vagyok, és próbálok segíteni, hogy megértsd a digitális világot és annak ránk gyakorolt ​​hatását. A mindennapi felhasználók számára munkám segít elmagyarázni, milyen kihívásokat jelent a digitális világ. Milyen nagy hatással van a közösségi média használata a magánéletére? Mit jelent, ha az olyan technológiákat, mint az arcfelismerés, elkezdik használni közösségeinkben? Segítek válaszolni az ehhez hasonló és még sok más kérdésre. A technológiát építő embereknek segítek abban, hogy biztonsági és adatvédelmi objektívet alkalmazzanak munkájuk során, hogy lehetővé tegyék a felhasználók számára, hogy egyértelműbb döntéseket hozzanak információikkal és viselkedésükkel kapcsolatban. Hatalmas zűrzavar uralkodik a magánélettel és a biztonsággal kapcsolatban. Nem szabadna. Könnyebben érthetővé teszem a biztonságot és a magánélet védelmét.