Ночь с 14 на 15 апреля: мой личный ответ на отключение СМЭВ

Я узнал об отключении не из новостей. Утром мне написал знакомый из небольшого банка: «всё упало, паспорта не проверяются, онлайн встал». В то время как раз дописывал обработку ошибок в smev4-rs, Rust-крейте для работы с СМЭВ 4.

Совпадение так совпадение.

Первые несколько часов ушли на то, чтобы понять, что вообще происходит. Минцифры говорило что транспорт в порядке. Жалобы шли и от тех, кто на СМЭВ 3, и от тех, кто переезжал на СМЭВ 4. Значит дело было не в версии протокола.

Параллельно в чатах разработчиков началось то, что я бы назвал «коллективным дебаггингом вслух». Люди постили статусы своих систем, пробовали разные эндпоинты, сравнивали коды ответов.

У одних была 403, у других 503 без тела, у третьих запросы просто висели. Это само по себе было информативно: такой разброс при одновременном сбое говорил о том, что проблема не в транспортном слое.

Когда стало ясно, что МВД закрыло доступ к своим данным как оператор ГИС, у меня в голове щёлкнуло: это именно тот сценарий, для которого я последние недели писал явное разграничение типов ошибок.

И вовсе не потому, что предвидел апрель.

Просто когда интегрируешься с государственными данными долго, понимаешь, что «СМЭВ лежит» и «МВД закрыло доступ» — это совершенно разные ситуации с разными последствиями. Первое чинится само, второе нет.

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

Почему всё встало, хотя транспорт работал

СМЭВ 4 по сравнению с третьей версией сделал одну хорошую вещь: ввёл централизованную ролевую модель управления доступом. Детальный контроль над тем, кто и к каким данным имеет доступ. Для безопасности это правильно.

Побочный эффект: одно административное действие на стороне владельца данных приводит к тому, что все 500+ подключённых организаций теряют доступ синхронно. Не нужно ничего ломать в транспорте.

Настройка в интерфейсе, и всё.

Это не баг СМЭВ 4, это следствие его архитектуры. И с этим нужно жить при проектировании интеграции.

Правовая ситуация, о которой мало кто говорит

Пока разворачивались события, я перечитал Положение ЦБ 444-П.

Пункт 2.2 положения и разъяснительное письмо Центробанка от декабря 2023 года довольно прямо говорят: для проверки паспорта в части сведений МВД при дистанционной идентификации есть только один законный способ — СМЭВ.

Других открытых систем с нужным правовым статусом попросту нет.

ЕСИА является идентификацией пользователя, а не проверкой документа. Сайт МВД — справочный сервис, он не годится для целей 115-ФЗ. Коммерческие агрегаторы не создают юридически достаточного основания.

То есть при недоступности СМЭВ банк физически не может выполнить требование закона и при этом не имеет законной альтернативы. Так себе ситуация.

20 апреля часть банков получила доступ обратно. Это были банки, которые смогли подтвердить наличие аттестата ФСТЭК по новым требованиям.

С 1 марта 2026 вступил в силу Приказ ФСТЭК №117. Он расширил требования к защите на системы, которые получают данные из государственных информационных систем.

Так как база МВД является государственной ИС, то и подключённые к ней банки тоже должны соответствовать требованиям. МВД воспользовалось этим как основанием для отключения.

Что конкретно ломается в интеграциях

Я поговорил с несколькими командами после инцидента. Общая проблема одна: любая ошибка внешнего сервиса схлопывается в один статус.

Что-то пошло не так, пишем в лог «smev error», идём дальше.

Для регуляторной отчётности это катастрофа.

Потому что «403 от МВД как результат административного решения» и «503 потому что агент перегружен» это принципиально разные события. У них разный путь деградации, разный смысл для комплаенса, разная строка в аудиторской записи.

Одна из команд, с которыми я говорил, обнаружила это именно 15 апреля: у них была «ошибка сервиса», они начали рестартить агенты, дёргать поддержку своего вендора и только через несколько часов выяснили, что проблема вообще не у них. Всё это время в логах была одна и та же нечитаемая строчка.

В smev4-rs я решил это через отдельный тип.

Классификатор принимает HTTP-статус и наличие заголовка Retry-After и возвращает enum:

let reason = UnavailableReason::from_http_status(403, false);
// ProviderAccessDenied — владелец закрыл доступ

let reason = UnavailableReason::from_http_status(503, true);
// QuotaOrRateLimit — 503 с Retry-After = лимит, а не деградация

let reason = UnavailableReason::from_http_status(503, false);
// ServiceDegraded — просто плохо

В обработке ошибок клиента это выглядит так:

match xml {
    Ok(body) => { /* всё хорошо */ }
    Err(SmevError::Unavailable { reason }) => {
        // сюда попадают 403, 423, 429, 503
        // reason содержит класс ошибки и статус
        log_incident("provider_unavailable", &reason);
        route_to_fallback();
    }
    Err(SmevError::Timeout) => {
        log_incident("transport_timeout", "polling_limit_reached");
        route_to_manual_queue();
    }
    Err(SmevError::Payload(msg)) if msg.contains("not found or expired") => {
        // тикет устарел — это не проблема доступности
        // это управление сессией на стороне вызывающего кода
        log_incident("ticket_expired", &msg);
    }
    Err(e) => {
        log_incident("unexpected_error", &e.to_string());
    }
}

Отдельно обрабатывается 404: истёкший тикет возвращается как SmevError::Payload, потому что это другой класс проблемы.

СМЭВ 3 и СМЭВ 4 возвращают разные данные

Это деталь, о которой я почти нигде не видел нормального объяснения.

