Резервне копіювання в хмарі: правило 3-2-1, RPO/RTO і копія, яку не зітре ransomware

Блог WebDisk · категорія: Безпека · час читання: ~9 хвилин

Коротко:- Синхронізація файлів – це не резервна копія: вона тиражує також і шкоду. Резервна копія має бути незалежною від оригіналу та стійкою до одного невдалого кліку.- Правило 3-2-1 (три копії, два різні носії, одна поза локацією) досі чинне; хмара закриває його найважчу ланку – копію поза межами компанії.- Резервна копія, яку ви жодного разу не відновлювали тестово, – це гіпотеза, а не захист. Тест відновлення планують так само серйозно, як і саме резервне копіювання.

Втрата даних рідко попереджає про свій прихід. Диск виходить з ладу без попередження, хтось перезаписує єдиний примірник договору, а ransomware шифрує все, до чого здатен дотягнутися, – разом із мережевими спільними ресурсами. Для компанії це означає простій, фінансові втрати, часто також втрату репутації, а буває, що й правові наслідки. Тому резервна копія перестала бути опцією – вона є фундаментом IT-безпеки. За однієї умови: що зроблена з розумом, а не «бо треба щось мати».

У цій статті ми впорядковуємо цей фундамент: чим резервне копіювання відрізняється від синхронізації, що насправді говорить правило 3-2-1, як перекласти скорочення RPO і RTO на рішення, зрозумілі для бізнесу, чому сучасний ransomware цілить насамперед у резервні копії – і чому тест відновлення є обов’язком, а не доброю практикою «колись потім». Пишемо для змішаної аудиторії: скористаються як одноосібна фірма, так і IT-команда, що складає аварійний план.

Синхронізація – це не резервне копіювання (і RAID теж ні)

Найчастіша ілюзія безпеки звучить так: «маю все в OneDrive/Dropbox, отже маю резервну копію». Не маєте. Синхронізація робить рівно те, що обіцяє назва: підтримує всюди той самий стан. Коли файл буде видалено, перезаписано або зашифровано програмою-вимагачем на одному пристрої, зміна слухняно попливе на всі інші. Версіонування, вбудоване в такі сервіси, буває порятунком для окремого документа, але не є планом відновлення компанії – воно не охоплює систем, баз даних чи конфігурацій і не має визначеної процедури повернення до роботи.

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

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

Правило 3-2-1: три копії, два носії, одна поза компанією

Класичне правило планування резервного копіювання вміщується у трьох цифрах: зберігай три копії даних (робочу плюс дві резервні), на двох різних типах носіїв або систем, з яких одну поза локацією, в якій працює компанія. Логіка проста: кожна ланка захищає від іншого сценарію. Друга копія рятує при відмові першої; інший носій – при ваді, спільній для всієї технології; копія поза компанією – при події, яка знищує цілу локацію: пожежі, затопленні, крадіжці, атаці, що охоплює локальну мережу.

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

Чесно варто додати: хмара є однією з ланок правила 3-2-1, а не його замінником. Копія виключно в одній хмарі – це й далі одна копія.

RPO і RTO по-людськи: скільки можете втратити і як довго можете простоювати

Два скорочення, які впорядковують кожну розмову про резервне копіювання:

• RPO (Recovery Point Objective) – скільки даних ви можете втратити, рахуючи назад від аварії. RPO – це на практиці відповідь на питання: «наскільки старою може бути остання копія, щоб із нею можна було жити?». Резервне копіювання раз на добу означає RPO 24 години – у найгіршому разі пропадає цілий робочий день.
• RTO (Recovery Time Objective) – як довго компанія може чекати на відновлення, перш ніж простій почне боліти по-справжньому. Це час від рішення «відновлюємо» до моменту, коли система знову працює.

Обидва значення визначають для кожної системи окремо, а не одне для всієї компанії. Архів документів витримає RPO, що рахується в добах; база замовлень інтернет-магазину – радше в годинах або хвилинах. Лише від цих чисел починається добір технічних рішень: частота копій, інкрементні копії (які записують лише зміни від попередньої копії – завдяки чому часте резервне копіювання не означає пересилання всього з нуля), пріоритети відновлення.

І одна річ, про яку рідко говорять рекламні матеріали: чим амбітніші RPO і RTO, тим вища вартість – частіших копій, більшого простору, швидшого каналу зв’язку. А реального RTO неможливо задекларувати: відновлення триває стільки, скільки дозволять обсяг даних і пропускна здатність. Тому RTO вимірюють у тестах, а не вписують у презентацію.

