Al hoe meer gebruikers bring hul hele IT-infrastruktuur na die publieke wolk. In die geval van onvoldoende antivirusbeheer in die infrastruktuur van die kliënt, ontstaan ernstige kuberrisiko's. Praktyk toon dat tot 80% van bestaande virusse perfek in 'n virtuele omgewing leef. In hierdie pos sal ons praat oor hoe om IT-hulpbronne in die openbare wolk te beskerm en waarom tradisionele antivirusse nie heeltemal geskik is vir hierdie doel nie.
Om mee te begin, sal ons jou vertel hoe ons by die idee gekom het dat die gewone antivirusbeskermingsinstrumente nie geskik is vir 'n publieke wolk nie en ander benaderings om hulpbronne te beskerm is nodig.
Eerstens verskaf verskaffers as 'n reël die nodige maatreëls om te verseker dat hul wolkplatforms op 'n hoë vlak beskerm word. Byvoorbeeld, ons by #CloudMTS ontleed alle netwerkverkeer, monitor die sekuriteitlogboeke van ons wolk en voer gereeld pentoetse uit. Wolksegmente wat aan individuele kliënte gegee word, moet ook veilig beskerm word.
Tweedens, die klassieke manier om kuberrisiko's te hanteer, behels die installering van 'n antivirus- en antivirusbestuurnutsmiddel op elke virtuele masjien. Met 'n groot aantal virtuele masjiene kan hierdie praktyk egter ondoeltreffend wees en aansienlike hoeveelhede rekenaarhulpbronne vereis, en sodoende die kliënt se infrastruktuur bykomend laai en die algehele werkverrigting van die wolk verminder. Dit het 'n sleutelvoorvereiste geword om nuwe benaderings te vind om effektiewe antivirusbeskerming vir kliënte se virtuele masjiene te bou.
Daarbenewens is die meeste antivirusoplossings op die mark nie aangepas om die uitdagings van die beskerming van IT-hulpbronne in 'n openbare wolkomgewing die hoof te bied nie. As 'n reël is dit swaargewig EPP-oplossings (Endpoint Protection Platforms), wat boonop nie die nodige aanpassing aan die kant van die wolkverskaffer se kliënte toelaat nie.
Dit word duidelik dat tradisionele antivirusoplossings nie goed geskik is om in die wolk te werk nie, aangesien dit die virtuele infrastruktuur ernstig laai tydens opdaterings en skanderings, en ook nie die nodige rolbestuurvlakke en instellings het nie. Vervolgens sal ons die redes waarom die wolk nuwe benaderings tot antivirusbeskerming benodig, in detail ontleed.
Wat antivirus in 'n publieke wolk moet kan doen
Dus, laat ons aandag gee aan die besonderhede van werk in 'n virtuele omgewing:
Doeltreffendheid van opdaterings en geskeduleerde massakontroles. As 'n aansienlike aantal virtuele masjiene wat tradisionele antivirus gebruik, 'n opdatering op dieselfde tyd inisieer, sal 'n sogenaamde "storm" van opdaterings in die wolk voorkom. Die krag van 'n ESXi-gasheer wat verskeie virtuele masjiene huisves, is dalk nie genoeg om 'n vlaag van dieselfde tipe take te hanteer wat by verstek begin word nie. Uit die oogpunt van 'n wolkverskaffer kan so 'n probleem lei tot bykomende vragte op 'n aantal ESXi-gashere, wat uiteindelik sal lei tot 'n daling in die werkverrigting van die wolk virtuele infrastruktuur. Dit kan onder andere die werkverrigting van virtuele masjiene van ander wolkkliënte beïnvloed. 'n Soortgelyke situasie kan ontstaan wanneer 'n massaskandering begin word: gelyktydige verwerking deur die skyfstelsel van baie versoeke van dieselfde tipe van verskillende gebruikers sal die werkverrigting van die hele wolk negatief beïnvloed. Met 'n hoë mate van waarskynlikheid sal 'n afname in die werkverrigting van bergingstelsels alle kliënte raak. Sulke intermitterende vragte behaag nie die verskaffer of sy kliënte nie, aangesien dit die "bure" in die wolk beïnvloed. Vanuit hierdie oogpunt kan tradisionele antivirus 'n groot probleem wees.
Veilige kwarantyn. As 'n lêer of dokument wat moontlik met 'n virus besmet is, in die stelsel gevind word, word dit na kwarantyn gestuur. Natuurlik kan die besmette lêer onmiddellik uitgevee word, maar dit is dikwels nie aanvaarbaar vir die meeste maatskappye nie. Korporatiewe onderneming-antivirusse wat nie aangepas is om in die verskaffer se wolk te werk nie, het as 'n reël 'n gemeenskaplike kwarantynsone - alle besmette voorwerpe val daarin. Byvoorbeeld, gevind op die rekenaars van maatskappy gebruikers. Die kliënte van die wolkverskaffer "woon" in hul eie segmente (of huurders). Hierdie segmente is ondeursigtig en geïsoleer: kliënte weet nie van mekaar nie en sien natuurlik nie wat ander in die wolk aanbied nie. Uiteraard kan 'n dokument wat vertroulike inligting of 'n handelsgeheim bevat moontlik by die algemene kwarantyn ingesluit word, wat deur alle gebruikers van die antivirus in die wolk verkry sal word. Dit is onaanvaarbaar vir die verskaffer en sy kliënte. Daarom kan daar net een oplossing wees - dit is 'n persoonlike kwarantyn vir elke kliënt in sy segment, waar nóg die verskaffer nóg ander kliënte toegang het.
Individuele sekuriteitsbeleide. Elke kliënt in die wolk is 'n aparte maatskappy wie se IT-afdeling sy eie sekuriteitsbeleide stel. Byvoorbeeld, administrateurs definieer skanderingsreëls en skedulering van antiviruskontroles. Gevolglik moet elke organisasie sy eie beheersentrum hê om antivirusbeleide op te stel. Terselfdertyd behoort die gespesifiseerde instellings nie ander wolkkliënte te beïnvloed nie, en die verskaffer moet seker kan maak dat, byvoorbeeld, antivirusopdaterings normaalweg vir alle virtuele kliëntmasjiene loop.
Organisasie van faktuur en lisensiëring. Die wolkmodel is buigsaam en behels dat slegs betaal word vir die hoeveelheid IT-hulpbronne wat deur die kliënt gebruik is. As daar 'n behoefte is, byvoorbeeld as gevolg van die seisoenaliteitsfaktor, dan kan die hoeveelheid hulpbronne vinnig verhoog of verminder word - alles gebaseer op die huidige behoeftes vir rekenaarkrag. Tradisionele antivirus is nie so buigsaam nie - as 'n reël koop die kliënt 'n lisensie vir 'n jaar vir 'n voorafbepaalde aantal bedieners of werkstasies. Wolkgebruikers, aan die ander kant, ontkoppel en koppel gereeld bykomende virtuele masjiene na gelang van hul huidige behoeftes – dienooreenkomstig moet antiviruslisensies dieselfde model ondersteun.
Die tweede vraag is wat presies deur die lisensie gedek sal word. Tradisionele antivirus word gelisensieer deur die aantal bedieners of werkstasies. Lisensies vir die aantal beskermde virtuele masjiene pas nie heeltemal binne die wolkmodel nie. Die kliënt kan enige aantal virtuele masjiene skep wat vir hom gerieflik is uit die beskikbare hulpbronne, byvoorbeeld vyf of tien masjiene. Hierdie getal is nie konstant vir die meeste kliënte nie, en dit is nie vir ons, as 'n verskaffer, moontlik om die verandering daarvan op te spoor nie. Dit is nie tegnies moontlik om volgens SVE te lisensieer nie: kliënte ontvang virtuele verwerkers (vCPU's), wat vir lisensiëring gebruik moet word. Die nuwe model van antivirusbeskerming behoort dus die kliënt in staat te stel om die vereiste aantal vCPU's te bepaal waarvoor hy antiviruslisensies sal ontvang.
Wetlike nakoming. 'n Belangrike punt, aangesien die toegepaste oplossings voldoening aan die vereistes van die reguleerder moet verseker. Byvoorbeeld, dikwels werk die "inwoners" van die wolk met persoonlike data. In hierdie geval moet die verskaffer 'n aparte gesertifiseerde wolksegment hê wat ten volle aan die vereistes van die Wet op Persoonlike Data voldoen. Dan hoef maatskappye nie die hele stelsel op hul eie te "bou" om met persoonlike data te werk nie: koop gesertifiseerde toerusting, koppel dit en konfigureer dit, en slaag sertifisering. Om die ISPD's van sulke kliënte te beskerm, moet die antivirus ook aan die vereistes van Russiese wetgewing voldoen en 'n FSTEC-sertifikaat hê.
Ons het die verpligte kriteria wat deur antivirusbeskerming in die publieke wolk nagekom moet word, hersien. Vervolgens sal ons ons eie ervaring deel met die aanpassing van 'n antivirusoplossing om in die verskaffer se wolk te werk.
Hoe kan jy vriende maak tussen antivirus en die wolk
Soos ons ondervinding getoon het, is die keuse van 'n oplossing gebaseer op beskrywing en dokumentasie een ding, maar die implementering daarvan in die praktyk in 'n reeds werkende wolkomgewing is 'n heeltemal ander taak wat kompleksiteit betref. Ons sal jou vertel wat ons in die praktyk gedoen het en hoe ons die antivirus aangepas het om in die verskaffer se publieke wolk te werk. Die verkoper van die antivirusoplossing is Kaspersky, wat antivirusbeskermingsoplossings vir wolkomgewings in sy portefeulje het. Ons het besluit op Kaspersky Security for Virtualization (Light Agent).
Dit bevat 'n enkele konsole van Kaspersky Security Center. Ligte agent en sekuriteit virtuele masjiene (SVM, Security Virtual Machine) en KSC integrasie bediener.
Nadat ons die argitektuur van die Kaspersky-oplossing bestudeer het en die eerste toetse saam met die verkoper se ingenieurs uitgevoer het, het die vraag ontstaan om die diens in die wolk te integreer. Die eerste implementering is gesamentlik op die Moskou-wolkwerf uitgevoer. En hier is wat ons verstaan het.
Om netwerkverkeer tot die minimum te beperk, is besluit om 'n SVM op elke ESXi-gasheer te plaas en die SVM aan ESXi-gashere te "heg". In hierdie geval het die ligagente van die beskermde virtuele masjiene toegang tot die SVM van die ESXi-gasheer waarop hulle loop. 'n Aparte administratiewe huurder is vir die hoof-KSC gekies. Gevolglik is ondergeskikte KSC's in die huurders van elke individuele kliënt geleë en kry toegang tot die voortreflike KSC wat in die bestuursegment geleë is. Hierdie skema laat jou toe om probleme wat by huurders van kliënte ontstaan, vinnig op te los.
Benewens die probleme met die verhoging van die komponente van die anti-virus oplossing self, het ons gekonfronteer met die taak om netwerkinteraksie te organiseer deur die skepping van bykomende VxLAN's. En hoewel die oplossing oorspronklik bedoel was vir ondernemingskliënte met private wolke, het ons met die hulp van ingenieursvernuf en tegnologiese buigsaamheid van NSX Edge daarin geslaag om al die probleme op te los wat verband hou met die skeiding van huurders en lisensiëring.
Ons het nou saamgewerk met Kaspersky-ingenieurs. Dus, in die proses om die oplossingargitektuur te ontleed in terme van netwerkinteraksie tussen stelselkomponente, is gevind dat, benewens toegang van ligagente na SVM, ook terugvoer nodig is - van SVM tot ligagente. Hierdie netwerkverbinding is nie moontlik in 'n multitenant-omgewing nie as gevolg van die moontlikheid van identiese netwerkinstellings van virtuele masjiene in verskillende wolkhuurders. Daarom, op ons versoek, het kollegas van die verkoper die netwerkinteraksiemeganisme tussen die ligagent en SVM herontwerp in terme van die uitskakeling van die behoefte aan netwerkverbinding van SVM na ligagente.
Nadat die oplossing op die Moskou-wolkwerf ontplooi en getoets is, het ons dit na ander werwe herhaal, insluitend die gesertifiseerde wolksegment. Die diens is nou beskikbaar in alle streke van die land.
Die argitektuur van die inligtingsekuriteitsoplossing binne die raamwerk van die nuwe benadering
Die algemene skema van hoe 'n antivirusoplossing in 'n publieke wolkomgewing werk, is soos volg:
Die skema van die antivirusoplossing in die publieke wolkomgewing #CloudMTS
Kom ons beskryf die kenmerke van die werking van individuele elemente van die oplossing in die wolk:
• 'n Enkele konsole wat kliënte in staat stel om die beskermingstelsel sentraal te bestuur: skanderings uitvoer, opdaterings beheer en kwarantynsones monitor. Dit is moontlik om individuele sekuriteitsbeleide binne u segment op te stel.
Daar moet kennis geneem word dat alhoewel ons 'n diensverskaffer is, ons nie inmeng met die instellings wat deur kliënte gestel word nie. Die enigste ding wat ons kan doen is om die sekuriteitsbeleide terug te stel na verstek ingeval 'n herkonfigurasie nodig is. Dit kan byvoorbeeld nodig wees as die kliënt hulle per ongeluk styfgedraai of aansienlik losgemaak het. 'n Maatskappy kan altyd 'n beheersentrum met verstekbeleide kry, wat hulle dan op hul eie kan instel. Die nadeel van Kaspersky Security Center is dat die platform tot dusver slegs vir die Microsoft-bedryfstelsel beskikbaar is. Alhoewel ligte agente met beide Windows- en Linux-masjiene kan werk. Kaspersky Lab beloof egter dat KSC in die nabye toekoms onder Linux OS sal werk. Een van die belangrike kenmerke van KSC is die vermoë om kwarantyn te bestuur. Elke kliëntmaatskappy in ons wolk het 'n persoonlike een. Hierdie benadering skakel situasies uit wanneer 'n virus-geïnfekteerde dokument per ongeluk op die publiek vertoon word, soos wat kan gebeur in die geval van 'n klassieke korporatiewe antivirus met 'n algemene kwarantyn.
• Ligte middels. As deel van die nuwe model word 'n liggewig Kaspersky Security-agent op elke virtuele masjien geïnstalleer. Dit laat jou toe om nie die anti-virus databasis op elke VM te stoor nie, wat die hoeveelheid skyfspasie wat beset word, verminder. Die diens is geïntegreer met die wolkinfrastruktuur en werk deur SVM, wat die digtheid van virtuele masjiene op die ESXi-gasheer en die werkverrigting van die hele wolkstelsel verhoog. Die ligagent bou 'n ry take vir elke virtuele masjien: kontroleer die lêerstelsel, geheue, ens. Maar die SVM is verantwoordelik vir die uitvoering van hierdie operasies, waaroor ons later sal praat. Die agent voer ook die funksies van 'n brandmuur uit, beheer sekuriteitsbeleide, stuur besmette lêers na kwarantyn, en monitor die algehele "gesondheid" van die bedryfstelsel waarop dit geïnstalleer is. Dit alles kan bestuur word met behulp van die reeds genoemde enkele konsole.
• Sekuriteit virtuele masjien. Alle hulpbron-intensiewe take (opdatering van anti-virus databasisse, geskeduleerde skanderings) word deur 'n aparte Security Virtual Machine (SVM) hanteer. Sy is verantwoordelik vir die werk van 'n volwaardige antivirus-enjin en databasisse daarvoor. 'n Maatskappy se IT-infrastruktuur kan verskeie SVM's insluit. Hierdie benadering verhoog die betroubaarheid van die stelsel – as 'n masjien faal en vir dertig sekondes nie reageer nie, begin agente outomaties na 'n ander een soek.
• KSC-integrasiebediener. Een van die komponente van die hoof-KSC, wat sy SVM's aan ligte agente toewys in ooreenstemming met die algoritme wat in sy instellings gespesifiseer word, en ook die beskikbaarheid van SVM's beheer. Hierdie sagtewaremodule bied dus lasbalansering vir alle SVM's van die wolkinfrastruktuur.
Algoritme om in die wolk te werk: die las op die infrastruktuur te verminder
Oor die algemeen kan die antivirus-bewerkingsalgoritme soos volg voorgestel word. Die agent kry toegang tot die lêer op die virtuele masjien en kontroleer dit. Die resultaat van die tjek word gestoor in 'n gemeenskaplike gesentraliseerde databasis van SVM-uitsprake (dit word Shared Cache genoem), elke inskrywing waarin 'n unieke lêermonster identifiseer. Hierdie benadering laat jou toe om te verseker dat dieselfde lêer nie verskeie kere in 'n ry nagegaan word nie (byvoorbeeld as dit op verskillende virtuele masjiene oopgemaak is). Die lêer word slegs herskandeer as dit gewysig is of die skandering met die hand begin is.
Implementering van 'n anti-virus oplossing in die verskaffer se wolk
Die prent toon 'n algemene skema vir die implementering van 'n oplossing in die wolk. In die beheersone van die wolk word die hoof-Kaspersky-sekuriteitsentrum ontplooi, en 'n individuele SVM word op elke ESXi-gasheer ontplooi deur die KSC-integrasiebediener te gebruik (elke ESXi-gasheer het sy eie SVM wat geassosieer word met spesiale instellings op die VMware vCenter Server). Kliënte werk in hul eie wolksegmente, wat virtuele masjiene by agente huisves. Hulle word bestuur deur individuele KSC-bedieners wat ondergeskik is aan die hoof-KSC. As dit nodig is om 'n klein aantal virtuele masjiene (tot 5) te beskerm, kan die kliënt toegang verleen word tot die virtuele konsole van 'n spesiale toegewyde KSC-bediener. Netwerkkommunikasie tussen kliënt-KSC's en die hoof-KSC, sowel as ligte agente en SVM's, word uitgevoer met behulp van NAT deur EdgeGW-kliënt virtuele routers.
Volgens ons skattings en die resultate van toetse deur kollegas in die verskaffer, verminder Light Agent die las op die virtuele infrastruktuur van kliënte met ongeveer 25% (in vergelyking met 'n stelsel wat tradisionele anti-virus sagteware gebruik). In die besonder verbruik die standaard Kaspersky Endpoint Security (KES)-antivirus vir fisiese omgewings byna twee keer soveel bediener-SVE-tyd (2,95%) as die ligte agent-gebaseerde virtualiseringsoplossing (1,67%).
SVE vrag vergelyking grafiek
'n Soortgelyke situasie word waargeneem met die frekwensie van skryfskyftoegange: vir 'n klassieke antivirus is dit 1011 IOPS, vir 'n wolk-antivirus is dit 671 IOPS.
Skyftoegangkoersvergelykingsgrafiek
Prestasiewinste help om infrastruktuurstabiliteit te handhaaf en om rekenaarkrag doeltreffender te gebruik. Deur aan te pas om in 'n publieke wolkomgewing te werk, verminder die oplossing nie die werkverrigting van die wolk nie: dit kontroleer sentraal lêers en laai opdaterings af, en versprei die vrag. Dit beteken dat aan die een kant bedreigings wat relevant is vir die wolkinfrastruktuur nie gemis sal word nie, aan die ander kant sal die vereistes vir virtuele masjienhulpbronne met gemiddeld 25% verminder word in vergelyking met tradisionele antivirus.
Wat funksionaliteit betref, is albei oplossings baie soortgelyk aan mekaar: hieronder is 'n vergelykingstabel. In die wolk, soos die toetsresultate hierbo toon, is dit egter steeds die beste om 'n oplossing vir virtuele omgewings te gebruik.
Oor faktuur binne die raamwerk van die nuwe benadering. Ons het besluit om 'n model te gebruik wat jou toelaat om lisensies te bekom volgens die aantal vCPU's. Dit beteken dat die aantal lisensies gelyk sal wees aan die aantal vCPU's. Antivirus kan getoets word deur 'n versoek te los .
In die volgende wolkverwante artikel sal ons praat oor die evolusie van wolk WAF's en wat beter is om te kies: hardeware, sagteware of wolk.
Die teks is voorberei deur werknemers van die #CloudMTS-wolkverskaffer: Denis Myagkov, hoofargitek en Alexey Afanasiev, inligtingsekuriteitsprodukontwikkelingsbestuurder.
Bron: will.com