Coraz więcej użytkowników przenosi swoją całą infrastrukturę IT do publicznej chmury. Jednak w przypadku niewystarczającej kontroli antywirusowej w infrastrukturze klienta pojawiają się poważne ryzyka cybernetyczne. Praktyka pokazuje, że do 80% istniejących wirusów dobrze funkcjonuje w środowisku wirtualnym. W tym poście opowiemy, jak zabezpieczyć zasoby IT w chmurze publicznej i dlaczego tradycyjne programy antywirusowe nie nadają się do tych celów.
Na początku opowiemy, jak doszliśmy do przekonania, że tradycyjne narzędzia ochrony antywirusowej nie nadają się do publicznej chmury i wymagają innych podejść do zabezpieczenia zasobów.
Po pierwsze, z reguły dostawcy zapewniają niezbędne środki, aby zagwarantować ochronę swoich platform chmurowych na wysokim poziomie. Na przykład w #CloudMTS analizujemy cały ruch sieciowy, monitorujemy logi systemów bezpieczeństwa naszej chmury, regularnie przeprowadzamy testy penetracyjne. Segmenty chmury oddane poszczególnym klientom również muszą być odpowiednio zabezpieczone.
Po drugie, klasyczna metoda walki z ryzykiem cybernetycznym zakłada instalację programu antywirusowego i narzędzi do jego zarządzania na każdą maszynę wirtualną. Jednak przy dużej liczbie maszyn wirtualnych taka praktyka może być nieefektywna i wymagać znacznych zasobów obliczeniowych, co dodatkowo obciąża infrastrukturę klienta i obniża ogólną wydajność chmury. To stało się kluczowym powodem poszukiwania nowych podejść do budowy skutecznej ochrony antywirusowej maszyn wirtualnych klientów.
Ponadto, większość dostępnych na rynku rozwiązań antywirusowych nie jest dostosowana do zadań ochrony zasobów IT w publicznym środowisku chmurowym. Z reguły są to ciężkie rozwiązania EPP (Endpoint Protection Platforms), które zresztą nie oferują możliwości niezbędnej personalizacji po stronie klientów dostawcy chmury.
Jest oczywiste, że tradycyjne rozwiązania antywirusowe są słabo przystosowane do pracy w chmurze, ponieważ poważnie obciążają infrastrukturę wirtualną podczas aktualizacji i skanowania, a także nie mają niezbędnych poziomów zarządzania rolami i ustawień. Poniżej szczegółowo omówimy, dlaczego chmura potrzebuje nowych podejść do ochrony antywirusowej.
Jakie umiejętności powinien mieć antywirus w publicznej chmurze
Zatem zwróćmy uwagę na specyfikę pracy w środowisku wirtualnym:
Efektywność przeprowadzania aktualizacji oraz masowe kontrole zgodnie z harmonogramem. Jeśli znaczna liczba maszyn wirtualnych korzystających z tradycyjnego oprogramowania antywirusowego inicjuje aktualizację w tym samym czasie, w chmurze wystąpi tak zwany 'storm' aktualizacji. Zasoby hosta ESXi, na którym znajduje się wiele maszyn wirtualnych, mogą być niewystarczające do obsługi strumienia jednorodnych zadań uruchamianych domyślnie. Z punktu widzenia dostawcy chmury taki problem może prowadzić do dodatkowego obciążenia wielu hostów ESXi, co w efekcie doprowadzi do spadku wydajności wirtualnej infrastruktury chmury. Może to również wpłynąć na wydajność wirtualnych maszyn innych klientów chmury. Podobna sytuacja może mieć miejsce podczas uruchamiania masowego skanowania: równoczesne przetwarzanie przez system dyskowy wielu jednorodnych zapytań od różnych użytkowników negatywnie wpłynie na wydajność całej chmury. Z dużym prawdopodobieństwem spadek wydajności systemu SAN wpłynie na wszystkich klientów. Takie skoki obciążenia nie są ani dla dostawcy, ani dla jego klientów pozytywne, ponieważ wpływają na 'sąsiadów' w chmurze. Z tej perspektywy tradycyjny program antywirusowy może stanowić poważny problem.
Bezpieczna kwarantanna. Gdy w systemie zidentyfikowany zostanie plik lub dokument potencjalnie zainfekowany wirusem, trafia on do kwarantanny. Oczywiście, zainfekowany plik można od razu usunąć, ale jest to często nieakceptowalne dla większości firm. Korporacyjne rozwiązania antywirusowe, które nie są przystosowane do pracy w chmurze dostawcy, zazwyczaj mają wspólną strefę kwarantanny — trafiają do niej wszystkie zainfekowane obiekty, na przykład wykryte na komputerach użytkowników firmy. Klienci chmurowego dostawcy „żyją” w swoich własnych segmentach (lub tenantach). Te segmenty są nieprzezroczyste i izolowane: klienci nie wiedzą o sobie nawzajem i, oczywiście, nie widzą, co umieszczają w chmurze inni. Oczywiste jest, że do wspólnej kwarantanny, z której będą korzystać wszyscy użytkownicy antywirusa w chmurze, potencjalnie może trafić dokument zawierający poufne informacje lub tajemnicę handlową. Jest to nieakceptowalne dla dostawcy i jego klientów. Dlatego jedynym rozwiązaniem może być osobista kwarantanna dla każdego klienta w jego segmencie, do której nie mają dostępu ani dostawca, ani inni klienci.
Indywidualne polityki bezpieczeństwa. Każdy klient w chmurze to osobna firma, której dział IT ustala własne polityki bezpieczeństwa. Na przykład, administratorzy określają zasady skanowania i harmonogramy testów antywirusowych. W związku z tym każda organizacja powinna mieć swoje centrum zarządzania do dostosowywania polityk antywirusowych. Ustalone ustawienia nie powinny wpływać na innych klientów chmury, a dostawca powinien mieć możliwość upewnienia się, że na przykład aktualizacje antywirusowe odbywają się zgodnie z planem dla wszystkich maszyn wirtualnych klienta.
Organizacja rozliczeń i licencjonowanie. Model chmurowy charakteryzuje się elastycznością i zakłada płatność tylko za te zasoby IT, które zostały wykorzystane przez zamawiającego. W razie potrzeby, na przykład z powodu czynnika sezonowego, można szybko zwiększać lub zmniejszać ilość zasobów — wszystko w zależności od aktualnych potrzeb w zakresie mocy obliczeniowych. Tradycyjny antywirus nie jest tak elastyczny — zazwyczaj klient kupuje licencję na rok na z góry określoną ilość. serwerów lub stacji roboczych. Użytkownicy chmury regularnie wyłączają i włączają dodatkowe maszyny wirtualne w zależności od bieżących potrzeb — w związku z tym licencje na oprogramowanie antywirusowe muszą wspierać ten model.
Drugie pytanie dotyczy tego, na co dokładnie będzie się rozciągała licencja. Tradycyjny program antywirusowy licencjonowany jest na liczbę serwerów lub stacji roboczych. Licencje oparte na liczbie chronionych maszyn wirtualnych nie w pełni odpowiadają modelowi chmurowemu. Klient może utworzyć dowolną liczbę maszyn wirtualnych z dostępnych zasobów, na przykład pięć lub dziesięć maszyn. Liczba ta nie jest stała dla większości klientów, a monitorowanie jej zmian nie jest możliwe dla nas jako dostawcy. Licencjonowanie na podstawie CPU nie jest technicznie możliwe: klienci otrzymują wirtualne procesory (vCPU), na których powinno być oparte licencjonowanie. W związku z tym nowy model ochrony antywirusowej powinien zakładać możliwość określenia przez zamawiającego potrzebnej liczby vCPU, na które będzie otrzymywał licencje antywirusowe.
Zgodność z prawodawstwem. To ważny punkt, ponieważ stosowane rozwiązania muszą zapewniać spełnienie wymagań regulacyjnych. Na przykład często „mieszkańcy” chmury pracują z danymi osobowymi. W takim przypadku dostawca powinien posiadać oddzielny, zatwierdzony segment chmury, który w pełni odpowiada wymaganiom ustawy „O danych osobowych”. Dzięki temu firmy nie muszą samodzielnie „budować” całego systemu do pracy z danymi osobowymi: kupować certyfikowany sprzęt, podłączać go i konfigurować, a następnie przechodzić certyfikację. Dla cyberochrony ISPDn takich klientów, program antywirusowy również musi odpowiadać wymaganiom prawa rosyjskiego i posiadać certyfikat FSTEK.
Przeanalizowaliśmy te niezbędne kryteria, którym musi odpowiadać ochrona antywirusowa w chmurze publicznej. Następnie podzielimy się własnym doświadczeniem dotyczącym dostosowania rozwiązania antywirusowego do pracy w chmurze dostawcy.
Jak można zintegrować program antywirusowy z chmurą
Jak pokazuje nasze doświadczenie, wybranie rozwiązania na podstawie opisu i dokumentacji to jedno, a wdrożenie go w istniejącej chmurowej infrastrukturze to zupełnie inne wyzwanie pod względem złożoności. Opowiemy, co robiliśmy w praktyce i jak dostosowaliśmy program antywirusowy do pracy w publicznej chmurze dostawcy. Wydawcą rozwiązania antywirusowego stał się Kaspersky, który w swoim portfolio ma rozwiązania w zakresie ochrony antywirusowej dla środowisk chmurowych. Zdecydowaliśmy się na „Kaspersky Security dla środowisk wirtualnych” (Lekki agent).
Oferuje on jednolitą konsolę Kaspersky Security Center. Lekki agent, wirtualne maszyny zabezpieczeń (SVM, Security Virtual Machine) oraz serwer integracyjny KSC.
Po zapoznaniu się z architekturą rozwiązania Kaspersky i przeprowadzeniu pierwszych testów wspólnie z inżynierami dostawcy, pojawiła się kwestia integracji usługi w chmurze. Pierwsze wdrożenie zostało zrealizowane siłami wspólnymi w moskiewskim centrum chmurowym. Oto, czego się dowiedzieliśmy.
Aby zminimalizować ruch sieciowy, podjęto decyzję o umiejscowieniu SVM na każdym hoście ESXi i „przypisaniu” SVM do hostów ESXi. W takim przypadku lekkie agenty zabezpieczanych wirtualnych maszyn łączą się z SVM na tym hoście ESXi, na którym są uruchomione. Dla głównego KSC wybrano oddzielny zarządzający tenant. W rezultacie podległe KSC znajdują się w tenantach każdego klienta i łączą się z nadrzędnym KSC, znajdującym się w segmencie zarządzania. Taki schemat umożliwia szybkie rozwiązywanie problemów, które pojawiają się w tenantach klientów.
Oprócz problemów związanych z uruchamianiem komponentów samego rozwiązania antywirusowego, stanęła przed nami задача organizacji interakcji sieciowej poprzez stworzenie dodatkowych VxLAN. I chociaż rozwiązanie początkowo było przeznaczone dla klientów enterprise z prywatnymi chmurami — dzięki inżynieryjnej pomysłowości i elastyczności technologicznej NSX Edge udało nam się rozwiązać wszystkie problemy związane z separacją tenantów i licencjonowaniem.
Współpracowaliśmy blisko z inżynierami Kaspersky. W trakcie analizy architektury rozwiązania, dotyczącej interakcji sieciowej między komponentami systemu, stwierdzono, że oprócz dostępu lekkich agentów do SVM, potrzebna jest również informacja zwrotna – od SVM do lekkich agentów. Taka sieciowa interakcja jest niemożliwa w multitenantowym środowisku z uwagi na możliwość istnienia identycznych ustawień sieciowych maszyn wirtualnych w różnych tenantach chmury. Dlatego na naszą prośbę zespół dostawcy opracował na nowo mechanizm interakcji sieciowej między lekkim agentem a SVM, eliminując potrzebę połączenia sieciowego od SVM do lekkich agentów.
Po wdrożeniu rozwiązania i przetestowaniu go na moskiewskim obszarze chmury, zainstalowaliśmy je na pozostałych lokalizacjach, w tym w zatwierdzonym segmencie chmury. Obecnie usługa jest dostępna we wszystkich regionach kraju.
Architektura rozwiązania zabezpieczeń w ramach nowego podejścia
Ogólny schemat działania rozwiązania antywirusowego w publicznym środowisku chmurowym wygląda następująco:
Schemat działania rozwiązania antywirusowego w publicznym środowisku chmurowym #CloudMTS
Opiszemy szczegóły działania poszczególnych elementów rozwiązania w chmurze:
• Jednolita konsola, która umożliwia klientom centralne zarządzanie systemem ochrony: uruchamianie skanowania, kontrolowanie aktualizacji oraz monitorowanie stref kwarantanny. Istnieje możliwość dostosowywania indywidualnych polityk bezpieczeństwa w ramach swojego segmentu.
Należy zauważyć, że chociaż jesteśmy dostawcą usługi, nie ingerujemy w ustawienia wprowadzane przez klientów. Jedyne, co możemy zrobić, to przywrócić domyślne polityki bezpieczeństwa w przypadku potrzeby ich ponownej konfiguracji. Na przykład, może to być konieczne, jeśli klient przypadkowo je zaostrzył lub znacznie osłabił. Firma zawsze może uzyskać centrum zarządzania z domyślnymi politykami, które następnie może dostosować samodzielnie. Minusem Kaspersky Security Center jest to, że platforma jest obecnie dostępna tylko dla systemu operacyjnego Microsoft. Chociaż lekkie agenty mogą działać zarówno na maszynach Windows, jak i Linux. Jednak w „Laboratorium Kaspersky’ego” obiecują, że w najbliższej przyszłości KSC będzie działać również na systemie Linux. Jedną z ważnych funkcji KSC jest możliwość zarządzania kwarantanną. Każda firma-klient w naszym chmurze ma swoją osobistą kwarantannę. Takie podejście wyklucza sytuacje, w których zainfekowany wirusem dokument przypadkowo trafia na ogólnodostępne miejsce, co mogłoby się zdarzyć w przypadku klasycznego korporacyjnego oprogramowania antywirusowego z ogólną kwarantanną.
• Lekkie agenty. W ramach nowego modelu na każdą maszynę wirtualną instalowany jest lekki agent Kaspersky Security. Pozwala to na nieprzechowywanie bazy danych antywirusowych na każdej VM, co zmniejsza zajmowaną przestrzeń dyskową. Usługa jest zintegrowana z infrastrukturą chmury i działa poprzez SVM, co zwiększa gęstość maszyn wirtualnych na hoście ESXi oraz wydajność całego systemu chmurowego. Lekki agent tworzy kolejkę zadań dla każdej maszyny wirtualnej: przetestować system plików, pamięć itd. Jednak za wykonanie tych operacji odpowiada już SVM, o którym porozmawiamy dalej. Agent pełni również funkcje zapory sieciowej, kontroluje polityki bezpieczeństwa, wysyła zainfekowane pliki do kwarantanny oraz monitoruje ogólne „zdrowie” systemu operacyjnego, na którym jest zainstalowany. Wszystkim tym można zarządzać za pomocą już wspomnianej jednej konsoli.
• Maszyna wirtualna Security. Wszystkie zasoby wymagające intensywnego przetwarzania (aktualizacje baz antywirusowych, zaplanowane kontrole) obsługuje dedykowana maszyna wirtualna Security (SVM). Odpowiada ona za działanie pełnoprawnego silnika antywirusowego oraz jego baz. Infrastruktura IT firmy może obejmować kilka SVM. Takie podejście zwiększa niezawodność systemu — jeśli jakaś maszyna przestaje działać i nie odpowiada przez trzydzieści sekund, agenci automatycznie zaczynają szukać innej.
• Serwer integracji KSC. Jeden z komponentów głównego KSC, który przydziela według algorytmu określonego w jego ustawieniach, lekkim agentom ich SVM oraz kontroluje dostępność SVM. W ten sposób ten moduł programowy zapewnia równoważenie obciążenia w całej chmurze infrastruktury SVM.
Algorytm działania w chmurze: zmniejszenie obciążenia infrastruktury
Ogólnie algorytm działania antywirusa można przedstawić w następujący sposób. Agent zwraca się do pliku na maszynie wirtualnej i go sprawdza. Wynik weryfikacji jest zapisywany w ogólnej, zcentralizowanej bazie orzeczeń SVM (nazywanej Shared Cache), a każdy wpis identyfikuje unikalny wzór pliku. Takie podejście pozwala na śledzenie, aby ten sam plik nie był sprawdzany wielokrotnie (np. jeśli został otwarty na różnych maszynach wirtualnych). Plik skanowany jest ponownie tylko w przypadku, gdy wprowadzono w nim zmiany lub gdy kontrola została uruchomiona ręcznie.
Wdrażanie rozwiązania antywirusowego w chmurze dostawcy
Na obrazku przedstawiono ogólny schemat wdrożenia rozwiązania w chmurze. W obszarze zarządzania chmurą uruchomiono główny Kaspersky Security Center, a na każdym hoście ESXi przy użyciu serwera integracji KSC zainstalowano indywidualną SVM (do każdego hosta ESXi specjalnymi ustawieniami na VMware vCenter Server przypisana jest własna SVM). Klienci pracują w swoich segmentach chmury, gdzie umieszczane są maszyny wirtualne z agentami. Zarządzane są one przez indywidualne serwery KSC, które podlegają głównemu KSC. W razie potrzeby ochrony niewielkiej liczby maszyn wirtualnych (do 5) klient może uzyskać dostęp do wirtualnej konsoli specjalnego wydzielonego serwera KSC. Interakcja sieciowa między klientami KSC a głównym KSC, a także lekkimi agentami i SVM odbywa się za pomocą NAT przez wirtualne routery klientów EdgeGW.
Według naszych ocen i wyników testów kolegów z dostawcy, Lekki agent zmniejsza obciążenie wirtualnej infrastruktury klientów o około 25% (w porównaniu z systemem używającym tradycyjnego oprogramowania antywirusowego). W szczególności standardowy program antywirusowy Kaspersky Endpoint Security (KES) dla środowisk fizycznych wykorzystuje prawie dwa razy więcej czasu procesora serwera (2,95%) niż rozwiązanie do wirtualizacji oparte na lekkich agentach (1,67%).
Wykres porównawczy obciążenia procesora
Podobna sytuacja ma miejsce w przypadku częstotliwości dostępu do dysku podczas zapisu: dla tradycyjnego programu antywirusowego wynosi ona 1011 IOPS, dla chmurowego programu antywirusowego — 671 IOPS.
Wykres porównawczy częstotliwości dostępu do dysku
Zyska na wydajności pozwala na utrzymanie stabilności infrastruktury i efektywniejsze wykorzystanie mocy obliczeniowej. Dostosowanie do pracy w publicznym środowisku chmurowym nie obniża wydajności chmury: realizuje centralizowane skanowanie plików i pobieranie aktualizacji, rozkładając obciążenie. Oznacza to, że z jednej strony nie zostaną pominięte aktualne zagrożenia dla infrastruktury chmurowej, a z drugiej strony średnio o 25% zmniejszą się wymagania dotyczące zasobów maszyn wirtualnych w porównaniu do tradycyjnego oprogramowania antywirusowego.
Pod względem funkcjonalności oba rozwiązania są do siebie bardzo podobne: poniżej znajduje się tabela porównawcza. Jednak w chmurze, jak pokazują powyższe wyniki testów, lepiej jest używać rozwiązania dla środowisk wirtualnych.
O taryfach w ramach nowego podejścia. Zdecydowaliśmy się na model, który pozwala na uzyskanie licencji w zależności od liczby vCPU. Oznacza to, że liczba licencji będzie równa liczbie vCPU. Antywirus można przetestować, składając wniosek .
W następnej części materiału dotyczącego chmury opowiemy o ewolucji chmurowych WAF i tym, co lepiej wybrać: sprzęt, oprogramowanie czy chmurę.
Tekst przygotowali pracownicy dostawcy usług chmurowych #CloudMTS: Denis Mjagkow, główny architekt oraz Aleksiej Afanasew, menedżer ds. rozwoju produktów IB.
Źródło: habr.com
