Перейти к основному содержимому

Архитектура Netgap

Netgap — приложение для построения контролируемого обмена данными между недоверенным и доверенным сетевыми сегментами по паттерну logical airgap. С архитектурной точки зрения оно выносит прямое обращение к защищенному сервису в отдельный исполнительный контур и заменяет его управляемым, наблюдаемым и ограниченным каналом передачи запросов и ответов.

Главная задача Netgap — снизить связность между внешними клиентами и внутренними системами. Клиент взаимодействует с netgap-gateway, а доступ к целевому сервису выполняет netgap-executor, расположенный в сегменте, где такой доступ разрешен политиками сети и безопасности.

Основные компоненты​

netgap-gateway​

netgap-gateway принимает входящие HTTP-запросы от клиентов, назначает им идентификаторы корреляции, сохраняет состояние соединений и помещает запросы во внутреннюю очередь. Gateway не вызывает целевой сервис напрямую: он выступает пограничной точкой приема, буферизации и возврата ответа клиенту.

Внутри gateway используются несколько важных компонентов:

  • RequestGateway — HTTP-вход для клиентских запросов.
  • RequestQueue — очередь ожидающих обработки запросов.
  • ConnectionPool — хранилище активных клиентских соединений, которым нужно вернуть ответ.
  • RequestBridge — gRPC-интерфейс, через который executor забирает следующий запрос.
  • ResponseBridge — gRPC-интерфейс, через который executor возвращает результат обработки.

netgap-executor​

netgap-executor подключается к bridge-интерфейсам gateway, забирает запросы из очереди, выполняет обращение к целевому HTTP-сервису и отправляет ответ обратно в gateway. Executor отделен от внешнего клиентского контура и может запускаться в доверенном сегменте рядом с защищаемыми сервисами.

Такой подход позволяет не открывать целевой сервис наружу и не давать gateway прямой сетевой доступ туда, куда он не должен обращаться по архитектурным правилам.

Поток обработки запроса​

  1. Клиент отправляет HTTP-запрос в netgap-gateway.
  2. Gateway сохраняет клиентское соединение и кладет запрос в RequestQueue.
  3. netgap-executor через RequestBridge забирает следующий запрос.
  4. Executor вызывает целевой сервис во внутреннем или доверенном сегменте.
  5. Executor отправляет результат в gateway через ResponseBridge.
  6. Gateway находит исходное соединение в ConnectionPool и возвращает ответ клиенту.

Интеграция в существующую архитектуру​

Netgap встраивается как промежуточный слой между потребителями API и защищаемыми сервисами. Для внешних клиентов он выглядит как обычная HTTP-точка входа, поэтому интеграция обычно сводится к перенаправлению клиентского трафика на netgap-gateway.

Со стороны доверенного сегмента размещается netgap-executor, которому разрешен доступ к целевому сервису и к gRPC-интерфейсам gateway. Между сегментами остается только контролируемый канал gateway ↔ executor, а не произвольный доступ клиентов к внутренним системам.

В типовой инфраструктуре Netgap может быть размещен рядом с API Gateway, reverse proxy, service mesh или сетевыми ACL/firewall-правилами. Он не заменяет эти элементы, а дополняет их: принимает прикладной трафик, разрывает прямую сетевую связность и добавляет буферизацию, трассируемость и контролируемую доставку запросов.

Сценарии применения​

  • Изоляция доверенного сегмента: Netgap разрывает прямую L1-L4 связность между клиентом и внутренним сервисом и помогает снизить поверхность атак на сетевом и транспортном уровнях.
  • Демпфер для отказоустойчивости сервисов: очередь и удержание соединений позволяют сглаживать кратковременные всплески нагрузки и временную недоступность исполнителя.
  • Шлюз синхронный → асинхронный: для клиента взаимодействие выглядит как обычный HTTP-вызов, а внутри запрос проходит через очередь и асинхронное получение executor'ом.
  • Изоляция недоверенного софта: внешние приложения работают только с netgap-gateway и не получают сетевой маршрут к внутренним системам.
  • Передача логов и телеметрии из недоверенного сегмента: серверы, IoT-устройства или edge-компоненты могут отправлять данные через контролируемый канал в доверенную зону.

Архитектурный результат​

Netgap формирует явную границу между внешним и внутренним контуром. Gateway отвечает за прием и удержание клиентского взаимодействия, executor — за выполнение разрешенного вызова в доверенной зоне, а bridge-компоненты связывают эти части через ограниченный и наблюдаемый канал. За счет этого приложение помогает строить более безопасные и управляемые потоки обмена данными без прямой связности между клиентами и защищаемыми сервисами.