Резервні копії, стійкі до програм-вимагачів ── правило 3-2-1, сховище, яке не можна перезаписати, і перевірка відновлення

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

Ключових моментів три: мати одну копію, яку заражений ПК не може перезаписати, не використовувати «Попередні версії» замість резервних копій і перевіряти, що відновлення справді можливе. Правило 3-2-1 визначає кількість копій і місця їх зберігання, але саме по собі як захист від програм-вимагачів має прогалини.

Команди в цій статті призначені лише для Windows, а їхній вивід перевірено в командному рядку адміністратора у Windows Server 2022. Екрани налаштувань і ціни продуктів можуть змінюватися, тож під час упровадження звіряйтеся з найновішою документацією кожного постачальника.

Багато організацій мали резервні копії, але не змогли відновитися

Національне поліцейське агентство Японії розпитує організації, що постраждали від програм-вимагачів, про стан їхніх резервних копій. У звіті за перше півріччя 2025 року 51 із 53 організацій, що відповіли, робили резервні копії. Проте з 48 організацій, яких запитали, чи змогли вони з резервної копії відновити стан безпосередньо перед атакою, це вдалося лише 7, а 41 — ні¹.

Із 35 організацій, які назвали причину невдалого відновлення, 23 відповіли «резервні копії теж зашифровано», 8 — «недоліки в експлуатації», 4 — «інше»¹. У тому самому звіті сказано, що угруповання програм-вимагачів видаляють журнали та резервні копії жертв, щоб замести сліди й завадити відновленню. Звіт закликає організації зберігати резервні копії в офлайн-середовищі².

flowchart TB
        accTitle: Як можна мати резервні копії і все одно не відновитися
        accDescr: Схема показує, що навіть якщо ви робите резервні копії, вони шифруються разом з усім іншим, коли заражений ПК до них дістається, а якщо процедуру відновлення не перевірено, відновленню заважають недоліки в експлуатації.
        A["Резервні копії робляться"] --> B{"Чи дістається до них заражений ПК?"}
        B -->|"Дістається"| C["Їх теж шифрують або видаляють"]
        B -->|"Не дістається"| D{"Чи перевірено процедуру відновлення?"}
        D -->|"Не перевірено"| E["Відновлення не вдається через недоліки в експлуатації"]
        D -->|"Перевірено"| F["Відновлення можливе"]

Рисунок 1: Резервні копії придатні, коли заражений ПК до них не дістається, а процедуру відновлення перевірено.

Є й випадки, коли відновлення вдалося. У 4-му виданні документа IPA «Настанови з інформаційної безпеки для малого й середнього бізнесу» описано випадок будівельної компанії, чиї файлові сервери та інші системи зашифрували після проникнення через пристрій VPN. Зокрема тому, що компанія двічі на рік проводила навчання з відновлення, вона запустила основні системи з резервних копій через п’ять днів після виявлення атаки. Утім, на відновлення кожної внутрішньої системи пішло 41 день, на відновлення віддаленого доступу — чотири місяці, а компанія втратила понад 20 відсотків внутрішніх файлів³. Те, що з резервних копій можна відновитися, не означає, що збитки зникають.

На схемі суцільна лінія позначає зв’язок, що виконується завжди, а штрихова — умовний зв’язок (умови наведено в описі кожного зв’язку на сторінці докладних відомостей). Повний перелік зв’язків (усього 13, із підтвердженнями та рівнем достовірності) і визначення основних понять зібрано на сторінці докладних відомостей карти знань (японською). Дані: JSON-LD / Turtle

Зловмисники видаляють резервні копії, до яких можуть дістатися

Посібник #StopRansomware, виданий американським CISA та іншими відомствами, зазначає, що багато програм-вимагачів намагаються знайти доступні резервні копії й видалити або зашифрувати їх, щоб жертва не могла відновитися без сплати викупу. Тому посібник вважає важливим зберігати резервні копії офлайн⁴.

Microsoft також пише, що зловмисники зосереджуються на виведенні з ладу програм резервного копіювання та функцій ОС, як-от тіньових копій томів⁵. До резервних копій, до яких може дістатися заражений ПК, належать:

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

Тіньові копії та каталоги резервних копій можна видалити навіть вбудованими командами ОС. MITRE ATT&CK класифікує цю техніку як «Inhibit System Recovery» (T1490). Там наведено приклади, як-от видалення всіх тіньових копій командою vssadmin.exe delete shadows /all /quiet і видалення каталогу резервних копій Windows командою wbadmin.exe delete catalog -quiet⁶. Посібник CISA також закликає стежити за підозрілим використанням vssadmin.exe, wbadmin.exe, wmic.exe (shadowcopy) та подібних інструментів⁴.

