Забытый сотрудник, рабочая учётка. Почему плохой оффбординг — это главная угроза безопасности.

Представьте: сотрудник уволился три месяца назад, а его токены до сих пор работают, почта пересылается неизвестно кому, а в каком-то забытом рекламном кабинете он всё ещё админ. Знакомо? Добро пожаловать в мир плохого оффбординга — места, где риски множатся, а головная боль становится хронической.

Оффбординг — это не просто "выпроводить человека и забыть". Это управляемое отключение всех нитей, которые связывают сотрудника с вашей IT-экосистемой. В 2025 году 48% HR-отделов планируют инвестировать в инструменты автоматизации оффбординга, потому что стоимость ошибок растёт пропорционально сложности инфраструктуры.

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

Почему все говорят об онбординге, а про оффбординг забывают

Есть такая штука — жизненный цикл сотрудника, который описывают моделью JML: Joiner (пришёл), Mover (поменял роль), Leaver (ушёл). На русском красивого термина нет, поэтому используем английские обозначения — так понятнее и короче.

Про Joiner все помнят: красивые welcome-киты, автоматические письма, торжественное вручение ноутбука. Про Leaver вспоминают в последний момент, когда HR звонит в панике: "А вы там все доступы отключили? А токены? А что с почтой делать?"

Между тем, 76% HR-отделов готовы взять обратно бывших сотрудников, а 40% уволившихся рассматривают возможность вернуться. Угадайте, что влияет на это решение? Правильно — то, как их проводили.

Когда включать оффбординг (спойлер: раньше, чем думаете)

Триггером служит любое изменение статуса, при котором человеку больше не нужны прежние права. Это не только увольнение, но и:

• Длительный отпуск или больничный (иногда стоит ограничить доступы)
• Смена роли с частичным отзывом прав
• Завершение проекта или субподряда
• Временная заморозка контракта
• Даже переход на другую команду внутри компании

Самые неприятные инциденты случаются не при полном уходе, а при забытом частичном оффбординге. Человек перешёл из разработки в маркетинг, а доступ к продакшену остался. Или подрядчик закончил один проект, но токены для другого никто не отозвал.

Золотое правило: один тикет — одна операция. Создали тикет "Leaver" или "Role change" в системе заявок — зафиксировали дату, время, ответственных и пошли по чек-листу.

Кто за что отвечает (или как не превратить процесс в перекладывание ответственности)

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

• HR или менеджер — инициируют процесс, ведут коммуникацию
• ИТ — отключают системы, собирают оборудование
• ИБ — контролируют безопасность, проверяют логи
• Финансы — закрывают расчёты, отменяют подписки
• Юристы — следят за соблюдением NDA и договоров
• Менеджер подразделения — принимает дела и активы

Без единого реестра оффбординга вы будете вечно отвечать на вопросы аудиторов: "А где подтверждение, что доступы отозваны?" Поэтому заведите простую таблицу со статусами и ссылками на доказательства.

Анатомия правильного тикета "Leaver"

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

• Личные данные: ФИО, ID сотрудника, подразделение, менеджер, контакт HR
• Временные рамки: дата ухода, часовой пояс, желаемое окно работ
• Технический блок: список систем и их владельцы (SSO, почта, VPN, Git, облака, CRM и т.д.)
• Клиентские среды: есть ли доступ, кто контакт со стороны клиента
• Коммуникации: нужен ли автоответчик, куда перенаправлять почту, на какой срок
• Активы: репозитории, проекты, ключи, лицензии, железо
• Формальности: напоминание об NDA, акты, расчёты

Хороший тикет читается как техзадание: понятно, что делать, кому и к какому сроку.

Инвентаризация доступов: увидеть невидимое

Здесь начинается самое интересное. Большая часть проблем рождается не в день оффбординга, а задолго до него, когда доступы выдавались "по дружбе", а учёт вёлся в нескольких Excel-файлах.

Идеальный мир: все доступы через единый провайдер идентичности (IdP), синхронизация по SCIM, управляемые группы. Реальный мир: половина систем интегрирована, четверть на самописных костылях, а остальное вообще "исторически сложилось".

Особая боль — личные аккаунты в рабочих системах. "У меня доступ к GitHub с личной почты ещё с прошлой работы" — знакомая мелодия? В оффбординге фильтр по корпоративному домену не поможет. Придётся проверять по всем адресам, которые привязаны к человеку.

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

