Vse več uporabnikov prenaša svojo celotno IT infrastrukturo v javni oblak. Če pa protivirusni nadzor v infrastrukturi stranke ni zadosten, nastanejo resna kibernetska tveganja. Praksa kaže, da do 80% obstoječih virusov popolnoma živi v virtualnem okolju. V tem prispevku bomo govorili o tem, kako zaščititi IT vire v javnem oblaku in zakaj tradicionalni protivirusni programi niso povsem primerni za te namene.
Za začetek vam povemo, kako smo prišli do ideje, da običajna protivirusna zaščitna orodja niso primerna za javni oblak in da so potrebni drugi pristopi k zaščiti virov.
Prvič, ponudniki na splošno zagotavljajo potrebne ukrepe za zagotovitev, da so njihove platforme v oblaku zaščitene na visoki ravni. Na primer, pri #CloudMTS analiziramo ves omrežni promet, spremljamo dnevnike varnostnih sistemov našega oblaka in redno izvajamo pentest. Segmenti oblaka, dodeljeni posameznim strankam, morajo biti tudi varno zaščiteni.
Drugič, klasična možnost za boj proti kibernetskim tveganjem vključuje namestitev protivirusnega programa in protivirusnih orodij za upravljanje na vsak virtualni stroj. Vendar pa je pri velikem številu virtualnih strojev ta praksa lahko neučinkovita in zahteva znatne količine računalniških virov, s čimer dodatno obremeni strankino infrastrukturo in zmanjša splošno zmogljivost oblaka. To je postal ključni predpogoj za iskanje novih pristopov k izgradnji učinkovite protivirusne zaščite za virtualne stroje strank.
Poleg tega večina protivirusnih rešitev na trgu ni prilagojenih za reševanje problemov zaščite informacijskih virov v javnem oblačnem okolju. Praviloma gre za težke rešitve EPP (Endpoint Protection Platforms), ki poleg tega ne zagotavljajo potrebne prilagoditve na strani odjemalca ponudnika oblaka.
Postane očitno, da tradicionalne protivirusne rešitve niso primerne za delo v oblaku, saj resno obremenjujejo virtualno infrastrukturo med posodabljanjem in skeniranjem, poleg tega pa nimajo potrebnih ravni upravljanja in nastavitev na podlagi vlog. Nato bomo podrobno analizirali, zakaj oblak potrebuje nove pristope k protivirusni zaščiti.
Kaj naj bi protivirusni program v javnem oblaku zmogel
Bodimo torej pozorni na posebnosti dela v virtualnem okolju:
Učinkovitost posodobitev in načrtovanih množičnih pregledov. Če veliko število virtualnih strojev, ki uporabljajo tradicionalni protivirusni program, sproži posodobitev hkrati, se bo v oblaku pojavila tako imenovana "nevihta" posodobitev. Zmogljivost gostitelja ESXi, ki gosti več virtualnih strojev, morda ne bo zadostovala za obvladovanje množice podobnih nalog, ki se privzeto izvajajo. Z vidika ponudnika oblaka lahko taka težava privede do dodatnih obremenitev številnih gostiteljev ESXi, kar bo na koncu privedlo do padca zmogljivosti virtualne infrastrukture oblaka. To lahko med drugim vpliva na delovanje virtualnih strojev drugih odjemalcev v oblaku. Podobna situacija se lahko pojavi pri zagonu množičnega skeniranja: sočasna obdelava diskovnega sistema številnih podobnih zahtev različnih uporabnikov bo negativno vplivala na delovanje celotnega oblaka. Z visoko stopnjo verjetnosti bo zmanjšanje zmogljivosti sistema za shranjevanje vplivalo na vse odjemalce. Takšne nenadne obremenitve ne ugajajo niti ponudniku niti njegovim strankam, saj vplivajo na »sosede« v oblaku. S tega vidika lahko tradicionalni antivirus predstavlja velik problem.
Varna karantena. Če je v sistemu zaznana datoteka ali dokument, ki je potencialno okužen z virusom, se pošlje v karanteno. Seveda lahko okuženo datoteko takoj izbrišemo, vendar to za večino podjetij pogosto ni sprejemljivo. Korporativni protivirusni programi, ki niso prilagojeni za delo v oblaku ponudnika, imajo praviloma skupno karantensko območje - vsi okuženi predmeti padejo vanj. Na primer tiste, ki jih najdemo na računalnikih uporabnikov podjetja. Stranke ponudnika oblaka »živijo« v svojih segmentih (oz. najemnikih). Ti segmenti so nepregledni in izolirani: stranke ne vedo drug za drugega in seveda ne vidijo, kaj drugi gostijo v oblaku. Očitno bi splošna karantena, do katere bodo dostopali vsi uporabniki protivirusnega programa v oblaku, potencialno lahko vsebovala dokument z zaupnimi informacijami ali poslovno skrivnostjo. To je za ponudnika in njegove stranke nesprejemljivo. Rešitev je torej lahko samo ena - osebna karantena za vsakega naročnika v njegovem segmentu, kamor nima dostopa niti ponudnik niti drugi naročniki.
Individualne varnostne politike. Vsak odjemalec v oblaku je ločeno podjetje, katerega IT oddelek postavlja lastne varnostne politike. Skrbniki na primer določijo pravila skeniranja in načrtujejo protivirusne preglede. V skladu s tem mora imeti vsaka organizacija svoj nadzorni center za konfiguracijo protivirusnih politik. Obenem navedene nastavitve ne bi smele vplivati na druge odjemalce v oblaku, ponudnik pa bi moral imeti možnost preveriti, ali se na primer protivirusne posodobitve izvajajo kot običajno za vse odjemalske virtualne stroje.
Organizacija obračunavanja in licenciranja. Za model v oblaku je značilna fleksibilnost in vključuje plačilo samo za količino informacijskih virov, ki jih je stranka uporabila. Če obstaja potreba, na primer zaradi sezonskosti, se lahko količina virov hitro poveča ali zmanjša - vse glede na trenutne potrebe po računalniški moči. Tradicionalni antivirus ni tako prilagodljiv - praviloma stranka kupi licenco za eno leto za vnaprej določeno število strežnikov ali delovnih postaj. Uporabniki oblaka redno odklopijo in priklopijo dodatne virtualne stroje glede na svoje trenutne potrebe – zato morajo protivirusne licence podpirati isti model.
Drugo vprašanje je, kaj točno bo dovoljenje zajemalo. Tradicionalni protivirusni program je licenciran glede na število strežnikov ali delovnih postaj. Licence, ki temeljijo na številu zaščitenih virtualnih strojev, niso povsem primerne v modelu oblaka. Stranka lahko iz razpoložljivih virov ustvari poljubno število virtualnih strojev, ki so mu primerni, na primer pet ali deset strojev. Ta številka pri večini naročnikov ni konstantna, njeni spremembi kot ponudnik ne moremo slediti. Ni tehnične možnosti licenciranja po CPE: odjemalci prejmejo virtualne procesorje (vCPE), ki jih je treba uporabiti za licenciranje. Tako naj bi novi model protivirusne zaščite vključeval možnost, da stranka sama določi zahtevano število vCPU-jev, za katere bo prejela protivirusne licence.
Skladnost z zakonodajo. Pomembna točka, saj morajo uporabljene rešitve zagotavljati skladnost z zahtevami regulatorja. Na primer, "prebivalci" oblaka pogosto delajo z osebnimi podatki. V tem primeru mora imeti ponudnik ločen certificiran segment oblaka, ki v celoti ustreza zahtevam zakona o osebnih podatkih. Potem podjetjem ni treba samostojno "graditi" celotnega sistema za delo z osebnimi podatki: kupiti certificirano opremo, jo povezati in konfigurirati ter opraviti certificiranje. Za kibernetsko zaščito ISPD takšnih strank mora protivirusni program izpolnjevati tudi zahteve ruske zakonodaje in imeti certifikat FSTEC.
Ogledali smo si obvezne kriterije, ki jih mora izpolnjevati protivirusna zaščita v javnem oblaku. Nato bomo delili lastne izkušnje pri prilagajanju protivirusne rešitve za delo v oblaku ponudnika.
Kako se lahko spoprijateljite med antivirusom in oblakom?
Kot so pokazale naše izkušnje, je izbira rešitve na podlagi opisa in dokumentacije eno, implementacija v praksi v že delujočem oblačnem okolju pa je po zahtevnosti povsem druga naloga. Povedali vam bomo, kaj smo naredili v praksi in kako smo protivirusni program prilagodili delovanju v javnem oblaku ponudnika. Ponudnik protivirusne rešitve je bil Kaspersky, katerega portfelj vključuje rešitve protivirusne zaščite za oblačna okolja. Odločili smo se za »Kaspersky Security za virtualizacijo« (Light Agent).
Vključuje eno samo konzolo Kaspersky Security Center. Lahki agent in varnostni virtualni stroji (SVM, Security Virtual Machine) in integracijski strežnik KSC.
Potem ko smo preučili arhitekturo rešitve Kaspersky in opravili prve teste skupaj z inženirji prodajalca, se je pojavilo vprašanje o integraciji storitve v oblak. Prva implementacija je bila izvedena skupaj na moskovski lokaciji v oblaku. In to smo spoznali.
Da bi čim bolj zmanjšali omrežni promet, je bilo odločeno, da se SVM postavi na vsakega gostitelja ESXi in se SVM »poveže« z gostitelji ESXi. V tem primeru lažji agenti zaščitenih virtualnih strojev dostopajo do SVM točno tistega gostitelja ESXi, na katerem se izvajajo. Za glavni KSC je bil izbran ločen upravni najemnik. Posledično se podrejeni KSC nahajajo v najemnikih vsake posamezne stranke in naslavljajo nadrejene KSC, ki se nahajajo v segmentu upravljanja. Ta shema vam omogoča hitro reševanje težav, ki se pojavijo pri najemnikih strank.
Poleg težav z dvigovanjem komponent same protivirusne rešitve smo se soočili z nalogo organizacije omrežne interakcije z ustvarjanjem dodatnih VxLAN. In čeprav je bila rešitev prvotno namenjena podjetniškim odjemalcem z zasebnimi oblaki, nam je s pomočjo inženirske podkovanosti in tehnološke prilagodljivosti NSX Edge uspelo rešiti vse težave, povezane z ločevanjem najemnikov in licenciranjem.
Tesno smo sodelovali z inženirji družbe Kaspersky. Tako je bilo v procesu analize arhitekture rešitve z vidika omrežne interakcije med komponentami sistema ugotovljeno, da je poleg dostopa lahkih agentov do SVM potrebna tudi povratna informacija - od SVM do lahkih agentov. Ta omrežna povezljivost ni mogoča v večnajemniškem okolju zaradi možnosti enakih omrežnih nastavitev virtualnih strojev v različnih najemnikih oblaka. Zato so na našo zahtevo sodelavci prodajalca predelali mehanizem omrežne interakcije med lahkim agentom in SVM v smislu odprave potrebe po omrežni povezljivosti od SVM do lahkih agentov.
Potem ko je bila rešitev uvedena in preizkušena na moskovski spletni strani v oblaku, smo jo replicirali na druga spletna mesta, vključno s certificiranim segmentom v oblaku. Storitev je zdaj na voljo v vseh regijah države.
Arhitektura rešitve informacijske varnosti v okviru novega pristopa
Splošna shema delovanja protivirusne rešitve v javnem oblačnem okolju je naslednja:
Shema delovanja protivirusne rešitve v javnem oblačnem okolju #CloudMTS
Naj opišemo značilnosti delovanja posameznih elementov rešitve v oblaku:
• Enotna konzola, ki odjemalcem omogoča centralno upravljanje zaščitnega sistema: izvajanje pregledov, nadzor posodobitev in spremljanje karantenskih območij. Možno je konfigurirati posamezne varnostne politike znotraj vašega segmenta.
Treba je poudariti, da čeprav smo ponudnik storitev, ne posegamo v nastavitve, ki jih določijo stranke. Edina stvar, ki jo lahko naredimo, je ponastavitev varnostnih politik na standardne, če je potrebna ponovna konfiguracija. To je na primer morda potrebno, če jih je stranka pomotoma zategnila ali znatno oslabila. Podjetje lahko vedno prejme nadzorni center s privzetimi pravilniki, ki jih lahko nato samostojno konfigurira. Slabost Kaspersky Security Center je, da je platforma trenutno na voljo samo za operacijski sistem Microsoft. Čeprav lahko lahki agenti delujejo s stroji Windows in Linux. Vendar Kaspersky Lab obljublja, da bo KSC v bližnji prihodnosti deloval pod operacijskim sistemom Linux. Ena od pomembnih funkcij KSC je sposobnost upravljanja karantene. Vsako podjetje naročnik v našem oblaku ima svojega osebnega. Ta pristop odpravlja situacije, ko dokument, okužen z virusom, pomotoma postane javno viden, kot bi se lahko zgodilo v primeru klasičnega korporativnega antivirusa s splošno karanteno.
• Lahka sredstva. Kot del novega modela je na vsak virtualni stroj nameščen lahek agent Kaspersky Security. To odpravlja potrebo po shranjevanju protivirusne baze podatkov na vsakem VM, kar zmanjša količino potrebnega prostora na disku. Storitev je integrirana z oblačno infrastrukturo in deluje prek SVM, kar poveča gostoto virtualnih strojev na gostitelju ESXi in zmogljivost celotnega oblačnega sistema. Lahki agent sestavi čakalno vrsto opravil za vsak virtualni stroj: preveri datotečni sistem, pomnilnik itd. Toda SVM je odgovoren za izvajanje teh operacij, o katerih bomo govorili kasneje. Agent deluje tudi kot požarni zid, nadzoruje varnostne politike, pošilja okužene datoteke v karanteno in spremlja splošno "zdravje" operacijskega sistema, v katerem je nameščen. Vse to je mogoče upravljati z že omenjeno enotno konzolo.
• Varnostni virtualni stroj. Vse naloge, ki zahtevajo veliko virov (posodobitve protivirusnih baz podatkov, načrtovani pregledi) upravlja ločen varnostni virtualni stroj (SVM). Odgovorna je za delovanje polnega protivirusnega mehanizma in baz podatkov zanj. IT infrastruktura podjetja lahko vključuje več SVM. Ta pristop poveča zanesljivost sistema – če en stroj odpove in se ne odzove trideset sekund, agenti samodejno začnejo iskati drugega.
• Integracijski strežnik KSC. Ena od komponent glavnega KSC, ki dodeljuje svoje SVM lahkim agentom v skladu z algoritmom, določenim v svojih nastavitvah, in tudi nadzoruje razpoložljivost SVM. Tako ta programski modul zagotavlja uravnoteženje obremenitve v vseh SVM-jih infrastrukture v oblaku.
Algoritem za delo v oblaku: zmanjšanje obremenitve infrastrukture
Na splošno lahko protivirusni algoritem predstavimo na naslednji način. Agent dostopa do datoteke na virtualnem računalniku in jo preveri. Rezultat preverjanja je shranjen v skupni centralizirani podatkovni zbirki sodb SVM (imenovani skupni predpomnilnik), vsak vnos v kateri identificira edinstven vzorec datoteke. Ta pristop vam omogoča, da zagotovite, da se ista datoteka ne pregleda večkrat zaporedoma (na primer, če je bila odprta na različnih virtualnih strojih). Datoteka se ponovno pregleda le, če so bile v njej opravljene spremembe ali če je bilo skeniranje zagnano ročno.
Implementacija protivirusne rešitve v oblaku ponudnika
Slika prikazuje splošen diagram implementacije rešitve v oblaku. Glavni Kaspersky Security Center je nameščen v nadzornem območju oblaka, posamezni SVM pa je nameščen na vsakem gostitelju ESXi z integracijskim strežnikom KSC (vsak gostitelj ESXi ima svoj SVM, pritrjen s posebnimi nastavitvami na VMware vCenter Server). Naročniki delajo v svojih segmentih oblaka, kjer se nahajajo virtualni stroji z agenti. Upravljajo se preko posameznih strežnikov KSC, ki so podrejeni glavnemu KSC. Če je potrebno zaščititi manjše število virtualnih strojev (do 5), lahko odjemalcu omogočimo dostop do virtualne konzole posebnega namenskega strežnika KSC. Omrežna interakcija med odjemalskimi KSC-ji in glavnim KSC-jem ter lahkimi agenti in SVM-ji se izvaja z uporabo NAT prek odjemalskih virtualnih usmerjevalnikov EdgeGW.
Po naših ocenah in rezultatih testov kolegov pri prodajalcu Light Agent zmanjša obremenitev virtualne infrastrukture odjemalcev za približno 25% (v primerjavi s sistemom, ki uporablja tradicionalno protivirusno programsko opremo). Zlasti standardni protivirusni program Kaspersky Endpoint Security (KES) za fizična okolja porabi skoraj dvakrat toliko časa procesorja strežnika (2,95 %) kot lahka rešitev za virtualizacijo, ki temelji na agentih (1,67 %).
Primerjalna tabela obremenitve procesorja
Podobno je tudi pri pogostosti dostopov do pisanja na disk: pri klasičnem antivirusu je 1011 IOPS, pri oblačnem antivirusu pa 671 IOPS.
Primerjalni graf stopnje dostopa do diska
Prednost zmogljivosti vam omogoča ohranjanje stabilnosti infrastrukture in učinkovitejšo uporabo računalniške moči. S prilagajanjem delu v javnem oblačnem okolju rešitev ne zmanjša zmogljivosti v oblaku: centralno preverja datoteke in prenaša posodobitve ter tako porazdeli obremenitev. To pomeni, da po eni strani ne bodo zgrešene grožnje, pomembne za infrastrukturo v oblaku, po drugi strani pa se bodo zahteve po virih za virtualne stroje zmanjšale v povprečju za 25 % v primerjavi s tradicionalnim protivirusnim programom.
Po funkcionalnosti sta si obe rešitvi zelo podobni: spodaj je primerjalna tabela. Vendar pa je v oblaku, kot kažejo zgornji rezultati testiranja, še vedno optimalna uporaba rešitve za virtualna okolja.
O tarifah v okviru novega pristopa. Odločili smo se za model, ki nam omogoča pridobivanje licenc glede na število vCPE. To pomeni, da bo število licenc enako številu vCPE. Svoj protivirusni program lahko preizkusite tako, da pustite zahtevo .
V naslednjem članku o temah v oblaku bomo govorili o razvoju oblakov WAF in o tem, kaj je bolje izbrati: strojno opremo, programsko opremo ali oblak.
Besedilo sta pripravila zaposlena pri ponudniku oblaka #CloudMTS: Denis Myagkov, vodilni arhitekt in Alexey Afanasyev, vodja razvoja izdelkov za informacijsko varnost.
Vir: www.habr.com