В ИТ любят слово «отказоустойчивость». Оно звучит инженерно и успокаивающе. Кластеры, зеркала, репликации — всё это создаёт ощущение контролируемости. Но последние десять лет показали неприятную вещь: большинство катастроф происходят не потому, что что-то сломалось, а потому что инфраструктуру целенаправленно уничтожили. Бла-бла-бла.

Сценарий повторяется с пугающей регулярностью. Злоумышленник получает административные привилегии, распространяется по сети, находит серверы резервного копирования, удаляет или шифрует копии — и только после этого атакует рабочие системы. Если компания не может восстановиться, она платит. Если может — выживает.

Разница между этими исходами — не в скорости дисков и не в количестве мгновенных снимков. Она в архитектуре доверия. Чтобы это понять, достаточно посмотреть на реальные истории.

Когда спасает случайность: Maersk и выключенный сервер

В 2017 году программа-вымогатель NotPetya уничтожила ИТ-инфраструктуру Maersk — одного из крупнейших мировых операторов контейнерных перевозок. Атака распространилась стремительно: контроллеры домена, серверы, рабочие станции — всё оказалось выведено из строя. Инфраструктура компании была распределённой, площадки синхронно обменивались данными. Именно это и сыграло роковую роль: вирус тиражировался вместе с репликацией.

Через несколько часов стало ясно: центральные ИТ-сервисы фактически уничтожены. Потери оценивались сотнями миллионов долларов. Но компанию спасла почти анекдотическая деталь — один контроллер домена в африканском офисе оказался отключён из-за перебоя электропитания и не успел заразиться. Этот «островок» стал отправной точкой для восстановления всей глобальной сети. Это был не продуманный план, а удача. Сервер случайно оказался в состоянии физического разрыва. Он был вне зоны поражения.

Если бы в архитектуре существовали изолированные резервные копии вне домена, хранилища с неизменяемыми копиями или офлайн-архивы, восстановление не зависело бы от географии и отключённого электричества. Maersk пережила катастрофу благодаря случайному АэроБарьеру. Но случайность — не стратегия, разумеется. Порадуемся за ребят.

Когда облако не равно защита: исчезновение Code Spaces

В 2014 году компания Code Spaces, предоставлявшая хостинг репозиториев, полностью полагалась на облако Amazon Web Services. Инфраструктура была виртуальной, гибкой, современной. Но она находилась в одной учётной записи.

Когда злоумышленник получил доступ к панели управления, всё произошло предсказуемо. Были удалены виртуальные машины, снэпшоты, резервные копии и объекты в S3. Компания пыталась вести переговоры, но процесс удаления продолжался. Через несколько дней стало ясно: восстановиться невозможно. Code Spaces объявила о закрытии. Здесь не было вируса, который распространялся сам. Был один скомпрометированный домен доверия. Вся инфраструктура — производственная сфера и бэкапы — существовала в одной логической плоскости. Удаление оказалось административной операцией, а не технической проблемой.

Можно ли было изменить исход? Да. Достаточно было вынести резервные копии в отдельную учётную запись с независимой аутентификацией, включить режим неизменяемого хранения данных, запрещающий удаление объектов до окончания срока хранения, хранить ключи отдельно и иметь отчуждённую копию вне облака. Облако не подвело компанию. Её подвела архитектура.

Когда компания отказывается платить: опыт Norsk Hydro

В 2019 году норвежский промышленный гигант Norsk Hydro подвергся атаке программой-вымогателем LockerGoga. Были заражены тысячи систем, производство оказалось частично парализовано. Но компания публично заявила: выкуп платить не будет. Восстановление заняло время. Часть процессов временно перевели в ручной режим. Однако данные не были утрачены.

Разница с Code Spaces была не в масштабе атаки, а в глубине подготовки. Сегментация сети, изоляция резервной инфраструктуры и наличие проверенных копий сделали шифрование болезненным, но не фатальным.

Это важный момент: катастрофоустойчивость не означает отсутствие ущерба. Она означает возможность восстановления без капитуляции.

Частичный паралич без гибели: случай Garmin

В 2020 году Garmin столкнулась с атакой программой-вымогателем WastedLocker. Сервисы были недоступны несколько дней, пострадала внутренняя инфраструктура. По сообщениям следователей, атакующие пытались повлиять и на резервные системы.