Ransomware насамперед шукає резервні копії

Сучасна атака ransomware рідко починається з шифрування. Зловмисник, який отримав доступ до інфраструктури, спершу роздивляється в ній – і методично вистежує резервні копії. Видаляє їх, шифрує або тихо псує, бо знає, що компанія зі справним резервним копіюванням не заплатить викуп. Лише потім шифрує продакшн.

Висновок із тисяч таких інцидентів: резервна копія, яку можна видалити тими самими правами, якими її записано, не є захистом від ransomware. Потрібна незмінна копія – записана в режимі WORM (write once, read many – «запиши раз, читай багато разів») – блокування, якого протягом заданого періоду не зніме жодним стандартним запитом ані зловмисник із захопленим обліковим записом адміністратора, ані помилковий скрипт, ані ми самі в поганий день. У світі сховищ S3 це реалізує механізм блокування об’єктів – ми детально описали його у статті про S3 Object Lock (WORM).

Наразі достатньо запам’ятати принцип: репозиторій резервних копій має бути незмінним протягом усього періоду зберігання, а доступ до нього – відокремленим від облікових записів, якими щодня адмініструють продакшн. У послузі WebDisk Backup копії потрапляють до нашого об’єктного сховища S3.

Чому object storage – це добра ціль для резервних копій?

Якщо копія має лежати поза компанією, кудись вона мусить фізично потрапити. Дедалі частіше цим місцем є object storage – об’єктне сховище з інтерфейсом S3, тобто стандартним API, яким сьогодні вміє говорити практично кожен інструмент резервного копіювання. Воно має властивості, які пасують до резервного копіювання винятково добре: простір докуповують у міру потреб, без інвестування наперед у дисковий масив, а версіонування та блокування об’єктів дають захист від перезапису й видалення.

Ми писали про нього ширше у статті про Object Storage у WebDisk; сховище побудоване на Ceph, відкритій платформі зберігання даних, і доступне через стандартні інструменти S3 (s3cmd, aws CLI, boto3). Те саме сховище, яке обслуговує застосунки, є також природною ціллю для резервних копій.

Від одного файлу до disaster recovery

Резервне копіювання в хмарі не обмежується документами. Файлові копії захищають вибрані каталоги систем Windows, Linux і macOS та дозволяють відновити окремий файл. Блокові копії охоплюють цілу операційну систему разом із конфігурацією, застосунками й базами даних – і саме вони відкривають шлях до disaster recovery, тобто аварійного плану відновлення роботи IT-систем.

Disaster recovery – це радше філософія, ніж технологія. Вона припускає, що аварія станеться напевно – питання не в тому «чи?», а «коли?» – тому наперед визначає, які послуги, в якій черговості та де буде запущено повторно. Резервне копіювання в хмарі є тут чимось більшим, ніж сховищем копій: середовище, відновлене з блокової копії, можна запустити як віртуальну машину в хмарі WebDisk – відновлені сервери спілкуються за тими самими внутрішніми адресами, що й до аварії. Компанія може працювати в хмарі, перш ніж відбудує власну інфраструктуру. Технічно це, зрештою, близький родич міграції середовища до хмари – тільки виконуваний під тиском, тому тим більше варто відпрацювати його заздалегідь.

Тест відновлення – це обов’язок, а не опція

Резервна копія, яку ніхто ніколи не відновлював, може виявитися непридатною саме тієї миті, коли буде найпотрібнішою, – а тоді вже пізно щось виправляти. Зелений статус «копію виконано» говорить лише про те, що щось записалося; він не говорить, що з цього можна повернутися. Мінімальний, повторюваний тест виглядає так:

1. Виберіть сценарій – окремий файл, база даних, цілий сервер. Тестуйте по черзі всі, а не лише найлегший.
2. Відновлюйте до ізольованого середовища, ніколи на продакшн – тест не може сам спричинити аварію.
3. Виміряйте час від старту до працюючої послуги. Це і є ваше реальне RTO – порівняйте його з припущеннями.
4. Перевірте узгодженість: система стартує, база відкривається, застосунок авторизує користувачів. «Файли скопіювалися» – це замало.
5. Задокументуйте процедуру крок за кроком і повторюйте тест циклічно (наприклад, щокварталу) та після кожної істотної зміни інфраструктури.

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

Чого резервне копіювання в хмарі не вирішує?

