🥇 Miks traditsioonilised viirusetõrjed ei sobi avalikele pilvedele. Ja mida teha?

Üha rohkem kasutajaid viib kogu oma IT-infrastruktuuri avalikku pilve. Kui aga kliendi infrastruktuuris puudub piisav viirusetõrje kontroll, tekivad tõsised küberriskid. Praktika näitab, et kuni 80% olemasolevatest viirustest elavad virtuaalses keskkonnas suurepäraselt. Selles postituses räägime, kuidas kaitsta IT-resursse avalikus pilves ja miks traditsioonilised viirusetõrjed ei ole nende eesmärkide saavutamiseks piisavad.

Alustame sellest, kuidas me jõudsime mõttele, et avalikule pilve ei sobi tuttavad viirusetõrje tööriistad ja on vajalikud teised lähenemisviisid ressursside kaitsmiseks.

Esiteks tagavad teenusepakkujad tavaliselt vajalikud meetmed, et garanteerida oma pilveplatvormide kõrge kaitse tase. Näiteks analüüsime meie #CloudMTS kogu võrgu liiklust, jälgime meie pilve turvasüsteemide logisid ja teostame regulaarselt sissetungi testimist. Eraklientidele antud pilvekliendisegmendid peavad samuti olema usaldusväärselt kaitstud.

Teiseks, klassikaline küberriskide vastu võitlemise variant hõlmab viirusetõrje ja selle juhtimisvahendite installimist igasse virtuaalmasinasse. Siiski, kui virtuaalmasinaid on palju, võib see praktika osutuda ebaefektiivseks ja nõuda märkimisväärset arvutusressurssi, koormates seeläbi veelgi kliendi infrastruktuuri ja vähendades pilve üldist jõudlust. See on muutunud peamiseks eelduseks uute lähenemisviiside leidmiseks kliendi virtuaalmasinate tõhusaks viirusetõrjeks.

Lisaks ei ole enamik turul olevaid viirusetõrje lahendusi kohandatud avaliku pilve keskkonnas IT-resursside kaitsmiseks. Need on tavaliselt rasked EPP-lahendused (Endpoint Protection Platforms), mis ei paku piisavat kohandamisvõimet pilveteenuse pakkujate klientidele.

On muutunud selgeks, et traditsioonilised viirusetõrje lahendused ei sobi hästi pilvekeskkonnas töötamiseks, kuna need koormavad virtuaalset infrastruktuuri tõsiselt uuenduste ja skannimise ajal, samuti ei paku nad vajalikke rolle haldussüsteemide ja seadeid. Järgmisena käsitleme üksikasjalikult, millistel põhjustel vajab pilv uusi lähenemisviise viirusetõrje kaitseks.

Mida peab viirusetõrje teadma avalikus pilves

Nii et pöörame tähelepanu virtuaalse keskkonna töö eripäradele:

Uuenduste tõhusus ja massilised kontrollid ajakava järgi. Kui suur hulk virtuaalmasinaid, mis kasutavad traditsioonilist viirusetõrjet, käivitavad samaaegselt uuendamise, toimub pilves nn „uuenduste torm”. ESXi hosti võimsus, millel asub mitu virtuaalmasinat, võib olla ebapiisav, et hallata samu ülesandeid, mis on vaikimisi käivitatud. Pilveteenuse pakkuja vaatenurgast võib see probleem põhjustada täiendavaid koormusi mitmetele ESXi hostidele, mis võib lõpuks viia pilve virtuaalse infrastruktuuri jõudluse languseni. See võib mõjutada ka teiste pilvekliendi virtuaalmasinate jõudlust. Sarnane olukord võib tekkida massilise skannimise käivitamisel: samaaegne paljude sarnaste päringute töötlemine erinevatelt kasutajatelt võib halvasti mõjutada kogu pilve jõudlust. Suure tõenäosusega kajastub salvestusseadmestiku jõudluse langus kõikide klientide seas. Sellised äkilised koormused ei meeldi ei teenusepakkujale ega tema klientidele, kuna need mõjutavad „naabreid” pilves. Sel põhjusel võib traditsiooniline viirusetõrje olla tohutu probleem.

