Все повече потребители прехвърлят цялата си ИТ инфраструктура в публичното облако. Въпреки това, при недостатъчно антивирусно покритие в инфраструктурата на клиента, възникват сериозни киберрискове. Практиката показва, че до 80% от съществуващите вируси отлично живеят в виртуална среда. В този пост ще разгледаме как да защитим ИТ ресурсите в публичното облако и защо традиционните антивируси не са съвсем подходящи за тези цели.
Първо, ще разкажем как достигнахме до извода, че обичайните инструменти за антивирусна защита не са подходящи за публичното облако и какви различни подходи са необходими за защита на ресурсите.
На първо място, доставчиците обикновено осигуряват необходимите мерки, за да гарантират високопрофилна защита на своите облачни платформи. Например, ние в #CloudMTS анализираме целия мрежови трафик, следим логовете на системите за сигурност на нашето облако и редовно извършваме тестове за проникване. Сегментите на облака, предоставени на отделни клиенти, също трябва да бъдат надеждно защитени.
На второ място, класическият вариант за справяне с киберрисковете включва инсталирането на антивирус и средства за управление на всяка виртуална машина. Въпреки това, при голям брой виртуални машини, такава практика може да се окаже неефективна и да изисква значителни компютърни ресурси, което допълнително натоварва инфраструктурата на клиента и намалява цялостната производителност на облака. Това стана ключов фактор за търсенето на нови подходи за изграждане на ефективна антивирусна защита на виртуалните машини на клиентите.
Освен това, повечето налични на пазара антивирусни решения не са адаптирани за защита на ИТ ресурсите в публична облачна среда. Обикновено те представляват тежки EPP решения ( платформи за защита на крайни точки), които също така не предлагат необходимата персонализация от страна на клиентите на облачния доставчик.
Става очевидно, че традиционните антивирусни решения не са добре пригодени да работят в облака, тъй като значително натоварват виртуалната инфраструктура по време на актуализации и сканирания, както и не притежават необходимите нива на ролево управление и настройки. По-долу подробно ще разгледаме причините, поради които облакът се нуждае от нови подходи за антивирусна защита.
Какво трябва да може антивирусът в публичното облако
Нека обърнем внимание на спецификата на работата във виртуална среда:
Ефективността на провеждането на актуализации и масови проверки по график. Ако значително количество виртуални машини, използващи традиционен антивирус, едновременно инициират актуализация, в облака ще се получи т. нар. "порой" от актуализации. Мощностите на ESXi хоста, на който са разположени няколко виртуални машини, може да не са достатъчни за обработка на вълната от однотипни задачи, стартирани по подразбиране. От гледна точка на облачния доставчик, такъв проблем може да доведе до допълнителни натоварвания на редица ESXi хостове, което в крайна сметка ще доведе до спад в производителността на виртуалната инфраструктура на облака. Това може да се отрази и на производителността на виртуалните машини на други клиенти на облака. Подобна ситуация може да възникне и при стартиране на масово сканиране: едновременното обработване на множество однотипни заявки от различни потребители от дисковата система ще окаже негативно влияние върху производителността на целия облак. С голяма степен на вероятност намаляването на работоспособността на СХД ще се отрази на всички клиенти. Такива скокове в натоварванията не радват нито доставчика, нито неговите клиенти, тъй като влияят на
Безопасна карантинa. Ако в системата бъде открит файл или документ, потенциално заразен с вирус, той се изпраща в карантина. Разбира се, заразеният файл може да бъде изтрит веднага, но това често не е приемливо за повечето компании. Корпоративните enterprise антивируси, които не са адаптирани за работа в облака на доставчика, обикновено имат обща карантинна зона — в нея попълват всички заразени обекти. Например, откритите на компютрите на потребителите на компанията. Клиентите на облачния доставчик „живеят“ в собствени сегменти (или тенанти). Тези сегменти са непрозрачни и изолирани: клиентите не знаят един за друг и, разбира се, не виждат какво поставят в облака другите. Очевидно е, че в обща карантина, до която ще имат достъп всички потребители на антивируса в облака, потенциално може да попадне документ, съдържащ конфиденциална информация или търговска тайна. Това е неприемливо за доставчика и неговите клиенти. Затова решението може да бъде само едно – лична карантина за всеки клиент в неговия сегмент, до която нямат достъп нито доставчикът, нито други клиенти.
Индивидуални политики за сигурност. Всеки клиент в облака е отделна компания, ИТ-отделът на която установява свои политики за сигурност. Например, администраторите определят правилата за сканиране и разписанието на антивирусните проверки. Съответно, всяка организация трябва да има свой център за управление за настройка на политиките на антивируса. При това зададените настройки не трябва да влияят на другите клиенти в облака, а доставчикът трябва да има възможност да се увери, че, например, обновленията на антивируса преминават в нормален режим за всички виртуални машини на клиента.
Организация на фактуриране и лицензиране. Облачният модел характеризира с гъвкавост и предполага заплащане само за обема на ИТ-ресурсите, които е използвал клиентът. Ако е необходимо, например, заради сезонност, обемът на ресурсите може бързо да се увеличава или намалява — всичко в зависимост от текущите нужди от изчислителни мощности. Традиционният антивирус не е толкова гъвкав — обикновено клиентът закупува лиценз за година за предварително определено количество. сървъри или работни станции. Потребителите на облака редовно изключват и включват допълнителни виртуални машини в зависимост от текущите си нужди — съответно антивирусните лицензи трябва да поддържат същия модел.
Вторият въпрос е какво точно ще обхваща лицензът. Традиционният антивирус се лицензира по брой сървъри или работни станции. Лицензирането по брой защитени виртуални машини не е напълно подходящо в рамките на облачния модел. Клиентът може да създаде всякакъв брой виртуални машини от наличните ресурси, например, пет или десет машини. Тази цифра не е постоянна за повечето клиенти, затова проследяването на промените за нас, като доставчик, не е възможно. Лицензирането по CPU няма техническа основа: клиентите получават виртуални процесори (vCPU), по които и трябва да се извършва лицензирането. Така, новият модел на антивирусна защита трябва да предвижда възможност за клиента да определи необходимия брой vCPU, за които ще получава антивирусни лицензи.
Спазване на законодателството. Важен аспект, тъй като прилаганите решения трябва да гарантират изпълнението на изискванията на регулатора. Например, често «жителите» на облака работят с лични данни. В такъв случай, доставчикът трябва да разполага с отделен сертифициран сегмент на облака, който напълно отговаря на изискванията на Закона за личните данни. Тогава на компаниите не им се налага сами да «строят» цялата система за работа с лични данни: да закупуват сертифицирано оборудване, да го свързват и настроят, да преминават атестация. За киберзащитата на ИСПДн на такива клиенти антивирусът също трябва да отговаря на изискванията на руското законодателство и да има сертификат от ФСТЕК.
Разгледахме задължителните критерии, на които антивирусната защита в публичния облак трябва да отговаря. По-късно ще споделим собствения си опит по адаптиране на антивирусно решение за работа в облака на доставчика.
Как може да се съчетаят антивирус и облак
Как показва нашият опит, изборът на решение въз основа на описание и документация е едно, а реализация в работеща облачна среда е съвсем различна задача по отношение на сложността. Ще споделим какво направихме на практика и как адаптирахме антивируса за работа в публично облако на доставчика. Вендор на антивирусното решение стана Kaspersky, който предлага решения за антивирусна защита в облачни среди. Застанахме на "Kaspersky Security за виртуални среди" (Лек агент).
Това включва единна конзола Kaspersky Security Center. Лек агент и виртуални машини за сигурност (SVM, Security Virtual Machine) и сървър за интеграция KSC.
След като изучихме архитектурата на решението Kaspersky и проведохме първоначални тестове съвместно с инженери от вендора, възникна въпросът за интеграцията на услугата в облака. Първото внедряване беше извършено съвместно на московската облачна площадка. И ето какво разбрахме.
За да минимализираме мрежовия трафик, беше взето решение на всеки ESXi хост да се разположи SVM и да се "привърже" SVM към ESXi хостовете. В този случай леките агенти на защитените виртуални машини се свързват към SVM точно на този ESXi хост, на който са стартирани. За главния KSC беше избран отделен административен тенант. В резултат на това подчинените KSC се разполагат в тенантите на всеки отделен клиент и се свързват с надвисналия KSC, разположен в сегмента за управление. Тази схема позволява бързо разрешаване на проблеми, възникващи в тенантите на клиентите.
Освен въпросите с внедряването на компонентите на самото антивирусно решение, пред нас стоеше задачата за организиране на мрежово взаимодействие чрез създаване на допълнителни VxLAN. И макар решението първоначално да е предназначено за предприятия с частни облаци — с помощта на инженерна находчивост и технологична гъвкавост NSX Edge, успяхме да разрешим всички задачи, свързани с разделянето на тенантите и лицензиране.
Работихме в тясно сътрудничество с инженерите на Kaspersky. При анализа на архитектурата на решението, касаеща мрежовото взаимодействие между компонентите на системата, беше установено, че освен достъпа от леки агенти до SVM, е необходима и обратна връзка – от SVM към леките агенти. Тази мрежова свързаност е невъзможна в среда с множество наематели поради възможността за съществуване на идентични мрежови настройки на виртуални машини в различни тенанти на облака. Затова по наша молба колегите от доставчика преработиха механизма на мрежовото взаимодействие между лекия агент и SVM, за да изключат необходимостта от мрежова свързаност от SVM към леките агенти.
След като решението беше разположено и тествано на московската платформа на облака, ние го разпространихме на останалите платформи, включително на сертифицирания сегмент на облака. В момента услугата е налична във всички региони на страната.
Архитектура на решение за информационна безопасност в рамките на новия подход
Общата схема на работа на антивирусното решение в публичната облачна среда изглежда по следния начин:
Схема на работа на антивирусното решение в публичната облачна среда #CloudMTS
Опишем особеностите на работата на отделните елементи на решението в облака:
• Единна конзола, която позволява на клиентите централизирано да управляват системата за защита: да стартират проверки, да контролират актуализациите и да наблюдават карантинните зони. Има възможност за настройване на индивидуални политики за сигурност в рамките на своя сегмент.
Важно да се отбележи, че въпреки че сме доставчик на услугата, не се намесваме в настройките, определени от клиентите. Единственото, което можем да направим, е да възстановим стандартните политики за сигурност в случай на необходимост от повторно конфигуриране. Например, това може да се наложи, ако клиентът случайно е затегнал или значително е отслабил тяхната сигурност. Компанията винаги може да получи контролен център с подразбиращи се политики, които след това може сама да настрои. Недостатъкът на Kaspersky Security Center е, че в момента платформата е налична само за операционната система Microsoft. Въпреки това, леките агенти могат да работят както с Windows, така и с Linux машини. Обаче, в „Лабораторията Касперски“ обещават, че скоро KSC ще заработи и под ОС Linux. Една от важните функции на KSC е управлението на карантината. Всеки клиент в нашето облако има своя собствена карантина. Този подход предотвратява ситуация, в която заразен документ случайно попада в общото пространство, както би се случило с класически корпоративен антивирус с обща карантина.
• Леки агенти. В новия модел, на всяка виртуална машина се инсталира лек агент Kaspersky Security. Това позволява да не се съхранява антивирусна база данни на всяка VM, което намалява заетото дисково пространство. Услугата е интегрирана с облачната инфраструктура и функционира чрез SVM, което увеличава плътността на виртуалните машини на ESXi хоста и производителността на цялата облачна система. Леките агенти организират опашка от задания за всяка виртуална машина: да проверят файловата система, паметта и т.н. Но за изпълнението на тези операции отговаря вече SVM, за която ще говорим по-късно. Освен това, агентът изпълнява функции на защитна стена, контролира политиките за сигурност, изпраща заразени файлове в карантина и следи общото „здраве“ на операционната система, на която е инсталиран. Всичко това може да се управлява чрез вече споменатата единна конзола.
• Сигурна виртуална машина. Всички ресурсоемки задачи (обновления на антивирусните бази, проверки по график) се извършват от отделна сигурна виртуална машина (SVM). Тя отговаря за функционирането на пълноценен антивирусен двигател и свързаните с него бази. ИТ инфраструктурата на компанията може да включва няколко SVM. Тази стратегия увеличава надеждността на системата - ако някоя машина се повреди и не отговаря в продължение на тридесет секунди, агентите автоматично започват да търсят друга.
• Сервер за интеграция KSC. Един от компонентите на основния KSC, който назначава на леките агенти своите SVM в съответствие с алгоритъма зададен в настройките му, както и контролира наличността на SVM. По този начин този софтуерен модул осигурява баланс на натоварването на всички SVM в облачната инфраструктура.
Алгоритъм на работа в облака: намаляване на натоварването на инфраструктурата
В общи линии алгоритъмът на работа на антивируса може да бъде представен по следния начин. Агентът се свързва с файл на виртуалната машина и го проверява. Резултатът от проверката се запазва в обща централизирана база от решения SVM (наречена Споделена кеш памет), всяка запис идентифицира уникален образец на файла. Тази стратегия позволява да се следи, за да не се проверява един и същ файл многократно (например, ако е бил отворен на различни виртуални машини). Файлът се сканира отново само ако е направена промяна или проверката е стартирана ръчно.
Реализация на антивирусно решение в облака на доставчика
На изображението е представена общата схема за реализиране на решението в облака. В управляващата зона на облака е разположен главният Kaspersky Security Center, а на всеки ESXi хост е разгръната индивидуална SVM чрез инвестиционния сървър KSC (към всеки ESXi хост са свързани специални настройки на VMware vCenter Server). Клиентите работят в своите сегменти на облака, където се разполагат виртуални машини с агенти. Те се управляват чрез индивидуални KSC сървъри, подчинени на главния KSC. При необходимост от защита на малък брой виртуални машини (до 5), на клиента може да бъде предоставен достъп до виртуална конзола на специално отделен сървър KSC. Мрежовото взаимодействие между клиентските KSC и главния KSC, а също така между леките агенти и SVM се осъществява с помощта на NAT през клиентските виртуални рутери EdgeGW.
Според нашите оценки и резултатите от тестовете на колеги от доставчика, Лекият агент намалява натоварването на виртуалната инфраструктура на клиентите с около 25% (в сравнение с система, използваща традиционен антивирус). В частност, стандартният антивирус Kaspersky Endpoint Security (KES) за физически среди изразходва почти два пъти повече процесорно време на сървъра (2,95%), отколкото решението за виртуализация, базирано на леки агенти (1,67%).
Графика за сравнение на натоварването на процесора
Подобна ситуация се наблюдава и с честотата на обращенията към диска по запис: за класическия антивирус тя е 1011 IOPS, а за облачния антивирус — 671 IOPS.
Графика за сравнение на честотата на обращенията към диска
Печалбата по производителността позволява поддържането на стабилността на инфраструктурата и по-ефективното използване на изчислителната мощ. Чрез адаптацията за работа в публична облачна среда, решението не намалява производителността на облака: извършва централизирана проверка на файловете и зареждане на актуализации, разпределяйки натоварването. Това означава, че, от една страна, няма да бъдат пропуснати актуалните заплахи за облачната инфраструктура, а от друга страна, в средно на 25% ще се намалят изискванията към ресурсите на виртуалните машини в сравнение с традиционния антивирус.
По функционалност и двете решения силно си напомнят едно на друго: по-долу е представена сравнителна таблица. Въпреки това, в облака, както показват посочените по-горе резултати от тестовете, все пак е оптимално да се използва решение за виртуални среди.
За тарификация в рамките на новия подход. Ние взехме решение да използваме модел, който позволява получаване на лицензи на база броя vCPU. Това означава, че броят на лицензите ще е равен на броя vCPU. Антивирусът може да се тества, като се подаде заявка. .
В следващия материал по облачната тематика ще разкажем за еволюцията на облачните WAF и какво е най-добре да изберете: хардуер, софтуер или облак.
Текстът е подготвен от служители на облачния доставчик #CloudMTS: Денис Мягков, водещ архитект и Алексей Афанасьев, мениджър по развитие на продукти в областта на информационната безопасност.
Източник: habr.com
