Я работаю в компании-интеграторе, и в числе прочего мы проектируем, внедряем и сопровождаем инфраструктурные решения, в том числе системы резервного копирования. За последние годы мы все чаще сталкиваемся с тем, что бэкапы перестают быть просто ИТ-задачей и становятся полноценным элементом кибербезопасности.
На практике, при целенаправленной атаке под угрозой оказываются не только продуктивные системы, но и сами резервные копии. Если злоумышленник получает доступ к инфраструктуре, он почти всегда пытается уничтожить или зашифровать бэкапы в первую очередь. В таких сценариях классические схемы резервного копирования перестают выполнять свою основную функцию — обеспечивать восстановление.
Один из подходов, позволяющих защитить резервные копии даже при попытке взлома основной инфраструктуры — резервное копирование с воздушным зазором, или air gap backup. Это метод хранения данных, при котором копии размещаются на носителях или системах, изолированных от сети и недоступных для прямого удаленного доступа.
И здесь идея air gap проста: нельзя повредить или украсть то, к чему невозможно подключиться. Несмотря на то, что технологию придумали еще наши деды, она остается актуальной – особенно в условиях роста числа атак. В этой статье разберем, зачем нужен airgap, какие варианты его эксплуатации существуют и каких случаях он действительно оправдан.
Что такое Air gap backup
Система резервного копирования является последней линией защиты данных. Если ничего не помогает – идут за резервными копиями. Но с появлением программ-вымогателей все стало сложнее. Ведь одно дело – авария (электричество, погода, ошибка – не важно), и совсем другое – умный противник, основная цель которого – уничтожение всех ваших данных.
Такой противник обязательно уничтожит и резервные копии, если доберется до них. Получается, что резервные копии теперь тоже надо защищать. Airgapbackup как раз придуман для того, чтобы ваша последняя линия обороны выстояла даже в случае злонамеренного нападения на ИТ-инфраструктуру.
Air gap backup (или резервное копирование с «Воздушным зазором») — это отделение резервных данных от любых общедоступных сетей. То есть создание «воздушной стены» между данными и точками доступа, уязвимыми для хакеров, для изоляции их друг от друга.
Основные преимущества air gap backup:
защита от атак программ-вымогателей (ransomware);
предотвращение потери данных и обеспечение непрерывности бизнеса;
соблюдение требований сompliance и минимизация рисков ответственности.
А есть ли проблема?
Согласно Verizon 2025 Data Breach Investigation Report,
44% нарушений кибербезопасности приходилось на атаки с использованием программ‑вымогателей (ransomware), что на 37% больше, чем в предыдущем году;
медианная сумма выплат злоумышленникам составила $115000;
В принципе, можно и без Verizon сходу припомнить публичные случаи порчи корпоративных данных, в том числе и в крупных отечественных компаниях. Причем потери оцениваются десятками и сотнями миллионов рублей, а целями может являться даже не шантаж или кража данных, а их уничтожение само по себе.
Конечно, air gap не поможет вам предотвратить утечку данных. Но, будучи правильно интегрированным в вашу стратегию резервного копирования (и DR-стратегию), он однажды может спасти вашу компанию.
Как реализовать air gap
Если не погружаться в излишнюю детализацию, есть три пути:
Логическое разделение
Cloud
Физическое разделение
Каждый способ имеет свои плюсы и минусы. Давайте их и рассмотрим.
1. Логическое разделение
Логически изолированные тома хранения могут создаваться с помощью программных разделов и сегментации сети как разновидности виртуализации хранилища.
Самая главная проблема, что такая изоляция наименее безопасна. Ну и, пожалуй, единственный плюс – простота и дешевизна. Могу предположить, что логическое разделение будет уместно как временное обходное решение или в случае если влияние рисков потери данных оценивается невысоко. Вариант реализации – СХД с WORM функционалом.
1. Cloud air gap
Облачные air gap‑решения представляют собой изолированные среды, которые управляются провайдерами сервисов резервного копирования. Организации отправляют резервные данные в облако, после чего провайдер размещает их в неизменяемом хранилище на логически изолированных томах (air-gapped). Такая организация защиты данных обладает всеми плюсами и минусами облачного хранения.
С одной стороны, вы получаете перевод CAPEX в OPEX, частично перекладываете ответственность на провайдера и существенно увеличиваете гибкость и расширяемость решения.
С другой стороны, для организации облачного air gap требуется учесть достаточно много нюансов. Например:
Нормы и требования регуляторов (наличие у провайдера необходимых лицензий).
Ваши политики – ИБ и не только.
Связность и доступность. Что с каналами? Как они защищены?
Тарифы провайдера. Особенно те, что пишут мелким шрифтом. Встречаются довольно неожиданные моменты, вроде платы за траффик DNS.
Ожидаемую и реальную производительность. Они часто отличаются – надо тестировать
Доступность. Записать скорее всего вы сможете быстро. А вот насколько оперативно сможете достать эти данные – часто зависит от тарифа.
Я в 2000-х часто слышал, что облака, это как электричество – воткнул в розетку и получаешь сервис. Так вот в 2026 году уже понятно, что это совсем не так. Для того, чтобы получить эффективный по цене и качеству сервис, его придется спроектировать внедрить и обслуживать.
Как ни странно, облачный air gap я считаю самым сложным технически вариантом «воздушного зазора».
2. Физическое разделение
Физические air gap-решения реализуются путём полного отключения носителей от любых устройств с сетевым подключением. Для физического air gap резервный том нужно извлечь из системы и разорвать все проводные и беспроводные соединения.
Несколько air gap‑томов могут быть связаны между собой проводной или беспроводной связью, но, если к любому из них есть доступ извне, ни один из них нельзя считать действительно изолированным.
Физический можно реализовать двумя способами:
· Отдельные носители
Сюда относятся внешние жёсткие диски, дискеты, ленты. Из этого всего, наверное, только ленты можно считать более-менее зрелым решением. В 2025 году делать архивы в вручную можно разве что дома. И то, если у вас не много данных.
· Специализированные СХД
Очевидно, что такие СХД должны в первую очередь отличаться не столько скоростью, сколько ценой за гигабайт и надежностью хранения. Помимо дедупликации и компрессии (must have), должны присутствовать также технологии защиты от выхода из строя как минимум 2 дисков в RAID. А еще крайне желательны мгновенные снимки и механизмы, обеспечивающие сетевую изоляцию, чтобы не заниматься переносом данных вручную.
Резюмирую:
Физические air gap самые простые с технической точки зрения реализации решения. Если вам требуется физический air gap, то у вас есть 2 варианта – ленточное хранение (со всеми плюсами и минусами лент), или СХД с функционалом, который позволит обеспечить надежные и эффективные изоляцию, надежность и при этом оптимальная по стоимости.
Важное в конце
В заключение хочется подчеркнуть следующее.
Air gap backup – это часть политики резервного копирования, которая является частью политики непрерывности бизнеса и катастрофоустойчивости. Она не является ни бэкапом, ни DR-решением, но дополняет и то, и другое.
Air gap СХД – это не Immutable СХД. Immutable СХД обычно основан на технологии WORM (Write Once, Read Many — «один раз записать, много раз прочитать», способе хранения данных, при котором после записи их нельзя изменить или удалить (навсегда или в течение заданного периода). Такие файлы можно просматривать, но нельзя редактировать или перезаписывать.
Ключевое различие между Immutable (WORM) СХД и air gap backup связано не с форматом хранения файлов, а с тем, где и как это хранилище размещено. Данные в резервной копии air gap, как правило, являются неизменяемыми, но само по себе immutable‑хранилище не обязательно изолировано и может находиться на устройстве с сетевым доступом.
А для того, чтобы неизменяемый бэкап считался air‑gapped, он должен быть логически или физически отделен от сети.
Вместо заключения
Air gap backup — технология не новая, но именно сейчас она снова становится актуальной. Рост числа атак на резервные копии заставляет по-новому смотреть на архитектуру хранения данных и на роль бэкапа в целом.
Интересно узнать, как вы реализуете защиту резервных копий у себя: используете ли air gap? А для бэкапов? Добро пожаловать в комментарии :-)
Комментарии (23)
KorP
20.01.2026 08:52Что-то из текста я так и не понял, как "специализированные схд" (я так понимаю под ними подразумеваются DD и SO) позволяют обеспечить физическое разделение, у котором идёт речь выше!?
GoogleBoom Автор
20.01.2026 08:52Ну, как минимум есть особенности.
Вам нужно достаточно дешевое хранение. Не на NVMe точно. И технологии оптимизации очень не помешают.
Изоляцию обеспечить не так уж и просто. Выше был комент про IPMI. Вам нужно придумать, как вы делаете резервные копии, и как вы их храните вне сети. Руками каждый раз разрывать связь - не вариант. Значит нужна автоматизация.
Угроза изменилась. Раньше бэкап был средством защиты от сбоя или аварии. Причем непреднамеренного сбоя или аварии. То есть достаточно было его хранить там, где его не затронет, например, пожар в DC. И не было проблем, если он был в сети - пожар по интернету не распространяется. А теперь нужно данные защищать уже от намеренного уничтожения. Зловред - не пожар. Ваши архивы для него тоже цель.
То есть да, СХД, как устройство, может быть общего назначения. А вот СИСТЕМА (в смысле информационная система хранения архивных данных в Вашей инфраструктуре) становится специализированной.
uuger
20.01.2026 08:52Вспоминая вид серверной, залитой ржавой водой из некорректно настроенной системы пожаротушения:
air gap должен быть действительно gap, а не галочкой в настройках гипервизора/схдGoogleBoom Автор
20.01.2026 08:52От пожара вам поможет просто репликация в другое место. Не нужно усложнять себе жизнь, если ваша угроза - пожар или наводнение. Air gap backup - это от другой угрозы.
uuger
20.01.2026 08:52предлагаете делать по одному виду бэкапа на каждый из видов угроз?
GoogleBoom Автор
20.01.2026 08:52Нет конечно! Но Air gap - не замена того бэкапа, который у вас уже есть. Это дополнение.
PetyaUmniy
20.01.2026 08:52тома хранения могут создаваться с помощью... сегментации сети как разновидности виртуализации хранилища.
Что это значит?
Почему тома? Тома - термин из области блочных устройств.
А если хранение делается на уровне файлов, например в s3? Не подходит?
Правильнее бы звучало - репозитории.Логическое разделение
такая изоляция наименее безопаснаИз чего это следует?
Если я делаю чисто логическое разделение, ставлю перед своим storage backend простой (а значит ожидаемо надежный и безопасный), опенсорсный, массово используемый (оттестированный) сервис, который все что только и делает - обеспечивает безопасность: разрешает пользователю user_1 ходить в storage_backend_1, а user_2 в соотвественно _2 и т.д.
Например:Использую на источниках данных в качестве утилиты бекапа restic.
-
А на сервере хранилище:
rest-server (его storage через rest api) отдельный инстанс для каждого клиента, с настройками append only, смотрящий в свой единственный бекенд репозиторий.
и nginx перед всеми инстансами для acl, т.е. разрешения юзерам обращаться только к своему rest-server -> своему storage backend.
Тогда я сделал что-то сильно небезопасно?
Но ведь чтобы утверждать такое, нужно сначала признать что такое жутко обкатаное ПО как nginx небезопасно. И злоумышленик вместо того чтобы начать ломать банки через этот небезопасный nginx, вклиниваясь в их трафик (т.е. с очень понятной и маштабируемой моделью монетизации), решил ломать какой-то богом забытый nginx в моей внутреней сети...Это разумеется невероятно.
Гипотетические риски такой небезопасности просто меркнут на фоне практической гиганской кривизны и забагованости проприетарного, особенно местячкового (т.н. импортозамещерованного), ПО, которое подчастую используется для ЫнтырПрайс бекапа... и в том числе прямо следующей из перечисленного небезопасности.Физическое разделение
Это вообще сомнительная история из мира идеалистов, у которых только крайности.
Причем им невероятно важны только те крайности которые они сами заметили. А то что на практике неразрывно с крайностями в одном вагоне едет еще и гора недостатков. Это идеалистам всеравно, это не тешит их воспаленное самолюбие (я сделал все идеально - "царь во дворца").А недостатки совершенно понятны:
Бекапы на отделенном (отсоединенном) от сети хранилище нужно таким же "отсоединенным" образом (=руками) выполнять и тестировать.
метрики что бекапа, что тестирования бекапа нужно "отсоединенным" (=руками) образом доставлять в единую систему мониторинга.
И вот мы на практике получаем: мы разменяли гипотетическую (сугубо идеалистическу) безопасность отключеных бекапов, на человеческий фактор их (бекапов) выполнения...
Что тут еще сказать?
Занавес.GoogleBoom Автор
20.01.2026 08:52Что это значит?Почему тома? Тома - термин из области блочных устройств.А если хранение делается на уровне файлов, например в s3? Не подходит?Правильнее бы звучало - репозитории.
Русское слово "Том" является прямым переводом английского слова Volume. И это никакого отношения не имеет к тому, какое у вас устройство - блочное, файловое или объектное, типа S3.
Похоже, что термин "репозиторий" применительно к S3 ввели в Amazon. Но я достаточно стар, чтобы помнить времена, когда Amazon был магазином книжек и делал только робкие попытки продавать ихз через Интернет. И вот тогда репозитории уже вполне себе существовали. Например Linux репозитории - это то место, откуда мы пакеты берем. И никакого отношения к СХД они не имели.
Последнее время люди вообщще очень вольно к терминам относятся... /немного песка посыпал ))/
Из чего это следует?
Если я делаю чисто логическое разделение, ставлю перед своим storage backend простой (а значит ожидаемо надежный и безопасный), опенсорсный, массово используемый (оттестированный) сервис, который все что только и делает - обеспечивает безопасность: разрешает пользователю user_1 ходить в storage_backend_1, а user_2 в соотвественно _2 и т.д.
Например:Использую на источниках данных в качестве утилиты бекапа restic.
-
А на сервере хранилище:
rest-server (его storage через rest api) отдельный инстанс для каждого клиента, с настройками append only, смотрящий в свой единственный бекенд репозиторий.
и nginx перед всеми инстансами для acl, т.е. разрешения юзерам обращаться только к своему rest-server -> своему storage backend.
Тогда я сделал что-то сильно небезопасно?
Но ведь чтобы утверждать такое, нужно сначала признать что такое жутко обкатаное ПО как nginx небезопасно. И злоумышленик вместо того чтобы начать ломать банки через этот небезопасный nginx, вклиниваясь в их трафик (т.е. с очень понятной и маштабируемой моделью монетизации), решил ломать какой-то богом забытый nginx в моей внутреней сети...Это разумеется невероятно.
Гипотетические риски такой небезопасности просто меркнут на фоне практической гиганской кривизны и забагованости проприетарного, особенно местячкового (т.н. импортозамещерованного), ПО, которое подчастую используется для ЫнтырПрайс бекапа... и в том числе прямо следующей из перечисленного небезопасности.Ухх... Opensource - это значит, что за код вообще никто не несет ответственности, и какие там дыры - вы просто не знаете. Поэтому да, вы сделали что-то сильно небезопасное.
Но, опять таки, все решает ваша толерантность к риску. Если ваши данные легко восстановимы или просто не очень дорогие, то Opensource - отличный выбор! Он может быть отличным выбором даже если у вас очень важные данные. Но только если это НЕ все, на что вы полагаетесь при их защите.
А недостатки совершенно понятны:
Бекапы на отделенном (отсоединенном) от сети хранилище нужно таким же "отсоединенным" образом (=руками) выполнять и тестировать.
метрики что бекапа, что тестирования бекапа нужно "отсоединенным" (=руками) образом доставлять в единую систему мониторинга.
И вот мы на практике получаем: мы разменяли гипотетическую (сугубо идеалистическу) безопасность отключеных бекапов, на человеческий фактор их (бекапов) выполнения...
Что тут еще сказать?
Занавес.Не все так печально. Можно и автоматически ))
Ну и не отменяет это необходимости в online бэкапе. Я ж специально в конце написал - это не замена, а дополнение к политике резервного копирования и DR.
uuger
20.01.2026 08:52Opensource - это значит, что за код вообще никто не несет ответственности, и какие там дыры - вы просто не знаете.
а за проприетарный софт несут прям дофига отвественности и вы знаете какие там дыры?
GritsanY
20.01.2026 08:52Немного побрюзжу - в моей практике термин Air Gap использовался исключительно для последнего способа - физическая невозможность получить доступ с одного сегмента в другой. Это и дата-диоды, и сникернет. А название Air Gap как бы противопоставляется другим, логическим/виртуальным способам разделения. Называть виртуальную изоляцию или Cloud Sync разновидностью Air Gap только маркетолог может.
GoogleBoom Автор
20.01.2026 08:52Air gap - это довольно радикальный метод. И нет ничего удивительного, что люди ищут такие реализации, которые и риски снизят, и хоть какую-то гибкость дадут. Самый надежный сервер, как известно - тот, который выключен в сейфе.
Все решает модель угроз компании и ее толерантность к риску.
Deosis
20.01.2026 08:52А если развернуть логику бекапов?
То есть не пользователь инициирует процедуру, а сервер подключается к пользовательскому компьютеру и выкачивает данные?
Теперь сервер можно переместить в отдельную подсеть с запретом входящих подключений.
GoogleBoom Автор
20.01.2026 08:52А что это меняет? Заберет сервер с пользовательского компьютера вирус. Тот зашифрует все, что есть на сервере...
Deosis
20.01.2026 08:52Так сервер не запускает на исполнение все полученные от пользователя данные.
Или вы считаете, что вирусы как органические, попав в память, размножатся и испортят все данные?
Bagatur
20.01.2026 08:52Ну, скажем, вопросы сохранности резервных копий в некоторых случаях уже даже присутствует в регуляторной документации и требования обязательны к исполнению. В частности, для банков РК есть требование хранения, как минимум, одного полного комплекта резервных копий ключевых систем оффлайн, в ячейке другого банка.
То, что касается снижения риска повреждения резервных копий, хранящихся в самой организации - ну, тут тоже вопросы даже логического разделения имеют значение. Условно - есть система хранения на лентах, есть, скажем, CommVault, который сам "тащит" бэкапы из гипервизоров, доступ к консоли системы резервирования крайне ограничен (надеюсь, не надо напоминать, что консоли управления оборудованием должны быть выведены в отдельную менеджмент подсеть, доступ к которой из общих сегментов закрыт, и которая не имеет свободного выхода в интернет?). Уже в данном случае риск повреждения резервных копий снижается, и снижается прилично.
select26
Интересная идея!
В качестве средства изоляции можно добавить в скрипт резерного копирования включение портов коммутатора (или еще лучше - LACP интерфейса) и отключение после окончания процесса копирования. Мониторинг NAS в любом случае остается доступен через IPMI.
Спасибо за статью!
Cas_on
Если есть доступ по IPMI, значит есть полноценный доступ к данным (в большинстве систем).
GoogleBoom Автор
Вы правы. Если злоумышленник получает доступ к IPMI - это все-равно, что физический доступ получить.
Статья задумывалась как обзорная. В детали специально не погружались. Может быть отдельно напишем про именно техническую реализацию.
Bagatur
Если у вас ipmi/idrac/ilo вообще доступен из общей сети - это уже очень плохо. Хорошая практика для менеджмент операций - отдельный vlan, отдельная подсеть, отсутствие маршрутизации между общим и менеджмент сегментами, ещё лучше - и отдельный комп для управления (вариант - использование Hop сервера или PAM с 2FA/MFA). И крайне желательно, при возможности, - ограничение подключений к серверам по ssh/rdp на уровне локальных файрволлов серверов. И да, ограничения на подключение в настройках ipmi etc. тоже совсем не лишни.
Alekseyz
Это давно реализовано и прекрасно работает. Включение устройства через WOL и выключение после того как закончится репликация
sansar
буквально на днях...одно хранилище для бэкапов(отключается от сети самостоятельно дергая питание коммутора) подключилось во время работы ransomware и было им поедено, второй сборщик(этот переносной и тупо wifi включает/выключает) подключился сильно позже и успешно обновил устаревшие бэки новым уже мусором.
и как бы несколько копий и аир гап, но при определенном стечении обстоятельств этого мало