Üha enam kasutajaid toovad kogu oma IT infrastruktuuri avalikku pilve. Kui aga viirusetõrje pole kliendi infrastruktuuris piisav, tekivad tõsised küberriskid. Praktika näitab, et kuni 80% olemasolevatest viirustest elab ideaalselt virtuaalses keskkonnas. Selles postituses räägime sellest, kuidas IT-ressursse avalikus pilves kaitsta ja miks traditsioonilised viirusetõrjed nendel eesmärkidel täielikult ei sobi.
Alustuseks räägime teile, kuidas jõudsime mõttele, et tavalised viirusetõrjevahendid ei sobi avaliku pilve jaoks ja et ressursside kaitsmiseks on vaja muid lähenemisviise.
Esiteks pakuvad teenusepakkujad üldiselt vajalikke meetmeid, et tagada nende pilveplatvormide kõrgetasemeline kaitse. Näiteks #CloudMTS-is analüüsime kogu võrguliiklust, jälgime oma pilve turvasüsteemide logisid ja teeme regulaarselt penteste. Samuti peavad olema turvaliselt kaitstud üksikutele klientidele eraldatud pilvesegmendid.
Teiseks hõlmab küberriskide vastu võitlemise klassikaline võimalus viirusetõrje ja viirusetõrjehaldustööriistade installimist igasse virtuaalmasinasse. Kuid suure hulga virtuaalmasinate puhul võib see praktika olla ebaefektiivne ja nõuda märkimisväärses koguses arvutusressursse, mis omakorda koormab veelgi kliendi infrastruktuuri ja vähendab pilve üldist jõudlust. Sellest on saanud peamine eeltingimus uute lähenemisviiside otsimisel klientide virtuaalmasinate tõhusa viirusetõrje loomiseks.
Lisaks ei ole enamik turul olevaid viirusetõrjelahendusi kohandatud IT-ressursside kaitsmise probleemide lahendamiseks avalikus pilvekeskkonnas. Reeglina on tegemist raskekaaluliste EPP-lahendustega (Endpoint Protection Platforms), mis pealegi ei võimalda pilvepakkuja kliendipoolel vajalikku kohandamist.
Selgub, et traditsioonilised viirusetõrjelahendused ei sobi pilves töötamiseks, kuna need koormavad tõsiselt virtuaalset infrastruktuuri värskenduste ja skannimiste ajal ning neil pole ka vajalikul tasemel rollipõhist haldust ja seadistusi. Järgmisena analüüsime üksikasjalikult, miks pilv vajab viirusetõrjeks uusi lähenemisi.
Mida peaks avalikus pilves olev viirusetõrje suutma
Niisiis, pöörame tähelepanu virtuaalses keskkonnas töötamise eripäradele:
Värskenduste ja plaanitud masskontrollide tõhusus. Kui märkimisväärne hulk traditsioonilist viirusetõrjet kasutavaid virtuaalmasinaid algatab samal ajal uuenduse, tekib pilves nn uuenduste “torm”. Mitut virtuaalmasinat majutava ESXi hosti võimsusest ei pruugi piisata vaikimisi töötavate sarnaste ülesannete hulga lahendamiseks. Pilvepakkuja seisukohast võib selline probleem kaasa tuua lisakoormuse mitmele ESXi hostile, mis lõppkokkuvõttes toob kaasa pilve virtuaalse infrastruktuuri jõudluse languse. See võib muu hulgas mõjutada teiste pilveklientide virtuaalmasinate jõudlust. Sarnane olukord võib tekkida massskannimise käivitamisel: paljude erinevate kasutajate sarnaste päringute samaaegne töötlemine kettasüsteemis mõjutab negatiivselt kogu pilve jõudlust. Suure tõenäosusega mõjutab salvestussüsteemi jõudluse vähenemine kõiki kliente. Sellised järsud koormused ei meeldi ei pakkujale ega tema klientidele, kuna need mõjutavad pilves olevaid "naabreid". Sellest vaatenurgast võib traditsiooniline viirusetõrje kujutada endast suurt probleemi.
Ohutu karantiini. Kui süsteemis tuvastatakse potentsiaalselt viirusega nakatunud fail või dokument, saadetakse see karantiini. Loomulikult saab nakatunud faili kohe kustutada, kuid see pole enamiku ettevõtete jaoks sageli vastuvõetav. Ettevõtete viirusetõrjetel, mis pole kohandatud teenusepakkuja pilves töötama, on reeglina ühine karantiinitsoon - kõik nakatunud objektid satuvad sellesse. Näiteks ettevõtte kasutajate arvutitest leitud. Pilvepakkuja kliendid "elavad" oma segmentides (või üürnikestes). Need segmendid on läbipaistmatud ja isoleeritud: kliendid ei tea üksteisest ega näe loomulikult, mida teised pilves hostivad. Ilmselgelt võib üldine karantiin, millele pääsevad ligi kõik pilves olevad viirusetõrje kasutajad, sisaldada dokumenti, mis sisaldab konfidentsiaalset teavet või ärisaladust. See on pakkuja ja tema klientide jaoks vastuvõetamatu. Seetõttu saab olla ainult üks lahendus – iga kliendi jaoks tema segmendis isiklik karantiin, kuhu teenusepakkujal ega teistel klientidel pole juurdepääsu.
Individuaalsed turvapoliitikad. Iga pilves olev klient on eraldi ettevõte, mille IT-osakond määrab oma turvapoliitikad. Näiteks määravad administraatorid kontrollimise reeglid ja ajastavad viirusetõrjekontrollid. Sellest lähtuvalt peab igal organisatsioonil olema viirusetõrjepoliitikate konfigureerimiseks oma juhtimiskeskus. Samal ajal ei tohiks määratud sätted mõjutada teisi pilvekliente ning pakkuja peaks saama kontrollida, et näiteks viirusetõrje värskendused viiakse läbi tavapäraselt kõigi kliendi virtuaalmasinate puhul.
Arveldamise ja litsentsimise korraldamine. Pilvemudelit iseloomustab paindlikkus ja see hõlmab ainult kliendi kasutatud IT-ressursside mahu eest tasumist. Kui tekib vajadus näiteks hooajalisuse tõttu, siis saab ressursside mahtu kiiresti suurendada või vähendada – seda kõike lähtudes hetkevajadusest arvutusvõimsuse järele. Traditsiooniline viirusetõrje pole nii paindlik – reeglina ostab klient aastaks litsentsi etteantud arvule serveritele või tööjaamadele. Pilvekasutajad ühendavad regulaarselt lahti ja ühendavad täiendavaid virtuaalmasinaid sõltuvalt nende hetkevajadustest – vastavalt peavad viirusetõrjelitsentsid toetama sama mudelit.
Teine küsimus on, mida litsents täpselt hõlmab. Traditsiooniline viirusetõrje on litsentsitud serverite või tööjaamade arvu järgi. Kaitstud virtuaalmasinate arvul põhinevad litsentsid ei sobi pilvemudelisse täielikult. Klient saab olemasolevatest ressurssidest luua suvalise arvu talle sobivaid virtuaalmasinaid, näiteks viis või kümme masinat. See arv ei ole enamiku klientide jaoks konstantne, meil kui pakkujal pole võimalik selle muutusi jälgida. CPU-ga litsentsimise tehniline võimalus puudub: kliendid saavad virtuaalprotsessoreid (vCPU-sid), mida tuleks kasutada litsentsimiseks. Seega peaks uus viirusetõrjemudel sisaldama kliendil võimalust määrata vajalik arv vCPU-sid, mille jaoks ta viirusetõrjelitsentse saab.
Õigusaktide järgimine. Oluline punkt, kuna kasutatavad lahendused peavad tagama vastavuse regulaatori nõuetele. Näiteks pilve "elanikud" töötavad sageli isikuandmetega. Sel juhul peab pakkujal olema eraldi sertifitseeritud pilvesegment, mis vastab täielikult isikuandmete seaduse nõuetele. Siis ei pea ettevõtted iseseisvalt kogu isikuandmetega töötamise süsteemi üles ehitama: ostma sertifitseeritud seadmeid, ühendama ja konfigureerima ning läbima sertifitseerimise. Selliste klientide ISPD küberkaitseks peab viirusetõrje vastama ka Venemaa seadusandluse nõuetele ja omama FSTEC sertifikaati.
Vaatasime läbi kohustuslikud kriteeriumid, millele avalikus pilves olev viirusetõrje peab vastama. Järgmisena jagame oma kogemusi viirusetõrjelahenduse kohandamisel teenusepakkuja pilves töötama.
Kuidas leida sõpru viirusetõrje ja pilve vahel?
Nagu meie kogemus on näidanud, on kirjelduse ja dokumentatsiooni põhjal lahenduse valimine üks asi, kuid juba töötavas pilvekeskkonnas praktikas rakendamine on keerukuse poolest hoopis teine ülesanne. Räägime teile, mida me praktikas tegime ja kuidas kohandasime viirusetõrje teenusepakkuja avalikus pilves töötama. Viirusetõrjelahenduse müüja oli Kaspersky, kelle portfellis on pilvekeskkondade viirusetõrjelahendused. Leppisime valikuga „Kaspersky Security for Virtualization” (Light Agent).
See sisaldab ühte Kaspersky Security Centeri konsooli. Kerged agendid ja turbe virtuaalmasinad (SVM, Security Virtual Machine) ja KSC integratsiooniserver.
Pärast Kaspersky lahenduse arhitektuuri uurimist ja esimesed testid koos müüja inseneridega tekkis küsimus teenuse pilve integreerimise kohta. Esimene rakendamine viidi läbi ühiselt Moskva pilvesaidil. Ja sellest me aru saime.
Võrguliikluse minimeerimiseks otsustati paigutada igale ESXi hostile SVM ja siduda SVM ESXi hostidega. Sel juhul pääsevad kaitstud virtuaalmasinate kerged agendid juurde täpselt selle ESXi hosti SVM-ile, milles nad töötavad. Põhi-KSC-le valiti eraldi haldusüürnik. Selle tulemusel asuvad alluvad KSC-d iga üksiku kliendi rentnike hulgas ja pöörduvad juhtimissegmendis asuva kõrgema KSC poole. See skeem võimaldab teil kiiresti lahendada klientide üürnike probleeme.
Lisaks viirusetõrjelahenduse enda komponentide tõstmisega seotud probleemidele seisime silmitsi ülesandega korraldada võrgusuhtlust täiendavate VxLAN-ide loomise kaudu. Ja kuigi lahendus oli algselt mõeldud privaatpilvedega äriklientidele, suutsime NSX Edge'i inseneritarkuste ja tehnoloogilise paindlikkuse abil lahendada kõik üürnike eraldamise ja litsentsimisega seotud probleemid.
Tegime tihedat koostööd Kaspersky inseneridega. Seega, analüüsides lahenduse arhitektuuri süsteemi komponentide vahelise võrgu interaktsiooni osas, leiti, et lisaks valgusagentidelt SVM-ile juurdepääsule on vajalik ka tagasiside - SVM-ist valgusagentideni. See võrguühendus pole mitme rentniku keskkonnas võimalik, kuna erinevates pilverentnike virtuaalmasinate võrguseaded on identsed. Seetõttu töötasid müüja kolleegid meie palvel ümber valgusagendi ja SVM-i vahelise võrguinteraktsiooni mehhanismi, et kõrvaldada vajadus võrguühenduse järele SVM-ilt kergete agentidega.
Pärast lahenduse juurutamist ja testimist Moskva pilvesaidil kopeerisime selle teistele saitidele, sealhulgas sertifitseeritud pilvesegmendile. Teenus on nüüd saadaval kõigis riigi piirkondades.
Infoturbe lahenduse arhitektuur uudse lähenemise raames
Viirusetõrjelahenduse üldine tööskeem avalikus pilvekeskkonnas on järgmine:
Viirusetõrjelahenduse tööskeem avalikus pilvekeskkonnas #CloudMTS
Kirjeldame lahenduse üksikute elementide toimimise iseärasusi pilves:
• Üks konsool, mis võimaldab klientidel kaitsesüsteemi keskselt hallata: skannida, kontrollida värskendusi ja jälgida karantiinitsoone. Oma segmendis on võimalik konfigureerida individuaalseid turvapoliitikaid.
Tuleb märkida, et kuigi oleme teenusepakkuja, ei sekku me klientide seatud seadistustesse. Ainus, mida saame teha, on lähtestada turvapoliitikad standardsetele, kui on vaja ümberseadistada. Näiteks võib see olla vajalik, kui klient on need kogemata pingutanud või oluliselt nõrgendanud. Ettevõte saab alati saada vaikepoliitikatega juhtimiskeskuse, mida saab seejärel iseseisvalt konfigureerida. Kaspersky Security Centeri puuduseks on see, et platvorm on hetkel saadaval ainult Microsofti operatsioonisüsteemile. Kuigi kergekaalulised agendid võivad töötada nii Windowsi kui ka Linuxi masinatega. Kaspersky Lab lubab aga, et lähiajal hakkab KSC tööle Linux OS-i all. KSC üks olulisi funktsioone on karantiini haldamise võimalus. Igal meie pilve kliendiettevõttel on isiklik. Selline lähenemine välistab olukorrad, kus viirusega nakatatud dokument muutub kogemata avalikult nähtavaks, nagu võib juhtuda üldise karantiiniga ettevõtte klassikalise viirusetõrje puhul.
• Valgusained. Uue mudeli osana on igasse virtuaalmasinasse installitud kerge Kaspersky Security agent. See välistab vajaduse salvestada viirusetõrje andmebaasi igasse VM-i, mis vähendab vajaliku kettaruumi hulka. Teenus on integreeritud pilve infrastruktuuriga ja töötab SVM-i kaudu, mis suurendab ESXi hostis olevate virtuaalmasinate tihedust ja kogu pilvesüsteemi jõudlust. Kerge agent koostab iga virtuaalmasina jaoks ülesannete järjekorra: kontrollige failisüsteemi, mälu jne. Kuid SVM vastutab nende toimingute tegemise eest, millest räägime hiljem. Agent toimib ka tulemüürina, juhib turbepoliitikaid, saadab nakatunud failid karantiini ja jälgib selle operatsioonisüsteemi üldist "tervist", millele see on installitud. Seda kõike saab hallata juba mainitud ühtse konsooli abil.
• Turvaline virtuaalmasin. Kõiki ressursimahukaid ülesandeid (viirusetõrje andmebaasi värskendused, plaanitud kontrollid) tegeleb eraldi turvaline virtuaalmasin (SVM). Ta vastutab täieõigusliku viirusetõrjemootori ja selle andmebaaside toimimise eest. Ettevõtte IT-infrastruktuur võib sisaldada mitut SVM-i. Selline lähenemine suurendab süsteemi töökindlust – kui üks masin ebaõnnestub ja ei reageeri kolmekümne sekundi jooksul, hakkavad agendid automaatselt teist otsima.
• KSC integratsiooniserver. Peamise KSC üks komponente, mis määrab oma SVM-id valgusagentidele vastavalt seadetes määratud algoritmile ja kontrollib ka SVM-ide saadavust. Seega pakub see tarkvaramoodul koormuse tasakaalustamist kõigi pilveinfrastruktuuri SVM-ide vahel.
Pilves töötamise algoritm: infrastruktuuri koormuse vähendamine
Üldiselt võib viirusetõrje algoritmi kujutada järgmiselt. Agent pääseb juurde virtuaalmasinas olevale failile ja kontrollib seda. Kontrollimise tulemus salvestatakse ühisesse tsentraliseeritud SVM-i otsuste andmebaasi (nn Shared Cache), kus iga kirje tuvastab unikaalse failinäidise. Selline lähenemine võimaldab tagada, et sama faili ei kontrollitaks mitu korda järjest (näiteks kui see avati erinevates virtuaalmasinates). Faili skannitakse uuesti ainult siis, kui selles on tehtud muudatusi või skannimist on alustatud käsitsi.
Viirusetõrjelahenduse juurutamine pakkuja pilves
Pildil on pilves lahenduse rakendamise üldskeem. Peamine Kaspersky turvakeskus on juurutatud pilve juhtimistsoonis ja iga ESXi hosti jaoks juurutatakse individuaalne SVM, kasutades KSC integratsiooniserverit (igal ESXi hostil on VMware vCenter Serveris spetsiaalsete sätetega ühendatud oma SVM). Kliendid töötavad oma pilvesegmentides, kus asuvad virtuaalmasinad koos agentidega. Neid hallatakse üksikute KSC serverite kaudu, mis alluvad peamisele KSC-le. Kui on vaja kaitsta väikest hulka virtuaalmasinaid (kuni 5), saab kliendile pakkuda juurdepääsu spetsiaalse KSC-serveri virtuaalsele konsoolile. Klientide KSC-de ja peamise KSC-de, samuti kergete agentide ja SVM-ide vaheline võrgu suhtlus toimub NAT-i abil EdgeGW kliendi virtuaalsete ruuterite kaudu.
Meie hinnangul ja müüja kolleegide testide tulemuste kohaselt vähendab Light Agent klientide virtuaalse infrastruktuuri koormust ligikaudu 25% (võrreldes traditsioonilist viirusetõrjetarkvara kasutava süsteemiga). Eelkõige kulutab tavapärane füüsiliste keskkondade jaoks mõeldud Kaspersky Endpoint Security (KES) viirusetõrje peaaegu kaks korda rohkem serveri protsessori aega (2,95%) kui kerge agendipõhine virtualiseerimislahendus (1,67%).
Protsessori koormuse võrdlustabel
Sarnast olukorda täheldatakse ka kettale kirjutamise juurdepääsu sagedusega: klassikalise viirusetõrje puhul on see 1011 IOPS, pilveviirusetõrje puhul 671 IOPS.
Ketta juurdepääsu määra võrdlusgraafik
Jõudluse eelis võimaldab teil säilitada infrastruktuuri stabiilsust ja kasutada arvutusvõimsust tõhusamalt. Avalikus pilvekeskkonnas töötamiseks kohandudes ei vähenda lahendus pilve jõudlust: see kontrollib tsentraalselt faile ja laadib alla uuendusi, jaotades koormuse. See tähendab, et ühelt poolt ei jää märkamata pilvetaristuga seotud ohud, teisalt väheneb virtuaalmasinate ressursivajadus võrreldes traditsioonilise viirusetõrjega keskmiselt 25%.
Funktsionaalsuse poolest on mõlemad lahendused üksteisega väga sarnased: allpool on võrdlustabel. Pilves aga, nagu ülaltoodud testitulemused näitavad, on siiski optimaalne kasutada virtuaalkeskkondadele mõeldud lahendust.
Tariifidest uue lähenemise raames. Otsustasime kasutada mudelit, mis võimaldab hankida litsentse vCPU-de arvu alusel. See tähendab, et litsentside arv on võrdne vCPU-de arvuga. Saate oma viirusetõrjet testida, jättes päringu .
Järgmises pilveteemalises artiklis räägime pilve WAF-ide arengust ja sellest, mida on parem valida: riistvara, tarkvara või pilv.
Teksti koostasid pilvepakkuja #CloudMTS töötajad: juhtivarhitekt Deniss Mjagkov ja infoturbe tootearendusjuht Aleksei Afanasjev.
Allikas: www.habr.com