СМЭВ 3 при проверке паспорта (вид сведений MVDR23) возвращает три поля: статус, код причины недействительности, дату с которой паспорт стал недействительным.

СМЭВ 4 (витрина rfp_check) возвращает только статус.

Это значит, что организация, которая мигрировала на СМЭВ 4 и отключила СМЭВ 3, потеряла два поля. Причём поля существенные: «паспорт недействителен потому что выдан новый» и «паспорт недействителен потому что в базе похищенных».

Это очень разные ситуации с разными действиями. Без кода причины разница неотличима.

Я думал об этом при проектировании роутера. Пока в smev4-rs его нет (запланировал на будущее), но архитектурно правильно держать обе версии за единым интерфейсом: СМЭВ 4 как основной канал, СМЭВ 3 для расширенных данных по мере необходимости.

Аудит попытки при отказе

Одна вещь, которую 15 апреля обнажил жёстко: у многих организаций нет записи о том, что попытка верификации вообще была сделана. А 115-ФЗ интересует не только успешный результат.

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

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

Не «система упала в 2:15», а «попытка верификации в 2:15:43.219, статус ProviderAccessDenied, перенаправлено в ручную очередь». Разница в том, что второе является доказательством, первое — просто лог.

В smev4-rs есть два варианта с аудитом. Простой, для одной попытки:

let fingerprint = SmevClient::request_fingerprint(canonical_request_bytes);

let (result, audit) = client
    .poll_response_audited(ticket, fingerprint)
    .await;

// audit создаётся независимо от исхода
// при Unavailable — маркер SMEV_UNAVAILABLE
// при Timeout — SMEV_TIMEOUT
// при успехе — хеш ответа

persist_audit_entry(&audit).await?;

И для серии попыток в одной сессии, с непрерывной цепочкой:

let nonce = SmevClient::request_fingerprint(canonical_request_bytes);

let (result1, audit1) = client
    .poll_response_chained(ticket1, nonce, None)
    .await;

// вторая ссылается на первую
let (result2, audit2) = client
    .poll_response_chained(ticket2, nonce, Some(&audit1))
    .await;

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

Хеш запроса вычисляется от канонического представления без персональных данных в явном виде. Это не просто privacy-by-design, это ещё и практично: хранить доказательство что именно запрашивалось, не храня сами данные.

Про дедупликацию и деньги

Постановление Правительства №1687 ввело тарификацию СМЭВ ещё в ноябре 2025. Плюс МВД хочет отдельный тариф за свои данные. Конкретные суммы ещё в нормативном процессе, но направление понятно.

Дублирующие запросы при любой тарификации выливаются в дополнительные расходы. request_fingerprint в крейте даёт детерминированный BLAKE3-хеш от входящих байтов. Один и тот же запрос, один и тот же хеш.

Можно использовать как ключ кеша:

let key = SmevClient::request_fingerprint(canonical_request_bytes);

if let Some(cached) = cache.get(&key, ttl_secs) {
    return Ok(cached);
}

let result = client
    .poll_response_with_config(ticket, config)
    .await?;

cache.set(&key, &result, ttl_secs);

Логика простая: один реальный запрос при первичной проверке, повторные сессии берутся из кеша. Это быстро окупится, когда появится тариф.

Про трейсинг

Клиент логирует через стандартный трейт tracing. Если у вас уже есть tracing-subscriber, работает просто:

DEBUG smev4_rs: starting SMEV queue polling ticket="tkt_abc" max_attempts=12
WARN  smev4_rs: SMEV provider unavailable ticket="tkt_abc" status=503 reason=ServiceDegraded
DEBUG smev4_rs: SMEV queue response ready ticket="tkt_xyz" attempts=3

warn для недоступности и таймаутов. Эти события должны триггерить алерты, а не просто попадать в дефолтный поток дебаг-логов.

Отдельно про аттестацию ФСТЭК

После 20 апреля стало очевидно: аттестат ФСТЭК перестал быть просто бумагой для службы безопасности. Он стал условием доступа к критически важной функции.

Приказ №117 изменил модель: теперь это не разовый проект, а непрерывный процесс с пересчётом показателей и жёсткими сроками устранения уязвимостей (критические за 24 часа). Для команд, которые привыкли раз в несколько лет обновлять аттестат, это другой операционный ритм.

Банки, у которых аттестат был актуальным, получили доступ обратно 20 апреля. У остальных простой продолжается.

В итоге

Сбой доступа в апреле 2026 года не является уникальным событием.

В 2021 году МВД объявило о закрытии офлайн-файла паспортов. В 2023 году закрыло. В 2026 году временно закрыло СМЭВ-доступ.

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

Это архитектурный факт, который нужно учитывать при проектировании.

Крейт smev4-rs с реализацией, о которой я написал, опубликован на crates.io ^[1] под Apache-2.0: smev4-rs ^[2]. Исходный код доступен на GitHub ^[3].

Если кто-то работает с СМЭВ на Rust, посмотрите, буду рад обратной связи.

Источники

Банки лишились доступа к сервису проверки паспортов МВД · Коммерсантъ, 16 апреля 2026 ^[4]

Банки лишились доступа к паспортным данным клиентов через базу МВД · РБК, 16 апреля 2026 ^[5]

Крупнейшим банкам вернули доступ к проверке клиентских паспортов · Коммерсантъ, 20 апреля 2026 ^[6]

Документы вернулись в оборот · Коммерсантъ, 20 апреля 2026 ^[7]

Информационное сообщение ФСТЭК №240/22/1492 · ГАРАНТ ^[8]

Приказ ФСТЭК №117 ^[9]

Постановление Правительства №1687 ^[10]

444-П и СМЭВ · КонсультантПлюс ^[11]

Описание сервиса СМЭВ 3+4 · Кворум ^[12]