Vis daugiau vartotojų perkelia visą savo IT infrastruktūrą į viešąjį debesį. Tačiau jei antivirusinė kontrolė kliento infrastruktūroje yra nepakankama, kyla rimtų kibernetinių pavojų. Praktika rodo, kad iki 80% esamų virusų puikiai gyvena virtualioje aplinkoje. Šiame įraše kalbėsime apie tai, kaip apsaugoti IT išteklius viešajame debesyje ir kodėl tradicinės antivirusinės priemonės nėra visiškai tinkamos šiems tikslams.
Pirmiausia papasakosime, kaip priėjome prie minties, kad įprastos antivirusinės apsaugos priemonės netinka viešajam debesiui ir kad reikia kitų būdų apsaugoti išteklius.
Pirma, paslaugų teikėjai paprastai imasi būtinų priemonių, kad užtikrintų, jog jų debesų platformos būtų apsaugotos aukštu lygiu. Pavyzdžiui, #CloudMTS analizuojame visą tinklo srautą, stebime debesies saugos sistemų žurnalus ir reguliariai atliekame pentestus. Atskiriems klientams priskirti debesų segmentai taip pat turi būti saugiai apsaugoti.
Antra, klasikinis būdas kovoti su kibernetine rizika apima antivirusinių ir antivirusinių valdymo įrankių įdiegimą kiekvienoje virtualioje mašinoje. Tačiau naudojant daug virtualių mašinų, ši praktika gali būti neveiksminga ir pareikalauti daug skaičiavimo išteklių, todėl dar labiau apkraunama kliento infrastruktūra ir sumažėja bendras debesies našumas. Tai tapo pagrindine prielaida ieškant naujų būdų, kaip sukurti efektyvią antivirusinę klientų virtualiųjų mašinų apsaugą.
Be to, dauguma antivirusinių sprendimų rinkoje nėra pritaikyti spręsti IT išteklių apsaugos viešoje debesų aplinkoje problemas. Paprastai tai yra sunkūs EPP sprendimai (Endpoint Protection Platforms), kurie, be to, neužtikrina reikiamo tinkinimo debesų tiekėjo kliento pusėje.
Akivaizdu, kad tradiciniai antivirusiniai sprendimai nėra tinkami darbui debesyje, nes jie rimtai apkrauna virtualią infrastruktūrą atnaujinimų ir nuskaitymų metu, taip pat neturi reikiamo vaidmenimis pagrįsto valdymo ir nustatymų lygio. Toliau išsamiai išanalizuosime, kodėl debesiui reikia naujų požiūrių į antivirusinę apsaugą.
Ką turėtų sugebėti viešajame debesyje esanti antivirusinė programa
Taigi, atkreipkime dėmesį į darbo virtualioje aplinkoje specifiką:
Atnaujinimų ir suplanuotų masinių nuskaitymų efektyvumas. Jei daug virtualių mašinų, naudojančių tradicinę antivirusinę, vienu metu inicijuoja atnaujinimą, debesyje įvyks vadinamoji naujinimų „audra“. ESXi pagrindinio kompiuterio, kuriame yra kelios virtualios mašinos, galios gali nepakakti, kad būtų galima atlikti panašių užduočių, vykdomų pagal numatytuosius nustatymus, srautą. Debesijos paslaugų teikėjo požiūriu, tokia problema gali sukelti papildomų apkrovų daugeliui ESXi pagrindinių kompiuterių, o tai galiausiai sumažės debesų virtualios infrastruktūros našumas. Tai, be kita ko, gali turėti įtakos kitų debesies klientų virtualių mašinų veikimui. Panaši situacija gali susidaryti paleidžiant masinį nuskaitymą: vienu metu daugelio panašių skirtingų vartotojų užklausų apdorojimas disko sistemoje neigiamai paveiks viso debesies našumą. Esant didelei tikimybei, saugojimo sistemos našumo sumažėjimas paveiks visus klientus. Tokios staigios apkrovos nedžiugina nei paslaugų teikėjo, nei jo klientų, nes paveikia „kaimynus“ debesyje. Šiuo požiūriu tradicinė antivirusinė programa gali sukelti didelę problemą.
Saugus karantinas. Jei sistemoje aptinkamas failas ar dokumentas, galimai užkrėstas virusu, jis siunčiamas į karantiną. Žinoma, užkrėstą failą galima ištrinti iš karto, tačiau daugeliui įmonių tai dažnai nepriimtina. Įmonių antivirusinės programos, kurios nėra pritaikytos dirbti tiekėjo debesyje, paprastai turi bendrą karantino zoną - į ją patenka visi užkrėsti objektai. Pavyzdžiui, tie, kurie randami įmonės vartotojų kompiuteriuose. Debesų paslaugų teikėjo klientai „gyvena“ savo segmentuose (arba nuomininkai). Šie segmentai yra neskaidrūs ir izoliuoti: klientai nežino vieni apie kitus ir, žinoma, nemato, ką kiti talpina debesyje. Akivaizdu, kad bendrame karantine, kurį galės pasiekti visi debesyje esantys antivirusiniai vartotojai, gali būti dokumentas, kuriame yra konfidenciali informacija arba komercinė paslaptis. Tai nepriimtina tiekėjui ir jo klientams. Todėl išeitis gali būti tik viena – asmeninis karantinas kiekvienam savo segmento klientui, kur nei paslaugų teikėjas, nei kiti klientai neturi prieigos.
Individuali saugumo politika. Kiekvienas debesies klientas yra atskira įmonė, kurios IT skyrius nustato savo saugumo politiką. Pavyzdžiui, administratoriai apibrėžia nuskaitymo taisykles ir suplanuoja antivirusinius patikrinimus. Atitinkamai, kiekviena organizacija turi turėti savo valdymo centrą antivirusinei strategijai konfigūruoti. Tuo pačiu metu nurodyti nustatymai neturėtų turėti įtakos kitiems debesies klientams, o teikėjas turėtų turėti galimybę patikrinti, ar, pavyzdžiui, antivirusiniai atnaujinimai atliekami kaip įprasta visose klientų virtualiose mašinose.
Sąskaitų išrašymo ir licencijavimo organizavimas. Debesijos modelis pasižymi lankstumu ir apima mokėjimą tik už IT išteklių, kuriuos naudojo klientas, kiekį. Jei yra poreikis, pavyzdžiui, dėl sezoniškumo, tada išteklių kiekį galima greitai padidinti arba sumažinti – viskas priklauso nuo esamų skaičiavimo galios poreikių. Tradicinė antivirusinė programa nėra tokia lanksti – paprastai klientas perka licenciją metams iš anksto nustatytam serverių ar darbo vietų skaičiui. Debesų vartotojai reguliariai atjungia ir prijungia papildomas virtualias mašinas, atsižvelgdami į esamus poreikius – atitinkamai antivirusinės licencijos turi palaikyti tą patį modelį.
Antras klausimas – ką tiksliai apims licencija. Tradicinė antivirusinė programa licencijuojama pagal serverių arba darbo stočių skaičių. Licencijos, pagrįstos apsaugotų virtualių mašinų skaičiumi, nėra visiškai tinkamos debesies modeliui. Klientas iš turimų resursų gali sukurti bet kokį jam patogų virtualių mašinų skaičių, pavyzdžiui, penkias ar dešimt mašinų. Šis skaičius daugeliui klientų nėra pastovus, mes, kaip paslaugų teikėjai, negalime stebėti jo pokyčių. Techninės galimybės licencijuoti pagal CPU nėra: klientai gauna virtualius procesorius (vCPU), kurie turėtų būti naudojami licencijavimui. Taigi naujasis antivirusinės apsaugos modelis turėtų apimti galimybę klientui nustatyti reikiamą vCPU skaičių, kuriam jis gaus antivirusines licencijas.
Teisės aktų laikymasis. Svarbus dalykas, nes naudojami sprendimai turi užtikrinti atitiktį reguliuotojo reikalavimams. Pavyzdžiui, debesies „gyventojai“ dažnai dirba su asmens duomenimis. Tokiu atveju teikėjas turi turėti atskirą sertifikuotą debesų segmentą, visiškai atitinkantį Asmens duomenų įstatymo reikalavimus. Tada įmonėms nereikia savarankiškai „kurti“ visos sistemos darbui su asmens duomenimis: įsigyti sertifikuotą įrangą, ją prijungti ir konfigūruoti bei atlikti sertifikavimą. Siekiant apsaugoti tokių klientų ISPD kibernetinę apsaugą, antivirusinė programa taip pat turi atitikti Rusijos teisės aktų reikalavimus ir turėti FSTEC sertifikatą.
Apžvelgėme privalomus kriterijus, kuriuos turi atitikti antivirusinė apsauga viešajame debesyje. Toliau pasidalinsime savo patirtimi, kaip pritaikyti antivirusinį sprendimą darbui tiekėjo debesyje.
Kaip susidraugauti tarp antivirusinės ir debesies?
Kaip parodė mūsų patirtis, pasirinkti sprendimą pagal aprašymą ir dokumentaciją yra vienas dalykas, tačiau jo įgyvendinimas praktiškai jau veikiančioje debesų aplinkoje sudėtingumo požiūriu yra visiškai kitoks uždavinys. Papasakosime, ką padarėme praktiškai ir kaip pritaikėme antivirusinę, kad ji veiktų tiekėjo viešajame debesyje. Antivirusinio sprendimo pardavėjas buvo Kaspersky, kurio portfelyje yra antivirusinės apsaugos sprendimai debesų aplinkoms. Mes apsistojome ties „Kaspersky Security for Virtualization“ („Light Agent“).
Jame yra viena „Kaspersky Security Center“ konsolė. Lengvosios agento ir saugos virtualios mašinos (SVM, Security Virtual Machine) ir KSC integravimo serveris.
Išstudijavus Kaspersky sprendimo architektūrą ir kartu su pardavėjo inžinieriais atlikus pirmuosius bandymus, iškilo klausimas dėl paslaugos integravimo į debesį. Pirmasis diegimas buvo atliktas kartu Maskvos debesų svetainėje. Ir tai mes supratome.
Siekiant sumažinti tinklo srautą, buvo nuspręsta kiekviename ESXi pagrindiniame kompiuteryje įdėti SVM ir „pririšti“ SVM prie ESXi pagrindinio kompiuterio. Tokiu atveju apsaugotų virtualių mašinų lengvieji agentai pasiekia tikslaus ESXi pagrindinio kompiuterio, kuriame jie veikia, SVM. Pagrindiniam KSC buvo pasirinktas atskiras administracinis nuomininkas. Dėl to pavaldžios KSC yra kiekvieno atskiro kliento nuomininkuose ir kreipiasi į aukštesnįjį KSC, esantį valdymo segmente. Ši schema leidžia greitai išspręsti klientų nuomininkų problemas.
Be problemų, susijusių su paties antivirusinio sprendimo komponentų iškėlimu, mes susidūrėme su užduotimi organizuoti tinklo sąveiką kuriant papildomus VxLAN. Ir nors sprendimas iš pradžių buvo skirtas verslo klientams, turintiems privačius debesis, naudodamiesi NSX Edge inžinerine išmintimi ir technologiniu lankstumu sugebėjome išspręsti visas su nuomininkų atskyrimu ir licencijavimu susijusias problemas.
Glaudžiai bendradarbiavome su „Kaspersky“ inžinieriais. Taigi, analizuojant sprendimo architektūrą pagal tinklo sąveiką tarp sistemos komponentų, buvo nustatyta, kad, be prieigos iš lengvųjų agentų į SVM, būtinas ir grįžtamasis ryšys – nuo SVM iki lengvųjų agentų. Šis tinklo ryšys neįmanomas kelių nuomininkų aplinkoje dėl identiškų virtualių mašinų tinklo nustatymų galimybės skirtinguose debesų nuomininkuose. Todėl mūsų prašymu pardavėjo kolegos pertvarkė tinklo sąveikos tarp lengvojo agento ir SVM mechanizmą, kad būtų išvengta tinklo ryšio tarp SVM ir lengvųjų agentų.
Po to, kai sprendimas buvo įdiegtas ir išbandytas Maskvos debesų svetainėje, pakartojome jį kitose svetainėse, įskaitant sertifikuotą debesų segmentą. Dabar paslauga teikiama visuose šalies regionuose.
Informacijos saugumo sprendimo architektūra naujo požiūrio rėmuose
Bendra antivirusinio sprendimo veikimo viešoje debesų aplinkoje schema yra tokia:
Antivirusinio sprendimo veikimo viešoje debesų aplinkoje schema #CloudMTS
Apibūdinkime atskirų sprendimo elementų veikimo debesyje ypatybes:
• Viena konsolė, leidžianti klientams centralizuotai valdyti apsaugos sistemą: vykdyti nuskaitymus, valdyti naujinimus ir stebėti karantino zonas. Savo segmente galima konfigūruoti individualias saugos strategijas.
Pažymėtina, kad nors esame paslaugų teikėjai, nesikišame į klientų nustatytus nustatymus. Vienintelis dalykas, kurį galime padaryti, tai iš naujo nustatyti saugos strategijas į standartines, jei reikia iš naujo konfigūruoti. Pavyzdžiui, to gali prireikti, jei klientas jas netyčia suveržė arba gerokai susilpnino. Įmonė visada gali gauti valdymo centrą su numatytosiomis strategijomis, kurias vėliau gali konfigūruoti savarankiškai. „Kaspersky Security Center“ trūkumas yra tas, kad platforma šiuo metu prieinama tik „Microsoft“ operacinei sistemai. Nors lengvi agentai gali dirbti ir su Windows, ir su Linux įrenginiais. Tačiau „Kaspersky Lab“ žada, kad artimiausiu metu KSC dirbs su Linux OS. Viena iš svarbių KSC funkcijų – galimybė valdyti karantiną. Kiekviena kliento įmonė mūsų debesyje turi asmeninę. Šis metodas pašalina situacijas, kai virusu užkrėstas dokumentas netyčia tampa viešai matomas, kaip gali nutikti naudojant klasikinę įmonės antivirusinę programą su bendru karantinu.
• Šviesos agentai. Kaip naujojo modelio dalis, kiekvienoje virtualioje mašinoje įdiegtas lengvas „Kaspersky Security“ agentas. Tai pašalina poreikį saugoti antivirusinę duomenų bazę kiekvienoje VM, o tai sumažina reikalingos vietos diske kiekį. Paslauga yra integruota su debesų infrastruktūra ir veikia per SVM, o tai padidina virtualių mašinų tankumą ESXi pagrindiniame kompiuteryje ir visos debesies sistemos našumą. Lengvasis agentas sukuria užduočių eilę kiekvienai virtualiai mašinai: patikrinkite failų sistemą, atmintį ir kt. Tačiau SVM yra atsakingas už šių operacijų atlikimą, apie kurias kalbėsime vėliau. Agentas taip pat veikia kaip užkarda, kontroliuoja saugos politiką, siunčia užkrėstus failus į karantiną ir stebi bendrą operacinės sistemos, kurioje jis įdiegtas, „sveikatą“. Visa tai galima valdyti naudojant jau minėtą vieną konsolę.
• Apsauga Virtuali mašina. Visas daug išteklių reikalaujančias užduotis (antivirusinių duomenų bazių atnaujinimus, suplanuotą nuskaitymą) tvarko atskira virtualioji saugos mašina (SVM). Ji yra atsakinga už visaverčio antivirusinio variklio ir jo duomenų bazių veikimą. Įmonės IT infrastruktūrą gali sudaryti keli SVM. Toks požiūris padidina sistemos patikimumą – sugenda viena mašina ir nereaguoja trisdešimt sekundžių, agentai automatiškai pradeda ieškoti kito.
• KSC integravimo serveris. Vienas iš pagrindinio KSC komponentų, kuris savo SVM priskiria lengviesiems agentams pagal nustatymuose nurodytą algoritmą, taip pat kontroliuoja SVM prieinamumą. Taigi šis programinės įrangos modulis suteikia apkrovos balansavimą visuose debesų infrastruktūros SVM.
Darbo debesyje algoritmas: infrastruktūros apkrovos mažinimas
Apskritai antivirusinį algoritmą galima pavaizduoti taip. Agentas pasiekia failą virtualioje mašinoje ir jį patikrina. Patikrinimo rezultatas saugomas bendroje centralizuotoje SVM verdiktų duomenų bazėje (vadinama Shared Cache), kurioje kiekvienas įrašas identifikuoja unikalų failo pavyzdį. Šis metodas leidžia užtikrinti, kad tas pats failas nebūtų nuskaitomas kelis kartus iš eilės (pavyzdžiui, jei jis buvo atidarytas skirtingose virtualiose mašinose). Failas nuskaitomas iš naujo tik tada, kai buvo atlikti jo pakeitimai arba nuskaitymas pradėtas rankiniu būdu.
Antivirusinio sprendimo diegimas tiekėjo debesyje
Paveikslėlyje parodyta bendra sprendimo įgyvendinimo debesyje schema. Pagrindinis „Kaspersky Security Center“ yra įdiegtas debesies valdymo zonoje, o individualus SVM yra įdiegtas kiekviename ESXi pagrindiniame kompiuteryje, naudojant KSC integravimo serverį (kiekvienas ESXi pagrindinis kompiuteris turi savo SVM, prijungtą su specialiais parametrais „VMware vCenter Server“). Klientai dirba savo debesų segmentuose, kuriuose yra virtualios mašinos su agentais. Jie valdomi per atskirus KSC serverius, pavaldžius pagrindiniam KSC. Jei reikia apsaugoti nedidelį virtualių mašinų skaičių (iki 5), klientui gali būti suteikta prieiga prie specialaus dedikuoto KSC serverio virtualios konsolės. Tinklo sąveika tarp klientų KSC ir pagrindinio KSC, taip pat lengvųjų agentų ir SVM, atliekama naudojant NAT per EdgeGW kliento virtualius maršrutizatorius.
Remiantis mūsų skaičiavimais ir pardavėjo kolegų testų rezultatais, „Light Agent“ sumažina klientų virtualios infrastruktūros apkrovą maždaug 25% (lyginant su sistema, kuri naudoja tradicinę antivirusinę programinę įrangą). Visų pirma, standartinė Kaspersky Endpoint Security (KES) antivirusinė programa, skirta fizinei aplinkai, sunaudoja beveik dvigubai daugiau serverio procesoriaus laiko (2,95 %) nei lengvas agentų pagrindu sukurtas virtualizacijos sprendimas (1,67 %).
CPU apkrovos palyginimo diagrama
Panaši situacija pastebima ir su diskų rašymo prieigų dažniu: klasikinei antivirusinei tai yra 1011 IOPS, debesies antivirusinei - 671 IOPS.
Disko prieigos greičio palyginimo grafikas
Našumo pranašumai leidžia išlaikyti infrastruktūros stabilumą ir efektyviau naudoti skaičiavimo galią. Pritaikius darbui viešoje debesų aplinkoje, sprendimas nesumažina debesies našumo: centralizuotai tikrina failus ir atsisiunčia atnaujinimus, paskirstydamas apkrovą. Tai reiškia, kad, viena vertus, debesų infrastruktūrai aktualios grėsmės nebus praleistos, kita vertus, virtualių mašinų resursų poreikiai sumažės vidutiniškai 25%, palyginti su tradicine antivirusine.
Kalbant apie funkcionalumą, abu sprendimai yra labai panašūs vienas į kitą: žemiau yra palyginimo lentelė. Tačiau debesyje, kaip rodo aukščiau pateikti testų rezultatai, vis tiek optimalu naudoti virtualioms aplinkoms skirtą sprendimą.
Apie tarifus naujojo požiūrio rėmuose. Nusprendėme naudoti modelį, leidžiantį gauti licencijas pagal vCPU skaičių. Tai reiškia, kad licencijų skaičius bus lygus vCPU skaičiui. Galite išbandyti savo antivirusinę programą palikdami užklausą .
Kitame straipsnyje debesų temomis kalbėsime apie debesų WAF raidą ir ką geriau rinktis: aparatinę, programinę įrangą ar debesį.
Tekstą parengė debesų tiekėjo #CloudMTS darbuotojai: pagrindinis architektas Denisas Myagkovas ir informacijos saugos produktų plėtros vadovas Aleksejus Afanasjevas.
Šaltinis: www.habr.com