Инициатива Минцифры по подтверждению действий через СМС

Канал подтверждения нельзя подменять политикой маршрутизации

По сообщениям источников, обсуждаемая идея могла войти в третий пакет мер против кибермошенничества. Ранее похожая норма уже появлялась во втором пакете, но в финальную версию не попала. Формулировка остаётся проблемной: «значимые действия» не определены.

Для почтовой инфраструктуры это не абстракция. Под такую категорию можно подвести вход в аккаунт, смену пароля, добавление адреса восстановления, изменение телефона, подтверждение покупки, изменение платёжных данных. Если перечень будет широким, сервисы потеряют часть гибкости в выборе факторов: push, внутренние уведомления, email-подтверждения, одноразовые коды, TOTP.

Текущая рабочая модель антифрода строится иначе: сервис сам выбирает механизм проверки по риску операции. Подозрительный вход — один сценарий. Смена критичных данных — другой. Рутинное действие с известного устройства — третий. Жёсткая привязка к СМС или одному мессенджеру ломает эту схему.

Рынок указывает на издержки и спорную надёжность

Собеседники Forbes, на которых ссылаются публикации, считают, что при принятии такой нормы банки и платформы получат дополнительные расходы на рассылку СМС и уведомлений в «Макс». В РВБ заявили, что уже используют многоуровневую проверку подозрительной активности, анализ рисков и дополнительные сценарии подтверждения при необходимости. Там инициативу в таком виде считают избыточной: безопасность не вырастет пропорционально затратам, а расходы могут лечь в стоимость товаров и услуг.

Президент Ассоциации компаний интернет-торговли Артём Соколов также не поддержал ограничение способов подтверждения отдельными каналами. Даже вариант «СМС или Макс», а не оба сразу, по его оценке, проблему полностью не решает.

Для администраторов вывод простой. Не проектируйте аутентификацию вокруг одного транспорта. СМС — транспорт. Мессенджер — транспорт. Email — тоже транспорт. Фактор должен оцениваться по стойкости, доступности, журналированию, управляемости и сценарию отказа. Без этого подтверждение превращается в точку отказа, а не в защитный контур.

Что проверить сейчас

Проверьте матрицу «действие → фактор подтверждения». Отдельно выделите вход, смену пароля, смену адреса восстановления, подключение нового устройства, изменение платёжных данных, экспорт данных и отключение 2FA. Если всё замкнуто на один канал, исправьте.

Проверьте TOTP. Эксперт проекта «Сетевые свободы» Станислав Селезнёв напомнил об открытом стандарте RFC 6238 TOTP: он не привязан к конкретному производителю или платформе и широко используется. Если в вашей системе TOTP уже есть, не удаляйте его из архитектуры без технического основания. Если его нет — включите в план развития MFA.

Проверьте почтовые сценарии восстановления. Для доменной почты это критично: компрометация mailbox часто даёт доступ к сбросу паролей в сторонних сервисах. Настройте SPF, DKIM и DMARC. Закройте лишние алиасы. Проверьте журналы входов. Запретите слабые пароли. Разведите административные и пользовательские ящики.

Проверьте зависимость от внешних каналов. Если подтверждение уходит только в СМС или только в одно приложение, сбой канала блокирует легитимного пользователя и не обязательно останавливает атакующего. Нужны резервные процедуры, но без «дыр» через поддержку.

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