Як це працює: детально та з прикладами

Ландшафт загроз змінився. Сучасні оператори ransomware (шифрувальників) більше не атакують «в лоб». Стандартний сценарій атаки включає приховану присутність у мережі (dwell time), підвищення привілеїв, горизонтальне переміщення (lateral movement) і — як обов’язковий етап — знищення резервних копій перед початком шифрування.

Ось кілька свіжих цифр, щоб показати глибину проблеми. Поточного року, за даними аналітиків, кожна четверта організація (24%) зіштовхнулася із кібер-вимаганням. При цьому репозиторії бекапів зазнають атак майже завжди (96% випадків), й у 2/3 випадків (76%) ці атаки досягають мети. У відповідь дедалі більше організацій переглядають свої підходи до кібербезпеки — за останніми даними 62% компаній уже застосовують незмінювані (immutable) резервні копії, а 82% мають розгорнуті плани Disaster Recovery.

Незмінюваність як необхідність

Проблема полягає в тому, що традиційна архітектура резервного копіювання, де репозиторії керуються тими самими обліковими записами, що й продуктивне середовище, стала вразливою. Якщо адміністративний доступ скомпрометовано, видалення копій займає хвилини. Відповідь індустрії на цей виклик — перехід до концепції Zero Trust Data Management, фундаментом якої є Immutable Backups (незмінювані копії) та Hardened Repository (посилений репозиторій).

Незмінюваність резервних копій слід розглядати не як опцію ПЗ, а як ізольований шар зберігання даних. Технічно це реалізація принципу WORM (Write Once, Read Many) — технології, за якої дані записуються до сховища лише один раз і надалі доступні тільки для читання). Система фіксує блоки даних на заданий період (Retention Policy). Протягом цього строку жодні операції модифікації або видалення неможливі на рівні файлової системи або API об’єктного сховища. Навіть маючи root-права або доступ до консолі керування резервним копіюванням (Veeam Backup & Replication та ін.), зловмисник отримає відмову в доступі при спробі видалити файл.

Це забезпечує захист як від зовнішніх, так і від внутрішніх загроз безпеці. У першому випадку хакер, навіть якщо отримує контроль над доменом і сервером бекапів, не зможе очистити репозиторій; у другій ситуації — власний зловмисний співробітник з правами адміністратора не зможе знищити дані компанії.

Подібні механізми захисту неодноразово доводили свою цінність у реальних інцидентах. Один із поширених сценаріїв — після компрометації домену зловмисники починають масово видаляти або перезаписувати резервні точки. На звичайних сховищах ці операції проходять майже миттєво. У проєктах, де застосовувалася immutable-політика, ситуація розвивалася інакше: копії залишалися доступними, і відновлення виконувалося вже з ізольованого середовища, незалежно від стану продакшну.

Сьогодні такі вимоги трапляються у дедалі більшій кількості проєктів, адже якщо резервний контур можна модифікувати через стандартний адміністративний доступ, це означає, що під час серйозної атаки він буде знищений одним із перших. Політики незмінюваності розв’язують цю проблему на рівні самої платформи зберігання, що й робить підхід дуже ефективним в умовах реальних загроз.

Але! Важливо розуміти, що незмінюваність резервних копій мінімізує (майже до нуля), але не повністю виключає ризики втрати даних. Навіть найсучасніші WORM-рішення та hardened-репозиторії можуть бути вразливими у разі незапланованих збоїв обладнання, помилок мікропрограмного забезпечення або некоректного оновлення резервного ПЗ.

Теоретично можливий й «форсований обхід» за фізичного доступу та низькорівневої маніпуляції із системою зберігання (наприклад, прямий доступ до блочного пристрою, перепрошивка контролера тощо). Але це майже неймовірний сценарій.

Крім того, ефективність залежить від правильності налаштувань: помилкові значення або недостатній строк зберігання можуть призвести до автоматичного видалення життєво важливих копій до моменту виявлення атаки або збою. Системний підхід до аудиту налаштувань і регулярного оновлення політик зберігання є вкрай важливим для запобігання подібним інцидентам.

Технічна реалізація захисту