flowchart TB
        accTitle: Резервні копії, до яких заражений ПК дістається і не дістається
        accDescr: Схема показує, що заражений ПК може записувати на постійно під'єднані зовнішні диски, у зіставлені спільні папки, папки синхронізації й тіньові копії, але не може записувати на від'єднані носії чи в сховище, яке не можна перезаписати.
        P["Заражений ПК"] --> R["Місця, куди він може записувати"]
        P -.-x N["Від'єднані носії, сховище, яке не можна перезаписати"]
        R --> A["Постійно під'єднаний зовнішній диск"]
        R --> B["Зіставлена спільна папка"]
        R --> C["Хмарна папка синхронізації"]
        R --> D["Тіньові копії"]

Рисунок 2: Резервні копії, що лежать там, куди заражений ПК може записувати, стають мішенню атаки.

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

«Попередні версії» не замінюють резервних копій

«Попередні версії» у Windows і тіньові копії спільних папок використовують службу тіньового копіювання томів (VSS). Системний постачальник VSS, що входить до Windows, використовує метод копіювання під час запису: перед перезаписом блока він зберігає його вміст в області відмінностей і так відтворює том на певний момент часу⁷.

У документації до VSS Microsoft пояснює різницю між тіньовою і резервною копією так. Коли дані з тіньової копії копіюють на знімний носій, наприклад стрічку, вміст цього носія стає резервною копією. Після копіювання саму тіньову копію можна видалити⁷. У документації також сказано, що коли місця в області відмінностей бракує, першими видаляються найстаріші тіньові копії⁷.

flowchart TB
        accTitle: Різниця між тіньовими копіями і резервними копіями
        accDescr: Схема показує, що тіньова копія — це набір відмінностей від вихідного тому, який видаляється через брак місця або зловмисником, тоді як резервна копія на окремому носії зберігається, навіть якщо вихідний том втрачено.
        V["Вихідний том"] --> S["Тіньова копія (відмінності)"]
        S --> L["Через брак місця видаляються від найстаріших"]
        S --> K["Зловмисник видаляє за допомогою vssadmin"]
        S -->|"Скопіювати на окремий носій"| B["Резервна копія"]
        B --> R["Зберігається, навіть якщо вихідний том втрачено"]

Рисунок 3: Тіньові копії залежать від даних вихідного тому; резервною копією стає те, що ви копіюєте на окремий носій.

Тіньові копії зручні, щоб користувачі самі відновлювали файли, які випадково перезаписали. Однак, як описано в попередньому розділі, зловмисники іноді їх видаляють. Механізм і експлуатацію детально пояснює стаття «Volume Shadow Copy (VSS): The Mechanism and the Practice» (англійською).

Щоб побачити, які тіньові копії лишилися, виконайте vssadmin list shadows у командному рядку адміністратора. Ця підкоманда доступна і в клієнтських, і в серверних системах⁸.

vssadmin list shadows

Журнал версій і кошик у OneDrive та SharePoint теж дають користувачам змогу повернути файли. Microsoft радить навчити користувачів відновлювати весь OneDrive на попередній момент часу. Також радить дозволяти користувачам відновлення лише тоді, коли ви впевнені, що зловмисника витіснено, і підготуватися до випадку, коли користувачі відновлять і шкідливу програму⁵.

Правило 3-2-1 визначає кількість копій і місця їх зберігання

Правило 3-2-1 — це емпіричне правило зберігання резервних копій. Документ «Data Backup Options», підготовлений 2012 року для US-CERT, пояснює його так⁹.

• 3: Зберігайте важливі файли у трьох копіях — оригінал і дві резервні копії.
• 2: Зберігайте їх на двох різних типах носіїв, щоб бути готовими до різних видів лиха.
• 1: Одну копію тримайте поза домом або компанією.

Як джерело документ називає книжку «The DAM Book» фотографа Пітера Крога про керування цифровими фотографіями⁹. Microsoft також згадує це правило у своїй документації про резервні копії для захисту від програм-вимагачів і описує «1» як «копію за межами майданчика або холодну копію»⁵.

Правило 3-2-1 вимагає тримати одну копію за межами компанії. Воно не вимагає, щоб ця копія була офлайн або незмінною. Тож якщо копія за межами компанії лежить у хмарі, куди заражений ПК може будь-коли записувати, її можуть зашифрувати разом із локальними копіями. Посібник CISA і документація Microsoft називають офлайн-зберігання захистом від програм-вимагачів. Microsoft також називає сховище, яке не можна перезаписати⁴⁵.

