Защо традиционните антивируси не са подходящи за публични облаци. И така, какво трябва да направя?

Все повече потребители пренасят цялата си ИТ инфраструктура в публичния облак. Въпреки това, ако антивирусният контрол е недостатъчен в инфраструктурата на клиента, възникват сериозни кибер рискове. Практиката показва, че до 80% от съществуващите вируси живеят перфектно във виртуална среда. В тази публикация ще говорим за това как да защитим ИТ ресурсите в публичния облак и защо традиционните антивируси не са напълно подходящи за тези цели.

Като начало ще ви кажем как стигнахме до идеята, че обичайните инструменти за антивирусна защита не са подходящи за публичния облак и че са необходими други подходи за защита на ресурсите.

Първо, доставчиците обикновено предоставят необходимите мерки, за да гарантират, че техните облачни платформи са защитени на високо ниво. Например в #CloudMTS ние анализираме целия мрежов трафик, наблюдаваме регистрационни файлове на системите за сигурност на нашия облак и редовно извършваме пентестове. Облачните сегменти, разпределени на отделни клиенти, също трябва да бъдат сигурно защитени.

Второ, класическият вариант за борба с кибер рисковете включва инсталиране на антивирусна програма и инструменти за управление на антивирусна програма на всяка виртуална машина. Въпреки това, с голям брой виртуални машини, тази практика може да бъде неефективна и да изисква значителни количества изчислителни ресурси, като по този начин допълнително натоварва инфраструктурата на клиента и намалява цялостната производителност на облака. Това се превърна в ключова предпоставка за търсене на нови подходи за изграждане на ефективна антивирусна защита на клиентските виртуални машини.

Освен това повечето антивирусни решения на пазара не са адаптирани за решаване на проблемите със защитата на ИТ ресурсите в публична облачна среда. По правило те са тежки EPP решения (Endpoint Protection Platforms), които освен това не осигуряват необходимото персонализиране от страна на клиента на облачния доставчик.

Става очевидно, че традиционните антивирусни решения не са подходящи за работа в облака, тъй като те сериозно натоварват виртуалната инфраструктура по време на актуализации и сканиране, а също така нямат необходимите нива на управление и настройки, базирани на роли. След това ще анализираме подробно защо облакът се нуждае от нови подходи за антивирусна защита.

Какво трябва да може да прави една антивирусна програма в публичен облак

И така, нека обърнем внимание на спецификата на работа във виртуална среда:

Ефективност на актуализациите и планираните масови сканирания. Ако значителен брой виртуални машини, използващи традиционна антивирусна програма, инициират актуализация по едно и също време, в облака ще настъпи така наречената „буря“ от актуализации. Мощността на ESXi хост, който хоства няколко виртуални машини, може да не е достатъчна, за да се справи с множеството подобни задачи, изпълнявани по подразбиране. От гледна точка на облачния доставчик подобен проблем може да доведе до допълнителни натоварвания на редица ESXi хостове, което в крайна сметка ще доведе до спад в производителността на облачната виртуална инфраструктура. Това може, наред с други неща, да повлияе на производителността на виртуални машини на други облачни клиенти. Подобна ситуация може да възникне при стартиране на масово сканиране: едновременната обработка от дисковата система на много подобни заявки от различни потребители ще се отрази негативно на производителността на целия облак. С голяма степен на вероятност намаляването на производителността на системата за съхранение ще засегне всички клиенти. Такива резки натоварвания не харесват нито доставчика, нито неговите клиенти, тъй като засягат „съседите“ в облака. От тази гледна точка традиционната антивирусна програма може да представлява голям проблем.

Безопасна карантина. Ако в системата бъде открит файл или документ, потенциално заразен с вирус, той се изпраща в карантина. Разбира се, заразен файл може да бъде изтрит веднага, но това често не е приемливо за повечето компании. Корпоративните корпоративни антивируси, които не са адаптирани да работят в облака на доставчика, като правило имат обща карантинна зона - всички заразени обекти попадат в нея. Например тези, открити на компютрите на фирмени потребители. Клиентите на облачния доставчик „живеят“ в свои собствени сегменти (или наематели). Тези сегменти са непрозрачни и изолирани: клиентите не знаят един за друг и, разбира се, не виждат какво другите хостват в облака. Очевидно общата карантина, до която ще имат достъп всички антивирусни потребители в облака, може потенциално да включва документ, съдържащ поверителна информация или търговска тайна. Това е недопустимо за доставчика и неговите клиенти. Следователно решението може да бъде само едно - лична карантина за всеки клиент в неговия сегмент, където няма достъп нито доставчикът, нито други клиенти.