Turvaline karantiin. Kuna süsteemis avastatakse fail või dokument, mis on potentsiaalselt viiruse nakkuse ohus, saadetakse see karantiini. Loomulikult võib nakatunud faili kohe eemaldada, kuid see ei ole sageli enamikule ettevõtetest vastuvõetav. Ettevõtte tasemel viirusetõrjed, mis ei ole kohandatud teenusepakkuja pilvekeskkonda, omavad tavaliselt ühte ühiskarantiini ala — sinna satuvad kõik nakatunud objektid. Näiteks need, mis avastatakse ettevõtte kasutajate arvutites. Pilveteenuse klientide isoleeritud segmendid (või tenantid) on läbipaistmatud: kliendid ei tea üksteisest ja loomulikult ei näe nad, mida teised pilves hoiavad. On ilmne, et üldisse karantiini, millele pääsevad ligi kõik viirusetõrje kasutajad, võib potentsiaalselt sattuda dokument, mis sisaldab konfidentsiaalset teavet või äri saladust. See on teenusepakkujale ja tema klientidele vastuvõetamatu. Seetõttu ei saa lahenduseks olla muud, kui igal kliendil peab olema isiklik karantiin oma segmendis, millele ei pääse juurde ei teenusepakkuja ega teised kliendid.

Isiklikud turvapoliitikad. Igal pilvklient on eraldi ettevõte, mille IT-osakond kehtestab oma turvapoliitikad. Näiteks määravad administraatorid skaneerimise reeglid ja viirusetõrje kontrollide ajakava. Seetõttu peab igal organisatsioonil olema oma juhtimiskeskus viirusetõrje poliitikate seadistamiseks. Samal ajal ei tohi määratud seaded mõjutada teisi pilvekliente ja teenusepakkuja peab olema kindel, et näiteks viirusetõrje värskendused toimuvad tavapäraselt kõikide kliendi virtuaalmasinate jaoks.

Arvepidamise ja litsentseerimise korraldus. Pilvemudel iseloomustab paindlikkust ja eeldab tasumist ainult nende IT-resursside mahtude eest, mida tellija on kasutanud. Kui näiteks on vajadus, tulenevalt hooajalisuse tegurist, saab ressursimahu kiiresti suurendada või vähendada — see sõltub täielikult hetke vajadustest arvutusvõimsuse järele. Traditsiooniline viirusetõrje ei ole nii paindlik — tavaliselt ostab klient aastaks litsentsi ette määratud koguse jaoks. serverid või tööjaamade. Pilvekasutajad katkevad ja ühendavad regulaarselt lisanduvaid virtuaalmasinaid vastavalt oma hetke vajadustele — seega peavad viirusetõrjelitsentsid toetama sama mudelit.

Teine küsimus on, millele litsents täpselt laienevad. Traditsiooniline viirusetõrje litsentseeritakse serverite või tööjaamade arvu järgi. Litsentsid kaitstavate virtuaalmasinate arvu järgi ei sobi täielikult pilvemudelisse. Klient võib olemasolevatest ressurssidest luua endale sobiva arvu virtuaalmasinaid, näiteks viis või kümme masinat. See arv ei ole enamikul klientidest püsiv, meie kui teenusepakkuja jaoks on selle muutuste jälgimine keeruline. Litsentseerida ei saa ka CPU alusel: kliendid saavad virtuaalseid protsessoreid (vCPU), mille alusel litsentseerimine peaks toimuma. Seega peaks uus viirusetõrjevõimekuse mudel võimaldama kliendil määrata vajalik arv vCPU-sid, millele ta soovib viirusetõrjelitsentse saada.

