Как мы сделали мультиплатформенный механизм для сброса пароля в IDM

Меня зовут Илья, я работаю в Группе Rubytech в департаменте информационной безопасности, и в этой статье расскажу, как мы сильно упростили себе жизнь, сделав сброс пароля мультиплатформенным. Если вы вдруг в вашей компании планируете что-то подобное — вам пригодится. А если просто интересно, как все это устроено — добро пожаловать под кат.

Зачем нам вообще это понадобилось

Современное корпоративное ИТ-пространство перестало быть монолитным.

Сейчас компания с точки зрения архитектуры предприятия представляет собой гибридную среду, включающую локальные службы каталогов (Active Directory), облачные платформы идентификации (Azure AD / Entra ID, Okta, Keycloak), а также серверные сегменты под управлением различных дистрибутивов Linux (RHEL, Debian, Astra Linux) и рабочих станций с Windows и macOS.

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

Так что именно отсутствие хоть насколько-то унифицированного подхода и вынуждает админов поддерживать откровенный зоопарк разрозненных механизмов. Кроме ожидаемого неудобства, тут есть ещё один минус — это увеличивает среднее время восстановления доступа (MTTR — Mean Time To Recover) до нескольких часов, парализуя работу сотрудников при блокировке учетной записи после неудачных попыток входа. Ну, на случай, если одного минуса вам было недостаточно.

Вот мы и решили сделать механизм универсальным.

Архитектурная концепция универсального механизма в IDM

Для решения этой проблемы система класса IDM Avanpost должна выступать единым оркестратором, абстрагирующим конечную платформу от пользователя.

Вот какие принципы мы прописали для универсальный механизма сброса пароля:

1. Единый фронт-енд (Self-Service Portal): пользователь инициирует процедуру через унифицированный веб-интерфейс, независимо от того, пароль какой ОС ему надо сбросить.

2. Многофакторная верификация личности (MFA): это обязательный этап подтверждения прав на сброс через независимые каналы (OTP/TOTP, пуш-уведомления, биометрия, резервные коды, кому что удобнее). Это нивелирует риски использования самого механизма сброса для несанкционированного захвата учетки, потому что бывает и такое.

3. Абстрактивный слой коннекторов: ядро IDM транслирует единую команду сброса в нативные протоколы целевых систем через безопасные API-коннекторы.

4. Криптографически безопасный канал передачи: доставка пароля происходит по зашифрованным каналам передачи данных, пароль не хранится в явном виде. Нигде и никогда.

5. Поддержку ротации паролей в паролевых хранилищах.

А теперь давайте про каждый из этих пяти принципов подробнее.

Единый фронт-енд (Self-Service Portal)

Мы разработали централизованный интерфейс самообслуживания, скрывающий от пользователя сложность гетерогенной ИТ-инфраструктуры. То есть человек видит один удобный интерфейс и не понимает, какие ужасы из чего на самом деле состоит вся инфраструктура.

Ключевым элементом является универсальная экранная форма сброса пароля:

1. Открывается по нажатию штатной кнопки «Сбросить пароль» на объектах управления внутри IDM.

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

3. При подтверждении введенного пароля экранная форма просит пользователя подтвердить сброс пароля, используя многофакторную верификацию.

4. После успешного подтверждения личности форма отображает два концептуально разных сообщения: либо «Пароль успешно сброшен», либо отобразит причину неуспешного сброса пароля.

Многофакторная верификация личности (MFA)

MFA на экране сброса пароля мы сделали через два независимых канала подтверждения:

• Приложение-аутентификатор (OTP/TOTP): основной и наиболее защищенный метод. На экранной форме по умолчанию активно поле для ввода 6-значного кода из мобильного приложения (например, Google Authenticator, Яндекс.Ключ или корпоративный токен). Код генерируется локально на устройстве сотрудника по алгоритму со счетчиком времени (TOTP) каждые 30–60 секунд и не зависит от сотовой сети.

• СМС-сообщение: это уже как резервный канал. Если приложение недоступно, пользователь выбирает альтернативу, и система отправляет одноразовый цифровой код в текстовом сообщении на привязанный номер телефона сотрудника.

  Выбор метода осуществляется переключателем на самой форме — тут кому как удобнее в конкретный момент времени. Но по умолчанию портал ожидает ввод именно OTP-кода как более устойчивого к перехвату трафика и атакам типа SIM-swapping.

Абстрактивный слой коннекторов

Технический посредник, который переводит единую команду сброса от портала в нативные протоколы каждой системы.

