
В 2025 году мировые потери от киберпреступности, по оценкам отраслевых аналитиков, превысили один триллион долларов США — "это ж сколько стран можно было прокормить?!".
В подавляющем большинстве случаев речь идёт об атаках программ-вымогателей. И в каждом таком инциденте рано или поздно возникает один и тот же вопрос: существует ли копия данных, до которой злоумышленник не сможет добраться?

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

Исторически воздушный зазор использовался в военных системах, где цена компрометации была критической. Компьютеры, управляющие стратегическими объектами, не подключались к интернету. Данные переносились на носителях под строгим контролем.
В корпоративной ИТ-среде долгое время воздушный зазор реализовывался примитивно: ленты с резервными копиями вынимались из библиотеки и отправлялись в сейф. Это действительно создавало изоляцию, но сопровождалось сложной логистикой, человеческим фактором и риском повреждения носителей при хранении в ненадлежащих условиях. Кроме того, в ряде отраслей отчуждение носителей с персональными данными требует дополнительного согласования с регуляторами. Современные ленточные библиотеки переосмыслили эту модель. Воздушный зазор перестал быть операционной процедурой и стал встроенным механизмом.
Как это реализовано у нас
Рассмотрим принцип действия АэроБарьера на примере наших ленточных библиотек, название которых мы пока не пишем (добираем заветную карму). Он прост, как и всё гениальное. Ленты в библиотеке размещаются в магазинах — модулях, которые роботизированная система может извлекать и возвращать в слоты. В обычном режиме робот перемещает картриджи между слотами и приводами, обеспечивая чтение и запись.

При активации блокировки от шифровальщиков магазин частично выдвигается из корпуса. Он остаётся зафиксированным механически, но его положение таково, что механическая система захвата картриджей в роботе не может быть программно отпозиционирована, чтобы робот мог управлять картриджами. Именно ограничитель фиксирует магазин в полуизвле-чённом состоянии и не позволяет ему двигаться. Он показан на фото — такое незамысловатое приспособ-ление обеспечивает надёжную защиту данных (и немножко магии, разумеется).
Робот «видит» штрих-коды через сканер. Система управления отображает наличие лент. Администратор может дистанционно провести инвентаризацию. Но ни одна команда из сети не способна заставить робот преодолеть физический зазор. Чтобы вернуть магазин в рабочее положение, оператор должен подойти к библиотеке и вручную вставить его обратно.

Чтобы предотвратить случайное попадание магазина в библиотеку, предусмотрен «режим удержания». Если поставить галочку в соответствующих настройках, то, в случае случайной загрузки защищенного магазина, он снова отщёлкнется обратно. Чтобы всё сработало, администратор должен нажать на кнопку «вставить магазин» в веб-интерфейсе библиотеки, на магазине замигает индикатор, после чего оператор, физически присутствующий возле библиотеки, должен его вставить. То есть не только администратор без оператора не может сделать картридж снова доступным, но и оператор без администратора на это не способен. Таким образом АэроБарьер реализуется внутри одного устройства, без выноса носителей за пределы дата-центра, но с сохранением ключевого свойства — недоступности для удалённого воздействия.
Почему аппаратный барьер меняет модель угрозы
Любое программное средство защиты — это код. Код может содержать уязвимости. Даже при минимальной вероятности обхода она не равна нулю. Аппаратный барьер переносит защиту из области вероятностей в область контролируемой механики.
Программа-вымогатель может получить права администратора, использовать уязвимости нулевого дня (программная ошибка, о которой производитель ещё не знает), обходить антивирусы. Но она не может механически изменить положение магазина. Она не может заставить робот пересечь пустоту. Для атаки потребуется реальный доступ к устройству, что выводит угрозу из категории массовых автоматизированных атак в категорию локальных диверсий. С точки зрения киберустойчивости это радикальное снижение поверхности атаки.
Экономика восстановления
При атаке программ-вымогателей критичным становится не только сам факт наличия резервной копии, но и скорость восстановления. Чем быстрее организация возвращается к операционной деятельности, тем меньше прямые и репутационные потери.
Физически изолированная копия даёт главное — гарантию целостности. Не нужно проверять, не были ли бэкапы зашифрованы до активации атаки. Не нужно гадать, не удалены ли снапшоты. Изолированные ленты остаются неизменными.
В ряде публичных расследований инцидентов отмечалось, что компании, имеющие офлайн-копии, отказались от выплаты выкупа и восстановили инфраструктуру самостоятельно. Там, где резервные копии находились онлайн, злоумышленники чаще уничтожали их первыми.
Лента как современный инструмент

