Identity Management (IdM) в компании: выстраиваем пошагово

В любой компании есть практически неизбежная болезнь роста, которой лучше переболеть как можно раньше — безалаберное управление доступами.

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

Потом, как правило, следует какой-то киберинцидент и появляется желание, а иногда и воля, навести порядок в управлении идентичностями (Identity Management).

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

Проблема в том, что идентичностей становится слишком много:
● сотрудники одновременно работают в облаках, локальных сервисах, почте, CRM, VPN, тестовых средах;
● у каждого несколько учетных записей;
● при смене должности роли меняются, а старые права остаются;
● подрядчикам создают временные доступы, которые забывают отключать;
● администраторы хранят пароли в таблицах, заметках, мессенджерах.

Identity Management или, более широко, Identity and Access Management (IAM) нужен для того, чтобы связать все это в один управляемый процесс с пониманием: кто является пользователем, какие у него полномочия, какие системы ему действительно нужны, кто выдал ему доступ, что происходит при смене роли, как быстро доступы будут отозваны при уходе.

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

Что входит в IAM-систему на практике
В реальных проектах IAM почти всегда строится вокруг пяти основных элементов. Ниже описываем их подробнее.

А. Жизненный цикл пользователя
Три ключевых события:
● приход в компанию — создание учетной записи, назначение ролей;
● переход между отделами — изменение прав;
● увольнение — полный отзыв доступа.

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

Б. Роли и права
Роль — это набор прав, который соответствует должности или функции.

Например бухгалтер имеет доступ к учетным системам и документам, разработчик — к репозиториям, тестовым стендам и VPN, менеджер — к CRM и корпоративным сервисам.

Когда доступы выдаются через роли, их проще назначать, проверять и пересматривать.

Г. Аутентификация
Аутентификация — это про простой вопрос: кто именно сейчас пытается войти в систему.

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

Поэтому в IAM почти всегда добавляют дополнительные способы подтверждения. Одноразовые коды, аппаратные ключи, подтверждение входа через приложение или биометрию. Обычно их используют вместе, а не выборочно.

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

Также постепенно (вернее, очень постепенно) набирают пополярность различные механизмы безпарольной аутентификации, например Passkeys и аппаратные токены/USB-ключи.

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

В зрелой IAM-модели такие учетные записи отделяются от обычных. Администратор работает под стандартной учеткой, а повышенные права получает только на время конкретной задачи. Это резко снижает риск того, что компрометация одной записи приведет к полному контролю над системой.

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

Часто добавляют и технические ограничения. Вход только с доверенных устройств или через защищенный доступ. Это делает атаки через украденные пароли или фишинг заметно сложнее и повышает управляемость всей системы.

В более зрелых организациях для управления привилегированным доступом используются отдельные PAM-системы (Privileged Access Management).

Е. Управление учетными данными
Это один из самых недооцененных элементов в IAM. Роли и права могут быть описаны идеально, но на практике все ломается в момент, когда дело доходит до реальных секретов.

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

Поэтому в зрелых IAM-проектах отдельно выделяют управление учетными данными. Эту задачу обычно решают корпоративные менеджеры паролей (Corporate Password Managers).

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

В российских компаниях эту роль часто закрывает менеджер паролей «ОдинКлюч». Он не подменяет собой всю IAM-систему, но дополняет ее там, где классические механизмы заканчиваются. Роли и политики отвечают за то, кому доступ разрешен, а «ОдинКлюч» за то, как именно этот доступ реализуется на уровне реальных секретов.

В результате управление учетными данными становится частью общей модели доступа.

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

Важное предупреждение: внедрение IAM — это не быстрый технический тюнинг, а комплексный организационно-технический проект. Он потребует инвестиций, времени (от нескольких месяцев до года) и сильной поддержки руководства.

Разобраться с типами пользователей
Сначала нужно понять, кто вообще работает с системами. Без этого дальше идти бессмысленно.

Обычно выделяют четыре группы:
— сотрудники — постоянные пользователи корпоративных сервисов;
— подрядчики — внешние специалисты с ограниченным доступом;
— сервисные учетные записи — для автоматизации, интеграций, скриптов;
— временные доступы — консультанты, сезонные сотрудники, проектные роли.

Если на этом этапе нет ясности, IAM превращается в свалку доступов. Доступы начинают выдаваться, а отозвать их потом забывают.

Совет: не пытайтесь описать всех и всё идеально с первого раза. Начните с одной-двух самых понятных и важных групп (например, постоянные сотрудники и ИТ-администраторы). Это позволит быстрее запустить пилот и получить первый результат!