Для каждой операционной системы и учетной записи IDM вызывает свой специфический коннектор: например, LDAP/WinRM для Active Directory, SSH-агента или SSSD для Linux и соответствующие API-интерфейсы для облачных приложений (например, SCIM). Это позволяет ядру IDM не знать особенностей реализации каждой ОС, работая с ними через унифицированный программный интерфейс (API).

Криптографически безопасный канал передачи

Мы предприняли комплекс мер, гарантирующий конфиденциальность данных на всем пути от пользователя до целевой системы.

Передача паролей

Система IDM работает по принципу Zero Knowledge (нулевого разглашения). Мы не храним действующие или новые пароли пользователей в открытом виде ни на портале самообслуживания, ни в базе данных ядра IDM. Как я и писал, нигде и никогда, да. Пароль передается только один раз внутри защищенного транспортного канала (TLS 1.2+) и немедленно зашифровывается асимметричным ключом конкретного коннектора перед отправкой в целевую систему (например, через протоколы LDAPS, WinRM over HTTPS или SSH). В самом ядре IDM может сохраняться лишь криптографический хеш для аудита факта смены.

Защита OTP-кодов

Одноразовые коды подтверждения мы тоже никогда не храним в открытом виде. При генерации запроса сессионный токен или код MFA сразу же шифруется симметричным алгоритмом (AES-256) с использованием уникального ключа данной сессии. Расшифровка происходит только в оперативной памяти модуля верификации в момент ввода кода пользователем. После успешной проверки или истечения времени жизни (TTL) расшифрованное значение уничтожается, а в системных логах фиксируется только факт прохождения этапа без сохранения самого значения кода.

Поддержка ротации паролей в паролевых хранилищах

При сбросе пароля через единый механизм IDM он автоматически обновляется не только в целевых системах (Active Directory, Linux), но и на сервере парольного хранилища. Это гарантирует, что централизованный сейф всегда содержит актуальный пароль для сервисных или привилегированных учетных записей, предотвращая сбои автоматизированных процессов.

Что мы получили в результате

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

Вот чего мы добились:

• Абстракция платформ через единый фронт-энд: для пользователя процедура восстановления доступа стала единообразной. Независимо от того, заблокирована ли учетная запись в Active Directory, на сервере под управлением Astra Linux или в облачном приложении, сотрудник использует один и тот же веб-интерфейс. Это полностью устранило когнитивную нагрузку и необходимость запоминать разные инструкции для разных ОС.

• Безопасность без ущерба удобству (MFA): обязательная многофакторка нивелировала риски несанкционированного захвата учеток через функцию сброса. При этом благодаря выбору метода по умолчанию (OTP-приложение) процесс занимает у сотрудника не более 30 секунд. Пользователи отмечают предсказуемость: «Я точно знаю, куда нажать и где взять код».

• Отказоустойчивость оркестрации (слой коннекторов): ядро системы работает как универсальный транслятор. Добавление новых систем в инфраструктуру больше не требует обучения пользователей новым сценариям — достаточно подключить новый бэкенд-коннектор. Процесс смены пароля теперь выполняется атомарно во всех связанных системах, исключая частичные сбои синхронизации.

• Гарантированная конфиденциальность данных: криптографически защищенные каналы (TLS 1.2+) и отказ от хранения паролей в явном виде позволили нам успешно пройти аудит информационной безопасности. Все данные шифруются в оперативной памяти и передаются нативным протоколам целевых систем только в защищенном виде.

• Целостность секретов (ротация в хранилищах): автоматическая синхронизация с паролевыми сейфами исключила простои автоматизированных сервисов мониторинга и резервного копирования, которые ранее возникали при ручной смене административных паролей.

Как это восприняли люди и бизнес

Положительный пользовательский опыт: сотрудники высоко оценили возможность самостоятельного решения проблемы забытого пароля в режиме 24/7 без ожидания ответа службы поддержки. В опросах отмечается фраза: «Сбросил сам за минуту и продолжил работу». Процесс воспринимается как интуитивно понятный и прозрачный.

Бесперебойность бизнес-процессов: время простоя квалифицированных специалистов при блокировке аккаунта сократилось со средних 2–3 часов до 1–2 минут. Для удаленных сотрудников эффект оказался наиболее значимым — отпала необходимость физического присутствия в офисе или использования корпоративных ServiceDesk для восстановления доступа.

Экономический эффект: нагрузка на службу технической поддержки снизилась по инцидентам категорий «Забытый пароль» и «Разблокировка учетной записи», что позволило перераспределить ресурсы инженеров первой линии на профильные задачи развития инфраструктуры.

В общем, плюсы есть, минусов не замечено. Если у вас тоже были проблемы со множеством систем в плане IDM и вы делали что-то универсальное, чтобы сэкономить всем время и нервы без потери уровня ИБ — поделитесь в комментариях.