После смены SIM-карты клиент может сохранить тот же номер, но риск захвата аккаунта в этот момент повышается: доступ к старой SIM уже не подтверждает, что запрос выполняет владелец. Flash Call помогает проверить контроль над номером звонком и одноразовым кодом, однако для чувствительных действий этого недостаточно без дополнительных правил. В статье разберём, как построить безопасный сценарий для малого бизнеса Беларуси, какие проверки добавить после смены SIM и что делать при сбое авторизации.
Почему смена SIM-карты требует отдельного сценария?
Номер телефона часто используют как логин или канал восстановления доступа. Когда клиент меняет SIM-карту, номер остаётся прежним, поэтому обычная проверка номера не показывает, давно ли он находится под контролем пользователя. Запрос на вход может сделать и настоящий владелец, и человек, который получил доступ к аккаунту другим способом.
Для бизнеса это особенно заметно в сценариях, где после авторизации можно изменить реквизиты, вывести деньги, оформить заказ с отсрочкой или открыть доступ сотруднику. Flash Call подтверждает, что звонок поступил на указанный номер. Проверку смены SIM нужно строить вокруг другого признака: времени и обстоятельств изменения номера у оператора, если такие данные доступны вашему процессу, а также истории действий клиента в аккаунте.
Самый практичный подход для малого бизнеса — разделить действия по риску. Вход в личный кабинет можно разрешить после Flash Call. Смена номера, восстановление доступа и изменение платёжных реквизитов требуют дополнительной паузы или ручной проверки.
Как выглядит безопасный сценарий авторизации по звонку?
Клиент вводит номер, после чего система отправляет запрос на Flash Call. Сервис звонит на этот номер, а приложение или сайт получает результат проверки. В зависимости от выбранного сценария клиент вводит код, который система связывает с конкретным запросом API. Подробные параметры метода и связь запроса с вызовом описаны в материале о проверке номера звонком через Flash Call.
- Создайте отдельную сессию авторизации и присвойте ей срок действия.
- Покажите клиенту последние цифры номера, на который уйдёт звонок.
- Передайте в API уникальный идентификатор запроса, чтобы ответ нельзя было отнести к другой попытке.
- После успешной проверки выдайте короткоживущий токен для входа.
- Запишите событие в журнал: время, номер в замаскированном виде, устройство и действие.
Если клиент недавно менял SIM, вход можно оставить доступным, но ограничить операции с последствиями для денег и доступа. Например, пользователь сможет просмотреть историю заказов, однако смена реквизитов потребует повторной проверки через отложенный срок или обращения к сотруднику.
Не отправляйте код в URL, открытые логи или сообщения об ошибках. На экране достаточно показать нейтральное уведомление: «Проверка не завершена, попробуйте ещё раз». Так система не раскрывает постороннему человеку, существует ли такой номер или аккаунт.
Какие проверки добавить после смены SIM-карты?
Flash Call проверяет доступ к телефонному номеру, но не доказывает, что человек имеет право менять настройки бизнеса или распоряжаться средствами. Поэтому после успешного звонка полезно проверить контекст запроса.
- Сравните устройство и город входа с обычной историей клиента, если такая информация уже собирается в вашем сервисе.
- Проверьте, не менялись ли недавно пароль, электронная почта, номер телефона или платёжные данные.
- Запросите повторную авторизацию перед операцией с высоким риском.
- Введите короткую задержку для смены реквизитов после восстановления доступа.
- Покажите владельцу аккаунта уведомление о новом входе через уже подтверждённый канал.
- Для корпоративного аккаунта добавьте подтверждение второго сотрудника или администратора.
Такая схема подходит, например, интернет-магазину, сервису заявок или внутреннему кабинету сменных сотрудников. Клиент сохраняет доступ к обычным функциям, а опасные изменения система блокирует до завершения дополнительных условий. Если бизнес открывает через звонок кассу, склад или другой рабочий раздел, полезно заранее определить роли и разрешённые действия для каждой роли: это снижает последствия скомпрометированного аккаунта. Пример подобного сценария разобран в материале о доступе сменных сотрудников к кассе и складу через Flash Call.
Как обрабатывать успешную и подозрительную попытку?
Система должна принимать решение не только по ответу «звонок подтверждён». Нужен набор состояний, который понятен разработчику и сотруднику поддержки.
| Состояние | Что видит клиент | Действие системы |
|---|---|---|
| Номер подтверждён, риск низкий | Доступ разрешён | Открыть обычные функции и создать короткую сессию |
| Номер подтверждён, риск высокий | Нужна дополнительная проверка | Ограничить смену реквизитов и восстановление доступа |
| Код неверный | Повторите ввод | Увеличить счётчик ошибок и временно остановить попытки после лимита |
| Звонок не поступил | Проверьте номер или выберите другой способ | Предложить разрешённый резервный канал |
| Слишком много запросов | Попробуйте позже | Остановить новые попытки и записать событие в журнал |
Лимиты нужны и для защиты, и для контроля расходов. Один пользователь не должен бесконечно запускать звонки при неверном вводе. Для каждого запроса задайте срок действия, число повторов и интервал между ними. Практические варианты настройки лимитов и повторных попыток собраны в статье о повторных попытках при Flash Call.
Резервный способ выбирайте заранее. Если бизнес использует SMS, голосовое подтверждение или ручную проверку, клиенту нужно показать понятный порядок действий. Резерв не должен автоматически разрешать смену реквизитов после одного неудачного звонка. Он только помогает восстановить доступ после проверки риска.
Какие ошибки встречаются чаще всего?
- Одинаковые правила для входа и смены реквизитов. Эти действия имеют разный риск, поэтому им нужны разные ограничения.
- Бесконечные повторные звонки. Без лимита злоумышленник может перегружать номер и создавать лишние запросы.
- Долгоживущая сессия. Если токен остаётся активным долго, украденный доступ сложнее отозвать.
- Сообщение о точной причине отказа. Фраза о «недавней смене SIM» раскрывает лишние сведения. Пользователь видит общее объяснение и инструкцию.
- Отсутствие ручного маршрута. Поддержка должна видеть, почему операция остановилась и какие проверки уже пройдены.
Проверить сам код недостаточно. Протестируйте сценарии на тестовых номерах: успешный звонок, неверный код, истёкшая сессия, повторный запрос, заблокированный номер и переход на резервный канал. Отдельно проверьте, что после выхода из аккаунта старый токен больше не открывает защищённые разделы.
3 шага, которые можно сделать на этой неделе:
- Разделить авторизацию по телефону и смену реквизитов на два разных уровня риска.
- Добавить срок действия запроса, лимит повторов и журнал событий для Flash Call.
- Описать отдельный маршрут для клиента после смены SIM-карты: ограниченный доступ, дополнительная проверка и понятный резервный способ восстановления.