Важливо розуміти різницю між Immutable Backup і Hardened Repository. Перша технологія відповідає за незмінюваність самих даних — це WORM-логіка, що фіксує копії на заданий строк і блокує будь-які операції видалення або модифікації. Hardened Repository, своєю чергою, захищає середовище, де ці дані зберігаються: мінімізує поверхню атаки, виключає інтерактивний доступ, прибирає постійні адміністративні облікові дані й працює як ізольований вузол (appliance). Перший шар забезпечує недоторканність резервних копій, другий — робить сховище недоступним для атакувальника. Разом вони закривають два різні класи загроз.

Якщо незмінюваність (Immutable) захищає дані, то Hardened Repository — саму платформу зберігання. Це спеціалізована конфігурація, що мінімізує поверхню атаки (attack surface). В архітектурі De Novo ми використовуємо підхід, заснований на трьох базових принципах:

• Ізоляція прав доступу. Репозиторій працює на базі Linux із застосуванням Single-use credentials. Облікові дані для доступу до сховища використовуються лише в момент розгортання компонентів (Data Mover), після чого не зберігаються в системі резервного копіювання.
• Вимкнення векторів віддаленого керування. Після розгортання репозиторій переводиться в режим single-purpose appliance: забезпечується виконання лише сервісних процесів, необхідних для роботи Veeam Data Mover, а будь-які засоби віддаленого адміністрування (включно з SSH) вимикаються на рівні конфігурації та мережевого стеку. Таким чином усуваються інтерактивні канали керування — репозиторій функціонує як ізольований компонент, а не як повноцінний Linux-хост, доступний для експлуатації вразливостей.
• Immutability Flag. Використовуються файлові системи з підтримкою WORM-механізмів, зокрема XFS з immutable-атрибутами, поверх яких Veeam вмикає власний Retention Lock. Ця комбінація працює на двох рівнях — файлова система блокує зміну об’єкта, а шар Veeam фіксує саму retention-політику, не дозволяючи адміністратору скоротити строк зберігання копій. Навіть отримавши доступ до процесів резервного ПЗ, зловмисник зіткнеться з відмовою вже на рівні ядра та заблокованою політикою зберігання.

Ось як це працює на практиці:

Сценарій 1: Зловмисник скомпрометував сервер керування бекапами та надіслав API-запит на видалення ланцюжка резервних копій. Результат: операцію відхилено репозиторієм. Відновлення розпочато негайно.

Сценарій 2: Експлуатація вразливості в сервісі моніторингу (RCE). Хакер потрапив усередину периметра, але не зміг розвинути атаку на репозиторій, оскільки сервіси працювали в обмеженому середовищі, а інтерактивний shell був недоступний.

Ще один типовий приклад — спроба використати вразливість у застарілій версії OpenSSH, встановленій за замовчуванням в одній зі старих інфраструктур. Під час переходу на hardened-модель така поверхня атаки зникла: зайві сервіси було вимкнено, а доступ залишався лише у сервісних процесів, що працюють у строго заданому режимі. Навіть якби атака відбулася, прав для видалення даних усе одно не було б.

Hardened-репозиторій добре працює у зв’язці з незмінюваними копіями: перший обмежує доступ до операцій, другий фіксує вміст. Разом вони формують шар, який зберігає працездатність навіть у тих випадках, коли продакшн-компоненти повністю скомпрометовані. Завдяки цьому резервний контур перестає залежати від стану домену, гіпервізорів або адміністративних систем — і витримує інциденти, які раніше вважалися критичними.

Порада №1

Для максимальної надійності роботи резервного контуру рекомендується впроваджувати регулярні аудити та автоматизовану звітність про стан копій, а також інтегрувати процеси керування резервним копіюванням із корпоративними політиками інформаційної безпеки. Особливу увагу слід приділяти процедурам керування обліковими даними, автоматизації оновлень ПЗ резервного копіювання, а також детальному документуванню змін в інфраструктурі. Типова помилка впровадження — зберігання облікових даних (credentials) у скриптах автоматизації або недостатня ізоляція адміністративних мереж, що може звести нанівець усі зусилля з побудови захищеного резервного шару.

Порада №2

