Stále více uživatelů přenáší celou svou IT infrastrukturu do veřejného cloudu. Pokud je však antivirová kontrola v infrastruktuře zákazníka nedostatečná, vznikají vážná kybernetická rizika. Praxe ukazuje, že až 80 % existujících virů žije perfektně 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č nejsou klasické antiviry pro tyto účely zcela vhodné.
Nejprve vám povíme, jak jsme došli k myšlence, že obvyklé nástroje antivirové ochrany nejsou vhodné pro veřejný cloud a že jsou vyžadovány jiné přístupy k ochraně zdrojů.
Za prvé, poskytovatelé obecně poskytují nezbytná opatření, aby zajistili, že jejich cloudové platformy budou chráněny na vysoké úrovni. Například v #CloudMTS analyzujeme veškerý síťový provoz, sledujeme protokoly bezpečnostních systémů našeho cloudu a pravidelně provádíme pentesty. Segmenty cloudu přidělené jednotlivým klientům musí být také bezpečně chráněny.
Za druhé, klasická možnost pro boj s kybernetickými riziky zahrnuje instalaci antivirového a antivirového nástroje pro správu na každý virtuální stroj. S velkým počtem virtuálních strojů však může být tento postup neúčinný a vyžaduje 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 předpokladem pro hledání nových přístupů k budování efektivní antivirové ochrany pro virtuální stroje zákazníků.
Většina antivirových řešení na trhu navíc není uzpůsobena k řešení problémů ochrany IT zdrojů v prostředí veřejného cloudu. Zpravidla se jedná o těžká řešení EPP (Endpoint Protection Platforms), která navíc neposkytují potřebné přizpůsobení na straně klienta poskytovatele cloudu.
Je zřejmé, že tradiční antivirová řešení nejsou vhodná pro práci v cloudu, protože vážně zatěžují virtuální infrastrukturu během aktualizací a kontrol a také nemají potřebné úrovně správy a nastavení na základě rolí. Dále podrobně rozebereme, proč cloud potřebuje nové přístupy k antivirové ochraně.
Co by měl umět antivirus ve veřejném cloudu
Věnujme tedy pozornost specifikům práce ve virtuálním prostředí:
Efektivita aktualizací a plánovaných hromadných kontrol. Pokud významný počet virtuálních počítačů využívajících tradiční antivirus spustí aktualizaci současně, dojde v cloudu k takzvané „bouři“ aktualizací. Výkon hostitele ESXi, který je hostitelem několika virtuálních strojů, nemusí stačit na to, aby zvládl množství podobných úloh spuštěných ve výchozím nastavení. Z pohledu poskytovatele cloudu může takový problém vést k dodatečnému zatížení řady hostitelů ESXi, což v konečném důsledku povede k poklesu výkonu cloudové virtuální infrastruktury. To může mimo jiné ovlivnit výkon virtuálních strojů jiných cloudových klientů. Podobná situace může nastat při spuštění hromadné kontroly: současné zpracování mnoha podobných požadavků od různých uživatelů diskovým systémem negativně ovlivní výkon celého cloudu. S vysokou mírou pravděpodobnosti se pokles výkonu úložného systému dotkne všech klientů. Taková náhlá zatížení nepotěší ani poskytovatele, ani jeho zákazníky, protože ovlivňují „sousedy“ v cloudu. Z tohoto pohledu mohou tradiční antiviry představovat velký problém.
Bezpečná karanténa. Pokud je v systému detekován soubor nebo dokument potenciálně infikovaný virem, je odeslán do karantény. Infikovaný soubor lze samozřejmě okamžitě smazat, ale to je pro většinu společností často nepřijatelné. Firemní podnikové antiviry, které nejsou přizpůsobeny pro práci v cloudu poskytovatele, mají zpravidla společnou karanténní zónu - do ní spadají všechny infikované objekty. Například ty, které se nacházejí na počítačích firemních uživatelů. Klienti poskytovatele cloudu „žijí“ ve svých vlastních segmentech (neboli tenantech). Tyto segmenty jsou neprůhledné a izolované: klienti o sobě navzájem nevědí a samozřejmě nevidí, co ostatní v cloudu hostují. Je zřejmé, že všeobecná karanténa, ke které budou mít přístup všichni uživatelé antiviru v cloudu, by mohla potenciálně zahrnovat dokument obsahující důvěrné informace nebo obchodní tajemství. To je pro poskytovatele a jeho zákazníky nepřijatelné. Proto může existovat jediné řešení – osobní karanténa pro každého klienta v jeho segmentu, kam nemá přístup poskytovatel ani další klienti.
Individuální bezpečnostní zásady. Každý klient v cloudu je samostatná společnost, jejíž IT oddělení si nastavuje vlastní bezpečnostní politiku. Správci například definují pravidla kontroly a plánují antivirové kontroly. V souladu s tím musí mít každá organizace své vlastní řídicí centrum pro konfiguraci antivirových zásad. Uvedené nastavení by zároveň nemělo mít vliv na ostatní cloudové klienty a poskytovatel by měl mít možnost ověřit, že například aktualizace antiviru probíhají jako obvykle u všech klientských virtuálních strojů.
Organizace fakturace a licencování. Cloudový model se vyznačuje flexibilitou a zahrnuje platbu pouze za množství IT zdrojů, které zákazník použil. Pokud je potřeba např. z důvodu sezónnosti, pak lze množství zdrojů rychle navýšit nebo snížit – vše na základě aktuální potřeby výpočetního výkonu. Tradiční antivirus není tak flexibilní – zpravidla si klient koupí licenci na rok pro předem daný počet serverů nebo pracovních stanic. Uživatelé cloudu se pravidelně odpojují a připojují další virtuální stroje v závislosti na jejich aktuálních potřebách – podle toho musí antivirové licence podporovat stejný model.
Druhá otázka je, co přesně bude licence pokrývat. Tradiční antivirus je licencován podle počtu serverů nebo pracovních stanic. Licence založené na počtu chráněných virtuálních strojů nejsou v rámci cloudového modelu zcela vhodné. Klient si může z dostupných zdrojů vytvořit libovolný počet pro něj vhodných virtuálních strojů, například pět nebo deset strojů. Toto číslo není pro většinu klientů konstantní, není možné pro nás jako poskytovatele sledovat jeho změny. Neexistuje žádná technická možnost licencování podle CPU: klienti obdrží virtuální procesory (vCPU), které by měly být použity pro licencování. Nový model antivirové ochrany by tak měl obsahovat možnost, aby si zákazník sám určil požadovaný počet vCPU, na které obdrží antivirové licence.
Soulad s legislativou. Důležitý bod, protože použitá řešení musí zajistit shodu s požadavky regulátora. Například „obyvatelé cloudu“ často pracují s osobními údaji. V tomto případě musí mít poskytovatel samostatný certifikovaný cloudový segment, který plně vyhovuje požadavkům zákona o osobních údajích. Firmy pak nemusejí samostatně „budovat“ celý systém pro práci s osobními údaji: nakupovat certifikované zařízení, připojovat a konfigurovat a podstupovat certifikaci. Pro kybernetickou ochranu ISPD takových klientů musí antivir splňovat i požadavky ruské legislativy a mít certifikát FSTEC.
Podívali jsme se na povinná kritéria, která musí antivirová ochrana ve veřejném cloudu splňovat. 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 se můžete spřátelit mezi antivirem a cloudem?
Jak ukázaly naše zkušenosti, vybrat řešení na základě popisu a dokumentace je jedna věc, ale implementovat jej do praxe v již fungujícím cloudovém prostředí je z hlediska náročnosti úplně jiný úkol. Prozradíme vám, co jsme dělali v praxi a jak jsme přizpůsobili antivir pro fungování ve veřejném cloudu poskytovatele. Dodavatelem antivirového řešení byla společnost Kaspersky, jejíž portfolio zahrnuje řešení antivirové ochrany pro cloudová prostředí. Rozhodli jsme se pro „Kaspersky Security for Virtualization“ (Light Agent).
Zahrnuje jednu konzolu Kaspersky Security Center. Lehký agent a bezpečnostní virtuální stroje (SVM, Security Virtual Machine) a integrační server KSC.
Poté, co jsme prostudovali architekturu řešení Kaspersky a provedli první testy společně s inženýry dodavatele, vyvstala otázka integrace služby do cloudu. První implementace byla provedena společně v cloudové lokalitě Moskva. A to jsme si uvědomili.
Aby se minimalizoval provoz v síti, bylo rozhodnuto umístit SVM na každého hostitele ESXi a „svázat“ SVM s hostiteli ESXi. V tomto případě lehcí agenti chráněných virtuálních počítačů přistupují k SVM přesného hostitele ESXi, na kterém běží. Pro hlavní KSC byl vybrán samostatný administrativní nájemce. V důsledku toho se podřízené KSC nacházejí v nájemcích každého jednotlivého klienta a oslovují nadřízené KSC umístěné v segmentu managementu. Toto schéma umožňuje rychle řešit problémy, které vznikají u klientských nájemců.
Kromě problémů s navyšováním komponent samotného antivirového řešení jsme byli postaveni před úkol zorganizovat síťovou interakci vytvořením dalších VxLAN. A přestože bylo řešení původně určeno pro podnikové klienty s privátními cloudy, s pomocí inženýrské zdatnosti a technologické flexibility NSX Edge jsme dokázali vyřešit všechny problémy spojené s oddělením nájemců a licencováním.
Úzce jsme spolupracovali s inženýry společnosti Kaspersky. V procesu analýzy architektury řešení z hlediska síťové interakce mezi komponentami systému bylo tedy zjištěno, že kromě přístupu od světelných agentů k SVM je nezbytná také zpětná vazba – od SVM k lehkým agentům. Tato síťová konektivita není možná v multitenantském prostředí kvůli možnosti identického síťového nastavení virtuálních strojů v různých cloudových tenantech. Kolegové od dodavatele proto na naši žádost přepracovali mechanismus síťové interakce mezi light agentem a SVM z hlediska eliminace potřeby síťové konektivity z SVM na light agenty.
Po nasazení a testování řešení na cloudovém webu v Moskvě jsme ho replikovali na další weby, včetně certifikovaného cloudového segmentu. Služba je nyní dostupná ve všech regionech země.
Architektura řešení informační bezpečnosti v rámci nového přístupu
Obecné schéma fungování antivirového řešení v prostředí veřejného cloudu je následující:
Schéma fungování antivirového řešení v prostředí veřejného cloudu #CloudMTS
Pojďme si popsat vlastnosti fungování jednotlivých prvků řešení v cloudu:
• Jediná konzola, která klientům umožňuje centrálně spravovat systém ochrany: spouštět kontroly, řídit aktualizace a monitorovat zóny karantény. V rámci vašeho segmentu je možné konfigurovat jednotlivé bezpečnostní politiky.
Nutno podotknout, že ačkoliv jsme poskytovatelem služeb, nezasahujeme do nastavení nastavených klienty. Jediné, co můžeme udělat, je resetovat bezpečnostní zásady na standardní, pokud je nutná rekonfigurace. To může být například nutné, pokud je klient omylem utáhl nebo výrazně oslabil. Společnost může vždy obdržet řídicí centrum s výchozími zásadami, které pak může samostatně konfigurovat. Nevýhodou Kaspersky Security Center je, že platforma je aktuálně dostupná pouze pro operační systém Microsoft. Ačkoli odlehčení agenti mohou pracovat s počítači se systémem Windows i Linux. Kaspersky Lab však slibuje, že v blízké budoucnosti bude KSC fungovat pod OS Linux. Jednou z důležitých funkcí KSC je schopnost řídit karanténu. Každá klientská společnost v našem cloudu má svůj osobní. Tento přístup eliminuje situace, kdy se dokument infikovaný virem náhodně stane veřejně viditelným, jak by se mohlo stát v případě klasického firemního antiviru s celkovou karanténou.
• Světelné látky. V rámci nového modelu je na každém virtuálním počítači nainstalován odlehčený agent Kaspersky Security. To eliminuje potřebu ukládat antivirovou databázi na každý virtuální počítač, což snižuje množství požadovaného místa na disku. Služba je integrována s cloudovou infrastrukturou a funguje prostřednictvím SVM, což zvyšuje hustotu virtuálních strojů na hostiteli ESXi a výkon celého cloudového systému. Light agent vytvoří frontu úloh pro každý virtuální stroj: zkontrolujte souborový systém, paměť atd. Ale SVM je zodpovědný za provádění těchto operací, o kterých si povíme později. Agent také funguje jako firewall, řídí bezpečnostní zásady, odesílá infikované soubory do karantény a monitoruje celkové „zdraví“ operačního systému, na kterém je nainstalován. To vše lze spravovat pomocí již zmíněné jediné konzole.
• Zabezpečení virtuálního stroje. Všechny úlohy náročné na zdroje (aktualizace antivirové databáze, plánované kontroly) jsou řešeny samostatným virtuálním počítačem zabezpečení (SVM). Je zodpovědná za provoz plnohodnotného antivirového enginu a databází k němu. Infrastruktura IT společnosti může zahrnovat několik SVM. Tento přístup zvyšuje spolehlivost systému – pokud jeden stroj selže a nereaguje třicet sekund, agenti automaticky začnou hledat jiný.
• Integrační server KSC. Jedna ze součástí hlavního KSC, která přiřazuje své SVM lehkým agentům v souladu s algoritmem uvedeným v jeho nastavení a také řídí dostupnost SVM. Tento softwarový modul tedy poskytuje vyrovnávání zátěže napříč všemi SVM cloudové infrastruktury.
Algoritmus pro práci v cloudu: snížení zátěže infrastruktury
Obecně lze antivirový algoritmus znázornit následovně. Agent přistupuje k souboru na virtuálním počítači a zkontroluje jej. Výsledek ověření je uložen ve společné centralizované databázi verdiktů SVM (nazývané sdílená mezipaměť), kde každý záznam identifikuje jedinečný vzorek souboru. Tento přístup umožňuje zajistit, aby stejný soubor nebyl zkontrolován několikrát za sebou (například pokud byl otevřen na různých virtuálních počítačích). Soubor je znovu zkontrolován pouze v případě, že v něm byly provedeny změny nebo byla kontrola spuštěna ručně.
Implementace antivirového řešení v cloudu poskytovatele
Obrázek ukazuje obecné schéma implementace řešení v cloudu. Hlavní Kaspersky Security Center je nasazeno v kontrolní zóně cloudu a na každém hostiteli ESXi je nasazen samostatný SVM pomocí integračního serveru KSC (každý hostitel ESXi má připojený vlastní SVM se speciálním nastavením na serveru VMware vCenter Server). Klienti pracují ve vlastních cloudových segmentech, kde jsou umístěny virtuální stroje s agenty. Jsou spravovány prostřednictvím jednotlivých serverů KSC podřízených hlavnímu KSC. Pokud je potřeba chránit malý počet virtuálních strojů (do 5), lze klientovi poskytnout přístup k virtuální konzoli speciálního dedikovaného KSC serveru. Síťová interakce mezi klientskými KSC a hlavním KSC, stejně jako lehkými agenty a SVM, se provádí pomocí NAT prostřednictvím klientských virtuálních směrovačů EdgeGW.
Podle našich odhadů a výsledků testů kolegů u dodavatele snižuje Light Agent zátěž virtuální infrastruktury klientů přibližně o 25 % (ve srovnání se systémem využívajícím tradiční antivirový software). Zejména standardní antivirus Kaspersky Endpoint Security (KES) pro fyzická prostředí spotřebovává téměř dvakrát tolik času procesoru serveru (2,95 %) než odlehčené virtualizační řešení založené na agentech (1,67 %).
Graf srovnání zatížení CPU
Podobná situace je pozorována u frekvence přístupů k zápisu na disk: u klasického antiviru je to 1011 IOPS, u cloudového antiviru je to 671 IOPS.
Graf porovnání rychlosti přístupu na disk
Výhoda výkonu umožňuje udržovat stabilitu infrastruktury a efektivněji využívat výpočetní výkon. Tím, že se řešení přizpůsobí práci v prostředí veřejného cloudu, nesnižuje výkon cloudu: centrálně kontroluje soubory a stahuje aktualizace a rozděluje zátěž. To znamená, že na jedné straně nebudou chybět hrozby relevantní pro cloudovou infrastrukturu, na druhé straně se nároky na zdroje virtuálních strojů sníží v průměru o 25 % ve srovnání s tradičním antivirem.
Z hlediska funkčnosti jsou si obě řešení velmi podobná: níže je srovnávací tabulka. Nicméně v cloudu, jak ukazují výsledky testů výše, je stále optimální použít řešení pro virtuální prostředí.
O tarifech v rámci nového přístupu. Rozhodli jsme se použít model, který nám umožňuje získat licence na základě počtu vCPU. To znamená, že počet licencí se bude rovnat počtu vCPU. Svůj antivirus můžete otestovat zanecháním požadavku .
V příštím článku o cloudových tématech si povíme o vývoji cloudových WAF a o tom, co je lepší zvolit: hardware, software nebo cloud.
Text připravili zaměstnanci cloudového poskytovatele #CloudMTS: Denis Myagkov, přední architekt a Alexey Afanasyev, manažer vývoje produktu pro bezpečnost informací.
Zdroj: www.habr.com