IDM на максималках: как управлять доступами к 1500 систем Яндекса и не стать узким местом
Когда в крупной компании появляются десятки, а затем сотни информационных систем, вопросы безопасности перестают решаться локальными договорённостями. Права сотрудников распределяются между базами данных, внутренними сервисами, HR-платформами, финансовыми инструментами и инфраструктурными решениями. В результате становится сложно понять, кто именно имеет доступ, кто его согласовал и на каком основании.
Именно для решения этой задачи создаётся система управления доступом IDM. Она объединяет запрос, согласование, выдачу, проверку и отзыв прав в едином контуре. Сотрудник выбирает нужную систему и роль, указывает цель запроса, после чего IDM определяет маршрут согласования и передаёт команду в целевой сервис. Все действия фиксируются: сохраняются сведения о выданных правах, согласующих лицах и сроках действия доступа.
Пока информационных систем немного, каждая команда может самостоятельно разработать форму заявки, настроить интеграцию и определить правила согласования. Запросы при этом отправляются через почту, чаты, тикеты или интерфейс конкретного сервиса. Но с ростом компании такой подход быстро перестаёт работать. Пользователь не понимает, где оформлять доступ, служба безопасности не может оперативно провести проверку, а аудиторам трудно восстановить историю изменений.
Централизованное управление доступом к информационным системам решает эту проблему, однако одновременно создаёт новую. В Яндексе IDM должен был обслуживать около 1500 систем. По мере роста популярности платформы очередь на подключение стала увеличиваться быстрее, чем команда успевала обрабатывать заявки. Параллельно накапливались запросы на доработки: одним сервисам требовались дополнительные поля, другим - сложные модели ролей, третьим - интеграция с внутренними базами и нестандартные сценарии автоматизации.
Команда IDM поняла, что прежняя модель превращает платформу в сервисное подразделение с ограниченной пропускной способностью. Если каждый коннектор и каждую особенность разрабатывать централизованно, IDM неизбежно станет бутылочным горлышком. Поэтому было принято решение перейти к self-service-подходу: команда платформы задаёт правила и предоставляет инструменты, а владельцы систем самостоятельно подключают свои сервисы.
Подробнее о том, как менялась архитектура и процессы, можно узнать в материале о [масштабировании IDM и управлении доступами](https://habr.com/ru/companies/yandex/articles/1078444/?utm_campaign=1078444&utm_source=habrahabr&utm_medium=rss).
Self-service вместо ручной работы
Новая модель потребовала чётко разделить зоны ответственности. Команда IDM отвечает за базовые возможности, безопасность, аудит, единые правила и стабильность платформы. Владелец подключаемой системы - за реализацию интеграции, корректность ролей и соответствие локальным требованиям.
Для этого был сформирован контракт из нескольких обязательных методов. Метод `Add-role` выдаёт пользователю роль в целевой системе, а `Remove-role` отзывает её. `Info` возвращает справочник доступных ролей, чтобы IDM мог поддерживать актуальное описание ресурсов. Метод `Get-roles` позволяет получить перечень фактически активных ролей пользователей и сопоставить его с данными IDM.
Такая сверка особенно важна: права могут измениться не только через IDM, но и напрямую в целевой системе. Регулярное сравнение выявляет расхождения - например, когда роль была выдана вручную, не была вовремя отозвана или изменилась после обновления структуры доступа. Это делает автоматизацию управления правами доступа не только способом ускорить выдачу ролей, но и инструментом контроля.
Сам контракт недостаточен без проверок. Платформа должна убедиться, что интеграция корректно обрабатывает ошибки, не выдаёт лишние права, умеет повторять временно неуспешные операции и сохраняет понятный журнал действий. Поэтому подключение сопровождается валидацией, тестовыми сценариями и ограничениями, которые защищают общую инфраструктуру от некорректных реализаций.
Гибкость достигается за счёт конфигурации и API. Системы могут использовать стандартный маршрут согласования либо строить собственные процессы поверх базовых механизмов IDM. При этом критичные требования безопасности остаются едиными: обязательные согласования, контроль конфликтующих ролей, аудит и возможность быстро отозвать доступ.
Что изменилось для пользователей и команд
Для сотрудников единая платформа означает предсказуемый путь: не нужно выяснять, кому писать и где искать форму заявки. Для владельцев систем подключение перестаёт зависеть от свободной мощности команды IDM. Они получают инструменты, документацию и понятные требования, а развитие интеграции могут планировать самостоятельно.
Для службы безопасности ценность заключается в прозрачности. В любой момент можно проверить, какие права есть у пользователя, кто их согласовал, когда доступ появился и почему он сохраняется. При изменении должности или увольнении сотрудника права можно централизованно пересмотреть и отозвать.
Однако масштабирование требует постоянного развития самой платформы. При большом количестве систем необходимо следить за качеством справочников ролей, единообразием названий, скоростью обработки запросов и устойчивостью интеграций. Полезными становятся автоматические проверки, метрики задержек, контроль неиспользуемых ролей и регулярная сертификация доступов руководителями.
Важный эффект даёт переход от разовых заявок к жизненному циклу доступа. Роль должна не просто выдаваться, а иметь понятное основание, владельца, срок действия и правила пересмотра. Такой подход снижает накопление избыточных полномочий и помогает реализовать принцип минимально необходимого доступа.
Итоги
Опыт масштабного внедрения показывает: IDM - это не только интерфейс для оформления заявок. Это платформа, которая объединяет идентификацию, роли, согласования, интеграции, аудит и контроль изменений. При небольшом числе систем централизованный подход можно поддерживать силами одной команды, но при росте компании требуется переход к платформенной модели.
Ключом к масштабированию становится self-service-интеграция, основанная на ясных контрактах, API, валидации и единых правилах безопасности. В таком случае управление доступами пользователей перестаёт зависеть от ручной обработки каждой заявки, а команда IDM может сосредоточиться на развитии платформы, а не на бесконечном подключении отдельных сервисов.
Практика показывает, что внедрение IDM-системы должно начинаться не только с выбора технологий, но и с определения ответственности, жизненного цикла ролей и требований к владельцам систем. Тогда единая точка управления доступом действительно уменьшает хаос, а не переносит его из разных сервисов в одну перегруженную команду. Дополнительные архитектурные детали и подходы к масштабированию описаны в материале о [централизованном управлении правами](https://habr.com/ru/companies/yandex/articles/1078444/?utm_campaign=1078444&utm_source=habrahabr&utm_medium=rss).
