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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Освен въпросите около стартирането на компонентите на самото антивирусно решение, пред нас възникна задача за организация на мрежовото взаимодействие чрез създаване на допълнителни VxLAN. И макар решението първоначално да беше предназначено за enterprise клиенти с частни облаци — с помощта на инженерна находчивост и технологична гъвкавост на 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 хост чрез интеграционен сървър KSC е внедрена индивидуална SVM (към всеки ESXi хост с помощта на специални настройки в VMware vCenter Server е привързана своя SVM). Клиентите работят в своите сегменти на облака, където са разположени виртуални машини с агенти. Те се управляват чрез индивидуални KSC сървъри, подчинени на главния KSC. В случай на необходимост от защита на малко количество виртуални машини (до 5), на клиента може да бъде предоставен достъп до виртуалната конзола на специален отделен KSC сървър. Мрежовото взаимодействие между клиентските KSC и главния KSC, както и между леките агенти и SVM се осъществява с помощта на NAT през клиентските виртуални рутери EdgeGW.

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

Графика на сравнение на натоварването на процесора

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

Графика на сравнение на честотата на обращенията към диска

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

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

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

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

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

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