Для об’єктивної оцінки ефективності резервного контуру доцільно впроваджувати визначені KPI — такі як частка успішно відновлених даних, середній час відновлення сервісів (RTO), кількість виявлених аномалій під час тестових відновлень (SureBackup) і частота аудитних перевірок політик зберігання. Також вкрай важливо забезпечити рольову взаємодію між командами кібербезпеки, експлуатації та бізнесу — щоб реакція на потенційні інциденти була максимально швидкою й узгодженою.

Інтеграція з ПЗ Veeam: верифікація як частина процесу

Наявність «зеленої галочки» у звіті про створення бекапу не гарантує успішного відновлення. Логічні збої файлових систем, «биті» блоки або некоректна робота застосунків можуть зробити резервну копію марною. Ми інтегруємо механізми автоматичної валідації Veeam (SureBackup) у стандартний процес обслуговування. Зокрема, проводяться регулярні перевірки цілісності даних на рівні низькорівневих блоків сховища (CRC Check), тобто сканування блоків на предмет прихованих пошкоджень (bit rot) або збоїв дискової підсистеми. Також обов’язково й ретельно тестується процес відновлення — автоматичний запуск віртуальних машин в ізольованій «пісочниці» з перевіркою старту ОС, запуску мережевих інтерфейсів, відгуку застосунків тощо.

Приклади з практики

Функція SureBackup особливо корисна для систем із розподіленими залежностями — баз даних, сервісів із зовнішньою автентифікацією, застосунків, що працюють у кластерних топологіях. В одній з інфраструктур резервне копіювання завершувалося без помилок, але під час підняття в «пісочниці» SQL-сервер не проходив ініціалізацію через некоректне завантаження драйвера після чергового оновлення. У продуктиві цей дефект був непомітним завдяки кешуванню та постійній зв’язаності сервісів, але під час відновлення призвів би до критичної затримки. Виконання SureBackup заздалегідь дозволило усунути проблему до інциденту.

В іншому розборі з’ясувалося, що резервні ланцюжки кількох критичних сервісів містили пошкоджені блоки через збій у контролері сховища. Візуально все виглядало коректно: точки створювалися вчасно, консоль не показувала відхилень. Але періодична валідація від Veeam підняла прапор під час спроби монтування вмісту. Пошкодження усунули, обладнання замінили, а команда безпеки зробила з цього стандартну практику: кожне критичне навантаження має проходити перевірку відновлення, а не просто створювати резервні файли.

Подібні випадки трапляються частіше, ніж здається. В інфраструктурах зі складною віртуалізацією або розподіленими ресурсами час від часу виникають помилки на рівні драйверів, мережевих шляхів, контролерів або самих застосунків. І якщо контур перевірки відсутній, такі дефекти залишаються невидимими аж до моменту реального відновлення. Після інтеграції з Veeam багато компаній уперше побачили, які сервіси піднімаються коректно, а які потребують коригування параметрів або перебудови ланцюжків.

Коли процес тестування стає частиною архітектури, з’являється розуміння, який час реально займе відновлення, які сервіси мають «приховані слабкі місця» і які налаштування потрібно уточнити заздалегідь.

Резервний контур як сервіс

Досвід показує, що якщо резервний контур керується так само, як і продуктив, він падає першим. Стратегія De Novo полягає у створенні архітектурного розриву між середовищем замовника та системою зберігання копій. Ми пропонуємо модель, у якій реалізовано три найважливіші аспекти захисту:

• Інфраструктурна ізоляція: Репозиторії розташовані поза доменом безпеки клієнта (Off-site backup). Компрометація Active Directory замовника жодним чином не впливає на доступність архівів.
• Гарантована незмінюваність: Політики Immutable налаштовуються на боці провайдера і не можуть бути вимкнені адміністраторами клієнта (захист від людського фактора та захоплення облікових записів).
• SLA на відновлення: Ми перетворюємо бекап із «набору файлів» на керований сервіс із прогнозованим часом відновлення (RTO).

В умовах сучасних кіберзагроз Immutable Backup і Hardened Repository — це фактично той «гігієнічний мінімум», який гарантує, що у бізнесу завжди залишиться «чиста» копія даних, до якої не дотягнеться жоден шифрувальник, навіть якщо він отримав повні права у вашій основній мережі.