В прошлой статье я писал, что безопасность — это не забор вокруг системы, а свойство её архитектуры, и что между «карточным домиком» и «бетонным саркофагом» лежит целое пространство решений. Сегодня — прогулка по одному конкретному участку этого пространства: как изолировать сегмент сети, не убив обмен данными.
Классический air gap — это и есть «бетонный саркофаг» в чистом виде: между сегментами нет ни одного кабеля, изоляция идеальная, пользоваться невозможно. На другом полюсе — обычный reverse proxy: удобно, быстро и почти ничего не изолирует. Всё интересное находится между этими полюсами и называется logical air gap: сквозного сетевого пути между сегментами нет, а осмысленный обмен данными — есть.
Звучит как оксюморон, поэтому вокруг термина много маркетинга и мало конкретики. Под катом — попытка навести порядок: шесть уровней, на которых можно устроить разрыв, три оси для честного сравнения и две популярные конструкции, которые выглядят как разрыв, но им не являются.
Зачем вообще это городить этот огород
Резонный вопрос: есть же файрвол. Но у любого периметра, построенного на фильтрации, есть неприятное свойство — сквозной путь в нём существует всегда. Файрвол решает, какие пакеты пропустить, но пакеты — проходят. Вся конструкция держится на трёх допущениях: правила написаны без ошибок, в сетевом стеке и в сервисе за ним нет неизвестных уязвимостей, и никто не поменяет конфигурацию — случайно или намеренно. Каждое из этих допущений регулярно не выполняется.
Пока за периметром живут вики и тестовый стенд — с этим можно мириться. Но есть сегменты, где цена компрометации несоизмерима со стоимостью любого посредника: технологические сети и АСУ ТП, бэкапы (первое, что ищет шифровальщик), ключи и HSM, контуры с персональными данными и коммерческой тайной, ML-модели, в которые вложены миллионы GPU-часов. Для таких сегментов «мы фильтруем трафик» — недостаточный ответ ни для архитектора, ни для регулятора.
Классический ответ — отрезать кабель — работает, но убивает то, ради чего сегмент вообще существует: данные должны попадать внутрь, результаты — наружу. Logical air gap — попытка оставить себе главное свойство отрезанного кабеля (пакет снаружи в принципе не может доехать до сервиса внутри), не отказываясь от обмена. Дальше — о том, какими способами это свойство достигается и что каждый способ стоит.
Что считаем разрывом
Рабочее определение:
Логический разрыв — это отсутствие сквозного сетевого пути между недоверенным и доверенным сегментом при сохранении осмысленного обмена данными между ними.
Ключевое слово — «сквозного». Пакет, отправленный внешним клиентом, не должен доходить до внутреннего сервиса. Между ними обязан быть посредник, который принимает данные, завершает обмен на себе и порождает новый обмен — по своей инициативе и по своим правилам.
Само по себе определение слишком широкое: под него формально попадает и аппаратный диод за миллионы, и nginx за вечер. Чтобы сравнивать их честно, я оцениваю каждый вариант по трём осям.
Ось 1. Остаётся ли сквозной маршрут. Может ли пакет из недоверенной зоны физически или логически добраться до доверенной. Крайние точки: «кабеля нет» и «маршрут есть, но фильтруется».
Ось 2. Кто инициирует соединение. Самый недооценённый параметр. Если соединение всегда открывает доверенная сторона, во внутреннем сегменте нет ни одного слушающего порта, доступного снаружи, — и вся категория атак «просканировал, нашёл, проэксплуатировал» исчезает как класс (ну или почти исчезают). Если инициирует недоверенная сторона, внутри обязан быть открытый порт, каким бы узким ни был протокол.
Ось 3. Возможен ли синхронный ответ. Может ли внешний клиент дождаться результата в рамках одного HTTP-запроса. Это граница между «шлюзом к API» и «системой доставки файлов». Многие красивые по изоляции варианты синхронный ответ не дают вовсе — и это надо знать до внедрения, а не после.
Четвёртая ось добавляется неявно — цена: деньги, задержка, объём работ. Именно она определяет, чем пользуются в реальности, а чем — только на слайдах.
Карта уровней
Варианты удобно раскладывать по уровню, на котором происходит сам разрыв. Чем ниже уровень — тем строже изоляция и неудобнее обмен; чем выше — тем удобнее обмен и тем больше доверия приходится оказывать коду посредника.

