Üha rohkem kasutajaid viib kogu oma IT-infrastruktuuri avalikku pilve. Kuid kui kliendi infrastruktuuri antiviiruskaalutlused on ebapiisavad, siis tekivad tõsised küberriskid. Praktika näitab, et kuni 80% olemasolevatest viirustest elab virtuaalses keskkonnas suurepäraselt. Selles postituses räägime, kuidas kaitsta IT-resursse avalikus pilves ja miks traditsioonilised viirusetõrjed ei sobi nende eesmärkide saavutamiseks.
Alustuseks räägime, kuidas me jõudsime arusaamisele, et avalikule pilve ei sobi tuttavad antiviirusetööriistad ning on vajalikud teistsugused lähenemisviisid ressursside kaitsmiseks.
Esiteks tagavad teenusepakkujad reeglina vajalikud meetmed, et tagada oma pilveplatvormide kaitse kõrgel tasemel. Näiteks analüüsime meie #CloudMTS kogu võrgu liiklust, jälgime oma pilve turvasüsteemide logisid ja viime regulaarselt läbi penteste. Pilves eraldi klientide kasutusse antud segmendid peavad samuti olema usaldusväärselt kaitstud.
Teiseks, klassikaline lähenemine küberriskide haldamisele eeldab viirusetõrje ja selle haldamise vahendite paigaldamist iga virtuaalmasina jaoks. Kuid suurt arvu virtuaalmasinate korral võib see praktika osutuda ebaefektiivseks ja nõuda märkimisväärseid arvutusressursse, mis lisaks koormavad kliendi infrastruktuuri ja vähendavad pilve üldist jõudlust. See on olnud peamine põhjus uute lähenemisviiside otsimiseks tõhusate viirusetõrje lahenduste arendamiseks kliendi virtuaalmasinate jaoks.
Lisaks sellele ei ole enamik turul olevaid viirusetõrje lahendusi kohandatud IT-ressursside kaitsmise ülesannete täitmiseks avalikus pilvekeskkonnas. Tavad on rasked EPP-lahendused (Endpoint Protection Platforms), mis ei paku ka vajalikku kohandamisvõimet pilveteenuse pakkuja kliendi poolel.
On selge, et traditsioonilised viirusetõrje lahendused ei sobi hästi pilvekeskkonda, kuna need koormavad tõsiselt virtuaalset infrastruktuuri uuenduste ja skannimiste ajal ning neil puuduvad vajalikud rolli juhtimise tasemed ja seaded. Järgnevalt vaatame lähemalt, miks on pilv vajab uusi lähenemisviise viirusetõrje kaitseks.
Milliseid oskusi peab viirusetõrje avalikus pilves omama
Seega, keskendume virtuaalse keskkonna töö erilistele aspektidele:
Uuenduste tõhusus ja massilised kontrollid ajakava järgi. Kui suur hulk virtuaalseid masinaid, mis kasutavad traditsioonilist viirusetõrjet, käivitab korraga uuenduse, toimub pilves nn uuenduste "torm". ESXi-hostil, millel asuvad mitmed virtuaalsed masinad, võib olla ebapiisavalt võimekust, et hallata sarnaste ülesannete rünnakut, mis käivitati vaikeseades. Pilveteenuse pakkuja jaoks võib selline probleem põhjustada lisakoormusi mitmes ESXi-hostis, mis lõppkokkuvõttes halvendab virtuaalse pilvinfra struktuuri jõudlust. See võib mõjutada ka teiste pilveklientide virtuaalsete masinate jõudlust. Sarnane olukord võib tekkida ka massilise skaneerimise käivitamisel: samal ajal, kui kõvakettasüsteem töötab paljude samalaadsete päringute töötlemisega erinevatelt kasutajatelt, halvendab see kogu pilve jõudlust. Suure tõenäosusega mõjutab salvestussüsteemi efektiivsus kõiki kliente. Sellised äkilised koormused ei rõõmusta ei teenuse pakkujat ega tema kliente, kuna need mõjutavad teiste „naabreid“ pilves. Selle nurga alt võib traditsiooniline viirusetõrje esindada suurt probleemi.
Turvaline karantiin. Kui süsteemis tuvastatakse fail või dokument, mis on potentsiaalselt viirusest nakatunud, saadetakse see karantiini. Loomulikult on nakatunud faili võimalik koheselt kustutada, kuid paljude ettevõtete jaoks ei ole see sageli vastuvõetav. Ettevõtete korrashoiu lahendused, mis ei ole kohandatud töötamiseks teenusepakkuja pilves, omavad reeglina ühtset karantiiniala — siia suunatakse kõik nakatunud objektid. Näiteks need, mis on tuvastatud ettevõtte kasutajate arvutites. Pilveteenuse kliendid „elavad“ omaette segmentides (või tenantides). Need segmentid on läbipaistmatud ja isoleeritud: kliendid ei tea üksteisest midagi ning loomulikult ei näe nad, mida teised pilves majutavad. On ilmne, et ühtekuuluvasse karantiini, mida kasutavad kõik pilviste antiviiruslahenduste kasutajad, võib potentsiaalselt sattuda dokument, mis sisaldab konfidentsiaalset teavet või ärisaladust. See on teenusepakkuja ja tema klientide jaoks vastuvõetamatu. Seetõttu on lahendus vaid üks – iga kliendi isiklik karantiin tema segmendis, kuhu ei oma juurdepääsu ei teenusepakkuja ega teised kliendid.
Isikupärastatud turvapoliitikad. Iga klient pilves on eraldi ettevõte, mille IT-osakond kehtestab oma turvapoliitikad. Näiteks määravad administraatorid skaneerimise reeglid ja viirusetõrje kontrollide ajakava. Seega peab igal organisatsioonil olema oma juhtimiskeskus viirusetõrje poliitikate seadistamiseks. Samuti ei tohiks seatud määrangud mõjutada teisi pilvekliende, ning teenusepakkujal peab olema võimalus veenduda, et näiteks viirusetõrje uuendused toimuvad normaalselt kõikide kliendi virtuaalmasinate jaoks.
Arveldamise korraldus ja litsentseerimine. Pilvemudel iseloomustub paindlikkusega ja tähendab, et tasuda tuleb vaid nende IT-resursside eest, mida klient on kasutanud. Vajadusel, näiteks hooajalisuse tõttu, on võimalik ressursse kiiresti suurendada või vähendada – kõik sõltub jooksvatest arvutusvõimsuse vajadustest. Tava viirusetõrje ei ole nii paindlik – reeglina ostab klient aastaks litsentsi etteantud arvu jaoks. serverite või tööjaamasid. Pilvekasutajad ühendavad ja katkestavad regulaarselt täiendavaid virtuaalmasinaid vastavalt oma praegustele vajadustele — seega peavad ka viirusetõrje litsentsid toetama sama mudelit.
Teine küsimus on, millele litsents täpselt laieneb. Traditsiooniline viirusetõrje litsentseeritakse serverite või tööjaamade arvu järgi. Litsentsid, mis katavad kaitstud virtuaalmasinate arvu, ei sobi pilvemudeli raamistikku. Klient saab olemasolevatest ressurssidest luua endale mugava arvu virtuaalmasinaid, näiteks viis või kümme masinat. Enamikul klientidest ei ole see number stabiilne, seega ei ole meie kui teenusepakkuja jaoks võimalik selle muutusi jälgida. Litsentseerida CPU järgi ei ole tehniliselt võimalik: kliendid saavad virtuaalseid protsessoreid (vCPU), mille alusel peaks litsentseerimine toimuma. Seetõttu peaks uus viirusetõrje kaitse mudel võimaldama tellijal määrata vajalik vCPU-de arvu, millele ta soovib viirusetõrje litsentse saada.
Seadusandlusele vastamine. Oluline punkt, kuna rakendatud lahendused peavad tagama regulaatori nõuete täitmise. Näiteks töötavad sageli «pilveelanikud» isiklike andmetega. Sellisel juhul peab teenusepakkuja omama eraldi sertifitseeritud pilvesegmenti, mis vastab täielikult isikuandmeid kaitse seaduse nõuetele. Ettevõtted ei pea enam ise «ehitama» kogu süsteemi isiklike andmetega töötamiseks: ostma sertifitseeritud seadmeid, neid ühendama ja seadistama, korraldama sertifitseerimist. Küberkaitse tagamiseks peaks ka selle klientide ISPDN-i viirusetõrje vastama Venemaa seadusandlikule nõuetele ja omama FSTEK-i sertifikaati.
Oleme arutanud neid kohustuslikke kriteeriume, millele peab vastama viirusetõrje kaitse avalikus pilves. Järgmisena jagame oma kogemusi viirusetõrjelahenduse kohandamisest teenusepakkuja pilves.
Kuidas viirusetõrjet ja pilve sõbralikuks muuta
Kogemuste põhjal on lahenduse valimine kirjelduste ja dokumentatsiooni põhjal üks asi, kuid selle praktikas rakendamine juba toimivas pilves keskkonnas on hoopis teistlaadi keerukus. Räägime, mida me praktikas tegime ja kuidas me kohandasime viirusetõrjet tööks teenusepakkuja avalikus pilves. Viirusetõrje lahenduse tarnijaks on Kaspersky, kelle portfellis on lahendusi pilvekeskkondade viirusetõkkeks. Lõime „Kaspersky Security virtuaalsete keskkondade jaoks” (Kerge agent).
See sisaldab ühte Kaspersky Security Centeri juhtimiskonsooli, kergagent ja turvamasinad (SVM, Security Virtual Machine) ning KSC integreerimisserverit.
Pärast Kaspersky lahenduse arhitektuuri uurimist ja esialgsete testide läbiviimist koos tarnija inseneridega, kerkis küsimus teenuse integreerimisest pilve. Esimene rakendus viidi läbi koostöös Moskva pilveplatvormil. Ja siin on, mida me mõistsime.
Võrgu liikluse minimaalseks vähendamiseks otsustati paigutada iga ESXi-hosti peale SVM ja 'siduda' SVM-i ESXi-hostidega. Sel juhul pöörduvad kergemad agentid kaitstud virtuaalmasinatest SVM-i juurde just selle ESXi-hostiga, millel nad töötavad. Peamiseks KSC-ks valiti eraldi administratiivne tenant. Tulemuseks on see, et alluvad KSC-d paiknevad iga eraldi kliendi tenantides ja pöörduvad kõrgema tasandi KSC poole, mis asub haldussegmendis. Selline skeem võimaldab kiiresti lahendada klientide tenantides tekkivaid probleeme.
Lisaks antiviiruslahenduse komponentide tõstmiseks tekkinud probleemidele seisis meie ees ülesanne korraldada võrgu interaktsiooni lisas VxLANide loomise kaudu. Ja kuigi lahendus oli algselt mõeldud ettevõtte klientidele, kellel on privaatpilved — inseneriteadlikkuse ja NSX Edge tehnilise paindlikkuse abil suutsime lahendada kõik tenantide eristamise ja litsentseerimisega seotud ülesanded.
Me töötasime tihedas koostöös Kaspersky inseneridega. Analüüsides lahenduse arhitektuuri süsteemi komponentide vahelise võrguside osas, selgus, et lisaks kergete agentide juurdepääsule SVM-ile on vajalik ka tagasiside – SVM-ist kergetele agentidele. See võrguside on multitenantilises keskkonnas võimatu, kuna erinevates tenantides võib eksisteerida identseid virtuaalmasinate võrgu seadistusi. Seetõttu töötasid meie palve peale tarnija kolleegid välja võrguside mehhanismi kerge agendi ja SVM vahel, et eemaldada vajadus SVM-i ja kergete agentide vahelise võrguside järele.
Pärast lahenduse juurutamist ja testimist Moskva pilves, laiendasime selle teistele platsidele, sealhulgas sertifitseeritud pilvesektorisse. Praegu on teenus saadaval kõigis riigi piirkondades.
Uue lähenemise raames küberturbe lahenduse arhitektuur
Antiviiruslahenduse üldine tööskeem avalikus pilvekeskkonnas on järgmine:
Antiviiruslahenduse tööskeem avalikus pilvekeskkonnas #CloudMTS
Kirjeldame lahenduse eraldi elementide tegevuse omadusi pilves:
• Ühine paneel, mis võimaldab klientidel keskelt haldada kaitsesüsteemi: teha skaneeringuid, jälgida uuendusi ja vaadata karantiinipiirkondi. On võimalik seadistada isiklikke turvapoliitikaid oma segmentide raames.
Oluline on märkida, et kuigi me oleme teenusepakkuja, ei sekku me klientide seadistustesse. Ainsad võimalused, mis meil on, on turvapoliitikate taastamine vaikeseadesse, kui on vaja üle seadistada. Näiteks võib seda vajada, kui klient on kogemata poliitikaid liiga rangeks muutnud või oluliselt leevendanud. Ettevõte saab alati juurde pääseda juhtimiskeskusele vaikimisi poliitiliste seadistustega, mida nad saavad ise kohandada. Kaspersky Security Centeri miinus on see, et platvorm on praegu saadaval ainult Microsofti operatsioonisüsteemile. Kuigi kerge agendid võivad töötada nii Windowsi kui ka Linuxi masinatega. Kuid „Kaspersky Laboratoorium“ lubab, et peagi hakkab KSC tööle ka Linuxi operatsioonisüsteemiga. Üks KSC olulisi funktsioone on karantiini haldamise võimalus. Igal meie pilves asuval kliendiettevõttel on isiklik karantiin. Selline lähenemine välistab olukorrad, kus viirushaige dokument satub kogemata avalikustamisele, nagu see võiks juhtuda klassikalise ettevõtte viirusetõrje puhul, kus on ühine karantiin.
• Kerge agent. Uue mudeli raames paigaldatakse igale virtuaalmasinale kerge Kaspersky Security agent. See võimaldab mitte hoida viirusetõrje andmebaasi igas VM-is, mis vähendab salvestusruumi mahtu. Teenus on integreeritud pilvi infrastruktuuriga ja töötab SVM-i kaudu, mis suurendab virtuaalmasinate tihedust ESXi hostis ning kogu pilvesüsteemi jõudlust. Kerge agent koostab ülesannete järjekorra iga virtuaalmasina jaoks: kontrollida failisüsteemi, mälu jne. Kuid nende toimingute täitmise eest vastutab juba SVM, millest räägime edasi. Samuti täidab agent tulemüüri funktsioone, kontrollib turvapoliitikaid, saadab nakatunud failid karantiini ja jälgib operatsioonisüsteemi üldist "tervishoidu", millel see on installitud. Kogu seda saab hallata juba mainitud ühtses konsoolis.
• Turvalisus Virtuaalmasin. Kõiki ressursimahukaid ülesandeid (antiviirusfailide uuendused, ajastatud kontrollid) haldab eraldi Turvalisus Virtuaalmasin (SVM). See vastutab täisfunktsionaalse antiviirusmootori ja selle baaside 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, otsivad agente automaatselt teist masinat.
• KSC Integreerimise Server. Üks peamise KSC komponente, mis määrab vastavalt seadistustes määratud algoritmile kergetele agentidele oma SVM-id ning kontrollib SVM-ide kättesaadavust. Seeläbi tagab see programmimoodul koormuse tasakaalustamise kõigi SVM-ide vahel pilvinfrastruktuuris.
Töö algoritm pilves: infrastruktuuri koormuse vähendamine
Antiviirusprogrammi töö algoritmi võib üldiselt kujutada järgmiselt. Agent pöördub faili poole virtuaalses masinas ja kontrollib seda. Kontrolli tulemus salvestatakse ühisesse kesksetesse otsuste andmebaasi SVM (mida nimetatakse Shared Cache), kus iga kirje tuvastab faili unikaalse mustri. Selline lähenemine võimaldab jälgida, et sama faili ei kontrollitaks järjestikku mitu korda (näiteks kui seda avatakse erinevates virtuaalsetes masinates). Fail skannitakse uuesti ainult siis, kui sellesse on tehtud muudatusi või kui kontroll käivitati käsitsi.
Antiviiruslahenduse rakendamine teenusepakkuja pilves
Pildil on kujutatud lahenduse üldstruktuur pilves. Pilve juhtimispiirkonnas on paigutatud peamine Kaspersky Security Center ning igal ESXi-hostil on integreerimisse serveeritud individuaalne SVM (iga ESXi-hostiga on spetsiaalsete seadistustega VMware vCenter Serveris seotud oma SVM). Klientide töö toimub nende pilve segmentides, kus asuvad virtuaalsed masinad agentidega. Need hallatakse individuaalsete KSC-serverite kaudu, mis alluvad peamisele KSC-le. Kui on vajadus kaitsta väikest arvu virtuaalseid masinaid (kuni 5), võib kliendile anda ligipääsu spetsiaalsele pühendatud KSC-serveri virtuaalsele konsoolile. Võrguside kliendi KSC-de ja peamise KSC vahel, samuti kergete agentide ja SVM-i vahel toimub NAT-i kaudu kliendi virtuaalsete EdgeGW marsruuterite abil.
Meie hinnangute ja tarnija kolleegide testitulemuste kohaselt vähendab Kerget agent klientide virtuaalinfrastruktuuri koormust umbes 25% (võrreldes traditsioonilise viirusetõrje programmiga). Eelkõige kasutab standardne viirusetõrje Kaspersky Endpoint Security (KES) füüsilistes keskkondades serveri protsessoriajast peaaegu kaks korda rohkem (2,95%) kui lahendus, mis põhineb kergetel agentidel (1,67%).
Protsessori koormuse võrdluse graafik
Sarnane olukord on täheldatud ka ketta kirjutamise pöördumiste tiheduse osas: klassikalise viirusetõrje puhul on see 1011 IOPS, pilve viirusetõrje puhul aga 671 IOPS.
Ketta pöördumiste tiheduse võrdluse graafik
Töötlemise tulemuslikkus tagab infrastruktuuri stabiilsuse ja arvutusvõimsuse tõhusama kasutamise. Avalikus pilvekeskkonnas töötamise kohandamise kaudu ei vähenda lahendus pilve jõudlust: see teostab failide keskset kontrolli ja värskenduste allalaadimist, jagades koormust. See tähendab, et ühelt poolt ei jää pilvi infrastruktuuri jaoks aktuaalsed ohud märkamata, samas kui teiselt poolt vähenevad nõuded virtuaalmasinate ressurssidele keskmiselt 25% võrreldes traditsioonilise viirusetõrjega.
Funktsionaalsuse poolest meenutavad mõlemad lahendused tugevalt üksteist: allpool on esitatud võrdlustabel. Siiski näitavad ülaltoodud testimistulemused, et pilves on siiski optimaalsem kasutada lahendust virtuaalsete keskkondade jaoks.
Uue lähenemise kauplemisest. Oleme võtnud kasutusele mudeli, mis võimaldab litsentse hankida vCPU arvu järgi. See tähendab, et litsentside arv vastab vCPU arvule. Viirusetõrjet saab testida, esitades taotluse. .
Järgnevas pilootmaterjalis rääkime me pilveteemade evolutsioonist ning sellest, kas valida riistvara, tarkvara või pilv.
Teksti koostasid pilveteenuse pakkuja #CloudMTS töötajad: Denis Mjagkov, peaarhitekt ja Aleksei Afanasev, toote arenduse juht infotehnoloogia valdkonnas.
Allikas: habr.com
