Joiner-Mover-Leaver: автоматизация жизненного цикла учётной записи

Когда ИТ-инфраструктура компании вырастает за пределы сотни сотрудников, ручное управление учетными записями превращается в мину замедленного действия. В ИБ-отдел регулярно прилетают хаотичные заявки в Service Desk: «Создать почту новому маркетологу», «Перевести инженера в отдел архитектуры, дать доступ к Git», «Заблокировать уволенного менеджера».

В этой суете системные администраторы неизбежно совершают критические ошибки. По статистике, до 30% учетных записей в средних и крупных компаниях принадлежат сотрудникам, которые давно уволились («осиротевшие» учетки, Orphaned Accounts). Хакеры обожают такие заброшенные профили: на них никто не меняет пароли, а их компрометация позволяет месяцами скрытно сидеть в корпоративной сети.

Решением этой проблемы является внедрение строгой концепции JML (Joiner-Mover-Leaver) — сквозной автоматизации жизненного цикла учетных записей. Давайте разберем архитектуру этого процесса и поймем, как связать кадровый учет с реальной безопасностью ИТ-систем.

Три стадии JML: правила автоматизации

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

1. Joiner (Прием на работу)
Безопасность начинается в первый рабочий день сотрудника (или за пару дней до него).
Как делать нельзя: Администратор создает учетную запись в Active Directory вручную, копируя права «похожего» сотрудника. В итоге новичок сразу получает избыточный доступ, который ему не положен по должности.
Как нужно делать: Единственным источником правды (Single Source of Truth) является кадровая база данных (например, 1С:ЗУП). Как только кадровик подписывает приказ о приеме на работу, HRM-система отправляет событие в платформу автоматизации (IDM/IGA). Система сама создает аккаунт в AD по корпоративному шаблону, генерирует уникальный почтовый ящик и выдает базовый ролевой профиль (Role-Based Access Control — RBAC), жестко привязанный к его должности и департаменту.

2. Mover (Кадровое перемещение)
Сотрудник растет внутри компании — например, переходит из отдела продаж в департамент аналитики.
Главный риск («Накопление прав»): При переходе сотруднику выдают новые права (к базам данных аналитиков), но забывают забрать старые (к CRM отдела продаж). Через 5 лет работы такой «старожил» превращается в суперпользователя с доступом ко всей интеллектуальной собственности компании.
Как нужно делать: Процесс автоматизации Mover устроен по принципу депривилегизации. Система считывает изменение должности в HRM, автоматически снимает все старые локальные права и группы доступа, а затем накладывает новый ролевой профиль. Если сотруднику для выполнения задач все же нужны специфичные старые файлы, он запрашивает их заново через процедуру временного одобрения.

3. Leaver (Увольнение)
Самая критическая точка с точки зрения рисков ИБ. Уволенный или обиженный сотрудник не должен иметь ни секунды доступа к ресурсам компании после официального расторжения договора.
Как делать нельзя: Заявка на блокировку теряется в ИТ-отделе, и бывший менеджер еще две недели из дома заходит в корпоративное облако, скачивая базу клиентов для перехода к конкурентам.
Как нужно делать: Блокировка должна происходить автоматически в день увольнения. Робот деактивирует учетную запись в Active Directory / FreeIPA, закрывает активные сессии на VPN-шлюзе, аннулирует токены OAuth2, блокирует пропуск на СКУД и отзывает лицензии от корпоративного софта.

Архитектура JML: связующее звено IDM/IGA

Чтобы автоматизировать этот конвейер, компания разворачивает системы класса IDM (Identity Management) или IGA (Identity Governance and Administration). Они выступают в роли оркестратора, связывая кадровые системы с техническим ландшафтом ЦОД.

[ Кадровая система (1С:ЗУП) ] ──(Событие: Прием/Увольнение)──> [ Платформа IDM / IGA ]
│
┌───────────────────────────────┬────────────────────────────────┴──────────────────────────────┐
▼ ▼ ▼
[ Каталог AD / FreeIPA ] [ Корпоративная почта ] [ Права в виртуальной среде ]

Внедрение IDM/IGA позволяет решить проблему лоскутной ИТ-инфраструктуры. Например, если ваши бизнес-приложения и базы данных развернуты в локальном ЦОД на корпоративных платформах виртуализации, система IDM сама создаст или заблокирует учетные записи инженеров на уровне управления гипервизором. Платформа виртуализации мгновенно получит команду на отзыв прав администратора, как только в кадровой системе появится отметка об увольнении сотрудника, исключая риск несанкционированного доступа к виртуальным серверам.

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

Давайте сопоставим ручной подход с автоматизированным JML-процессом по ключевым метрикам эффективности:

С чего начать внедрение JML на практике

• Создайте ролевую матрицу: Прежде чем покупать софт автоматизации, наведите порядок на бумаге. Соберитесь с руководителями отделов и четко пропишите: какие папки, чаты и базы данных нужны каждой должности по умолчанию.
• Наведите порядок в HRM: Кадровая база данных должна содержать актуальную информацию. Если в кадрах сотрудники годами числятся «ведущими специалистами общего профиля», автоматизировать доступы робот не сможет. Каждая должность должна иметь уникальный код.
• Внедрите регулярную аттестацию прав (Access Certification): Даже при автоматизации раз в полгода запускайте в IDM процесс ревизии. Система должна автоматически отправлять руководителям департаментов списки их сотрудников с вопросом: «Иванову всё еще нужен доступ к этой финансовой папке?». Если руководитель не нажимает кнопку подтверждения в течение недели, доступ отзывается автоматически.

Автоматизация жизненного цикла JML — это базовая гигиена кибербезопасности. Перенос ответственности за создание и блокировку цифровых личностей с плеч уставших системных администраторов на строгие алгоритмы автоматизации позволяет закрыть до 80% векторов потенциальных атак, связанных с человеческим фактором и компрометацией забытых учетных данных.