Coraz więcej użytkowników przenosi całą swoją infrastrukturę IT do chmury publicznej. Jeśli jednak kontrola antywirusowa w infrastrukturze klienta jest niewystarczająca, powstają poważne zagrożenia cybernetyczne. Praktyka pokazuje, że aż 80% istniejących wirusów doskonale żyje w środowisku wirtualnym. W tym poście porozmawiamy o tym, jak chronić zasoby IT w chmurze publicznej i dlaczego tradycyjne antywirusy nie do końca nadają się do tych celów.
Na początek opowiemy, jak doszliśmy do wniosku, że zwykłe narzędzia ochrony antywirusowej nie nadają się do chmury publicznej i że potrzebne są inne podejścia do ochrony zasobów.
Po pierwsze, dostawcy na ogół zapewniają niezbędne środki, aby zapewnić 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 i regularnie przeprowadzamy pentesty. Segmenty chmury przydzielane poszczególnym klientom również muszą być bezpiecznie chronione.
Po drugie, klasyczna opcja zwalczania zagrożeń cybernetycznych polega na zainstalowaniu na każdej maszynie wirtualnej programu antywirusowego i narzędzi do zarządzania antywirusem. Jednak przy dużej liczbie maszyn wirtualnych praktyka ta może być nieskuteczna i wymagać znacznych ilości zasobów obliczeniowych, tym samym dodatkowo obciążając infrastrukturę klienta i zmniejszając ogólną wydajność chmury. Stało się to kluczowym warunkiem poszukiwania nowych podejść do budowania skutecznej ochrony antywirusowej dla maszyn wirtualnych klientów.
Ponadto większość rozwiązań antywirusowych dostępnych na rynku nie jest przystosowana do rozwiązywania problemów związanych z ochroną zasobów IT w środowisku chmury publicznej. Z reguły są to rozwiązania EPP (Endpoint Protection Platforms) o dużej wadze, które ponadto nie zapewniają niezbędnej personalizacji po stronie klienta dostawcy chmury.
Staje się oczywiste, że tradycyjne rozwiązania antywirusowe nie nadają się do pracy w chmurze, ponieważ poważnie obciążają infrastrukturę wirtualną podczas aktualizacji i skanowania, a także nie mają niezbędnego poziomu zarządzania i ustawień opartych na rolach. Następnie szczegółowo przeanalizujemy, dlaczego chmura potrzebuje nowego podejścia do ochrony antywirusowej.
Co powinien potrafić antywirus w chmurze publicznej
Zwróćmy zatem uwagę na specyfikę pracy w środowisku wirtualnym:
Wydajność aktualizacji i zaplanowanych masowych skanów. Jeżeli znaczna liczba maszyn wirtualnych korzystających z tradycyjnego antywirusa zainicjuje aktualizację w tym samym czasie, w chmurze nastąpi tzw. „burza” aktualizacji. Moc hosta ESXi, na którym znajduje się kilka maszyn wirtualnych, może nie wystarczyć do obsługi natłoku podobnych zadań uruchomionych domyślnie. Z punktu widzenia dostawcy chmury taki problem może skutkować dodatkowym obciążeniem wielu hostów ESXi, co ostatecznie doprowadzi do spadku wydajności wirtualnej infrastruktury chmury. Może to między innymi mieć wpływ na wydajność maszyn wirtualnych innych klientów chmury. Podobna sytuacja może wystąpić przy uruchomieniu masowego skanowania: jednoczesne przetwarzanie przez system dyskowy wielu podobnych żądań od różnych użytkowników negatywnie wpłynie na wydajność całej chmury. Z dużym prawdopodobieństwem spadek wydajności systemu pamięci masowej dotknie wszystkich klientów. Takie nagłe obciążenia nie podobają się ani dostawcy, ani jego klientom, ponieważ wpływają na „sąsiadów” w chmurze. Z tego punktu widzenia tradycyjny antywirus może stanowić duży problem.
Bezpieczna kwarantanna. Jeśli w systemie zostanie wykryty plik lub dokument potencjalnie zainfekowany wirusem, jest on przesyłany do kwarantanny. Oczywiście zainfekowany plik można natychmiast usunąć, jednak w większości firm jest to często nie do przyjęcia. Korporacyjne programy antywirusowe dla przedsiębiorstw, które nie są przystosowane do pracy w chmurze dostawcy, z reguły mają wspólną strefę kwarantanny - do niej wpadają wszystkie zainfekowane obiekty. Na przykład te znalezione na komputerach użytkowników firmowych. Klienci dostawcy chmury „żyją” we własnych segmentach (lub najemcach). Segmenty te są nieprzejrzyste i izolowane: klienci nie wiedzą o sobie nawzajem i oczywiście nie widzą, co inni hostują w chmurze. Oczywiście ogólna kwarantanna, do której dostęp będą mieli wszyscy użytkownicy antywirusa w chmurze, potencjalnie może obejmować dokument zawierający poufne informacje lub tajemnicę handlową. Jest to niedopuszczalne dla dostawcy i jego klientów. Dlatego rozwiązanie może być tylko jedno – osobista kwarantanna dla każdego klienta w jego segmencie, do której ani dostawca, ani inni klienci nie mają dostępu.
Indywidualne polityki bezpieczeństwa. Każdy klient w chmurze to osobna firma, której dział IT ustala własną politykę bezpieczeństwa. Na przykład administratorzy definiują reguły skanowania i planują skanowanie antywirusowe. W związku z tym każda organizacja musi mieć własne centrum kontroli, aby konfigurować zasady antywirusowe. Jednocześnie określone ustawienia nie powinny mieć wpływu na innych klientów chmury, a dostawca powinien mieć możliwość sprawdzenia, czy np. aktualizacje oprogramowania antywirusowego są przeprowadzane normalnie dla wszystkich klienckich maszyn wirtualnych.
Organizacja rozliczeń i licencjonowania. Model chmurowy charakteryzuje się elastycznością i polega na płaceniu wyłącznie za ilość zasobów IT, z których korzystał klient. Jeśli zajdzie taka potrzeba np. ze względu na sezonowość, wówczas ilość zasobów można szybko zwiększyć lub zmniejszyć – wszystko w oparciu o aktualne zapotrzebowanie na moc obliczeniową. Tradycyjny program antywirusowy nie jest tak elastyczny – z reguły klient kupuje licencję na rok na określoną liczbę serwerów lub stacji roboczych. Użytkownicy chmury regularnie odłączają i podłączają dodatkowe maszyny wirtualne w zależności od swoich bieżących potrzeb – w związku z tym licencje antywirusowe muszą obsługiwać ten sam model.
Drugie pytanie dotyczy tego, co dokładnie będzie obejmować licencja. Tradycyjny program antywirusowy jest licencjonowany na podstawie liczby serwerów lub stacji roboczych. Licencje oparte na liczbie chronionych maszyn wirtualnych nie do końca sprawdzają się w modelu chmurowym. Klient może z dostępnych zasobów stworzyć dowolną dogodną dla siebie liczbę maszyn wirtualnych, na przykład pięć lub dziesięć maszyn. Dla większości klientów liczba ta nie jest stała, my jako dostawca nie mamy możliwości śledzenia jej zmian. Nie ma technicznej możliwości licencjonowania według procesora: klienci otrzymują procesory wirtualne (vCPU), które należy wykorzystać do licencjonowania. Tym samym nowy model ochrony antywirusowej powinien obejmować możliwość określenia przez klienta wymaganej liczby procesorów wirtualnych, na które otrzyma licencje antywirusowe.
Zgodność z przepisami. Ważna kwestia, gdyż zastosowane rozwiązania muszą zapewniać zgodność z wymaganiami regulatora. Na przykład „mieszkańcy” chmury często pracują z danymi osobowymi. W takim przypadku dostawca musi posiadać wydzielony, certyfikowany segment chmury, w pełni zgodny z wymogami ustawy o danych osobowych. Wtedy firmy nie muszą samodzielnie „budować” całego systemu do pracy z danymi osobowymi: kupować certyfikowany sprzęt, podłączać go i konfigurować oraz przechodzić certyfikację. Aby zapewnić cyberochronę ISPD takich klientów, program antywirusowy musi również spełniać wymagania rosyjskiego ustawodawstwa i posiadać certyfikat FSTEC.
Przyjrzeliśmy się obowiązkowym kryteriom, jakie musi spełniać ochrona antywirusowa w chmurze publicznej. Następnie podzielimy się własnymi doświadczeniami w dostosowywaniu rozwiązania antywirusowego do pracy w chmurze dostawcy.
Jak połączyć program antywirusowy z chmurą?
Jak pokazało nasze doświadczenie, wybór rozwiązania na podstawie opisu i dokumentacji to jedno, ale wdrożenie go w praktyce w już działającym środowisku chmurowym to zupełnie inne zadanie pod względem złożoności. Opowiemy Ci, co zrobiliśmy w praktyce i jak dostosowaliśmy program antywirusowy do pracy w chmurze publicznej dostawcy. Dostawcą rozwiązania antywirusowego była firma Kaspersky, której portfolio obejmuje rozwiązania ochrony antywirusowej dla środowisk chmurowych. Zdecydowaliśmy się na „Kaspersky Security for Virtualization” (Light Agent).
Zawiera pojedynczą konsolę Kaspersky Security Center. Lekkie maszyny wirtualne agentów i zabezpieczeń (SVM, Security Virtual Machine) oraz serwer integracyjny KSC.
Po przestudiowaniu architektury rozwiązania Kaspersky i przeprowadzeniu pierwszych testów wspólnie z inżynierami dostawcy pojawiło się pytanie o integrację usługi z chmurą. Pierwsze wdrożenie zostało przeprowadzone wspólnie w moskiewskiej lokalizacji chmurowej. I właśnie to sobie uświadomiliśmy.
Aby zminimalizować ruch sieciowy, zdecydowano się umieścić maszynę SVM na każdym hoście ESXi i „powiązać” maszynę SVM z hostami ESXi. W takim przypadku lekkie agenty chronionych maszyn wirtualnych uzyskują dostęp do SVM dokładnie tego hosta ESXi, na którym działają. Dla głównego KSC wybrano osobnego najemcę administracyjnego. W efekcie podrzędne KSC zlokalizowane są u najemców każdego indywidualnego klienta i adresowane są do nadrzędnego KSC zlokalizowanego w segmencie zarządczym. Ten schemat pozwala szybko rozwiązać problemy pojawiające się u najemców klientów.
Oprócz problemów z montażem komponentów samego rozwiązania antywirusowego, stanęliśmy przed zadaniem zorganizowania interakcji sieciowej poprzez utworzenie dodatkowych sieci VxLAN. I chociaż rozwiązanie było pierwotnie przeznaczone dla klientów korporacyjnych posiadających chmury prywatne, dzięki sprytowi inżynieryjnemu i elastyczności technologicznej NSX Edge byliśmy w stanie rozwiązać wszystkie problemy związane z separacją najemców i licencjonowaniem.
Ściśle współpracowaliśmy z inżynierami z Kaspersky. Tym samym w procesie analizy architektury rozwiązania pod kątem interakcji sieciowej pomiędzy komponentami systemu stwierdzono, że oprócz dostępu od agentów light do SVM niezbędna jest także informacja zwrotna – od SVM do agentów light. Taka łączność sieciowa nie jest możliwa w środowisku wielodostępnym ze względu na możliwość identycznych ustawień sieciowych maszyn wirtualnych w różnych dzierżawcach chmury. Dlatego na naszą prośbę koledzy ze strony dostawcy przerobili mechanizm interakcji sieciowej pomiędzy lekkim agentem a SVM pod kątem wyeliminowania konieczności zapewnienia łączności sieciowej pomiędzy SVM a lekkimi agentami.
Po wdrożeniu i przetestowaniu rozwiązania w moskiewskiej lokalizacji chmurowej zreplikowaliśmy je w innych lokalizacjach, w tym w certyfikowanym segmencie chmur. Usługa jest już dostępna we wszystkich regionach kraju.
Architektura rozwiązania bezpieczeństwa informacji w ramach nowego podejścia
Ogólny schemat działania rozwiązania antywirusowego w środowisku chmury publicznej wygląda następująco:
Schemat działania rozwiązania antywirusowego w środowisku chmury publicznej #CloudMTS
Opiszmy cechy działania poszczególnych elementów rozwiązania w chmurze:
• Pojedyncza konsola umożliwiająca klientom centralne zarządzanie systemem ochrony: uruchamianie skanowania, kontrolowanie aktualizacji i monitorowanie stref kwarantanny. Istnieje możliwość skonfigurowania indywidualnych polityk bezpieczeństwa w ramach Twojego segmentu.
Należy zaznaczyć, że choć jesteśmy usługodawcą, to nie ingerujemy w ustawienia dokonywane przez Klientów. Jedyne, co możemy zrobić, to zresetować zasady bezpieczeństwa do standardowych, jeśli konieczna będzie rekonfiguracja. Może to być np. konieczne, jeśli klientka przypadkowo je dokręciła lub znacząco osłabiła. Firma zawsze może otrzymać centrum kontroli z domyślnymi politykami, które może następnie samodzielnie skonfigurować. Wadą Kaspersky Security Center jest to, że platforma jest obecnie dostępna tylko dla systemu operacyjnego Microsoft. Chociaż lekcy agenci mogą współpracować zarówno z maszynami z systemem Windows, jak i Linux. Kaspersky Lab obiecuje jednak, że w najbliższej przyszłości KSC będzie działać pod systemem operacyjnym Linux. Jedną z ważnych funkcji KSC jest możliwość zarządzania kwarantanną. Każda firma klienta w naszej chmurze ma swoją osobistą. Takie podejście eliminuje sytuacje, w których dokument zainfekowany wirusem przypadkowo staje się publicznie widoczny, co mogłoby się zdarzyć w przypadku klasycznego korporacyjnego programu antywirusowego z ogólną kwarantanną.
• Lekkie środki. W ramach nowego modelu na każdej maszynie wirtualnej instalowany jest lekki agent Kaspersky Security. Eliminuje to potrzebę przechowywania antywirusowej bazy danych na każdej maszynie wirtualnej, co zmniejsza ilość wymaganego miejsca na dysku. Usługa jest zintegrowana z infrastrukturą chmurową i działa poprzez SVM, co zwiększa gęstość maszyn wirtualnych na hoście ESXi i wydajność całego systemu chmurowego. Lekki agent buduje kolejkę zadań dla każdej maszyny wirtualnej: sprawdź system plików, pamięć itp. Ale za wykonanie tych operacji odpowiada SVM, o czym porozmawiamy później. Agent działa również jako zapora sieciowa, kontroluje polityki bezpieczeństwa, wysyła zainfekowane pliki do kwarantanny i monitoruje ogólną „kondycję” systemu operacyjnego, na którym jest zainstalowany. Wszystkim tym można zarządzać za pomocą wspomnianej już pojedynczej konsoli.
• Wirtualna maszyna bezpieczeństwa. Wszystkie zadania wymagające dużych zasobów (aktualizacje antywirusowych baz danych, zaplanowane skanowania) są obsługiwane przez oddzielną wirtualną maszynę bezpieczeństwa (SVM). Odpowiada za działanie pełnoprawnego silnika antywirusowego i baz danych dla niego. Infrastruktura informatyczna firmy może obejmować kilka maszyn SVM. Takie podejście zwiększa niezawodność systemu – jeśli jedna maszyna ulegnie awarii i nie odpowie przez trzydzieści sekund, agenci automatycznie rozpoczynają poszukiwania kolejnej.
• Serwer integracyjny KSC. Jeden z komponentów głównego KSC, który przydziela swoje SVM lekkim agentom zgodnie z algorytmem określonym w jego ustawieniach, a także kontroluje dostępność SVM. Dlatego ten moduł oprogramowania zapewnia równoważenie obciążenia na wszystkich maszynach SVM infrastruktury chmury.
Algorytm pracy w chmurze: zmniejszenie obciążenia infrastruktury
Ogólnie algorytm antywirusowy można przedstawić w następujący sposób. Agent uzyskuje dostęp do pliku na maszynie wirtualnej i sprawdza go. Wynik weryfikacji jest przechowywany we wspólnej, scentralizowanej bazie danych werdyktów SVM (zwanej Shared Cache), a każdy wpis identyfikuje unikalną próbkę pliku. Takie podejście pozwala mieć pewność, że ten sam plik nie zostanie przeskanowany kilka razy z rzędu (na przykład, jeśli był otwierany na różnych maszynach wirtualnych). Plik zostanie ponownie przeskanowany tylko wtedy, gdy dokonano w nim zmian lub skanowanie zostało rozpoczęte ręcznie.
Wdrożenie rozwiązania antywirusowego w chmurze dostawcy
Na obrazku przedstawiono ogólny schemat wdrożenia rozwiązania w chmurze. Główne Kaspersky Security Center jest wdrażane w strefie kontroli chmury, a indywidualna maszyna SVM jest wdrażana na każdym hoście ESXi przy użyciu serwera integracyjnego KSC (każdy host ESXi ma dołączoną własną maszynę SVM ze specjalnymi ustawieniami na VMware vCenter Server). Klienci pracują we własnych segmentach chmurowych, w których zlokalizowane są maszyny wirtualne z agentami. Zarządzanie nimi odbywa się poprzez indywidualne serwery KSC podległe głównemu KSC. W przypadku konieczności ochrony niewielkiej liczby maszyn wirtualnych (do 5) klientowi można zapewnić dostęp do konsoli wirtualnej specjalnego dedykowanego serwera KSC. Interakcja sieciowa pomiędzy klienckimi KSC i głównym KSC, a także lekkimi agentami i maszynami SVM odbywa się przy użyciu NAT za pośrednictwem wirtualnych routerów klienta EdgeGW.
Według naszych szacunków i wyników testów współpracowników u dostawcy Light Agent zmniejsza obciążenie infrastruktury wirtualnej klientów o około 25% (w porównaniu z systemem korzystającym z tradycyjnego oprogramowania antywirusowego). W szczególności standardowy program antywirusowy Kaspersky Endpoint Security (KES) dla środowisk fizycznych zużywa prawie dwukrotnie więcej czasu procesora serwera (2,95%) niż lekkie rozwiązanie do wirtualizacji opartej na agentach (1,67%).
Tabela porównawcza obciążenia procesora
Podobną sytuację obserwuje się w przypadku częstotliwości zapisów na dysku: dla klasycznego antywirusa jest to 1011 IOPS, dla antywirusa chmurowego jest to 671 IOPS.
Wykres porównawczy szybkości dostępu do dysku
Zwiększona wydajność pozwala zachować stabilność infrastruktury i efektywniej wykorzystywać moc obliczeniową. Dostosowując się do pracy w środowisku chmury publicznej, rozwiązanie nie zmniejsza wydajności chmury: centralnie sprawdza pliki i pobiera aktualizacje, rozkładając obciążenie. Oznacza to, że z jednej strony nie zostaną przeoczone zagrożenia istotne dla infrastruktury chmurowej, z drugiej strony wymagania zasobów dla maszyn wirtualnych zostaną zmniejszone średnio o 25% w porównaniu z tradycyjnym antywirusem.
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, nadal optymalne jest wykorzystanie rozwiązania dla środowisk wirtualnych.
O taryfach w ramach nowego podejścia. Zdecydowaliśmy się zastosować model, który pozwala nam pozyskiwać licencje w oparciu o liczbę vCPU. Oznacza to, że liczba licencji będzie równa liczbie vCPU. Możesz przetestować swój program antywirusowy, zostawiając prośbę .
W kolejnym artykule poświęconym tematyce chmurowej porozmawiamy o ewolucji chmurowych WAF-ów i o tym, co lepiej wybrać: sprzęt, oprogramowanie czy chmurę.
Tekst przygotowali pracownicy dostawcy chmury #CloudMTS: Denis Myagkov, wiodący architekt i Alexey Afanasyev, menadżer ds. rozwoju produktów związanych z bezpieczeństwem informacji.
Źródło: www.habr.com