Egyre több felhasználó hozza teljes informatikai infrastruktúráját a nyilvános felhőbe. Ha azonban az ügyfél infrastruktúrájában nem megfelelő a vírusvédelem, akkor komoly kiberkockázatok merülnek fel. A gyakorlat azt mutatja, hogy a létező vírusok akár 80%-a tökéletesen él virtuális környezetben. Ebben a bejegyzésben arról fogunk beszélni, hogyan védhetjük meg az informatikai erőforrásokat a nyilvános felhőben, és hogy a hagyományos víruskeresők miért nem teljesen alkalmasak ezekre a célokra.
Kezdésként elmondjuk, hogyan jutottunk arra az ötletre, hogy a szokásos vírusvédelmi eszközök nem alkalmasak a nyilvános felhőre, és más megközelítésekre van szükség az erőforrások védelmére.
Először is, a szolgáltatók általában megteszik a szükséges intézkedéseket felhőplatformjaik magas szintű védelmének biztosítására. Például a #CloudMTS-nél elemezzük az összes hálózati forgalmat, figyeljük felhőnk biztonsági rendszereinek naplóit, és rendszeresen végzünk penteszteket. Az egyes ügyfelek számára kiosztott felhőszegmenseket is biztonságosan védeni kell.
Másodszor, a kiberkockázatok leküzdésének klasszikus módja egy vírusirtó és víruskereső eszközök telepítése minden virtuális gépre. Nagyszámú virtuális gép esetén azonban ez a gyakorlat hatástalan lehet, és jelentős mennyiségű számítási erőforrást igényel, ezáltal tovább terheli az ügyfél infrastruktúráját, és csökkenti a felhő általános teljesítményét. Ez kulcsfontosságú előfeltétele lett annak, hogy új megközelítéseket keressünk az ügyfelek virtuális gépei hatékony vírusvédelmének kialakításához.
Ezenkívül a legtöbb víruskereső megoldás a piacon nem alkalmas az IT-erőforrások védelmével kapcsolatos problémák megoldására nyilvános felhőkörnyezetben. Általában nehézsúlyú EPP-megoldásokról (Endpoint Protection Platforms) van szó, amelyek ráadásul nem biztosítják a szükséges testreszabást a felhőszolgáltató ügyféloldalán.
Nyilvánvalóvá válik, hogy a hagyományos vírusirtó megoldások nem alkalmasak a felhőben való munkavégzésre, mivel a frissítések és vizsgálatok során komolyan terhelik a virtuális infrastruktúrát, és nem rendelkeznek a szükséges szintű szerepkör-alapú kezeléssel és beállításokkal. Ezután részletesen elemezzük, miért van szüksége a felhőnek új megközelítésekre a vírusvédelem terén.
Mire képes egy nyilvános felhőben lévő vírusirtó?
Tehát figyeljünk a virtuális környezetben végzett munka sajátosságaira:
A frissítések és ütemezett tömeges ellenőrzések hatékonysága. Ha a hagyományos vírusirtót használó virtuális gépek jelentős része egyszerre kezdeményez frissítést, akkor a felhőben úgynevezett frissítési „vihar” indul. Előfordulhat, hogy a több virtuális gépet kiszolgáló ESXi-gazdagép ereje nem elegendő az alapértelmezés szerint futó hasonló feladatok záporának kezelésére. A felhőszolgáltató szemszögéből egy ilyen probléma több ESXi gazdagépen további terhelést okozhat, ami végső soron a felhő virtuális infrastruktúra teljesítményének csökkenéséhez vezet. Ez többek között hatással lehet más felhőkliensek virtuális gépeinek teljesítményére. Hasonló helyzet adódhat tömeges vizsgálat indításakor: a különböző felhasználóktól származó sok hasonló kérés lemezrendszer általi egyidejű feldolgozása negatívan befolyásolja a teljes felhő teljesítményét. A tárolórendszer teljesítményének csökkenése nagy valószínűséggel minden klienst érint. Az ilyen hirtelen terhelések nem tetszenek sem a szolgáltatónak, sem az ügyfeleinek, mivel hatással vannak a felhőben lévő „szomszédokra”. Ebből a szempontból a hagyományos vírusirtó nagy problémát jelenthet.
Biztonságos karantén. Ha potenciálisan vírussal fertőzött fájlt vagy dokumentumot észlel a rendszer, akkor karanténba kerül. Természetesen a fertőzött fájl azonnal törölhető, de ez a legtöbb cég számára gyakran nem elfogadható. A vállalati vállalati víruskeresőknek, amelyek nem alkalmasak a szolgáltató felhőjében való működésre, általában van egy közös karanténzóna - minden fertőzött objektum ebbe esik. Például a vállalati felhasználók számítógépein találhatók. A felhőszolgáltató ügyfelei a saját szegmensükben (vagy bérlőikben) „élnek”. Ezek a szegmensek átláthatatlanok és elszigeteltek: az ügyfelek nem tudnak egymásról, és természetesen nem látják, hogy mások mit tárolnak a felhőben. Nyilvánvaló, hogy az általános karantén, amelyhez minden vírusirtó felhasználó hozzáfér a felhőben, potenciálisan magában foglalhat egy bizalmas információkat vagy üzleti titkot tartalmazó dokumentumot. Ez elfogadhatatlan a szolgáltató és ügyfelei számára. Ezért csak egy megoldás lehet - személyes karantén minden egyes ügyfél számára a saját szegmensében, ahová sem a szolgáltató, sem más ügyfelek nem férhetnek hozzá.
Egyéni biztonsági szabályzatok. A felhőben minden ügyfél külön vállalat, amelynek IT osztálya saját biztonsági szabályzatot állít be. Az adminisztrátorok például ellenőrzési szabályokat határoznak meg, és ütemezik a vírusellenőrzést. Ennek megfelelően minden szervezetnek saját vezérlőközponttal kell rendelkeznie a vírusvédelmi házirendek konfigurálásához. Ugyanakkor a megadott beállítások nem érinthetnek más felhőklienseket, és a szolgáltatónak ellenőriznie kell, hogy például a víruskereső frissítések a szokásos módon hajtódnak-e végre az összes kliens virtuális gépen.
A számlázás és az engedélyezés szervezése. A felhőmodellt a rugalmasság jellemzi, és csak annyi IT-erőforrásért kell fizetni, amennyit az ügyfél használt. Ha például szezonalitás miatt van rá igény, akkor az erőforrások mennyisége gyorsan növelhető vagy csökkenthető – mindezt az aktuális számítási teljesítményigények alapján. A hagyományos vírusirtó nem olyan rugalmas - általában az ügyfél egy évre vásárol licencet előre meghatározott számú kiszolgálóhoz vagy munkaállomáshoz. A felhőfelhasználók az aktuális igényeiktől függően rendszeresen leválasztják és csatlakoztatják további virtuális gépeket – ennek megfelelően a víruskereső licenceknek is támogatniuk kell ugyanazt a modellt.
A második kérdés az, hogy pontosan mire terjed ki az engedély. A hagyományos vírusirtó licencét a szerverek vagy munkaállomások száma határozza meg. A védett virtuális gépek számán alapuló licencek nem teljesen megfelelőek a felhőmodellben. A kliens a rendelkezésére álló erőforrásokból tetszőleges számú, számára kényelmes virtuális gépet hozhat létre, például öt vagy tíz gépet. Ez a szám a legtöbb ügyfélnél nem állandó, változásait mi szolgáltatóként nem tudjuk követni. CPU-n keresztüli licencelésre nincs technikai lehetőség: a kliensek virtuális processzorokat (vCPU-kat) kapnak, amelyeket a licencelésre kell használni. Így az új vírusvédelmi modellnek tartalmaznia kell azt a lehetőséget, hogy az ügyfél meghatározza a szükséges számú vCPU-t, amelyre vírusvédelmi licencet kap.
A jogszabályok betartása. Fontos szempont, mivel az alkalmazott megoldásoknak biztosítaniuk kell a szabályozói követelményeknek való megfelelést. Például a felhő „lakói” gyakran dolgoznak személyes adatokkal. Ebben az esetben a szolgáltatónak külön tanúsított felhőszegmenssel kell rendelkeznie, amely teljes mértékben megfelel a személyes adatokról szóló törvény követelményeinek. Ekkor a vállalatoknak nem kell önállóan „felépíteniük” a teljes rendszert a személyes adatokkal való munkavégzéshez: tanúsított berendezéseket vásárolniuk, csatlakoztatniuk és konfigurálniuk, valamint tanúsításon kell átesniük. Az ilyen ügyfelek ISPD-jének kibervédelme érdekében a víruskeresőnek meg kell felelnie az orosz jogszabályok követelményeinek, és rendelkeznie kell FSTEC tanúsítvánnyal.
Megvizsgáltuk azokat a kötelező kritériumokat, amelyeknek a nyilvános felhőben található vírusvédelemnek meg kell felelnie. Ezután megosztjuk saját tapasztalatainkat egy víruskereső megoldás adaptálásával kapcsolatban a szolgáltató felhőjében.
Hogyan szerezhet barátságot a vírusirtó és a felhő között?
Tapasztalataink szerint a leírás és a dokumentáció alapján egy megoldást választani egy dolog, de a gyakorlati megvalósítás egy már működő felhőkörnyezetben összetettségét tekintve egészen más feladat. Elmondjuk, mit csináltunk a gyakorlatban, és hogyan adaptáltuk a víruskeresőt a szolgáltató nyilvános felhőjében való működéshez. A vírusirtó megoldás szállítója a Kaspersky volt, amelynek portfóliójában felhőkörnyezetek vírusvédelmi megoldásai is megtalálhatók. A „Kaspersky Security for Virtualization” (Light Agent) mellett döntöttünk.
Egyetlen Kaspersky Security Center konzolt tartalmaz. Könnyű ügynök és biztonsági virtuális gépek (SVM, Security Virtual Machine) és KSC integrációs szerver.
Miután áttanulmányoztuk a Kaspersky megoldás architektúráját és elvégeztük az első teszteket a gyártó mérnökeivel közösen, felmerült a kérdés a szolgáltatás felhőbe való integrálása. Az első megvalósítást közösen hajtották végre a moszkvai felhőtelepen. És erre rájöttünk.
A hálózati forgalom minimalizálása érdekében úgy döntöttek, hogy minden ESXi gazdagépen elhelyeznek egy SVM-et, és az SVM-et az ESXi gazdagépekhez „kötik”. Ebben az esetben a védett virtuális gépek egyszerű ügynökei pontosan annak az ESXi-gazdagépnek az SVM-jét érik el, amelyen futnak. A fő KSC-hez külön adminisztratív bérlőt választottak. Ennek eredményeként az alárendelt KSC-k az egyes ügyfelek bérlőinél helyezkednek el, és az irányítási szegmensben található felsőbbrendű KSC-hez fordulnak. Ez a séma lehetővé teszi az ügyfelek bérlőinél felmerülő problémák gyors megoldását.
Amellett, hogy magának a víruskereső megoldásnak az összetevőinek felemelésével kapcsolatos problémák merültek fel, a hálózati interakció megszervezésével is szembe kellett néznünk további VxLAN-ok létrehozásával. És bár a megoldást eredetileg a privát felhőkkel rendelkező vállalati ügyfeleknek szánták, az NSX Edge mérnöki hozzáértése és technológiai rugalmassága segítségével minden, a bérlők szétválasztásával és a licenceléssel kapcsolatos problémát meg tudtunk oldani.
Szorosan együttműködtünk a Kaspersky mérnökeivel. Így a megoldás architektúrának a rendszerkomponensek közötti hálózati kölcsönhatás szempontjából történő elemzése során azt találtuk, hogy a könnyű ügynököktől az SVM-hez való hozzáférésen túlmenően visszacsatolás is szükséges - az SVM-től a könnyű ágensekig. Ez a hálózati kapcsolat nem lehetséges több-bérlős környezetben, mivel a virtuális gépek azonos hálózati beállításai lehetnek a különböző felhőbérlőkben. Ezért kérésünkre a szállító kollégái átdolgozták a könnyű ügynök és az SVM közötti hálózati interakció mechanizmusát annak érdekében, hogy kiküszöböljék az SVM és a könnyű ágensek közötti hálózati kapcsolat szükségességét.
Miután a megoldást üzembe helyezték és tesztelték a moszkvai felhőalapú webhelyen, más webhelyekre replikáltuk, beleértve a tanúsított felhőszegmenst is. A szolgáltatás ma már az ország minden régiójában elérhető.
Információbiztonsági megoldás felépítése új szemlélet keretein belül
A víruskereső megoldás általános működési sémája nyilvános felhőkörnyezetben a következő:
Víruskereső megoldás működési sémája nyilvános felhőkörnyezetben #CloudMTS
Ismertesse a megoldás egyes elemeinek működési jellemzőit a felhőben:
• Egyetlen konzol, amely lehetővé teszi az ügyfelek számára a védelmi rendszer központi kezelését: ellenőrzések futtatását, frissítések vezérlését és a karanténzónák figyelését. Lehetőség van egyedi biztonsági házirendek konfigurálására a szegmensén belül.
Tudni kell, hogy bár szolgáltató vagyunk, nem avatkozunk be az ügyfelek által beállított beállításokba. Az egyetlen dolog, amit tehetünk, hogy visszaállítjuk a biztonsági házirendeket szabványosra, ha újrakonfigurálásra van szükség. Erre például akkor lehet szükség, ha az ügyfél véletlenül megfeszítette vagy jelentősen meggyengítette őket. Egy vállalat mindig kaphat egy vezérlőközpontot alapértelmezett házirendekkel, amelyeket aztán önállóan konfigurálhat. A Kaspersky Security Center hátránya, hogy a platform jelenleg csak a Microsoft operációs rendszerhez érhető el. Bár a könnyű ügynökök Windows és Linux gépekkel is működhetnek. A Kaspersky Lab azonban azt ígéri, hogy a közeljövőben a KSC Linux operációs rendszer alatt fog működni. A KSC egyik fontos funkciója a karantén kezelésének képessége. Felhőnkben minden ügyfélcégnek van egy személyes. Ez a megközelítés kiküszöböli azokat a helyzeteket, amikor egy vírussal fertőzött dokumentum véletlenül nyilvánosan láthatóvá válik, ahogy ez egy klasszikus vállalati vírusirtó esetében is megtörténhet, általános karanténba helyezve.
• Enyhe szerek. Az új modell részeként minden virtuális gépen egy könnyű Kaspersky Security ügynök van telepítve. Ez kiküszöböli a víruskereső adatbázis tárolásának szükségességét minden egyes virtuális gépen, ami csökkenti a szükséges lemezterületet. A szolgáltatás integrálva van a felhő infrastruktúrával, és az SVM-en keresztül működik, ami növeli az ESXi gazdagépen lévő virtuális gépek sűrűségét és a teljes felhőrendszer teljesítményét. A könnyű ügynök minden virtuális géphez feladatsort készít: ellenőrizze a fájlrendszert, a memóriát stb. De az SVM felelős ezeknek a műveleteknek a végrehajtásáért, amelyekről később fogunk beszélni. Az ügynök tűzfalként is működik, felügyeli a biztonsági házirendeket, karanténba küldi a fertőzött fájlokat, és figyeli annak az operációs rendszernek az általános „állapotát”, amelyre telepítve van. Mindez a már említett egyetlen konzol segítségével kezelhető.
• Biztonsági virtuális gép. Minden erőforrásigényes feladatot (víruskereső adatbázis-frissítések, ütemezett ellenőrzések) egy különálló Security Virtual Machine (SVM) kezel. Felelős a teljes körű víruskereső motor és az ehhez tartozó adatbázisok működtetéséért. Egy vállalat informatikai infrastruktúrája több SVM-et is tartalmazhat. Ez a megközelítés növeli a rendszer megbízhatóságát – ha az egyik gép meghibásodik, és harminc másodpercig nem válaszol, az ügynökök automatikusan egy másikat kezdenek keresni.
• KSC integrációs szerver. A fő KSC egyik komponense, amely a beállításaiban megadott algoritmusnak megfelelően hozzárendeli SVM-jeit a könnyű ügynökökhöz, és az SVM-ek elérhetőségét is szabályozza. Így ez a szoftvermodul terheléselosztást biztosít a felhőinfrastruktúra összes SVM-je között.
A felhőben végzett munka algoritmusa: az infrastruktúra terhelésének csökkentése
Általában a víruskereső algoritmus a következőképpen ábrázolható. Az ügynök hozzáfér a fájlhoz a virtuális gépen, és ellenőrzi azt. Az ellenőrzés eredményét a rendszer egy közös központi SVM-verdikt adatbázisban tárolja (megosztott gyorsítótárnak nevezzük), amelyben minden egyes bejegyzés egyedi fájlmintát azonosít. Ez a megközelítés lehetővé teszi annak biztosítását, hogy ugyanazt a fájlt ne vizsgálják többször egymás után (például ha különböző virtuális gépeken nyitották meg). A fájl újraolvasása csak akkor történik meg, ha módosításokat hajtottak végre rajta, vagy a vizsgálatot manuálisan elindították.
Víruskereső megoldás megvalósítása a szolgáltató felhőjében
A képen a megoldás felhőben való megvalósításának általános diagramja látható. A fő Kaspersky Security Center a felhő vezérlési zónájában van telepítve, és egy egyedi SVM kerül telepítésre minden ESXi gazdagépen a KSC integrációs kiszolgáló segítségével (minden ESXi gazdagéphez saját SVM van csatolva a VMware vCenter Server speciális beállításaival). Az ügyfelek saját felhőszegmenseikben dolgoznak, ahol az ügynökökkel rendelkező virtuális gépek találhatók. Ezeket a fő KSC-nek alárendelt egyedi KSC-szervereken keresztül kezelik. Ha kisszámú virtuális gépet kell védeni (legfeljebb 5), az ügyfél hozzáférést biztosíthat egy speciális dedikált KSC szerver virtuális konzoljához. A kliens KSC-k és a fő KSC, valamint a könnyű ügynökök és az SVM-ek közötti hálózati interakció NAT használatával történik az EdgeGW kliens virtuális útválasztókon keresztül.
Becsléseink és a gyártó munkatársai által végzett tesztek eredményei szerint a Light Agent körülbelül 25%-kal csökkenti az ügyfelek virtuális infrastruktúrájának terhelését (egy hagyományos vírusirtó szoftvert használó rendszerhez képest). Konkrétan a Kaspersky Endpoint Security (KES) szabványos víruskereső fizikai környezetekhez csaknem kétszer annyi szerver CPU-időt fogyaszt (2,95%), mint egy könnyű, ügynök alapú virtualizációs megoldás (1,67%).
CPU terhelés összehasonlító táblázat
Hasonló helyzet figyelhető meg a lemezírási hozzáférések gyakoriságával: egy klasszikus vírusirtó esetében ez 1011 IOPS, egy felhő víruskeresőnél pedig 671 IOPS.
Lemezelérési arány összehasonlító grafikon
A teljesítménybeli előnyök lehetővé teszik az infrastruktúra stabilitásának fenntartását és a számítási teljesítmény hatékonyabb felhasználását. A nyilvános felhőkörnyezetben való munkához alkalmazkodva a megoldás nem csökkenti a felhőteljesítményt: központilag ellenőrzi a fájlokat és letölti a frissítéseket, elosztva a terhelést. Ez azt jelenti, hogy egyrészt nem maradnak el a felhő infrastruktúrával kapcsolatos fenyegetések, másrészt a virtuális gépek erőforrásigénye átlagosan 25%-kal csökken egy hagyományos vírusirtóhoz képest.
A funkcionalitást tekintve mindkét megoldás nagyon hasonlít egymásra: az alábbiakban egy összehasonlító táblázat található. A felhőben azonban, mint a fenti teszteredmények mutatják, még mindig optimális a virtuális környezetekhez való megoldás használata.
A tarifákról az új szemlélet keretein belül. Úgy döntöttünk, hogy olyan modellt használunk, amely lehetővé teszi, hogy a vCPU-k száma alapján szerezzünk licenceket. Ez azt jelenti, hogy a licencek száma megegyezik a vCPU-k számával. A víruskeresőt egy kérés meghagyásával tesztelheti .
A felhő témájú következő cikkünkben a felhő WAF-ok fejlődéséről lesz szó, és arról, hogy mit érdemes választani: hardvert, szoftvert vagy felhőt.
A szöveget a #CloudMTS felhőszolgáltató munkatársai készítették: Denis Myagkov vezető építész és Alekszej Afanasjev, információbiztonsági termékfejlesztési vezető.
Forrás: will.com