Привет, Хабр! На связи команда данных «МосТрансПроекта». Недавно мы рассказывали про бот «Информатум», в котором хранятся служебные презентации. При разработке системы мы уделили особое внимание защите чувствительной информации. Поэтому доступ к материалам предоставляется сотрудникам только после авторизации и подтверждения их данных. Но что, если появится еще несколько ботов? Неужели сотрудникам придется каждый раз проходить проверку для доступа к новым сервисам, а администраторам тратить время на верификацию? Для решения этой задачи мы разработали универсальное и экономящее время решение, о котором расскажем в данной статье.
Точка входа
Одна из ключевых задач, которую мы постоянно решаем в МосТрансПроекте – автоматизация и сокращение времени на решение запросов и проблем, которые могут возникать в ходе работы. Именно так и появился «Информатум». Какое-то время он был единственным из ботов в экосистеме наших сервисов. Соответственно, проблема авторизации не стояла столь остро: новый пользователь запускал бот, указывал данные, администратор проверял их, а затем давал отмашку техническим специалистам – открыть или запретить доступ к функциям и материалам «Информатума».
Однако в прошлом году все изменилось. Например, у нас появился Ihelp – бот службы технической поддержки, где пользователи могут оперативно решить возникающие проблемы с оборудованием или сервисами, проконсультироваться со специалистами, получить доступ к необходимым для работы информационным системам (пишите в комментариях, если хотите, чтобы мы рассказали о его разработке в отдельной статье).
Наличие нескольких ботов, в каждом из которых была своя собственная система авторизации и аутентификации, само по себе стало трудозатратным и неэффективным процессом. Сотрудники, зарегистрированные в одном из сервисов, были вынуждены повторно проходить процедуру регистрации в остальных, администраторы тратили время на подтверждение их личности, технические специалисты – на написание скриптов для подключения к боту. Отсутствие единой базы пользователей требовало постоянного мониторинга и ручного удаления подписчиков (например, тех, кто сменил место работы и перешел в другую компанию). Мы тратили на это огромное количество рабочего времени. Однако, что еще хуже, решения, которые изначально задумывались для упрощения пути пользователя от возникновения потребности до ее удовлетворения, на самом деле стали его усложнять.
Так перед нами в полный рост встала проблема внедрения единой и максимально автоматизированной системы доступа в корпоративные боты. Мы хотели сделать так, чтобы пользователь мог один раз зарегистрироваться в одном из сервисов и при этом имел возможность пользоваться всеми остальными, как уже запущенными, так и перспективными. И здесь, как это часто бывает, мы оказались на развилке.
Вход служебный, но не черный
Основной вопрос, который стоял перед нами в начале работы – что лучше, найти уже готовое работающее решение или попробовать создать его самим? Изучив существующие варианты, мы пришли к выводу, что ни один из них не устраивал нас на все 100%: на просторах сети просто не существовало сервиса, который позволял бы получить контроль над всеми нужными нам ресурсами. К тому же, важно было обеспечить единую архитектуру у всех ботов. Таким образом, оптимальным вариантом была выбрана самостоятельная разработка: только она позволяла учесть все наши потребности и «хотелки».
Здесь начинается путь Единой Системы Авторизации в Ботах, которые мы в ИТ-команде ласково назвали ЕСАБ.
Одним из ключевых требований к новому сервису стала конфиденциальность: поскольку доступ к ботам по плану должен быть полностью автоматизированным, получать его должны только те люди, которые работают в МосТрансПроекте. Мы рассматривали несколько вариантов, как реализовать это на практике. Естественно, самым очевидным решением было бы связать базу учетных записей и базу ЕСАБ. Однако от этой идеи довольно быстро отказались, потому что уникальные идентификаторы сотрудников используются не на всех внутренних ресурсах.
Тогда наш ИТ-директор предложил альтернативный вариант – авторизацию с помощью указания адреса корпоративной почты. Для этого нам пришлось использовать простой SMTP-сервер: при первом входе в один из ботов у пользователя запрашивается адрес почтового ящика, на который будет направлено письмо со ссылкой для авторизации. Она действительна только для одного перехода и только в течение 30 минут (это ограничение введено на случай, если человек неправильно укажет адрес, и ссылка придет другому сотруднику). Таким образом, мы исключаем возможность повторной регистрации сторонних пользователей по той же самой ссылке.
После подтверждения почты для сотрудника создается учетная запись в базе ЕСАБ, которая подтягивает его данные во все остальные боты: человеку достаточно их запустить, подождать 1-2 секунды, за которые произойдет верификация, и далее пользоваться всеми доступными функциями. Подробнее о том, как это работаем – в следующем разделе.
Пути пользователя неисповедимы
Теперь давайте пошагово опишем путь пользователя, который он проходит после внедрения ЕСАБ.
Сразу оговоримся, что авторизация возможна только при подключении к корпоративной сети или единому VPN-клиенту организации. Это является дополнительной мерой защиты от утечки критических данных.
Пользователь заходит в один из ботов и нажимаем кнопку /start.
Далее бот отправляет ему вводное сообщение с «рассказом о себе» (зачем он нужен, как им пользоваться и т.п.), а затем предлагает указать адрес рабочей почты для дальнейшей авторизации
Пользователь указывает свою почту. Если она введена без ошибок и реально существует, SMTP-сервер отправляет на нее письмо, содержащее ссылку для авторизации. Бот информирует, что ссылка действительна только в течение 30 минут: если не успеть, то процедуру регистрации придется пройти заново
Пользователь заходит в свой почтовый ящик, открывает письмо и кликает по присланной ссылке. После этого он автоматический переходит в бот и может пользоваться всем его функционалом.
Процесс удаления пользователя из бота при этом стал полностью автоматизированным. Если раньше сотрудников, которые по то или иной причине забывали отписаться от корпоративных ботов после увольнения, администраторам приходилось «вычищать» вручную (причем отдельно в каждом из ботов), то теперь ЕСАБ делает это самостоятельно. Происходит это следующим образом.
Как только рабочая почта уволившегося человека блокируется, она перестает отображаться в системе Битрикс24, где заведены аккаунты для каждого работника МосТрансПроекта. ЕСАБ обрабатывает данную информацию, помечает флажок пользователя как неактивный и сразу же удаляет его изо всех ботов. Это происходит практически в режиме реального времени: ушедший из компании сотрудник в тот же день теряет доступ ко всем корпоративным ресурсам одновременно. Таким образом, мы полностью устранили человеческий фактор и необходимость постоянного мониторинга пользователей со стороны нашей команды, а значит, и потенциальные ошибки, которые могли быть с этим связаны.
Да, удобство, безопасность, повышение комфорта целевой аудитории сервиса – безусловно, прекрасные и красивые слова, однако зачастую за ними скрывается практически полное отсутствие реальной пользы для конечных пользователей продукта и «разработка новых фичей ради разработки новых фичей». Поэтому мы как люди, постоянно работающие с данными, хотели бы показать простые и измеримые показатели, которые наглядно продемонстрируют улучшения в процессе авторизации в ботах. О них и расскажем в следующем разделе.
Где цифры, Зин?
Перед началом работ мы собрали статистику по затраченному времени на регистрацию и удаление пользователей в «Информатуме», одном из корпоративных ботов, о котором рассказывали в одной из предыдущих статей. Подчеркнем, что в данном случае речь идет о получении доступа к одному боту одного сотрудника: если же он хотел подписаться на двух и более ботов, то указанные далее временные показатели также пропорционально увеличивались.
До внедрения ЕСАБ в процессе авторизации участвовало минимум три человека. Они совокупно тратили на это 19 минут своего рабочего времени.
Пользователь | Администратор | Разработчик |
Поиск администратора и создание сообщения с просьбой о добавлении в бот – 5 минут Проверка после выдачи доступа к боту – 2 минуты Заполнение своих данных – 1 минута | Ответ пользователю – 2 минуты Передачу данных пользователя нашей команде – 3 минуты Уведомление пользователя о том, что ему необходимо проверить доступ – 1 минута | Написание скрипта для добавления пользователя – 4 минуты Проверка того, чтобы пользователь успешно получил доступ – 1 минута |
После внедрения ЕСАБ была полностью исключена ручная работа администратора и разработчика, а пользователь стал тратить на процесс авторизации три минуты своего времени:
1 минуту – для того, чтобы указать свои данные
2 минуты – для того, чтобы зайти на корпоративную почту, прочитать письмо и перейти по ссылке для авторизации.
Итого, у нас получилось сократить время, затрачиваемое на подключение к ботам, в шесть раз, а также минимизировать человеческий фактор.
А удаление пользователей стало полностью автоматизированным, как мы и писали выше. Т.е. на него тратится ровно 0 минут человеческого времени. Ранее же этот процесс требовал скоординированной работы минимум трех сотрудников и занимал в среднем 11 минут:
Администратор запрашивал у HR-менеджера выгрузку сотрудников, уволенных за неделю – 1 минута
HR-менеджер готовил список сотрудников и отправлял его администратору – 3 минуты
Администратор ВРУЧНУЮ сравнивал присланный документ с базой пользователей, находил тех, кого нужно удалить из бота, и ставил задачу разработчику – 5 минут
Разработчик удалял сотрудника из бота – 2 минуты.
Итого, полный цикл регистрации в боте и последующего удаления сократился с 30 минут до трех, а количество человек, которые в нем участвовали – с четырех до одного. В масштабах компании, где работает больше 500 сотрудников, это дни и недели (а в перспективе – и месяцы) времени, сэкономленного благодаря внедрению ЕСАБ.
Путь открыт
Безусловно мы не могли не предусмотреть возможность подключения к системе ботов наших коллег из транспортного комплекса Москвы, которые находятся за пределами контура Института. Полностью автоматизированная схема регистрации в данном случае не смогла бы работать корректно, поэтому для таких пользователей был разработан отдельный путь, включающий ручное одобрение заявки администратором. Он, в целом, повторяет стандартные шаги, которые мы описали выше. Единственная разница состоит в том, что при указании внешнего адреса рабочей почты, уведомление о запросе доступа к боту поступает напрямую администратору. Далее у него есть два рабочих дня, чтобы выяснить все необходимые детали и вынести решение: одобрить или отклонить заявку.
Один раз в неделю проводится аудит внешних пользователей в ЕСАБ. Администратор выгружает их список из системы и проверяет статус каждого на Транспортном портале. После этого все пользователи, которые больше не являются сотрудниками транспортного комплекса, оперативно удаляются из ЕСАБ, а значит и из всех корпоративных ботов одновременно.
Естественно, это не массовая история. Подключения пользователей из внешнего контура – единичные случаи, поэтому все они обычно уже заранее согласованы между руководством МосТрансПроекта и представителями транспортного комплекса. Кроме того, написать напрямую администраторам и запросить права доступа могут и внутренние пользователи. Например, если у них возникли какие-либо технические проблемы и авторизоваться привычным путем не получилось. К счастью, такое происходит довольно редко, но мы все равно стараемся максимально быстро разбираться в подобных ситуациях и помогать коллегам.
На этом месте у читателей наверняка уже возник вопрос – «Окей, вы самостоятельно придумали и разработали сервис, упростивший жизнь вам и вашим пользователям. Но как именно это было реализовано с технической стороны? Какие из ваших идей можно масштабировать и внедрить в своей компании?»
Что ж, давайте разбираться.
А что под капом?
Наш микросервис состоит из нескольких компонентов.
FastAPI – основное приложение, которое обрабатывает запросы и управляет логикой авторизации.
PostgreSQL – база для хранения данных пользователей и одноразовых токенов авторизации.
RabbitMQ – брокер сообщений, он используется для передачи данных между сервисами и управления очередью.
SMTP-Server – почтовый сервер для отправки писем на корпоративную почту.
Apache Airflow – в нашем случае выполняет функцию планировщика, который по расписанию вызывает endpoint для обновления данных пользователей из системы Битрикс24.
А вот схемы их взаимодействия.
Как видите, при внедрении ЕСАБ мы не использовали сложных решений, а основная задача состояла в том, чтобы грамотно соединить простые базовые компоненты в эффективно работающую схему. Поэтому они легко масштабируются и поддерживают интеграцию в другие сервисы. Наша команда будет рада, если вы сможете применить часть наших идей при реализации своих проектов.
Над внедрением ЕСАБ работали: Дарья Архипова и Илья Фошин.
А как решаете кейсы с авторизацией сотрудников компании в корпоративных ботах? Пишите в комментариях.
