Ілюстрація: Black in UA
Як і в попередній історії, це збірний сценарій — типова ніч, яку фахівці Black in UA бачать у практиці десятки разів на рік. Компанії різні, галузі різні. Помилка — майже завжди одна й та сама.
Системний адміністратор отримує автоматичне сповіщення про аномальне навантаження на файловому сервері вночі. Відкладає до ранку, йде спати.
Вранці стає зрозуміло: зашифровано базу 1С, бухгалтерські архіви, сканкопії договорів за три роки. У текстовому файлі README_RESTORE.txt — вимога у криптовалюті та дедлайн 72 години.
На питання «де бекап?» — три різні відповіді від трьох людей. З’ясовується: «бекап» — це та сама шафа/той самий сервер у тій же локальній мережі, який теж зашифрувало разом з оригіналом.
«У нас є бекап» і «наш бекап відновлюється» — два різні твердження. Друге перевіряють одиниці власників компаній.
Єдина копія була в тій же мережі — і зашифрувалась разом з оригіналом. Вибір: платити викуп без гарантій або відновлювати бізнес з нуля. Дні простою, втрачені клієнти, розмова з банком про відстрочку кредиту.
Існує офлайн-копія поза мережею. ІТ-команда відновлює дані з холодної копії за кілька годин, записку з README ігнорують. Простій відновлення замість кризи.
| Тип бекапу | Захищає від поломки/крадіжки | Захищає від шифрувальника в мережі |
|---|---|---|
| Локальний NAS у тій же мережі | Так | Ні |
| Звичайний хмарний бекап (без ізоляції) | Так | Частково |
| Офлайн / air-gapped копія | Так | Так |
| Immutable-хмарний бекап | Так | Так |
Ручний бекап рано чи пізно пропускають — відпустка, завантаженість, звичайна людська забудькуватість. Автоматичний розклад прибирає цей ризик повністю.
Копіювання за розкладом (щодня або частіше для критичних даних) із збереженням кількох попередніх версій дозволяє відкотитися не лише до вчора, а й до моменту до зараження, яке могло статись непомітно за кілька днів до шифрування.
Автоматичне сповіщення про невдалий або пропущений бекап важливіше за сам факт його налаштування — без моніторингу «зламаний» бекап можуть не помічати місяцями.
Шифрувальник, потрапивши в мережу, намагається зашифрувати все, до чого дотягнеться, включно з підключеними мережевими дисками та бекап-сховищами.
Копія, яка фізично відключена від мережі більшість часу (зовнішній накопичувач, окремий сегмент мережі), недосяжна для шкідливого ПЗ, яке поширюється мережею.
Хмарні сховища з режимом незмінності не дозволяють видалити або перезаписати файл протягом заданого періоду, навіть якщо зловмисник отримав облікові дані адміністратора.
Резервна копія теж містить чутливі дані — і теж потребує захисту.
Шифрування бекапу на рівні сховища захищає дані навіть у разі крадіжки фізичного носія або компрометації хмарного акаунта постачальника послуг.
💡 Перевіряйте відновлення, а не наявність
Бекап, який жодного разу не відновлювали на практиці — це теоретичний бекап. Планова перевірка відновлення — обов’язкова частина плану, а не опція.
RTO (Recovery Time Objective) — скільки часу компанія може простояти без систем. RPO (Recovery Point Objective) — скільки даних вона готова втратити з моменту останнього бекапу. Ці два числа визначають, наскільки часто і як швидко має відбуватись відновлення.
Якщо компанія може дозволити собі втратити не більше одного дня даних (RPO = 24 години) і простій не довший півдня (RTO = 12 годин), бекап має відбуватись щонайменше раз на добу, а процедура відновлення — бути відпрацьована так, щоб вкладатись у ці півдня.
Тестове відновлення на окремому середовищі — єдиний спосіб дізнатись, що бекап справді працює, до того, як він знадобиться в реальній кризі.
Пошкоджений файл, застарілий формат, відсутній доступ до ключа шифрування — усе це виявляється лише в момент спроби відновлення, а не в момент створення копії.
Письмова інструкція «що робити в перші години після виявлення шифрування» економить найдорожчий ресурс під час кризи — час на роздуми.
Заздалегідь визначена людина або підрядник, яка ізолює заражені системи від мережі, повідомляє керівництво і запускає процедуру відновлення — без цього перші критичні хвилини йдуть на пошук відповідального.
⚠️ Оплата викупу не гарантує повернення даних
За оцінками галузі, частина компаній, які заплатили викуп, так і не отримали повного доступу до даних або стали повторною ціллю тих самих зловмисників. Надійніша стратегія — не опинятись на переговори з вимагачами, а мати робочу копію, яка дозволяє взагалі їх ігнорувати.
Залежить від обсягу даних, кількості систем і вимог до швидкості відновлення. Black in UA робить аудит і підбирає рішення під конкретний розмір і бюджет, а не продає однакове рішення всім.
Сам по собі — ні. Синхронізація — не бекап: якщо шифрувальник зашифрує файл локально, цей стан синхронізується в хмару. Потрібна версійність та ізоляція від автоматичної синхронізації змін.
Щонайменше раз на квартал — тестове відновлення на окремому середовищі, а моніторинг успішного завершення самого бекапу — щодня.
Негайно ізолювати заражені пристрої від мережі (вимкнути Wi-Fi/кабель), не вимикати сам пристрій до консультації з фахівцем, повідомити відповідального за IT або підрядника з кібербезпеки і почати відновлення з ізольованої копії.
Це рішення без гарантованого позитивного результату і поза межами технічної консультації — оплата не гарантує розшифрування, а лише підтверджує зловмисникам, що атака рентабельна. Найкраща стратегія — унеможливити саму цю дилему за допомогою робочого бекапу.
Ваш бекап дійсно відновлюється?
Black in UA перевіряє вашу схему резервного копіювання та будує схему, яка витримає реальну атаку шифрувальника, а не тільки виглядає надійно на папері.