IaC skeniranje: fantastična, spregledana priložnost za učenje

Vse, kar preberete o infrastrukturi kot kodi (IaC), je osredotočeno na to, kako deluje ali zakaj želite zagotoviti, da se dejansko gradi tako, kot želite.

To so kritična področja. Toda ali dovolj razmišljamo o tem, kako ta pristop uporabljamo v naši organizaciji?

As Melinda Marks iz ESG v poročilu podjetja navaja, da je "83 % organizacij doživelo porast napačnih konfiguracij predlog IAC", ko so še naprej sprejemale tehnologijo.

Vemo iz dela, ki ga je opravilo Cloud Security Alliance ("Glavne grožnje za računalništvo v oblaku: Nesramna enajsta“) in drugi, so napačne konfiguracije še vedno največje tveganje v oblaku.

IaC je podprt za zmanjša
napačne konfiguracije s sistematiziranjem ustvarjanja infrastrukture, dodajanjem stopnje strogosti in procesa, ki zagotavlja, da ekipe gradijo, kar hočejo, in samo tisto, kar hočejo. Če približno 83 % ekip tega ne vidi, je v igri globlja težava.

V manjših ekipah, kjer sta del Dev in Ops filozofije DevOps skupaj, je to smiselno. IaC tem majhnim ekipam omogoča uporabo istega jezika – kode – za opis vsega, kar počnejo.

To je razlog, zakaj v AWS CDK in projekti, kot so cdk8s. Te abstrakcije na visoki ravni so bolj udobne za razvijalce.

Ops/SRE/platformska perspektiva storitve v oblaku se bo močno razlikovala od perspektive razvijalca iste storitve. Razvijalec si bo ogledal storitev čakalne vrste in se poglobil v njen vmesnik – preprosto končno točko za dodajanje in eno za branje? prodano To je enostavna integracija.

Cilj te operativne perspektive je najti robove. Torej, kdaj ta čakalna vrsta doseže svojo mejo? Ali je zmogljivost konstantna ali se radikalno spreminja pod obremenitvijo?

Da, obstajajo prekrivajoči se pomisleki. In ja, to je poenostavljen pogled. Ampak ideja drži. IaC rešuje veliko težav, lahko pa tudi ustvari in poveča nepovezanost med ekipami. Še pomembneje je, da lahko poudari vrzel med namenom tega, kar poskušate zgraditi, in resničnostjo tega, kar ste zgradili.

Posledično se tu pogosto stopnjujejo varnostni pomisleki.

Večina orodij – komercialnih ali odprtokodnih – je osredotočena na prepoznavanje stvari, ki so narobe s predlogami infrastrukture. Ta
je dobra konstrukcija. Izdelava ta
bi bilo slabo. Cilj teh orodij je ustvariti te rezultate kot del cevovoda za stalno integracijo/neprekinjeno dostavo (CI/CD).

To je odličen začetek. Vendar odmeva isto jezikovno vprašanje.

Kdo govori in kdo posluša?

Ko orodje IAC izpostavi težavo, kdo jo bo obravnaval? Če je to razvojna skupina, ali ima dovolj informacij, da ve, zakaj je bilo to označeno kot težava? Če je to operativna ekipa, ali so posledice težave navedene v poročilu?

Razvijalcem se pogosto zgodi, da preprosto prilagodijo konfiguracijo, da bo testiranje IaC uspešno.

Pri operacijah je običajno odvisno, ali so testi uspešni. Če so, potem na naslednjo nalogo. To ni udarec za nobeno ekipo; namesto tega poudarja vrzel med pričakovanji in realnostjo.

Potreben je kontekst. Varnostno orodje IaC zagotavlja vpogled v to, kaj bo (upajmo) kmalu zgrajeno. Cilj je ustaviti težave pred pridejo v proizvodnjo.

Današnje varnostno orodje IAC poudarja resnične težave, ki jih je treba obravnavati. Obogatitev rezultatov teh orodij z dodatnim kontekstom, ki je specifičen za skupino, odgovorno za kodo, je odlična priložnost za avtomatizacijo po meri.

To bo tudi pomagalo premostiti jezikovno vrzel. Rezultat vaših orodij je v bistvu v tretjem jeziku – samo zato, da bi bile stvari bolj zapletene – in jih je treba sporočiti na način, ki je smiseln za razvojno ali operativno občinstvo. Pogosto oboje.

Na primer, ko pregled označi, da pravilo varnostne skupine nima opisa, zakaj je to pomembno? Samo prejemanje opozorila z napisom »Dodajte opis za kontekst« nikomur ne pomaga graditi bolje.

Ta vrsta zastave je odlična priložnost za izobraževanje ekip, ki gradijo v oblaku. Če dodate razlago, da morajo biti pravila varnostne skupine čim bolj specifična, se zmanjša možnost zlonamernih napadov. Navedite sklice na primere močnih pravil. Pokličite to, ne da bi vedeli za namero, in druge ekipe ne bodo mogle preizkusiti veljavnosti varnostne potrditve.

Varnost je odgovornost vseh, zato bo priznavanje jezikovne vrzeli med razvijalci in operacijami poudarilo priložnosti, kot je ta, za dodajanje preprostih avtomatizacij, ki vašim ekipam zagotavljajo vpogled. To bo pomagalo izboljšati to, kar gradijo, in posledično bo spodbudilo boljše varnostne rezultate.

O Author

Sem forenzik, govornik in tehnološki analitik, ki vam poskušam pomagati razumeti digitalni svet in njegov vpliv na nas. Za vsakodnevne uporabnike moje delo pomaga razložiti, kakšni so izzivi digitalnega sveta. Kako velik vpliv ima uporaba družbenih medijev na vašo zasebnost? Kaj pomeni, ko se tehnologije, kot je prepoznavanje obraza, začnejo uporabljati v naših skupnostih? Pomagam odgovoriti na takšna in druga vprašanja. Ljudem, ki gradijo tehnologijo, jim pomagam, da pri svojem delu uporabijo objektiv varnosti in zasebnosti, tako da lahko uporabnikom omogočijo sprejemanje jasnejših odločitev o njihovih informacijah in vedenju. Ko gre za zasebnost in varnost, je gora zmede. Ne bi smelo biti. Varnost in zasebnost olajšam za razumevanje.