Сброс пароля через техподдержку: как проверить личность сотрудника и не отдать учётную запись злоумышленнику

Сброс пароля через техподдержку: как проверить личность сотрудника и не отдать учётную запись злоумышленнику

Изображение: OpenAI

Служба поддержки пользователей остаётся одной из самых уязвимых точек в ИБ-контуре компании. Злоумышленнику бывает куда проще выдать себя за сотрудника или руководителя и убедить инженера первой линии сбросить пароль, чем пытаться взломать учётную запись. Михаил Ванин, генеральный директор Identity Blitz, рассказывает, как правильно организовать процедуру проверки личности удалённых и офисных сотрудников и исключить человеческий фактор.

Михаил Ванин, генеральный директор Identity Blitz
Михаил Ванин, генеральный директор Identity Blitz

Почему сценарий сброса пароля становится брешью в защите

Вход по паролю с многофакторной аутентификацией (MFA) можно сравнить с крепкими воротами. Но сценарий восстановления доступа через службу поддержки продуман далеко не всегда и на деле может оказаться хлипкой калиткой чёрного входа. Атакующие активно применяют методы социальной инженерии против сотрудников поддержки первой линии. Они давят на срочность, ссылаются на сорванные сделки, имитируют звонки из командировок или прикрываются распоряжениями руководства. Срабатывает психологический фактор: рядовому оператору поддержки сложно отказать «вице-президенту», которому якобы срочно нужен доступ на важном совещании.

Когда регламент работы службы поддержки размыт, а для отдельной категории пользователей действуют послабления, социальная инженерия приводит к компрометации системы. Защитить корпоративные ресурсы помогает подход Zero Trust с его главным принципом: «никому априори не доверяй, всегда перепроверяй». Суть Zero Trust заключается в отсутствии изначального доверия, а не в его полном запрете — доверие появляется только после прохождения необходимых проверок. Но чтобы этот принцип работал, он должен быть зафиксирован в понятных сценариях проверки.

Сценарий 1. Самообслуживание и автоматизация

Один их самых надёжных способов защитить техподдержку от социальной инженерии — полностью исключить человека из процедуры сброса пароля. Для этого внедряют портал самообслуживания.

Сотрудник переходит на портал и сбрасывает пароль самостоятельно проходит строгую многофакторную аутентификацию. При этом в режиме сброса пароля сам пароль уже нельзя использовать как фактор аутентификации, поэтому вместо него в комбинации факторов применяются другие защитные механизмы:

  • Push-уведомления или TOTP-коды в корпоративном аутентификаторе;
  • Аппаратные ключи и смарт-карты;
  • Биометрическая проверка (голос или распознавание лица).

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

Минусы: требует заранее развёрнутой системы MFA. Бесполезен, когда пользователь потерял сразу все свои факторы аутентификации. Из-за того, что в сценарии сброса нельзя задействовать старый пароль, администраторам приходится настраивать в MFA специальный альтернативный сценарий. Часто для этого выбирают способ входа, который менее удобен и непривычен для пользователя.

Сценарий 2. Верификация силами техподдержки: технические и процедурные меры

Если портала самообслуживания нет или сотрудник потерял доступ ко всем факторам MFA, процесс переходит к инженеру первой линии. В этом случае поддержка использует комбинированный набор проверок.

1. Технические проверки со стороны первой линии

Инженер поддержки сам инициирует отправку проверочных факторов:

  • Обратный звонок: оператор перезванивает только на подтверждённый номер из кадровой базы.
  • Одноразовый код (СМС или Flash-call): отправка OTP-кода на привязанный номер.
  • Запрос в авторизованный рабочий чат: подтверждение через корпоративный мессенджер, который уже установлен на смартфоне сотрудника.

Плюсы: быстро реализуется в рамках стандартных процессов службы поддержки.

Минусы: сохраняются риски подмены номера или перехвата СМС.

2. Динамические контекстные вопросы

Когда технические каналы скомпрометированы или недоступны, статические кодовые слова и паспортные данные не помогут — их легко узнать через открытые источники. Вместо них оператор задаёт динамические контекстные вопросы о текущей рабочей активности сотрудника: например, номер табельного учёта или трудового договора, серийный номер корпоративного ноутбука, название текущего проекта.

Плюсы: контекстные вопросы тяжело собрать через открытые источники; метод не требует покупки аппаратных токенов или СМС-шлюзов.

Минусы: сотрудник сам может забыть точные детали (например, номер договора); оператору требуется доступ к кадровым и бухгалтерским системам для фактчекинга.

