У статті розповідається, як захистити резервні копії від вірусів-шифрувальників і чому звичайного бекапу вже недостатньо. Ви дізнаєтесь, як підготувати систему зберігання даних до кібератак, уникнути втрати інформації та мінімізувати наслідки зараження. Автор пояснює, як організувати резервування так, щоб навіть після зламу компанія змогла швидко відновити роботу. Матеріал допоможе зрозуміти, з чого почати побудову надійного захисту даних і які помилки найчастіше призводять до повної втрати інформації.
Десятиліттями резервні копії слугували головним захистом від фізичних збоїв обладнання та випадкової втрати даних. Надійна система резервного копіювання (СРК) мала пережити пожежу чи потоп і забезпечити безперервність роботи бізнесу. Та сьогодні з’явилася інша, значно реальніша загроза, перед якою безсилі вогнетривкі стіни й рознесені дата-центри.
Віруси-шифрувальники (Ransomware) стали серйозним випробуванням для більшості компаній. Зловмисники дедалі частіше шифрують дані, паралізуючи бізнес-процеси, спричиняючи фінансові збитки та репутаційні втрати. Наявність бекапів не гарантує безпеки, якщо саме резервне копіювання налаштоване неправильно або без урахування сучасних ризиків.
Мета матеріалу — розглянути актуальні методи й технології у сфері зберігання даних і резервного копіювання, які допомагають зменшити шкоду від атак шифрувальників і мінімізувати втрату інформації. Важливо пам’ятати: недостатньо просто зробити копію — потрібно зробити її правильно.
Коли йдеться про ransomware, насамперед мається на увазі логічне пошкодження даних та компрометація облікових записів адміністраторів домену.
Будь-яка компанія повинна приділити увагу чотирьом ключовим напрямам: технологіям, процесам, персоналу та дотриманню основних правил інформаційної безпеки. У кожному з них важливо провести комплекс заходів, що зменшують наслідки атак і прискорюють відновлення даних.
Перш ніж переходити до складних технічних рішень і сценаріїв відновлення, варто закріпити базові правила, які мають стати частиною “цифрової гігієни” кожної організації. Ці принципи — не рекомендації, а обов’язкові заходи, без яких система резервного копіювання приречена бути вразливою. Нижче подано основні методи, які реально працюють і перевірені практикою:
Дотримання стратегії 3-2-1-1. Для надійного зберігання потрібно мати три копії даних; дві з них — на різних типах носіїв (наприклад, масив і хмара, або масив і стрічка); одну копію — поза основним дата-центром; ще одну — на незмінному сховищі (WORM) або в офлайн-режимі.
Окреме розміщення резервних копій. Бекапи не повинні зберігатися на продуктивних масивах, де знаходяться основні дані. Вони мають бути розміщені на окремих пристроях або у спеціальних сховищах.
Регулярність резервування. Резервні копії потрібно створювати за затвердженим графіком, перевіряти їхню цілісність і виключати будь-які збої чи пропуски у процесі.
Консистентність даних. Копії слід робити не лише на рівні файлової системи, а й на рівні баз даних та програм, щоб при відновленні відтворювався повний робочий ландшафт системи.
Сегментація мережі. Оскільки атаки шифрувальників здебільшого відбуваються через мережу Ethernet, необхідно фізично відокремлювати мережі передачі, керування, зберігання даних і резервного копіювання.
Ізольоване зберігання (air-gapped backups). Копії мають зберігатися в офлайн-середовищі без постійного підключення до мережі. Використовуються змінні носії — стрічки або зовнішні диски, що зберігаються у захищених приміщеннях.
Резервування каталогу та бази керування. Необхідно регулярно копіювати базу даних дедуплікації, каталог резервних копій і сервер керування, щоб у разі атаки швидко відновити працездатність.
Захист каталогу. Метадані системи резервного копіювання потрібно дублювати. Наявність автономної копії каталогу дозволяє швидко відновити інформацію про те, де зберігаються потрібні резерви.
Автоматизація копіювання каталогу. Один із ефективних варіантів — збереження каталогу на окремій NFS-кулі в ізольованому сегменті, який не підключений до домену. Куля монтується лише за розкладом, виконується копіювання, після чого ресурс відключається. Це можна налаштувати через cron і pre/post-команди.
Використання вбудованих механізмів захисту. Сучасне програмне забезпечення резервного копіювання містить функції виявлення аномалій, блокування несанкціонованих змін і запобігання шифруванню даних. Важливо не ігнорувати ці можливості.
Каталог системи резервного копіювання — це серце всієї структури. Втрата його метаданих означає неможливість відновити дані навіть за наявності фізичних копій. Тому всі розвинені СРК мають механізми створення автономних резервних копій каталогу, які можна розгорнути “з нуля” на новому сервері в режимі холодного резерву. Рекомендується щонайменше раз на добу робити повне резервування каталогу в окремому сховищі, а службову інформацію — дублювати у вигляді текстових файлів або надсилати поштою. Копії каталогу бажано дублювати на стрічки для зберігання поза основним майданчиком.
Більшість сучасних систем резервного копіювання вже мають вбудований захист від шифрувальників. Такі модулі автоматично виявляють аномалії у поведінці клієнтів, блокують шкідливі процеси, захищають власні файли, каталоги та бази даних. Нижче наведено приклади популярних рішень:
Кіберпротект (Кібер Бекап). Модуль Active Protection відстежує процеси на сервері: якщо програма намагається шифрувати файли або майнити криптовалюту, система створює оповіщення і виконує задані дії. Вона також блокує зміни власних конфігурацій, записів реєстру та локальних копій. Додатково модуль Оцінка вразливостей аналізує захищені машини, перевіряє оновлення ОС і програм.
Acronis CyberBackup. Містить аналогічні механізми моніторингу процесів, запобігання шифруванню, контроль доступу до резервних копій і вбудовану перевірку цілісності даних.
RuBackup (Група «Астра»). Передбачає реплікацію обраних копій за розкладом на незалежну інсталяцію. Завдяки автономності другого домену шифрувальник не може пошкодити збережені дані. Також підтримується цифровий підпис резервних копій для контролю їхньої справжності.
Правильно побудована система резервного копіювання — це не просто технічна вимога, а основа кіберстійкості бізнесу. Жоден антивірус чи міжмережевий екран не гарантує повного захисту від шифрувальників, але грамотно організовані бекапи дозволяють уникнути катастрофічних наслідків.
Регулярність, ізоляція, сегментація, контроль доступу та постійне тестування — ось п’ять складових справді живучої системи. Коли резервні копії розміщено в кількох середовищах і захищено від змін, компанія отримує шанс швидко відновитися навіть після масштабної атаки.
У сучасних умовах бекап — це не архів, а активна частина кібероборони. І саме він визначає, чи виживе інфраструктура після зустрічі з вірусом-шифрувальником.
Сучасні системи резервного копіювання дедалі частіше оснащуються власними механізмами безпеки, що дозволяють виявляти та блокувати шкідливу активність ще до того, як вона зашкодить даним. Нижче наведено приклади найбільш популярних платформ, які інтегрували захист від вірусів-шифрувальників безпосередньо у свій функціонал.
Commvault B&R має окрему утиліту Enable Ransomware Protection, яка дозволяє централізовано керувати функціями захисту та моніторингу активності файлів у межах CommCell. Система блокує зміну локальних копій будь-якими процесами, окрім власних, аналізує історію операцій і виявляє підозрілу активність. Додатково можна використовувати honeypot-файли — приманки, які сигналізують про спробу шифрування. Програма також створює звіти про аномалії та надсилає сповіщення при втраті зв’язку з клієнтами резервного копіювання.
Veritas NetBackup застосовує функціонал AIR (Auto Image Replication), який реплікує резервні копії на незалежні домени через політики SLP. Такий підхід забезпечує повну ізоляцію бекапів від атакованої інфраструктури. Додаткову безпеку гарантує використання спеціалізованих пристроїв NetBackup Appliance із протоколом OST, що дозволяє зберігати копії у форматі WORM. Система також оснащена модулем Anomaly Detection, який за допомогою алгоритмів машинного навчання виявляє нетипові дії під час резервування.
Veeam Backup & Replication реалізує захист через Immutable-сховища та функції Hardened Repository, що обмежують зміну даних на Linux-серверах. Інтеграція з HPE StoreOnce дозволяє створювати незмінне сховище з подвійною автентифікацією, запобігаючи редагуванню резервів упродовж заданого періоду. Моніторинг здійснюється за допомогою Veeam ONE, який аналізує активність системи та допомагає швидко реагувати на загрози. Vinchin Backup & Recovery також застосовує ізольовані сховища, де функція Storage Security захищає резервні копії від сторонніх змін і несанкціонованого доступу.
Одним із дієвих способів захисту даних є регулярне створення миттєвих знімків (снепшотів) на продуктивних масивах із подальшою реплікацією на окрему систему зберігання, призначену для резервних копій.
Варто пам’ятати, що снепшот на робочому масиві сам по собі не є повноцінною резервною копією — це швидкий і зручний інструмент для оперативного зняття копії та відновлення даних. Головна умова — забезпечити консистентність знімку, щоб уникнути пошкоджень при відновленні. Якщо ж консистентний снепшот реплікується на окрему систему, він уже може вважатися повноцінною резервною копією.
Відповідальність за підтримання консистентності, ротацію знімків і керування копіями лежить на програмному забезпеченні для резервного копіювання (СРК). Проте слід враховувати ризики — неконтрольоване збільшення обсягу снепшотів може знизити продуктивність і підвищити вартість зберігання, особливо якщо потрібна окрема ліцензія. Основна перевага такого підходу — надзвичайно швидке відновлення даних.
Сучасні промислові рішення, як-от Veeam або Commvault, добре інтегруються з провідними дисковими масивами (**Huawei, NetApp**) для автоматизованого створення снепшотів. Такі знімки можуть використовуватися як для швидкого відновлення, так і як перший рівень довгострокового зберігання.
Створення снепшотів можливе і без спеціального ПЗ — безпосередньо засобами СГД за допомогою технології CDP (Continuous Data Protection), яку підтримують провідні виробники (**Huawei, Dell, NetApp, Pure**). Вона дозволяє створювати знімки з інтервалом до кількох хвилин і керувати їхньою ротацією. Проте такі снепшоти не є консистентними, а відновлення після них нагадує запуск системи після раптового вимкнення живлення.
Українські розробники поки що не мають повноцінної технології CDP, але деякі рішення, як-от Yadro Gen2, Aerodisk Engine, Baum, дозволяють створювати снепшоти через CLI або API. Також можливе використання відкладеної асинхронної реплікації, коли копія даних оновлюється з певним запізненням (на кілька годин або днів) — однак ця функція доступна не у всіх виробників.
Використання зовнішніх файлових систем із захистом від перезапису протягом заданого терміну (Retention lock) може значною мірою ускладнити життя зловмисникам, особливо щодо їх видалення/псування. Технології незмінного сховища (immutable storage) захищають дані резервних копій змін після їх створення.
В даному випадку потрібна підтримка як з боку СГД (NetApp SnapLock, Huawei Hyperlock), так і з боку СРК. В іншому випадку можливі помилки в роботі ПЗ СРК, оскільки керуючі компоненти (майстер-сервер, медіасервери) не зможуть коректно працювати із заблокованими від запису файлами резервних копій. Найпростіший варіант – використовувати файлові системи в режимі WORM лише для виконання повних копій.
У системах захисту від вірусів-шифрувальників дедуплікатори фактично виступають окремим типом сховищ із файловим доступом. Їхня головна роль — зменшення обсягу резервних копій і підвищення захищеності за рахунок використання спеціальних протоколів доступу до даних.
Багато вендорів мають власні рішення immutable storage у вигляді апаратних PBBA (Purpose-Built Backup Appliance) — таких як *NetBackup Flex Appliance, HPE StoreOnce, Dell EMC DataDomain, Quantum DXi, Tatlin Backup* тощо. Ці системи побудовані з урахуванням потреб безпечного зберігання резервних копій і захисту їх від модифікації навіть у випадку компрометації операційної системи або ПЗ.
Ключовим елементом безпеки PBBA є використання пропрієтарних протоколів взаємодії між програмним забезпеченням резервного копіювання (СРК) і пристроєм зберігання — таких як DDBoost (Dell EMC) або Catalyst (HPE). Завдяки цьому дані не доступні безпосередньо з файлової системи, оскільки обмін відбувається через спеціальні API, а не стандартні протоколи *CIFS, NFS або SMB*. Це значно ускладнює несанкціонований доступ і знижує ризик шифрування чи видалення копій.
Наприклад, у HPE StoreOnce реалізовано механізм StoreOnce Catalyst Store. Він не використовує системні команди ОС, а спілкується з клієнтами лише через набір API-команд, вбудованих у плагін резервного ПЗ. Таким чином, дані, що зберігаються у StoreOnce, недоступні з операційної системи, їх можна переглядати лише через консоль ПЗ СРК або веб-інтерфейс дедуплікатора.
Основна перевага PBBA полягає в тому, що вони ізольовані від файлових протоколів, мають власну систему аутентифікації й не покладаються на стандартні засоби ОС. Завдяки цьому навіть у разі зламу медіасервера чи інфраструктури, резервні копії залишаються недоторканими та доступними для відновлення.
Стрічкові носії залишаються одним із найнадійніших способів захисту від атак вірусів-шифрувальників. Навіть у разі повної втрати майстер-сервера системи резервного копіювання (СРК) дані зі стрічок можна імпортувати — така функція підтримується більшістю програмних рішень. Єдиний недолік полягає у тривалому процесі відновлення, оскільки потрібно послідовно зчитати кожну стрічку. Швидкість цього процесу залежить від типу носія, його обсягу та технічних характеристик. Раніше згадувалося, що створення резервної копії каталогу СРК значно скорочує час відновлення у випадку пошкодження системи під час атаки.
Для критично важливих середовищ рекомендується дублювати резервні копії на окремі стрічкові носії, виймати їх із бібліотек і зберігати в офсайтових сейфах, стійких до займання. Такий підхід ускладнює доступ зловмисників навіть за умови, що вони отримають контроль над інфраструктурою СРК. Водночас цей метод не виключає ризику внутрішньої загрози — з боку співробітників, які мають прямий доступ до системи й можуть навмисно пошкодити дані.
WORM-стрічки доцільно використовувати у випадках, коли потрібно забезпечити довготривале зберігання резервних копій (3–10 років) відповідно до регуляторних вимог або коли бібліотека фізично ізольована. Такі носії дорожчі, оскільки не підлягають перезапису, але їхня особливість — одноразовий запис — гарантує неможливість випадкового чи навмисного видалення даних, що особливо важливо під час кібератак або помилок персоналу.
WORM-картриджі конструктивно майже не відрізняються від звичайних RW-моделей. Головна відмінність полягає у спеціальному чіпі Linear Tape-Open Cartridge Memory (LTO-CM), який визначає носій як WORM. Додаткові зміни стосуються сервотреків, що використовуються для перевірки незмінності даних. Зазвичай нижня частина таких картриджів має сірий колір, а корпус може бути оснащений гвинтами з антивандальним захистом. Приводи, які підтримують режим WORM, автоматично розпізнають ці картриджі та додають унікальний ідентифікатор (WORM ID) до кожного набору записаних даних.
Одним із практичних способів додаткового захисту резервних копій є фізичне блокування стрічок від запису у бібліотеці після завершення копіювання. Ідеальний сценарій — коли адміністратор резервного копіювання щодня перевіряє касети, виставляє прапорець захисту від запису на Full-стрічках і розблоковує лише ті, для яких минув період зберігання (Retention). Дотримання цього регламенту може періодично перевіряти офіцер інформаційної безпеки або аутсорсингова служба.
Щоб спростити управління великою кількістю носіїв, рекомендується використовувати касети зі штрих-кодами. Перед початком роботи потрібно переконатися, що всі коди зчитуються правильно та не пошкоджені. Якщо у вас кілька бібліотек, важливо уникати дублювання штрих-кодів — це допоможе уникнути плутанини при ротації.
Для розміщення резервних копій можна використовувати S3-сховища, які доступні у двох основних формах — публічні хмари (наприклад, Mail.ru, Yandex Cloud тощо) або on-premise рішення, реалізовані на базі відкритих систем (Ceph, MinIO) чи пропрієтарних платформ (Hitachi Content Platform, NetApp StorageGrid, Tatlin Object).
Програмне забезпечення резервного копіювання має підтримувати роботу з основними методами S3-протоколу, зокрема з механізмом Object Lock, який забезпечує незмінність об’єктів і передбачає три режими блокування:
Governance — кероване блокування, яке можна обійти за спеціального підтвердження;
Compliance — суворе блокування, що не дозволяє змінювати або видаляти дані до закінчення терміну дії;
Legal Hold — безстрокове блокування, яке користувач може вручну активувати чи зняти, але обійти не можна.
У випадку використання Object Lock варто враховувати, що система резервного копіювання не зможе автоматично видаляти копії після завершення періоду зберігання. Тому налаштування політики збереження потрібно виконати ще на етапі проектування інфраструктури.
Використання on-premise S3-сховищ дає повний контроль, але потребує додаткових інвестицій у обладнання, адміністрування та підтримку. Крім того, це створює ризик людського фактора, адже адміністратори мають фізичний доступ до серверів і кластерів, що зберігають копії.
Натомість публічні хмари виглядають безпечнішими, оскільки доступ до них обмежується ключами доступу (access key / secret key) без прямого керування фізичними серверами. Проте вони передбачають додаткові витрати — оплату трафіку, обсягів зберігання та операцій введення-виведення.
У підсумку, S3-сховища з Object Lock забезпечують високий рівень ізоляції та захисту резервних копій, але вимагають ретельного планування, фінансової оцінки та чітких політик управління життєвим циклом даних, щоб уникнути неочікуваних ризиків і зайвих витрат.
Усі процедури резервного копіювання та відновлення даних мають бути формалізовані в офіційній документації СРК і погоджені з керівництвом та власниками систем. Актуалізацію таких документів слід проводити щонайменше раз на пів року. Необхідно мати:
єдиний регламент резервного копіювання та відновлення;
плани відновлення для кожної інформаційної системи (включно із самою СРК);
регламент відновлення системи резервного копіювання;
правила роботи з копіями, що вилучаються або передаються.
Усі дії виконуються за заявками (RFC) із зазначенням відповідальних осіб. Підготовка документації вимагає аудиту інформаційних систем, визначення показників RTO і RPO, термінів зберігання копій та оцінки критичності кожної системи (за допомогою BIA). Це дозволяє обрати оптимальну схему резервування, враховуючи вимоги до швидкості відновлення та допустимий час простою.
Щоб переконатись у працездатності системи, варто регулярно проводити навчальні відновлення у контрольованому, ізольованому середовищі. Такі перевірки допомагають з’ясувати:
скільки часу потрібно для повного відновлення даних;
де виникають “вузькі місця” у процесі;
чи зберігається цілісність баз даних;
чи охоплює резервна копія всі необхідні дані;
чи можливо відновити сам каталог СРК при обраній схемі резервування.
Результати таких тестів дозволяють удосконалити регламенти й уникнути помилок під час реальної аварії.
Єдина система моніторингу — ключовий інструмент для оперативного реагування на інциденти й профілактичного контролю стану СРК. Відповідальні спеціалісти мають своєчасно отримувати сповіщення про збої, помилки чи аномалії через електронну пошту, SMS, месенджери або дзвінки чергових інженерів.
Як мінімум слід використовувати моніторинг, вбудований у ПЗ резервного копіювання, і відстежувати стан апаратних компонентів — медіасерверів, сховищ та каналів зв’язку.
Ознаки потенційної загрози:
раптове збільшення обсягу інкрементальних копій;
нетипове навантаження на файлові системи чи LUN;
ручне видалення резервних файлів;
спроби несанкціонованого доступу до СРК.
Такі сигнали вимагають негайного аналізу, адже можуть свідчити про підготовку або початок атаки шифрувальника.
Щоб мінімізувати ризики несанкціонованого доступу до системи резервного копіювання, необхідно дотримуватися кількох базових правил.
Захист сховищ даних. Найвразливішими для атак є файлові системи на внутрішніх або підключених дисках через CIFS/NFS. Для мереж зберігання даних (SAN) доцільніше використовувати Fibre Channel, оскільки цей протокол менш схильний до зовнішніх вторгнень, ніж Ethernet.
Локальні облікові записи. Щоб уникнути компрометації у разі злому домену Active Directory, у сегментах керування, резервного копіювання та СХД потрібно застосовувати локальні облікові записи з жорсткою парольною політикою й регулярною зміною паролів.
Фізичний контроль доступу. Компоненти СРК мають розміщуватися у захищених приміщеннях із СКУД і відеоспостереженням, щоб виключити несанкціонований фізичний доступ.
Актуальність оновлень. Важливо регулярно встановлювати патчі на ОС і ПЗ СРК, особливо ті, що усувають критичні вразливості. Необхідно відстежувати безпекові бюлетені виробників і своєчасно реагувати на виявлені загрози.
Мережевий захист. Для контролю трафіку між сегментами слід застосовувати брандмауери, але не пропускати через них сам трафік резервного копіювання, аби уникнути втрати продуктивності. Рекомендується залишати мінімально необхідний набір портів і, за можливості, використовувати нестандартні.
Резервування конфігурацій мережі. Конфігураційні файли комутаторів (FC, Ethernet) слід копіювати після кожних змін, але не рідше раз на місяць. Наприклад, у Brocade це команда
configupload, а в Cisco MDS —copy running-config startup-config. Це допоможе швидко відновити зонінг SAN-мереж у разі збою.
Адміністративна безпека. Доступ до адміністративної консолі СРК варто здійснювати лише з виділеного термінального сервера та за наявності апаратного USB-токена. Для входу обов’язково має використовуватися багатофакторна аутентифікація (MFA) й чітке розмежування прав користувачів.
Контур СРКіВС — це остання лінія оборони компанії, яка забезпечує відновлення даних після шифрувальних атак або критичних інцидентів. Найбільш надійний результат дає дотримання принципу «3-2-1-1» та впровадження багаторівневого захисту.
Низка заходів не потребує великих інвестицій — достатньо правильно налаштувати вже наявну СРК, оновити політики доступу й упорядкувати процеси резервного копіювання. Решта рішень, як-от стрічкові бібліотеки чи ізольовані сегменти, вимагають додаткових ресурсів, але суттєво підвищують стійкість інфраструктури.
Поєднання технологічних рішень, регулярного моніторингу та чітких регламентів дозволяє створити систему, здатну не лише відновити дані, а й ефективно протидіяти спробам їх шифрування чи знищення.
