Усё больш карыстачоў выводзяць у публічнае воблака ўсю сваю ІТ-інфраструктуру. Аднак у выпадку недастатковасці антывіруснага кантролю ў інфраструктуры замоўца ўзнікаюць сур'ёзныя кібер-рызыкі. Практыка паказвае, што да 80% існуючых вірусаў выдатна жывуць у віртуальным асяроддзі. У гэтым пасце раскажам пра тое, як абараніць ІТ-рэсурсы ў публічным воблаку і чаму традыцыйныя антывірусы не зусім падыходзяць для гэтых мэт.
Для пачатку раскажам, як мы падышлі да думкі аб тым, што для публічнага аблокі не падыходзяць звыклыя інструменты антывіруснай абароны і патрабуюцца іншыя падыходы да абароны рэсурсаў.
Па-першае, як правіла, правайдэры забяспечваюць неабходныя меры, каб гарантаваць абарону сваіх хмарных платформаў на высокім узроўні. Напрыклад, мы ў #CloudMTS аналізуем увесь сеткавы трафік, маніторым логі сістэм бяспекі нашага аблокі, рэгулярна выконваем пентэсты. Сегменты аблокі, аддадзеныя асобным кліентам, таксама павінны быць надзейна абаронены.
Па-другое, класічны варыянт барацьбы з кібер-рызыкамі мае на ўвазе ўстаноўку антывіруса і сродкаў кіравання ім на кожную віртуальную машыну. Аднак пры вялікай колькасці віртуальных машын такая практыка можа быць неэфектыўнай і патрабаваць значных аб'ёмаў вылічальных рэсурсаў, тым самым дадаткова нагружаючы інфраструктуру заказчыка і зніжаючы агульную прадукцыйнасць аблокі. Гэта стала ключавой перадумовай для пошуку новых падыходаў да пабудовы эфектыўнай антывіруснай абароны віртуальных машын замоўцаў.
Акрамя таго, большасць наяўных на рынку антывірусных рашэнняў не адаптаваны для рашэння задач абароны ІТ-рэсурсаў у публічным хмарным асяроддзі. Як правіла, яны ўяўляюць сабой цяжкавагавыя EPP-рашэнні (Endpoint Protection Platforms), якія, да таго ж, не даюць магчымасці неабходнай кастамізацыі на баку кліентаў хмарнага правайдэра.
Становіцца відавочна, што традыцыйныя антывірусныя рашэнні дрэнна падыходзяць для працы ў воблаку, бо яны сур'ёзна нагружаюць віртуальную інфраструктуру падчас абнаўленняў і сканавання, таксама не маюць неабходных узроўняў ролевага кіравання і налад. Далей падрабязна разбяром, у сілу якіх чыннікаў воблака мае патрэбу ў новых падыходах па антывіруснай абароне.
Што павінен умець антывірус у публічным воблаку
Такім чынам, звернем увагу на спецыфіку працы ў віртуальным асяроддзі:
Эфектыўнасць правядзення абнаўленняў і масавыя праверкі па раскладзе. Калі значная колькасць віртуальных машын, якія выкарыстоўваюць традыцыйны антывірус, адначасова ініцыююць абнаўленне, у воблаку адбудзецца так званы "шторм" абнаўленняў. Магутнасці ESXi-хаста, на якім размяшчаюцца некалькі віртуальных машын, можа не хапіць для апрацоўкі шквалу аднатыпных задач, запушчаных па змаўчанні. З пункту гледжання хмарнага правайдэра, такая праблема можа прывесці да дадатковых нагрузак на цэлы шэраг ESXi-хастоў, што ў выніку прывядзе да падзення прадукцыйнасці віртуальнай інфраструктуры аблокі. Гэта можа адбіцца, у тым ліку, на прадукцыйнасці віртуальных машын іншых кліентаў аблокі. Аналагічная сітуацыя можа скласціся пры запуску масавага сканавання: адначасовая апрацоўка дыскавай сістэмай мноства аднатыпных запытаў ад розных карыстачоў будзе негатыўна ўплываць на прадукцыйнасць усяго аблокі. З вялікай доляй верагоднасці зніжэнне працаздольнасці СГД адаб'ецца на ўсіх кліентах. Такія скачкападобныя нагрузкі не цешаць ні правайдэра, ні яго замоўцаў, бо ўплываюць на «суседзяў» у воблаку. З гэтага пункту гледжання традыцыйны антывірус можа ўяўляць вялікую праблему.
Бяспечны каранцін. Калі ў сістэме выяўлены файл або дакумент, патэнцыйна заражаны вірусам, ён адпраўляецца ў карантын. Вядома, заражаны файл можна адразу выдаліць, але гэта часта не прымальна для большасці кампаній. Карпаратыўныя 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. І хоць рашэнне першапачаткова было прызначана для enterprise-кліентаў з прыватнымі аблокамі – з дапамогай інжынернай кемлівасці і тэхналагічнай гнуткасці NSX Edge нам удалося вырашыць усе задачы, звязаныя з падзелам тэнантаў і ліцэнзаваннем.
Мы працавалі ў шчыльным звязку з інжынерамі Kaspersky. Так, падчас аналізу архітэктуры рашэння ў частцы сеткавага ўзаемадзеяння паміж кампанентамі сістэмы было ўсталявана, што, акрамя доступу ад лёгкіх агентаў да SVM, таксама неабходна зваротная сувязь - ад SVM да лёгкіх агентаў. Дадзеная сеткавая злучанасць немагчымая ў multitenant-асяроддзі з прычыны магчымасці існавання ідэнтычных сеткавых налад віртуальных машын у розных тэнантах аблокі. Таму па нашай просьбе калегамі з вендара быў перапрацаваны механізм сеткавага ўзаемадзеяння паміж лёгкім агентам і SVM у частцы выключэння неабходнасці сеткавай звязанасці ад SVM да лёгкіх агентаў.
Пасля таго, як рашэнне было разгорнута і пратэставана на маскоўскай пляцоўцы аблокі, мы растыражавалі яго на астатнія пляцоўкі, у тым ліку атэставаны сегмент аблокі. Цяпер сэрвіс даступны ва ўсіх рэгіёнах краіны.
Архітэктура ИБ-рашэнні ў рамках новага падыходу
Агульная схема працы антывіруснага рашэння ў публічным хмарным асяроддзі выглядае наступным чынам:
Схема працы антывіруснага рашэння ў публічным хмарным асяроддзі #CloudMTS
Апішам асаблівасці працы асобных элементаў рашэння ў воблаку:
• Адзіная кансоль, якая дазваляе кліентам цэнтралізавана кіраваць сістэмай абароны: запускаць праверкі, кантраляваць абнаўленні і назіраць за каранціннымі зонамі. Ёсць магчымасць настройваць індывідуальныя палітыкі бяспекі ў рамках свайго сегмента.
Варта адзначыць, што мы хоць і з'яўляемся пастаўшчыком сэрвісу, але не ўмешваемся ў наладкі, якія ўстанаўліваюцца кліентамі. Адзінае, што мы можам зрабіць - гэта скінуць палітыкі бяспекі да стандартных у выпадку неабходнасці пераналадкі. Напрыклад, гэта можа спатрэбіцца, калі кліент выпадкова ўзмацніў жорсткасць іх або значна прыслабіў. Кампанія заўсёды можа атрымаць цэнтр кіравання з дэфолтнымі палітыкамі, якія затым можа самастойна наладзіць. Мінус Kaspersky Security Center у тым, што пакуль платформа даступная толькі для аперацыйнай сістэмы Microsoft. Хаця лёгкія агенты могуць працаваць як з Windows, так і з Linux-машынамі. Аднак у "Лабараторыі Касперскага" абяцаюць, што ўжо хуткім часам KSC запрацуе і пад АС Linux. Адна з важных функцый KSC – магчымасць кіравання каранцінам. У кожнай кампаніі-кліента ў нашым воблаку ён персанальны. Такі падыход выключае сітуацыі, калі заражаны вірусам дакумент выпадкова трапляе на ўсеагульны агляд, як гэта магло б адбыцца ў выпадку з класічным карпаратыўным антывірусам з агульным каранцінам.
• Лёгкія агенты. У рамках новай мадэлі на кожную віртуальную машыну усталёўваецца лёгкі агент Kaspersky Security. Гэта дазваляе не захоўваць антывірусную базу дадзеных на кожнай VM, што скарачае аб'ём займанай дыскавай прасторы. Сэрвіс інтэграваны з інфраструктурай аблокі і працуе праз SVM, што павялічвае шчыльнасць віртуальных машын на ESXi-хасце і прадукцыйнасць усёй хмарнай сістэмы. Лёгкі агент выбудоўвае чаргу заданняў для кожнай віртуальнай машыны: праверыць файлавую сістэму, памяць і т.д. Але за выкананне гэтых аперацый адказвае ўжо SVM, аб якой пагаворым далей. Таксама агент выконвае функцыі міжсеткавага экрана, кантралюе палітыкі бяспекі, адпраўляе заражаныя файлы ў каранцін і маніторыць агульнае "здароўе" аперацыйнай сістэмы, на якой усталяваны. Усім гэтым можна кіраваць з дапамогай ужо згаданай адзінай кансолі.
• Security Virtual Machine. Усімі рэсурсаёмістымі задачамі (абнаўленнямі антывірусных баз, праверкамі па раскладзе) займаецца асобная Security Virtual Machine (SVM). Яна адказвае за працу паўнавартаснага антывіруснага рухавіка і баз да яго. ІТ-інфраструктура кампаніі можа ўключаць некалькі SVM. Такі падыход падвышае надзейнасць сістэмы калі нейкая машына выходзіць з ладу і не адказвае на працягу трыццаці секунд, агенты аўтаматычна пачынаюць шукаць іншую.
• Сервер інтэграцыі KSC. Адзін з кампанентаў галоўнага KSC, які прызначае ў адпаведнасці з зададзеным у яго наладах алгарытмам, лёгкім агентам свае SVM, а таксама кантралюе даступнасць SVM. Такім чынам дадзены праграмны модуль забяспечвае балансаванне нагрузкі на ўсе SVM хмарнай інфраструктуры.
Алгарытм працы ў воблаку: зніжэнне нагрузкі на інфраструктуру
У цэлым алгарытм працы антывіруса можна ўявіць наступным чынам. Агент звяртаецца да файла на віртуальнай машыне і правярае яго. Вынік праверкі захоўваецца ў агульнай цэнтралізаванай базе вердыктаў SVM (яна завецца Shared Cache), кожны запіс у якой ідэнтыфікуе ўнікальны ўзор файла. Такі падыход дазваляе сачыць, каб адзін і той жа файл не правяраўся некалькі разоў запар (напрыклад, калі яго адчынілі на розных віртуальных машынах). Файл скануецца паўторна толькі ў тым выпадку, калі ў яго ўнеслі змены ці праверка была запушчана ўручную.
Рэалізацыя антывіруснага рашэння ў воблаку правайдэра
На малюнку прадстаўлена агульная схема рэалізацыі рашэння ў воблаку. У кіравальнай зоне аблокі разгорнуты галоўны Kaspersky Security Center, а на кожным ESXi-хасце пры дапамозе сервера інтэграцыі KSC разгорнута індывідуальная SVM (да кожнага ESXi-хасту адмысловымі наладамі на VMware vCenter Server прывязаны свой SVM). Кліенты працуюць у сваіх сегментах аблокі, дзе размяшчаюцца віртуальныя машыны з агентамі. Кіруюцца яны праз індывідуальныя KSC-серверы, падпарадкаваныя галоўнаму KSC. У выпадку неабходнасці абароны невялікай колькасці віртуальных машын (да 5) кліенту можа прадастаўляцца доступ да віртуальнай кансолі спецыяльнага выдзеленага сервера KSC. Сеткавае ўзаемадзеянне паміж кліенцкімі KSС і галоўным KSC, а таксама лёгкімі агентамі і SVM ажыццяўляецца пры дапамозе NAT праз кліенцкія віртуальныя маршрутызатары EdgeGW.
Па нашых ацэнках і выніках тэстаў калег у вендары, Лёгкі агент зніжае нагрузку на віртуальную інфраструктуру кліентаў прыкладна на 25% (калі параўноўваць з сістэмай, якая выкарыстоўвае традыцыйнае антывіруснае ПА). У прыватнасці, стандартны антывірус Kaspersky Endpoint Security (KES) для фізічных асяроддзяў расходуе амаль у два разы больш працэсарнага часу сервера (2,95%), чым рашэнне для віртуалізацыі на базе лёгкіх агентаў (1,67%).
Графік параўнання нагрузкі на працэсар
Падобная сітуацыя назіраецца з частатой зваротаў да дыска па запісе: для класічнага антывіруса яна складае 1011 IOPS, для хмарнага антывіруса - 671 IOPS.
Графік параўнання частаты зваротаў да дыска
Выйгрыш па прадукцыйнасці дазваляе падтрымліваць стабільнасць інфраструктуры і больш эфектыўна выкарыстоўваць вылічальныя магутнасці. За кошт адаптацыі для працы ў публічным хмарным асяроддзі рашэнне не змяншае прадукцыйнасці аблокі: яно ажыццяўляе цэнтралізаваную праверку файлаў і загрузку абнаўленняў, размяркоўваючы нагрузку. Гэта значыць, што, з аднаго боку, не будуць прапушчаны актуальныя для хмарнай інфраструктуры пагрозы, з другога - у сярэднім на 25% знізяцца патрабаванні да рэсурсаў віртуальных машын у параўнанні з традыцыйным антывірусам.
Па функцыянальнасці абодва рашэнні моцна нагадваюць адзін аднаго: ніжэй прыведзена параўнальная табліца. Аднак у воблаку, як паказваюць прыведзеныя вышэй вынікі тэсціраванняў, усё ж аптымальней выкарыстоўваць рашэнне для віртуальных асяроддзяў.
Пра тарыфікацыю ў межах новага падыходу. Мы прынялі рашэнне выкарыстоўваць мадэль, якая дазваляе атрымліваць ліцэнзіі па колькасці vCPU. Гэта значыць, што колькасць ліцэнзій будзе роўнай колькасці vCPU. Антывірус можна пратэставаць, пакінуўшы заяўку .
У наступным матэрыяле па хмарнай тэматыцы мы распавядзем аб эвалюцыі хмарных WAF і тым, што лепш абраць: жалеза, ПЗ ці воблака.
Тэкст падрыхтавалі супрацоўнікі хмарнага правайдэра #CloudMTS: Дзяніс Мягкоў, вядучы архітэктар і Аляксей Афанасьеў, менеджэр па развіцці прадуктаў ИБ.
Крыніца: habr.com