Важно: уровни комбинируются. Боевые контуры почти никогда не строятся на одном варианте — типичная конструкция: сетевой разрыв (уровень 1) + транспортный посредник (уровень 2) + валидация схемы (уровень 4). Дальше — кирпичи, а не готовые здания.
Уровень 0. Физика: ошибиться в настройке нельзя, потому что настраивать нечего
Здесь разрыв обеспечивается отсутствием среды передачи либо её физической однонаправленностью.
0.1. Классический air gap и sneakernet. Ни кабеля, ни радиоканала; данные переносятся на съёмном носителе через контроль на входе. Эталон, относительно которого измеряется всё остальное. Платим часами задержки и человеком в цикле — который одновременно и главный носитель риска: заражённая флешка остаётся классическим вектором проникновения в изолированный контур.
0.2. Аппаратный оптический диод. Устройство, у которого физически есть только передатчик с одной стороны и только приёмник с другой: волокно идёт в одну сторону, обратного волокна нет. Однонаправленность доказывается схемотехникой, а не конфигом. Обратный канал — а значит, и эксфильтрация из доверенного сегмента — невозможен в принципе. Цена: дорого, нет ACK (надёжность строится избыточностью поверх UDP), синхронный ответ невозможен по определению.
0.2. Аппаратный оптический диод. Устройство, у которого физически есть только передатчик с одной стороны и только приёмник с другой: волокно идёт в одну сторону, обратного волокна нет. Однонаправленность доказывается схемотехникой, а не конфигом. Обратный канал — а значит, и эксфильтрация из доверенного сегмента — невозможен в принципе. Цена: дорого, нет ACK (надёжность строится избыточностью поверх UDP), синхронный ответ невозможен по определению.
0.4. Станция переноса с ручным подтверждением и её роботизированный вариант. Выделенная машина с двумя носителями: оператор (или манипулятор) явно подтверждает каждый перенос. Человек ловит то, что не ловит автоматика, — странные объёмы, нетипичные форматы. Обратная сторона известна каждому, кто внедрял согласования: при потоке подтверждений человек начинает штамповать «ок» не глядя, и защита превращается в ритуал.
Уровень 1. Сеть: среда есть, маршрута нет
Пакету из недоверенной зоны просто некуда ехать. Главное отличие от уровня 0: разрыв держится на конфигурации — а значит, снимается одной неверной командой.
1.1. Раздельные VRF/VLAN без маршрутизации. Разные таблицы маршрутизации или широковещательные домены, между которыми нет ни утечки маршрутов, ни SVI. Дёшево, ноль задержки, база под любой другой вариант. Но общий control plane коммутатора остаётся общей поверхностью атаки.
1.2. Dual-homed хост без форвардинга. Машина с двумя интерфейсами и выключенным ip_forward: пакеты не проходят насквозь, их принимает и порождает заново процесс уровня приложения. Простая и проверяемая точка, где маршрут заканчивается, а данные продолжаются. Компрометация этого хоста — мост между сегментами, поэтому hardening без компромиссов.
1.3. Двойной NAT через «тамбур». Промежуточная сеть, чьи адреса видят обе стороны — и только их. Прячет внутреннюю адресацию, но честно скажем: маршрут никуда не делся, он просто транслируется. Это сокрытие топологии, а не разрыв.
1.4. Bump-in-the-wire на L2. Прозрачный мост без IP-адресов в разрыве кабеля: пропускает только явно разрешённые кадры. Его нельзя атаковать по IP, потому что IP у него нет. Минус зеркальный: фильтрует кадры, а не смысл — разрешённый протокол проходит целиком, со всей своей уязвимой поверхностью.
1.5. Односторонний UDP правилом файрвола. «Диод без диода»: разрешено единственное направление на один порт, запрещён любой обратный трафик, включая ICMP. Стоит одно правило и работает уже сегодня — но однонаправленность держится на конфигурации, которую можно изменить удалённо. Хорош как пилот перед закупкой железного диода.
Уровень 2. Транспорт: маршрут до посредника есть, сквозной сессии нет
Клиент устанавливает соединение с посредником; посредник самостоятельно устанавливает другое соединение. Именно здесь живёт большинство работающих продуктов — это единственный уровень, где строгость ещё есть, а синхронный ответ уже есть.
2.1. Терминация TCP на прокси. Посредник полностью завершает внешнее соединение и открывает своё внутрь. Ни один байт TCP-заголовка снаружи не попадает во внутренний сегмент; фрагментация и трюки со стеком остаются за дверью. Слабое место: соединение внутрь всё-таки открывается в сторону доверенной зоны — слушающий порт там есть.
2.2. Pull-модель. Соединение всегда инициирует доверенная сторона: внутренний компонент сам подключается к шлюзу в недоверенной зоне и забирает работу; ответ возвращается отдельным исходящим вызовом. Результат: во внутреннем сегменте ноль слушающих портов, файрвол настраивается «только исходящие», снаружи нельзя даже постучаться — стучаться некуда. При этом синхронный ответ сохраняется, задержка — единицы миллисекунд. Цена: шлюз снаружи хранит состояние незавершённых запросов и требует аккуратной корреляции запрос-ответ.
2.3. Встречные исходящие к точке сопряжения. Симметричный вариант: в DMZ стоит точка встречи, к которой обе стороны подключаются исходящими соединениями. Оба периметра закрыты на вход. Платим третьей стороной, которой нужно доверять — или строить сквозное шифрование поверх.
А теперь две конструкции, которые регулярно продают как «разрыв».
2.4. Ловушка №1: reverse-tunnel. Внутренний хост поднимает наружу SSH remote forward, WireGuard или connector-агент и публикует через него внутренний порт. Входящих соединений нет — выглядит как pull-модель. Но внутри туннеля восстанавливается сквозной поток: это не разрыв, это обход периметра. Компрометация внешней точки даёт прямой доступ внутрь. Для админского доступа — нормально; как изоляция — нет.
2.5. Ловушка №2: SPA и port-knocking. Порт закрыт, пока клиент не пришлёт подписанный пакет; потом файрвол открывает окно доступа. Отлично прячет сервис от сканирования — жертву сначала надо найти. Но после открытия окна связь сквозная: это не разрыв, это отложенное разрешение.
Уровень 3. Хранилище: стороны вообще не общаются напрямую
Одна сторона пишет в общий посредник, другая читает. Посредник — единственный объект, который видят обе зоны.
3.1. Брокер сообщений (Redis, RabbitMQ, Kafka, NATS). Запрос в очередь, ответ по correlation ID. Знакомая модель, права разделяются средствами брокера, всплески нагрузки гасятся демпфером. По моим измерениям цена такого разрыва для синхронного API — порядка трети пропускной способности, и потолком становится сам брокер.
3.2. Файловый спул. Общий каталог, атомарность через запись во временное имя и rename, целостность через подпись. Работает где угодно, включая контуры без права на сетевые сервисы, и естественно ложится на диод. Платим задержкой и классикой файловых гонок.
3.3. Объектное хранилище как почтовый ящик. Тот же спул, но с декларативной моделью прав: внешней стороне — только PutObject в один префикс, внутренней — только GetObject/DeleteObject. Версионирование и журнал доступа из коробки.
3.4. Таблица-мейлбокс в СУБД. INSERT заявки снаружи, SELECT ... FOR UPDATE SKIP LOCKED изнутри, результат — в соседнюю таблицу. Транзакционность и аудит бесплатно, если база уже есть. На высоком темпе превращается в очаг блокировок.
3.5. Однонаправленная репликация и CDC. Передаются не сообщения, а само состояние: реплика доступна только на чтение. Читающая сторона в принципе не может ничего изменить у источника. Команды так не передашь — только данные.
3.6. Разделяемая память между ВМ. Два сегмента — две виртуалки на одном гипервизоре без виртуальной сети между ними: обмен через ivshmem или virtio-vsock. Ни маршрута, ни порта, ни IP, задержка в микросекунды. Цена: обе стороны на одном хосте, протокол поверх памяти пишется руками, а гипервизор становится общим доверенным элементом.
3.7. Спул с антивирусом и CDR. К любому посреднику добавляется обязательная стадия: файл не проверяется, а пересобирается заново — без макросов, скриптов и активного содержимого. Внутрь попадает не тот байтовый поток, что пришёл снаружи, а его очищенная реконструкция.
Уровень 4. Смысл: проходит не трафик, а разрешённое сообщение
Граница проходит не по пакетам, а по семантике. Эти варианты не заменяют уровни 1–3, а надстраиваются над ними.
4.1. Контролируемый RPC с узкой схемой. Между сегментами разрешён ровно один вызов с описанным контрактом — например, gRPC с protobuf и mTLS. Вместо «любого HTTP» — конечный список полей известных типов; всё, что не укладывается в схему, умирает в парсере до бизнес-логики.
4.2. Прокси с пересборкой запроса. Посредник разбирает протокол целиком и формирует внутрь новый запрос: только разрешённые заголовки, канонизированный путь, перепроверенная кодировка. Исходные байты дальше не идут — и вместе с ними не идут request smuggling, двойное кодирование и обход по нестандартным заголовкам.
4.3. Подписанный конверт. Безопасность переносится с транспорта на само сообщение: подпись, метка времени, nonce против повторов. После этого транспорт не важен — хоть очередь, хоть файл, хоть диод, — а посредник может быть скомпрометирован, но подделать сообщение не сможет. Одна оговорка: криптография не мешает передать внутрь корректно подписанную гадость.
4.4. Схемная валидация на границе. JSON Schema или protobuf-дескриптор, лимиты на размер и вложенность, белый список полей. Дёшево, ловит и атаки, и ошибки интеграции. Внутренний сервис перестаёт быть первым, кто читает недоверенные данные, — практически обязательный слой.
4.5. Ticket и callback. Синхронный вызов меняется на двухфазный: заявка → 202 Accepted с идентификатором → результат позже. Задержка перестаёт быть проблемой — можно ставить сколь угодно строгий транспорт, вплоть до диода. Платим переписыванием клиентов.
4.6. Human-in-the-loop и правило четырёх глаз. Переход через границу требует решения человека, для критичных операций — двух независимых. Единственный способ поймать запрос, легитимный по форме, но недопустимый по сути. Работает для единичных операций и деградирует в ритуал на потоке.
Уровень 5. Экзотика: для калибровки границ
Эти варианты редко доезжают до продакшена, но полезны — они показывают, что «разрыв» — это свойство конструкции, а не название продукта.
5.1. Экран → камера с QR-цепочками. Однонаправленный канал без единого электрического соединения; фонтанные коды переживают пропуски кадров. Десятки килобайт в секунду, зато отсутствие обратного канала проверяется невооружённым глазом.
5.2. «Бумажный диод». Печать штрихкодов и сканирование на другой стороне. Носитель в принципе не может нести исполняемый код, а перенесённое можно подшить в папку.
5.3. Акустический канал. Модем на звуковой карте, включая ультразвук. В продакшене встречается ровно наоборот — как известный вектор утечки из изолированных контуров, который блокируют отключением аудиоустройств.
5.4. Светодиод → фотодиод. Биты в секунду через мигание индикатора. Не транспорт, а нижняя граница самого понятия «связи нет» — и модель угроз для проектировщиков изолированных помещений.
5.5. Курьер с опечатанным носителем. Институционализированный sneakernet с актами и комиссией. Задержка — сутки, зато диск в сумке — это десятки терабайт.
Вся карта одним взглядом
Те же 32 варианта на одной шкале — по пяти осям сразу. Оценки грубые и сравнительные: они нужны, чтобы выбрать направление, а не чтобы подставлять в расчёт. Шкала у каждой колонки своя: в «строгости» и «зрелости» зелёное — это «больше», в «задержке» и «стоимости» — «меньше».

