Слоистая архитектура

Экосистема состоит из пяти слоёв. Нижний слой обслуживает верхний; верхний слой не знает внутреннего устройства нижнего и общается с ним только через его контракт.

СЛОЙ 4 — ОТРАСЛЕВЫЕ ПРОДУКТЫ (vertical)
    ring.dgov.mn          Ring System — реинжиниринг процессов
    hurdan.dgov.mn        Платформа «Хурдан» — доставка и контроль услуг
    developer.gerege.mn   Developer Portal (есть версия для dgov)
    wallet.gerege.mn      Gerege Wallet — цифровой кошелёк гражданина

СЛОЙ 3 — ОСНОВА ПЛАТФОРМЫ
  -- 2-е поколение: Nexus — модульный монолит, магазин приложений
    nexus.gerege.mn       Gerege Nexus — upstream, 8 модулей
    eduge.mn              Eduge.mn — отраслевой форк бренда
    (домен ожидается)     Gerege SSO — форк, сосредоточенный на входе
  -- 1-е поколение: Template — по форку на репозиторий
    template.gerege.mn    Gerege Template Platform
    template.dgov.mn      Government Template Platform V3.0 (+ порт на Node.js)
    gerege.mn             Gerege Platform (сам является провайдером SSO)
    → Clean Architecture Go + Next.js BFF + конвейер Gemini AI

СЛОЙ 2 — АУТЕНТИФИКАЦИЯ / SSO (провайдер OIDC)
    sso.gerege.mn   Gerege SSO          sso.dgov.mn      Government SSO
    dan.gerege.mn   DAN Gateway         gsign.gerege.mn  G-Sign
    → собственный код OAuth2/OIDC на Go (Hydra полностью заменён), одна БД
    → eID-прокси: разрешённые сервисы eID только зарегистрированным приложениям

СЛОЙ 1 — ЯДРО IDENTITY / PKI
    eID Mongolia (eid-platform-mn)
    server (Go) · web · admin · iOS SDK · Android SDK · macOS/Windows
    пороговая ECDSA 2-of-2 · два ключа / два сертификата (PIN1 вход / PIN2 подпись)
    CA · OCSP · CRL · TSA

СЛОЙ 0 — ОБМЕН ДАННЫМИ
    X-Road instance MN — central server, security-серверы
    Смежный сервис: xyp.gerege.mn (справки о юридических лицах)

Слой 0 — Обмен данными

Что это: стандартизованный канал обмена данными между организациями — X-Road (инстанс MN).

Роль: организации-участники вызывают сервисы друг друга с подтверждением подлинности, подписью и отметкой времени. Каждый security-сервер представляет своего участника, а central server подписывает и распространяет список доверия (globalconf).

Особая связь: eID Mongolia выполняет для X-Road роль удостоверяющего центра (CA) — то есть слой 1 даёт слою 0 корень доверия.

Статус: Частично Central server и первые security-серверы подняты, топология определена; внедрение в широкую эксплуатацию продолжается.

Слой 1 — Ядро identity / PKI

Что это: eID Mongolia — национальная платформа eID (в духе Smart-ID / eIDAS).

Роль: идентифицировать граждан и организации, пропускать их в системы и давать возможность поставить юридически значимую подпись. Плюс весь жизненный цикл сертификата: выпуск (CA), проверка действительности (OCSP/CRL), отметка времени (TSA).

Ключевые решения:

• Пороговая ECDSA 2-of-2 — закрытый ключ подписи не существует целиком ни у одной из сторон.
• Два ключа / два сертификата — PIN1 → вход, PIN2 → подпись.
• Идентификатор — civil_id; ETSI ID для физического лица — PNOMN-<civil_id>, для организации — NTRMN-<...>.
• KYC — через DAN, с проверкой живости по распознаванию лица.

Кто использует: слой 2 (SSO) напрямую; слои 3–4 — через SSO.

Статус: Production

Слой 2 — Аутентификация / SSO

Что это: провайдеры OAuth2/OIDC — Gerege SSO (sso.gerege.mn) и Government SSO (sso.dgov.mn), а также смежные сервисы DAN Gateway и G-Sign.

Роль — три вещи:

