Joiner-Mover-Leaver в доступах: автоматизация прав сотрудников

В чем проблема с доступами при найме, переводе и увольнении

Во многих компаниях доступы до сих пор выдаются вручную. HR пишет письмо в ИТ, руководитель добавляет человека в чаты, администратор «по памяти» ставит галочки в разных системах. Часть просьб теряется в переписках, а часть делается «на всякий случай», чтобы новичок точно мог работать с первого дня.

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

О проблеме обычно говорят простые симптомы: появляются общие аккаунты «на отдел», у людей копятся лишние роли «потому что когда-то было нужно», а у подрядчиков доступы живут месяцами после завершения работ. И однажды выясняется, что никто не может быстро ответить на вопрос: «У кого есть доступ к этой системе и почему?».

Понятный процесс Joiner-Mover-Leaver (JML) меняет ситуацию. Он ускоряет онбординг, делает переводы предсказуемыми и снижает риски при увольнении. Главное - решения перестают зависеть от переписок и человеческой памяти.

Joiner, Mover, Leaver простыми словами

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

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

Mover (перевод) - это не «добавить еще один доступ», а пересмотреть старые. Смена отдела, проекта или должности означает, что часть прежних прав больше не нужна, а новые должны появиться быстро. Типичная ошибка - «копить» доступы после каждого изменения роли, пока у сотрудника не окажутся права «почти на все».

Leaver (увольнение) - самый чувствительный этап. Здесь удобно разделить действия на три слоя:

• Сразу: закрыть вход (учетка, почта, VPN, удаленный доступ, токены и ключи).
• В ближайшие часы: заблокировать доступ к критичным системам (финансы, HR, CRM, исходный код).
• После передачи дел: переоформить владельца общих ящиков, файлов, задач и учеток во внешних сервисах.

Если HR, ИТ и служба безопасности говорят на одном языке (что считается событием, кто инициирует, кто согласует, что именно меняется), процесс становится повторяемым и его проще автоматизировать.

Какие данные и системы участвуют в JML-процессе

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

Источник события обычно в HR: HR-система или кадровый приказ (прием, перевод, увольнение). Важен не «письмо на почту», а формальный сигнал с типом изменения, датой и понятной идентификацией сотрудника.

Каталог сотрудников (единая карточка) должен содержать стабильный идентификатор и актуальные атрибуты: статус, подразделение, должность, руководитель, локация, тип занятости. Без единого ID легко получить дубли учеток или ситуацию, когда права отзываются «не у того Иванова».

Целевые системы, где реально живут доступы, обычно включают корпоративную почту и календарь, VPN и удаленный доступ, файловые ресурсы, бизнес-системы (ERP/CRM, бухгалтерия, СЭД), сервис-деск.

Логи и аудит обязательны даже при полной автоматизации. В любой момент должно быть видно: кто инициировал, кто согласовал и когда изменения применили. Минимум, который стоит фиксировать: событие и источник, какие права выдали/сняли и по какому правилу, кто согласовал, кто выполнил (система/админ), а также ручные исключения и причину.

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

Роли и ответственность: кто за что отвечает

JML чаще ломается не из-за технологий, а из-за размытых ролей. Когда непонятно, кто фиксирует событие, кто выбирает доступы, а кто следит за рисками, появляются лишние права, задержки и спорные «исключения».

HR: источник события и точных данных

HR запускает процесс (найм, перевод, увольнение) и передает минимум атрибутов, без которых автоматизация будет «гадать». Обычно это должность и подразделение, дата начала (или дата изменения/увольнения), тип занятости (штат/подряд), локация или площадка (если влияет на доступ).

Руководитель: подтверждает роль по задачам

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

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

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

Модель доступа: роли, группы и правила согласования

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

Начните со стандартных ролей, понятных и HR, и ИТ (бухгалтер, кадровик, менеджер продаж, инженер, руководитель отдела, оператор колл-центра). Для каждой роли закрепите конкретные группы (в AD/IAM) и права в ключевых системах. Важно выдавать доступ через группы, а не «по пользователю», иначе при переводе и увольнении останутся хвосты.

Права удобно разделить на четыре уровня: базовые (почта, чаты, Wi-Fi, общие папки), расширенные (профильные системы отдела), привилегированные (админ-роли, финансовые отчеты, персональные данные, настройки инфраструктуры) и временные (на проект или замещение с датой окончания).

Базовые доступы часто можно выдавать автоматически по роли и подразделению. Расширенные обычно требуют подтверждения руководителя, а привилегированные - отдельного согласования владельца системы или ИБ.

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

Пошагово: как автоматизировать выдачу прав при найме

Автоматизация этапа Joiner строится на простом принципе: доступы выдаются не по письмам и просьбам, а по событию из HR и понятным правилам.

1) Запускайте процесс от HR-события

Как только HR оформил прием и указал дату выхода, должна создаваться задача на доступы. У задачи нужен владелец (обычно ИТ или ИБ) и срок, например «до 10:00 первого рабочего дня».

2) Проверьте данные и назначьте роль

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

3) Базовые доступы - автоматически, исключения - по согласованию

Автоматизация должна закрывать большую часть потребностей: учетная запись, почта, стандартные группы, базовые корпоративные системы. Все нестандартное (доступ к финансовым данным, админ-права, критичные серверы) оставьте через короткое согласование с руководителем и ИБ.

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

4) Уведомьте сотрудника и руководителя