Хорошо видно, где в этой таблице живут компромиссы: колонка «синхронный ответ» зеленеет только на уровнях 2 и 4, у физики и экзотики сплошная зелёная «строгость» упирается в красную «задержку», а два оранжевых ряда-ловушки на уровне 2 выделяются красным именно там, где у соседей всё зелено.
Что из этого следует
Если свести всю карту к нескольким тезисам:
Синхронный ответ живёт только на уровнях 2 и 4. Всё, что строже, — диоды, спулы, переносы — не способно обслуживать синхронные вызовы внешнего клиента. Уровни 2 и 4 комбинируются друг с другом без потерь, и именно их связка (плюс сетевой разрыв уровня 1 под ними) — рабочая основа для шлюза к API.
«Кто инициирует соединение» важнее, чем кажется. Pull-модель с нулём слушающих портов во внутреннем сегменте убирает целый класс атак почти бесплатно — и при этом о ней вспоминают гораздо реже, чем о дорогих диодах.
Два самых популярных «разрыва» — не разрывы. Reverse-tunnel восстанавливает сквозной поток внутри туннеля, SPA/port-knocking открывает сквозное окно после стука. Оба инструмента полезны — но не как изоляция.
Строгость нужна не максимальная, а достаточная. Выгоднее вкладываться не в высокий уровень строгости, а в то, чтобы выбранный уровень был реализован без дыр.
В следующей статье хочу показать, что получается, когда из этих кирпичей собираешь работающий шлюз: где оказывается узкое место, сколько стоит разрыв в миллисекундах и RPS и какие оптимизации отбивают его цену.
А пока интересен ваш опыт: какие из этих конструкций встречались вам в проде — и выдержали ли они первую же встречу с реальными требованиями бизнеса?
