Двухфакторная аутентификация для корпоративных веб-сервисов

В процессе своей работы часто сталкиваюсь с различного рода атаками на корпоративные веб-сервисы. Встречались и случаи, когда злоумышленнику удавалось получить доступ к пользовательскому аккаунту. Чтобы минимизировать подобный риск и обезопасить свои сервисы, возникла идея внедрения системы двухфакторной аутентификации, с помощью которой можно было бы обезопасить сразу все корпоративные веб-сервисы, то есть инфраструктуру. Вторым фактором аутентификации в данном случае является смс-авторизация или e-mail авторизации в дополнение к существующей на сервисах с аутентификацией по паролю.

Описание сервиса

Сервис дополнительной аутентификации для внешнего доступа к веб-сервисам компании должен будет осуществлять проверку по UID, в основу формирования которого ложится IP-адрес, с которого он осуществляет доступ и данные user-agent. Если по результатам проверки UID не находится в базе доверенных, то требуется авторизация путем ввода одноразового пароля, отправляемого на телефонный номер или email-аккаунт пользователя.

После авторизации в базу системы аутентификации добавляется UID.

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

Базовая архитектура системы

Требования к функционалу мы для себя определили следующие:

1. Динамическая авторизация по IP пользователей веб-сервисов Компании (TCP: 80, 443);
2. Возможность включения аутентификации для любых сервисов, к примеру, SMTP, IMAP, Jabber, FTP и т.д. (с некоторыми неудобствами для пользователей);
3. Возможность разграничения доступа (фильтрации) по веб-сервисам: почта, трекер и т.п.;
4. Авторизация новых адресов должна производиться путем ввода разового пароля, получаемого пользователем на заранее введенный моб. телефон или email;
5. В качестве базы данных пользователей должен использоваться LDAP;
6. Мобильные телефоны, соответствующие пользователю, должны храниться в LDAP, адресной книге портала или локальной базе системы (реализовать 1 или более вариантов);
7. Модульность системы: (возможность замены отдельных модулей системы, без серьезных последствий для остальной системы: возможность замены типа аутентификации, возможность замены типа межсетевого экрана или иного ПО);
8. Фильтрация пользователей по общей группе (базовая группа/роль дающая пользователю доступ к основному набору сервисов);
9. Возможность добавления дополнительных группы (для отдельных сервисов) и фильтрация по данным группам.
10. Плавающий срок хранения авторизованных UID, учитываться должны следующие параметры:
    — Давность последнего входа (таймаут)
    — Общее кол-во входов;
11. CAPTCHA + таймаут на повторную отправку после 2-3 отправок разовых паролей подряд (к примеру 5 минут), после 5-10 отправки — блокировка;
12. При удачной и неудачной аутентификации пользователю должно выводиться сообщение:
    — При удачной на несколько секунда показывается баннер «Успешный вход в систему», а затем идет пересылка на искомый адрес
    — При неудачной аутентификации показывается сообщение с ошибкой, контакты технической поддержки и ссылку на повторную аутентификацю
13. Хранение всех ip-адресов с которых пользователь получал аутентификацию;
14. Хранение всех ip-адресов с которых пользователь запрашивал аутентификацию;
15. Ограничение по ip геолокаций и TOR;
16. Универсальность по соотношениям внешних/внутренних адресов;
17. Доступность ряда сервисов только для доверенных групп IP (реализуется опциональным фильтром);
18. Возможность ограничения e-mail серверов, которые могут быть использованы для получения разового пароля;

Что читатели думают по поводу предложенного способа организации двухфакторной авторизации? Буду рад комментариям и вашим предложениям.

Также, возможно, кто-то может поделиться опытом внедрения аналогичной системы.