Индивидуални политики за сигурност. Всеки клиент в облака е отделна компания, чийто ИТ отдел определя свои собствени политики за сигурност. Например, администраторите определят правила за сканиране и планират антивирусни сканирания. Съответно всяка организация трябва да има собствен контролен център за конфигуриране на антивирусни политики. В същото време посочените настройки не трябва да засягат други облачни клиенти и доставчикът трябва да може да провери дали например антивирусните актуализации се извършват както обикновено за всички клиентски виртуални машини.

Организация на фактуриране и лицензиране. Облачният модел се характеризира с гъвкавост и включва плащане само за количеството ИТ ресурси, които са били използвани от клиента. Ако има нужда, например поради сезонност, тогава количеството ресурси може бързо да се увеличи или намали - всичко това въз основа на текущите нужди от изчислителна мощност. Традиционната антивирусна програма не е толкова гъвкава - по правило клиентът купува лиценз за една година за предварително определен брой сървъри или работни станции. Облачните потребители редовно прекъсват връзката и свързват допълнителни виртуални машини в зависимост от текущите си нужди - съответно антивирусните лицензи трябва да поддържат същия модел.

Вторият въпрос е какво точно ще покрива лицензът. Традиционната антивирусна програма се лицензира според броя на сървърите или работните станции. Лицензите, базирани на броя на защитените виртуални машини, не са напълно подходящи в облачния модел. Клиентът може да създаде произволен брой удобни за него виртуални машини от наличните ресурси, например пет или десет машини. Този номер не е постоянен за повечето клиенти и не е възможно ние, като доставчик, да проследим промените му. Няма техническа възможност за лицензиране по CPU: клиентите получават виртуални процесори (vCPU), които трябва да се използват за лицензиране. По този начин новият модел на антивирусна защита трябва да включва възможността клиентът да определя необходимия брой vCPU, за които ще получи антивирусни лицензи.

Съответствие със законодателството. Важен момент, тъй като използваните решения трябва да гарантират съответствие с изискванията на регулатора. Например облачните „резиденти“ често работят с лични данни. В този случай доставчикът трябва да има отделен сертифициран облачен сегмент, който да отговаря изцяло на изискванията на Закона за личните данни. Тогава компаниите не трябва самостоятелно да „изграждат“ цялата система за работа с лични данни: закупуване на сертифицирано оборудване, свързване и конфигуриране и преминаване на сертификация. За киберзащита на ISPD на такива клиенти, антивирусът също трябва да отговаря на изискванията на руското законодателство и да има сертификат FSTEC.

Разгледахме задължителните критерии, на които трябва да отговаря антивирусната защита в публичния облак. След това ще споделим нашия собствен опит в адаптирането на антивирусно решение за работа в облака на доставчика.

Как можете да направите приятели между антивирусната програма и облака?

Както показа нашият опит, изборът на решение въз основа на описание и документация е едно, но прилагането му на практика във вече работеща облачна среда е съвсем различна задача по отношение на сложността. Ще ви разкажем какво направихме на практика и как адаптирахме антивируса да работи в публичния облак на доставчика. Доставчикът на антивирусното решение беше Kaspersky, чието портфолио включва решения за антивирусна защита за облачни среди. Спряхме се на „Kaspersky Security за виртуализация“ (Лек агент).

Той включва една конзола на Kaspersky Security Center. Лек агент и виртуални машини за сигурност (SVM, Security Virtual Machine) и KSC интеграционен сървър.

След като проучихме архитектурата на решението Kaspersky и проведохме първите тестове заедно с инженерите на доставчика, възникна въпросът за интегрирането на услугата в облака. Първото внедряване беше извършено съвместно в московския облачен сайт. И това разбрахме.