Сотруднику нужна простая инструкция: что уже работает, где вход, куда писать при проблемах. Руководителю - подтверждение, что человек «готов к работе».

5) Подтвердите факт доступа и зафиксируйте аудит

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

Пошагово: как управлять доступами при переводе (Mover)

Перевод - коварный этап: права уже есть, и часть из них незаметно становится лишней.

1) Зафиксируйте, что именно поменялось

Нужен четкий триггер: смена отдела, должности, проекта или уровня доступа (например, переход в команду с финансовыми данными). Лучше всего, когда HR-событие содержит новую роль, подразделение, руководителя и дату вступления.

2) Сначала снимите лишнее, потом добавляйте новое

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

После изменений проверьте «серые зоны»: общие папки, рассылки, командные чаты и права на календари. Именно там чаще всего остаются самые широкие доступы.

3) Учитывайте сроки: сразу или по дате перевода

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

4) Ведите историю и «кто подтвердил»

Сохраните след: что было, что стало, кто согласовал и когда применили. Это помогает и в рабочих спорах, и на проверках.

Пошагово: как безопасно отзывать доступы при увольнении (Leaver)

Цель этапа Leaver простая: сотрудник больше не должен иметь технической возможности войти в системы, а бизнес не должен потерять переписку, документы и доступ к нужным данным.

1) Что отключать сразу (в день увольнения)

Сначала закрывайте вход, потом разбирайтесь с передачей дел. Обычно сразу нужно: заблокировать учетку в домене/SSO и локальные учетки в ключевых системах, отключить VPN и другой удаленный доступ, отозвать активные сессии и токены в почте и мессенджерах, закрыть доступ к админ-панелям, облакам, репозиториям кода, витринам данных и BI, снять любые привилегированные и временные права.

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

2) Что закрывать после (когда дела переданы)

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

3) Устройства и физические носители

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

4) Подрядчики и временные сотрудники

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

5) Контроль и отчетность для ИБ

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

Частые ошибки и ловушки, которые ломают JML

Крупные провалы обычно связаны не с «плохим инструментом», а с дисциплиной: где-то выдали права быстрее, чем оформили, где-то забыли забрать, а где-то учетная запись расползлась на две-три.

Одна из типичных проблем - выдача прав «по просьбе в чате». Сначала кажется, что это быстрее, но потом невозможно ответить на базовые вопросы: кто согласовал, на какой срок и по какой причине.

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

Еще одна ловушка - отсутствие единого идентификатора сотрудника. Разные форматы ФИО в HR, почте и домене приводят к дублям учеток. Потом увольняют «Иванова И.И.», а активной остается «ivanov.i» с доступом к критичным системам.

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

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

Короткий чек-лист готовности к автоматизации JML

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

Сначала проверьте основу: есть ли единый перечень систем, где существуют учетки, и назначены ли владельцы доступов. Владелец - не всегда ИТ; часто это руководитель бизнеса или администратор конкретной системы, который понимает, какие права реально нужны.

Дальше - шаблоны ролей. Для ключевых должностей должны быть понятные наборы прав: что выдаем в первый день, что добавляем позже, что запрещено по умолчанию.

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

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

Пример из практики: найм, перевод и увольнение одного сотрудника

Анна принята в региональный филиал на роль специалиста по закупкам. Через 3 месяца ее переводят в головной офис, а еще через полгода она увольняется.

В день выхода (Joiner) система берет данные из HR (ФИО, роль, подразделение, локация, руководитель, дата выхода) и автоматически выдает базовый набор: корпоративную учетную запись и вход на рабочую станцию, почту и календарь, доступ в корпоративный мессенджер, базовые папки и, при необходимости, заявку на лицензию, привязанную к роли.

Часть прав логично включать только позже (например, после испытательного срока): доступ к финансовым реестрам, согласование договоров, расширенные отчеты в учетной системе. Так меньше риска выдать лишнее, если сотрудник не остается.

Через 3 месяца Анну переводят (Mover). Триггер - изменение подразделения и локации в HR. Процесс делает две вещи: снимает все, что относится к филиалу, и добавляет то, что нужно в головном офисе. Меняются группы доступа, папки и рабочие пространства, права в профильных системах и лицензии. Если требуется сохранить доступ к проектной папке филиала на 2 недели, это оформляется как временное исключение с датой окончания.

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

Чтобы понимать, что процесс реально работает, удобно измерять: время онбординга (от записи в HR до готовности доступов), число ручных исключений на сотрудника, долю доступов вне роли, процент просроченных отключений и время «дочистки» после переводов (старые группы, лишние лицензии).

Следующие шаги: как запустить JML без остановки работы

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

Начните со списка систем, где есть доступы (почта, AD, 1С, CRM, файловые хранилища, отраслевые сервисы), и выделите 10-20 самых частых ролей. Затем зафиксируйте один входной канал для запросов (например, сервис-деск) и понятные статусы, опишите правила согласования, задайте сроки (готовность к первому дню и скорость отключения при увольнении), настройте минимальную автоматизацию (создание учеток, добавление в группы, снятие типовых прав) и проведите пилот в одном подразделении.

Если нужна помощь на стороне, GSE.kz (gse.kz) как системный интегратор может подключиться к описанию ролей и правил, увязке HR и ИТ и организации поддержки. Это особенно полезно, когда доступов много и критична стабильная работа процесса 24/7.