Все більше користувачів виводять у публічну хмару всю свою ІТ-інфраструктуру. Однак у разі недостатності антивірусного контролю в інфраструктурі замовника виникають серйозні кібер-ризики. Практика показує, що до 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. Такий підхід підвищує надійність системи - якщо якась машина виходить з ладу і не відповідає протягом XNUMX секунд, агенти автоматично починають шукати іншу.
• Сервер інтеграції 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