flowchart TB
        accTitle: Правило 3-2-1 і захист від програм-вимагачів
        accDescr: Схема показує доповнення правила 3-2-1 (три копії, два типи носіїв, одна копія за межами компанії) однією офлайн або незмінною копією і подальшу перевірку того, що відновлення можливе.
        A["Три копії"] --> B["Два типи носіїв"]
        B --> C["Одна за межами компанії"]
        C --> D["Одна офлайн або незмінна"]
        D --> E["Перевірити, що відновлення можливе"]

Рисунок 4: Доповніть правило 3-2-1 копією, яку заражений ПК не може перезаписати, і перевіркою, що відновлення можливе.

Виробник програм резервного копіювання Veeam популяризує це як «правило 3-2-1-1-0». У документації Veeam додаткова «1» означає мати одну копію, яка є офлайн, ізольованою повітряним проміжком (air gap) або незмінною, а «0» — нуль помилок під час регулярної перевірки відновлення¹⁰. Це назва з документації постачальника, а не офіційний стандарт. Проте два додаткові пункти збігаються з тим, чого вимагають CISA та IPA.

Майте одну копію, яку заражений ПК не може перезаписати

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

Від’єднайте носій від ПК і зберігайте окремо

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

Для організацій, які хочуть піти далі, настанови називають «фізичну ізоляцію». Це зберігання резервних копій у місці, фізично відокремленому від вихідної системи, і зберігання зовнішніх сховищ або резервних стрічок якомога далі. Як приклади місць зберігання наведено банківську скриньку або надійного ділового партнера чи пов’язану компанію¹².

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

Використовуйте хмарне сховище, яке не можна перезаписати

Хмарні сховища мають функції, що на заданий строк забороняють перезапис або видалення даних. Вони зберігають дані у стані, який називають WORM (Write Once, Read Many).

У незмінному сховищі Azure Blob Storage після налаштування політики зберігання на основі часу дані протягом цього строку можна створювати й читати, але не змінювати чи видаляти¹³. Політику спершу створюють у розблокованому стані, а після перевірки блокують. Заблоковану політику не можна видалити, а її строк зберігання можна подовжити, але не скоротити¹³. Microsoft пояснює, що змінювати чи видаляти дані не можуть навіть користувачі з правами адміністратора облікового запису¹³.

Amazon S3 Object Lock має два режими. У режимі відповідності (compliance) протягом строку зберігання ніхто, зокрема кореневий користувач облікового запису AWS, не може перезаписати чи видалити версію об’єкта. У режимі керування (governance) змінювати чи знімати налаштування зберігання можуть лише користувачі з особливими правами¹⁴. Object Lock можна використовувати лише в контейнерах (bucket) з увімкненим керуванням версіями S3¹⁴.

flowchart TB
        accTitle: Два приклади сховища, яке не можна перезаписати
        accDescr: Схема показує, що в незмінному сховищі Azure Blob Storage заблоковану політику не можна видалити, а строк зберігання — скоротити, і що в S3 Object Lock у режимі compliance не може видаляти навіть кореневий користувач, тоді як у режимі governance зміни дозволяють особливі права.
        W["Сховище, яке не можна перезаписати"] --> AZ["Незмінне сховище Azure Blob Storage"]
        W --> S3["S3 Object Lock"]
        AZ --> AZ1["Після блокування строк зберігання не скоротити"]
        S3 --> C["Режим compliance"]
        S3 --> G["Режим governance"]
        C --> C1["Навіть кореневий користувач не може видалити"]
        G --> G1["Особливі права дозволяють зміни"]

Рисунок 5: Обидва сховища на заданий строк відмовляють у перезаписі й видаленні; наскільки суворо — залежить від налаштувань.

Якщо в Azure ви помітите помилку в конфігурації вже після блокування політики, скоротити строк зберігання не вийде¹³. Посібник CISA зазначає, що деякі хмарні провайдери пропонують сховище, яке не можна перезаписати, і застерігає, що помилкова конфігурація може призвести до значних витрат. Також він згадує, що таке сховище може не відповідати вимогам певних регуляторних норм⁴. Якщо задати довгий строк зберігання і заблокувати його, видалити дані протягом цього строку не вийде, а плата за зберігання й далі нараховуватиметься. Почніть із розблокованого стану або короткого строку, перевірте, що відновлення можливе, і лише потім застосовуйте робочі налаштування.