Тем не менее компания восстановилась. Причина была не в чудесной скорости ИТ-отдела, а в том, что копии не находились в той же зоне доверия, что и рабочая среда. Доступ к основному домену не означал автоматического уничтожения резервных данных.

Garmin потеряла время, но не потеряла бизнес.

Общий вывод, который неочевиден

Во всех этих историях поражает одно: технологии высокой доступности почти не влияют на исход. Репликация, зеркалирование, географическое распределение — всё это помогает при отказах оборудования. Но при злонамеренной атаке эти механизмы могут работать против владельца, мгновенно тиражируя разрушение.

Выживают не те, у кого быстрее каналы связи. Выживают те, у кого есть разрыв.

Этот разрыв может быть логическим — в виде хранилища с неизменяемыми копиями, где данные нельзя удалить до истечения срока хранения. Он может быть организационным — когда администратор домена не имеет прав на уничтожение резервных копий. Он может быть физическим — когда носитель просто извлечён и хранится вне сети.

Примечательно, что в истории Maersk роль «ленты» сыграл выключенный сервер. Он не был подключён. Его нельзя было заразить удалённо. Именно так работает физическое отчуждение: простое отсутствие соединения оказывается сильнее любой криптографии.

Технологии против катастрофы

Современные системы хранения позволяют включать режим неизменяемости объектов, при котором данные нельзя удалить или изменить до окончания установленного срока хранения. Это программная реализация принципа WORM — «одна запись — множественное чтение». Даже если злоумышленник получит административный доступ, удаление будет технически невозможно.

Разделённое хранение данных в облаке создаёт второй слой изоляции. Рабочая область и резервные копии существуют в разных учётных записях, с разной аутентификацией и разными административными доступами. Компрометация одного аккаунта не уничтожает второй.

Наконец, офлайн-архивы — например, ленточные носители с физическим извлечением — создают абсолютный АэроБарьер. Их нельзя зашифровать через программный интерфейс, удалить скриптом — они требуют реального доступа.

Эти решения выглядят избыточными до первого инцидента. После него они превращаются в единственное реальное преимущество: возможность не вступать в торг с вымогателями и просто сказать «нет».

Многоуровневая модель защиты

В современных стратегиях защиты резервных копий существует несколько уровней, которые помогают справляться с разными угрозами.

На первом уровне — мгновенные снимки и быстрая репликация — мы защищаемся от поломки отдельного сервера и технических сбоев.

Второй уровень отвечает за ошибки администратора: отдельный сервер резервного копирования и изолированная учётная запись позволяют не удалить случайно важные данные.

На третьем уровне стоят меры против программ-вымогателей: неизменяемые копии, ограничения доступа и раздельная аутентификация делают невозможным мгновенное уничтожение резервов, даже если злоумышленник получил права администратора.

Наконец, уровень «Судного дня» включает офлайн-копии, независимое хранение ключей и пошаговый план восстановления с нуля. Этот уровень позволяет восстановить всю инфраструктуру, даже если рабочие системы и основной домен доверия уничтожены полностью.

Это защита от «всё уничтожено».

Минимальный набор против «апокалипсиса»

  • Есть изолированный сервер резервного копирования.

  • Есть неизменяемые копии.

  • Есть офлайн-копия.

  • Есть независимая аутентификация.

  • Ключи хранятся вне рабочих систем.

  • Проводятся регулярные тесты восстановления.

  • Есть документированный план восстановления.

  • Возможен запуск инфраструктуры с нуля.

Если хотя бы два пункта отсутствуют — архитектура уязвима.

Без иллюзий

Главный урок последних лет состоит в том, что резервное копирование — это не сервис для удобства администраторов. Это механизм стратегического выживания.

Если резервную копию можно удалить с помощью тех же учётных записей, что управляют рабочими системами, она не выполняет свою защитную функцию.

Если она реплицируется теми же каналами — она уязвима.

Если она находится в том же домене доверия — она разделяет его судьбу.

Реальные катастрофы показали: защищает не скорость восстановления, а глубина изоляции.

Сценарий «Судного дня» уже случался — у глобальных логистических компаний, облачных стартапов, промышленных гигантов. Одни потеряли сотни миллионов, другие — сам бизнес. Разделяло их не наличие бэкапа как такового, а его архитектура.

И вопрос, который должен задать себе любой архитектор, звучит просто: «Если завтра инфраструктура будет полностью скомпрометирована — останется ли что-то вне зоны поражения?»

Если ответ неочевиден, значит «Судный день» уже встроен в проект. Что скажете?