• Фізика каналу зв’язку. Перша повна копія і повне відновлення великого середовища тривають стільки, скільки дозволить інтернет. Інкрементні копії та дедуплікація (зберігання повторюваних блоків лише один раз) полегшують щоденність, але аварійний план мусить враховувати час повного відновлення – звідси цінність відновлення безпосередньо в хмарі, близько до даних.
• Резервна копія – це не архів. Резервна копія служить відновленню поточного стану; архів – багаторічному зберіганню відповідно до вимог законодавства. Вони мають інші періоди зберігання та інші витрати; плутання їх призводить або до прогалин, або до переплати.
• Незмінність захищає цілісність, а не конфіденційність. Копія WORM переживе атаку, але зловмисник із доступом може прочитати дані. За конфіденційність відповідає шифрування – у русі та у спокої; у WebDisk Backup копії шифруються вже на боці джерела й залишаються зашифрованими у сховищі.
• Хмара не звільняє від правила 3-2-1. Копія в хмарі – це одна ланка ланцюга; критичні дані й далі повинні мати більше ніж одну резервну копію.
• Технологія не замінить процедур. Розклад, період зберігання, моніторинг виконання та відпрацьоване відновлення так само важливі, як і саме сховище – саме вони відрізняють резервне копіювання від складу файлів.

Часті питання

Чи достатньо OneDrive або Dropbox як резервної копії компанії? Ні. Синхронізація тиражує поточний стан – також видалення й наслідки ransomware. Версіонування в таких сервісах рятує окремі файли, але не відновить сервера, бази чи конфігурації і не дає жодних гарантій щодо часу повернення до роботи.

У чому полягає правило резервного копіювання 3-2-1? Зберігай три копії даних (робочу плюс дві резервні), на двох різних типах носіїв або систем, з яких одну поза локацією компанії. Кожна ланка захищає від іншого сценарію – від відмови окремого пристрою до події, яка знищує цілу локацію. Резервне копіювання в хмарі закриває останню, історично найважчу ланку: копію поза компанією.

Що означають RPO і RTO? RPO (Recovery Point Objective) говорить, скільки даних ви можете втратити, рахуючи назад від аварії – резервне копіювання раз на добу означає RPO 24 години. RTO (Recovery Time Objective) – це час від рішення «відновлюємо» до моменту, коли система знову працює. Обидва значення визначають окремо для кожної системи, а реальне RTO з’ясовують у тестах відновлення, а не в деклараціях.

Як часто виконувати резервні копії? Так часто, як випливає з RPO даної системи: якщо втрата чотирьох годин роботи є прийнятною, резервного копіювання кожні чотири години достатньо; якщо ні – потрібні частіші інкрементні копії. Почніть із бізнесового питання «скільки ми можемо втратити?», а не з можливостей інструмента.

Чи може ransomware зашифрувати також резервну копію в хмарі? Може спробувати – і якщо репозиторій копій є звичайним ресурсом, доступним із повними правами з атакованої мережі, буває успішним. Тому репозиторій резервних копій має бути незмінним (WORM) протягом періоду зберігання та відокремленим від щоденних адміністративних облікових записів. Деталі механізму блокування об’єктів S3 (Object Lock) описуємо в окремій статті в блозі.

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

З чого почати, якщо сьогодні не маю жодної резервної копії? З інвентаризації: що є справді критичним? Визначте RPO і RTO для двох–трьох найважливіших систем, запустіть для них автоматичне резервне копіювання до локації поза компанією – і в перший місяць виконайте тест відновлення. Одна протестована резервна копія варта більше, ніж п’ять непротестованих.

Підсумок

Резервне копіювання в хмарі – це не окремий продукт, а стратегія: правило 3-2-1 визначає архітектуру, RPO і RTO перекладають її на мову бізнесу, незмінний репозиторій боронить копії від ransomware, а регулярний тест відновлення перетворює надію на перевірену процедуру. Хмара закриває в цій стратегії найважчі елементи – копію поза компанією та місце, в якому середовище можна запустити повторно після аварії.

Саме так ми побудували WebDisk Backup: файлові копії систем Windows, Linux і macOS, блокові копії серверів і віртуальних машин, а також резервне копіювання середовищ Kubernetes, засновані на рішеннях компанії Veeam, інкрементні та дедупліковані, зашифровані на боці джерела, збережені в нашому Object Storage – з можливістю відновлення цілого середовища як віртуальних машин у хмарі WebDisk. Хочете обговорити план резервного копіювання або тест відновлення у своїй організації? Напишіть до нас.