Ключ от всех дверей: единый провайдер аутентификации Blitz IDP
Всем привет! Представьте огромную связку ключей, которую вам приходится всюду таскать с собой, перемещаясь по условному офисному зданию, в котором множество дверей. Типы замков разные, ключей много, вы постоянно путаетесь в них. Неудобно, не правда ли? Если проводить параллели с IT и пользователями, то такая ситуация вполне возможна при одновременном использовании большого количества приложений с локальной аутентификацией. Поэтому в нашей компании мы решили применить такой продукт, как единый провайдер аутентификации на базе Blitz Identity Provider. Еще один несомненный плюс использования IDP — возможность подключения к нему всех необходимых каталогов пользователей: ведь их вполне может быть гораздо больше, чем один. Статья предназначена для архитекторов решений и поможет продумать оптимальную структуру и перспективы развития ИТ-продуктов в части аутентификации, а также избежать граблей, на которые наступали мы.
Зачем это нужно?
• Во‑первых, это повышение удовлетворённости пользователя — гораздо удобнее использовать единую пару логин/пароль для доступа к приложениям;
• Во‑вторых, повышение уровня информационной безопасности. Если каждый пользователь имеет для каждой системы различные данные для авторизации, есть риски встретить среди них ненадежные комбинации, да и количество систем с различной локальной аутентификацией требует повышенного внимания к защите этих механизмов;
• В‑третьих, упрощение поддержки и дальнейшего развития. С централизованной системой это гораздо удобнее, а также упрощение несет огромные плюсы в части стандартизации интеграции приложений и удобства администрирования системы аутентификации/авторизации в целом.
На рынке присутствуют различные решения, которые могут использоваться в качестве единого провайдера авторизации. Это, например, keycloak, Azure B2C, ADFS и Blitz IDP. Как вы уже, наверное, догадались, речь пойдет именно о Blitz IDP. Этот продукт является одним из корпоративных стандартов в нашей компании, и моя команда стояла у истоков внедрения этого продукта, а также именно мы сейчас занимается его поддержкой и развитием.
Ну, а теперь предлагаю рассмотреть процесс внедрения IDP провайдера в нашей группе компаний — как пришли к такому решению, с чем столкнулись и как реализовывали некоторые интересные штуки.
Критерии и выбор IDP провайдера
В 2019 году мы стояли перед задачей создания Единого корпоративного портала (о нем писал мой коллега Сергей Тарасов в статье «Как мы допиливали Битрикс и защищали его от хищных роботов»), где каждый пользователь сможет запросить/получить какие-то услуги, ознакомиться с новостями компании и поучаствовать в жизни сообщества. До этого в компании использовался портал на базе SharePoint, но доступ к нему имели только доменные сотрудники из AD. Это значит, что пользоваться Порталом могли только коллеги, работающие в офисе, а сотрудники с производственных площадок — нет.
При проработке требований к этой активности как раз и встал вопрос аутентификации пользователей.
Казалось бы, простейшим решением было создать новый LDAP каталог для сотрудников с производственных площадок и организовать интеграцию приложения с каждым из источников данных (напрямую ходить в каталоги пользователей), но мы прекрасно понимали, что получение данных по пользователям и единая система авторизации — это разные вещи, хотя и могут пересекаться между собой.
Мы выделили ряд требований, включая задел на будущее, и объединили их вместе. В итоге получилось, что IDP должен удовлетворять следующим требованиям:
• Гибкость и масштабируемость. Необходимо создавать обширные и масштабируемые решения для управления идентификационными данными и доступом к сетевым ресурсам, а также быстро адаптироваться к меняющимся требованиям безопасности и регулирования;
• Совместимость и интеграция с различными приложениями и IT-инфраструктурой по различным стандартам, таким как SAML, OAuth2 и OpenID Connect;
• Различные возможности обеспечения необходимого уровня информационной безопасности: многофакторная аутентификация (MFA), Single Sign-On (SSO), контроль доступа на основе ролей и правил и т.д.;
• Соответствие стандартам и регулятивным требованиям;
• Удобный и интуитивно понятный пользовательский интерфейс, который позволял бы пользователям и администраторам без особых усилий управлять идентификационными данными, процессами аутентификации и доступа к ресурсам;
• Активная вендорская поддержка и хорошая документация.
Здесь мы пошли исследовать рынок готовых решений и остановили свой выбор на Blitz IDP. Этот продукт удовлетворял требованиям, изложенным выше, и был одним из немногих (если не единственным на тот момент) который был полностью разработан российскими коллегами. (Да-да, в дальнейшем нам это здорово сыграло на руку).
Установка и первые результаты
Первым делом определились с архитектурой. Здесь был сделан упор на отказоустойчивость и производительность, так как количество одновременных обращений к сервису достаточно большое. Было развернуто несколько нод приложений, обрабатывающих запросы через наш инфраструктурный балансировщик, кластер БД Couchbase и настроен в качестве источника данных наш доменный каталог AD. Никаких микросервисов — только полноценные машины, простые и понятно настроенные.
По итогу проведенных работ наш новый портал обзавелся системой аутентификации, а пользователи — возможностью ходить на ресурс под своими доменными учетными записями. Тему окна авторизации пользователя отредактировали под наш корпоративный стиль, определились с нужными кнопками и используемыми сервисами. На этом первичный этап внедрения можно было считать успешным.
Далее мы приступили к реализации возможности доступа сотрудников с производственных площадок. Для этого на отдельной машине был размещен и подключен к IDP независимый LDAP-каталог на базе открытого бесплатного решения (389-ds), и схема нашего провайдера приобрела примерно вот такой вот вид:
Оставалось самое интересное — продумать механизм его наполнения. И в контексте учета требований это была непростая задача!
Организация доступа сотрудников с производственных площадок
В процессе проработки задачи были определены следующие требования:
• Необходимо было автоматически добавить в каталог (создать) учетные записи уже существующих сотрудников, оформленных на текущий момент в группе компаний, но не имеющих учетной записи в AD.
• Для всех вновь оформленных сотрудников создание учетной записи должно происходить автоматически (опять же, не имеющих доменной УЗ), и пользователь должен быть об этом уведомлен.
• Должна быть предусмотрена возможность создания УЗ сотрудником самостоятельно (например, если при оформлении сотрудники кадровой службы по каким-либо причинам не указали его номер телефона, и, таким образом, создание УЗ не произошло автоматически). При этом должна производиться проверка того, что данный сотрудник действительно существует и оформлен в нашей компании.
• Должна производиться автоматическая блокировка учетной записи при увольнении сотрудника.
• Должен быть предусмотрен механизм самостоятельного восстановления пароля пользователем, а также механизм полного восстановления доступа к УЗ (например, если сотрудник не помнит ни личной почты, ни того, на какой номер телефона производилась регистрация).
Наполнение каталога
Для быстрого наполнения нового каталога пользователей и повышения зоны охвата был написан скрипт, выполняющий следующие действия — опрос кадровой системы на появление записей о сотрудниках, подходящих под определенные требования и создание для них учетных записей. Алгоритм работы — каждую ночь происходит поиск в кадровой системе записей с датой изменения не старше одних суток, отсутствием заполненного поля LOGIN_AD (что подразумевает отсутствие у него учетной записи в AD-каталоге пользователей) и заполненным номером телефона. Для такого пользователя скрипт через специально заведенное приложение в IDP-провайдере вызывает процедуру регистрации новой УЗ в каталоге 389-ds и по ее окончании на указанный в УЗ номер телефона отправляется приветственное СМС с указанием ссылки на Портал, логином и паролем пользователя, который он может в дальнейшем изменить. Первично скрипт запускался на более широкий диапазон дат трудоустройства для обработки уже существующих записей, а в дальнейшем дельта по датам была сведена к последним суткам. Таким образом, вновь оформленные сотрудники автоматически получают свою учетную запись и доступ к важному ресурсу.
Процедура авторегистрации
Возможность самостоятельной регистрации пользователей
Для пользователей, которые по тем или иным причинам не получили свою УЗ, предусмотрели возможность самостоятельной регистрации с помощью заполнения формы, ссылка на которую есть на странице авторизации. Форма реализована на «мощностях» самого Blitz IDP и кастомизирована именно под наши требования — при регистрации пользователя запрашиваются определенные поля, и специально написанное приложение «идет» в кадровую систему, делает сверку этих полей, и, если у пользователя действительно отсутствует УЗ, происходит ее создание.
Блокировка уволенных сотрудников
Для поддержания каталога в актуальном состоянии и исключения событий, связанных с неправомерным доступом к информационным системам, каждую ночь запускается скрипт, проверяющий наличие в кадровой системе записей с проставленной датой увольнения. Если дата присутствует, и она не старше определенного периода, делается выборка сотрудников, и скрипт выполняет блокировку этих пользователей в LDAP-каталоге 398-ds, меняя значение атрибута «locked» учетной записи с «false» на «true». Таким образом, при попытке аутентификации пользователь получает сообщение о блокировке УЗ и доступа к подключенным к IDP провайдеру приложениям больше не имеет.
Самостоятельное восстановление доступа для сотрудников
Рекавери для восстановления пароля у Blitz IDP есть штатно «из коробки» — можно настроить его на подтверждение сброса путем отправки сообщения на указанный в УЗ номер телефона или почту, а вот приложение для «полного восстановления» доступа (для каталога 389-ds) в случае утери доступа к телефону/почте пришлось писать самостоятельно. Работает оно схоже с процедурой саморегистрации, опрашивая пользователя и проверяя его данные в кадровой системе. Если пользователь вводит верные данные, приложение через API меняет атрибуты в учетной записи на новые, указанные пользователем, и сотрудник вновь получает возможность аутентификации на портале и всех подключенных к IDP приложениях.
Таким образом, удалось решить все поставленные задачи — обеспечить всех сотрудников возможностью использования корпоративного портала, обвязать систему аутентификации удобными инструментами регистрации и учесть все требования по безопасности. А еще сотрудники получили такие сопутствующие блага как SSO, сквозную аутентификацию через Kerberos с корпоративных устройств и возможность входа через СМС для тех, кто не хочет запоминать пароли.
После некоторых наблюдений мы убедились и в надежности системы — с единовременной нагрузкой в 7000 пользователей она справилась «на ура», при этом остался достаточный запас по производительности.
Что мы имеем сейчас и выводы спустя время
На данный момент к системе аутентификации на базе Blitz IDP у нас подключено более 20 приложений, удобные аудит логи для коллег из информационной безопасности, добавлены еще несколько LDAP-каталогов пользователей, продуманы и внедрены определенные правила доступа для пользователя относительно его каталога, реализована удобная схема для работы подключенных приложений с ролевой моделью на основе доменных групп.
В итоге мы смогли успешно реализовать единое централизованное место, где пользователь может управлять персональными параметрами доступа к различным системам с возможностью просмотра аудита входов и гибкой настройкой различных параметров входа.
Сейчас система продолжает активно развиваться в различных направлениях, учитывая не только интересы бизнеса, но и другие. Например, требования информационной безопасности. И это еще раз показывает, что мы не ошиблись с выбором продукта — по прошествии достаточно большого количества времени и развития наших сервисов, могу сказать, что Blitz IDP — надежный, удобный и гибкий инструмент.
В заключение среди прочих выводов, хотелось бы отметить важность предварительного анализа задачи, проработки архитектуры и выработки правил/требований для будущего решения. Это позволит избежать создания «однодневных» информационных систем и реализовывать решения, которые будут служить «верой и правдой» долгое время и в дальнейшем помогут сэкономить ресурсы! Как материальные, так и нематериальные.
