Двухфакторная аутентификация в организации: защита информации без потери удобства для пользователей

Включить второй фактор технически несложно, сложно сделать так, чтобы сотрудники им действительно пользовались, а не искали способы обойти. Начнём с того, зачем он вообще нужен, помимо требований ФСТЭК России и существующих нормативных документов. Пароли можно подобрать простым перебором, в особенности, там, где нет парольных политик, но также часто пароли утекают при фишинге, работник вводит пароль на фишинговом сайте, который выглядит в точности как корпоративный портал, а также бывают уязвимости, которые позволяют сбросить удаленно пароль через RCE. Частым явлением бывает, что работник использует один и тот же пароль на работе и в стороннем сервисе, этот сервис взламывают, и база с паролями оказывается в открытом доступе. Результат во всех случаях одинаковый: у злоумышленника появляется рабочая учётная запись, он заходит с обычным логином и паролем, и средства защиты не видят в этом ничего подозрительного, потому что формально вход законный.

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

Удобство пользователя — не уступка и не приятное дополнение к защите. Это условие, при котором защита вообще работает. Неудобный второй фактор в итоге может даже снижать безопасность, потому что порождает обходные пути, о которых служба ИБ не знает и которые она не контролирует.

Сами факторы делятся на три категории: то, что пользователь знает (пароль, ПИН-код), то, чем он владеет (токен, смарт-карта, доверенное устройство), и то, чем он является (биометрия). Многофакторной считается аутентификация с двумя и более факторами из разных категорий, поэтому пароль вместе с контрольным вопросом ею не является: и то и другое относится к категории «знание», это просто двухэтапная проверка.

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

• Одноразовые коды в SMS. Самый слабый способ. Сообщение можно перехватить, но чаще злоумышленник перевыпускает SIM-карту жертвы по поддельным документам или через сотрудника оператора связи и получает все коды сам. Для пользователя это привычно и не требует ничего устанавливать, поэтому сопротивления почти не вызывает. Разумный компромисс: оставить SMS резервным каналом, но не защищать ими привилегированный доступ.
• Приложения-генераторы одноразовых кодов (TOTP). Надёжнее и, что важно для пользователя, работают полностью автономно: код формируется на устройстве и связь для этого не нужна. Цена — необходимость установить приложение и вводить шестизначный код руками при каждом входе. Слабое место в том, что код вводится куда угодно, в том числе на фишинговой странице. Отдельно стоит упомянуть схему, когда злоумышленник поднимает прокси между пользователем и настоящим порталом: жертва вводит и пароль, и одноразовый код на поддельной странице, а атакующий передаёт их дальше и забирает готовую сессию.
• Подтверждение входа в мобильном приложении (push). Самый удобный вариант для сотрудника: нажал кнопку и вошёл, ничего не нужно набирать, но, как и для TOTP, нужно приложение, которое пользователь должен установить.
• Аппаратные токены и смарт-карты. Дают наивысшую стойкость, и здесь нужно различать два разных класса устройств. Токены с отечественной криптографией по ГОСТ закрывают требования к строгой аутентификации и работают с российскими удостоверяющими центрами. Токены со стандартом FIDO2 (он же WebAuthn) обеспечивают криптографическую привязку к конкретному домену, то есть устойчивы к фишингу на уровне самого протокола: на поддельном сайте такой токен просто не сработает. Это разные технологии, и сочетаются они в одном устройстве далеко не всегда: не всякий USB-токен умеет FIDO2, и не всякий FIDO-токен поддерживает ГОСТ. Уточняйте модель и версию прошивки у производителя, а сертификат проверяйте по реестру. Для пользователя токен часто оказывается удобнее приложения, потому что не требует доставать телефон, но тяжелее в эксплуатации для технической поддержки, а также для удаленных работников, так как токен можно забыть дома, потерять и на все это нужны отдельные сценарии.
• Биометрия. Удобна, но привязана к конкретному устройству. В корпоративных схемах обычно работает не как самостоятельный второй фактор, а как способ разблокировать хранящийся на устройстве ключ (но также необходимо обеспечивать корректную обработку и комплексную защиту самой биометрии с точки зрения защиты ПДн).

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

Где двухфакторная аутентификация ломается о пользователя?

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