Последовательность отключений: что первое, что потом

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

Первая линия обороны

• SSO и провайдеры идентичности — отключаем в Okta, Azure AD или чём там у вас
• VPN и удалённый доступ — рубим возможность подключиться к внутренним ресурсам
• Многофакторная аутентификация — отзываем токены, удаляем устройства
• Корпоративная почта — НЕ удаляем сразу, включаем автоответчик и переадресацию

Критичные системы

• Git и CI/CD — убираем из команд, блокируем push'ы, переносим владение репозиториями
• Облачные провайдеры — AWS, Azure, GCP, отзыв ключей доступа и ролей
• Базы данных — особенно продакшен, там ошибки дорого стоят
• Мониторинг и алерты — а то будете получать уведомления на несуществующий email

Токены и секреты

• API-ключи и персональные токены доступа
• SSH-ключи во всех системах
• OAuth-приложения и интеграции
• Пароли приложений и сервисные аккаунты
• Общие секреты, к которым был доступ — пересоздаём

Периферия (но не менее важная)

• DNS и домены — регистраторы любят давать админские права всем подряд
• CDN и WAF — Cloudflare, Akamai и прочие
• Аналитика — Google Analytics, Яндекс.Метрика, где человек был админом
• Реклама — кабинеты в соцсетях и поисковиках
• CRM и биллинг — доступ к клиентским данным
• Менеджеры паролей — 1Password, Bitwarden, LastPass

Внешние SaaS

• Рабочие инструменты: Notion, Figma, Miro, Trello
• Коммуникации: Slack, Discord, Telegram-боты
• Статусы: Statuspage, внешние мониторинги
• Платёжные подписки — проверьте, что списания остановились

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

Устройства и данные: железо тоже важно

Техника — это не только MacBook Pro на столе. Это телефоны, аппаратные токены, смарт-карты, сетевое оборудование, даже ключи от серверной. В идеальном мире всё это учтено в MDM/ITAM-системе.

Обязательный минимум:

• Блокировка и удалённая очистка через MDM
• Возврат физических токенов 2FA
• Акт приёма-передачи с подписями и печатями
• Перенос владения над документами и проектами
• Закрытие доступов к общим папкам и хранилищам

Если использовали BYOD (принеси своё устройство), убедитесь, что корпоративный контейнер удалён чисто, а личные данные остались нетронутыми. Никому не нужны судебные разбирательства из-за случайно стёртых семейных фото.

Почта и коммуникации: как не запутать партнёров

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

Правильный алгоритм:

1. Настроить автоответчик с контактами замещающего лица
2. Включить переадресацию на 1-2 недели (не дольше!)
3. Отключить личные правила пересылки и внешние интеграции
4. Очистить подписи и обновить корпоративный справочник
5. Перевести календарные встречи новому владельцу

Шаблон автоответчика, который работает:

"Здравствуйте! Контакты по вопросам [тематика] изменились. По рабочим вопросам пишите [ФИО, должность, email]. По срочным делам — [телефон]. Это автоматическое сообщение."

Короткий, информативный, без лишних эмоций.

Юридическая сторона: бумажки тоже нужны

Техническая часть идёт рука об руку с юридической. Тут всё просто:

• Напоминаем об NDA и авторских правах
• Закрываем финансовые расчёты
• Оформляем акт возврата/уничтожения
• Ставим отметку в реестре оффбординга
• Для подрядчиков — подтверждаем передачу результатов

Полезная практика — финальный 15-минутный созвон с руководителем: все ли задачи переданы, кто взял ответственность, где лежат критичные файлы. Эти четверть часа могут предотвратить недели поисков забытого скрипта или незадокументированной интеграции.

Проверяем результат: аудит перед закрытием

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

Чек-лист финальной проверки:

• Выгружаем логи активности за последние 30 дней из SIEM, IdP, DLP
• Проверяем правила переадресации, алиасы, подписки на рассылки
• Ищем OAuth-приложения и вебхуки, созданные от имени пользователя
• Проверяем облачные провайдеры на "осиротевшие" ключи и роли
• Пересоздаём общие секреты, к которым был доступ
• Закрываем тикет с полным пакетом доказательств

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

Топ-7 ошибок, которые делают все

Учиться на чужих ошибках дешевле, чем на своих.

