Egyre több felhasználó helyezi át IT-infrastruktúráját a nyilvános felhőbe. Azonban, ha a megrendelő infrastruktúrájában nem elegendő az antivírus védelem, komoly kiberkockázatok merülhetnek fel. A gyakorlat azt mutatja, hogy a meglévő vírusok akár 80%-a is kiválóan él a virtuális környezetben. Ebben a bejegyzésben bemutatjuk, hogyan védhetjük meg IT-erőforrásainkat a nyilvános felhőben, és miért nem alkalmasak a hagyományos antivírusok ezekre a feladatokra.
Először is szeretnénk elmondani, hogyan jutottunk arra a következtetésre, hogy a nyilvános felhő számára nem megfelelőek a megszokott antivírus védelmi eszközök, és hogy más megközelítések szükségesek az erőforrások védelméhez.
Először is a szolgáltatók általában biztosítják azokat a szükséges intézkedéseket, amelyek garantálják a felhőplatformjaik magas szintű védelmét. Például mi a #CloudMTS rendszeresen elemezzük a teljes hálózati forgalmat, figyeljük a felhőbiztonsági naplókat, és rendszeres penetrációs teszteket végzünk. A felhő egyes szegmenseit, amelyeket külön-külön ügyfeleknek adunk át, szintén megbízhatóan kell védeni.
Másodszor, a klasszikus megközelítés a kiberkockázatok kezelésére azt jelenti, hogy antivírus programot és annak irányító eszközeit kell telepíteni minden egyes virtuális gépre. Azonban ha nagy számú virtuális gép van, ez a gyakorlat hatástalanná válhat, és jelentős számú számítási erőforrást igényelhet, ezzel tovább terhelve a megrendelő infrastruktúráját, ami csökkenti a felhő általános teljesítményét. Ez volt a kulcsfontosságú előfeltétel, amely új megközelítések keresésére ösztönözte a virtuális gépek hatékony antivírus védelmének megvalósítását.
Ezenkívül a piacon lévő legtöbb antivírus megoldás nem alkalmazkodik az IT-erőforrások védelmére a nyilvános felhő környezetben. Általában nehézkes EPP-megoldásokat (Endpoint Protection Platforms) kínálnak, amelyek ráadásul nem biztosítanak megfelelő testreszabási lehetőségeket a felhőszolgáltató ügyfelei számára.
Nyilvánvalóvá válik, hogy a hagyományos antivírus megoldások nem alkalmasak a felhőben való működésre, mivel komolyan terhelik a virtuális infrastruktúrát frissítések és beolvasások során, ráadásul nem rendelkeznek a szükséges szerepkezelési szintekkel és beállításokkal. A következőkben részletesen elemzünk, hogy milyen okokból van szükség új megközelítésekre az antivírus védelemben a felhőben.
Milyen képességekkel kell rendelkeznie egy antivírusnak a nyilvános felhőben
Tehát összpontosítsunk a virtuális környezet működésére:
A frissítések és a tömeges ellenőrzések ütemezésének hatékonysága. Ha jelentős számú virtuális gép, amely hagyományos antivírust használ, egyszerre kezdeményez frissítést, a felhőben bekövetkezik egy úgynevezett "frissítési vihar". Az ESXi-gazdagépen, ahol több virtuális gép található, nem biztos, hogy elegendő kapacitás áll rendelkezésre az egyidejűleg indított, azonos típusú feladatok megoldásához. A felhőszolgáltató szempontjából ez problémát okozhat, mivel további terhelést jelenthet számos ESXi-gazdagépre, ami végső soron a virtuális felhőinfrastruktúra teljesítményének csökkenéséhez vezethet. Ez a felhő többi ügyfelének virtuális gépeinek teljesítményére is hatással lehet. Hasonló helyzet állhat elő tömeges beolvasás indításakor: a diszk rendszerét egyidejűleg sok azonos típusú kéréssel megcélzó műveletek negatívan befolyásolják az egész felhő teljesítményét. Nagy valószínűséggel a tárhely teljesítménycsökkenése minden ügyfélnél megmutatkozik. Az ilyen hirtelen terhelések sem a szolgáltatót, sem az ügyfeleit nem örvendeztetik meg, mivel hatással vannak a felhő „szomszédaira”. E szempontból a hagyományos antivírus nagy problémát jelenthet.
Biztonságos karantén. Ha a rendszer egy potenciálisan vírusfertőzött fájlt vagy dokumentumot észlel, azt karanténba helyezi. Természetesen a fertőzött fájlt azonnal törölni lehet, de ez gyakran nem elfogadható a legtöbb vállalat számára. Azok a vállalati enterprise antivírusok, amelyek nem lettek adaptálva a szolgáltató felhőjében való működésre, általában közös karanténterülettel bírnak — ide kerülnek a fertőzött objektumok, például a vállalati felhasználók számítógépein észleltek. A felhőszolgáltató ügyfelei „saját” szegmenseikben (vagy tenantaikban) élnek. Ezek a szegmensek átláthatatlanok és izoláltak: az ügyfelek nem tudnak egymásról, és természetesen nem látják, hogy mások mit helyeznek el a felhőben. Nyilvánvaló, hogy a közös karanténba, amelyhez a felhő antivírusának minden felhasználója hozzáfér, potenciálisan bekerülhet olyan dokumentum, amely bizalmas információt vagy üzleti titkot tartalmaz. Ez elfogadhatatlan a szolgáltató és annak ügyfelei számára. Ezért a megoldás csak egy lehet – minden ügyfél számára személyes karantén a saját szegmensében, ahová sem a szolgáltató, sem más ügyfelek nem férhetnek hozzá.
Egyedi biztonsági politikák. Minden ügyfél a felhőben egy különálló vállalat, amelynek IT-osztálya saját biztonsági politikáit állítja fel. Például az adminisztrátorok meghatározzák a víruskereső vizsgálatok szabályait és időbeosztását. Ennek megfelelően minden szervezetnek saját irányító központtal kell rendelkeznie a víruskereső politikák beállításához. A megadott beállításoknak nem szabad befolyásolniuk a felhő többi ügyfelét, a szolgáltatónak pedig biztosítania kell, hogy például a víruskereső frissítései zökkenőmentesen történjenek meg a kliens összes virtuális gépén.
A számlázás és a licencelés megszervezése. A felhőmodell a rugalmasságot jellemzi, és csak azokat az IT-erőforrásokat kell megfizetni, amelyeket az ügyfél ténylegesen igénybe vett. Ha szükséges, például a szezonalitás miatt, a kapacitások mennyisége gyorsan növelhető vagy csökkenthető — mindez a jelenlegi számítási igények alapján. A hagyományos víruskereső nem annyira rugalmas — általában az ügyfél egy évre vásárol licencet egy előre meghatározott mennyiségre. szerverek vagy munkaállomás. A felhasználók rendszeresen le- és bekapcsolják a további virtuális gépeket a jelenlegi igényeiknak megfelelően - ennek megfelelően az antivírus licenszeknek is támogatniuk kell ezt a modellt.
A második kérdés az, hogy pontosan mire terjed ki a licensz. A hagyományos antivírus a szerverek vagy munkaállomások számához van licenszelve. A virtuális gépek számához kapcsolódó licenszek nem igazán illeszkednek a felhőmodell keretei közé. Az ügyfél az adott erőforrásokból bármennyi virtuális gépet létrehozhat, például öt vagy tíz gépet. Ez a szám a legtöbb ügyfélnél nem állandó, így ezt a változást nyomon követni számunkra, mint szolgáltató, nem lehetséges. A CPU alapján történő licenszelésre nincs technikai lehetőség: az ügyfelek virtuális processzorokat (vCPU) kapnak, amelyek alapján a licenszelést végezni kell. Így az új antivírus védelmi modell lehetőséget kell, hogy biztosítson az ügyfél számára a szükséges vCPU számának meghatározására, amelyre antivírus licenszeket fog kapni.
A jogszabályoknak való megfelelés. Fontos pont, mivel az alkalmazott megoldásoknak biztosítaniuk kell a szabályozó követelményeinek teljesítését. Például gyakran a felhő "lakói" személyes adatokkal dolgoznak. Ilyen esetben a szolgáltatónak rendelkeznie kell egy külön tanúsított felhőrészleggel, amely teljes mértékben megfelel a "Személyes adatok védelméről" szóló törvény követelményeinek. Így a cégeknek nem kell önállóan "felépíteniük" az egész rendszert a személyes adatok kezelésére: tanúsított berendezéseket kell vásárolniuk, csatlakoztatniuk kell azokat, és el kell végezniük a tanúsítást. A kiberbiztonság érdekében a személyes adatok védelmére készült antivírusnak is meg kell felelnie az orosz jogszabályi követelményeknek, és rendelkeznie kell az FSTEK tanúsítványával.
Megvizsgáltuk azokat az alapvető kritériumokat, amelyeknek a nyilvános felhőben az antivírus védelemnek meg kell felelnie. Ezt követően megosztjuk saját tapasztalatainkat az antivírus megoldás felhőszolgáltatásra való alkalmazásának terén.
Hogyan hozhatjuk össze az antivírust és a felhőt
Tapasztalataink szerint a megoldás választása leírás és dokumentáció alapján egy dolog, de a már működő felhő környezetben való megvalósítása egy teljesen más szintű nehézség. Elmondjuk, mit tettünk a gyakorlatban és hogyan alkalmaztuk az antivírust egy nyilvános felhőszolgáltató keretrendszerében. Az antivírus megoldás szállítója a Kaspersky, amelynek portfóliójában találhatók antivírus védelmi megoldások felhőalapú környezetekhez. A „Kaspersky Security virtualizált környezetekhez” (Könnyű ügynök) mellett döntöttünk.
Ez magában foglalja a Kaspersky Security Center egységes konzolját. A könnyű ügynök és a biztonsági virtuális gépek (SVM, Security Virtual Machine) valamint a KSC integrációs szerverét.
Miután megvizsgáltuk a Kaspersky megoldás architektúráját és elvégeztük az első teszteket a szállító mérnökeivel, felmerült a kérdés a szolgáltatás integrálásáról a felhőbe. Az első telepítést közösen valósítottuk meg a moszkvai felhő telephelyén. És itt van, amit megértettünk.
A hálózati forgalom minimalizálása érdekében úgy döntöttünk, hogy minden ESXi-hoszton elhelyezzük az SVM-et, és „hozzákapcsoljuk” az SVM-et az ESXi-hoszthoz. Így a védett virtuális gépek könnyű ügynökei az arra az ESXi-hosztra vonatkozó SVM-hez fordulnak, amelyen futnak. A fő KSC számára egy külön adminisztratív tenant lett kiválasztva. Ennek eredményeként a KSC alá tartozó egységek minden egyes ügyfél tenantjaiban helyezkednek el, és a felettes KSC-hez fordulnak, amely a menedzsment szegmensben található. Ez a rendszer lehetővé teszi az ügyféltanantokban felmerülő problémák gyors megoldását.
A saját antivírus megoldás komponenseinek telepítése mellett felmerült a feladat a hálózati interakció megszervezése érdekében további VxLAN-ok létrehozásával. Bár a megoldás eredetileg az enterprise ügyfelek számára készült magánhálózatokkal — mérnöki leleményesség és az NSX Edge technológiai rugalmassága révén sikerült megoldanunk az összes, a tenantok elkülönítésével és a licenceléssel kapcsolatos feladatot.
Szoros együttműködésben dolgoztunk a Kaspersky mérnökeivel. A megoldás architektúrájának elemzése során, a rendszer komponensei közötti hálózati interakció szempontjából megállapítottuk, hogy a könnyű ügynökök hozzáférésén kívül szükség van a visszajelzésre is – az SVM-től a könnyű ügynökök felé. Ez a hálózati kapcsolat multitenanciás környezetben nem lehetséges, mivel különböző tenantokban azonos hálózati beállítások létezhetnek a virtuális gépekben. Ezért kérésünkre a beszállítók kollégái átdolgozták a hálózati interakció mechanizmusát a könnyű ügynök és az SVM között, hogy ne legyen szükség hálózati kapcsolatra az SVM-től a könnyű ügynökök felé.
Miután a megoldást telepítettük és teszteltük a moszkvai felhőhelyszínen, elterjesztettük más helyszínekre is, beleértve a tanúsított felhős szegmenst. Jelenleg a szolgáltatás minden régióban elérhető az országban.
Az új megközelítés keretein belüli IT-biztonsági megoldás architektúrája
Az antivírusrendszer működésének általános séma a nyilvános felhőkörnyezetben a következőképpen néz ki:
Az antivírusrendszer működési sémája a nyilvános felhőkörnyezetben #CloudMTS
Leírjuk a megoldás egyes elemeinek működésével kapcsolatos sajátosságokat a felhőben:
• Egységes konzol, amely lehetővé teszi az ügyfelek számára a védelmi rendszer központosított kezelését: ellenőrzések indítása, frissítések ellenőrzése és a karanténzónák nyomon követése. Lehetőség van egyedi biztonsági politikák beállítására a saját szegmensük keretein belül.
Meg kell jegyezni, hogy bár szolgáltató vagyunk, nem avatkozunk be az ügyfelek által beállított konfigurációkba. Az egyetlen dolog, amit tehetünk, hogy szükség esetén alapértelmezetten visszaállítjuk a biztonsági irányelveket. Például erre akkor lehet szükség, ha az ügyfél véletlenül szigorította vagy jelentősen enyhítette azokat. A vállalat mindig hozzáférhet az alapértelmezett irányelvekkel rendelkező kezelőközponthoz, amelyet később saját magának állíthat be. A Kaspersky Security Center hátránya, hogy a platform jelenleg csak a Microsoft operációs rendszeren érhető el. Bár a könnyű ügynökök mind Windows, mind Linux gépeken működhetnek. A „Kaspersky Lab” azonban ígéri, hogy hamarosan az KSC Linux operációs rendszeren is működni fog. Az KSC egyik fontos funkciója a karantén kezelése. Minden ügyfélcég a felhőnkben saját személyre szabott karanténnal rendelkezik. Ez a megközelítés megszünteti a helyzeteket, amikor egy vírus által megfertőzött dokumentum véletlenül a nyilvánosság elé kerül, mint ahogy ez egy klasszikus vállalati antivírus esetén a közös karanténnal megtörténhetett volna.
• Könnyű ügynökök. Az új modell keretein belül minden virtuális gépre egy könnyű Kaspersky Security ügynök kerül telepítésre. Ez lehetővé teszi, hogy ne tároljuk az antivírus adatbázist minden VM-en, ezáltal csökkentve a szükséges lemezterületet. A szolgáltatás integrálva van a felhő infrastruktúrájával és az SVM-en keresztül működik, amely növeli a virtuális gépek sűrűségét az ESXi gazdagépen és javítja az egész felhőrendszer teljesítményét. A könnyű ügynök feladatok sorát épít minden virtuális gép számára: fájlrendszer ellenőrzése, memória stb. Azonban a feladatok végrehajtásáért az SVM felel, amiről később beszélünk. Az ügynök további funkciókat is ellát, mint például a tűzfal kezelése, biztonsági irányelvek ellenőrzése, megfertőzött fájlok karanténba helyezése és az operációs rendszer általános "egészségének" figyelemmel kísérése, amelyen telepítve van. Mindezeket a már említett egységes konzolon keresztül lehet kezelni.
• Biztonsági Virtuális Gépek. Minden erőforrás-igényes feladatot (vírusadatbázisok frissítése, ütemezett ellenőrzések) egy külön Biztonsági Virtuális Gép (SVM) lát el. Ő felelős a teljes értékű víruskereső motor és annak adatbázisa működéséért. A vállalat IKT-infrastruktúrája több SVM-et is magában foglalhat. Ez a megközelítés növeli a rendszer megbízhatóságát – ha valamelyik gép harminc másodpercig nem válaszol, az ügynökök automatikusan elkezdik keresni a következőt.
• KSC Integrációs Szerver. A fő KSC egyik összetevője, amely a beállított algoritmus szerint rendeli hozzá a könnyű ügynökökhöz a saját SVM-jeiket, valamint ellenőrzi azok elérhetőségét. Így ez a szoftvermodul biztosítja az összes SVM terhelésének kiegyenlítését a felhőinfrastruktúrában.
Algoritmus az infrastruktúra terhelésének csökkentésére a felhőben
Általánosságban a víruskereső működése a következőképpen képzelhető el. Az ügynök hozzáfér egy fájlhoz a virtuális gépen, és ellenőrzi azt. Az ellenőrzés eredménye egy központi, megosztott SVM határozathiánybázisba kerül (amelyet Shared Cache-nek hívnak), ahol minden bejegyzés egyedi fájlmintát azonosít. Ez a megközelítés lehetővé teszi, hogy ugyanazt a fájlt ne ellenőrizzék többször egymás után (például ha azt különböző virtuális gépeken nyitották meg). A fájl csak akkor kerül újra ellenőrzésre, ha módosították, vagy a vizsgálatot kézzel indították.
A víruskereső megoldás megvalósítása a szolgáltató felhőjében
A képen a felhőbeli megoldás általános megvalósítási sémája látható. A felhő vezérlő zónájában telepítve van a fő Kaspersky Security Center, míg minden ESXi-hoszton az integrációs KSC szerver segítségével egyéni SVM került telepítésre (minden ESXi-hoszthoz speciális beállításokkal a VMware vCenter Serverhez rendelnek saját SVM-et). Az ügyfelek saját felhőszegmenseikben dolgoznak, ahol virtuális gépek ügynökeivel együtt helyezkednek el. Ezeket az egyéni KSC-szerverek kezelik, amelyek a fő KSC-nek alárendelt. Amennyiben szükséges néhány virtuális gép (legfeljebb 5) védelme, az ügyfél hozzáférést kaphat egy speciális dedikált KSC virtuális konzolhoz. Az ügyfél KSC-je és a fő KSC, valamint a könnyű ügynökök és az SVM közötti hálózati interakció NAT segítségével zajlik az ügyfél virtuális EdgeGW routerein keresztül.
Értékeléseink és a gyártó kollégái által végzett tesztek alapján a könnyű ügynök körülbelül 25%-kal csökkenti az ügyfelek virtuális infrastruktúrájára nehezedő terhelést (ha összehasonlítjuk a hagyományos antivírus szoftvereket használó rendszerrel). Különösen, a Kaspersky Endpoint Security (KES) standard antivírus a fizikai környezetekben majdnem kétszer annyi processzori időt használ, mint a könnyű ügynökökön alapuló virtualizálási megoldás (2,95% vs. 1,67%).
A processzorterhelés összehasonlító diagramja
Hasonló helyzet figyelhető meg a lemezírási hívások gyakoriságában is: a klasszikus antivírus esetén 1011 IOPS, míg a felhőalapú antivírusnál 671 IOPS.
A lemezhez való hozzáférés gyakoriságát összehasonlító diagram
A teljesítményjavulás lehetővé teszi az infrastruktúra stabilitásának fenntartását és a számítási kapacitások hatékonyabb kihasználását. A nyilvános felhő környezetre való alkalmazkodás révén a megoldás nem csökkenti a felhő teljesítményét: központosított fájlellenőrzést és frissítések letöltését valósít meg, elosztva a terhelést. Ez azt jelenti, hogy egyrészt a felhőinfrastruktúra szempontjából releváns fenyegetések nem maradnak el, másrészt átlagosan 25%-kal csökkennek a virtuális gépek erőforrásigényei a hagyományos antivírussal összehasonlítva.
A funkcionalitás szempontjából a két megoldás nagyon hasonlít egymásra: alább található egy összehasonlító táblázat. Azonban a tesztelési eredmények alapján a felhőben optimálisabb a virtuális környezethez készült megoldást használni.
Az új megközelítésen belüli tarifálásról. Úgy döntöttünk, hogy olyan modellt használunk, amely lehetővé teszi a licenszek megszerzését a vCPU-k számának megfelelően. Ez azt jelenti, hogy a licenszek száma megegyezik a vCPU-k számával. Az antivírust lehet tesztelni, ha jelentkezik. .
A következő anyagunkban a felhő témakörében a felhőalapú WAF evolúciójáról beszélünk és arról, hogy mi a legjobb választás: hardver, szoftver vagy felhő.
A szöveget a felhőszolgáltató #CloudMTS munkatársai készítették: Denisz Mjagkov, vezető építész és Alexej Afanaszjev, termékfejlesztési menedzser.
Forrás: habr.com
