Сè повеќе корисници ја носат целата своја ИТ инфраструктура на јавниот облак. Меѓутоа, ако антивирусната контрола е недоволна во инфраструктурата на клиентот, се јавуваат сериозни сајбер ризици. Практиката покажува дека до 80% од постоечките вируси живеат совршено во виртуелна средина. Во овој пост ќе зборуваме за тоа како да ги заштитиме ИТ ресурсите во јавниот облак и зошто традиционалните антивируси не се целосно соодветни за овие цели.
За почеток, ќе ви кажеме како дојдовме до идејата дека вообичаените алатки за заштита од вируси не се соодветни за јавниот облак и дека се потребни други пристапи за заштита на ресурсите.
Прво, провајдерите генерално ги обезбедуваат неопходните мерки за да се осигураат дека нивните облак платформи се заштитени на високо ниво. На пример, во #CloudMTS го анализираме целиот мрежен сообраќај, ги следиме дневниците на безбедносните системи на нашиот облак и редовно вршиме пентести. Облак сегментите доделени на поединечни клиенти, исто така, мора да бидат безбедно заштитени.
Второ, класичната опција за борба против сајбер ризиците вклучува инсталирање на антивирус и алатки за управување со антивируси на секоја виртуелна машина. Меѓутоа, со голем број виртуелни машини, оваа практика може да биде неефикасна и да бара значителни количини на компјутерски ресурси, а со тоа дополнително да ја вчита инфраструктурата на клиентот и да ги намали вкупните перформанси на облакот. Ова стана клучен предуслов за пребарување на нови пристапи за градење ефикасна антивирусна заштита за виртуелните машини на клиентите.
Покрај тоа, повеќето антивирусни решенија на пазарот не се приспособени да ги решат проблемите со заштита на ИТ ресурсите во опкружување со јавен облак. Како по правило, тие се тешки EPP решенија (Endpoint Protection Platforms), кои, згора на тоа, не дозволуваат неопходно прилагодување на клиентската страна на давателот на облак.
Станува очигледно дека традиционалните антивирусни решенија се слабо прилагодени за работа во облакот, бидејќи тие сериозно ја вчитуваат виртуелната инфраструктура за време на ажурирањата и скенирањето, а исто така ги немаат потребните нивоа на управување и поставки засновани на улоги. Следно, детално ќе анализираме зошто на облакот му се потребни нови пристапи за заштита од вируси.
Што треба да може да направи антивирус во јавен облак
Значи, да обрнеме внимание на спецификите на работа во виртуелна средина:
Ефикасност на ажурирањата и закажаните масовни скенови. Ако значителен број виртуелни машини кои користат традиционален антивирус иницираат ажурирање во исто време, ќе се појави таканаречена „бура“ од ажурирања во облакот. Моќта на ESXi-домаќин кој е домаќин на неколку виртуелни машини можеби не е доволна за да се справи со низата слични задачи што се извршуваат стандардно. Од гледна точка на давателот на облак, таков проблем може да доведе до дополнителни оптоварувања на голем број ESXi хостови, што на крајот ќе доведе до пад на перформансите на виртуелната инфраструктура на облакот. Ова може, меѓу другото, да влијае на перформансите на виртуелните машини на други клиенти на облак. Слична ситуација може да се појави при стартување на масовно скенирање: истовремената обработка од системот на дискот на многу слични барања од различни корисници негативно ќе влијае на перформансите на целиот облак. Со висок степен на веројатност, намалувањето на перформансите на системот за складирање ќе влијае на сите клиенти. Ваквите нагли оптоварувања не му угодуваат ниту на давателот ниту на неговите клиенти, бидејќи тие влијаат на „соседите“ во облакот. Од оваа гледна точка, традиционалниот антивирус може да претставува голем проблем.
Безбеден карантин. Ако на системот се открие датотека или документ потенцијално заразен со вирус, тие се испраќаат во карантин. Се разбира, заразената датотека може веднаш да се избрише, но тоа често не е прифатливо за повеќето компании. Антивирусите на корпоративните претпријатија кои не се прилагодени да работат во облакот на давателот, по правило, имаат заедничка карантинска зона - сите заразени предмети паѓаат во неа. На пример, оние што се наоѓаат на компјутерите на корисниците на компанијата. Клиентите на давателот на облак „живеат“ во нивните сопствени сегменти (или станари). Овие сегменти се непроѕирни и изолирани: клиентите не знаат едни за други и, се разбира, не гледаат што другите хостираат во облакот. Очигледно, општиот карантин, до кој ќе пристапат сите корисници на антивируси во облакот, потенцијално може да вклучи документ што содржи доверливи информации или деловна тајна. Ова е неприфатливо за давателот и неговите клиенти. Затоа, може да има само едно решение - личен карантин за секој клиент во неговиот сегмент, каде што нема пристап ниту давателот, ниту другите клиенти.
Индивидуални безбедносни политики. Секој клиент во облакот е посебна компанија, чиј оддел за ИТ поставува свои безбедносни политики. На пример, администраторите ги дефинираат правилата за скенирање и закажуваат скенирање против вируси. Според тоа, секоја организација мора да има свој контролен центар за да ги конфигурира антивирусните политики. Во исто време, наведените поставки не треба да влијаат на другите клиенти на облакот, а давателот треба да може да потврди дека, на пример, ажурирањата на антивирус се извршуваат нормално за сите виртуелни машини на клиентите.
Организација на наплата и лиценцирање. Моделот на облак се карактеризира со флексибилност и вклучува плаќање само за количината на ИТ ресурси што ги користел клиентот. Ако има потреба, на пример, поради сезонска, тогаш количината на ресурси може брзо да се зголеми или намали - сето тоа врз основа на моменталните потреби за компјутерска моќ. Традиционалниот антивирус не е толку флексибилен - по правило, клиентот купува лиценца за една година за однапред одреден број сервери или работни станици. Корисниците на облакот редовно се исклучуваат и поврзуваат дополнителни виртуелни машини во зависност од нивните моментални потреби - соодветно, лиценците за антивирус мора да го поддржуваат истиот модел.
Второто прашање е што точно ќе опфаќа лиценцата. Традиционалниот антивирус е лиценциран според бројот на сервери или работни станици. Лиценците засновани на бројот на заштитени виртуелни машини не се целосно соодветни во моделот на облак. Клиентот може да создаде кој било број виртуелни машини погодни за него од достапните ресурси, на пример, пет или десет машини. Овој број не е константен за повеќето клиенти, не е возможно за нас, како провајдер, да ги следиме неговите промени. Не постои техничка можност за лиценцирање по процесорот: клиентите добиваат виртуелни процесори (vCPU), кои треба да се користат за лиценцирање. Така, новиот модел на антивирусна заштита треба да ја вклучи можноста клиентот да го одреди потребниот број на vCPU за кои ќе добие лиценци за антивирус.
Усогласеност со законодавството. Важна точка, бидејќи употребените решенија мора да обезбедат усогласеност со барањата на регулаторот. На пример, „жителите“ на облак често работат со лични податоци. Во овој случај, давателот мора да има посебен сертифициран сегмент на облак кој целосно ги исполнува барањата на Законот за лични податоци. Тогаш компаниите не треба самостојно да го „изградат“ целиот систем за работа со лични податоци: да купуваат сертифицирана опрема, да ја поврзат и конфигурираат и да подлежат на сертификација. За сајбер заштита на ISPD на такви клиенти, антивирусот исто така мора да ги исполнува барањата на руското законодавство и да има сертификат FSTEC.
Ги разгледавме задолжителните критериуми што мора да ги исполнува антивирусната заштита во јавниот облак. Следно, ќе го споделиме нашето сопствено искуство во прилагодувањето на антивирусно решение за работа во облакот на давателот.
Како можете да се дружите помеѓу антивирус и облак?
Како што покажа нашето искуство, изборот на решение засновано на опис и документација е една работа, но неговото имплементирање во пракса во веќе функционална облак средина е сосема поинаква задача во однос на сложеноста. Ќе ви кажеме што направивме во пракса и како го адаптиравме антивирусот да работи во јавниот облак на давателот. Продавач на антивирусното решение беше Kaspersky, чие портфолио вклучува решенија за заштита од вируси за облак околини. Се решивме на „Касперски безбедност за виртуелизација“ (Светлосен агент).
Вклучува една единствена конзола на Kaspersky Security Center. Лесни агенти и безбедносни виртуелни машини (SVM, Security Virtual Machine) и KSC сервер за интеграција.
Откако ја проучувавме архитектурата на решението Kaspersky и ги спроведовме првите тестови заедно со инженерите на продавачот, се појави прашањето за интегрирање на услугата во облакот. Првата имплементација беше спроведена заеднички на локацијата на облакот во Москва. И тоа е она што го сфативме.
Со цел да се минимизира мрежниот сообраќај, беше одлучено да се постави SVM на секој ESXi хост и да се „врзе“ SVM со ESXi хостовите. Во овој случај, светлосните агенти на заштитените виртуелни машини пристапуваат до SVM на точниот ESXi домаќин на кој работат. За главниот КСЦ беше избран посебен административен закупец. Како резултат на тоа, подредените KSC се наоѓаат во закупците на секој поединечен клиент и се обраќаат до супериорниот KSC лоциран во сегментот на управување. Оваа шема ви овозможува брзо да ги решите проблемите што се јавуваат кај станарите на клиентите.
Покрај проблемите со подигање на компонентите на самото антивирусно решение, се соочивме со задача да организираме мрежна интеракција преку создавање дополнителни VxLAN. И иако решението првично беше наменето за клиенти на претпријатија со приватни облаци, со помош на инженерската вештина и технолошката флексибилност на NSX Edge успеавме да ги решиме сите проблеми поврзани со одвојувањето на станарите и лиценцирањето.
Тесно соработувавме со инженерите на Kaspersky. Така, во процесот на анализа на архитектурата на решението во однос на мрежната интеракција помеѓу компонентите на системот, беше откриено дека, покрај пристапот од светлосни агенси до SVM, неопходна е и повратна информација - од SVM до светлосни агенти. Ова мрежно поврзување не е можно во опкружување со повеќе закупци поради можноста за идентични мрежни поставки на виртуелните машини во различни закупци на облак. Затоа, на наше барање, колегите од продавачот го преработија механизмот на мрежната интеракција помеѓу светлосниот агент и SVM во смисла на елиминирање на потребата за мрежно поврзување од SVM до светлосни агенти.
Откако решението беше распоредено и тестирано на страницата на облак во Москва, го реплициравме на други локации, вклучувајќи го и сертифицираниот сегмент на облак. Услугата сега е достапна во сите региони на земјата.
Архитектура на решение за безбедност на информации во рамките на нов пристап
Општата шема на работа на антивирусно решение во јавна облак средина е како што следува:
Шема на работа на антивирусно решение во јавна облак средина #CloudMTS
Дозволете ни да ги опишеме карактеристиките на работата на поединечните елементи на решението во облакот:
• Единствена конзола што им овозможува на клиентите централно да управуваат со системот за заштита: да извршуваат скенирања, да контролираат ажурирања и да ги следат карантинските зони. Можно е да се конфигурираат индивидуални безбедносни политики во рамките на вашиот сегмент.
Треба да се напомене дека иако сме давател на услуги, ние не се мешаме во поставките поставени од клиентите. Единственото нешто што можеме да го направиме е да ги ресетираме безбедносните политики на стандардни доколку е неопходна реконфигурација. На пример, ова може да биде неопходно ако клиентот случајно ги затегнал или значително ги ослабнал. Компанијата секогаш може да добие контролен центар со стандардни политики, кои потоа може самостојно да ги конфигурира. Недостаток на Kaspersky Security Center е тоа што платформата моментално е достапна само за оперативниот систем Мајкрософт. Иако лесните агенти можат да работат и со Windows и со Linux машини. Сепак, Kaspersky Lab ветува дека во блиска иднина KSC ќе работи под Linux OS. Една од важните функции на KSC е способноста да управува со карантин. Секоја клиентска компанија во нашиот облак има лична. Овој пристап ги елиминира ситуациите кога документот заразен со вирус случајно станува јавно видлив, како што може да се случи во случај на класичен корпоративен антивирус со општ карантин.
• Светлосни агенси. Како дел од новиот модел, на секоја виртуелна машина е инсталиран лесен агент Kaspersky Security. Ова ја елиминира потребата за складирање на антивирусната база на податоци на секој VM, што го намалува потребниот простор на дискот. Услугата е интегрирана со облак инфраструктурата и работи преку SVM, што ја зголемува густината на виртуелните машини на ESXi хостот и перформансите на целиот облак систем. Лесниот агент создава редица задачи за секоја виртуелна машина: проверете го датотечниот систем, меморијата итн. Но, SVM е одговорен за извршување на овие операции, за кои ќе зборуваме подоцна. Агентот исто така функционира како заштитен ѕид, ги контролира безбедносните политики, испраќа инфицирани датотеки во карантин и го следи целокупното „здравје“ на оперативниот систем на кој е инсталиран. Сето ова може да се управува со користење на веќе споменатата единечна конзола.
• Безбедносна виртуелна машина. Сите задачи со интензивни ресурси (надградби на базата на податоци за анти-вирус, закажани скенирања) се справуваат со посебна виртуелна машина за безбедност (SVM). Таа е одговорна за работата на полноправно антивирусен мотор и бази на податоци за него. ИТ инфраструктурата на една компанија може да вклучува неколку SVM. Овој пристап ја зголемува доверливоста на системот - ако една машина не успее и не реагира триесет секунди, агентите автоматски почнуваат да бараат друга.
• Сервер за интеграција на KSC. Една од компонентите на главниот KSC, кој ги доделува своите SVM на светлосни агенти во согласност со алгоритмот наведен во неговите поставки, а исто така ја контролира достапноста на SVM. Така, овој софтверски модул обезбедува балансирање на оптоварувањето низ сите SVM на инфраструктурата на облакот.
Алгоритам за работа во облак: намалување на оптоварувањето на инфраструктурата
Општо земено, антивирусниот алгоритам може да се претстави на следниов начин. Агентот пристапува до датотеката на виртуелната машина и ја проверува. Резултатот од верификацијата се чува во заедничка централизирана база на податоци за пресуди на SVM (наречена Заедничка кеш), секој запис во кој идентификува единствен примерок од датотека. Овој пристап ви овозможува да се осигурате дека истата датотека не се скенира неколку пати по ред (на пример, ако е отворена на различни виртуелни машини). Датотеката повторно се скенира само ако се направени промени во неа или скенирањето е рачно започнато.
Имплементација на антивирусно решение во облакот на провајдерот
Сликата покажува општ дијаграм за имплементација на решението во облакот. Главниот центар за безбедност на Kaspersky е распореден во контролната зона на облакот, а поединечен SVM се распоредува на секој ESXi-домаќин користејќи го серверот за интеграција KSC (секој ESXi-домаќин има свој SVM прикачен со посебни поставки на серверот VMware vCenter). Клиентите работат во сопствените сегменти на облак, каде што се наоѓаат виртуелните машини со агенти. Тие се управуваат преку поединечни 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