1. Провайдер идентичности — RP получают кнопку Sign in with Gerege. Authorization code + PKCE (S256), ротируемый refresh token (с обнаружением повторного использования), client_credentials.
2. eID-прокси — разрешённые сервисы eID передаются только зарегистрированным приложениям. Приложение не обращается к eID напрямую.
3. Единственное место регистрации приложений — OAuth client и client secret создаются и живут только здесь.

Без Hydra

Ранее использовался Ory Hydra; теперь необходимые механизмы переписаны на собственном коде Go. Отдельная БД Hydra слита с основной. В результате снизились сразу три вещи: внешние зависимости, сложность миграций и стоимость эксплуатации.

Статус: Production

Слой 3 — Основа платформы

У этого слоя теперь два поколения. Оба работают в production, и переход между ними идёт прямо сейчас.

2-е поколение — Gerege Nexus Production

Что это: платформа-модульный монолит — бизнес-модули реализуют Go-контракт Module и компилируются в один бинарник; какие приложения активны у арендатора, решает магазин приложений (app_installations) в PostgreSQL.

Что изменилось: в 1-м поколении новый продукт означал форк шаблона. В Nexus новый продукт — это обычно новый модуль, а для бренда — форк upstream, обновляемый слиянием из него.

	1-е поколение (Template)	2-е поколение (Nexus)
Новый продукт	Форк шаблона	Написать модуль либо сделать форк под бренд
Распространение	По одному развёртыванию на репозиторий	По арендаторам, через магазин приложений
Как перемещается код	Пакеты open-gerege-core · @gerege/ui-core	Upstream → форки сливают из него
Вызовы между модулями	HTTP	Внутрипроцессные вызовы Go

Текущие форки: nexus.gerege.mn (upstream, эталонное развёртывание) · eduge.mn (сфера образования) · Gerege SSO (сосредоточен на слое входа, домена пока нет).

Восемь готовых модулей: Contacts · Products · Inventory · Billing & e-Barimt · Digital Documents · Developer Portal · PDF E-Sign (eID PIN2) · государственные услуги (настраиваемый процесс, иерархия, SLA).

Nexus не заменяет слой 2

В Nexus есть собственный провайдер OAuth2/OIDC, но он обслуживает арендаторов и сторонних клиентов именно этого развёртывания. В масштабе экосистемы единственный путь к идентификации гражданина — по-прежнему слой 2: Nexus тоже никогда не обращается к eID напрямую.

1-е поколение — Template Platform Production

Что это: Template Platform — готовая к production основа для создания цифровых услуг; а также Gerege Platform — расширенный вариант, способный сам быть провайдером SSO.

Роль: при запуске новой услуги следующее доступно с первого дня:

• аутентификация через eID и Google, сессии (JWT access + ротация refresh),
• организации и членство, защищённые через RLS,
• RBAC (superadmin → admin → manager → user), журнал аудита,
• API-шлюз (services / routes / consumers / API key / policy + телеметрия),
• конвейер ИИ (Gemini) — чат, STT/TTS, перевод, база знаний,
• жёсткий базовый уровень безопасности (CSP/HSTS, allow-list CORS, rate limit, RLS),
• наблюдаемость (OpenTelemetry + Prometheus + структурированные логи).

Статус: Production

Слой 4 — Отраслевые продукты

Что это: реальные продукты, выросшие из Template.

Продукт	Назначение	Статус
Developer Portal	Каталог API, вход в регистрацию приложений	Production
Gerege Wallet	Цифровой кошелёк гражданина	Частично
Ring System	Реинжиниринг процессов государственных услуг	Частично
Платформа «Хурдан»	Доставка услуг и контроль над ней	Production

Ring и Хурдан работают на государственной линии.

Правило зависимостей

Весь код экосистемы соблюдает следующее направление зависимостей:

graph TD
    L4["Слой 4 — Отраслевые продукты"] --> L3["Слой 3 — Основа платформы"]
    L3 --> L2["Слой 2 — SSO / OIDC"]
    L2 --> L1["Слой 1 — eID / PKI"]
    L2 -.->|"справки"| L0["Слой 0 — X-Road"]
    L1 -.->|"роль CA"| L0

Правило: нельзя обращаться через слой. Например, приложение слоя 4 не обращается напрямую к eID — только через SSO. Это одновременно удерживает учётные данные в одном месте и не разрывает цепочку аудита.

Единственная разрешённая связь «вниз» — роль eID как CA для X-Road; она образует корень доверия и потому выведена из-под правила слоёв.