Процессы приёма, перевода и увольнения сотрудников для более упорядоченного контроля доступа

Почему после изменений в HR возникают пробелы в доступе

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

Большинство команд занимаются видимыми вещами в первую очередь. Кто‑то вспомнит про ноутбук, бейдж, зарплату и рабочее место. Менее заметные доступы остаются открытыми: доски проектов, платёжные панели, группы в Git, консоли облака, менеджеры паролей или старые рабочие пространства в Slack.

Проблема усиливается, когда один человек взаимодействует со множеством систем. Новому сотруднику может понадобиться почта, место в CRM, инструмент поддержки, репозиторий, тестовый сервер и облачный аккаунт. Если за каждое приложение отвечает кто‑то свой, никто не видит полной картины. Один админ удалит два аккаунта, другой отложит задачу, а одно приложение забудут на месяцы.

Внутренние перемещения часто сложнее, чем увольнения. При переводе менеджеры думают о том, что человеку нужно в новой роли, и меньше — о том, что ему нужно отобрать. Репозитории хорошо это показывают: инженер переходит в другую команду, сохраняет права на запись в старых репозиториях и по‑прежнему видит настройки деплоя или секреты, которые уже не соответствуют его задачам.

Общие админ‑аккаунты дают ещё больший «слепой» участок. Если пятеро знают один и тот же root‑пароль, удаление одного именованного пользователя ничего не меняет. Учётка по‑прежнему работает, и никто не скажет, кто использовал её последним.

Эти пробелы обычно возникают из обычных привычек. HR обновляет статус первым, а владельцы приложений действуют по почте или памяти позже. Менеджеры лучше следят за железом, чем за SaaS. При переводах добавляют новые права, но редко убирают старые. Общие учётные данные скрывают, кто реально ещё имеет доступ.

Рабочие процессы joiner/mover/leaver решают проблему только тогда, когда событие в HR связано с каждым последующим изменением доступа. Если эта связь слаба, старые права аккуратно накапливаются, пока аудит, инцидент или сюрприз на счёте не выявят их.

Сделайте единый реестр доступов

Большинство команд думают только об очевидных учётках. Почта и SSO важны, но это только входная дверь. Старые доступы часто живут через боковые двери: VPN‑профили, локальные входы на устройства или сессии в браузере, которые никто не отозвал.

Поместите все системы, к которым может получить доступ человек, в один простой реестр. Если HR, IT и инженеры ведут отдельные списки, что‑то обязательно пропадёт при переводе или уходе.

Реестр должен покрывать системы идентификации — почту, SSO, VPN, менеджеры паролей и доменные админ‑аккаунты. Включите бизнес‑инструменты: платёжные системы, CRM, ПО поддержки, документы, чат, календари и шаринг файлов. Инструменты инженеров тоже туда относятся: хостинг Git, регистры пакетов, CI‑пайплайны, инструменты деплоя, консоли облака, мониторинг и трекинг ошибок. Не забывайте про общие ресурсы: папки команд, дашборды, общие почтовые ящики, доски проектов и внутренние вики.

Последний раздел — тот, который чаще всего упускают: нехуманитарные доступы. Сюда входят сервисные учётки, API‑токены, SSH‑ключи, менеджеры секретов, боты и аккаунты автоматизации, которые создал один человек и до сих пор контролирует. Разработчик может уйти, а его токен всё ещё публикует пакеты, SSH‑ключ даёт доступ к серверу, или его облачный пользователь владеет сервисной учёткой. Это типично для растущих команд.

Для каждой системы ответьте на два простых вопроса: как человек получает доступ и как быстро этот доступ можно удалить? Если вы не можете ответить на оба, система не под контролем.

Именно здесь рабочие процессы joiner/mover/leaver становятся практичными. Событие «mover» — это не просто новая должность. Это может означать, что у менеджера отбирают доступ к зарплате, у подрядчика — права на продакшен, или закрывают права на запись в репозиторий, когда человек переходит в поддержку.

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

Назначьте владельцев и сроки

Работа с доступами распадается, когда каждый думает, что «кто‑то другой» этим займётся. HR обновляет запись сотрудника, менеджер отправляет сообщение в чате, IT меняет пару инструментов — а старый доступ к репозиторию остаётся.

