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

20:08 / 20 октября, 2025

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

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

Оффбординг — это не просто "выпроводить человека и забыть". Это управляемое отключение всех нитей, которые связывают сотрудника с вашей 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 недели (не дольше!)
Отключить личные правила пересылки и внешние интеграции
Очистить подписи и обновить корпоративный справочник
Перевести календарные встречи новому владельцу

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Период	Действия
T-7...T-3 дня	Создать тикет, собрать инвентарь доступов, согласовать окно работ
T-1 день	Подготовить скрипты отключения, шаблоны уведомлений, проверить резервные сценарии
T0 (день X)	Отключить критичные доступы, включить автоответчик, отозвать токены, переназначить владельцев
T+1...T+7 дней	Проверить логи, пересоздать общие секреты, получить акты, закрыть расчёты
T+30 дней	Финальный аудит, обновление чек-листов, анализ lessons learned

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

Автоматизация: роботы 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 дней
Пересозданы общие секреты, к которым был доступ
Отключены платёжные подписки и автосписания
Получены акты возврата/уничтожения
Закрыты финансовые расчёты
Уведомлены клиенты об изменении контактов
Обновлена документация и процедуры
Проведён финальный аудит безопасности
Тикет закрыт с полным пакетом доказательств

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Этот список удобно держать как шаблон к каждому тикету "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-процессам и становится полноценной дисциплиной на стыке кадров, ИТ и безопасности. Компании, которые поймут это раньше других, получат конкурентное преимущество в виде лучшей репутации работодателя, снижения рисков и более высокой эффективности команд.

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