Sve više korisnika dovodi cijelu svoju IT infrastrukturu u javni oblak. Međutim, ako antivirusna kontrola nije dovoljna u infrastrukturi korisnika, javljaju se ozbiljni sajber rizici. Praksa pokazuje da do 80% postojećih virusa savršeno živi u virtuelnom okruženju. U ovom postu ćemo govoriti o tome kako zaštititi IT resurse u javnom oblaku i zašto tradicionalni antivirusi nisu u potpunosti prikladni za te svrhe.
Za početak ćemo vam reći kako smo došli do ideje da uobičajeni alati za antivirusnu zaštitu nisu prikladni za javni oblak i da su potrebni drugi pristupi zaštiti resursa.
Prvo, provajderi općenito pružaju potrebne mjere kako bi osigurali da su njihove platforme u oblaku zaštićene na visokom nivou. Na primjer, u #CloudMTS analiziramo sav mrežni promet, pratimo logove sigurnosnih sistema našeg oblaka i redovno izvodimo pentestove. Segmenti oblaka dodijeljeni pojedinačnim klijentima također moraju biti sigurno zaštićeni.
Drugo, klasična opcija za borbu protiv sajber rizika uključuje instaliranje antivirusnih i antivirusnih alata za upravljanje na svakoj virtuelnoj mašini. Međutim, sa velikim brojem virtuelnih mašina, ova praksa može biti neefikasna i zahteva značajne količine računarskih resursa, čime se dodatno učitava infrastruktura korisnika i smanjuju ukupne performanse oblaka. Ovo je postao ključni preduslov za traženje novih pristupa izgradnji efikasne antivirusne zaštite za virtuelne mašine korisnika.
Osim toga, većina antivirusnih rješenja na tržištu nije prilagođena rješavanju problema zaštite IT resursa u javnom oblaku. Po pravilu, to su teška EPP rješenja (Endpoint Protection Platforms), koja, osim toga, ne pružaju potrebnu prilagodbu na strani klijenta cloud provajdera.
Postaje očigledno da tradicionalna antivirusna rješenja nisu prikladna za rad u oblaku, jer ozbiljno opterećuju virtualnu infrastrukturu tokom ažuriranja i skeniranja, a također nemaju potrebne nivoe upravljanja i postavki zasnovanih na ulogama. Zatim ćemo detaljno analizirati zašto su oblaku potrebni novi pristupi antivirusnoj zaštiti.
Šta bi antivirusni program u javnom oblaku trebao biti u stanju učiniti
Dakle, obratimo pažnju na specifičnosti rada u virtuelnom okruženju:
Efikasnost ažuriranja i planiranih masovnih skeniranja. Ako značajan broj virtuelnih mašina koje koriste tradicionalni antivirus istovremeno pokrene ažuriranje, u oblaku će se pojaviti takozvana „oluja“ ažuriranja. Snaga ESXi hosta koji ugošćuje nekoliko virtuelnih mašina možda neće biti dovoljna da se nosi sa mnoštvom sličnih zadataka koji se podrazumevano izvršavaju. Sa stanovišta cloud provajdera, takav problem može dovesti do dodatnog opterećenja brojnih ESXi hostova, što će u konačnici dovesti do pada performansi virtualne infrastrukture oblaka. Ovo može, između ostalog, uticati na performanse virtuelnih mašina drugih klijenata u oblaku. Slična situacija može se pojaviti prilikom pokretanja masovnog skeniranja: istovremena obrada od strane sistema diska mnogih sličnih zahtjeva različitih korisnika negativno će utjecati na performanse cijelog oblaka. Sa visokim stepenom verovatnoće, smanjenje performansi sistema skladištenja će uticati na sve klijente. Ovakva nagla opterećenja ne prijaju ni provajderu ni njegovim korisnicima, jer utiču na „komšije“ u oblaku. Sa ove tačke gledišta, tradicionalni antivirus može predstavljati veliki problem.
Sigurna karantena. Ako se na sistemu otkrije datoteka ili dokument potencijalno zaražen virusom, on se šalje u karantenu. Naravno, zaraženi fajl se može odmah izbrisati, ali to često nije prihvatljivo za većinu kompanija. Korporativni korporativni antivirusi koji nisu prilagođeni za rad u oblaku provajdera, u pravilu imaju zajedničku karantensku zonu - svi zaraženi objekti padaju u nju. Na primjer, one koje se nalaze na računarima korisnika kompanije. Klijenti cloud provajdera „žive” u svojim segmentima (ili stanari). Ovi segmenti su neprozirni i izolovani: klijenti ne znaju jedni za druge i, naravno, ne vide šta drugi hostuju u oblaku. Očigledno, opća karantena, kojoj će pristupiti svi antivirusni korisnici u oblaku, potencijalno može uključivati dokument koji sadrži povjerljive informacije ili poslovnu tajnu. Ovo je neprihvatljivo za provajdera i njegove kupce. Dakle, može postojati samo jedno rješenje - lični karantin za svakog klijenta u njegovom segmentu, gdje ni provajder ni drugi klijenti nemaju pristup.
Individualne sigurnosne politike. Svaki klijent u oblaku je zasebna kompanija, čiji IT odjel postavlja vlastite sigurnosne politike. Na primjer, administratori definiraju pravila skeniranja i zakazuju antivirusna skeniranja. Shodno tome, svaka organizacija mora imati svoj vlastiti kontrolni centar za konfiguriranje antivirusnih politika. U isto vrijeme, navedene postavke ne bi trebale utjecati na druge klijente u oblaku, a provajder bi trebao moći provjeriti da se, na primjer, antivirusna ažuriranja provode normalno za sve klijentske virtuelne mašine.
Organizacija fakturisanja i licenciranja. Cloud model karakterizira fleksibilnost i uključuje plaćanje samo količine IT resursa koje je korisnik koristio. Ako postoji potreba, na primjer, zbog sezonskog karaktera, tada se količina resursa može brzo povećati ili smanjiti - sve na osnovu trenutnih potreba za računarskom snagom. Tradicionalni antivirus nije toliko fleksibilan - klijent u pravilu kupuje licencu na godinu dana za unaprijed određen broj servera ili radnih stanica. Korisnici oblaka redovno isključuju i povezuju dodatne virtuelne mašine u zavisnosti od njihovih trenutnih potreba – shodno tome, antivirusne licence moraju podržavati isti model.
Drugo pitanje je šta će tačno licenca pokrivati. Tradicionalni antivirus je licenciran prema broju servera ili radnih stanica. Licence zasnovane na broju zaštićenih virtuelnih mašina nisu u potpunosti prikladne unutar modela oblaka. Klijent može kreirati bilo koji broj virtuelnih mašina koje mu odgovaraju iz raspoloživih resursa, na primer, pet ili deset mašina. Ovaj broj nije konstantan za većinu klijenata, mi kao provajder ne možemo pratiti njegove promjene. Ne postoji tehnička mogućnost licenciranja po CPU-u: klijenti dobijaju virtuelne procesore (vCPU) koje treba koristiti za licenciranje. Stoga bi novi model antivirusne zaštite trebao uključiti mogućnost da korisnik odredi potreban broj vCPU-a za koje će dobiti antivirusne licence.
Usklađenost sa zakonodavstvom. Važna stvar, jer korištena rješenja moraju osigurati usklađenost sa zahtjevima regulatora. Na primjer, "stanovnici" oblaka često rade s ličnim podacima. U tom slučaju, provajder mora imati poseban certificirani segment oblaka koji je u potpunosti usklađen sa zahtjevima Zakona o ličnim podacima. Tada kompanije ne moraju samostalno „izgraditi“ cijeli sistem za rad s ličnim podacima: kupiti certificiranu opremu, povezati je i konfigurirati i proći certifikaciju. Za sajber zaštitu ISPD-a takvih klijenata, antivirus mora biti usklađen sa zahtjevima ruskog zakonodavstva i imati FSTEC certifikat.
Razmotrili smo obavezne kriterije koje mora ispuniti antivirusna zaštita u javnom oblaku. Zatim ćemo podijeliti vlastito iskustvo u prilagođavanju antivirusnog rješenja za rad u oblaku provajdera.
Kako se možete sprijateljiti između antivirusa i oblaka?
Kao što je naše iskustvo pokazalo, odabir rješenja na osnovu opisa i dokumentacije je jedna stvar, ali implementacija u praksi u već radnom cloud okruženju je po složenosti sasvim drugi zadatak. Reći ćemo vam šta smo radili u praksi i kako smo prilagodili antivirus za rad u javnom oblaku provajdera. Prodavac antivirusnog rješenja bio je Kaspersky, čiji portfolio uključuje rješenja za zaštitu od virusa za okruženja u oblaku. Odlučili smo se za „Kaspersky Security for Virtualization“ (Light Agent).
Uključuje jednu Kaspersky Security Center konzolu. Laki agent i sigurnosne virtuelne mašine (SVM, Security Virtual Machine) i KSC integracioni server.
Nakon što smo proučili arhitekturu rešenja Kaspersky i sproveli prve testove zajedno sa inženjerima dobavljača, postavilo se pitanje integracije servisa u oblak. Prva implementacija obavljena je zajedno na lokaciji u oblaku u Moskvi. I to smo shvatili.
Kako bi se minimizirao mrežni promet, odlučeno je da se postavi SVM na svaki ESXi host i "veže" SVM za ESXi hostove. U ovom slučaju, laki agenti zaštićenih virtuelnih mašina pristupaju SVM-u tačnog ESXi hosta na kojem su pokrenuti. Za glavni KSC je izabran poseban administrativni zakupac. Kao rezultat toga, podređeni KSC se nalaze u zakupcima svakog pojedinačnog klijenta i obraćaju se nadređenoj KSC koja se nalazi u segmentu upravljanja. Ova shema vam omogućava da brzo riješite probleme koji se javljaju kod zakupaca klijenata.
Pored problema sa podizanjem komponenti samog antivirusnog rešenja, suočili smo se sa zadatkom organizacije mrežne interakcije kroz kreiranje dodatnih VxLAN-ova. I iako je rješenje prvobitno bilo namijenjeno poslovnim klijentima sa privatnim oblacima, uz pomoć inženjerske pameti i tehnološke fleksibilnosti NSX Edgea uspjeli smo riješiti sve probleme vezane za odvajanje stanara i licenciranje.
Blisko smo sarađivali sa Kaspersky inženjerima. Dakle, u procesu analize arhitekture rješenja u smislu mrežne interakcije između komponenti sistema, utvrđeno je da je, osim pristupa od svjetlosnih agenata SVM-u, neophodna i povratna informacija - od SVM-a do svjetlosnih agenata. Ova mrežna povezanost nije moguća u okruženju sa više stanara zbog mogućnosti identičnih mrežnih postavki virtuelnih mašina u različitim zakupcima oblaka. Stoga su, na naš zahtjev, kolege iz vendora preradile mehanizam mrežne interakcije između svjetlosnog agenta i SVM-a u smislu eliminacije potrebe za mrežnim povezivanjem SVM-a do svjetlosnih agenata.
Nakon što je rješenje implementirano i testirano na moskovskoj web lokaciji u oblaku, replicirali smo ga na druge lokacije, uključujući i certificirani segment oblaka. Usluga je sada dostupna u svim regijama zemlje.
Arhitektura rješenja za sigurnost informacija u okviru novog pristupa
Opća shema rada antivirusnog rješenja u javnom oblaku je sljedeća:
Šema rada antivirusnog rješenja u javnom oblaku #CloudMTS
Hajde da opišemo karakteristike rada pojedinih elemenata rješenja u oblaku:
• Jedinstvena konzola koja omogućava klijentima da centralno upravljaju sistemom zaštite: pokreću skeniranja, kontrolišu ažuriranja i nadgledaju karantinske zone. Moguće je konfigurirati pojedinačne sigurnosne politike unutar vašeg segmenta.
Treba napomenuti da iako smo mi pružalac usluga, mi se ne miješamo u postavke koje postavljaju klijenti. Jedino što možemo učiniti je resetirati sigurnosne politike na standardne ako je potrebna rekonfiguracija. Na primjer, to može biti potrebno ako ih je klijent slučajno stegnuo ili značajno oslabio. Kompanija uvijek može dobiti kontrolni centar sa zadanim politikama, koje potom može samostalno konfigurirati. Nedostatak Kaspersky Security Center-a je što je platforma trenutno dostupna samo za Microsoft operativni sistem. Iako lagani agenti mogu raditi i sa Windows i Linux mašinama. Međutim, Kaspersky Lab obećava da će KSC u bliskoj budućnosti raditi pod Linux OS-om. Jedna od važnih funkcija KSC-a je sposobnost upravljanja karantinom. Svaka kompanija klijent u našem oblaku ima ličnu. Ovakav pristup eliminira situacije u kojima dokument zaražen virusom slučajno postane javno vidljiv, kao što bi se moglo dogoditi u slučaju klasičnog korporativnog antivirusa sa općim karantinom.
• Laka sredstva. Kao deo novog modela, lagani Kaspersky Security agent je instaliran na svakoj virtuelnoj mašini. Ovo eliminiše potrebu za pohranjivanjem antivirusne baze podataka na svaki VM, što smanjuje količinu potrebnog prostora na disku. Servis je integrisan sa infrastrukturom oblaka i radi preko SVM-a, što povećava gustinu virtuelnih mašina na ESXi hostu i performanse celog cloud sistema. Lagani agent pravi red zadataka za svaku virtuelnu mašinu: proverava sistem datoteka, memoriju itd. Ali SVM je odgovoran za izvođenje ovih operacija, o čemu ćemo govoriti kasnije. Agent takođe funkcioniše kao zaštitni zid, kontroliše bezbednosne politike, šalje zaražene fajlove u karantin i prati celokupno „zdravlje“ operativnog sistema na kojem je instaliran. Sve ovo se može upravljati pomoću već spomenute jedinstvene konzole.
• Sigurnosna virtuelna mašina. Svim zadacima koji zahtijevaju velike resurse (ažuriranja antivirusnih baza podataka, planirana skeniranja) upravlja posebna sigurnosna virtualna mašina (SVM). Ona je odgovorna za rad punopravnog antivirusnog motora i baza podataka za njega. IT infrastruktura kompanije može uključivati nekoliko SVM-ova. Ovaj pristup povećava pouzdanost sistema - ako jedna mašina pokvari i ne odgovori trideset sekundi, agenti automatski počinju da traže drugu.
• KSC integracioni server. Jedna od komponenti glavnog KSC-a, koja dodeljuje svoje SVM-ove lakim agentima u skladu sa algoritmom navedenim u njegovim postavkama, a takođe kontroliše dostupnost SVM-a. Dakle, ovaj softverski modul omogućava balansiranje opterećenja na svim SVM-ovima cloud infrastrukture.
Algoritam za rad u oblaku: smanjenje opterećenja infrastrukture
Općenito, antivirusni algoritam se može predstaviti na sljedeći način. Agent pristupa datoteci na virtuelnoj mašini i provjerava je. Rezultat verifikacije je uskladišten u zajedničkoj centralizovanoj bazi podataka SVM presuda (nazvanoj Shared Cache), svaki unos u kojem identifikuje jedinstveni uzorak datoteke. Ovaj pristup vam omogućava da osigurate da se ista datoteka ne skenira nekoliko puta zaredom (na primjer, ako je otvorena na različitim virtuelnim mašinama). Datoteka se ponovo skenira samo ako su u njoj napravljene promjene ili je skeniranje pokrenuto ručno.
Implementacija antivirusnog rješenja u oblaku provajdera
Slika prikazuje opći dijagram implementacije rješenja u oblaku. Glavni Kaspersky Security Center je raspoređen u kontrolnoj zoni oblaka, a pojedinačni SVM se postavlja na svaki ESXi host koristeći KSC integracioni server (svaki ESXi host ima svoj SVM povezan sa posebnim postavkama na VMware vCenter serveru). Klijenti rade u sopstvenim segmentima oblaka, gde se nalaze virtuelne mašine sa agentima. Njima se upravlja preko pojedinačnih KSC servera koji su podređeni glavnom KSC-u. Ako je potrebno zaštititi mali broj virtuelnih mašina (do 5), klijentu se može obezbediti pristup virtuelnoj konzoli posebnog namenskog KSC servera. Mrežna interakcija između klijentskih KSC-ova i glavnog KSC-a, kao i lakih agenata i SVM-a, se vrši korišćenjem NAT-a preko EdgeGW klijentskih virtuelnih rutera.
Prema našim procjenama i rezultatima testova kolega kod dobavljača, Light Agent smanjuje opterećenje virtuelne infrastrukture klijenata za približno 25% (u poređenju sa sistemom koji koristi tradicionalni antivirusni softver). Konkretno, standardni Kaspersky Endpoint Security (KES) antivirus za fizička okruženja troši skoro dvostruko više procesorskog vremena servera (2,95%) od laganog rješenja virtuelizacije baziranog na agentima (1,67%).
Uporedni grafikon CPU opterećenja
Slična situacija je uočena i sa učestalošću pristupa upisivanju na disk: za klasični antivirus to je 1011 IOPS, za cloud antivirus 671 IOPS.
Grafikon poređenja brzine pristupa disku
Prednost performansi vam omogućava da održite stabilnost infrastrukture i efikasnije koristite računarsku snagu. Prilagođavajući se radu u javnom oblaku, rješenje ne smanjuje performanse oblaka: centralno provjerava datoteke i preuzima ažuriranja, raspoređujući opterećenje. To znači da, s jedne strane, prijetnje relevantne za infrastrukturu oblaka neće biti propuštene, s druge strane, zahtjevi za resursima za virtuelne mašine će biti smanjeni u prosjeku za 25% u odnosu na tradicionalni antivirus.
Što se tiče funkcionalnosti, oba rješenja su vrlo slična jedno drugom: u nastavku je tabela poređenja. Međutim, u oblaku, kao što pokazuju gornji rezultati testiranja, i dalje je optimalno koristiti rješenje za virtuelna okruženja.
O tarifama u okviru novog pristupa. Odlučili smo da koristimo model koji nam omogućava da dobijemo licence na osnovu broja vCPU-ova. To znači da će broj licenci biti jednak broju vCPU-ova. Možete testirati svoj antivirus tako što ćete ostaviti zahtjev .
U sljedećem članku o temama oblaka govorit ćemo o evoluciji WAF-ova u oblaku i šta je bolje odabrati: hardver, softver ili oblak.
Tekst su pripremili zaposleni u cloud provajderu #CloudMTS: Denis Mjagkov, vodeći arhitekta i Aleksej Afanasjev, menadžer razvoja proizvoda za bezbednost informacija.
izvor: www.habr.com