Шлюзы, trace_id, route_id и контролируемый обмен

Маршрутизация (routing) в суверенной цифровой инфраструктуре — это управляемый путь цифрового события от источника к получателю, через доверенные шлюзы, сетевые зоны, трассировку и контроль доступа.

Юридически значимый цифровой обмен не должен происходить хаотично, через неучтенные каналы или серые маршруты. Каждый документ, запрос, подтверждение, архивная квитанция или DLT-событие должны иметь официальный маршрут, технический след и проверяемую историю прохождения.

Ключевая формула Событие движется не просто по сети. Оно проходит по контролируемому маршруту: source -> gateway -> route_id -> trace_id -> destination -> proof -> log -> verification.

Коротко за 30 секунд

Routing — это слой контролируемого обмена между системами, сервисами, ЦОДами, узлами доверия и участниками цифровой экосистемы.

Он определяет, через какой шлюз проходит событие, какой маршрут ему назначен, как оно трассируется, где фиксируется, кто имеет право его передать, кто имеет право его принять и как затем проверить факт прохождения маршрута.

trace_id показывает сквозной след события через все системы. route_id показывает утвержденный маршрут обмена. Шлюзы контролируют вход, выход, безопасность, формат, полномочия и передачу события дальше.

Так создается сетевой порядок для доверенной цифровой инфраструктуры: документы, доказательства, архивные квитанции, DLT-события и проверочные запросы проходят по официальным каналам, а не через неучтенные точки обмена.

Что такое Routing в архитектуре доверия

Routing (маршрутизация) — это совокупность правил, шлюзов, сетевых зон, идентификаторов маршрута и журналов, которые управляют прохождением цифрового события между участниками инфраструктуры.

В обычной IT-системе маршрутизация часто означает техническую доставку запроса от одного сервиса к другому. В архитектуре доверия routing имеет более широкий смысл: он фиксирует правовой, технический, сетевой и доказательный контекст движения события.

Для доверенной цифровой экосистемы важно не только то, что документ был создан. Важно знать, как он прошел через систему, через какой шлюз был передан, кому был направлен, где был проверен, где был зафиксирован, где был архивирован и кто имел доступ к его маршруту.

Зачем нужен контролируемый обмен

Контролируемый обмен нужен для того, чтобы юридически значимые события не терялись, не проходили через неучтенные каналы и не становились зависимыми от слабых интеграций между отдельными системами.

• исключить серые маршруты обмена данными;
• зафиксировать путь каждого юридически значимого события;
• разделить зоны доступа и зоны ответственности;
• проверять, кто отправил событие и кто его получил;
• защитить обмен от подмены, несанкционированной передачи и потери контекста;
• связать цифровой документ с доказательством, DLT-записью и архивной квитанцией;
• обеспечить наблюдаемость и расследуемость инцидентов;
• создать техническую основу для доверенной интеграции между разными участниками экосистемы.

Основные элементы routing-слоя

Элемент	Русское описание	Роль в архитектуре
Gateway	Шлюз	Контролирует вход, выход, формат, безопасность и передачу события.
trace_id	Сквозной идентификатор трассировки	Позволяет увидеть полный путь события через все системы и сервисы.
route_id	Идентификатор утвержденного маршрута	Определяет, по какому разрешенному маршруту должно пройти событие.
source	Источник события	Система, пользователь, сервис или узел, который инициирует обмен.
destination	Получатель события	Система, сервис, архив, DLT-узел или проверяющая сторона.
policy	Политика обмена	Определяет, кто имеет право отправлять, получать и проверять событие.
audit log	Журнал аудита	Фиксирует действия, статусы, ошибки и контрольные точки маршрута.
proof	Доказательство	Связывает маршрут события с хэшем, подписью, временем и квитанциями.

Шлюзы в суверенной инфраструктуре

Шлюз (gateway) — это контролируемая точка входа или выхода цифрового события. Шлюз не просто передает запрос. Он проверяет, можно ли это событие принять, обработать, передать дальше, зафиксировать или вернуть отправителю.

В архитектуре sovereign.satcom.kg шлюзы являются ключевыми инфраструктурными элементами. Они связывают участников экосистемы, ЦОДы, узлы доверия, DLT-сеть, архивные сервисы, verification-сервисы и внешние интеграции.

Типы шлюзов