Seadusandlik nõuetekohasus. Oluline punkt, kuna rakendatud lahendused peavad tagama regulatiivsete nõuete täitmise. Näiteks töötavad sageli „pilveelanikud” isikuandmetega. Sellisel juhul peab teenusepakkujal olema eraldi sertifitseeritud pilvesegment, mis vastab täielikult isikuandmete seaduse nõuetele. Sel juhul ei pea ettevõtted iseseisvalt „ehitama” kogu süsteemi isikuandmetega töötamiseks: ostma sertifitseeritud varustust, selle ühendama ja seadistama, läbitama sertifitseerimise. Küberkaitse ISPDN-ile peaks ka selliste klientide jaoks viirusetõrje vastama Venemaa seadusandlikele nõuetele ning olema FSTEK sertifikaadiga.

Oleme käsitlenud kohustuslikke kriteeriume, millega viirusetõrje peab rahuldama avalikus pilves. Edasi jagame oma kogemusi viirusetõrjelahenduse kohandamisest, et töötada teenusepakkuja pilves.

Kuidas saab viirusetõrjet ja pilve omavahel siduda?

Kogemused näitavad, et lahenduse valimine kirjelduste ja dokumentatsiooni põhjal on üks asi, kuid selle rakendamine juba töötavas pilvesüsteemis on hoopis teine väljakutse. Räägime, mida me praktikas tegime ja kuidas kohandasime viirusetõrjet töötamiseks teenusepakkuja avalikus pilves. Viirusetõrje lahenduse tarnijaks sai Kaspersky, kelle portfellis on viirusetõrje lahendused pilvealuste jaoks. Valisime "Kaspersky Security virtuaalsetele keskkondadele" (Kerge agent).

See sisaldab ühte Kaspersky Security Center'i console'i. Kerge agent ja turva virtuaalmasinad (SVM, Security Virtual Machine) ning KSC integreerimise server.

Pärast Kaspersky lahenduse arhitektuuri uurimist ja esialgsete testide läbiviimist koos tarnija inseneridega tekkis küsimus teenuse integreerimisest pilve. Esimene rakendus tehti ühiselt Moskva pilves. Ja siin on see, mida me õppisime.

Ahnud võrgu liikluse vähendamiseks otsustati iga ESXi-hosti paigaldada SVM ja "siduda" SVM ESXi-hostidega. Nii saavad kaetud virtuaalmasinate kerge agendid pöörduda SVM-i poole just sellel ESXi-hostil, kus nad töötavad. Peamise KSC jaoks valiti eraldi haldustenant. Seetõttu asuvad alamsüsteemid KSC igas eraldi kliendi tenantis ja pöörduvad ülemise KSC poole, mis asub juhtimissegmentides. Selline skeem võimaldab kiiresti lahendada probleeme, mis tekivad klientide tentantes.

Lisaks viirusetõrje lahenduse komponentide ülesseadmise küsimustele seisis meie ees ülesanne korraldada võrgukoostööd täiendavate VxLAN-de loomise kaudu. Ja kuigi lahendus oli algselt mõeldud enterprise klientidele era pilvedega — inseneride leidlikkuse ja tehnoloogilise paindlikkuse abil NSX Edge suutsime lahendada kõik probleemid, mis olid seotud tentantide eristamise ja litsentseerimisega.

Me töötasime tihedas koostöös Kaspersky inseneridega. Nii selgus analüüsi käigus, et süsteemi komponentide vahelise võrgu suhtluse arhitektuuris on lisaks kergete agentide juurdepääsule SVM-ile vajalik ka tagasiside – SVM-ilt kergetele agentidele. Selle võrgu seotuse loomine on multitenant- keskkonnas võimatu, kuna erinevates tenantides võiks olla samasugused virtuaalmasinate võrguseaded. Seetõttu töötasid meie palve peale tarnija kolleegid ümber võrgu suhtlemise mehhanismi kerge agendi ja SVM vahel, et välistada vajadus SVM-ilt kergetele agentidele suunatud võrgusidet.