Стереотип о ленте как о «ретро-технологии» можно смело выкидывать из головы, если он у вас присутствует. Современные форматы LTO обеспечивают десятки терабайт на один картридж и высокую скорость передачи данных. Крупнейшие облачные провайдеры используют ленточные технологии для долгосрочного хранения именно из-за их плотности, низкого энергопотребления и предсказуемой долговечности.
Главное же преимущество ленты в контексте киберугроз — это естественная дискретность доступа. Лента не может быть одновременно доступна для записи множеству процессов через сеть. Она требует физического взаимодействия с приводом. А если между лентой и приводом создан воздушный зазор, то доступ отсутствует в принципе.
Парадокс цифровой эпохи

Мы живём в эпоху, когда кибератаки становятся автоматизированными и масштабируемыми. Искусственный интеллект помогает злоумышленникам быстрее анализировать инфраструктуру жертвы. В ответ бизнес наращивает программные средства защиты. Возникает гонка алгоритмов.
Но в этой гонке выигрывает тот, кто способен выйти за её пределы.
Ленточные библиотеки с АэроБарьером — не шаг назад, а шаг в сторону от уязвимой парадигмы «всё онлайн».
Это признание простого факта: то, что не подключено к сети, не может быть взломано удалённо. Что скажете? Рассчитываем на ваши положительные реакции, чтобы поскорее добрать карму и рассказывать реальные кейсы из практики, полезные фичи по администрированию, свой софт и многое другое. Подписывайтесь!
Статью подготовил Дмитрий Никитин, технический писатель "ДИАМАНТ"
Комментарии (5)

igrblkv
07.04.2026 14:13USB-хаб на 4-7 портов с выключателем каждого порта и с соответствующим количеством подключенных дисков уделывает любую ленточную библиотеку когда не надо петабайты бекапить. Не хватает только механизма отключения всех портов кроме одного, как в старых радиолах с кнопочным управлением, но это чисто механически делается.
Любители автоматизации могут ещё по таймеру переключение портов по очереди сделать, что-бы каждый день на неделе - свой диск.
Diamant_storage Автор
07.04.2026 14:13мутная тема, если мы говорим про энтерпрайз решения, а так - велосипед выигрывает у машины, если на нём не надо ехать 5000 км)))