1. Вход занимает слишком много времени. Если система запрашивает второй фактор при каждом обращении, пользователь тратит на подтверждения по несколько минут в день, а за месяц набегают часы. Эта проблема решается тремя способами. Первый — доверенные устройства, когда повторную проверку запрашивают не каждый раз, а с установленной периодичностью. Второй — единый вход (SSO), при котором сотрудник проходит проверку один раз и получает доступ сразу ко всем нужным системам. Третий — риск-ориентированная аутентификация: второй фактор запрашивают только тогда, когда параметры сеанса отклоняются от привычных, например вход идёт с нового устройства, из другой страны или в нерабочее время. Здесь есть неочевидный риск: чем дольше система помнит устройство как доверенное, тем ценнее для злоумышленника украденный файл сессии.
2. «Не хочу ставить рабочее приложение на личный телефон». Требование порождает конфликт, который вы не выиграете, а на режимных объектах оно вдобавок упирается в прямые запреты. Выход один: предложить альтернативу. Тем, кто не хочет или не может использовать личный телефон, нужно выдать аппаратный токен или служебное устройство. Это естественно дороже, но снимает конфликт, а заодно закрывает вопрос с сотрудниками, у которых нет смартфона.
3. «Я потерял доступ и не могу работать». Токен потерялся, телефон сломался, сотрудник сменил номер. Человек не может выполнять свои задачи и через полчаса пишет в поддержку. Такие ситуации нужно предусмотреть заранее: выдать резервные одноразовые коды, зарегистрировать второе средство аутентификации, описать процедуру восстановления доступа. При этом помните, что сама процедура восстановления может быть слабым звеном схемы. Сценарий, при котором человек звонит в службу поддержки, называет фамилию и дату рождения и получает сброс второго фактора, злоумышленники отработали до автоматизма, и никакой токен от этого не спасёт. Проверка личности при восстановлении должна быть не слабее самой аутентификации: очно, через непосредственного руководителя и заявку, по видеосвязи с предъявлением документа или через заранее подтверждённый отдельный канал.
4. «У меня нет связи». Ни SMS, ни push-уведомление до пользователя не дойдут. Значит, основным или хотя бы резервным способом нужен механизм, работающий автономно: приложение-генератор кодов или аппаратный токен. Отдельно стоит иметь в виду, что произойдёт, если недоступным окажется сам сервер аутентификации.
5. «Мне сложно с этим разобраться». Часть сотрудников споткнётся на установке приложения или на переносе настроек при смене телефона. Помогают пошаговая инструкция со скриншотами именно вашего интерфейса, короткая очная демонстрация и усиленная поддержка в первые дни после запуска. Возросшую нагрузку на службу поддержки заложите в план заранее.
6. «Почему такие сложности ради ерунды». Если требовать аппаратный токен для входа в систему бронирования переговорных комнат, вы настроите людей против всей затеи, включая те системы, где второй фактор действительно необходим. Ресурсы нужно разделить по значимости: строгая аутентификация там, где она необходима по требованиям и по уровню риска, простые способы для всего остального.

Как внедрять, чтобы не получить сопротивление?

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

1. Начните с пилота на подразделениях ИТ и информационной безопасности. Коллеги найдут пробелы в инструкции, и обойдётся это дешевле, чем если те же пробелы обнаружит бухгалтерия в отчётный период.
2. Расширьте охват на группы с наибольшим риском: удалённый доступ, привилегированные учётные записи, доступ к персональным данным и финансовым системам.
3. Откройте добровольное подключение и объясните людям, что происходит и зачем. Довод «этого требует ФСТЭК» работает плохо. Довод «так у вас не уведут учётную запись, а вместе с ней и премию» работает заметно лучше.
4. Сделайте проверку обязательной после того, как основная масса сотрудников подключилась сама.

С самого начала считайте несколько показателей: долю подключённых пользователей, количество обращений в поддержку, количество восстановлений доступа и количество отклонённых подтверждений. Первые три показывают, насколько удобно получилось. Последний работает индикатором того, что чьи-то пароли уже утекли.

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

Автор: Мыськив Иван, начальник отдела противодействия компьютерным атакам и управления уязвимостями информационных систем Digital Design