Pärast lahenduse juurutamist ja testimist Moskva pilveserveri keskkonnas levitasime seda ka teistesse keskkondadesse, sealhulgas akrediteeritud pilvlahendustesse. Nüüd on teenus saadaval kõikides riigi piirkondades.

IB-lahenduse arhitektuur uue lähenemise raames

Antiviiruslahenduse töö üldine skeem avalikus pilvkeskkonnas on järgmine:

Antiviiruslahenduse töö skeem avalikus pilvkeskkonnas #CloudMTS

Käesolevaga kirjeldame lahenduse erinevate elementide töö omadusi pilves:

• Üksne juhtpaneel, mis võimaldab klientidel tsentraliseeritud kujul kaitsesüsteemi hallata: teostada skaneerimisi, jälgida uuendusi ja jälgida karantiinialasid. Samuti on võimalik seada oma segmendi piires individuaalseid turvapoliitikaid.

Oluline on märkida, et kuigi me oleme teenusepakkuja, ei sekkume klientide seatud seadistustesse. Ainus, mida me teha saame, on vajadusel taastada vaikeseaded turvapoliitikates. Näiteks võib see olla vajalik, kui klient on neid kogemata karmistanud või oluliselt nõrgestanud. Ettevõte saab alati pääseda juurde juhtimiskeskusele, kus on vaikeseaded, mida saab seejärel iseseisvalt kohandada. Kaspersky Security Center'i miinus on see, et see on praegu saadaval ainult Microsofti operatsioonisüsteemile. Kuigi kerged agendid saavad töötada nii Windows kui ka Linuxi masinatega. Kuid Kaspersky Laboratooriumis lubavad nad, et peagi töötavad KSC ka Linuxi operatsioonisüsteemidel. Üks KSC olulisi funktsioone on karantiini haldamine. Igal meie pilves oleval kliendiettevõttel on personaalne karantiin. See lähenemine välistab olukorrad, kus viirusega nakatunud dokument satub kogemata avalikkuse ette, nagu see võiks juhtuda klassikalise ettevõtte viirusetõrjega, kus karantiin on ühine.

• Kerged agendid. Uues mudelis instalitakse iga virtuaalse masina jaoks Kaspersky Security kerge agent. See võimaldab mitte hoida viirusetõrje andmebaasi igas VM-is, mis vähendab hõivatud kettaruumi mahtu. Teenus on integreeritud pilvestruktuuriga ning töötab läbi SVM-i, mis suurendab virtuaalsete masinate tihedust ESXi hostis ja kogu pilvesüsteemi jõudlust. Kerge agent seadistab iga virtuaalse masina jaoks ülesannete järjekorra: failisüsteemi kontroll, mälu jne. Kuid nende toimingute täitmiseks vastutab juba SVM, millest räägime edaspidi. Samuti täidab agent tulemüürifunktsioone, kontrollib turvapoliitikaid, saadab nakatunud failid karantiini ning jälgib operatsioonisüsteemi üldist „tervist”, millel see on installitud. Kõike seda saab hallata juba mainitud ühtse kontseptsiooni kaudu.

• Turvaline Virtuaalmasin. Kõigi ressursinõudlike ülesannetega (viirusetõrje baaside värskendamine, ajastatud kontrollid) tegeleb eraldi Turvaline Virtuaalmasin (SVM). See vastutab täieõigusliku viirusetõrje mootori ja sellega seotud andmebaaside töö eest. Ettevõtte IT-infrastruktuur võib sisaldada mitmeid SVM-e. Selline lähenemine suurendab süsteemi usaldusväärsust — kui mõni masin ebaõnnestub ja ei reageeri kolmekümne sekundi jooksul, hakkavad agentid automaatselt otsima muud.

• KSC Integreerimisserver. Üks peamise KSC komponente, mis määrab vastavalt selle seadistustes määratud algoritmile kergetele agentidele oma SVM-id, samuti jälgib SVM-idede kättesaadavust. Nii tagab see programmimoodul kogu pilveinfrastruktuuri SVM-ide koormuse tasakaalu.