Тип шлюза	Назначение
API Gateway / API-шлюз	Единая точка управляемого API-доступа к сервисам инфраструктуры.
Trust Gateway / шлюз доверия	Проверяет событие, полномочия, формат и готовность к фиксации в DLT.
Archive Gateway / архивный шлюз	Передает архивные пакеты в Арбитражный Архив и возвращает архивные квитанции.
Verification Gateway / шлюз проверки	Обрабатывает запросы на проверку документа, DLT-квитанции, архивной квитанции или статуса.
Routing Gateway / маршрутизационный шлюз	Определяет разрешенный маршрут обмена и назначает route_id.
Security Gateway / шлюз безопасности	Проверяет доступ, токены, сертификаты, устройства, ключи и сетевые политики.
Integration Gateway / интеграционный шлюз	Связывает государственные, корпоративные и инфраструктурные системы через управляемые интеграции.
Event Gateway / событийный шлюз	Принимает события от систем-источников и передает их в event bus, DLT или аналитику.

Что такое trace_id

trace_id — это сквозной идентификатор трассировки цифрового события. Он позволяет связать между собой все действия, которые произошли с событием в разных системах, шлюзах, сервисах и узлах.

Если событие прошло через несколько сервисов, каждый сервис добавляет свои журналы и статусы, но trace_id остается единым. Благодаря этому можно восстановить полный путь: где событие возникло, через какой шлюз прошло, где было проверено, куда передано, где зафиксировано, где архивировано и где проверено повторно.

• показывает сквозной путь события;
• связывает журналы разных систем;
• помогает расследовать ошибки и инциденты;
• позволяет доказать, что событие прошло через утвержденный контур;
• упрощает аудит, мониторинг и техническую поддержку;
• связывает документ, DLT-квитанцию, архивную квитанцию и verification-запрос.

Пример Один договор может иметь document_id, один или несколько event_id, общий trace_id для маршрута обработки и отдельные receipt_id для DLT и Архива.

Что такое route_id

route_id — это идентификатор разрешенного маршрута обмена. Он показывает не просто фактический путь события, а утвержденную схему, по которой событие должно пройти.

route_id нужен, чтобы отличать допустимый маршрут от несанкционированного обмена. Например, налоговое событие, архивная квитанция, проверочный запрос или DLT-событие должны проходить через определенные шлюзы и зоны, а не напрямую между случайными системами.

route_id связывает маршрут с правилами: кто может инициировать обмен, какие шлюзы обязательны, какие проверки выполняются, какие зоны задействованы, какие журналы создаются и какие подтверждения должны быть получены.

• определяет разрешенный путь обмена;
• связывает событие с маршрутом и политикой доступа;
• указывает обязательные шлюзы и контрольные точки;
• помогает обнаружить нарушение маршрута;
• упрощает стандартизацию межсистемного обмена;
• создает основу для доказуемой сетевой дисциплины.

Разница между trace_id и route_id

Параметр	trace_id	route_id
Смысл	Фактическая трассировка события	Утвержденный маршрут обмена
Отвечает на вопрос	Где прошло событие?	Как событие должно было пройти?
Используется для	Логов, мониторинга, расследований	Политик, контроля маршрута, комплаенса
Пример	TRACE-2026-000001	ROUTE-DOC-ARCHIVE-001
Связь	Один trace_id может ссылаться на route_id	Один route_id может использоваться многими событиями

Принцип контролируемого обмена

Контролируемый обмен строится на простой логике: любое юридически значимое событие должно пройти через известный источник, доверенный шлюз, утвержденный маршрут, проверку прав, журналирование, доказательную фиксацию и подтверждение доставки.

1. Система-источник создает событие или документ.
2. Событию присваивается event_id и trace_id.
3. Маршрутизатор определяет route_id.
4. Security Gateway проверяет доступ, устройство, токен, сертификат или ключ.
5. Trust Gateway проверяет формат, полномочия и контекст события.
6. Событие получает криптографическое доказательство: hash, подпись, timestamp.
7. При необходимости доказательство передается в DLT-сеть.
8. Архивный пакет передается через Archive Gateway.
9. Получатель принимает событие и фиксирует статус.
10. Verification Gateway позволяет проверить событие, маршрут, DLT-квитанцию и архивную квитанцию.

Сетевые зоны

