Анализ вариантов реализации паттерна logical airgap
logical airgap - это целое пространство решений, разрыв можно устроить на очень разных уровнях — от перерезанной пары в кабеле до правила «этот JSON проходит, а этот нет». В предыдущих постах я приводил короткие списки вариантов, но это была иллюстрация, а не разбор: четыре пункта в статье про MVP и таблица из четырёх строк в каталоге оптимизаций.
Здесь — полный каталог: три с половиной десятка способов реализовать логический разрыв, сгруппированных по уровню, на котором он происходит. По каждому варианту одни и те же вопросы: как реализуется, что даёт, плюсы, минусы, где уместен.
Что считается разрывом
Рабочее определение, которым я пользуюсь дальше:
Логический разрыв — это отсутствие сквозного сетевого пути между недоверенным и доверенным сегментом при сохранении осмысленного обмена данными между ними.
Ключевое слово — «сквозного». Пакет, отправленный внешним клиентом, не должен доходить до внутреннего сервиса. Между ними обязан быть посредник, который принимает данные, завершает обмен на себе и порождает новый обмен по своей инициативе и по своим правилам.
Само по себе это определение слишком широкое: под него попадает и аппаратный диод, и обычный обратный прокси. Поэтому каждый вариант дальше оценивается по трём осям.
Ось 1. Остаётся ли сквозной маршрут. Может ли пакет из недоверенной зоны физически или логически добраться до доверенной. Крайние точки — «кабеля нет» и «маршрут есть, но фильтруется».
Ось 2. Кто инициирует соединение. Самый недооценённый параметр. Если соединение всегда открывает доверенная сторона, внутренний сегмент не имеет ни одного слушающего порта, доступного снаружи, — и вся категория атак «просканировал, нашёл, эксплуатировал» пропадает. Если инициирует недоверенная сторона, внутри обязан быть открытый порт, каким бы узким ни был протокол.
Ось 3. Возможен ли синхронный ответ. Может ли внешний клиент дождаться результата в рамках одного HTTP-запроса. Это граница между «шлюзом к API» и «системой доставки файлов». Многие красивые по изоляции варианты синхронный ответ либо не дают вовсе, либо дают ценой, которая делает их бессмысленными.
Ко всем трём осям неявно добавляется четвёртая — цена: деньги, задержка и объём работ. Она и определяет, чем в реальности пользуются, а чем — только на слайдах.
Карта уровней разрыва
Варианты я разложил по уровню, на котором происходит сам разрыв. Чем ниже уровень, тем строже изоляция и тем неудобнее обмен; чем выше — тем удобнее и тем больше доверия приходится оказывать коду посредника.
Читать эту шкалу стоит так:
| Уровень | Где происходит разрыв | Строгость | Синхронный ответ |
|---|---|---|---|
| 0. Физика | Среды передачи между сегментами нет или она однонаправленная | Максимальная | Практически невозможен |
| 1. Сеть | Среда есть, маршрута между подсетями нет | Высокая | Нет без посредника уровнем выше |
| 2. Транспорт | Маршрут есть до посредника, сквозной сессии нет | Средняя | Да |
| 3. Посредник-хранилище | Стороны общаются только через третье хранилище | Средняя | Да, но с задержкой |
| 4. Прикладной уровень | Проходит не трафик, а разрешённое сообщение | Зависит от реализации | Да |
| 5. Экзотика | Данные меняют физическую природу: свет, звук, бумага | Максимальная | Нет |
Важно, что уровни комбинируются. Боевые контуры почти никогда не используют один вариант: типичная конструкция — сетевой разрыв (уровень 1) плюс транспортный посредник (уровень 2) плюс валидация схемы (уровень 4). Каталог перечисляет кирпичи, а не готовые здания.
Шаблон описания
Каждый вариант дальше описан одинаково, чтобы их можно было сравнивать, а не читать подряд:
- Как реализуется — из чего собирается на практике.
- Что даёт — какое свойство появляется у контура.
- Плюсы — за что его выбирают.
- Минусы — чем за это платят.
- Где уместен — в каких сценариях он не выглядит избыточным.
Схемы у всех вариантов в единой нотации: недоверенная зона слева, механизм разрыва в центре, доверенная зона справа.
Уровень 0. Физический разрыв
Здесь разрыв обеспечивается не конфигурацией, а отсутствием среды передачи либо её физической однонаправленностью. Ошибиться в настройке нельзя — настраивать нечего.
0.1. Классический air gap и sneakernet
Как реализуется. Между сегментами нет ни одного кабеля и ни одного радиоканала. Данные переносятся вручную на съёмном носителе, с контролем на входе: проверка носителя, антивирус, журнал переноса.
Что даёт. Полное отсутствие сетевого пути — тот эталон, относительно которого измеряются все остальные варианты.
Плюсы. Не зависит от корректности софта; понятен регуляторам; переживает любую компрометацию сетевого периметра. Минусы. Задержка от минут до суток; человек в цикле — и главный носитель риска (заражённая флешка — классический вектор проникновения в изолированный контур); не масштабируется. Где уместен. Гостайна, изолированные сегменты АСУ ТП, редкие переносы больших объёмов — обновления, дистрибутивы, базы сигнатур.
0.2. Аппаратный оптический диод
Как реализуется. В канал ставится устройство, у которого физически есть только передатчик на одной стороне и только приёмник на другой: волокно идёт в одну сторону, обратного волокна нет. Поверх строится протокол без подтверждений — обычно UDP-поток с прямой коррекцией ошибок и многократным повтором.
Что даёт. Однонаправленность, доказуемую на уровне схемотехники, а не конфигурации.
Плюсы. Обратный канал невозможен в принципе, значит, невозможна и экcфильтрация из доверенного сегмента; сертифицируемо. Минусы. Дорого; нет ACK — надёжность приходится строить избыточностью; синхронный ответ невозможен; каждый прикладной протокол требует своей пары «прокси-отправитель / прокси-получатель». Где уместен. Вынос телеметрии, логов и исторических данных из КИИ наружу; репликация «только читать» в защищённый сегмент.
0.3. Диод на обрезанных парах Ethernet или RS-232
Как реализуется. Бюджетный вариант того же принципа: в кабеле физически разрывается пара, отвечающая за обратное направление (или снимается сигнал RTS/CTS у последовательного порта). Получается односторонняя линия из подручных материалов.
Что даёт. Ту же однонаправленность за стоимость кабеля, но без каких-либо гарантий производителя.
Плюсы. Почти бесплатно; собирается за час; наглядно демонстрирует принцип. Минусы. Ethernet без обратной пары не поднимает link на многих чипах — нужны медиаконвертеры или свитчи с ручной настройкой; ноль сертификации; легко «починить» обратно случайной заменой кабеля. Где уместен. Лаборатории, стенды, демонстрации, внутренние сегменты с невысокими требованиями к формальному подтверждению.
0.4. Шлюзовая станция переноса с ручным подтверждением
Как реализуется. Выделенный компьютер с двумя носителями и оператором: данные сгружаются с внешнего носителя, проходят проверку, оператор явно подтверждает перенос, после чего данные записываются на внутренний носитель. Часто это отдельное помещение и отдельный регламент.
Что даёт. Разрыв плюс обязательное человеческое решение по каждой порции данных.
Плюсы. Позволяет ловить то, что не ловит автоматика: странные объёмы, нетипичные форматы, попытки вынести лишнее; создаёт персональную ответственность за перенос. Минусы. Пропускная способность измеряется в переносах в час; дорого в людях; человек устаёт и начинает штамповать подтверждения. Где уместен. Ввод обновлений и конфигураций в критичный контур; вывод отчётов наружу.
0.5. Автоматизированный перенос носителя
Как реализуется. Ту же станцию обслуживает не человек, а механика: роботизированная библиотека картриджей или манипулятор, переставляющий носитель между двумя изолированными приводами. Стороны обмениваются не пакетами, а томами.
Что даёт. Физический разрыв без человека в цикле и с предсказуемым расписанием переноса.
Плюсы. Регулярность и журналируемость; масштабируется по объёму (терабайты за проход), а не по числу сообщений. Минусы. Экзотическая механика, которую надо обслуживать; задержка в десятки минут; сам робот становится единственной точкой отказа и объектом атаки на прошивку. Где уместен. Регулярный вывоз больших массивов данных из изолированного контура: архивы, резервные копии, наборы для обучения моделей.
Сводка по уровню 0
| Вариант | Механика | Что выигрываем | Чем платим |
|---|---|---|---|
| Классический air gap | Ручной перенос носителя | Эталонная изоляция | Часы задержки, человек в цикле |
| Аппаратный диод | Только передатчик с одной стороны | Доказуемая однонаправленность | Цена, отсутствие ACK, нет ответа |
| Диод на обрезанных парах | Разрыв обратной пары в кабеле | Тот же принцип почти бесплатно | Нет гарантий и сертификации |
| Станция переноса | Оператор подтверждает каждую порцию | Человеческий контроль содержимого | Единицы переносов в час |
| Робот-перенос | Механическая перестановка носителя | Регулярность без человека | Экзотическое железо, десятки минут |
Уровень 1. Сетевой разрыв
Среда передачи есть, но маршрута между сегментами нет: пакет из недоверенной зоны некуда адресовать. Разрыв обеспечивается конфигурацией — а значит, может быть снят одной неверной командой. Это главное отличие уровня 1 от уровня 0.
1.1. Раздельные VRF или VLAN без маршрутизации
Как реализуется. Сегменты живут в разных таблицах маршрутизации (VRF) или разных широковещательных доменах (VLAN), и между ними нет ни утечки маршрутов, ни SVI-интерфейса. Обмен возможен только через хост, включённый в оба домена явным решением.
Что даёт. Отсутствие сквозного L3-пути при общей физической инфраструктуре.
Плюсы. Дёшево — это конфигурация существующего оборудования; хорошо ложится на уже принятую сегментацию; ноль дополнительной задержки. Минусы. Разрыв держится на конфиге и живёт ровно до первой ошибки в маршрутах; общий control plane коммутатора остаётся общей поверхностью атаки (VLAN hopping, компрометация железа). Где уместен. База под любой другой вариант: сначала убираем маршрут, потом решаем, чем именно его заменить.
1.2. Dual-homed хост без форвардинга
Как реализуется. Один хост с двумя сетевыми интерфейсами — по одному в каждый сегмент — с выключенным ip_forward. Пакеты не проходят насквозь: их принимает и порождает заново процесс уровня приложения.
Что даёт. Явную точку, где маршрут заканчивается, а данные продолжаются.
Плюсы. Просто, дёшево, легко проверяется одной командой; естественная площадка для посредника любого типа. Минусы. Компрометация хоста означает мост между сегментами — весь разрыв держится на одной машине; требует жёсткого hardening и минимума софта. Где уместен. Практически любой шлюзовый сценарий среднего уровня строгости; классическая площадка для размещения прокси или брокера.
1.3. Промежуточная шлюзовая сеть с двойным NAT
Как реализуется. Между сегментами создаётся третья сеть — «тамбур». Внешняя сторона видит только адреса тамбура, внутренняя — тоже только их. Ни один адрес доверенного сегмента наружу не публикуется, трансляция выполняется дважды.
Что даёт. Сокрытие топологии и адресации внутреннего контура плюс единственную зону, где стороны вообще могут встретиться.
Плюсы. Внутренние адреса не утекают ни в заголовках, ни в ошибках; удобно навешивать журналирование и фильтрацию на одну зону. Минусы. Маршрут технически существует, просто транслируется — от логической связности мы не избавились; двойной NAT ломает протоколы, передающие адреса внутри полезной нагрузки; отладка становится неприятной. Где уместен. Корпоративные периметры, где требование — не пускать наружу внутреннюю адресацию, а не устранить маршрут.
1.4. Bump-in-the-wire фильтр на L2
Как реализуется. Прозрачный мост без IP-адресов включается в разрыв кабеля и пропускает только явно разрешённые кадры: конкретные MAC, конкретный EtherType, конкретный порт. Для сети он невидим.
Что даёт. Точку контроля, которую нельзя атаковать по IP, потому что у неё нет IP.
Плюсы. Не требует перенастройки адресации; сам фильтр не адресуем и потому плохо доступен для атаки; минимальная задержка. Минусы. Фильтрует кадры, а не смысл: разрешённый протокол проходит целиком, вместе со всей своей уязвимой поверхностью; сложно диагностировать — устройства «нет» ни в одной таблице. Где уместен. Промышленные протоколы с фиксированной топологией, где список допустимых собеседников известен заранее и не меняется.
1.5. Односторонний UDP-поток правилом межсетевого экрана
Как реализуется. Программная эмуляция диода: межсетевой экран разрешает единственное направление — UDP на один порт из сегмента A в сегмент B — и запрещает любой обратный трафик, включая ICMP-ошибки. Прикладной протокол строится без подтверждений.
Что даёт. Поведение диода без покупки диода.
Плюсы. Стоит одно правило; можно поднять сегодня; подходит для тех же сценариев, что и аппаратный диод, — телеметрии и логов. Минусы. Однонаправленность держится на конфигурации, а не на физике: правило можно изменить удалённо, и это делает вариант неприемлемым там, где требуется доказательство; UDP теряет пакеты, надёжность придётся строить самому. Где уместен. Пилоты и обкатка «диодных» сценариев до закупки железа; внутренние контуры, где достаточно организационных гарантий.
Сводка по уровню 1
| Вариант | Механика | Что выигрываем | Чем платим |
|---|---|---|---|
| Раздельные VRF/VLAN | Нет маршрута между доменами | Дёшево, без задержки | Разрыв держится на конфигурации |
| Dual-homed хост | Форвардинг выключен, работает процесс | Явная точка терминации | Компрометация хоста = мост |
| Двойной NAT | Тамбур между сегментами | Сокрытие адресации | Маршрут остаётся, просто транслируется |
| L2-фильтр | Прозрачный мост со списком разрешённого | Не атакуем по IP | Фильтрует кадры, а не содержимое |
| Односторонний UDP | Правило межсетевого экрана | Диод без диода | Гарантия только организационная |
Уровень 2. Транспортный и сессионный разрыв
Маршрут до посредника есть, а сквозной сессии — нет. Клиент устанавливает соединение с посредником, посредник самостоятельно устанавливает другое соединение внутрь. Именно на этом уровне живёт большинство работающих продуктов, потому что это единственный уровень, где строгость ещё есть, а синхронный ответ уже возможен.
2.1. Терминация TCP на прокси: два независимых соединения
Как реализуется. Посредник принимает соединение снаружи, полностью его завершает — читает запрос до конца, — и открывает своё собственное соединение внутрь. Ни один байт заголовка TCP снаружи не попадает во внутренний сегмент.
Что даёт. Разрыв на уровне сессии: сквозного потока нет, есть два отдельных, связанных только логикой посредника.
Плюсы. Синхронный ответ работает естественно; фрагментация, странные TCP-опции и трюки со стеком остаются снаружи; точка, где удобно валидировать содержимое. Минусы. Соединение внутрь всё-таки открывается снаружи внутрь — во внутреннем сегменте есть слушающий порт; ошибка в прокси означает сквозной путь; прокси — узкое место и точка отказа. Где уместен. Публикация внутреннего API наружу там, где строгость требований умеренная, а прозрачность для клиента важна.
2.2. Pull-модель: исходящее соединение из доверенного сегмента
Как реализуется. Соединение всегда инициирует доверенная сторона: внутренний компонент сам подключается к шлюзу в недоверенной зоне и запрашивает работу. Шлюз принимает HTTP от клиента, кладёт запрос в очередь и отдаёт его тому, кто пришёл за ним изнутри; ответ возвращается по тому же принципу — отдельным исходящим вызовом.
Что даёт. Полное отсутствие слушающих портов в доверенном сегменте: снаружи внутрь нельзя даже постучаться, потому что стучаться некуда.
Плюсы. Сканирование и эксплуатация внутренних сервисов снаружи невозможны; межсетевой экран внутреннего сегмента настраивается «только исходящие»; синхронный ответ сохраняется, задержка — единицы миллисекунд. Минусы. Шлюз в недоверенной зоне хранит состояние незавершённых запросов и становится целью атаки на отказ; нужна корреляция запроса и ответа; при наивной реализации — опрос вместо ожидания, то есть паразитная нагрузка. Где уместен. Внешний клиент вызывает внутренний API и получает синхронный ответ.
2.3. Reverse-tunnel из доверенного сегмента
Как реализуется. Внутренний хост поднимает наружу постоянный туннель (SSH remote forward, WireGuard, коммерческие connector-агенты) и публикует через него внутренний порт на внешней точке. Снаружи трафик заходит в туннель и выходит внутри.
Что даёт. Ту же инверсию инициативы, что и pull-модель, но без разбора содержимого.
Плюсы. Разворачивается за минуты; работает с любым TCP-протоколом; входящих соединений в доверенный сегмент нет. Минусы. Внутри туннеля восстанавливается сквозной поток — это уже не разрыв, а обход периметра; никакой валидации содержимого; компрометация внешней точки даёт прямой доступ внутрь. Где уместен. Административный доступ и временные интеграции. Как основа продуктового logical airgap — нет: свойство «нет сквозного пути» здесь теряется.
2.4. Встречные исходящие соединения к точке сопряжения
Как реализуется. В промежуточной зоне (DMZ или облако) стоит точка сопряжения. К ней обе стороны подключаются исходящими соединениями и обмениваются сообщениями через неё. Ни один сегмент не принимает входящих.
Что даёт. Симметричную конструкцию, в которой оба периметра закрыты на вход.
Плюсы. Внутренний и внешний сегменты одинаково защищены; точка сопряжения не хранит долговременных данных и легко дублируется; удобно, когда сегменты вообще не видят друг друга по сети. Минусы. Появляется третья сторона, которой нужно доверять — или строить сквозное шифрование поверх неё; дополнительный хоп добавляет задержку; ещё один компонент в эксплуатации. Где уместен. Связь между площадками разных владельцев; сценарии, где недоверенная сторона тоже не имеет права принимать соединения.
2.5. Канал по требованию: SPA и port-knocking
Как реализуется. Порт внутреннего сервиса закрыт всегда. Клиент отправляет одиночный аутентифицированный пакет (Single Packet Authorization) или последовательность стуков; межсетевой экран проверяет подпись и открывает доступ для конкретного адреса на короткое окно.
Что даёт. Невидимость сервиса для сканирования: до авторизации порта просто нет.
Плюсы. Убирает целый класс массовых атак — жертву сначала надо найти; дёшево, реализуется штатными средствами межсетевого экрана. Минусы. После открытия окна связь становится сквозной — разрыва нет, есть отложенное разрешение; уязвимо к повторам, если пакет не привязан ко времени и адресу; плохо сочетается с массовым клиентским доступом. Где уместен. Дополнительный слой перед административными интерфейсами. Как самостоятельный logical airgap — не годится.
Сводка по уровню 2
| Вариант | Кто инициирует | Синхронный ответ | Главный недостаток |
|---|---|---|---|
| Терминация TCP на прокси | Недоверенная сторона | Да | Слушающий порт внутри остаётся |
| Pull-модель | Доверенная сторона | Да | Состояние и нагрузка на внешний шлюз |
| Reverse-tunnel | Доверенная сторона | Да | Внутри туннеля — сквозной поток |
| Точка сопряжения в DMZ | Обе, исходящими | Да | Третья сторона и лишний хоп |
| SPA / port-knocking | Недоверенная сторона | Да | После открытия разрыва нет |
Уровень 3. Разрыв через посредник-хранилище
Стороны не общаются напрямую вообще: одна пишет в общее хранилище, другая читает из него. Хранилище становится единственным объектом, который видят обе зоны, и единственным местом, где применяются правила доступа.
3.1. Брокер сообщений
Как реализуется. Между сегментами ставится Redis, RabbitMQ, Kafka или NATS. Внешняя сторона кладёт запрос в очередь и ждёт ответ в персональной очереди по correlation ID; внутренняя забирает, выполняет и кладёт ответ.
Что даёт. Разрыв плюс демпфер: всплеск нагрузки и кратковременная недоступность исполнителя перестают быть отказом.
Плюсы. Модель простая и всем знакомая; права разделяются средствами брокера — продюсер может только писать; естественная устойчивость к всплескам. Минусы. Корреляцию, TTL и повторную обработку приходится делать руками; брокер сам становится потолком производительности и отдельным компонентом, который надо защищать и обновлять. Измерения на этом варианте — в статье про MVP: цена разрыва оказалась около 35% пропускной способности, а потолком стала однопоточность брокера. Где уместен. Асинхронные интеграции; сценарии, где нужен демпфер; быстрый старт до перехода на более узкий канал.
3.2. Файловый спул
Как реализуется. Общий каталог (SMB, NFS, локальный том), в который одна сторона кладёт файлы, а другая их забирает. Атомарность обеспечивается записью во временное имя и переименованием; целостность — контрольной суммой и подписью.
Что даёт. Обмен без единого сетевого протокола между сегментами: общий знаменатель — файловая система.
Плюсы. Работает где угодно, включая контуры без права на сетевые сервисы; тривиально журналируется и архивируется; естественно ложится на диод — то же самое, только «в одну сторону». Минусы. Задержка от сотен миллисекунд до минут; синхронный ответ требует опроса каталога; файловая система становится общей поверхностью атаки (гонки, символические ссылки, переполнение тома). Где уместен. Передача пакетов данных, отчётов, обновлений; сценарии, где надо быть совместимым с аппаратным диодом.
3.3. Объектное хранилище как почтовый ящик
Как реализуется. Тот же спул, но в S3-совместимом хранилище: внешняя сторона имеет право только PutObject в один префикс, внутренняя — только GetObject и DeleteObject из него. Разграничение задаётся политикой доступа.
Что даёт. Спул с внятной моделью прав и без общей файловой системы.
Плюсы. Права описываются декларативно и проверяемо; хранилище масштабируется само; версионирование и журнал доступа из коробки. Минусы. Задержка выше, чем у локального спула; появляется зависимость от внешнего сервиса, который часто находится вне обоих контуров; оплата по запросам делает опрос дорогим. Где уместен. Облачные и гибридные контуры; передача крупных артефактов; сценарии, где важен неизменяемый журнал переданного.
3.4. Таблица-мейлбокс в СУБД
Как реализуется. Обмен идёт через таблицу: внешняя сторона делает INSERT заявок, внутренняя выбирает их с блокировкой (SELECT ... FOR UPDATE SKIP LOCKED) и пишет результат в соседнюю таблицу. Права на схему разделены на уровне ролей.
Что даёт. Транзакционный обмен: заявка и её результат живут в одной ACID-истории.
Плюсы. Ничего нового ставить не надо, если СУБД уже есть; строгая консистентность и удобная выборка «что зависло»; аудит бесплатно. Минусы. База — тяжёлый посредник с большой поверхностью атаки; очередь в таблице живёт на опросе; при высоком темпе таблица превращается в очаг блокировок и вакуумирования. Где уместен. Корпоративные системы с уже развёрнутой СУБД и невысоким темпом обмена — заявки, задания, согласования.
3.5. Однонаправленная репликация и CDC
Как реализуется. Данные не передаются как сообщения — реплицируется само состояние: физическая репликация БД, поток изменений (CDC), периодическая выгрузка. Приёмная сторона доступна только на чтение.
Что даёт. Внутренние данные оказываются снаружи (или наоборот) без единого запроса от одной стороны к другой.
Плюсы. Читающая сторона вообще не может ничего изменить у источника; хорошо ложится на диод; нагрузка предсказуема и не зависит от числа клиентов. Минусы. Работает только для чтения — команды так не передашь; данные всегда немного отстают; наружу утекает структура внутренней модели данных. Где уместен. Витрины, отчётность, публикация справочников наружу, «зеркало» внутренней базы для внешних потребителей.
3.6. Разделяемая память между виртуальными машинами
Как реализуется. Оба сегмента — виртуальные машины на одном гипервизоре, и между ними нет виртуальной сети: обмен идёт через общий сегмент памяти (ivshmem) или сокет гипервизора (virtio-vsock). Сетевого стека в этой связи нет вообще.
Что даёт. Обмен без сети и без сетевых уязвимостей, с задержкой в микросекунды.
Плюсы. Самый быстрый из посредников; ни маршрута, ни порта, ни IP; изоляция обеспечивается гипервизором. Минусы. Обе стороны обязаны быть на одном хосте — масштабирование и катастрофоустойчивость страдают; протокол поверх памяти пишется вручную, включая синхронизацию; гипервизор становится общим доверенным элементом со своей историей уязвимостей. Где уместен. Компактные высоконагруженные стенды, встраиваемые решения, устройства «два контура в одной коробке».
3.7. Спул с антивирусом и CDR на пути
Как реализуется. К любому из предыдущих посредников добавляется обязательная стадия обработки: антивирусная проверка, разбор формата и пересоздание файла заново (Content Disarm and Reconstruction) — документ пересобирается без макросов, скриптов и активного содержимого.
Что даёт. Гарантию, что во внутренний сегмент попадает не тот же самый байтовый поток, что пришёл снаружи, а его очищенная реконструкция.
Плюсы. Снимает целый класс атак через содержимое файлов; результат наглядно объясняется аудитору; хорошо сочетается с ручным подтверждением. Минусы. Работает только для известных форматов; задержка от секунд до минут; лицензии на движки стоят денег; сам разборщик форматов — потенциально уязвимый код, который читает недоверенные данные. Где уместен. Ввод документов и обновлений в критичный контур; всё, где содержимое приходит от внешних людей, а не от системы.
Сводка по уровню 3
| Вариант | Посредник | Задержка | Чем платим |
|---|---|---|---|
| Брокер сообщений | Redis, RabbitMQ, Kafka | Единицы мс | Брокер как потолок и как объект защиты |
| Файловый спул | Каталог | Сотни мс — минуты | Опрос, гонки, общая ФС |
| Объектное хранилище | Бакет с политиками | Сотни мс | Внешний сервис, плата за запросы |
| Таблица-мейлбокс | СУБД | Десятки мс | Тяжёлый посредник, блокировки |
| Репликация и CDC | Поток изменений | Секунды | Только чтение, отставание |
| Разделяемая память | Гипервизор | Микросекунды | Один хост, ручной протокол |
| Спул с антивирусом и CDR | Каталог плюс обработка | Секунды — минуты | Лицензии, форматы, задержка |
Уровень 4. Прикладной и семантический разрыв
На этом уровне граница проходит не по трафику, а по смыслу: внутрь попадает не «то, что прислали», а «то, что разрешено» — сообщение, собранное заново по известной схеме. Варианты уровня 4 почти всегда надстраиваются над уровнями 1–3, а не заменяют их.
4.1. Контролируемый RPC с узкой схемой
Как реализуется. Между сегментами разрешён ровно один вызов с описанным контрактом — обычно gRPC с protobuf-схемой и взаимной аутентификацией по mTLS. Всё, что не укладывается в схему, отбрасывается парсером ещё до бизнес-логики.
Что даёт. Минимальную поверхность: вместо «любого HTTP» — конечный список полей известных типов.
Плюсы. Строгая типизация и генерация кода из схемы; низкая задержка; взаимная аутентификация сторон; backpressure и мультиплексирование достаются от HTTP/2. Минусы. Контракт надо проектировать и версионировать; управление сертификатами становится отдельной задачей; произвольный «прозрачный» трафик через такой канал не пропустишь — и это осознанная цена. Где уместен. Продуктовый мост между сегментами, когда набор операций известен и стабилен.
4.2. Протокольный прокси с пересборкой запроса
Как реализуется. Посредник разбирает прикладной протокол целиком и формирует внутрь новый запрос: только разрешённые заголовки, канонизированный путь, перепроверенная кодировка тела. Исходные байты дальше не идут.
Что даёт. Устойчивость к атакам на расхождение в разборе: request smuggling, двойное кодирование, обход по нестандартным заголовкам.
Плюсы. Внутренний сервис видит нормализованный запрос; удобное место для фильтрации и обогащения; работает с существующими клиентами без их изменения. Минусы. Прокси должен знать протокол досконально и обновляться вместе с ним; каждая новая версия HTTP — новая работа; разбор недоверенных данных сам по себе рискован. Где уместен. Публикация legacy-API наружу; контуры, где нельзя менять клиента, но нужна жёсткая нормализация.
4.3. Message-level security: подписанный конверт
Как реализуется. Безопасность переносится с транспорта на само сообщение: полезная нагрузка упаковывается в конверт с подписью и (при необходимости) шифрованием, с меткой времени и одноразовым идентификатором. Транспорт после этого не важен — хоть файл, хоть очередь, хоть диод.
Что даёт. Независимость доверия от канала: посредник может быть скомпрометирован, но подделать или прочитать сообщение он не сможет.
Плюсы. Один и тот же формат работает поверх любого транспорта — это то, что делает возможной смену транспорта без пересмотра модели угроз; защита от повторов через nonce; проверяемый источник сообщения. Минусы. Управление ключами и их ротация; накладные расходы на подпись каждого сообщения; сама криптография не мешает передать внутрь корректно подписанную гадость. Где уместен. Любой контур, где посредник находится вне зоны доверия; обязательный слой при обмене между организациями.
4.4. Схемная валидация и очистка полезной нагрузки
Как реализуется. На границе стоит валидатор: JSON Schema или protobuf-дескриптор, ограничения на размер и глубину вложенности, белый список полей, отбрасывание всего неизвестного. Всё, что не соответствует схеме, не доходит до внутреннего сервиса.
Что даёт. Внутренний сервис перестаёт быть первым, кто читает недоверенные данные.
Плюсы. Дёшево реализуется; ловит и атаки, и обычные ошибки интеграции; схема служит документацией контракта. Минусы. Схему надо поддерживать в актуальном состоянии, иначе она начнёт ломать легитимные запросы; глубокая валидация стоит процессорного времени на каждый запрос; семантику этим не проверишь — только форму. Где уместен. Везде, где через границу ходят структурированные данные. Практически обязательный слой.
4.5. Асинхронный контракт: ticket и callback
Как реализуется. Синхронный вызов заменяется двухфазным: клиент отправляет заявку и немедленно получает идентификатор (202 Accepted), а результат забирает позже опросом статуса или получает уведомлением. Внутренняя сторона обрабатывает заявку в своём темпе.
Что даёт. Свободу выбирать сколь угодно медленный и строгий транспорт разрыва — задержка перестаёт быть проблемой.
Плюсы. Совместим с диодом, спулом и ручным подтверждением; естественная устойчивость к всплескам; долгие операции перестают упираться в таймаут HTTP. Минусы. Меняет контракт для клиента — а значит, требует переписывания интеграций; появляется хранилище состояния заявок и политика его очистки; пользовательские сценарии «нажал и увидел» ломаются. Где уместен. Тяжёлые операции: обработка документов, длительные расчёты, всё, что и так не укладывается в секунды.
4.6. Human-in-the-loop и правило четырёх глаз
Как реализуется. Переход через границу требует явного решения человека, а для критичных операций — двух независимых подтверждений. Технически это очередь на согласование с интерфейсом оператора и журналом решений.
Что даёт. Смысловой контроль там, где автоматика бессильна: правило ловит не «неверный формат», а «неверное намерение».
Плюсы. Единственный способ поймать легитимный по форме, но недопустимый по сути запрос; персональная ответственность и полный аудит; хорошо принимается регуляторами. Минусы. Задержка измеряется минутами и часами; дорого; при потоке подтверждений люди начинают нажимать «ок» не глядя, и защита превращается в ритуал. Где уместен. Единичные критичные операции: изменение конфигурации промышленного контура, вынос данных наружу, экстренный доступ.
Сводка по уровню 4
| Вариант | Что проверяется | Синхронный ответ | Чем платим |
|---|---|---|---|
| RPC с узкой схемой | Соответствие контракту | Да | Проектирование контракта, сертификаты |
| Прокси с пересборкой | Корректность протокола | Да | Прокси обязан знать протокол |
| Подписанный конверт | Подлинность сообщения | Да | Управление ключами |
| Схемная валидация | Форма данных | Да | Поддержка схемы, процессорное время |
| Ticket и callback | Ничего нового, меняется контракт | Нет | Переписывание клиентов |
| Human-in-the-loop | Намерение | Нет | Минуты и часы, люди |
Уровень 5. Экзотика и пограничные варианты
Эти варианты редко попадают в продуктив, но нужны в каталоге: они очерчивают границы пространства решений и наглядно показывают, что «разрыв» — это свойство конструкции, а не название продукта. Все они помечены честно: демонстрационные либо узкорегламентные.
5.1. Оптический канал экран — камера и QR-цепочки
Как реализуется. Отправляющая сторона выводит данные на экран последовательностью QR-кодов, принимающая снимает их камерой и распознаёт. Поток кодируется с избыточностью (фонтанные коды), чтобы пережить пропуски кадров.
Что даёт. Однонаправленный канал, не требующий вообще никакого электрического соединения между сегментами.
Плюсы. Разрыв виден невооружённым глазом — буквально; обратный канал требует второй пары «экран — камера», то есть его отсутствие проверяется физически; собирается из готового железа. Минусы. Пропускная способность — десятки килобайт в секунду в лучшем случае; чувствительность к свету и фокусу; сложность синхронизации. Демонстрационный вариант. Где уместен. Показать принцип, вынести ключ или небольшой конфиг из изолированного контура, где запрещены любые кабели.
5.2. Печать и скан: «бумажный диод»
Как реализуется. Данные печатаются в машиночитаемом виде (штрихкоды, QR, OCR-шрифт) и сканируются на другой стороне. Между сегментами — бумага.
Что даёт. Разрыв, при котором носитель информации в принципе не может нести исполняемый код в электронном виде.
Плюсы. Абсолютная наглядность и полный «физический аудит»: перенесённое можно подшить в папку; невозможна передача скрытых потоков вне видимого содержимого. Минусы. Килобайты на лист; ошибки распознавания; полностью ручной процесс. Узкорегламентный вариант. Где уместен. Регламенты, где перенос обязан быть документально оформлен: ключи, акты, единичные конфигурации.
5.3. Акустический канал
Как реализуется. Модем на звуковой карте: одна сторона проигрывает модулированный сигнал (в том числе ультразвуковой), другая слушает микрофоном. По сути возврат к телефонным модемам, только по воздуху.
Что даёт. Передачу данных между машинами, у которых нет ни сети, ни съёмных носителей.
Плюсы. Не требует никакого дополнительного оборудования — динамик и микрофон есть везде; канал легко физически отключить, вынув устройство. Минусы. Единицы килобит в секунду; шум и переотражения; главное — это в первую очередь известный вектор утечки, а не транспорт: именно так данные выносят из изолированных контуров. Демонстрационный вариант. Где уместен. Исследования и демонстрации. В продуктиве присутствует ровно наоборот — как угроза, которую блокируют, отключая аудиоустройства.
5.4. Светодиод и фотодиод: канал на индикаторах
Как реализуется. Информация модулируется миганием светодиода — индикатора активности диска, статуса устройства, — а на другой стороне снимается фотодиодом или камерой. Родственники: тепловые, электромагнитные и вибрационные каналы.
Что даёт. Передачу без единого штатного интерфейса, только через побочное излучение.
Плюсы. Показывает нижнюю границу того, что вообще считать «отсутствием связи»; полезен как модель угроз при проектировании изолированных помещений. Минусы. Биты в секунду; требует прямой видимости; никакой практической ценности как транспорт. Пограничный вариант, приведён как иллюстрация. Где уместен. Оценка рисков side-channel-утечек, а не построение обмена.
5.5. Распределённый реестр как арбитр перехода
Как реализуется. Факт передачи фиксируется в общем журнале (DLT или просто в append-only-журнале с подписями и хеш-цепочкой), а стороны обмениваются не данными, а записями о них: «такой-то пакет с таким-то хешем разрешён к переносу такими-то подписантами».
Что даёт. Неотрекаемость: ни одна сторона не может задним числом отрицать факт и содержание переноса.
Плюсы. Сильная гарантия целостности и авторства решений; удобно, когда стороны принадлежат разным организациям и не доверяют друг другу; журнал переживает компрометацию любой из сторон. Минусы. Полноценный блокчейн здесь почти всегда избыточен: те же свойства даёт подписанный hash-chain журнал за долю усилий; задержка консенсуса; ещё одна инфраструктура. Узкорегламентный вариант. Где уместен. Межведомственный и межорганизационный обмен с юридически значимым журналом.
5.6. Курьерская доставка носителя по регламенту
Как реализуется. Институционализированный sneakernet: носитель опечатывается, сопровождается актом, перевозится курьером по утверждённому маршруту и вскрывается комиссией на приёмной стороне.
Что даёт. Разрыв, встроенный не в сеть, а в организационный процесс, — с юридически оформленной цепочкой ответственности.
Плюсы. Работает между площадками без какой-либо связи вообще; пропускная способность по объёму огромна (диск в сумке — это десятки терабайт); цепочка хранения документирована. Минусы. Задержка от часов до суток; полностью ручной процесс; риски смещаются в физическую плоскость — подмена, копирование, потеря. Узкорегламентный вариант. Где уместен. Первичная загрузка данных в изолированный контур, регулярные архивные выгрузки, обмен между удалёнными площадками.
Сводка по уровню 5
| Вариант | Статус | Пропускная способность | Зачем в каталоге |
|---|---|---|---|
| Экран и камера, QR | Демонстрационный | Десятки КБ/с | Разрыв, видимый глазом |
| Печать и скан | Узкорегламентный | КБ на лист | Документально оформленный перенос |
| Акустический канал | Демонстрационный | Килобиты/с | Прежде всего — модель угрозы |
| Светодиод и фотодиод | Пограничный | Биты/с | Нижняя граница понятия «нет связи» |
| Реестр как арбитр | Узкорегламентный | Не транспорт | Неотрекаемость решений о переносе |
| Курьер по регламенту | Узкорегламентный | Терабайты за рейс | Обмен между площадками без связи |
Сводная таблица каталога
Все уровни на одной шкале. Оценки грубые и сравнительные: они нужны, чтобы выбрать направление, а не чтобы подставлять в расчёт.
Цвет ячейки — это оценка значения внутри своей колонки, от благоприятного к плохому:
Шкала у каждой колонки своя: в «строгости» и «зрелости» зелёное — это больше, а в «задержке» и «стоимости» зелёное — это меньше.
Из таблицы видно главное ограничение всего пространства: колонка «синхронный ответ» уверенно заполняется «да» только на уровнях 2 и 4 — и это ровно те два уровня, которые комбинируются друг с другом без потерь. Всё, что строже, синхронный вызов внешнего клиента не обслуживает в принципе.
Что дальше
Из каталога напрямую вытекает прикладной вопрос: где на этой карте стоит Netgap сегодня, какие позиции каталога имеет смысл реализовать дальше и от каких стоит отказаться сознательно. Это отдельный разговор, и он вынесен в следующий пост — «Куда развивать Netgap: размышления о направлениях и порядке работ».
Здесь зафиксирую только вывод, который относится к самому каталогу, а не к продукту: строгость изоляции стоит выбирать не максимальную, а достаточную для сценария — и дальше вкладываться в то, чтобы выбранный уровень был реализован без дыр.
Это третий технический пост серии. Ранее: измерения MVP и локализация узкого места и каталог оптимизаций logical airgap.