За да се сведе до минимум мрежовият трафик, беше решено да се постави SVM на всеки ESXi хост и да се „свърже“ SVM към ESXi хостовете. В този случай леките агенти на защитени виртуални машини имат достъп до SVM на точния ESXi хост, на който работят. За основния KSC беше избран отделен административен наемател. В резултат на това подчинените KSC се намират в наемателите на всеки отделен клиент и се обръщат към висшестоящите KSC, разположени в сегмента на управление. Тази схема ви позволява бързо да решавате проблеми, които възникват при наемателите на клиенти.

В допълнение към проблемите с повишаването на компонентите на самото антивирусно решение, бяхме изправени пред задачата да организираме мрежово взаимодействие чрез създаването на допълнителни VxLAN. И въпреки че първоначално решението беше предназначено за корпоративни клиенти с частни облаци, с помощта на инженерния опит и технологичната гъвкавост на NSX Edge успяхме да разрешим всички проблеми, свързани с разделянето на наемателите и лицензирането.

Работихме в тясно сътрудничество с инженерите на Kaspersky. По този начин, в процеса на анализиране на архитектурата на решението по отношение на мрежовото взаимодействие между системните компоненти, беше установено, че освен достъп от леки агенти до SVM, е необходима и обратна връзка - от SVM към леки агенти. Тази мрежова свързаност не е възможна в мултитенантна среда поради възможността за идентични мрежови настройки на виртуални машини в различни облачни клиенти. Ето защо, по наша молба, колегите от доставчика преработиха механизма на мрежово взаимодействие между лекия агент и SVM по отношение на елиминирането на необходимостта от мрежова свързаност от SVM към леките агенти.

След като решението беше внедрено и тествано на московския облачен сайт, ние го репликирахме на други сайтове, включително сертифицирания облачен сегмент. Услугата вече е достъпна във всички региони на страната.

Архитектура на решение за информационна сигурност в рамките на нов подход

Общата схема на работа на антивирусно решение в публична облачна среда е следната:

Схема на работа на антивирусно решение в публична облачна среда #CloudMTS

Нека опишем характеристиките на работата на отделните елементи на решението в облака:

• Единна конзола, която позволява на клиентите да управляват централно системата за защита: да изпълняват сканирания, да контролират актуализациите и да наблюдават карантинните зони. Възможно е да конфигурирате индивидуални политики за сигурност във вашия сегмент.

Трябва да се отбележи, че въпреки че сме доставчик на услуги, ние не се намесваме в настройките, зададени от клиентите. Единственото нещо, което можем да направим, е да нулираме политиките за сигурност към стандартните, ако е необходимо преконфигуриране. Например, това може да е необходимо, ако клиентът случайно ги е затегнал или значително ги е отслабил. Една компания винаги може да получи контролен център с политики по подразбиране, които след това може да конфигурира независимо. Недостатъкът на Kaspersky Security Center е, че в момента платформата е достъпна само за операционната система на Microsoft. Въпреки че леките агенти могат да работят както с Windows, така и с Linux машини. Kaspersky Lab обаче обещава, че в близко бъдеще KSC ще работи под Linux OS. Една от важните функции на KSC е способността да управлява карантина. Всяка клиентска компания в нашия облак има лична. Този подход елиминира ситуации, при които документ, заразен с вирус, случайно става публично видим, както може да се случи в случай на класическа корпоративна антивирусна програма с обща карантина.

• Леки агенти. Като част от новия модел, на всяка виртуална машина е инсталиран олекотен Kaspersky Security агент. Това елиминира необходимостта от съхраняване на антивирусната база данни на всяка виртуална машина, което намалява необходимото дисково пространство. Услугата е интегрирана с облачната инфраструктура и работи чрез SVM, което увеличава плътността на виртуалните машини на ESXi хоста и производителността на цялата облачна система. Лекият агент изгражда опашка от задачи за всяка виртуална машина: проверка на файловата система, паметта и т.н. Но SVM е отговорен за извършването на тези операции, за които ще говорим по-късно. Агентът функционира и като защитна стена, контролира политиките за сигурност, изпраща заразените файлове в карантина и следи цялостното „здравословно състояние“ на операционната система, на която е инсталиран. Всичко това може да се управлява с помощта на вече споменатата единична конзола.