Контролируемая маршрутизация невозможна без разделения инфраструктуры на сетевые зоны. Каждая зона выполняет свою роль и имеет отдельные правила доступа, мониторинга и обмена.

Сетевая зона	Назначение
Public Access Zone / зона публичного доступа	Точки входа для пользователей, сайтов, публичных API и verification-запросов.
DMZ / демилитаризованная зона	Буферная зона между внешним доступом и внутренними сервисами.
Application Zone / прикладная зона	Сервисы документов, кабинеты, порталы, workflow и прикладная логика.
Integration Zone / интеграционная зона	Шлюзы, API, event bus, интеграция с внешними и внутренними системами.
Trust Zone / зона доверия	Trust Gateway, proof-сервисы, проверка полномочий, подготовка событий к DLT.
DLT Zone / зона DLT	Узлы распределенного реестра доказательств и сервисы фиксации событий.
Archive Zone / архивная зона	Арбитражный Архив, архивные пакеты, archive receipt, долгосрочное хранение.
Management Zone / зона управления	Администрирование, мониторинг, SIEM/SOC, журналы, аудит и управление конфигурациями.
Backup / DR Zone / резервная зона	Резервное копирование, аварийное восстановление и резервные контуры.

Официальные домены и маршруты

В суверенной инфраструктуре домен является не только адресом сайта. Он становится элементом цифровой идентичности сервиса, организации, узла, шлюза или доверенного контура.

Маршрут должен быть связан с официальной доменной идентичностью. Это позволяет человеку и машине понимать, какой сервис участвует в обмене, в какой зоне он находится, какие права имеет и как проверить его принадлежность к доверенной инфраструктуре.

• домены используются как понятные цифровые адреса;
• поддомены могут обозначать сервисы, зоны, узлы и шлюзы;
• сертификаты и ключи связывают домены с криптографической идентичностью;
• маршруты должны быть описаны и контролируемы;
• юридически значимый обмен не должен идти через неизвестные адреса или неучтенные точки.

Публичные IP и управляемая маршрутизируемость

Публичный IP в такой архитектуре не означает открытый и незащищенный доступ. Он означает, что сетевой адрес является управляемым, наблюдаемым, маршрутизируемым и включенным в официальный контур инфраструктуры.

Для юридически значимого обмена важно, чтобы путь события был понятным: от какого домена, через какой IP-контур, через какой шлюз, в какую сетевую зону, к какому получателю и с каким статусом.

Закрытые внутренние адреса могут использоваться внутри зон, но внешние и межзоновые взаимодействия должны быть описаны, защищены, трассируемы и подчинены правилам маршрутизации.

Наблюдаемость и аудит маршрутов

Routing-слой должен быть наблюдаемым. Это означает, что администратор, оператор безопасности или проверяющая сторона могут увидеть не содержание документа, а технический путь и статус события.

• когда событие было создано;
• через какой шлюз прошло;
• какой route_id был применен;
• какой trace_id связывает все операции;
• какие проверки выполнены;
• какие ошибки возникали;
• какие узлы подтвердили событие;
• передано ли событие в DLT;
• принят ли архивный пакет;
• кто и когда выполнял проверку.

Связь routing-слоя с DLT

DLT фиксирует доказательство события. Routing-слой показывает, как это событие пришло к фиксации.

В DLT может быть записан не весь маршрут, а доказательная часть: event_id, trace_id, route_id, hash, timestamp, тип события и ссылка на архивную квитанцию. Этого достаточно, чтобы позже проверить, что событие было зафиксировано в рамках контролируемого маршрута.

Важно DLT не заменяет маршрутизацию. DLT фиксирует доказательство факта. Routing показывает управляемый путь, по которому факт был сформирован, проверен и передан.

Связь routing-слоя с Арбитражным Архивом

Арбитражный Архив принимает архивные пакеты через контролируемый маршрут. Это исключает ситуацию, когда документ или доказательство попадают в архив без понятного источника, полномочия, trace_id и route_id.

Archive Gateway должен фиксировать прием пакета, проверку хэша, связь с DLT-квитанцией, источник, маршрут, время получения и статус архивного хранения.

Связь routing-слоя с trust.asiainfo.kg

Сайт trust.asiainfo.kg объясняет, как создается цифровое доверие: идентичность, полномочия, доказательство, DLT, Арбитражный Архив и проверка.

