Уявіть звичайний ранок: система не працює, файли зашифровані, на екрані — вимога викупу. Усередині ще є спокій: «у нас же є резервні копії». А потім з’ясовується, що відновлюватися нема з чого. Репозиторій з бекапами видалений або зашифрований разом з усією інфраструктурою.
Це вже не рідкісний інцидент і не «невдалий кейс». Для України у 2025–2026 роках це нормальна картина. Сучасні ransomware-атаки майже завжди починаються не з шифрування серверів, а з полювання на резервні копії. Зловмисникам не потрібно знищувати бізнес, якщо можна знищити можливість відновлення.
Відповідно до досвіду Softline IT, більшість компаній упевнені, що з бекапами у них усе гаразд. Але коли доходить до інциденту, виявляється, що резервні копії були частиною тієї ж самої системи, яку атакували.
Типова схема виглядає просто: сервер бекапів у тому ж домені, той самий обліковий запис адміністратора, постійний доступ до NAS або мережевих папок. Формально бекапи є. Фактично вони не ізольовані.
Сучасні зловмисники працюють методично. Вони можуть перебувати в мережі від кількох годин до кількох днів, інколи довше, але тренд один — діяти швидко. За цей час вони отримують потрібні права доступу, знаходять бекап-інфраструктуру, видаляють точки відновлення, знищують snapshots або змінюють політики зберігання. Шифрування — це вже фінальний крок, коли бізнесу більше нічим відповідати.
Найбільша проблема класичного підходу в тому, що бекап став частиною поверхні атаки. Якщо адміністратор може видалити резервну копію, це означає, що й зловмисник з украденими адмінськими правами може зробити те саме.
Immutable-бекапи: це не «тільки для читання» і не галочка в налаштуваннях
Саме тут з’являється поняття immutable-бекапів. Це не «тільки для читання» і не галочка в налаштуваннях. Immutable означає, що дані після запису не можна змінити або видалити протягом визначеного часу — навіть маючи повні адміністративні права. Не тому, що хтось «не дозволяє», а тому, що це фізично неможливо на рівні сховища.
На практиці це реалізується або через об’єктні сховища з object lock, або через спеціально захищені бекуп-репозиторії на Linux. У першому випадку дані записуються в хмару або віддалене сховище, де діє жорстка політика незмінності. У другому — створюється окремий сервер з мінімальними правами доступу, де бекап-файли не можна видалити до завершення терміну зберігання.
Важливий нюанс: immutable не робить інфраструктуру «незнищенною». Він захищає саме дані від логічного знищення або перезапису — тобто від того, що і є головною метою ransomware.
Air-gap: фізичний та логічний
Але однієї незмінності недостатньо. Якщо бекуп-сховище постійно доступне з тієї ж мережі, воно все одно лишається ціллю. Тому другий ключовий принцип — air-gap.
Класичний air-gap — це фізичний розрив: стрічки або знімні носії. Це працює, але вимагає дисципліни, логістики, живлення і людей, які реально цим займаються. В українських умовах не кожна компанія може дозволити собі таку модель без ризиків для операційної діяльності.
Тому все частіше використовується логічний air-gap. Це окремий контур — зазвичай у хмарі або в іншому дата-центрі — куди бекап передається через обмежений канал. Доступ відкривається лише на час копіювання і закривається одразу після. Дані знаходяться поза основною інфраструктурою і захищені політикою незмінності.
На практиці саме поєднання immutable та air-gap дає той рівень захисту, який дозволяє відновлюватися навіть після серйозної атаки.
Типові помилки SMB
- Усе на одному NAS. Файли + бекапи + ті ж адмінські паролі. Компрометація NAS = повна втрата.
- Бекап у тому ж домені. Доменний адмін автоматично стає адміном бекапів.
- Бекапи ніколи не тестувалися. Їх створюють, але жодного разу не відновлювалися в умовах, наближених до реальних.
- Самописні скрипти замість бекап-рішення. Без контролю версій, без незмінності, без перевірок цілісності та процедур відновлення.
Важливо розуміти просту річ: бекап вважається існуючим лише тоді, коли з нього вдалося відновитися. Усе інше — припущення.
Мінімальний робочий стандарт: 3-2-1-1-0
Сьогодні мінімальним робочим стандартом є правило 3-2-1-1–0:
- 3 копії даних
- 2 різні типи носіїв
- 1 копія поза основною інфраструктурою
- 1 копія offline або immutable (air-gap)
- 0 помилок після перевірок відновлення
Без останніх двох пунктів бізнес фактично не готовий до ransomware — незалежно від того, скільки «копій» зберігається в тому самому контурі.
Чому відновлення часто не працює
Проблема не в технологіях резервного копіювання. А в тому, що бекап-інфраструктуру будують, виходячи з припущення: адміністратор завжди під контролем. У реальності ж саме адміністратор і його облікові дані стають головною ціллю атаки.
Immutable та air-gap — це не «модні слова» і не зайві витрати. Це останній рубіж, який працює навіть у сценарії, коли мережа скомпрометована, доступи втрачені, а інцидент уже стався.
Почати варто з простого запитання: чи можете ви сьогодні, зайшовши під основним адмінським обліковим записом, видалити резервну копію? Якщо відповідь «так», значить у разі атаки це зможе зробити й зловмисник.
Як Softline IT допомагає знизити ризики своїх клієнтів
У роботі з резервним копіюванням Softline IT виходить не з теорії, а з інцидентів, які вже сталися або могли статися. Наше завдання — не «поставити бекап», а зробити так, щоб у критичний момент бізнес реально міг відновитися.
Починаємо з аудиту. Дивимося, де саме знаходяться резервні копії, хто має до них доступ, у якому домені або контурі працює бекап-інфраструктура, чи можна видалити бекап з-під стандартних адміністративних облікових записів. Дуже часто вже на цьому етапі стає зрозуміло, що формально бекапи є, але фактично вони не захищені.
Далі розділяємо доступи і контури. Бекуп-сервери виводяться з домену, облікові записи мінімізуються, права доступу переглядаються. Там, де це можливо, ми прибираємо постійний мережевий доступ до сховищ і залишаємо його лише на час резервного копіювання.
Окремий акцент — на незмінності даних. Ми впроваджуємо immutable-бекапи або на базі об’єктних сховищ з object lock, або через захищені бекап-репозиторії. Це дозволяє гарантувати, що резервні копії не можна видалити або змінити навіть у разі компрометації адміністраторських доступів.
Ще один важливий елемент — логічний air-gap. Для клієнтів в Україні це зазвичай означає винесення однієї з копій у віддалений або хмарний контур з обмеженим вікном доступу. Такий підхід знижує ризик одночасного ураження продуктивної інфраструктури і резервних копій.
Ми також обов’язково перевіряємо відновлення. Налаштування автоматичних тестів, пробні розгортання, перевірка цілісності даних — без цього будь-який бекап залишається лише припущенням. Клієнт має знати не тільки, що копії створюються, а й за який час і в якому обсязі він зможе відновити роботу.
У підсумку клієнт отримує не набір інструментів, а зрозумілу модель: які дані захищені, від яких сценаріїв, з яким часом відновлення і з якими залишковими ризиками. Саме це, а не кількість копій чи назви продуктів, і є основою кіберстійкості.