igrblkv
07.04.2026 14:13Бэкапы нужны только энтерпрайзу?
Мелкому и среднему бизнесу бекапы без надобности?
Зачем им покупать библиотеку за килобаксы и где взять столько денег?
А если надо проехать пару тысяч километров - какой автомобиль выигрывает? КАМАЗ? Лада? Или лучше на велике, ведь далеко не 5000 км?
Почему-то всем надо заполучить в клиенты условный Газпром... Аккуратнее с такими желаниями - у вас может получиться! Проблема в том, что он же будет единственным клиентом - остальные просто не потянут такой уровень.
PS: Почему в своё время выстрелили микротики? Почему народ просто не продолжил покупать Циски дальше? Может стоить подумать и о финансовой стороне? Ведь кроме покупки самого отечественного решения надо ещё и железо под него закупить и специалистов нанять, которые за еду не долго продержатся и смысла в таком купленном решении не будет - никто не сможет с ним и в нём работать!
zgwerby
ЕСЛИ.
- Если в качестве IT-отдела были наняты люди, а не взяты за копейки выпускники шараги тире ПТУ "информационных технологий" в виде аутсорса, формально работающие в помойном, околоИПшном ООО, чьи слова в принципе в компании имеют вес, восприятие вклада в компанию которых выше, а не на уровне "компукторная уборщиться".
- Если аудит/анализ/выкладки айтишников показали, что покупка и обслуживание стойки (в том числе и операционные расходы, на те же кассеты) с ленточным бэкапом и библиотекой в принципе оправдана и имеет смысл.
- Если СЕО в принципе прислушалось к результатам аудита и решило вложить деньги в "холодную" бэковую, "наша-служба-и-опасна-и-трудна-и-даже-на-сотый-взгляд-в-упор-не-видна-до-первого-инцидента"-инфраструктуру, а не, снова прислушавшись к гудению недополученной прибыли в кошельке, вложившихся в расширение вечно загруженных под сотку продуктивных мощностей.
- Если руководство компании смогло пересилить себя и выделило раз (покупка, установка и интеграция) и внесло в операционные расходы требуемые деньги на кассеты и расходники, а не отправило на них себя по курортам, а своих дитачек - по Итонам и Йелям.
- Если в руководстве IT-департаментом не завёлся сумасшедший, строящий холодные резервные копии на достаточных для мелкого бизнеса "жёсткий диск через обестачивающее бокс-с-алиэкспресс (для внешнего хдд с подключением по юсб, хорошо, если не 2.0) реле" и прочих копродендро-решениях, который почти всегда может отговорить СЕО от капитальных вложений, обещая такое же, только по цене кофе.
- Если была приобретена нормальная, надёжная, не лежащая 90% времени в ремонте и не пребывающая в непрекращающемся процессе настройки, система холодного хранения бэкапов, а не помойное нонеймое, зато с шильдиком "дёсево-дёсево, касество сатри халёсее-лёсее, корефана", с достаточной расчётной ёмкостью библиотеки, с поддержкой write-once для критических данных.
- Если само оборудование было нормально установлено и интегрировано в системы снятия резервных копий, а не захлебнулось после первых "боевых" снятий РК, превратившись в дорогущий, жрущий питание шкаф с роботом и неонкой унутре.
- Если очередной не-вееам не дал петуха и не перестал снимать резервные копии, снимая какую-то туфту с отписками поддержки с подтекстом: "мы тут бросили вас, кастомеры, потому, что иначе нас не допустят до госзакупок в штатах, кстати, наш куратор из ЦРУ приготовил вам сюрпрайз, мазафакеры".
- Если сами данные в основном контуре на момент снятия данных уже не были превращены в зашифрованную кашу (особенно это касается архивных и других редкооткрываемых данных) или просто не были попорчены системой хранения (очевидный RAID0+1 или RAID5, остальное вызывает у выдеяющих деньги приступы амфибиотропной асфиксии) основного контура так, что на первый взгляд с ними всё ок
- Если эти данные резервной копии нормально записаны на нормальные, а не на босотовые дженерик-кассеты (которые такие же по объёму, но на треть дешевле и с откатом в карман закупайке) в проверенном, не битом, раскатывающимся обратно даже из простой, не говорим уже про сложные схемы дифференциальных копий, формате файла РК.
- Если аникей установил эти стопоры, скажем после воскресного бэкапа, на периодические оперативные резервные копии руками в рамках понедельничного будничного ритуала.
ЕСЛИ.
Diamant_storage Автор
Давайте разберемся в Ваших "ЕСЛИ".
Начнем с простого - если бэкапы не нужны, то ССЗБ. И ничего страшного, не надо переживать, это не Ваш цирк и не Ваши обезьяны, а того, кто решил, что они не нужны.
А дальше - требования. Если нужен write-once, то нужен write-once. Если нужна надежность (ее бы в цифрах выразить, не всё “дёсево-дёсево” плохое, оно просто имеет какую-то надежность за какие-то деньги) - то нужна надежность. Это всё - баланс. Если у вас бизнес-требования никакие - ну значит и не требуется ничего, тут нет никакой проблемы же, выдыхаем.
Интегрированность - другое дело. Есть отличные комбинации ЛБ и СРК, с взаимной сертификацией и регулярным тестированием. Есть российские, есть зарубежные. Не хотите зарубежные - что же, российские объективно очень неплохи, поддержку имеют, выбор тоже есть, навскидку - КиберБэкап, Рубекап, Береста. Да, у них есть свои особенности и оговорки, но уж точно нет кураторов из ЦРУ и подобных сюрпризов с бросанием клиентов на произвол судьбы.
А дальше Вы вообще рассуждаете про какие-то “если”, которые относятся к тому, чтобы считать бэкапами копии данных, сделанные до внедрения нормальной инфраструктуры. Сначала делаете инфраструктуру, потом бэкапы.
И не нужно полагаться на персонал, нужно строить политики так, чтобы они сами формировали действия персонала. Стопоры эти ставятся, грубо говоря, раз и навсегда, магазины блокируются автоматически, более того, для случаев, когда их “случайно” захлопнули после автоматической блокировки, сняв ее, предусмотрены политики вида “если не было указания администратора через веб-интерфейс, то закрытый магазин блокируем снова”. Есть очень простые решения и очень простые политики, которые позволяют значительно снизить влияние некорректных действий персонала. Конечно же, нельзя предусмотреть все. Если завтра на основную и резервную площадку не упадет метеорит, то, возможно, бэкапы удастся сохранить до завтра.
Если не переживать, то переживём. Всё хорошо.