|
Professor Seleznov
|
Я узнал об отключении не из новостей. Утром мне написал знакомый из небольшого банка: «всё упало, паспорта не проверяются, онлайн встал». В то время как раз дописывал обработку ошибок в 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 под Apache-2.0: smev4-rs. Исходный код доступен на GitHub. Если кто-то работает с СМЭВ на Rust, посмотрите, буду рад обратной связи. Источники Банки лишились доступа к сервису проверки паспортов МВД · Коммерсантъ, 16 апреля 2026 Банки лишились доступа к паспортным данным клиентов через базу МВД · РБК, 16 апреля 2026 Крупнейшим банкам вернули доступ к проверке клиентских паспортов · Коммерсантъ, 20 апреля 2026 Документы вернулись в оборот · Коммерсантъ, 20 апреля 2026 Информационное сообщение ФСТЭК №240/22/1492 · ГАРАНТ Приказ ФСТЭК №117 Постановление Правительства №1687 444-П и СМЭВ · КонсультантПлюс Описание сервиса СМЭВ 3+4 · Кворум-Источник
|