1. Забыли про ботов и сервисные токены — интеграции продолжают работать "в темноте"
2. Проигнорировали периферию — рекламные кабинеты и регистраторы доменов часто без SSO
3. Не закрыли внешние SaaS — доступы живут, деньги списываются
4. Не сменили владельцев проектов — релизы встают, команда не может работать
5. Учли только корпоративную почту — а личные адреса в рабочих системах пропустили
6. Удалили почту сразу — партнёры потеряли связь и начали звонить всем подряд
7. Не проверили логи — а там интересная активность уже после "ухода"

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

Timeline: что делать и когда

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

Не пытайтесь всё сделать за один день. Растянутый на неделю процесс снижает стресс и вероятность ошибок.

Автоматизация: роботы vs человеческий фактор

48% HR-департаментов планируют инвестировать в автоматизацию оффбординга к 2025 году — и это правильно. Чем больше автоматизировано, тем стабильнее процесс.

С чего начать:

• Интеграция HR-системы с IdP по событиям (создание, изменение роли, увольнение)
• SCIM-провижининг там, где поддерживается
• Управляемые группы и роли через Infrastructure as Code
• Автоматическая ротация секретов при блокировке в IdP
• Шаблоны тикетов и динамические чек-листы

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

Подрядчики и клиентские среды: больше сторон — больше ответственности

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

Если подрядчик работал в окружении клиента:

• Уведомляем ответственного за ИБ у клиента
• Фиксируем отзыв доступов в их системе
• Прикладываем скриншоты к реестру оффбординга
• Получаем подтверждение от клиента

Для субподрядчиков добавляется контроль цепочки: кто и кому делегировал права, на каких основаниях, где документы. Чем прозрачнее цепочка, тем проще её закрыть.

Метрики: как понять, что процесс работает

Что не измеряется — то не управляется. Несколько практичных показателей:

• Time to disable — процент уходов, закрытых в день X по критичным системам
• Average offboarding time — среднее время полного оффбординга
• Automation rate — доля автоматических отключений
• Orphaned accounts — количество "висячих" доступов на T+7 и T+30
• Compliance score — процент оффбордингов с полным пакетом документов

Эти цифры быстро показывают прогресс и узкие места. Если время полного оффбординга больше недели — есть куда оптимизировать.

Инструменты и сервисы для автоматизации

Несколько направлений для изучения (это не реклама, а ориентиры):

• Провайдеры идентичности: Microsoft Entra ID, Google Workspace, Okta
• Управление доступом: StrongDM, CyberArk
• Git и DevOps: GitHub, GitLab, Atlassian
• HR-платформы: HR Cloud, BambooHR
• MDM/устройства: Microsoft Intune, Jamf
• Мониторинг: Grafana, Datadog, Splunk

Мега-чек-лист: всё в одном месте

Копируйте, адаптируйте под себя, используйте как шаблон для каждого тикета.

Подготовка (T-7...T-1)

• Тикет создан, дата подтверждена, ответственные назначены
• Собран полный список учёток (включая личные почты в рабочих системах)
• Уведомлены владельцы всех систем
• Подготовлены шаблоны автоответчика и уведомлений
• Проверены резервные сценарии (кто подменит, если уйдёт ключевой человек)

День X (T0)

• IdP: блокировка, отзыв MFA, завершение сессий
• VPN отключён
• Почта: автоответчик + переадресация на ограниченный срок
• Git/CI/CD: удаление из команд, перенос владения репозиториями
• Облачные провайдеры: отзыв ключей и ролей
• API-токены и SSH-ключи отозваны
• OAuth-приложения и интеграции отключены
• DNS/домены: проверены регистраторы и управляющие панели
• SaaS-сервисы: Notion, Figma, аналитика, реклама
• CRM, биллинг, менеджеры паролей
• MDM: блокировка устройств, удалённая очистка
• Возврат физических токенов и оборудования

После ухода (T+1...T+30)

• Проверены логи активности за последние 30 дней
• Пересозданы общие секреты, к которым был доступ
• Отключены платёжные подписки и автосписания
• Получены акты возврата/уничтожения
• Закрыты финансовые расчёты
• Уведомлены клиенты об изменении контактов
• Обновлена документация и процедуры
• Проведён финальный аудит безопасности
• Тикет закрыт с полным пакетом доказательств

