Подписаться
Читать в телеграм
В реалиях цифровой экономики данные компаний — один из наиболее ценных активов, который находится под постоянной угрозой. Число глобальных кибератак с использованием программ-вымогателей (ransomware), особенно шифровальщиков, продолжает расти, как и их сложность. Так, согласно исследованию аналитической фирмы Comparitech, в 2025 году оно увеличилось на 32%, а в опросе компании Veeam Software 89% организаций заявили, что целью хакеров были репозитории резервных копий. Кроме того, безопасности данных угрожают сбои оборудования и непреднамеренные ошибки сотрудников.
В таких условиях классические подходы к резервному копированию уже не работают, а его система (СРК) из обычного хранилища файловых копий превращается в важнейший и последний оборонительный рубеж. Теперь это не просто инструмент для копирования данных, а комплексное решение, которое обеспечивает способность восстановить всю ИТ-инфраструктуру — от операционных систем и приложений до бизнес-процессов. Ни один другой ее элемент не воскресит данные после атаки шифровальщиков — СРК защищает их именно от логической порчи.
Концепция «Last Resort Backup» (резервная копия последней надежды) выходит в ИТ-тренды, потому что подразумевает создание не просто еще одной копии, а защищенного, проверенного и изолированного бэкапа. Он заточен под то, чтобы выжить, даже когда пробиты все предыдущие уровни защиты. И порой СРК требует большей устойчивости, чем продуктивные системы, причем обеспечивать ее нужно, принимая как технические, так и организационные меры.
О том, почему у компаний возникает ложное чувство защищенности и какие практики построения СРК самые эффективные, рассказали на прошедшей конференции IT Elements эксперты компании «Инфосистемы Джет».
СРК как залог непрерывности бизнеса
Компании до сих пор уповают на то, что наличие резервных копий само по себе является залогом быстрого и успешного восстановления данных, и такая позиция формирует ложное чувство защищенности. Однако в случае атаки обычные копии оказываются бесполезны, потому что они были доступны для записи из скомпрометированной продуктивной сети.
«Хорошая СРК существует не просто потому, что “так надо”. Она базируется на принципах эшелонированной защиты и глубокой интеграции с ИБ-процессами. Тем не менее в корпоративных ИТ-инфраструктурах СРК по-прежнему сводят к утилитарной функции, тогда как она, наоборот, играет ключевую роль в аварийном восстановлении и обеспечении непрерывности критичных бизнес-процессов, зависящих от сложной взаимосвязи данных, учетных записей, сетевых настроек и конфигураций серверов».
Игорь Шконда,
руководитель направления систем резервного копирования компании «Инфосистемы Джет»
Лучшие практики построения СРК
Если разложить систему резервного копирования на фреймворк 3P (персонал, процессы и продукты), то, обозревая именно технические практики, формирующие многоуровневую защиту, стоит сфокусироваться на продуктах — в частности, на неизменяемых хранилищах.
Первую практику следует взять за правило: резервные копии и компоненты управления СРК должны быть полностью изолированы от продуктивной среды. Если последняя скомпрометирована (зашифрован или удален продуктив), восстанавливать будет не с чего и нечего, а бизнес-процессы придется строить практически с нуля.
Следующая практика заключается в расширении схемы резервного копирования со стандартной «3-2-1» до «3-2-1-1-0». Иными словами, нужно иметь три копии данных (3), две из них хранить на разных носителях (2), одну сделать отчуждаемой и хранить в отдельном знании (1) (еще лучше — в другом районе города), а еще одну — неизменяемой или расположить ее в изолированной среде (1) и иметь ноль ошибок при периодических тестовых восстановлениях (0).
Трафик компонентов системы резервного копирования лучше отделить от трафика данных — в идеале на уровне физических интерфейсов, чтобы усложнить злоумышленнику доступ к компонентам СРК.
«Еще одна полезная практика заключается в принципе минимальных привилегий на основе ролевой модели. То есть не следует давать операторам СРК права администраторов СРК. Также не следует интегрировать интерфейс управления СРК, как и операционные системы мастер- и медиасерверов СРК, с корпоративной службой каталогов (например, Active Directory), потому что она все чаще становится точкой уязвимости и приоритетным объектом атаки. Преступник получает учетные записи администраторов домена и администраторов СРК, доступ к бэкапам, а дальше — дело техники. В СРК нужно использовать только локальные учетные записи с неповторяющимися паролями. В крупных компаниях, с большим количеством пользователей СРК, имеет смысл организовать отдельную изолированную службу каталогов, никак не связанную с корпоративной».
Олег Кандальцев,
старший инженер-проектировщик систем хранения данных компании «Инфосистемы Джет»
При построении системы резервного копирования важно помнить о концепции Air Gap — так называемого воздушного зазора между бэкапами и основной сетью. Он может быть физическим (самый простой) — подразумевающим отчуждение ленточных картриджей, которые предназначены для хранения большого объема данных. Его создание гарантирует восстановление после аварии. Но поскольку ленточные библиотеки пока не представлены в реестре Минпромторга, можно использовать логический Air Gap: его реализуют в объектных хранилищах с помощью технологий WORM (Write Once, Read Many) и Object Lock, которые на определенный срок делают данные неизменяемыми, защищают их от перезаписи и удаления.
Несомненно, стоит упомянуть о ключевой роли актуальной документации и о тестовом восстановлении СРК. Наличие схем инфраструктуры и регламентов резервного копирования будет очень кстати в случае аварии — их не придется придумывать заново. Регулярное документирование и тестовое восстановление всей системы или бизнес-процесса — единственный способ проверить работоспособность резервных копий. Это трудозатратный процесс, однако он точно окупится в случае реальной атаки.
«Разумеется, обязательно нужно настроить многофакторную аутентификацию (MFA) для всех учетных записей, имеющих доступ к системе, а также проводить логирование и постоянный мониторинг аномалий в СРК. К ним относят, например, массовое удаление данных, изменение политик резервного копирования или попытки доступа с неавторизованных хостов. Современные системы могут включать проактивную защиту (Active Protection) от действий шифровальщика».
Игорь Шконда,
руководитель направления систем резервного копирования компании «Инфосистемы Джет»
В уровнях отказоустойчивости дата-центров заказчикам помогают ориентироваться так называемые классификации инженерной инфраструктуры. В мире таких классификаций несколько, самыми известными на базе стандартов являются ISO/IEC 22237 c делением на Class 1–4, ANSI/TIA-942 c делением на Rate 1-4, а также справочный документ частной американской консалтинговой компании Uptime Institute c делением на Tier I-IV. При этом модели и методики хоть и отличаются, но в отношении отказоустойчивости четыре категории по смыслу гармонизированы друг с другом. Так, если центры обработки данных начального класса 1 при поломке отключаются, то ЦОД категории 4 продолжает работать в отказоустойчивой топологии.
СРК как Last Resort: кейсы
Концепция Last Resort реализуется, когда все остальные превентивные меры оказались бесполезными. Рассмотрим несколько соответствующих кейсов. Представим атаку Ransomware: домен скомпрометирован, серверы зашифрованы, ключи доступа украдены, а обычные резервные копии, хранившиеся на локальном диске и сетевой шаре, тоже зашифрованы или удалены.
Тестовые данные содержатся в текстовых файлах Word и Excel. Резервные копии данных создаются с помощью СРК «Кибер бэкап». Три резервные копии данных размещены в разных хранилищах: узел хранения (локальное хранилище), CIFS-шара (сетевое хранилище) и «Кибер хранилище» (объектное хранилище S3 с включенным Object lock). Общий объем данных — примерно гигабайт. Вирус-шифровальщик скомпилирован в exe-файл. При запуске на узле хранения резервных копий он получает доступ к сети, компрометирует домен, повышает привилегии доступа к файловой системе, сначала шифрует все файлы резервных копий (локальных, сетевых, объектных), затем — непосредственно продуктивные данные, а в финале выводит на экран сообщение с требованием выкупа.
Резервные копии в локальной папке уничтожаются безвозвратно. Восстановление может проходить по двум сценариям: через Object Lock на объектном хранилище либо через снапшоты тома сетевой папки.
В первом сценарии используется защищенная от изменения (на настраиваемый период времени) копия (immutable backup), хранящаяся в объектном хранилище с включенным версионированием и Object Lock и режимом Compliance.
«Даже если злоумышленник попытается перезаписать бэкап с Object Lock, своим действием он создаст новую версию объекта. При этом исходная защищенная и незашифрованная версия может быть просто восстановлена поверх новой зашифрованной. Благодаря этому можно реконструировать практически всё — от отдельных файлов до инфраструктуры в целом».
Олег Кандальцев,
старший инженер-проектировщик систем хранения данных компании «Инфосистемы Джет»
Непосредственно восстановление можно выполнять вручную, применяя S3-клиент, но лучше написать несложный скрипт-восстановитель с использованием S3 API: в цикле сначала ищется незашифрованная версия каждого объекта в хранилище по времени создания резервной копии, затем эта версия копируется поверх зашифрованной в новую версию, которая делается текущей, и, после восстановления всех объектов, с помощью СРК «Кибер бэкап» восстанавливаются исходные данные. Также можно восстановить файл в объектном хранилище, где включено версионирование без Object Lock, удалив последнюю версию объекта. Однако если вирус-шифровальщик обнаружит, что Object Lockотсутствует, он может сразу после шифрования безвозвратно удалить первую, незашифрованную версию этого объекта. Неизменяемые копии в объектном хранилище с версионированием и технологией Object Lock остаются нетронутыми.
Во втором сценарии для тома с CIFS-шарой делается снапшот на СХД сразу после бэкапа. После того как эта CIFS-шара будет зашифрована, можно сделать откат тома на этот снапшот и получить таким образом незашифрованные резервные копии. Однако важно понимать, что снапшот лишь дополняет бэкап и формируется вручную, а делать его вручную после каждого бэкапа нереально. Если создавать снапшоты скриптом, высока вероятность ошибок в случаях, когда не удалится предыдущий снапшот перед бэкапом или когда снапшот не успеет вовремя сформироваться: например, если до завершения предыдущего бэкапа начнется следующий бэкап, то при откате на этот снапшот из резервной копии ничего не получится восстановить, так как она останется незавершенной.
Кроме того, следует помнить: если злоумышленник получит административный доступ к интерфейсам управления серверов (через IPMI), на которых построено объектное хранилище, или к интерфейсу управления СХД с резервными копиями, то он сможет легко уничтожить любые данные безвозвратно — например, удалив пул в СХД или подменив загрузчик на ОС серверов и записав произвольные данные на их тома. Поэтому необходимо либо предусмотрительно отключать кабели от этих интерфейсов, либо подключать их напрямую в один компьютер управления, не связанный с сетью.
RPO + RTO + восстановимость = зрелость ИТ
На способность ИТ-инфраструктуры к восстановлению непосредственно влияют ключевые метрики реальной устойчивости бизнеса — RPO и RTO.
RPO (Recovery Point Objective) — это целевая точка восстановления, то есть максимальный период времени, за который могут быть потеряны данные в случае сбоя. Например, если это два часа, то компания должна делать бэкапы как минимум каждые два часа, чтобы ущерб не стал критичным.
RTO (Recovery Time Objective) — целевое время восстановления систем после аварии. Максимальный период, в течение которого они могут находиться в нерабочем состоянии.
«Несмотря на установленные метрики, у многих компаний, даже при наличии бэкапов, восстановление может занимать недели. Это происходит потому, что отсутствуют практики тестирования сбоев и восстановления. Соответственно, не хватает документации, и это приводит к неподготовленности сотрудников. Только регулярные тесты позволяют стремиться к заявленным RTO и RPO, определяют устойчивость ИТ-процессов в компании и ее готовность к реальной кибератаке».
Игорь Шконда,
руководитель направления систем резервного копирования компании «Инфосистемы Джет»
В условиях роста киберугроз, которые еще и постоянно совершенствуются, СРК становится стратегическим активом, от которого зависит выживание бизнеса при практически любой нештатной ситуации — от ошибки сотрудника до мощной кибератаки. И как показывает практика, единственный по-настоящему ценный бэкап — это тот, который спроектирован с учетом возможной катастрофы. 