• Виртуална машина за сигурност. Всички задачи, изискващи големи ресурси (актуализации на антивирусни бази данни, планирани сканирания) се обработват от отделна виртуална машина за сигурност (SVM). Тя отговаря за работата на пълноценен антивирусен двигател и бази данни за него. ИТ инфраструктурата на една компания може да включва няколко SVM. Този подход повишава надеждността на системата – ако една машина се повреди и не реагира в продължение на тридесет секунди, агентите автоматично започват да търсят друга.

• KSC интеграционен сървър. Един от компонентите на основния KSC, който присвоява своите SVM на леки агенти в съответствие с алгоритъма, посочен в неговите настройки, и също така контролира наличността на SVM. По този начин този софтуерен модул осигурява балансиране на натоварването във всички SVM на облачната инфраструктура.

Алгоритъм за работа в облака: намаляване на натоварването на инфраструктурата

Като цяло антивирусният алгоритъм може да бъде представен по следния начин. Агентът има достъп до файла на виртуалната машина и го проверява. Резултатът от проверката се съхранява в обща централизирана база данни с присъди на SVM (наречена споделен кеш), всеки запис в който идентифицира уникална извадка от файл. Този подход ви позволява да гарантирате, че един и същ файл не се сканира няколко пъти подред (например, ако е бил отворен на различни виртуални машини). Файлът се сканира повторно само ако са направени промени в него или сканирането е стартирано ръчно.

Внедряване на антивирусно решение в облака на доставчика

Изображението показва обща диаграма на внедряването на решението в облака. Основният Kaspersky Security Center е разположен в контролната зона на облака и индивидуален SVM е разположен на всеки ESXi хост с помощта на KSC интеграционния сървър (всеки ESXi хост има собствен SVM, прикрепен със специални настройки на VMware vCenter Server). Клиентите работят в собствени облачни сегменти, където са разположени виртуални машини с агенти. Те се управляват чрез отделни KSC сървъри, подчинени на основния KSC. Ако е необходимо да се защитят малък брой виртуални машини (до 5), клиентът може да получи достъп до виртуалната конзола на специален специализиран KSC сървър. Мрежовото взаимодействие между клиентските KSC и основния KSC, както и леките агенти и SVM, се осъществява с помощта на NAT чрез клиентски виртуални рутери EdgeGW.

Според нашите оценки и резултатите от тестовете на колегите от доставчика, Light Agent намалява натоварването на виртуалната инфраструктура на клиентите с приблизително 25% (в сравнение със система, използваща традиционен антивирусен софтуер). По-специално, стандартната антивирусна програма Kaspersky Endpoint Security (KES) за физически среди изразходва почти два пъти повече време на процесора на сървъра (2,95%) от леко базирано на агент решение за виртуализация (1,67%).

Сравнителна таблица за натоварване на процесора

Подобна ситуация се наблюдава и при честотата на достъпа за запис на диск: за класически антивирус е 1011 IOPS, за облачен антивирус е 671 IOPS.

Графика за сравнение на скоростта на достъп до диска

Предимството в производителността ви позволява да поддържате стабилността на инфраструктурата и да използвате изчислителната мощност по-ефективно. Като се адаптира към работа в публична облачна среда, решението не намалява производителността на облака: то централно проверява файловете и изтегля актуализации, разпределяйки натоварването. Това означава, че от една страна няма да бъдат пропуснати заплахи, свързани с облачната инфраструктура, от друга страна, изискванията за ресурси за виртуални машини ще бъдат намалени средно с 25% в сравнение с традиционната антивирусна програма.

По отношение на функционалността и двете решения са много сходни едно с друго: по-долу е сравнителна таблица. В облака обаче, както показват резултатите от тестовете по-горе, все още е оптимално да се използва решение за виртуални среди.

За тарифите в рамките на новия подход. Решихме да използваме модел, който ни позволява да получаваме лицензи въз основа на броя vCPU. Това означава, че броят на лицензите ще бъде равен на броя на vCPU. Можете да тествате вашата антивирусна програма, като оставите заявка онлайн.

В следващата статия по облачни теми ще говорим за еволюцията на облачните WAF и какво е по-добре да изберете: хардуер, софтуер или облак.

Текстът е подготвен от служители на облачния доставчик #CloudMTS: Денис Мягков, водещ архитект и Алексей Афанасиев, мениджър по разработването на продукти за информационна сигурност.

Източник: www.habr.com