Клиентские среды и внешние подрядчики

Отдельная песня — когда ваш сотрудник имел доступ к системам клиента или когда увольняется внешний подрядчик. Здесь добавляются дополнительные слои ответственности и согласований.

Алгоритм для клиентских сред:

1. Заранее уведомить контактное лицо по ИБ у клиента
2. Согласовать временные рамки отзыва доступов
3. Зафиксировать отключение в их системах (скриншоты, логи)
4. Получить подтверждение от клиента в письменном виде
5. Приложить всё к реестру оффбординга

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

Что делать с "бумерангами" — возвращающимися сотрудниками

76% компаний готовы рассмотреть возвращение бывшего сотрудника, а 40% уволившихся не исключают такой возможности. Качество оффбординга напрямую влияет на эти решения.

Если есть шанс на возвращение:

• Архивируйте данные вместо полного удаления
• Сохраните профили в деактивированном состоянии
• Задокументируйте специфику роли и доступов
• Поддерживайте профессиональные связи

Возвращающиеся сотрудники часто показывают лучшую производительность — у них меньше период адаптации и выше мотивация.

Особые случаи: экстренный и принудительный оффбординг

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

Экстренный протокол:

1. Немедленная блокировка в IdP и всех критичных системах
2. Отзыв VPN и удалённого доступа в первые минуты
3. Блокировка корпоративных карт и финансовых инструментов
4. Уведомление службы безопасности и IT-команды
5. Фиксация всех действий сотрудника в логах
6. Изоляция рабочего места (если физически доступно)

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

Большой чек-лист оффбординга

Этот список удобно держать как шаблон к каждому тикету "Leaver". Он не заменяет регламент, но даёт скелет процедуре и экономит время.

• Тикет "Leaver" создан, дата/время ухода подтверждены, владельцы систем назначены
• Собран список учётных записей: рабочая и личные почты, логины в внешних сервисах, рекламные кабинеты, доменные регистраторы
• IdP: блокировка, отзыв MFA, завершение активных сессий, отключение VPN
• Почта: автоответчик и переадресация на N дней, отключение правил и внешних интеграций, передача календаря
• Git/CI/CD/облака: удаление из групп, перенос владения, блокировка релизов, отзыв ключей и токенов, ротация общих секретов
• SaaS: Notion, Figma, Miro, Statuspage, мониторинг, аналитика, CRM, биллинг — отключено, подписки закрыты
• DNS/домен: проверены доступы, аккаунты и двухфакторная аутентификация
• MDM/оборудование: блокировка/очистка, возврат токенов 2FA, акт возврата/уничтожения
• Юридическое: напоминание об NDA, закрытие расчётов, отметка в реестре оффбординга
• Аудит: выгрузка логов 7–30 дней, проверка вебхуков, алиасов, OAuth-приложений
• Клиентские среды: уведомлён контакт ИБ клиента, доступы отозваны, подтверждения приложены
• Тикет закрыт с доказательствами: ссылки/скриншоты, акты, отчёт ИБ

Измеряем эффективность: KPI и метрики оффбординга

Несколько ключевых показателей, которые помогут понять качество процесса:

• Time to Critical Disable — время от создания тикета до блокировки критичных доступов (цель: < 4 часов)
• Complete Offboarding Time — полное время закрытия оффбординга (цель: < 7 дней)
• Automation Rate — процент автоматически отключённых систем (цель: > 70%)
• Compliance Score — доля оффбордингов с полным пакетом документов (цель: 100%)
• Orphaned Accounts Discovery — количество найденных "висячих" доступов через 30 дней (цель: 0)
• Employee Satisfaction — оценка процесса увольнения уходящими сотрудниками (цель: > 8/10)

Эти метрики не только показывают текущее состояние, but и помогают обосновать инвестиции в автоматизацию перед руководством.

Итог: оффбординг — это сервис, а не наказание

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

В 2025 году оффбординг перестаёт быть "довеском" к HR-процессам и становится полноценной дисциплиной на стыке кадров, ИТ и безопасности. Компании, которые поймут это раньше других, получат конкурентное преимущество в виде лучшей репутации работодателя, снижения рисков и более высокой эффективности команд.

И не забывайте главный принцип: если чего-то нет в реестре и без доказательства — этого не было. В оффбординге это правило спасает особенно часто.