Stále více uživatelů přenáší celou svou IT infrastrukturu do veřejného cloudu. Nicméně v případě nedostatečné antivirové kontroly v infrastruktuře zákazníka vznikají vážná kybernetická rizika. Praxe ukazuje, že až 80 % stávajících virů se skvěle usazuje ve virtuálním prostředí. V tomto příspěvku si povíme, jak ochránit IT zdroje ve veřejném cloudu a proč tradiční antiviry pro tyto účely nejsou zcela vhodné.
Nejdříve si povíme, jak jsme došli k myšlence, že pro veřejný cloud nevyhovují obvyklé nástroje antivirové ochrany a že jsou potřeba odlišné přístupy k ochraně zdrojů.
Za prvé, poskytovatelé obvykle zajišťují potřebná opatření k tomu, aby garantovali vysokou úroveň ochrany svých cloudových platforem. Například my v #CloudMTS analyzujeme veškerý síťový provoz, monitorujeme záznamy bezpečnostních systémů našeho cloudu a pravidelně provádíme penetrační testy. Segmenty cloudu, které jsou svěřeny jednotlivým klientům, také musí být spolehlivě chráněny.
Za druhé, klasická varianta boje s kybernetickými riziky předpokládá instalaci antiviru a prostředků jeho správy na každém virtuálním stroji. Nicméně při velkém počtu virtuálních strojů může být tato praxe neefektivní a vyžadovat značné množství výpočetních zdrojů, čímž dále zatěžuje infrastrukturu zákazníka a snižuje celkový výkon cloudu. To se stalo klíčovým důvodem pro hledání nových přístupů k vytváření efektivní antivirové ochrany virtuálních strojů zákazníků.
Kromě toho většina dostupných antivirových řešení na trhu není přizpůsobena pro řešení úkolů ochrany IT zdrojů ve veřejném cloudovém prostředí. Obvykle se jedná o těžká EPP řešení (Endpoint Protection Platforms), která navíc nenabízejí potřebnou přizpůsobivost na straně klientů cloudového poskytovatele.
Stává se zřejmým, že tradiční antivirová řešení se špatně hodí pro práci v cloudu, protože vážně zatěžují virtuální infrastrukturu během aktualizací a skenování, také nemají potřebné úrovně role managementu a nastavení. Dále podrobně probereme, proč cloud potřebuje nové přístupy k antivirové ochraně.
Co by měl antivirus umět v veřejném cloudu
Pojďme se tedy zaměřit na specifika práce ve virtuálním prostředí:
Účinnost provádění aktualizací a hromadných kontrol podle plánu. Pokud významné množství virtuálních strojů, které používají tradiční antivirus, současně iniciuje aktualizaci, v cloudu dojde k takzvané „aktualizační bouři“. Kapacity ESXi hostitele, na kterém je umístěno několik virtuálních strojů, nemusí stačit na zpracování přívalových úloh spuštěných ve výchozím nastavení. Z pohledu cloudového poskytovatele může tento problém vést k dodatečným zátěžím na řadu ESXi hostitelů, což nakonec povede k poklesu výkonu virtuální infrastruktury cloudu. To se může odrazit i na výkonu virtuálních strojů dalších klientů cloudu. Podobná situace může nastat při spuštění hromadného skenování: současné zpracování velkého množství podobných požadavků od různých uživatelů diskovým systémem bude negativně ovlivňovat výkon celého cloudu. S vysokou pravděpodobností se snížení výkonu úložiště odrazí na všech klientech. Tyto skokové zátěže nepotěší ani poskytovatele, ani jeho zákazníky, protože ovlivňují „sousedé“ v cloudu. Z tohoto pohledu může tradiční antivirus představovat značný problém.
Bezpečná karanténa. Pokud je v systému nalezen soubor nebo dokument potenciálně infikovaný virem, je zaslán do karantény. Samozřejmě, infikovaný soubor lze okamžitě smazat, ale to je často pro většinu firem nepřijatelné. Firemní enterprise antiviry, které nejsou přizpůsobeny k použití v cloudu poskytovatele, obvykle mají společnou karanténní zónu — do ní spadají všechny infikované objekty. Například ty, které byly objeveny na počítačích uživatelů firmy. Klienti cloudového poskytovatele „žijí“ ve svých vlastních segmentech (nebo tenantech). Tyto segmenty jsou neprůhledné a izolované: klienti o sobě nevědí a samozřejmě nevidí, co do cloudu umisťují ostatní. Je zřejmé, že do společné karantény, kterou budou využívat všichni uživatelé antiviru v cloudu, se potenciálně může dostat dokument obsahující důvěrné informace nebo obchodní tajemství. To je pro poskytovatele a jeho klienty nepřijatelné. Proto může být řešení pouze jedno – osobní karanténa pro každého klienta ve svém segmentu, do níž nemají přístup ani poskytovatel, ani ostatní klienti.
Individuální bezpečnostní politiky. Každý klient v cloudu je samostatná firma, jejíž IT oddělení nastavuje své bezpečnostní politiky. Například administrátoři určují pravidla skenování a rozvrh antivirových kontrol. Odpovídajícím způsobem musí mít každá organizace své řídicí centrum pro nastavování antivirových politik. Přitom zadané nastavení nesmí ovlivnit ostatní klienty cloudu a poskytovatel by měl mít možnost ujistit se, že například aktualizace antiviru probíhají v normálním režimu pro všechny virtuální stroje klienta.
Organizace fakturace a licencování. Cloudový model se vyznačuje flexibilitou a předpokládá plnění pouze za objem IT zdrojů, které klient skutečně použil. Pokud je potřeba, například s ohledem na sezónní faktory, je možné objem zdrojů operativně zvyšovat nebo snižovat — vše na základě aktuálních požadavků na výpočetní výkon. Tradiční antivir není tak flexibilní — obvykle si klient kupuje licenci na rok na předem určený počet. servery nebo pracovních stanic. Uživatelé cloudu pravidelně odpojují a připojují další virtuální stroje v závislosti na svých aktuálních potřebách — tím pádem by licencování antiviru mělo podporovat stejný model.
Druhou otázkou je, na co přesně se licence vztahuje. Tradiční antivirus je licencován podle počtu serverů nebo pracovních stanic. Licence podle počtu chráněných virtuálních strojů nejsou zcela vhodné v rámci cloudového modelu. Klient může z dostupných zdrojů vytvořit libovolný počet virtuálních strojů, například pět nebo deset strojů. Toto číslo většiny klientů není stálé, sledovat jeho změnu pro nás jako poskytovatele není možné. Licencování podle CPU není technicky možné: klienti dostávají virtuální procesory (vCPU), na které by mělo probíhat licencování. Nový model antivirové ochrany by proto měl předpokládat možnost určení potřebného počtu vCPU, za které klient získá antivirové licence.
Soulad s legislativou. Důležitý bod, protože použitá řešení musí zajišťovat splnění požadavků regulátora. Například často „obyvatelé“ cloudu pracují s osobními údaji. V takovém případě by měl poskytovatel disponovat odděleným certifikovaným segmentem cloudu, který plně vyhovuje požadavkům zákona „O osobních údajích“. Poté společnosti nemusí samostatně „staví“ celý systém pro práci s osobními údaji: nakupovat certifikované vybavení, připojovat ho a nastavovat, podstupovat certifikaci. Pro kybernetickou ochranu ISPDn těchto klientů by také měl antivirus splňovat požadavky ruské legislativy a mít certifikát FSTEK.
Prozkoumali jsme povinná kritéria, která by měla splňovat antivirová ochrana ve veřejném cloudu. Dále se podělíme o vlastní zkušenosti s přizpůsobením antivirového řešení pro práci v cloudu poskytovatele.
Jak lze spojit antivirus a cloud?
Na základě naší zkušenosti platí, že vybrat řešení podle popisu a dokumentace je jedna věc, ale implementovat ho v již fungujícím cloudovém prostředí je úkol mnohem složitější. Pojďme si říct, co jsme dělali v praxi a jak jsme přizpůsobili antivirus pro práci v veřejném cloudu poskytovatele. Dodavatelem antivirového řešení se stal Kaspersky, jehož portfolio zahrnuje řešení pro antivirovou ochranu v cloudových prostředích. Zvolili jsme 'Kaspersky Security pro virtuální prostředí' (Lehký agent).
To zahrnuje jednotnou konzoli Kaspersky Security Center. Lehký agent a bezpečnostní virtuální stroje (SVM, Security Virtual Machine) a server integrace KSC.
Poté, co jsme prozkoumali architekturu řešení Kaspersky a provedli první testy společně s inženýry dodavatele, nastala otázka integrace služby do cloudu. První nasazení bylo provedeno společnými silami na moskevské platformě cloudu. A zde je to, co jsme pochopili.
Abychom minimalizovali síťový provoz, bylo rozhodnuto umístit SVM na každý ESXi host a 'připojit' SVM k ESXi hostům. V takovém případě se lehké agenti chráněných virtuálních strojů obracejí na SVM právě toho ESXi hosta, na kterém jsou spuštěny. Pro hlavní KSC byl zvolen samostatný administrativní tenant. Výsledkem je, že podřízené KSC se nachází v tenantech každého jednotlivého klienta a obrací se na nadřazený KSC, umístěný v segmentu správy. Tento model umožňuje rychle řešit problémy, které vznikají v tenantech klientů.
Kromě otázek týkajících se nasazení samotných komponent antivirového řešení jsme čelili úkolu organizace síťové komunikace prostřednictvím vytváření dalších VxLAN. Ačkoli bylo řešení původně určeno pro enterprise klienty s privátními cloudu — díky inženýrské vynalézavosti a technologické flexibilitě NSX Edge se nám podařilo vyřešit všechny úkoly spojené se segmentací tenantů a licencováním.
Úzce jsme spolupracovali s inženýry společnosti Kaspersky. Během analýzy architektury řešení v oblasti síťové interakce mezi komponenty systému jsme zjistili, že kromě přístupu lehkých agentů k SVM je také nezbytná zpětná vazba – z SVM k lehkým agentům. Tato síťová provázanost je v multitenantním prostředí nemožná kvůli možnosti existence identických síťových nastavení virtuálních strojů v různých tenantech cloudu. Proto byl na naši žádost mechanismus síťové interakce mezi lehkým agentem a SVM přepracován tak, aby se vyloučila potřeba síťové provázanosti z SVM k lehkým agentům.
Po rozložení a testování řešení na moskevské cloudové platformě jsme jej zkopírovali na další platformy, včetně certifikovaného segmentu cloudu. Nyní je služba dostupná ve všech regionech země.
Architektura řešení kybernetické bezpečnosti v rámci nového přístupu
Obecný schéma fungování antivirového řešení v veřejném cloudovém prostředí vypadá takto:
Schéma fungování antivirového řešení v veřejném cloudovém prostředí #CloudMTS
Popíšeme zvláštnosti fungování jednotlivých komponent řešení v cloudu:
• Jediná konzole, která umožňuje klientům centrálně spravovat ochranný systém: spouštět kontroly, sledovat aktualizace a pozorovat karanténní zóny. Existuje možnost nastavovat individuální bezpečnostní politiky v rámci svého segmentu.
Je třeba poznamenat, že i když jsme poskytovatelem služby, nezasahujeme do nastavení provedených klienty. To jediné, co můžeme udělat, je resetovat bezpečnostní politiky na výchozí, pokud je potřeba přeprogramovat. Například to může být nutné, pokud klient náhodou tyto politiky zpřísnil nebo výrazně uvolnil. Společnost vždy může získat řídicí centrum s výchozími politikami, které může poté samostatně přizpůsobit. Nevýhodou Kaspersky Security Center je, že zatím je platforma dostupná pouze pro operační systém Microsoft. Ačkoli lehké agenty mohou fungovat jak na Windows, tak na Linuxových strojích. Nicméně v „Laboratořích Kaspersky“ slibují, že už v blízké době bude KSC fungovat i pod operačním systémem Linux. Jedna z důležitých funkcí KSC je možnost správy karantény. Každá společnost-klient v našem cloudu má vlastní karanténu. Tento přístup vylučuje situace, kdy by infikovaný dokument náhodně unikl na veřejnost, jak by to mohlo nastat v případě klasického firemního antiviru s centrální karanténou.
• Lehké agenty. V rámci nového modelu je na každou virtuální stroj instalován lehký agent Kaspersky Security. To umožňuje neukládat antivirovou databázi na každém VM, což snižuje objem zabraného diskového prostoru. Služba je integrována se cloudovou infrastrukturou a pracuje prostřednictvím SVM, což zvyšuje hustotu virtuálních strojů na ESXi hostiteli a výkon celého cloudového systému. Lehké agenti vytvářejí frontu úkolů pro každý virtuální stroj: prověřit souborový systém, paměť atd. Ale za provádění těchto operací už odpovídá SVM, o které si povíme dále. Také agent vykonává funkce firewallu, kontroluje bezpečnostní politiky, posílá infikované soubory do karantény a monitoruje celkové „zdraví“ operačního systému, na kterém je nainstalován. Vše tímto lze spravovat pomocí již zmíněné jednotné konzole.
• Bezpečnostní virtuální stroj. Všechny zdroje náročné úkoly (aktualizace antivirových databází, provádění plánovaných kontrol) zajišťuje samostatný Bezpečnostní virtuální stroj (SVM). Ten je zodpovědný za provoz plnohodnotného antivirového motoru a jeho databází. IT infrastruktura společnosti může zahrnovat několik SVM. Tento přístup zvyšuje spolehlivost systému — pokud nějaký stroj selže a neodpovídá po dobu třiceti sekund, agenti automaticky začnou vyhledávat jiný.
• Server integrace KSC. Jedna z komponent hlavního KSC, která přiděluje podle v jeho nastavení zadaného algoritmu lehkým agentům své SVM, a také kontroluje dostupnost SVM. Tímto způsobem tento softwarový modul zajišťuje vyvážení zátěže na všech SVM cloudové infrastruktury.
Algoritmus práce v cloudu: snížení zátěže na infrastrukturu
Celkově lze algoritmus fungování antiviru představit následovně. Agent se obrací na soubor na virtuálním stroji a kontroluje ho. Výsledek kontroly se ukládá do společné centralizované databáze verdiktů SVM (ta se nazývá Shared Cache), přičemž každá položka v této databázi identifikuje jedinečný vzorek souboru. Tento přístup umožňuje sledovat, aby stejný soubor nebyl kontrolován několikrát po sobě (například, pokud ho otevřeli na různých virtuálních strojích). Soubor se znovu skenuje pouze v případě, že do něj byly provedeny změny nebo byla kontrola spuštěna ručně.
Realizace antivirového řešení v cloudu poskytovatele
Na obrázku je znázorněn celkový schéma implementace řešení v cloudu. V řídicí zóně cloudu je nasazen hlavní Kaspersky Security Center a na každém ESXi hostiteli je pomocí integračního serveru KSC nasazena individuální SVM (každé ESXi hostiteli je zvláštními nastaveními na VMware vCenter Server přiřazena vlastní SVM). Klienti pracují ve svých segmentech cloudu, kde jsou umístěny virtuální stroje s agenty. Tyto pořizují prostřednictvím individuálních KSC serverů, které podléhají hlavnímu KSC. V případě potřeby ochrany malého počtu virtuálních strojů (do 5) může být klientovi poskytnut přístup k virtuální konzoli specializovaného dedikovaného serveru KSC. Síťová interakce mezi klientskými KSC a hlavním KSC, stejně jako mezi lehkými agenty a SVM, probíhá pomocí NAT přes klientské virtuální směrovače EdgeGW.
Podle našich odhadů a výsledků testů kolegů u dodavatele, Lehké agenty snižují zátěž na virtuální infrastruktuře klientů přibližně o 25 % (ve srovnání se systémem, který používá tradiční antivirus). Konkrétně standardní antivirus Kaspersky Endpoint Security (KES) pro fyzická prostředí spotřebovává téměř dvakrát více procesorového času serveru (2,95 %) než řešení pro virtualizaci založené na lehkých agentech (1,67 %).
Graf porovnání zátěže na procesor
Podobná situace se projevuje u frekvence zapisování na disk: pro klasický antivirus je 1011 IOPS, pro cloudový antivirus — 671 IOPS.
Graf porovnání frekvence přístupu na disk
Zisk v výkonu umožňuje udržovat stabilitu infrastruktury a efektivněji využívat výpočetní zdroje. Díky adaptaci pro práci v veřejném cloudovém prostředí řešení nesnižuje výkon cloudu: provádí centralizované kontroly souborů a stahování aktualizací, čímž rozděluje zátěž. To znamená, že na jedné straně nebudou přehlédnuty aktuální hrozby pro cloudovou infrastrukturu, na druhé straně se průměrně o 25 % sníží požadavky na zdroje virtuálních strojů ve srovnání s tradičním antivirem.
Funkčně si obě řešení velmi připomínají: níže je uvedena srovnávací tabulka. Ve cloudu je však, jak ukazují výše uvedené testovací výsledky, optimálnější použít řešení pro virtuální prostředí.
O tarifaci v rámci nového přístupu. Rozhodli jsme se využít model, který umožňuje získávat licence podle počtu vCPU. To znamená, že počet licencí bude odpovídat počtu vCPU. Antivir můžete otestovat tím, že podáte žádost. .
V dalším materiálu o cloudovém tématu se podíváme na evoluci cloudových WAF a na to, co je lepší zvolit: hardware, software nebo cloud.
Text připravili zaměstnanci cloudového poskytovatele #CloudMTS: Denis Mjagkov, hlavní architekt a Alexej Afanasjev, manažer pro rozvoj produktů v oblasti kybernetické bezpečnosti.
Zdroj: habr.com