Описать роли
Следующим шагом нужно уйти от логики, что доступы выдаются человку и перейти к ролям.

Роль — это не имя сотрудника, а функция. Например: бухгалтер, разработчик, менеджер, администратор.

Для каждой роли фиксируют:
— к каким системам нужен доступ;
— какие действия разрешены;
— какие ограничения действуют.

Так доступы становятся предсказуемыми. Новый сотрудник получает роль и вместе с ней ровно тот набор прав, который нужен для работы, без лишнего.

Связать роли с системами
После описания ролей их необходимо связать с конкретными системами и сервисами, в которых работают пользователи

На этом этапе определяют:
— какие права у роли в каждой системе;
— где нужен второй фактор;
— какие действия должны фиксироваться в журналах.

Ключевая техническая задача здесь — определить «Источник истины» (Source of Truth). Им должна стать одна система, из которой автоматически берутся данные о сотрудниках, их должностях и структуре подразделений. Без этой синхронизации процесс рассыпается.

Именно здесь IAM начинает работать как процесс. Доступы можно выдавать и отзывать не вручную, а по правилам.

Настроить жизненный цикл учетных записей
Дальше описывается простой, но обязательный порядок работы с учетками. Например:
● Новый сотрудник: HR инициирует запрос, руководитель подтверждает роль, ИТ создает учетные записи, пользователю выдают доступы и инструкции.
● Смена должности: Права пересматриваются, лишние доступы убираются, новые добавляются.
● Увольнение: Учетные записи блокируются, секреты отзываются, внешние сервисы отключаются.

Этот процесс должен быть максимально автоматизирован. Чем больше ручных действий, тем выше риск, что что-то забудут.

Взять под контроль привилегированные учетные записи
Административные доступы самая чувствительная часть любой инфраструктуры.

В зрелой модели для них действует отдельный набор правил:
— админские учетные записи отделены от обычных;
— секреты не хранятся у конкретных людей;
— все действия фиксируются;
— права регулярно пересматриваются.

Это снижает риск инцидентов и упрощает разбор, если что-то пошло не так.

Упорядочить работу с учетными данными
Даже при идеальных ролях IAM ломается там, где начинаются реальные пароли и ключи.

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

Поэтому в IAM почти всегда появляется отдельный класс решений — PAM (Privileged Access Management) или корпоративные менеджеры паролей. Они специализируются именно на контроле над учетными данными, особенно привилегированными.

Такой инструмент решает три задачи:
— хранит пароли и ключи централизованно;
— дает доступ без раскрытия самого секрета;
— показывает, кто и когда этим доступом пользовался.

Включить журналирование и контроль
Система должна отвечать на простые вопросы:
— кто входил;
— откуда;
— что делал;
— кто запросил повышение прав.

Эти данные нужны и для расследований, и для внутренних проверок. Без них невозможно понять, что происходит с доступами на самом деле. Кроме того, детальное журналирование — обязательное требование многих стандартов безопасности (ФЗ-152, ГОСТ Р 57 580, ISO 27 001). На основе этих логов также стоит построить ключевые метрики (KPI) системы IAM, например: «Среднее время выдачи доступа» или «Время полного отзыва при увольнении».

Регулярно пересматривать доступы
Не нужно думать, что это разовая настройка. Хотя бы раз в полгода нужно:
— сверять роли с фактическими правами;
— убирать лишние доступы;
— проверять админские учетные записи;
— обновлять правила при изменении инфраструктуры.

Это самый скучный этап, но именно он удерживает систему в рабочем состоянии.

Измеряйте результат и готовьтесь к сложностям
Внедрение IAM редко проходит гладко. Заранее подготовьтесь к типичным вызовам:
● Сопротивление сотрудников: Новые процедуры (MFA, запросы через портал) покажутся неудобными. Важна разъяснительная работа и поддержка.
● «Серые» процессы: Обнаружатся доступы, выданные в обход всех правил по устной договоренности. Их нужно легализовать или закрыть.
● Интеграции: Подключение некоторых унаследованных систем может оказаться неоправданно дорогим. Иногда их проще исключить из автоматического процесса.

Успех проекта — не в идеальной технической реализации, а в том, чтобы контролируемые доступы стали новой нормой жизни компании. Начните с малого, покажите ценность на пилоте и масштабируйтесь.

У вас все настроено правильно, если в итоге компания может точно сказать:
— кто имеет доступ к каждой системе;
— какие права есть у конкретного пользователя и почему;
— кто согласовал этот доступ;
— где хранятся учетные данные;
— сколько времени занимает отзыв всех доступов при увольнении.

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