Каждый запрос на joiner, mover или leaver должен начинаться с одного триггера. Это может быть система HR, форма тикета или общий workflow‑инструмент. Важно, чтобы событие начиналось в одном месте, а не в разбросанных письмах и сообщениях в чате.

Для каждой системы нужен именованный владелец. Не просто «IT» или «engineering», а конкретный человек для Google Workspace, конкретный для AWS, для GitHub или GitLab, для Slack и так далее. Ему не нужно постоянно нажимать все кнопки, но он должен убедиться, что изменение произошло и запись корректна.

Растущей команде полезно зафиксировать три решения: кто утверждает стандартный доступ для нового сотрудника, кто утверждает исключения вроде админ‑прав, и кто выдаёт и отзывает временный доступ. Если никто не отвечает за исключения, они превращаются в постоянные права. Подрядчику дали админ‑доступ «на неделю», а он остаётся полгода.

Сроки должны быть такими же чёткими. Планируемый новый сотрудник — это не то же самое, что экстренный уход. Доступ нового сотрудника должен быть готов до начала работы. Переводы должны обновляться в тот же день, когда меняется роль. Уход — закрываться в оговоренное время или сразу в срочных случаях. Временный доступ должен иметь явную дату окончания, а не расплывчатое напоминание.

Когда правила ясны, процесс перестаёт выглядеть как расплывчивая политика. Менеджеры знают, к кому обращаться. HR знает, как запустить изменение. Владельцы систем знают свои сроки.

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

Стройте рабочий процесс шаг за шагом

Хорошие рабочие процессы joiner/mover/leaver начинаются с чёткого триггера. HR создаёт запрос, указывает менеджера и даты: дата начала, дата вступления в новую роль или дата увольнения. Если эти данные приходят поздно, изменения доступа тоже задерживаются.

Держите отдельные чек‑листы для joiner, mover и leaver. Новому сотруднику нужны аккаунты, базовые группы и инструменты на первый день. При переводе сначала нужно убрать старое — именно оно обычно остаётся. При уходе нужен таймированный выключатель, привязанный к точной дате ухода.

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

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

Простой поток выглядит так:

1. HR создаёт событие с датами и данными менеджера.
2. Менеджер подтверждает роль и согласованные исключения.
3. IT или владелец системы применяют шаблон роли и у movers сначала удаляют старые права.
4. В день увольнения владелец закрывает аккаунты, завершает сессии и отзывает токены.
5. Команда отмечает все задачи выполненными в одной общей записи.

Последний шаг важнее, чем кажется. Если статус выполнения разбросан по почте, чату и стикерам, у никого не будет полной картины. Размещайте всё в одном тикете, одной админ‑панели или одном трекере, где HR, IT и менеджер видят статус.

Для уходящих не ограничивайтесь отключением основного входа. Закрывайте SaaS‑учётки, отзывайте личные токены, удаляйте SSH‑ключи, завершайте активные сессии и проверяйте членства в репозиториях. Один пропущенный токен может держать дверь открытой долго после ухода сотрудника.

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

Проверяйте облако, SaaS и репозитории вместе

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

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

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

Риск иногда заключается вовсе не в пользовательских аккаунтах. Это дополнительные учётные данные, которые люди создают в работе: персональные токены для скриптов, SSH‑ключи, ключи деплоя в репозиториях, CI‑раннеры, боты и общие пароли, оставленные в старых документах или чатах.

Эти элементы остаются, потому что не всегда привязаны к имени человека. Закрытая лицензия SaaS может выглядеть чистой, а старый токен при этом всё ещё вытягивает код или бот‑аккаунт продолжает деплоить в прод.

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

Один вопрос помогает многое: «До чего этот человек или этот учётный элемент ещё может добраться в облаке, SaaS и коде?» Это работает лучше, чем проверять инструменты по‑отдельности.

Простой пример из растущей команды

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

Одна сотрудница начала в поддержке и помогала с возвратами, поэтому ей дали доступ к биллингу и финансовым панелям. Через несколько месяцев она стала продуктовым лидом. Менеджер обновил её должность в HR, и все посчитали перевод завершённым.

