IDM на максималках: как управлять доступами к 1500 системам и не превратить платформу в узкое место
Когда в компании десятки или сотни информационных систем, управление доступами быстро перестаёт быть локальной задачей отдельных команд. Права выдаются через почту, чаты, тикеты и интерфейсы самих сервисов. В результате сложно понять, кто имеет доступ, на каком основании он появился, кто его согласовал и действительно ли он ещё нужен.
Именно эту проблему решает IDM - Identity Management System, единая платформа для управления учётными записями, ролями и разрешениями. Через неё сотрудник может запросить доступ, руководитель или владелец системы - подтвердить его, а целевая система - автоматически выдать нужную роль. Все события фиксируются: от создания заявки до отзыва разрешения.
На раннем этапе централизованный подход действительно устраняет хаос. Однако при масштабировании возникает новая проблема: сама команда IDM становится единственной точкой, через которую проходят все изменения. Так произошло и в крупной инфраструктуре Яндекса. Очередь на подключение новых систем начала расти быстрее, чем команда успевала их интегрировать, а запросы на доработки стали поступать практически от каждого подразделения.
Как единая система управления доступами становится узким местом
Сначала подключение системы к IDM выглядело как обычный проект. Команда IDM изучала особенности сервиса, проектировала интеграцию, добавляла нужные поля, настраивала согласования и проверяла корректность выдачи ролей.
Но у каждой системы быстро обнаруживались собственные требования. Одним нужно было указывать дополнительные параметры при запросе доступа, другим - поддерживать сложную иерархию ролей. Где-то требовалось получать сведения из внутренней базы, а где-то - запускать нестандартную автоматизацию после согласования заявки.
В результате платформа, созданная для упрощения процессов, сама стала источником очередей. Команда IDM одновременно выступала разработчиком интеграций, консультантом, владельцем бизнес-процессов и оператором поддержки. При подключении примерно 1500 систем такой подход перестал масштабироваться.
Выходом стала смена модели: IDM должен был превратиться из сервисной команды, которая вручную выполняет заявки, в платформу для самостоятельного подключения систем.
Self-service вместо ручной интеграции
Self-service-модель предполагает чёткое разделение ответственности. Платформа предоставляет единые правила, базовые механизмы, средства контроля и требования безопасности. Команды, владеющие системами, самостоятельно описывают свои роли, процессы и интеграционные сценарии в рамках заданного контракта.
Чтобы это работало, необходимо заранее определить:
- какие операции обязана поддерживать каждая подключаемая система;
- в каком формате передаются данные;
- как проверяется корректность интеграции;
- какие ограничения нельзя обойти;
- какие настройки можно менять без участия команды IDM;
- как обрабатываются ошибки и повторные запросы.
Основой интеграции стал стандартный набор операций. Метод `Add-role` отвечает за выдачу роли пользователю, `Remove-role` - за её отзыв. Дополнительно используются операции для проверки текущего состояния доступа и получения списка доступных ролей. Благодаря этому IDM не должен знать внутреннее устройство каждого сервиса: ему достаточно понимать общий контракт.
Однако одного API недостаточно. Если разрешить системам полностью самостоятельно определять поведение, единая платформа быстро потеряет управляемость. Поэтому вместе с гибкостью нужны строгая схема данных, обязательные проверки и единый жизненный цикл заявки.
Контракты, валидация и границы ответственности
Контракт подключения описывает не только технические методы, но и смысл передаваемых данных. В нём фиксируется, что такое пользователь, роль, система, заявка и результат операции. Отдельно задаются требования к идентификаторам, срокам действия доступа, обработке повторных запросов и возврату ошибок.
Валидация должна выполняться до подключения системы в промышленную эксплуатацию. Она проверяет, например:
- можно ли однозначно определить пользователя;
- не выдаётся ли роль несуществующей учётной записи;
- корректно ли обрабатывается повторная выдача;
- действительно ли отзыв доступа удаляет разрешение;
- возвращает ли система понятный статус операции;
- сохраняется ли возможность восстановить историю изменений.
Особенно важна идемпотентность. Повторный вызов операции не должен приводить к непредсказуемому результату. Если роль уже выдана, повторная команда выдачи должна завершаться безопасно, а не создавать дубликаты или ломать состояние доступа.
Настраиваемые процессы согласования
У разных систем отличаются требования к подтверждению доступа. Где-то достаточно согласования руководителя, где-то нужен владелец ресурса, служба безопасности или несколько независимых подтверждений.
Поэтому в IDM нельзя ограничиваться одним жёстко зашитым маршрутом. Платформа должна поддерживать настраиваемые процессы: последовательное и параллельное согласование, обязательные и условные этапы, автоматическое подтверждение для отдельных ролей, а также дополнительные проверки риска.
При этом гибкость не должна превращаться в бесконтрольность. Нельзя позволять владельцу системы отключить обязательное согласование или выдать критическую роль без фиксации основания. Важные правила должны находиться на уровне платформы и применяться ко всем интеграциям одинаково.
Роли необходимо отделять от технических разрешений
Одна из самых сложных задач - согласовать понятную пользователю модель ролей с реальными разрешениями внутри системы. Сотруднику проще запросить роль "аналитик" или "оператор", чем разбираться в десятках технических флагов. Но целевая система может хранить права совсем иначе.
Поэтому IDM должен поддерживать слой преобразования: бизнес-роль сопоставляется с набором технических разрешений. Такое разделение позволяет менять внутреннюю реализацию системы без пересмотра всех процессов согласования. Одновременно владельцу ресурса проще контролировать, какие полномочия входят в конкретную роль.
Полезно также хранить описание каждой роли, её владельца, уровень критичности, срок действия и условия предоставления. Без этого каталог постепенно превращается в перечень непонятных обозначений, а пользователи начинают выбирать роли наугад.
Сверка фактических и заявленных доступов
Автоматическая выдача прав не гарантирует, что состояние системы всегда останется корректным. Администратор может изменить роль вручную, интеграция может завершиться ошибкой, а учётная запись - быть удалена не во всех связанных сервисах.
Поэтому важной частью IDM становится периодическая сверка. Платформа сравнивает ожидаемые доступы с фактическими и выявляет расхождения. Если роль должна быть выдана, но отсутствует, её можно восстановить. Если доступ существует без основания, он направляется на проверку или автоматически отзывается согласно политике.
Сверка также помогает обнаруживать "осиротевшие" права - разрешения, которые остались после перевода сотрудника, увольнения или изменения должности. Именно такие доступы часто становятся наиболее серьёзным риском для безопасности.
Как не перегрузить центральную платформу
При большом количестве систем IDM должен быть рассчитан на независимое выполнение операций. Медленная или временно недоступная целевая система не должна блокировать обработку всех остальных заявок.
Для этого применяются очереди, повторные попытки, ограничение частоты запросов и изоляция интеграций. Каждая операция получает уникальный идентификатор, а её состояние можно отследить от постановки в очередь до окончательного результата.
Нужны и понятные статусы: "создано", "ожидает согласования", "передано в систему", "выполнено", "ошибка", "требует вмешательства". Такая модель упрощает поддержку и не заставляет пользователей обращаться к администраторам за информацией о каждой заявке.
Наблюдаемость и аудит
В системе управления доступами недостаточно знать только конечный результат. Для расследований и аудита важно видеть всю цепочку событий: кто запросил разрешение, кто его подтвердил, какие проверки были выполнены, когда произошла выдача и по какой причине доступ был отозван.
Журнал должен быть защищён от незаметного изменения, а события - связаны между собой. Полезно разделять технические логи и бизнес-аудит: первые нужны разработчикам для диагностики, вторые - специалистам по безопасности, аудиторам и владельцам систем.
Отдельное внимание стоит уделить уведомлениям. Пользователь должен понимать, почему заявка задержалась, а владелец - какие действия требуют его участия. При этом чрезмерное количество сообщений создаёт информационный шум, поэтому уведомления лучше строить вокруг действительно значимых изменений.
Что даёт переход к платформенной модели
Self-service-интеграция не отменяет работу команды IDM, а меняет её характер. Вместо постоянного выполнения однотипных заявок специалисты занимаются развитием платформы, безопасностью, качеством контрактов, инструментами диагностики и поддержкой сложных сценариев.
Команды систем получают больше самостоятельности и быстрее подключают сервисы. Пользователи видят единый интерфейс и одинаковую логику запросов. Служба безопасности получает централизованный аудит, единые политики и возможность регулярно пересматривать права.
Главный вывод масштабного проекта прост: централизовать нужно правила и контроль, но не каждое действие. Если вся работа выполняется одной командой, даже хорошо спроектированная система неизбежно становится бутылочным горлышком. Масштабирование начинается тогда, когда платформа задаёт безопасные рамки, а команды внутри этих рамок могут самостоятельно подключать системы, настраивать роли и развивать собственные процессы.