Pli kaj pli da uzantoj alportas sian tutan IT-infrastrukturon al la publika nubo. Tamen, se kontraŭvirusa kontrolo estas nesufiĉa en la infrastrukturo de la kliento, seriozaj ciberriskoj aperas. Praktiko montras, ke ĝis 80% de ekzistantaj virusoj vivas perfekte en virtuala medio. En ĉi tiu afiŝo ni parolos pri kiel protekti IT-resursojn en la publika nubo kaj kial tradiciaj antivirusoj ne estas tute taŭgaj por ĉi tiuj celoj.
Komence, ni rakontos al vi kiel ni venis al la ideo, ke la kutimaj kontraŭvirusaj protektaj iloj ne taŭgas por la publika nubo kaj ke aliaj aliroj por protekti rimedojn estas postulataj.
Unue, provizantoj ĝenerale provizas la necesajn mezurojn por certigi, ke iliaj nubaj platformoj estas protektitaj altnivele. Ekzemple, ĉe #CloudMTS ni analizas la tutan retan trafikon, monitoras protokolojn de la sekurecaj sistemoj de nia nubo kaj regule faras pentestojn. Nubaj segmentoj asignitaj al individuaj klientoj ankaŭ devas esti sekure protektitaj.
Due, la klasika opcio por kontraŭbatali ciberriskojn implikas instali antivirusajn kaj antivirusajn administrajn ilojn sur ĉiu virtuala maŝino. Tamen, kun granda nombro da virtualaj maŝinoj, ĉi tiu praktiko povas esti neefika kaj postuli signifajn kvantojn da komputikresursoj, tiel plue ŝarĝante la infrastrukturon de la kliento kaj reduktante la ĝeneralan rendimenton de la nubo. Ĉi tio fariĝis ŝlosila antaŭkondiĉo por serĉi novajn alirojn por konstrui efikan kontraŭvirusan protekton por klientaj virtualaj maŝinoj.
Krome, plej multaj kontraŭvirusaj solvoj sur la merkato ne estas adaptitaj por solvi la problemojn pri protektado de IT-resursoj en publika nuba medio. Kiel regulo, ili estas pezaj EPP-solvoj (Endpoint Protection Platforms), kiuj, krome, ne provizas la necesan personigon ĉe la klienta flanko de la nuba provizanto.
Evidentiĝas, ke tradiciaj kontraŭvirusaj solvoj ne taŭgas por labori en la nubo, ĉar ili serioze ŝarĝas la virtualan infrastrukturon dum ĝisdatigoj kaj skanadoj, kaj ankaŭ ne havas la necesajn nivelojn de rol-bazita administrado kaj agordoj. Poste, ni analizos detale kial la nubo bezonas novajn alirojn al kontraŭvirusa protekto.
Kion antiviruso en publika nubo devus povi fari
Do, ni atentu la specifaĵojn pri laborado en virtuala medio:
Efikeco de ĝisdatigoj kaj planitaj amasskanadoj. Se signifa nombro da virtualaj maŝinoj uzantaj tradician antiviruson komencas ĝisdatigon samtempe, tiel nomata "ŝtormo" de ĝisdatigoj okazos en la nubo. La potenco de ESXi-gastiganto, kiu gastigas plurajn virtualajn maŝinojn, eble ne sufiĉas por trakti la bombardon de similaj taskoj defaŭlte. El la vidpunkto de la nuba provizanto, tia problemo povas konduki al pliaj ŝarĝoj sur kelkaj ESXi-gastigantoj, kio finfine kondukos al malpliigo de la rendimento de la nuba virtuala infrastrukturo. Ĉi tio povas, interalie, influi la agadon de virtualaj maŝinoj de aliaj nubaj klientoj. Simila situacio povas aperi dum lanĉo de amasa skanado: samtempa prilaborado de la disksistemo de multaj similaj petoj de malsamaj uzantoj negative influos la agadon de la tuta nubo. Kun alta grado de probableco, malkresko en stokada agado de la sistemo influos ĉiujn klientojn. Tiaj abruptaj ŝarĝoj ne plaĉas nek al la provizanto nek al liaj klientoj, ĉar ili influas la "najbarojn" en la nubo. De ĉi tiu vidpunkto, tradicia antiviruso povas prezenti grandan problemon.
Sekura kvaranteno. Se dosiero aŭ dokumento potenciale infektita kun viruso estas detektita en la sistemo, ĝi estas sendita al kvaranteno. Kompreneble, infektita dosiero povas esti forigita tuj, sed ĉi tio ofte ne estas akceptebla por plej multaj kompanioj. Korporaciaj entreprenaj antivirusoj, kiuj ne taŭgas por labori en la nubo de la provizanto, kutime havas komunan kvarantenan zonon - ĉiuj infektitaj objektoj falas en ĝin. Ekzemple, tiuj trovitaj en la komputiloj de firmaaj uzantoj. Klientoj de la nuba provizanto "vivas" en siaj propraj segmentoj (aŭ luantoj). Ĉi tiuj segmentoj estas maldiafanaj kaj izolitaj: klientoj ne scias unu pri la alia kaj, kompreneble, ne vidas, kion aliaj gastigas en la nubo. Evidente, la ĝenerala kvaranteno, kiu estos alirebla de ĉiuj antivirusaj uzantoj en la nubo, eble povus inkluzivi dokumenton enhavantan konfidencajn informojn aŭ komercan sekreton. Ĉi tio estas neakceptebla por la provizanto kaj ĝiaj klientoj. Sekve, povas esti nur unu solvo - persona kvaranteno por ĉiu kliento en sia segmento, kie nek la provizanto nek aliaj klientoj havas aliron.
Individuaj sekurecaj politikoj. Ĉiu kliento en la nubo estas aparta firmao, kies IT-fako fiksas siajn proprajn sekurecpolitikojn. Ekzemple, administrantoj difinas skanajn regulojn kaj planas kontraŭvirusajn skanaĵojn. Sekve, ĉiu organizo devas havi sian propran kontrolcentron por agordi kontraŭvirusajn politikojn. Samtempe, la specifitaj agordoj ne devas influi aliajn nubajn klientojn, kaj la provizanto devus povi kontroli, ke ekzemple antivirusaj ĝisdatigoj estas efektivigitaj normale por ĉiuj klientaj virtualaj maŝinoj.
Organizo de fakturado kaj licencado. La nuba modelo estas karakterizita per fleksebleco kaj implikas pagi nur por la kvanto de IT-resursoj, kiuj estis uzitaj de la kliento. Se ekzistas bezono, ekzemple, pro sezoneco, tiam la kvanto de rimedoj povas esti rapide pliigita aŭ reduktita - ĉio surbaze de la nunaj bezonoj por komputa potenco. Tradicia antiviruso ne estas tiel fleksebla - kiel regulo, la kliento aĉetas permesilon por jaro por antaŭfiksita nombro da serviloj aŭ laborstacioj. Nubo-uzantoj regule malkonekti kaj konekti pliajn virtualajn maŝinojn depende de siaj nunaj bezonoj - sekve, antivirusaj permesiloj devas subteni la saman modelon.
La dua demando estas, kion precize kovros la permesilo. Tradicia antiviruso estas licencita laŭ la nombro da serviloj aŭ laborstacioj. Licencoj bazitaj sur la nombro da protektitaj virtualaj maŝinoj ne estas tute taŭgaj ene de la nuba modelo. La kliento povas krei ajnan nombron da virtualaj maŝinoj oportunaj por li el la disponeblaj rimedoj, ekzemple, kvin aŭ dek maŝinoj. Ĉi tiu nombro ne estas konstanta por plej multaj klientoj; ne eblas por ni, kiel provizanto, spuri ĝiajn ŝanĝojn. Ne ekzistas teknika ebleco licenci per CPU: klientoj ricevas virtualajn procesorojn (vCPUs), kiuj devus esti uzataj por licencado. Tiel, la nova kontraŭvirusa protekto-modelo devus inkluzivi la kapablon por la kliento determini la postulatan nombron da vCPU-oj por kiuj li ricevos kontraŭvirusajn licencojn.
Konformo al leĝaro. Grava punkto, ĉar la uzitaj solvoj devas certigi konformecon al la postuloj de la reguligisto. Ekzemple, nubaj "loĝantoj" ofte laboras kun personaj datumoj. En ĉi tiu kazo, la provizanto devas havi apartan atestitan nuban segmenton, kiu plene konformas al la postuloj de la Leĝo pri Personaj Datumoj. Tiam kompanioj ne bezonas sendepende "konstrui" la tutan sistemon por labori kun personaj datumoj: aĉeti atestitan ekipaĵon, konekti kaj agordi ĝin, kaj sperti atestilon. Por ciberprotekto de la ISPD de tiaj klientoj, la antiviruso ankaŭ devas plenumi la postulojn de rusa leĝaro kaj havi FSTEC-atestilon.
Ni rigardis la devigajn kriteriojn, kiujn devas plenumi kontraŭvirusa protekto en la publika nubo. Poste, ni dividos nian propran sperton pri adaptado de antivirusa solvo por labori en la nubo de la provizanto.
Kiel vi povas amikiĝi inter antiviruso kaj nubo?
Kiel montris nia sperto, elekti solvon bazitan sur priskribo kaj dokumentado estas unu afero, sed efektivigi ĝin praktike en jam funkcianta nuba medio estas tute alia tasko laŭ komplekseco. Ni rakontos al vi, kion ni faris praktike kaj kiel ni adaptis la antiviruson por funkcii en la publika nubo de la provizanto. La vendisto de la kontraŭvirusa solvo estis Kaspersky, kies biletujo inkluzivas kontraŭvirusajn protektosolvojn por nubaj medioj. Ni decidis por "Kaspersky Security for Virtualization" (Lumo-Agente).
Ĝi inkluzivas ununuran konzolon de Kaspersky Security Center. Malpeza agento kaj sekurecaj virtualaj maŝinoj (SVM, Security Virtual Machine) kaj KSC-integra servilo.
Post kiam ni studis la arkitekturon de la solvo de Kaspersky kaj faris la unuajn provojn kune kun la inĝenieroj de la vendisto, aperis la demando pri integriĝo de la servo en la nubon. La unua efektivigo estis farita kune ĉe la Moskva nuba loko. Kaj tion ni konstatis.
Por minimumigi retan trafikon, oni decidis meti SVM sur ĉiu ESXi-gastiganto kaj "ligi" la SVM al la ESXi-gastigantoj. En ĉi tiu kazo, malpezaj agentoj de protektitaj virtualaj maŝinoj aliras la SVM de la ĝusta ESXi-gastiganto sur kiu ili funkcias. Aparta administra luanto estis selektita por la ĉefa KSC. Kiel rezulto, malĉefaj KSCoj situas en la luantoj de ĉiu individua kliento kaj alparolas la superan KSC situantan en la administradsegmento. Ĉi tiu skemo permesas vin rapide solvi problemojn, kiuj ŝprucas ĉe klientaj luantoj.
Krom problemoj pri altigado de la komponantoj de la kontraŭvirusa solvo mem, ni alfrontis la taskon organizi retan interagadon per kreado de pliaj VxLAN-oj. Kaj kvankam la solvo estis origine destinita por entreprenaj klientoj kun privataj nuboj, kun la helpo de la inĝenieristiko kaj teknologia fleksebleco de NSX Edge ni povis solvi ĉiujn problemojn asociitajn kun la apartigo de luantoj kaj licencado.
Ni laboris proksime kun Kaspersky-inĝenieroj. Tiel, en la procezo de analizado de la solva arkitekturo laŭ reto-interago inter sistemaj komponantoj, oni trovis, ke, krom aliro de malpezaj agentoj al SVM, ankaŭ necesas retrosciigo - de SVM al malpezaj agentoj. Ĉi tiu retkonektebleco ne eblas en plurluanto-medio pro la ebleco de identaj retaj agordoj de virtualaj maŝinoj en malsamaj nubaj luantoj. Sekve, laŭ nia peto, kolegoj de la vendisto relaboris la mekanismon de interagado de reto inter la malpeza agento kaj SVM koncerne forigi la bezonon de reta konektebleco de SVM al malpezaj agentoj.
Post kiam la solvo estis deplojita kaj provita sur la Moskva nuba retejo, ni reproduktis ĝin al aliaj retejoj, inkluzive de la atestita nuba segmento. La servo nun disponeblas en ĉiuj regionoj de la lando.
Arkitekturo de informsekureca solvo en la kadro de nova aliro
La ĝenerala skemo de funkciado de antivirusa solvo en publika nuba medio estas jena:
Skemo de funkciado de kontraŭvirusa solvo en publika nuba medio #CloudMTS
Ni priskribu la funkciojn de la funkciado de individuaj elementoj de la solvo en la nubo:
• Ununura konzolo, kiu permesas al klientoj centre administri la protektan sistemon: ruli skanojn, kontroli ĝisdatigojn kaj monitori kvarantenzonojn. Eblas agordi individuajn sekurecpolitikojn ene de via segmento.
Oni devas rimarki, ke kvankam ni estas provizanto de servoj, ni ne malhelpas la agordojn fiksitajn de klientoj. La nura afero, kiun ni povas fari, estas restarigi la sekurecpolitikojn al normaj se reagordo estas necesa. Ekzemple, ĉi tio povas esti necesa se la kliento hazarde streĉis ilin aŭ signife malfortigis ilin. Firmao ĉiam povas ricevi kontrolcentron kun defaŭltaj politikoj, kiujn ĝi tiam povas agordi sendepende. La malavantaĝo de Kaspersky Security Center estas, ke la platformo nuntempe disponeblas nur por la Microsoft operaciumo. Kvankam malpezaj agentoj povas labori kun kaj Vindozo kaj Linukso maŝinoj. Tamen, Kaspersky Lab promesas, ke en proksima estonteco KSC funkcios sub Linukso OS. Unu el la gravaj funkcioj de KSC estas la kapablo administri kvarantenon. Ĉiu klienta kompanio en nia nubo havas personan. Ĉi tiu aliro forigas situaciojn kie dokumento infektita per viruso hazarde iĝas publike videbla, kiel povus okazi en la kazo de klasika kompania antiviruso kun ĝenerala kvaranteno.
• Mildaj agentoj. Kiel parto de la nova modelo, malpeza Kaspersky Security agento estas instalita sur ĉiu virtuala maŝino. Ĉi tio forigas la bezonon stoki la kontraŭvirusan datumbazon sur ĉiu VM, kio reduktas la kvanton da diskospaco bezonata. La servo estas integrita kun la nuba infrastrukturo kaj funkcias per SVM, kiu pliigas la densecon de virtualaj maŝinoj sur la gastiganto ESXi kaj la rendimenton de la tuta nuba sistemo. La malpeza agento konstruas vicon da taskoj por ĉiu virtuala maŝino: kontrolu la dosiersistemon, memoron, ktp. Sed la SVM respondecas pri plenumi ĉi tiujn operaciojn, pri kiuj ni parolos poste. La agento ankaŭ plenumas la funkciojn de fajroŝirmilo, kontrolas sekurecpolitikojn, sendas infektitajn dosierojn al kvaranteno kaj kontrolas la ĝeneralan "sanon" de la operaciumo sur kiu ĝi estas instalita. Ĉio ĉi estas administrebla per la jam menciita ununura konzolo.
• Sekureca Virtuala Maŝino. Ĉiuj resurs-intensaj taskoj (kontraŭvirusaj datumbazaj ĝisdatigoj, planitaj skanadoj) estas pritraktitaj de aparta Sekureca Virtuala Maŝino (SVM). Ŝi respondecas pri la funkciado de plentaŭga kontraŭvirusa motoro kaj datumbazoj por ĝi. La IT-infrastrukturo de firmao povas inkludi plurajn SVMojn. Ĉi tiu aliro pliigas la fidindecon de la sistemo - se unu maŝino malsukcesas kaj ne respondas dum tridek sekundoj, agentoj aŭtomate komencas serĉi alian.
• KSC integriga servilo. Unu el la komponantoj de la ĉefa KSC, kiu asignas siajn SVM-ojn al malpezaj agentoj laŭ la algoritmo specifita en ĝiaj agordoj, kaj ankaŭ kontrolas la haveblecon de SVM-oj. Tiel, ĉi tiu programara modulo provizas ŝarĝan ekvilibron tra ĉiuj SVM-oj de la nuba infrastrukturo.
Algoritmo por labori en la nubo: redukti la ŝarĝon sur la infrastrukturo
Ĝenerale, la antivirusa algoritmo povas esti reprezentita jene. La agento aliras la dosieron sur la virtuala maŝino kaj kontrolas ĝin. La rezulto de la konfirmo estas konservita en ofta alcentrigita SVM-verdikdatumbazo (nomita Shared Cache), ĉiu eniro en kiu identigas unikan dosierprovaĵon. Ĉi tiu aliro permesas vin certigi, ke la sama dosiero ne estas skanita plurajn fojojn sinsekve (ekzemple, se ĝi estis malfermita sur malsamaj virtualaj maŝinoj). La dosiero estas resanita nur se ŝanĝoj estis faritaj al ĝi aŭ la skanado estis komencita permane.
Efektivigo de kontraŭvirusa solvo en la nubo de la provizanto
La bildo montras ĝeneralan diagramon de la solvo-efektivigo en la nubo. La ĉefa Kaspersky Security Center estas deplojita en la kontrolzono de la nubo, kaj individua SVM estas deplojita sur ĉiu ESXi-gastiganto uzante la KSC-integrigan servilon (ĉiu ESXi-gastiganto havas sian propran SVM ligitan kun specialaj agordoj sur VMware vCenter Server). Klientoj laboras en siaj propraj nubaj segmentoj, kie troviĝas virtualaj maŝinoj kun agentoj. Ili estas administritaj per individuaj KSC-serviloj malĉefaj al la ĉefa KSC. Se necesas protekti malgrandan nombron da virtualaj maŝinoj (ĝis 5), la kliento povas ricevi aliron al la virtuala konzolo de speciala dediĉita KSC-servilo. Reta interago inter kliento KSCoj kaj la ĉefa KSC, same kiel malpezaj agentoj kaj SVMoj, estas efektivigita uzante NAT per EdgeGW-kliento virtualaj enkursigiloj.
Laŭ niaj taksoj kaj la rezultoj de testoj de kolegoj ĉe la vendisto, Light Agent reduktas la ŝarĝon sur la virtuala infrastrukturo de klientoj je proksimume 25% (kompare kun sistemo uzanta tradician kontraŭvirusan programaron). Aparte, la norma antiviruso Kaspersky Endpoint Security (KES) por fizikaj medioj konsumas preskaŭ duoble pli da servila CPU-tempo (2,95%) ol malpeza agent-bazita virtualiga solvo (1,67%).
CPU-ŝarĝa kompara diagramo
Simila situacio estas observata kun la ofteco de disko-skribaj aliroj: por klasika antiviruso ĝi estas 1011 IOPS, por nuba antiviruso ĝi estas 671 IOPS.
Komparo-grafiko de la aliro pri disko
La rendimenta avantaĝo permesas vin konservi infrastrukturan stabilecon kaj uzi komputikan potencon pli efike. Adaptiĝante por labori en publika nuba medio, la solvo ne reduktas nuban rendimenton: ĝi centre kontrolas dosierojn kaj elŝutas ĝisdatigojn, distribuante la ŝarĝon. Ĉi tio signifas, ke, unuflanke, minacoj rilataj al la nuba infrastrukturo ne estos maltrafita, aliflanke, la rimedpostuloj por virtualaj maŝinoj reduktiĝos meze de 25% kompare kun tradicia antiviruso.
Laŭ funkcieco, ambaŭ solvoj estas tre similaj unu al la alia: malsupre estas kompara tabelo. Tamen, en la nubo, kiel la testrezultoj supre montras, estas ankoraŭ optimuma uzi solvon por virtualaj medioj.
Pri tarifoj en la kadro de la nova aliro. Ni decidis uzi modelon, kiu ebligas al ni akiri licencojn laŭ la nombro da vCPUoj. Ĉi tio signifas, ke la nombro da licencoj estos egala al la nombro da vCPUoj. Vi povas testi vian antiviruson lasante peton .
En la sekva artikolo pri nubaj temoj, ni parolos pri la evoluo de nubaj WAF-oj kaj kio estas pli bone elekti: aparataro, programaro aŭ nubo.
La teksto estis preparita de dungitoj de la nuba provizanto #CloudMTS: Denis Myagkov, ĉefa arkitekto kaj Alexey Afanasyev, administranto pri disvolviĝo de produktoj pri informa sekureco.
fonto: www.habr.com