Как защитить корпоративные аккаунты при увольнении сотрудника
Сотрудник уволился. Трудовой договор расторгнут, оборудование сдано, пропуск деактивирован. Казалось бы, всё. Но в среднем доступы уволенного сотрудника к корпоративным системам остаются активными ещё от трёх до пяти дней — а в некоторых компаниях неделями и даже месяцами. За это время бывший коллега, который уходил в обиде или просто нашёл лучшее место, технически может войти в CRM, скачать базу клиентов, удалить критичные файлы или передать доступ конкурентам.
Это не паранойя. Это задокументированная статистика: по данным исследований, около 20% инцидентов информационной безопасности связаны с действиями бывших сотрудников. И почти все они происходят именно в окно между увольнением и фактическим отзывом всех доступов.
В этой статье — пошаговый алгоритм, который закрывает это окно.
Почему «просто удалить аккаунт в AD» недостаточно
Типичная ошибка: IT-отдел блокирует учётку в Active Directory и считает задачу закрытой. Но у современного сотрудника доступы разбросаны по десяткам систем, которые к AD не привязаны или привязаны не напрямую.
Вот неполный список того, что остаётся активным после блокировки AD:
Облачные сервисы — Google Workspace, Microsoft 365, Notion, Jira, Confluence, Slack, Trello. Каждый из них — отдельная учётная запись с отдельным паролем.
Корпоративные мессенджеры — Telegram-боты и группы, где у сотрудника были права администратора.
Рекламные кабинеты — Google Ads, Яндекс Директ, VK Реклама, Meta. Особенно опасно, если доступ был выдан на личный аккаунт сотрудника, а не корпоративный.
Банковские и финансовые сервисы — доступ в интернет-банк, платёжные системы, бухгалтерские сервисы.
Инфраструктура и DevOps — SSH-ключи, токены API, доступы к серверам, репозитории, CI/CD пайплайны. Здесь отдельный риск: разработчик мог оставить свой ключ в коде или конфигурационном файле.
Пароли, которые знал только он — пароли от сервисов, которые хранились у сотрудника в голове или в личном менеджере паролей.
Последний пункт — самый опасный. Если пароли не хранились централизованно, компания после увольнения сотрудника просто не знает, к чему у него был доступ.
Чеклист отзыва доступов при увольнении
В день увольнения (первый приоритет)
Это действия, которые нельзя откладывать ни на час — особенно если увольнение конфликтное.
Заблокировать учётную запись в Active Directory или LDAP. Это отключит доступ ко всем системам, интегрированным через SSO.
Отозвать активные сессии в корпоративном менеджере паролей. Если используется BearPass — один клик в разделе «Активные сессии», и сотрудник немедленно выходит из системы на всех устройствах.
Сменить пароли от систем, к которым у сотрудника был прямой доступ — особенно критичных: серверы, банк, облачные хранилища с конфиденциальными данными.
Отозвать SSH-ключи и API-токены. Попросить DevOps-команду проверить, не оставил ли сотрудник свои ключи в репозиториях или конфигурационных файлах.
Удалить или передать права администратора в корпоративных мессенджерах и рабочих группах.
В течение 24–48 часов (второй приоритет)
Отключить доступы к облачным сервисам: Google Workspace, Microsoft 365, Jira, Confluence, Slack, Notion и другим рабочим инструментам.
Передать или удалить аккаунт в рекламных кабинетах. Если доступ был привязан к личному аккаунту сотрудника — смените привязку на корпоративный аккаунт.
Проверить, не был ли корпоративный email привязан к внешним сервисам как основной для восстановления пароля.
Архивировать рабочую почту и передать доступ руководителю или преемнику.
В течение недели (третий приоритет)
Провести инвентаризацию всех систем, к которым имел доступ сотрудник, и убедиться, что ни одна не пропущена.
Проверить журнал событий в менеджере паролей — посмотреть, что сотрудник просматривал и копировал в последние дни работы.
Если сотрудник имел доступ к персональным данным клиентов — зафиксировать факт проверки для соответствия требованиям 152-ФЗ.
Как инсайдеры используют окно уязвимости
Понимание типичных сценариев помогает расставить приоритеты в чеклисте.
Скачивание баз данных. Сотрудник, зная об увольнении заранее, в последние дни активно скачивает данные клиентов, контрагентов, внутренние документы. По статистике, пик активности приходится на 1–3 дня до финального дня работы.
Передача доступов. Уволенный сотрудник передаёт логин и пароль от корпоративных систем новому работодателю или третьим лицам. Особенно актуально для менеджеров по продажам, которые уходят к конкурентам вместе с клиентской базой.
Намеренная диверсия. Удаление данных, изменение конфигураций, намеренное создание проблем — редко, но происходит. Особенно в ситуациях конфликтного увольнения.
Случайное использование. Бывший сотрудник продолжает по привычке заходить в корпоративные системы — не с злым умыслом, но это всё равно нарушение и риск утечки данных.
Три причины, почему компании не успевают закрыть доступы вовремя
Нет единого реестра доступов. IT-отдел не знает, к каким системам имел доступ конкретный сотрудник. Информация разбросана по головам разных администраторов и разных отделов.
Нет стандартного процесса offboarding. В компании нет чеклиста, нет ответственного, нет дедлайна. Каждый раз это делается по-разному.
Пароли не хранятся централизованно. Если пароли хранились у самого сотрудника — после его ухода компания не знает, к чему у него был доступ и что нужно сменить.
Как автоматизировать процесс
Ручной отзыв доступов — медленный и ненадёжный. Человеческий фактор, забытые системы, отпуск IT-специалиста в нужный момент. Правильное решение — выстроить процесс, в котором большинство действий выполняется автоматически или по одной команде.
Централизованное хранение паролей. Когда все корпоративные пароли хранятся в едином менеджере с ролевой моделью доступа, ситуация «пароль знал только он» становится невозможной. Новый сотрудник получает доступ к нужным папкам в системе — и именно этот доступ отзывается при увольнении. Пароли при этом остаются в компании.
Интеграция с LDAP и SSO. Если менеджер паролей интегрирован с Active Directory через LDAP, блокировка учётки в AD автоматически прекращает доступ к BearPass и всем системам, подключённым через SSO. Одно действие — весь доступ закрыт.
Kill Switch. В BearPass есть функция принудительного завершения всех активных сессий пользователя. Нажать одну кнопку — и сотрудник мгновенно выходит из системы на всех устройствах, включая личный телефон.
Автоматические уведомления. Через модуль «Правила» в BearPass можно настроить уведомление на почту службы безопасности при авторизации определённого аккаунта — например, уже уволенного сотрудника, если его учётку по какой-то причине не успели закрыть.
Журнал событий. Полная история действий каждого пользователя позволяет после увольнения провести аудит — посмотреть, что именно сотрудник просматривал и копировал в последние дни. Это важно и для расследования инцидентов, и для подтверждения факта проверки перед регулятором.
Что говорит закон
С 30 мая 2025 года вступили в силу изменения в КоАП, которые существенно увеличили штрафы за утечку персональных данных. Если утечка произошла по вине бывшего сотрудника, чей доступ не был своевременно закрыт, ответственность несёт компания — как оператор персональных данных. Штраф для юридических лиц составляет от 3 до 15 млн рублей, при повторном нарушении — от 1 до 3% годовой выручки, но не менее 20 млн рублей.
Это означает, что своевременный отзыв доступов — не просто вопрос безопасности, но и прямое требование законодательства.
Итог
Безопасный offboarding — это процесс, а не разовое действие. Он должен быть стандартизирован, задокументирован и по возможности автоматизирован.
Минимальный набор для любой компании: чеклист отзыва доступов, ответственный за его выполнение и централизованное хранение паролей — чтобы после ухода сотрудника компания точно знала, от чего и где нужно сменить пароль.
Если ваша команда сейчас хранит корпоративные пароли в таблицах, мессенджерах или у конкретных людей — это именно тот момент, чтобы исправить ситуацию до следующего увольнения. Попробуйте BearPass бесплатно — первые 5 пользователей бессрочно, без ограничений по функционалу.
