(c) Ram Dass (Kali Linux)
Классические пароли имеют большое количество угроз и уязвимостей (особенно человеческого фактора) и оставлять доступ к публичным сервисам организации только по паролю – слишком рискованно для любого бизнеса. Лучшие практики для усиления безопасности это внедрение 2-ух факторной аутентификации. Но мы пойдём ещё дальше, я расскажу об адаптивной многофакторной аутентификации.
Небольшая предыстория
В начале было слово и слово это было не просто слово, а набор слов, – целое требование в ТЗ нового разрабатываемого клиентского веб-сервиса в целях цифровизации "офлайнового" бизнес-процесса. Требование звучало так: "Реализовать механизм двухфакторной аутентификации".
На определённом этапе разработки клиентского сервиса в целях формирования и реализации потребностей клиентов – была сформирована фокус-группа пользователей от крупных клиентов организации. Для них в определённый момент был опубликован предварительный тестовый инстанс веб-сервиса с минимально реализованным к тому времени функционалом. Доступ предоставлялся по клиентскому IP-адресу (да, не очень удобно, зато секьюрно). Также почти сразу, мы закрыли веб-приложение WAF-ом в режиме Prevent, причём без каких-либо костылей, и это было лучшим решением в плане безопасности. В таком режиме разработки и тестирования сервиса прошло примерно 10 месяцев и мы, наконец, дошли до фазы проекта – реализация требований безопасности.
В самом начале проекта у нас уже была разработана и внедрена форма входа в приложение на базе уже существующего механизма. Пришло время глобально заняться вопросами безопасности сервиса. Подход был выбран следующий:
- Поиск и исправление всех обнаруженных уязвимостей приложения всеми доступными нам средствами (проверяли приложение на соответствие требованиям стандарта OWASP ASVS, запускали различные сканеры уязвимостей SAST\DAST и т.д.)
- Разработка процессов системы безопасности приложения (регистрация пользователей, первый вход, 2-FA, сброс пароля, управление сессиями и т.д.)
- Пентест приложения и исправление обнаруженных уязвимостей.
Когда поднялся вопрос о реализации 2FA я начал изучать вопрос и наткнулся вот на такую простую схему:
Это оказалась схема адаптивной мультифакторной аутентификации. В конце заметки будет ссылка на коммерческое решение, где можно почерпнуть много интересного в целом по данному классу решений (adaptive multifactor authentication), а также ознакомиться с более продвинутыми возможностями коммерческого продукта.
Что разъясняет эта схема?
Что веб-приложение проверяет не только 2 (или более) фактора аутентификации, но и осуществляется проверка так называемого контекста пользователя, – сверяются некие известные данные о пользователе. Например, что пользователем осуществляется вход с известного устройства, сети, браузера, определённого времени на устройстве или осуществляется проверка известного поведения пользователя, например доступ к приложению из известной геолокации, аналитика движений мыши, скорости набора текста, вход в рабочее время и т.д. Если всё ОК – второй фактор не запрашивается. Это если кратко.
1) Удобство (не нужно каждый раз проходить второй фактор, система "помнит" контекст клиента)
2) Повышенный риск-ориентированный уровень безопасности (система может быть настроена на проверку определённых рисков)
3) Экономический эффект (например, не нужно каждый раз отправлять платные СМС, снижается время на безопасный вход в приложение)
Никто не мешает внедрять подобное в SSO-решениях и кастомизировать под свои риски и потребности. Механизм доказывает, что можно делать безопасные решения не в ущерб функциональности и удобству:
Security Functionality Usability Triangle (c) EC-Council CEH
Рассмотрим подробнее пример реализации:
При успешном прохождении первого фактора (логин и пароль) и второго фактора (ввод кода из SMS, из Email, приложения и т.д.), веб-сервер должен запоминать контекст клиента, например связку: IP-адрес (к примеру первые 2 октета, на случай если IP-адрес клиента динамически меняется), user-agent (идентификатор браузера клиента) и далее генерировать токен аутентификации для клиентского браузера, сохраняя его в Cookies с определённым сроком жизни (зависит от контекста организации и приложения, срок жизни токена например 1 месяц). Веб-сервер под каждого успешно аутентифицированного пользователя ведёт в БД отдельную таблицу запоминаемого контекста клиента: IP-адрес, User-Agent, Token (этим не ограничено).
При следующем входе клиента – если контекст пользователя не поменялся (срок действия токена не истёк и валидный токен присутствует в Cookies браузера, IP-адрес не изменился, User-Agent тот же) – второй фактор система не запрашивает. Если поменялось хоть что-нибудь из контекста пользователя, – инициируется запрос и проверка второго фактора (у нас это был OTP: код по SMS, email и т.д.) и выдача нового токена при успешной аутентификации. При этом ещё нужно задать ограничение на кол-во запоминаемых контекстов пользователя и при его превышении - удаление наиболее старого или сброс остальных с уведомлением. Также, например, осуществлять сброс токенов - когда при переборе паролей (атакующие сумели обойти CAPTCHA) осуществляется сброс всех токенов для данного пользователя (скажем после 100-ой попытки подбора пароля). Это для подстраховки, если атакующий изменит вектор атаки. При прохождении второго фактора и входа на сервис – отправлять пользователю email-уведомление.
Результаты
Совместно с командной разработки мы реализовали подобный механизм. Но вместо дорогого и не всегда доступного SMS-сервиса (на западе крупный бизнес давно уже от него уходит) в нашем приложении была реализована отправка кода по EMAIL. Да, не самый безопасный способ, зато самый простой и доступный в реализации (не во всех организациях разрешено на рабочем месте использовать смартфон). По сути мы перекладываем риски безопасности для второго фактора на плечи сервиса электронной почты клиента. Это не самое секьюрное решение, но в контексте нашего приложения и других механизмов безопасности – этого достаточно (по моей субъективной оценке).
Cо стороны КЛИЕНТОВ и БИЗНЕСА – к реализованному решению никаких претензий не последовало, оно показалось вполне удобным, а главное – безопасным.
Также, механизм прошёл успешный аудит безопасности командой пентестеров (топовый сервис-провайдер в РФ). По методике OWASP Testing Guide (раздел OTG-AUTHN-XXX) – уязвимостей не обнаружено.
"Я считаю это успех! Машина времени работает!" (с)
p.s. Помните, мало просто внедрить 2FA, надо убедиться, что нет других уязвимостей, например, перехвата сессии или отсутствия ограничения на кол-во одновременных сессий и т.д., чтобы всё не оказалось напрасным. Также, надо всё самому проверять, особенно логику процессов безопасности. Разработчики и тестировщики могут пропустить.
Коммерческие решения
Как обещал, хорошая презентация по этой теме и, на мой взгляд, интересный коммерческий продукт и его возможности:
- https://www.slideshare.net/SecureAuth2FASSO/why-twofactor-isnt-enough
- https://www.secureauth.com/products/access-management/adaptive-authentication
Комментариев нет:
Отправить комментарий