Све више корисника доводи целу своју ИТ инфраструктуру у јавни облак. Међутим, ако је антивирусна контрола недовољна у инфраструктури корисника, јављају се озбиљни сајбер ризици. Пракса показује да до 80% постојећих вируса савршено живи у виртуелном окружењу. У овом посту ћемо говорити о томе како заштитити ИТ ресурсе у јавном облаку и зашто традиционални антивируси нису у потпуности погодни за ове сврхе.
За почетак ћемо вам рећи како смо дошли до идеје да уобичајени алати за заштиту од вируса нису прикладни за јавни облак и да су потребни други приступи заштити ресурса.
Прво, провајдери генерално обезбеђују неопходне мере како би осигурали да су њихове платформе у облаку заштићене на високом нивоу. На пример, у #ЦлоудМТС анализирамо сав мрежни саобраћај, пратимо евиденције безбедносних система нашег облака и редовно вршимо пентестове. Сегменти облака додељени појединачним клијентима такође морају бити безбедно заштићени.
Друго, класична опција за борбу против сајбер ризика укључује инсталирање антивирусних и антивирусних алата за управљање на свакој виртуелној машини. Међутим, са великим бројем виртуелних машина, ова пракса може бити неефикасна и захтева значајне количине рачунарских ресурса, чиме се додатно учитава инфраструктура корисника и смањују укупне перформансе облака. Ово је постао кључни предуслов за тражење нових приступа изградњи ефикасне антивирусне заштите за виртуелне машине корисника.
Поред тога, већина антивирусних решења на тржишту није прилагођена за решавање проблема заштите ИТ ресурса у јавном облаку. По правилу, то су тешка ЕПП решења (Ендпоинт Протецтион Платформс), која, штавише, не пружају неопходну прилагодбу на страни клијента цлоуд провајдера.
Постаје очигледно да традиционална антивирусна решења нису погодна за рад у облаку, јер озбиљно оптерећују виртуелну инфраструктуру током ажурирања и скенирања, а такође немају потребне нивое управљања и подешавања заснованог на улогама. Затим ћемо детаљно анализирати зашто су облаку потребни нови приступи антивирусној заштити.
Шта антивирусни програм у јавном облаку треба да ради
Дакле, обратимо пажњу на специфичности рада у виртуелном окружењу:
Ефикасност ажурирања и планираних масовних скенирања. Ако значајан број виртуелних машина које користе традиционални антивирус покрену ажурирање у исто време, у облаку ће се појавити такозвана „олуја“ ажурирања. Снага ЕСКСи хоста који хостује неколико виртуелних машина можда неће бити довољна да се носи са мноштвом сличних задатака који се подразумевано извршавају. Са становишта провајдера облака, такав проблем може довести до додатног оптерећења на бројним ЕСКСи хостовима, што ће на крају довести до пада перформанси виртуелне инфраструктуре облака. Ово може, између осталог, утицати на перформансе виртуелних машина других клијената у облаку. Слична ситуација може се појавити приликом покретања масовног скенирања: истовремена обрада од стране система диска многих сличних захтева од различитих корисника негативно ће утицати на перформансе целог облака. Са великим степеном вероватноће, смањење перформанси система за складиштење ће утицати на све клијенте. Таква нагла оптерећења не пријају ни провајдеру ни његовим купцима, јер утичу на „комшије“ у облаку. Са ове тачке гледишта, традиционални антивирус може представљати велики проблем.
Безбедан карантин. Ако се датотека или документ потенцијално заражен вирусом открије на систему, он се шаље у карантин. Наравно, заражена датотека се може одмах избрисати, али то често није прихватљиво за већину компанија. Корпоративни корпоративни антивируси који нису прилагођени за рад у облаку провајдера, по правилу, имају заједничку карантинску зону - сви заражени објекти падају у њу. На пример, оне које се налазе на рачунарима корисника компаније. Клијенти клауд провајдера „живе“ у сопственим сегментима (или закупцима). Ови сегменти су непрозирни и изоловани: клијенти не знају једни за друге и, наравно, не виде шта други хостују у облаку. Очигледно, општи карантин, којем ће приступити сви антивирусни корисници у облаку, потенцијално би могао да садржи документ који садржи поверљиве информације или пословну тајну. Ово је неприхватљиво за провајдера и његове купце. Дакле, може постојати само једно решење – лични карантин за сваког клијента у његовом сегменту, где ни провајдер ни други клијенти немају приступ.
Индивидуалне безбедносне политике. Сваки клијент у облаку је посебна компанија, чије ИТ одељење поставља сопствене безбедносне политике. На пример, администратори дефинишу правила скенирања и заказују антивирусно скенирање. Сходно томе, свака организација мора имати сопствени контролни центар за конфигурисање антивирусних политика. Истовремено, наведена подешавања не би требало да утичу на друге клијенте у облаку, а провајдер би требало да буде у могућности да провери да ли се, на пример, антивирусна ажурирања обављају нормално за све клијентске виртуелне машине.
Организација фактурисања и лиценцирања. Модел облака карактерише флексибилност и подразумева плаћање само количине ИТ ресурса које је корисник користио. Ако постоји потреба, на пример, због сезонског карактера, онда се количина ресурса може брзо повећати или смањити – све на основу тренутних потреба за рачунарском снагом. Традиционални антивирус није толико флексибилан - клијент по правилу купује лиценцу на годину дана за унапред одређени број сервера или радних станица. Корисници облака редовно искључују и повезују додатне виртуелне машине у зависности од њихових тренутних потреба – сходно томе, антивирусне лиценце морају подржавати исти модел.
Друго питање је шта ће тачно лиценца покривати. Традиционални антивирус је лиценциран према броју сервера или радних станица. Лиценце засноване на броју заштићених виртуелних машина нису у потпуности прикладне у оквиру модела облака. Клијент може да креира било који број виртуелних машина погодних за њега из расположивих ресурса, на пример, пет или десет машина. Овај број није константан за већину клијената, ми као провајдер не можемо да пратимо његове промене. Не постоји техничка могућност лиценцирања путем ЦПУ-а: клијенти добијају виртуелне процесоре (вЦПУ), које треба користити за лиценцирање. Дакле, нови модел антивирусне заштите треба да укључи могућност да корисник одреди потребан број вЦПУ-а за које ће добити антивирусне лиценце.
Усклађеност са законодавством. Важна тачка, јер коришћена решења морају да обезбеде усаглашеност са захтевима регулатора. На пример, „становници“ облака често раде са личним подацима. У овом случају, провајдер мора имати посебан сертификован сегмент облака који је у потпуности усклађен са захтевима Закона о личним подацима. Тада компаније не морају самостално да „изграде“ цео систем за рад са личним подацима: купују сертификовану опрему, повезују и конфигуришу је и прођу сертификацију. За сајбер заштиту ИСПД-а таквих клијената, антивирус такође мора бити у складу са захтевима руског законодавства и имати ФСТЕЦ сертификат.
Погледали смо обавезне критеријуме које мора да испуни антивирусна заштита у јавном облаку. Затим ћемо поделити сопствено искуство у прилагођавању антивирусног решења за рад у облаку провајдера.
Како се можете спријатељити између антивируса и облака?
Као што је наше искуство показало, избор решења на основу описа и документације је једно, али је имплементација у пракси у већ радном цлоуд окружењу по сложености сасвим други задатак. Рећи ћемо вам шта смо радили у пракси и како смо прилагодили антивирус да ради у јавном облаку провајдера. Продавац антивирусног решења био је Касперски, чији портфолио укључује решења за заштиту од вируса за окружења у облаку. Одлучили смо се за „Касперски Сецурити фор Виртуализатион“ (Лигхт Агент).
Укључује једну конзолу Касперски Сецурити Центер. Лаки агент и безбедносне виртуелне машине (СВМ, Сецурити Виртуал Мацхине) и КСЦ интеграциони сервер.
Након што смо проучили архитектуру решења Касперски и спровели прве тестове заједно са инжењерима добављача, поставило се питање интеграције услуге у облак. Прва имплементација је спроведена заједно на московској локацији у облаку. И то смо схватили.
Да би се минимизирао мрежни саобраћај, одлучено је да се постави СВМ на сваки ЕСКСи хост и да се СВМ „веже“ за ЕСКСи хостове. У овом случају, лаки агенти заштићених виртуелних машина приступају СВМ-у тачног ЕСКСи хоста на којем су покренути. За главни КСЦ је изабран посебан административни закупац. Као резултат тога, подређени КСЦ се налазе у закупцима сваког појединачног клијента и обраћају се надређеној КСЦ која се налази у сегменту управљања. Ова шема вам омогућава да брзо решите проблеме који се јављају код закупаца клијената.
Поред проблема са подизањем компоненти самог антивирусног решења, суочили смо се са задатком организовања мрежне интеракције кроз креирање додатних ВкЛАН-ова. Иако је решење првобитно било намењено пословним клијентима са приватним облацима, уз помоћ инжењерске памети и технолошке флексибилности НСКС Едге-а успели смо да решимо све проблеме везане за одвајање станара и лиценцирање.
Блиско смо сарађивали са Касперски инжењерима. Тако је у процесу анализе архитектуре решења у погледу мрежне интеракције између компоненти система утврђено да је, поред приступа од светлосних агената СВМ-у, неопходна и повратна спрега – од СВМ до светлосних агената. Ова мрежна повезаност није могућа у окружењу са више станара због могућности идентичних мрежних подешавања виртуелних машина у различитим закупцима облака. Стога су, на наш захтев, колеге из продавца прерадиле механизам мрежне интеракције између светлосног агента и СВМ-а у смислу елиминисања потребе за мрежним повезивањем од СВМ-а до лаких агената.
Након што је решење постављено и тестирано на московској локацији у облаку, реплицирали смо га на друге локације, укључујући и сертификовани сегмент облака. Услуга је сада доступна у свим регионима земље.
Архитектура решења за безбедност информација у оквиру новог приступа
Општа шема рада антивирусног решења у јавном облаку је следећа:
Шема рада антивирусног решења у јавном облаку #ЦлоудМТС
Хајде да опишемо карактеристике рада појединих елемената решења у облаку:
• Јединствена конзола која омогућава клијентима да централно управљају системом заштите: покрећу скенирања, контролишу ажурирања и надгледају карантинске зоне. Могуће је конфигурисати појединачне безбедносне политике унутар вашег сегмента.
Треба напоменути да иако смо провајдер услуга, ми се не мешамо у подешавања која постављају клијенти. Једино што можемо да урадимо је да ресетујемо безбедносне политике на стандардне ако је потребна реконфигурација. На пример, ово може бити неопходно ако их је клијент случајно стегнуо или значајно ослабио. Компанија увек може да добије контролни центар са подразумеваним смерницама, које затим може самостално да конфигурише. Недостатак Касперски Сецурити Центер-а је што је платформа тренутно доступна само за Мицрософт оперативни систем. Иако лагани агенти могу да раде и са Виндовс и са Линук машинама. Међутим, Касперски Лаб обећава да ће КСЦ у блиској будућности радити под Линук ОС-ом. Једна од важних функција КСЦ-а је способност управљања карантином. Свака клијентска компанија у нашем облаку има личну. Овакав приступ елиминише ситуације у којима документ заражен вирусом случајно постане јавно видљив, као што би се могло догодити у случају класичног корпоративног антивируса са општим карантином.
• Лаки агенси. Као део новог модела, лагани Касперски Сецурити агент је инсталиран на свакој виртуелној машини. Ово елиминише потребу за складиштењем антивирусне базе података на сваком ВМ-у, што смањује количину простора на диску који се троши. Сервис је интегрисан са инфраструктуром облака и ради преко СВМ-а, што повећава густину виртуелних машина на ЕСКСи хосту и перформансе целог клауд система. Лаки агент прави ред задатака за сваку виртуелну машину: проверава систем датотека, меморију итд. Али СВМ је одговоран за обављање ових операција, о чему ћемо касније говорити. Агент такође функционише као заштитни зид, контролише безбедносне политике, шаље заражене датотеке у карантин и надгледа целокупно „здравље“ оперативног система на којем је инсталиран. Све ово се може управљати помоћу већ поменуте јединствене конзоле.
• Сигурносна виртуелна машина. Свим задацима који захтевају велике ресурсе (ажурирања антивирусних база података, заказана скенирања) управља посебна безбедносна виртуелна машина (СВМ). Она је одговорна за рад пуноправног антивирусног мотора и база података за њега. ИТ инфраструктура компаније може укључивати неколико СВМ-ова. Овај приступ повећава поузданост система – ако једна машина поквари и не реагује тридесет секунди, агенти аутоматски почињу да траже другу.
• КСЦ интеграциони сервер. Једна од компоненти главног КСЦ-а, која додељује своје СВМ-ове лаким агентима у складу са алгоритмом наведеним у његовим подешавањима, а такође контролише доступност СВМ-а. Дакле, овај софтверски модул обезбеђује балансирање оптерећења у свим СВМ-овима инфраструктуре облака.
Алгоритам за рад у облаку: смањење оптерећења инфраструктуре
Генерално, антивирусни алгоритам се може представити на следећи начин. Агент приступа датотеци на виртуелној машини и проверава је. Резултат верификације се чува у заједничкој централизованој бази података СВМ пресуда (која се зове Дељени кеш), сваки унос у коме идентификује јединствени узорак датотеке. Овај приступ вам омогућава да осигурате да се иста датотека не скенира неколико пута заредом (на пример, ако је отворена на различитим виртуелним машинама). Датотека се поново скенира само ако су у њој направљене промене или је скенирање покренуто ручно.
Имплементација антивирусног решења у облаку провајдера
На слици је приказан општи дијаграм имплементације решења у облаку. Главни Касперски Сецурити Центер је распоређен у контролној зони облака, а појединачни СВМ се поставља на сваки ЕСКСи хост користећи КСЦ интеграциони сервер (сваки ЕСКСи хост има свој СВМ повезан са посебним подешавањима на ВМваре вЦентер серверу). Клијенти раде у сопственим сегментима облака, где се налазе виртуелне машине са агентима. Њима се управља преко појединачних КСЦ сервера који су подређени главном КСЦ-у. Ако је потребно заштитити мали број виртуелних машина (до 5), клијенту се може обезбедити приступ виртуелној конзоли специјалног наменског КСЦ сервера. Мрежна интеракција између клијентских КСЦ-ова и главног КСЦ-а, као и лаких агената и СВМ-а, се врши коришћењем НАТ-а преко ЕдгеГВ клијентских виртуелних рутера.
Према нашим проценама и резултатима тестова колега код продавца, Лигхт Агент смањује оптерећење виртуелне инфраструктуре клијената за приближно 25% (у поређењу са системом који користи традиционални антивирусни софтвер). Конкретно, стандардни Касперски Ендпоинт Сецурити (КЕС) антивирус за физичка окружења троши скоро двоструко више процесорског времена сервера (2,95%) од лаганог решења виртуелизације заснованог на агентима (1,67%).
Табела за поређење оптерећења процесора
Слична ситуација се примећује и са учесталошћу приступа уписивању на диск: за класични антивирус то је 1011 ИОПС, за цлоуд антивирус 671 ИОПС.
Графикон поређења брзине приступа диску
Предност перформанси вам омогућава да одржите стабилност инфраструктуре и ефикасније користите рачунарску снагу. Прилагођавајући се раду у јавном облаку, решење не смањује перформансе облака: централно проверава датотеке и преузима ажурирања, распоређујући оптерећење. То значи да, с једне стране, претње релевантне за инфраструктуру облака неће бити пропуштене, а са друге стране, захтеви за ресурсима за виртуелне машине биће смањени у просеку за 25% у поређењу са традиционалним антивирусом.
Што се тиче функционалности, оба решења су веома слична једно другом: испод је табела поређења. Међутим, у облаку, као што показују горњи резултати тестирања, и даље је оптимално користити решење за виртуелна окружења.
О тарифама у оквиру новог приступа. Одлучили смо да користимо модел који нам омогућава да добијемо лиценце на основу броја вЦПУ-а. То значи да ће број лиценци бити једнак броју вЦПУ-а. Можете тестирати свој антивирус тако што ћете оставити захтев .
У следећем чланку о темама у облаку, говорићемо о еволуцији ВАФ-ова у облаку и шта је боље изабрати: хардвер, софтвер или облак.
Текст су припремили запослени у клауд провајдеру #ЦлоудМТС: Денис Мјагков, водећи архитекта и Алексеј Афанасјев, менаџер развоја производа за безбедност информација.
Извор: ввв.хабр.цом