Infrastruktura kao kod (IaC) je postala široko prihvaćena
praksa u modernom DevOps-u, automatizujući upravljanje i obezbjeđivanje tehnološke infrastrukture putem mašinski čitljivih datoteka definicija.
Šta možemo učiniti da IaC bude siguran po defaultu?
Sigurnosni tokovi rada za IaC
Prvo, uzmimo u obzir da se sigurnosni tokovi posla za IaC obično sastoje od više koraka i praksi.
IaC kod se pohranjuje u sistemima za kontrolu verzija, kao što je Git, sa promjenama koje se prate i pregledavaju prije spajanja, što pomaže u poboljšanju konzistentnosti. Sigurnosne politike i provjere konfiguracije su često automatizirane i integrirane u CI/CD cjevovode kako bi se osiguralo da je svaki zahtjev za urezivanje ili povlačenje validiran u odnosu na sigurnosne politike prije implementacije.
Između ostalih najboljih sigurnosnih praksi (kao što je princip najmanjih privilegija , modeliranje i otkrivanje prijetnji, praćenje vremena izvođenja, te revizija i evidentiranje), organizacije takođe moraju osigurati da se nova infrastruktura obezbjeđuje na osnovu ažuriranih, sigurnih specifikacija, a ne modifikacijom postojećih resursa ili koristeći zastarjele IaC šablone. Svi ovi tokovi posla i automatizacije odigrali su vitalnu ulogu u omogućavanju organizacijama da lakše implementiraju konzistentnu infrastrukturu u modernim okruženjima.
Sigurnosni nedostaci su suštinski za IaC
Nažalost, pretvaranje sigurnosnih politika u kod u IaC-u uključuje nekoliko potencijalnih problema, prvenstveno uzrokovanih ljudskom greškom. Kada sigurnosni timovi ili programeri ručno prevedu sigurnosne politike u IaC kod, postoji značajan rizik od grešaka ili pogrešnih tumačenja, što se onda može širiti u više okruženja.
Osim mogućnosti ljudske greške, ovaj proces je takođe radno intenzivan, usporavajući procese razvoja i implementacije. I nažalost, ove ručne konverzije mogu negirati neke od povećanja efikasnosti koje IaC obećava da će isporučiti.
Još jedan značajan izazov je da se sigurnosne politike neizbježno razvijaju, a ručno ažuriranje odgovarajuće IaC-a uvodi veći potencijal za ljudske greške. Ako se ne ažuriraju u cijelosti, infrastruktura možda radi prema zastarjelim sigurnosnim standardima.
Osim toga, kako infrastruktura postaje složenija, ručno upravljanje i implementacija sigurnosnih politika postaje sve izazovnije i podložnije greškama jer uvodi više potencijalnih tačaka kvara. Složenije aplikacije takođe često imaju više međusobno zavisnih komponenti kojima je teško upravljati bez stvaranja nenamjernih sukoba. A sve se to oslanja na to da vaš tim ima duboko razumijevanje i sigurnosnih politika i IaC kodiranja.
Scanning IaC
Skeniranje IaC šablona prije implementacije je neosporno važno; to je efikasan način da se identifikuju potencijalni sigurnosni problemi u ranoj fazi razvoja. Može pomoći u sprečavanju kršenja sigurnosti i osigurati da je vaša infrastruktura cloud-a usklađena s najboljim sigurnosnim praksama. Ako imate IaC alate za skeniranje integrisane u vaše CI/CD cjevovode, takođe možete pokrenuti automatizirana skeniranja sa svakim zahtjevom za urezivanje ili povlačenje koda, hvatajući greške rano.
Skeniranja nakon implementacije su važna jer procjenjuju infrastrukturu u njenom operativnom okruženju, što može rezultirati pronalaženjem problema koji nisu identificirani u okruženjima za razvoj i testiranje. Ova skeniranja mogu također identificirati neočekivane ovisnosti ili sukobe između resursa.
Bilo koje ručne popravke koje napravite da biste riješili ove probleme takođe će zahtijevati od vas da ažurirate postojeće IaC predloške, inače će sve aplikacije koje koriste te predloške biti implementirane s istim problemima. I dok je identificiranje ovih problema u proizvodnim okruženjima važno za ukupnu sigurnost, takođe može povećati vaše troškove i zahtijevati od vašeg tima da primijeni ručne popravke i na aplikaciju i na IaC.
Automatizacija može promašiti cilj
Neki alati nude automatske funkcije sanacije kako bi se smanjila potreba za ručnim popravkama IaC-a automatskim primjenom sigurnosnih zakrpa. Nažalost, automatizacija sanacije može stvoriti različite probleme. Na primjer, automatizirani alati za sanaciju mogu biti nedovoljni jer:
- Radite na osnovu unaprijed definiranih pravila i algoritama, koji možda neće u potpunosti uzeti u obzir jedinstveni kontekst svake aplikacije ili okruženja, što dovodi do promjena koje razbijaju aplikacije ili uzrokuju druge probleme.
- Primijenite previše restriktivne popravke bez otkrivanja da li uzrokuju probleme. Na primjer, smanjenje privilegija za Kubernetes pod koji zahtijeva eskalirane privilegije može rezultirati nefunkcionisanjem aplikacije.
- Neuspješno uzeti u obzir odstupanja uzrokovana pomakom u konfiguraciji, što dovodi do daljeg odstupanja i potencijalne nestabilnosti aplikacije.
- Ne može razlikovati kritične i nekritične probleme, što dovodi do nepotrebnih ili čak štetnih promjena koje bi mogle utjecati na dostupnost i integritet usluge.
- Bavite se simptomima, a ne osnovnim uzrocima, uzrokujući probleme koji se ponavljaju jer osnovni problem ostaje neriješen.
- Borite se da primenite ispravke za složene scenarije koji zahtevaju nijansirano donošenje odluka; složena pitanja često zahtijevaju ljudsku intervenciju.
- Uvesti nove ranjivosti ako popravka otvara nove vektore napada ili slabi postojeće sigurnosne mjere.
Automatska sanacija zvuči idealno, ali uvodi bezbroj neželjenih posljedica koje bi mogle utjecati na pouzdanost i upotrebljivost vaših aplikacija.
Učinite aplikaciju izvorom sigurnosti
Imajući na umu sva ova sigurnosna pitanja, kako da infrastrukturu učinimo sigurnom prema zadanim postavkama kada ima toliko ručnih koraka na putu?
Jedan od prijedloga je da se na aplikaciju gleda kao na izvor istine za infrastrukturu. Kako to izgleda?
Kada programer napiše aplikaciju, on kontinuirano donosi izbore. Na primjer: kojoj bazi podataka treba pristupiti aplikaciji? Na koje druge resurse aplikacija treba da se poveže da bi radila? Svaka odluka zahtijeva infrastrukturu koja će je podržavati i sva ta infrastruktura mora biti dostupna developeru. I ne samo to; infrastruktura kojoj programer ima pristup treba da se uskladi sa relevantnim sigurnosnim standardima na osnovu već donetih odluka.
Koristeći aplikaciju kao izvor istine, možete:
- Uklonite potrebu da programer zna sve sigurnosne politike potrebne za aplikaciju
- Osigurajte da je dostupna odgovarajuća infrastruktura za podršku
- Uklonite potrebu da se programeri sjete da kodiraju sve zahtjeve
- Uštedite vrijeme sigurnosnih timova tako što ćete eliminirati potrebu za revizijom svake linije
- IaC-a kako bi se osiguralo da je usklađena s politikama sigurnosti i usklađenosti
- Osigurajte da je konfiguracija infrastrukture direktno usklađena sa zahtjevima aplikacije
- Minimizirajte rizik od neusklađenosti između aplikacije i infrastrukture
Ovaj pristup poboljšava efikasnost i automatizaciju, pojednostavljujući vašu implementaciju standardizacijom onoga što aplikacija zahtijeva. Takođe čini mnogo jednostavnijim sprovođenje sigurnsosnih i usklađenih politika i garantuje da postoje kontrole pristupa sa najmanjim privilegijama.
IaC siguran po defaultu je moguć
Iako IaC rješava mnoge izazove implementacije aplikacija, i dalje se oslanja na ljude da ručno konvertuju sigurnosne politike u IaC. Ali ako možete apstrahovati IaC koristeći alate koji generišu infrastrukturu iz samog koda aplikacije, IaC možete učiniti sigurnim po defaultu.
Ugrađivanjem konteksta aplikacije u infrastrukturu, organizacije mogu prestati brinuti o ranjivostima i pogrešnim konfiguracijama i umjesto toga se fokusiraju na razvoj i isporuku aplikacija.
Izvor:Help Net Security