Розділіть права на керування резервними копіями

Навіть якщо ви використовуєте сховище, яке не можна перезаписати, зловмисник може змінити налаштування й політики резервного копіювання, якщо їх можна змінити звичайним обліковим записом адміністратора. Microsoft радить перед зміною чи видаленням онлайн-резервних копій вимагати додатковий крок, наприклад багатофакторну автентифікацію або PIN-код безпеки. Також радить обмежити операції резервного копіювання й відновлення користувачами з визначеними ролями та зменшити кількість файлових ресурсів, де багато користувачів можуть записувати й видаляти⁵.

Навіть якщо ПК і резервними копіями керує одна людина, не використовуйте обліковий запис для керування місцем зберігання резервних копій для щоденного входу на ПК і захистіть його багатофакторною автентифікацією.

Зберігайте кілька поколінь

Настанови IPA називають «керування поколіннями», тобто зберігання резервних копій із кількох моментів часу. Це дає змогу в разі пошкодження або втрати даних повернутися до певного моменту¹². Як описано вище, якщо шифрування помічають не одразу, найновіші резервні копії вже міститимуть зашифровані дані. Скільки поколінь зберігати, визначайте з огляду на те, скільки часу може минути до виявлення шифрування, і на вартість зберігання.

flowchart TB
        accTitle: Три заходи, щоб мати копію, яку не можна перезаписати
        accDescr: Схема показує зберігання від'єднаних носіїв або використання сховища, яке не можна перезаписати, відокремлення прав на керування резервними копіями від звичайних облікових записів і зберігання кількох поколінь.
        A["Копія, яку не можна перезаписати"] --> B["Зберігати від'єднані носії"]
        A --> C["Сховище, яке не можна перезаписати"]
        B --> D["Розділити права на керування"]
        C --> D
        D --> E["Зберігати кілька поколінь"]

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

Перевірте, що відновлення можливе

У звіті Національного поліцейського агентства другою за поширеністю причиною невдалого відновлення були «недоліки в експлуатації»¹. Чи можна справді відновитися з резервної копії, не дізнаєшся, поки не спробуєш. Роботу, під час якої дані справді відновлюють із резервної копії, щоб це перевірити, називають тестом відновлення.

Настанови IPA поділяють роботу з резервними копіями на три частини: створення, зберігання й відновлення. Для відновлення вони радять скласти план відновлення і перевірити, що відновлення відбувається правильно³. Для критичних для бізнесу систем вони радять узгодити створення резервних копій і процедури з цільовим часом відновлення (RTO) і цільовою точкою відновлення (RPO) та перевірити їхню дієвість навчаннями. RTO — це час, потрібний для відновлення до цільового рівня, а RPO — момент, до якого відновлюють, тобто час найновішої резервної копії¹⁵. Посібник CISA також, з огляду на відновлення після аварій, закликає регулярно перевіряти, що резервні копії придатні й цілісні⁴.

flowchart TB
        accTitle: Як провести тест відновлення
        accDescr: Схема показує процес: визначити порядок відновлення, відновити в окреме середовище, порівняти витрачений час і відновлений момент із RTO та RPO і виправити робочу інструкцію.
        A["Визначити порядок відновлення"] --> B["Відновити в окреме середовище"]
        B --> C["Порівняти витрачений час із RTO"]
        B --> D["Порівняти відновлений момент із RPO"]
        C --> E["Виправити робочу інструкцію"]
        D --> E
        E -.->|"Наступна перевірка"| A

Рисунок 7: Спробуйте відновити, перевірте, чи відповідають час і момент цілям, і внесіть результати в робочу інструкцію.

Що перевіряти

На основі документації IPA та Microsoft те, що слід перевірити, можна узагальнити так.

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

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

Застереження щодо відновлення після атаки

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

flowchart TB
        accTitle: Порядок відновлення з резервної копії після атаки
        accDescr: Схема показує видалення самої програми-вимагача і шляху проникнення, вибір резервної копії з незараженого моменту, її перевірку на шкідливі програми і подальше відновлення спершу систем із найвищим пріоритетом.
        A["Видалити саму програму-вимагача"] --> B["Дослідити шлях проникнення і залишене"]
        B --> C["Вибрати незаражений момент"]
        C --> D["Перевірити резервну копію"]
        D --> E["Спершу відновити найвищий пріоритет"]

Рисунок 8: Після атаки приберіть те, що залишили зловмисники, і перед відновленням підтвердьте незаражений момент.