Это не было завершено. У неё остался доступ к финансовым данным, потому что никто не отвечал за шаг по его удалению.

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

Облачные права тоже проскочили. HR зафиксировал изменения, но никто не пересмотрел IAM‑роли, общие креды или права на уровне проекта. Новый продуктовый лидер по‑прежнему видел финансовые данные, а подрядчик продолжал просматривать код, пока кто‑то не заметил.

Так в обычных компаниях происходит drift доступа. Никто не совершает одну большую ошибку. Люди просто предполагают, что следующий человек это убрал.

Короткая рутина закрывает пробел. HR фиксирует изменение роли и дату окончания контракта в одном месте. Менеджер подтверждает, какие доступы ещё нужны. Владелец системы в тот же день удаляет старые права в SaaS, облаке и репозиториях. Затем кто‑то проверяет изменения и отмечает задачу выполненной.

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

Ошибки, которые сохраняют старые права

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

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

Ещё одна ошибка — сначала добавить новые права, а старые не снять и не вернуться к этому. Это часто происходит при внутренних переводах: человек начинает работать сразу, и это кажется эффективным, но права складываются.

Команды также слишком концентрируются на SSO и игнорируют всё вне него. Старые права остаются в маленьких SaaS‑инструментах со отдельными входами, локальных админ‑учётках на ноутбуках или серверах, общих репозиториях вне основной системы идентичности, экстренных админ‑паролях, известных бывшим сотрудникам, и учётках подрядчиков или стажёров, которые после проекта никто не проверяет.

Экстренные пароли требуют отдельного внимания. Если несколько человек знали «break‑glass» пароль и его не меняли месяцами, вы не знаете, кто всё ещё может войти. Та же проблема с общими SSH‑ключами, старыми VPN‑аккаунтами и сервисными учётками, созданными в спешке.

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

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

Быстрые проверки, которые ловят остатки

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

Еженедельная проверка работает лучше, чем масштабная чистка раз в несколько месяцев. Начните с реестра HR и каталога SSO. Сравните, кто активен, кто сменил команду и кто ушёл. Если кто‑то неактивен в HR, но всё ещё активен в SSO, считайте это промахом и исправьте в тот же день.

Дальше проверьте отключённые почтовые аккаунты на наличие живого доступа в SaaS. Такое встречается чаще, чем думают команды: почтовый ящик закрыт, а у человека остаётся валидная сессия, API‑токен или мобильный доступ.

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

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

Также полезно прогнать один недавний кейс оффбординга от начала до конца. Возьмите реального человека, который ушёл, и проверьте: обновился ли статус в HR, заблокирован ли SSO, отозваны ли сессии в SaaS, удалён ли доступ к репозиториям и при необходимости сменили ли общие креды.

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

Если одна проверка регулярно проваливается, автоматизируйте именно её. Сопоставление HR и SSO по неделям часто даёт самый быстрый эффект.

Что делать дальше

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

Опишите один ясный путь для каждого изменения в HR: приём, перевод и уход. Укажите, кто запрашивает доступ, кто его утверждает, кто вносит изменения и кто подтверждает, что всё случилось. Затем создайте несколько простых шаблонов ролей. Агент поддержки может нуждаться в двух SaaS‑инструментах и не иметь доступа к репозиториям. Бэкенд‑инженер может требовать роль в облаке, двух репозиториев и права только для чтения логов. Шаблоны уменьшают одноразовые запросы и ускоряют ревью доступов.

Нужен ещё один человек, который будет владеть исключениями, напоминаниями и контрольными шагами. Когда уборка доступа принадлежит «всем», старые права остаются открытыми.

Если привлекаете внешних специалистов, держите задачу практичной. Oleg Sotnikov at oleg.is работает со стартапами и малыми компаниями как fractional CTO и советник, помогая упорядочить доступы в облаке, SaaS и репозиториях без превращения этого в тяжёлый проект. Такой внешний обзор часто достаточно, чтобы увидеть, где права остаются, и внедрить простой процесс, который команда действительно будет использовать.