Sve više i više korisnika svoju cjelokupnu IT infrastrukturu prenosi u javni oblak. Međutim, ako je antivirusna kontrola nedovoljna u korisnikovoj infrastrukturi, nastaju ozbiljni kibernetički rizici. Praksa pokazuje da do 80% postojećih virusa savršeno živi u virtualnom 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 na ideju da uobičajeni alati za antivirusnu zaštitu nisu prikladni za javni oblak i da su potrebni drugi pristupi zaštiti resursa.
Prvo, pružatelji općenito osiguravaju potrebne mjere kako bi osigurali da su njihove platforme u oblaku zaštićene na visokoj razini. Na primjer, u #CloudMTS analiziramo sav mrežni promet, pratimo zapise sigurnosnih sustava našeg oblaka i redovito provodimo pentestove. Segmenti oblaka dodijeljeni pojedinačnim klijentima također moraju biti sigurno zaštićeni.
Drugo, klasična opcija za borbu protiv kibernetičkih rizika uključuje instaliranje antivirusa i antivirusnih alata za upravljanje na svakom virtualnom računalu. Međutim, s velikim brojem virtualnih strojeva, ova praksa može biti neučinkovita i zahtijevati značajne količine računalnih resursa, čime se dodatno opterećuje korisnikova infrastruktura i smanjuje ukupna izvedba oblaka. To je postao ključni preduvjet za traženje novih pristupa izgradnji učinkovite antivirusne zaštite za virtualna računala 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. U pravilu su to teška EPP rješenja (Endpoint Protection Platforms), koja, osim toga, ne pružaju potrebnu prilagodbu na strani klijenta cloud providera.
Postaje očito da tradicionalna antivirusna rješenja nisu prikladna za rad u oblaku, budući da ozbiljno opterećuju virtualnu infrastrukturu tijekom ažuriranja i skeniranja, a također nemaju potrebne razine upravljanja i postavki na temelju uloga. Zatim ćemo detaljno analizirati zašto su oblaku potrebni novi pristupi antivirusnoj zaštiti.
Što bi antivirusni program u javnom oblaku trebao moći
Dakle, obratimo pozornost na specifičnosti rada u virtualnom okruženju:
Učinkovitost ažuriranja i planiranih masovnih skeniranja. Ako značajan broj virtualnih računala koja koriste tradicionalne antivirusne programe pokrenu ažuriranje u isto vrijeme, u oblaku će se dogoditi takozvana "oluja" ažuriranja. Snaga ESXi hosta koji ugošćuje nekoliko virtualnih strojeva možda neće biti dovoljna da se nosi s nizom sličnih zadataka koji se izvode prema zadanim postavkama. Sa stajališta pružatelja usluga oblaka, takav problem može dovesti do dodatnih opterećenja određenog broja ESXi hostova, što će u konačnici dovesti do pada performansi virtualne infrastrukture oblaka. To može, između ostalog, utjecati na performanse virtualnih strojeva drugih klijenata u oblaku. Slična situacija može se pojaviti prilikom pokretanja masovnog skeniranja: istovremena obrada diskovnog sustava mnogih sličnih zahtjeva od različitih korisnika negativno će utjecati na performanse cijelog oblaka. Uz visok stupanj vjerojatnosti, smanjenje performansi sustava za pohranu će utjecati na sve klijente. Takva nagla opterećenja ne zadovoljavaju ni pružatelja usluga ni njegove korisnike, jer utječu na "susjede" u oblaku. S ove točke gledišta, tradicionalni antivirusni program može predstavljati veliki problem.
Sigurna karantena. Ako se u sustavu otkrije datoteka ili dokument potencijalno zaražen virusom, šalje se u karantenu. Naravno, zaraženu datoteku moguće je odmah izbrisati, no to većini tvrtki često nije prihvatljivo. Antivirusi korporativnih poduzeća koji nisu prilagođeni za rad u oblaku davatelja, u pravilu, imaju zajedničku zonu karantene - svi zaraženi objekti padaju u nju. Na primjer, oni koji se nalaze na računalima korisnika tvrtke. Klijenti cloud providera “žive” u svojim segmentima (ili stanarima). Ti su segmenti neprozirni i izolirani: klijenti ne znaju jedni za druge i, naravno, ne vide što drugi hostiraju u oblaku. Očito, opća karantena, kojoj će pristupati svi antivirusni korisnici u oblaku, potencijalno može uključivati dokument koji sadrži povjerljive informacije ili poslovnu tajnu. To je neprihvatljivo za pružatelja i njegove korisnike. Dakle, rješenje može biti samo jedno - osobna karantena za svakog klijenta u njegovom segmentu, gdje nema pristupa niti pružatelj niti drugi klijenti.
Individualne sigurnosne politike. Svaki klijent u oblaku je zasebna tvrtka, čiji IT odjel postavlja vlastite sigurnosne politike. Na primjer, administratori definiraju pravila skeniranja i planiraju antivirusna skeniranja. U skladu s tim, svaka organizacija mora imati vlastiti kontrolni centar za konfiguraciju antivirusnih pravila. U isto vrijeme, navedene postavke ne bi trebale utjecati na druge klijente u oblaku, a pružatelj bi trebao moći provjeriti da se, na primjer, antivirusna ažuriranja provode kao i normalno za sve klijentske virtualne strojeve.
Organizacija naplate i licenciranja. Cloud model karakterizira fleksibilnost i uključuje plaćanje samo one količine IT resursa koje je kupac koristio. Ako postoji potreba, primjerice, zbog sezonalnosti, tada se količina resursa može brzo povećati ili smanjiti - sve na temelju trenutnih potreba za računalnim snagama. Tradicionalni antivirusni program nije toliko fleksibilan - u pravilu klijent kupuje licencu na godinu dana za unaprijed određeni broj poslužitelja ili radnih stanica. Cloud korisnici redovito isključuju i spajaju dodatne virtualne strojeve ovisno o svojim trenutnim potrebama – sukladno tome, antivirusne licence moraju podržavati isti model.
Drugo je pitanje što će licenca točno pokrivati. Tradicionalni antivirusni program licenciran je prema broju poslužitelja ili radnih stanica. Licence temeljene na broju zaštićenih virtualnih strojeva nisu u potpunosti prikladne unutar modela oblaka. Klijent može stvoriti bilo koji broj virtualnih strojeva koji mu odgovaraju iz dostupnih resursa, na primjer, pet ili deset strojeva. Ovaj broj kod većine klijenata nije konstantan, mi kao pružatelj usluga ne možemo pratiti njegove promjene. Ne postoji tehnička mogućnost licenciranja prema CPU-u: klijenti dobivaju virtualne procesore (vCPU-ove) koji bi se trebali koristiti za licenciranje. Tako bi novi model antivirusne zaštite trebao sadržavati mogućnost da korisnik sam odredi potreban broj vCPU-a za koje će dobiti antivirusne licence.
Usklađenost sa zakonodavstvom. Važna točka, budući da korištena rješenja moraju osigurati usklađenost sa zahtjevima regulatora. Na primjer, "stanovnici" oblaka često rade s osobnim podacima. U tom slučaju pružatelj mora imati zaseban certificirani segment oblaka koji u potpunosti odgovara zahtjevima Zakona o osobnim podacima. Tada tvrtke ne moraju samostalno "graditi" cijeli sustav za rad s osobnim podacima: kupiti certificiranu opremu, spojiti je i konfigurirati te proći certifikaciju. Za kibernetičku zaštitu ISPD-a takvih klijenata, antivirus također mora biti u skladu sa zahtjevima ruskog zakonodavstva i imati FSTEC certifikat.
Pogledali smo obvezne kriterije koje mora zadovoljiti antivirusna zaštita u javnom oblaku. Zatim ćemo podijeliti vlastito iskustvo u prilagodbi antivirusnog rješenja za rad u oblaku pružatelja usluga.
Kako možete steći prijatelje između antivirusa i oblaka?
Kao što je naše iskustvo pokazalo, odabir rješenja temeljen na opisu i dokumentaciji je jedna stvar, ali implementacija istog u praksi u već funkcionalnom cloud okruženju je sasvim drugačiji zadatak u smislu složenosti. Reći ćemo vam što smo radili u praksi i kako smo prilagodili antivirus za rad u javnom oblaku pružatelja usluga. Dobavljač antivirusnog rješenja bio je Kaspersky, čiji portfelj uključuje rješenja za antivirusnu zaštitu za cloud okruženja. Odlučili smo se za "Kaspersky Security za virtualizaciju" (Light Agent).
Uključuje jednu Kaspersky Security Center konzolu. Laki agent i sigurnosni virtualni strojevi (SVM, Security Virtual Machine) i KSC integracijski poslužitelj.
Nakon što smo proučili arhitekturu rješenja Kaspersky i proveli prve testove zajedno s inženjerima dobavljača, postavilo se pitanje integracije usluge u oblak. Prva implementacija provedena je zajednički na moskovskom oblaku. I to smo shvatili.
Kako bi se mrežni promet sveo na najmanju moguću mjeru, odlučeno je postaviti SVM na svaki ESXi host i "povezati" SVM s ESXi hostovima. U ovom slučaju, lagani agenti zaštićenih virtualnih strojeva pristupaju SVM-u točno onog ESXi hosta na kojem se izvode. Za glavni KSC odabran je zaseban administrativni stanar. Kao rezultat toga, podređeni KSC-ovi nalaze se u stanarima svakog pojedinog klijenta i obraćaju se nadređenom KSC-u koji se nalazi u segmentu upravljanja. Ova shema omogućuje vam brzo rješavanje problema koji se javljaju kod stanara klijenata.
Osim problema s podizanjem komponenti samog antivirusnog rješenja, suočili smo se sa zadatkom organizacije mrežne interakcije kroz stvaranje dodatnih VxLAN-ova. Iako je rješenje izvorno bilo namijenjeno poslovnim klijentima s privatnim oblacima, uz pomoć inženjerske pameti i tehnološke fleksibilnosti NSX Edgea uspjeli smo riješiti sve probleme povezane s odvajanjem stanara i licenciranja.
Blisko smo surađivali s inženjerima tvrtke Kaspersky. Tako je u procesu analize arhitekture rješenja u smislu mrežne interakcije između komponenti sustava utvrđeno da je osim pristupa lakih agenata SVM-u nužna i povratna informacija - od SVM-a lakim agentima. Ova mrežna povezanost nije moguća u multitenant okruženju zbog mogućnosti identičnih mrežnih postavki virtualnih strojeva u različitim zakupcima oblaka. Stoga su kolege iz dobavljača na naš zahtjev preradili mehanizam mrežne interakcije između laganog agenta i SVM-a u smislu eliminacije potrebe za mrežnim povezivanjem od SVM-a do lakih agenata.
Nakon što je rješenje implementirano i testirano na moskovskom oblaku, replicirali smo ga na drugim mjestima, uključujući certificirani segment oblaka. Usluga je sada dostupna u svim regijama zemlje.
Arhitektura rješenja informacijske sigurnosti u okviru novog pristupa
Opća shema rada antivirusnog rješenja u javnom oblaku je sljedeća:
Shema rada antivirusnog rješenja u javnom oblaku #CloudMTS
Opišimo značajke rada pojedinih elemenata rješenja u oblaku:
• Jedinstvena konzola koja klijentima omogućuje centralizirano upravljanje zaštitnim sustavom: pokretanje skeniranja, kontrola nadogradnji i nadzor karantenskih zona. Moguće je konfigurirati pojedinačne sigurnosne politike unutar vašeg segmenta.
Treba napomenuti da iako smo davatelj usluga, ne miješamo se u postavke koje postavljaju klijenti. Jedino što možemo učiniti je resetirati sigurnosna pravila na standardna ako je potrebna ponovna konfiguracija. Na primjer, to može biti potrebno ako ih je klijent slučajno zategnuo ili značajno oslabio. Tvrtka uvijek može dobiti kontrolni centar sa zadanim pravilima, koje zatim može samostalno konfigurirati. Nedostatak Kaspersky Security Centera je što je platforma trenutno dostupna samo za Microsoft operativni sustav. Iako lagani agenti mogu raditi i s Windows i s Linux strojevima. 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 karantenom. Svaka tvrtka klijent u našem oblaku ima svoju osobnu. Ovaj 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 s općom karantenom.
• Lagani agensi. Kao dio novog modela, na svakom virtualnom računalu instaliran je lagani Kaspersky Security agent. Time se eliminira potreba za pohranjivanjem antivirusne baze podataka na svakom VM-u, što smanjuje količinu potrebnog prostora na disku. Usluga je integrirana s cloud infrastrukturom i radi kroz SVM, što povećava gustoću virtualnih strojeva na ESXi hostu i performanse cijelog cloud sustava. Laki agent gradi red zadataka za svaki virtualni stroj: provjerite datotečni sustav, memoriju itd. Ali SVM je odgovoran za izvođenje ovih operacija, o kojima ćemo govoriti kasnije. Agent također funkcionira kao vatrozid, kontrolira sigurnosne politike, šalje zaražene datoteke u karantenu i prati sveukupno "zdravlje" operativnog sustava na kojem je instaliran. Svim ovim se može upravljati pomoću već spomenute jedinstvene konzole.
• Sigurnosni virtualni stroj. Svim zadacima koji zahtijevaju velike resurse (ažuriranje antivirusne baze podataka, planirano skeniranje) upravlja zaseban sigurnosni virtualni stroj (SVM). Ona je odgovorna za rad punopravnog antivirusnog motora i baza podataka za njega. IT infrastruktura tvrtke može uključivati nekoliko SVM-ova. Ovaj pristup povećava pouzdanost sustava – ako jedan stroj zakaže i ne odgovori trideset sekundi, agenti automatski počinju tražiti drugi.
• KSC integracijski poslužitelj. Jedna od komponenti glavnog KSC-a, koja dodjeljuje svoje SVM-ove lakim agentima u skladu s algoritmom navedenim u svojim postavkama, a također kontrolira dostupnost SVM-ova. Stoga ovaj softverski modul omogućuje uravnoteženje opterećenja na svim SVM-ovima infrastrukture oblaka.
Algoritam za rad u oblaku: smanjenje opterećenja infrastrukture
Općenito, antivirusni algoritam može se predstaviti na sljedeći način. Agent pristupa datoteci na virtualnom računalu i provjerava je. Rezultat provjere pohranjuje se u zajedničku centraliziranu SVM bazu podataka (koja se naziva Shared Cache), a svaki unos u kojoj identificira jedinstveni uzorak datoteke. Ovaj vam pristup omogućuje da se ista datoteka ne skenira nekoliko puta zaredom (na primjer, ako je otvorena na različitim virtualnim računalima). Datoteka se ponovno skenira samo ako su u njoj napravljene promjene ili je skeniranje pokrenuto ručno.
Implementacija antivirusnog rješenja u cloudu pružatelja usluga
Slika prikazuje opći dijagram implementacije rješenja u oblaku. Glavni Kaspersky Security Center raspoređen je u kontrolnoj zoni oblaka, a pojedinačni SVM postavljen je na svakom ESXi hostu pomoću KSC integracijskog poslužitelja (svaki ESXi host ima svoj vlastiti SVM priključen s posebnim postavkama na VMware vCenter poslužitelju). Klijenti rade u svojim segmentima oblaka, gdje se nalaze virtualni strojevi s agentima. Njima se upravlja putem pojedinačnih KSC poslužitelja koji su podređeni glavnom KSC-u. Ukoliko je potrebno zaštititi manji broj virtualnih strojeva (do 5), klijentu se može omogućiti pristup virtualnoj konzoli posebnog namjenskog KSC poslužitelja. Mrežna interakcija između klijentskih KSC-ova i glavnog KSC-a, kao i lakih agenata i SVM-ova, provodi se korištenjem NAT-a putem EdgeGW klijentskih virtualnih usmjerivača.
Prema našim procjenama i rezultatima testova kolega u dobavljaču, Light Agent smanjuje opterećenje virtualne infrastrukture klijenata za približno 25% (u usporedbi sa sustavom koji koristi tradicionalni antivirusni softver). Konkretno, standardni antivirus Kaspersky Endpoint Security (KES) za fizička okruženja troši gotovo dvostruko više CPU vremena poslužitelja (2,95%) od laganog virtualizacijskog rješenja temeljenog na agentima (1,67%).
Tablica usporedbe opterećenja CPU-a
Slična je situacija i s učestalošću pristupa upisivanju na disk: za klasični antivirusni program iznosi 1011 IOPS, za cloud antivirusni program 671 IOPS.
Usporedni grafikon brzine pristupa disku
Prednost performansi omogućuje vam održavanje stabilnosti infrastrukture i učinkovitije korištenje računalne snage. Prilagodbom za rad u javnom oblaku, rješenje ne smanjuje performanse oblaka: ono centralno provjerava datoteke i preuzima ažuriranja, raspoređujući opterećenje. To znači da, s jedne strane, prijetnje relevantne za infrastrukturu u oblaku neće biti propuštene, s druge strane, zahtjevi za resursima za virtualna računala smanjit će se u prosjeku za 25% u usporedbi s tradicionalnim antivirusnim programom.
Što se tiče funkcionalnosti, oba su rješenja vrlo slična jedno drugome: u nastavku je usporedna tablica. Međutim, u oblaku je, kao što pokazuju gornji rezultati testa, još uvijek optimalno koristiti rješenje za virtualna okruženja.
O tarifama u okviru novog pristupa. Odlučili smo koristiti model koji nam omogućuje dobivanje licenci na temelju broja vCPU-a. To znači da će broj licenci biti jednak broju vCPU-a. Svoj antivirus možete testirati ostavljanjem zahtjeva .
U sljedećem članku o temama u oblaku govorit ćemo o evoluciji WAF-ova u oblaku i što je bolje odabrati: hardver, softver ili oblak.
Tekst su pripremili zaposlenici cloud providera #CloudMTS: Denis Myagkov, vodeći arhitekt i Alexey Afanasyev, voditelj razvoja proizvoda za informacijsku sigurnost.
Izvor: www.habr.com