ЕГИС ОТБ для речных круизов: интеграция АЦБПДП с задержкой ≤30 минут
- ЕГИС ОТБ
- АЦБПДП
- транспортная безопасность
- 152-ФЗ
- Минтранс
- интеграции
ЕГИС ОТБ — Единая Государственная Информационная Система Обеспечения Транспортной Безопасности — обязательный канал передачи персональных данных пассажиров и экипажа в АЦБПДП Минтранса для всех видов пассажирских перевозок. Регламентная задержка — не более 30 минут от изменения данных в системе бронирования до их появления в централизованной базе.
Что такое ЕГИС ОТБ и кому это касается
Полная расшифровка: Единая Государственная Информационная Система Обеспечения Транспортной Безопасности. Цель — учёт и контроль персональных данных пассажиров и экипажа транспортных средств в интересах антитеррористической защищённости (Постановление Правительства РФ № 1208).
Кто обязан передавать данные:
- Водный транспорт — пассажирские суда (включая круизные и прогулочные).
- Железнодорожный транспорт — пассажирские перевозчики.
- Авиация — все коммерческие авиаперевозки.
- Автотранспорт — пассажирские перевозки на регулярных межрегиональных и международных маршрутах.
Куда уходят данные: в АЦБПДП (Автоматизированные централизованные базы персональных данных о пассажирах и персонале) — единое хранилище Минтранса, к которому имеют доступ силовые ведомства.
Нормативная база
| Документ | Что регулирует |
|---|---|
| Постановление Правительства РФ № 1208 | Порядок и требования к передаче ПД пассажиров |
| TU IVpostinfMoRe v13 | Технический регламент взаимодействия систем |
| Requirements ACDPDP MORE rus | Требования к структуре передаваемых данных |
| Руководство по API в4.1 | Текущая версия протокола взаимодействия |
| 152-ФЗ | Защита персональных данных пассажиров и экипажа |
АЦБПДП — технические требования
- Форматы: CSV / XML (зависит от типа сообщения и канала).
- Кодировка: строго UTF-8 без BOM. Любая другая — отказ при приёме.
- Транспорт: mTLS (взаимная TLS-аутентификация) поверх REST или FTP-шлюза в зависимости от типа потока.
- SLA: передача данных с задержкой ≤ 30 минут от момента создания/изменения брони.
- 152-ФЗ: анонимизация имён в формате personRef «Имя Отчество Ф.», шифрование пакетов ZIP+GOST 28147-89, журналирование доступа.
Архитектура нашей интеграции
Реализована production-интеграция для крупного оператора речных круизов. Стек:
- Очередь задач: Hatchet TS SDK v1 поверх Supabase Postgres 17 (отдельная schema, но та же БД).
- Worker: dedicated
egis-otb-workerв hermes-stack docker-compose с retry/backoff и идемпотентностью. - Сертификаты mTLS: автоматическое продление через Caddy + хранение приватных ключей в режиме
chmod 600. - Резервирование: все исходящие пакеты архивируются в S3-совместимое хранилище (для верификации и расследования инцидентов).
Этапы внедрения (6 месяцев)
| Этап | Сроки | Содержание |
|---|---|---|
| Инфраструктура | 01.12.2025 — 31.12.2025 | Получение mTLS-сертификатов, настройка шлюзов FTP+REST, тестовый стенд |
| Ядро системы | 01.01.2026 — 31.01.2026 | Схема БД, валидация ПД на стороне приложения, очереди и retry-логика |
| Интеграции | 01.02.2026 — 28.02.2026 | Подключение к АЦБПДП, smoke-тесты с тестовым контуром Минтранса |
| Тестирование | 01.05.2026 — 31.05.2026 | E2E с реальными бронями, нагрузочное, fault injection, сертификация |
Workflow в коде (упрощённо)
// hermes-stack/egis-otb-worker/src/workflows/sync-passenger.ts
import { defineWorkflow } from '@hatchet-dev/typescript-sdk/v1';
export const syncPassengerToACDPDP = defineWorkflow(hatchet)
.step('validate', async ({ input }) => {
const errors = validatePD(input.passenger); // 152-ФЗ + personRef anonymization
if (errors.length) throw new Error(`PD validation failed: ${errors.join(', ')}`);
return { passenger: anonymize(input.passenger) };
})
.step('encode', async ({ parentOutput }) => {
const csv = toUTF8CSV(parentOutput.passenger); // строго UTF-8 без BOM
const encrypted = await zipAndEncrypt(csv, GOST_KEY); // ZIP + GOST 28147-89
return { payload: encrypted };
})
.step('transmit', async ({ parentOutput }) => {
// mTLS POST в АЦБПДП с idempotency-key = SHA256(passenger.id + version)
const res = await acdpdp.send(parentOutput.payload, {
mTLS: { cert: process.env.MTLS_CERT, key: process.env.MTLS_KEY },
idempotencyKey: hash(input.passenger.id + input.version),
});
return { receipt: res.receiptId };
})
.step('persist', async ({ parentOutput }) => {
// сохраняем receiptId в БД для аудита и поиска по запросу регулятора
await db.acdpdpReceipts.insert({ receiptId: parentOutput.receipt, ... });
});
Типовые нарушения и как мы их избежали
| Проблема | Решение |
|---|---|
| Превышение SLA 30 минут при пиковых нагрузках | Priority queue на Hatchet, выделенный worker pool на пиковые часы |
| Ошибки кодировки (cp1251 вместо UTF-8) | Строгая валидация кодировки до отправки + fallback с явной перекодировкой |
| Ротация mTLS-сертификатов без даунтайма | Caddy auto-TLS + симлинк в /etc/ssl/private/egis-otb-current.pem |
| Дублирующие отправки при retry | Idempotency-Key = SHA256(passenger.id + version) |
| Неконсистентность данных при отмене брони | Compensating workflow: cancel-passenger отменяет ранее отправленную запись |
Что мы из этого вынесли
- Hatchet workflow с явным state machine в БД упрощает аудит — на каждый шаг есть запись в
crm_activities. При запросе регулятора видим всю историю. - Идемпотентность с самого начала — дешевле, чем чинить дублирующие отправки потом. Idempotency-Key должен быть детерминирован, а не случайный UUID.
- Тестовый контур Минтранса работает по другим правилам — пакеты, отвергнутые на тесте, могут пройти на проде, и наоборот. Закладывайте время на pre-prod валидацию (2-3 недели).
Ссылки
- Постановление Правительства РФ № 1208 — порядок передачи ПД в АЦБПДП
- 152-ФЗ — обработка персональных данных
- Astral — обязательные ЭПД 2026 (2025-12)
- Hatchet TS SDK v1 docs