3. Согласование через руководителя

Если у оператора остаются сомнения, он может перенаправить заявку непосредственному руководителю сотрудника по внутренним каналам (СЭД, рабочий звонок).

Плюсы: блокирует атаки, рассчитанные на быструю компрометацию.

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

Сценарий 3. Нестандартные методы для небольших компаний

Развёртывание MFA-платформ, СМС-шлюзов и интеграция с кадровыми системами требуют ресурсов, которые есть не у каждой компании. В небольших организациях со множеством удалённых сотрудников можно применить альтернативные методы подтверждения личности:

  • Подтверждение через личный профиль в соцсетях: оператор просит сотрудника написать сообщение с его давнего личного аккаунта. Главное — убедиться, что профиль ведётся давно, содержит историю публикаций и личные фотографии, а не создан за пару дней до обращения.
  • Микроплатёж через СБП: оператор просит перевести символическую сумму (например, 17 рублей) по системе быстрых платежей на корпоративный или дежурный номер. В деталях перевода отображаются имя, отчество и первая буква фамилии отправителя. Если ограничить время перевода 3-5 минутами и запрашивать случайную сумму с копейками, злоумышленник не успеет связаться с настоящим пользователем и убедить его провести платёж.

Как построить безопасный регламент: золотые правила для службы поддержки

Какими бы способами верификации ни пользовалась компания, они не сработают без чёткого алгоритма действия для первой линии:

  • Определение формата работы: если сотрудник в офисе — сброс пароля выполняется только при личном визите с демонстрацией бейджа или паспорта.
  • Проверка MFA: для удалённого сотрудника в первую очередь запускается автоматический сценарий через MFA (Push/TOTP), если он предусмотрен в компании.
  • Резервный сценарий: если доступа к MFA нет, последовательно запускаются обратный звонок на номер из кадровой базы, проверка контекстных вопросов и согласование с руководителем.

Чтобы защитить операторов от давления и ошибок, регламент дополняют базовыми правилами безопасности:

  • Сброс пароля для администраторов, топ-менеджеров и привилегированных учётных записей не может выполняться одним оператором. Требуется обязательное подтверждение от второго специалиста или службы ИБ. Это снимает давление с линейного сотрудника поддержки: даже под угрозой увольнения он не сможет нарушить правило в одиночку.
  • Сгенерированный пароль имеет ограниченный срок действия (например, 2 часа), и его требуется сменить при первом входе.
  • Пароль никогда не диктуют голосом и не отправляют в открытом виде в мессенджерах — только через одноразовые защищённые ссылки.
  • Если стандартные способы верификации пройти не удалось, запуск процедуры задерживается (например, на 24 часа). При этом уведомления о запросе сброса отправляются самому сотруднику и его руководителю. Это даёт настоящему владельцу учётной записи время среагировать и заблокировать атаку.
  • Звонки, тикеты и факты сброса паролей фиксируются в SIEM-системе для регулярного анализа.

Используемые термины

MFA — многофакторная аутентификация.

Zero Trust — концепция кибербезопасности, согласно которой ни одному пользователю, устройству или приложению нельзя доверять по умолчанию, даже если они уже находятся внутри корпоративной сети или ранее проходили проверку.

Push — короткое всплывающее сообщение, которое сайт или мобильное приложение отправляет на устройство пользователя.

TOTP — алгоритм создания одноразовых временных паролей, которые используются для двухфакторной аутентификации.

Flash-call — технология автоматической авторизации и подтверждения номера телефона с помощью входящего звонка.

OTP — уникальный временный пароль, который действует только для одного сеанса входа.

SIEM — класс программных решений, который в режиме реального времени собирает, агрегирует и анализирует данные о безопасности из различных источников в IT-инфраструктуре компании.

Identity Blitz
Автор: Identity Blitz
Identity Blitz – российский разработчик программного обеспечения в сфере информационной безопасности. Компания специализируется на программных продуктах для идентификации, аутентификации, авторизации и аудита доступа пользователей к информационным ресурсам. Продукты компании сертифицированы по требованиям безопасности информации ФСТЭК России и внесены в Реестр российского ПО. Основной продукт компании – сервер аутентификации Blitz Identity Provider, решение классу IAM, SSO, MFA. Поддерживает современные протоколы аутентификации (OpenID Connect, OAuth 2.0, SAML, WS-Federation, RADIUS), популярные отечественные операционные системы и СУБД. Российская альтернатива Keycloak.
Комментарии:

Как мы обрабатываем данные: политика обработки персональных данных