Töö algoritm pilves: koormuse vähendamine infrastruktuurile

Üldiselt võib viirusetõrje töö algoritmi esitada järgmiselt. Agent pöördub virtuaalmasinas oleva faili poole ja kontrollib seda. Kontrolli tulemus salvestatakse ühisesse keskse juhtide SVM andmebaasi (mida nimetatakse Shared Cache), iga kirje, mis identifitseerib unikaalse faili mustri. Selline lähenemine võimaldab jälgida, et sama faili ei kontrollitaks mitu korda järjest (näiteks kui seda avati erinevates virtuaalmasinates). Faili skaneeritakse uuesti ainult siis, kui sellesse on tehtud muudatusi või kontroll käivitatakse käsitsi.

Viirusetõrje lahenduse rakendamine teenusepakkuja pilves

Pildil on kujutatud pilvelahenduse rakendamise üldine skeem. Pilvehalduspiirkonnas on paigaldatud peamine Kaspersky Security Center ja iga ESXi hosti peal on KSC integreerimisserveri abil paigaldatud individuaalne SVM (iga ESXi hosti jaoks on VMware vCenter Serveris eriseaded, mille abil on seotud oma SVM). Klientidel on juurdepääs oma pilve segmentidele, kus asuvad virtuaalsed masinad agentidega. Neid hallatakse individuaalsete KSC serverite kaudu, mis on allutatud peamisele KSC-le. Kui on vajalik kaitsta väikest hulka virtuaalseid masinaid (kuni 5), võib kliendile anda juurdepääsu eraldatud KSC serveri virtuaalsele konsoolile. Klientide KSC ja peamise KSC, samuti kergete agentide ja SVM-i vaheline võrguühendus toimub NAT-i abil klientide virtuaalsete EdgeGW marsruuterite kaudu.

Meie uuringute ja partneri katsetuste põhjal vähendab kerge agent kliendi virtuaalinfrastruktuuri koormust umbes 25% (võrreldes süsteemiga, mis kasutab traditsioonilist viirusetõrjetarkvara). Eriti Kaspersky Endpoint Security (KES) klassikaline viirusetõrje füüsilistes keskkondades kasutab serveri protsessorivõimekuse aega peaaegu kaks korda rohkem (2,95%), kui virtualiseerimise lahendus, mis põhineb kergetel agentidel (1,67%).

Protsessori koormuse võrdluse diagramm

Sarnane olukord on täheldatav ka ketta kirjutamise sageduse osas: klassikalise viirusetõrje puhul on see 1011 IOPS, pilveviirusetõrje puhul aga 671 IOPS.

Ketta ligipääsu sageduse võrdluse diagramm

Tulemuse kasu võimaldab säilitada infrastruktuuri stabiilsust ja tõhusamalt ära kasutada arvutusvõimsust. Avalikus pilves keskkonnas töötamiseks kohandatud lahendus ei vähenda pilve jõudlust: see viib läbi failide tsentraliseeritud kontrolli ja allalaadib värskendusi, jagades koormust. See tähendab, et ühelt poolt ei jäeta tähelepanuta pilvohutuste jaoks asjakohaseid ohte, teiselt poolt vähenevad virtuaalmasinate ressursinõudmised keskmiselt 25% võrreldes traditsioonilise viirusetõrjega.

Funktsionaalsuse poolest sarnanevad mõlemad lahendused tugevalt üksteisele: allpool on esitatud võrdlev tabel. Siiski, nagu ülaltoodud testimistest selgub, on pilves ikkagi optimaalsem kasutada lahendust virtuaalsete keskkondade jaoks.

Teave uue lähenemise hinnakujunduse kohta. Otsustasime kasutada mudelit, mis võimaldab hankida litsentse vastavalt vCPU arvule. See tähendab, et litsentside arv on võrdne vCPU arvuga. Viirusevastast tarkvara saab testida, jättes taotluse. veebisaidil.