Сайт sovereign.satcom.kg объясняет, на какой сетевой и инфраструктурной основе это доверие работает. Страница Routing связывает эти два уровня: доверенное цифровое событие должно не только иметь доказательство, но и пройти через контролируемый маршрут.

Пример логики маршрута

Ниже приведен условный пример маршрута цифрового документа. Это не описание конкретной закрытой системы, а публичная архитектурная модель.

1. Организация создает цифровой документ.

2. Система присваивает document_id и event_id.

3. Routing Gateway определяет route_id.

4. Security Gateway проверяет доступ и аутентификацию.

5. Trust Gateway проверяет полномочия, формат и контекст.

6. Proof Layer формирует hash, signature и timestamp.

7. DLT Gateway передает доказательство в DLT-сеть.

8. Archive Gateway передает архивный пакет в Арбитражный Архив.

9. Verification Gateway позволяет проверить документ, квитанцию и маршрут.

Пример структуры события маршрутизации

Для разработчиков и архитекторов routing-событие может описываться в структурированном виде. Ниже приведен пример логики данных, который может быть далее оформлен в RFC.

{
  "event_id": "EVT-2026-000001",
  "document_id": "DOC-2026-000001",
  "trace_id": "TRACE-2026-000001",
  "route_id": "ROUTE-DOC-TRUST-ARCHIVE-001",
  "source": "org.example.kg",
  "destination": "archive.trust.kg",
  "gateway_chain": [
    "api-gateway",
    "security-gateway",
    "trust-gateway",
    "archive-gateway"
  ],
  "event_type": "DOCUMENT_ARCHIVE_SUBMISSION",
  "timestamp": "2026-01-01T12:00:00+06:00",
  "status": "ACCEPTED",
  "proof_hash": "sha256:...",
  "dlt_receipt_id": "DLT-2026-000001",
  "archive_receipt_id": "ARCH-2026-000001"
}

Принципы routing-архитектуры

• Маршрут должен быть описан до начала обмена.
• Каждое событие должно иметь trace_id.
• Каждый тип обмена должен иметь route_id.
• Юридически значимые события должны проходить через доверенные шлюзы.
• Шлюз не должен быть только техническим прокси: он должен выполнять проверку политики, формата и безопасности.
• Маршрут должен быть журналируемым и проверяемым.
• События с высоким уровнем значимости должны связываться с DLT и Арбитражным Архивом.
• Сетевые зоны должны быть разделены по уровню доверия и назначению.
• Административные действия должны быть наблюдаемыми и аудируемыми.
• Нельзя смешивать рабочий обмен, архивный обмен, DLT-фиксацию и публичную проверку в одном неразделенном сетевом контуре.

Что получает цифровая экосистема

• понятные маршруты цифровых событий;
• контроль обмена между системами;
• отказ от неучтенных каналов передачи;
• снижение риска подмены данных;
• техническую основу для аудита и расследований;
• связь документа с DLT и Архивом;
• повышение доверия к цифровому обмену;
• масштабируемую модель подключения новых участников.

Что получает оператор инфраструктуры

• единое понимание маршрутов;
• управляемые точки входа и выхода;
• логическую карту обмена;
• мониторинг ошибок и задержек;
• контроль нагрузки на шлюзы;
• возможность расследовать инциденты;
• стандартизированные API и маршруты;
• основу для SLA и технической поддержки.

Карточки для страницы

Карточка	Заголовок	Текст
1	Trust Gateway	Проверяет цифровое событие перед фиксацией в DLT и передачей в Архив.
2	trace_id	Связывает все операции события в единую сквозную трассу.
3	route_id	Определяет утвержденный маршрут обмена между участниками инфраструктуры.
4	Controlled Exchange	Юридически значимый обмен проходит через официальные шлюзы и зоны.
5	Network Zones	Сетевые зоны разделяют доступ, данные, архив, DLT, управление и интеграции.
6	Observability	Маршруты событий наблюдаемы, журналируемы и доступны для аудита.

Заключение

Routing в суверенной цифровой инфраструктуре — это не просто техническая доставка пакетов. Это управляемый обмен юридически значимыми цифровыми событиями через доверенные шлюзы, trace_id, route_id, сетевые зоны, журналы, DLT-доказательства и архивные квитанции. Именно routing превращает обмен между системами в проверяемый, наблюдаемый и безопасный цифровой процесс.