Як часто перевіряти

І настанови IPA, і посібник CISA радять «регулярно» перевіряти, що відновлення можливе, але не називають кількості¹¹⁴. Компанія з описаного вище випадку IPA проводила навчання з відновлення двічі на рік³. Визначте, як довго може стояти робота і наскільки давнім може бути відновлений момент, і перевіряйте з такою частотою, щоб підтвердити, що ви це виконуєте.

Що вирішити насамперед

Викладене можна підсумувати як те, що мала чи середня компанія має вирішити насамперед.

flowchart TB
        accTitle: Порядок ухвалення рішень щодо резервних копій, стійких до програм-вимагачів
        accDescr: Схема показує порядок: визначити охоплення, вирішити, де зберігати копії і яку копію неможливо перезаписати, вирішити щодо прав і поколінь, визначити RTO і RPO та перевірити, що відновлення можливе.
        A["Визначити охоплення"] --> B["Вирішити, де зберігати копії"]
        B --> C["Вирішити щодо копії, яку не можна перезаписати"]
        C --> D["Вирішити щодо прав і поколінь"]
        D --> E["Визначити RTO і RPO"]
        E --> F["Перевірити, що відновлення можливе"]

Рисунок 9: Ухваліть усі рішення в одній послідовності — від охоплення до фінальної перевірки, що відновлення можливе.

У 4-му виданні настанов IPA до «5 правил інформаційної безпеки», з яких починають організації, додано правило «Робіть резервні копії!», тож тепер їх 6¹⁶. Як працювати з настановами загалом, підсумовано в статті «Where Should SMEs Start on Security?» (англійською). Якщо плануєте заміну серверів, перегляньте також «Preparing for Windows Server 2016 End of Support» (англійською).

Пов’язані статті

• Where Should SMEs Start on Security? — A Walkthrough of IPA’s ‘Information Security Guidelines for SMEs,’ 4th Edition
• Volume Shadow Copy (VSS): The Mechanism and the Practice — Why Backup Software Can Copy Files That Are Still in Use
• Preparing for Windows Server 2016 End of Support

Посилання

Пов’язані статті

Найновіші статті зі спільними тегами. Поглиблюйте знання на близьких темах.

Пов’язані теми

Сторінки з близькими темами. Від статті можна перейти до пов’язаних послуг та інших матеріалів.

Послуги за цією темою

Ця стаття пов’язана з наведеними нижче сторінками послуг. Оберіть найближчу до вашого завдання.

Поширені запитання

Запитання, які найчастіше виникають під час консультацій на тему цієї статті.

Якщо я роблю резервні копії, чи зможу відновити все після зараження програмою-вимагачем?

Часто самого лише резервного копіювання для відновлення недостатньо. За даними про збитки, які Національне поліцейське агентство Японії узагальнило за перше півріччя 2025 року, 41 із 48 організацій, які робили резервні копії й відповіли, не змогли відновити стан безпосередньо перед атакою. Найчастішою причиною було те, що резервні копії теж були зашифровані. Потрібна копія, яку заражений ПК не може перезаписати, і треба перевірити, що з неї можна відновитися.

Якщо у Windows є попередні версії, чи потрібні мені ще резервні копії?

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

Чи достатньо дотримуватися правила 3-2-1 для захисту від програм-вимагачів?

Іноді ні. Правило 3-2-1 вимагає трьох копій, двох типів носіїв і однієї копії за межами компанії, але не вимагає, щоб копія за межами компанії була офлайн або незмінною. Копію в хмарі, куди заражений ПК може будь-коли записувати, можуть так само зашифрувати. Додайте одну копію на офлайн-носії або в сховищі, яке не можна перезаписати.

Як часто слід перевіряти, що з резервних копій можна відновитися?

І настанови IPA, і посібник CISA кажуть «регулярно» й не називають кількості. У настановах IPA описано випадок компанії, яка двічі на рік проводила навчання з відновлення і запустила основні системи через п'ять днів після виявлення атаки. Визначте, як довго може стояти робота і наскільки давнім може бути відновлений момент, і перевіряйте з такою частотою, щоб підтвердити, що ви це виконуєте.

Профіль автора

Сторінка з профілем автора статті.

Ґо Комура

Представник компанії KomuraSoft LLC

Працює переважно над розробкою ПЗ для Windows, технічними консультаціями та розслідуванням дефектів. Особливо сильна сторона — проєкти з наявними активами та розслідування збоїв з неочевидною причиною.