Уволился сотрудник: какие доступы нужно отключить в первый же день

Когда сотрудник увольняется, обычно в первую очередь думают о документах, передаче дел, оборудовании и расчёте. IT-доступы нередко остаются где-то в конце списка.

Именно здесь появляется риск: человек уже не работает в компании, но его учётная запись Windows всё ещё активна, VPN продолжает подключаться, корпоративная почта доступна с личного телефона, а пароль от общего сервиса никто не менял.

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

Главная проблема — доступы накапливаются годами

Когда сотрудника принимают на работу, права обычно выдаются постепенно.

Сначала создаётся учётная запись Windows. Потом нужен доступ к общей папке. Через неделю — к 1С. Затем сотруднику подключают VPN для удалённой работы, корпоративную почту, облачное хранилище, CRM и ещё несколько сервисов.

Через год никто уже не помнит полный набор его доступов.

Если в компании нет единого процесса управления доступом, увольнение превращается в попытку вспомнить всё вручную.

И именно тогда что-то обычно забывается.

Первое, что нужно отключить — персональную учётную запись

Если сотрудник использовал персональную учётную запись Windows или доменную учётную запись, её необходимо заблокировать сразу после прекращения доступа к рабочим системам.

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

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

Особенно это важно, если на сервере ведётся аудит входов, RDP-сеансов или действий с файлами.

RDP нужно проверять отдельно

Отключение учётной записи Windows обычно закрывает возможность войти под ней через RDP, но сам удалённый доступ всё равно стоит проверить отдельно.

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

• другую учётную запись для удалённого подключения;
• общий RDP-логин;
• локальную учётную запись на отдельном компьютере;
• VPN перед подключением к RDP;
• стороннюю программу удалённого управления.

Поэтому вопрос должен звучать не только «отключили ли пользователя», а «какими способами этот человек вообще мог подключаться удалённо».

Архитектуру удалённого доступа мы подробно разбирали в статье «RDP, AnyDesk и Radmin: как безопасно организовать удалённый доступ» .

VPN — отдельная точка входа

Если сотрудник подключался к корпоративной сети через VPN, его VPN-доступ необходимо отозвать независимо от состояния Windows-аккаунта.

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

Особое внимание нужно уделить ситуациям, когда VPN использует общий логин на несколько сотрудников.

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

И это одна из причин, почему персональные учётные записи удобнее не только для аудита, но и для нормального отзыва прав.

AnyDesk, Radmin, TeamViewer и другие средства удалённого управления

На практике именно такие программы часто забывают.

Сотрудник мог получить постоянный unattended-доступ к рабочему компьютеру через AnyDesk, Radmin Server, TeamViewer или другое средство.

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

Поэтому после увольнения необходимо проверить:

• какие программы удалённого управления установлены на его рабочем компьютере;
• включён ли постоянный доступ;
• какие аккаунты привязаны к программе;
• не использовался ли общий пароль;
• нет ли сохранённого доступа у бывшего сотрудника с личного устройства.

Корпоративная почта

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

Она часто используется не только для переписки, но и для восстановления паролей, подтверждения входов и регистрации в других сервисах.

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

После увольнения необходимо:

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

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

MFA тоже нужно отзывать

Иногда учётную запись блокируют, но забывают про второй фактор.

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

Даже если текущий пароль уже изменён, старый MFA-фактор лучше удалить из настроек аккаунта.

Особенно это важно для:

• почты;
• VPN;
• облачных сервисов;
• хостинга;
• CRM;
• административных панелей;
• финансовых и государственных сервисов.

1С и другие внутренние системы

Если у сотрудника была отдельная учётная запись 1С, её также необходимо отключить.

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

Отдельные пользователи в 1С значительно упрощают эту процедуру.

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

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

Сетевые папки и файловые серверы

При использовании персональных Windows-учётных записей блокировка пользователя обычно автоматически закрывает его доступ к сетевым ресурсам.

Но этим проверка не должна ограничиваться.

Стоит посмотреть:

• не использовался ли общий сетевой логин;
• не были ли сохранены реквизиты на личном компьютере;
• не выдавался ли доступ через отдельную локальную учётную запись сервера;
• не были ли файлы синхронизированы на личное устройство;
• не оставались ли публичные ссылки на облачные копии документов.

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

Облачные хранилища

Google Drive, OneDrive, Dropbox и другие облачные сервисы часто оказываются вне поля зрения системного администратора, особенно если сотрудники начали использовать их самостоятельно.

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

Бывший сотрудник мог получить доступ:

• через корпоративный аккаунт;
• через личный email;
• по публичной ссылке;
• через приглашение к отдельной папке;
• через синхронизированный локальный клиент.

Поэтому блокировки основной учётной записи иногда недостаточно.

CRM, таск-трекеры и корпоративные сервисы

В современной компании значительная часть доступа вообще находится за пределами локальной сети.

Это могут быть:

• CRM;
• системы управления задачами;
• корпоративные мессенджеры;
• облачная телефония;
• сервисы документооборота;
• системы видеоконференций;
• аналитика;
• панели управления сайтами;
• рекламные кабинеты;
• хостинг и домены.

Главная сложность здесь в том, что IT-служба не всегда знает обо всех сервисах, которыми пользовался сотрудник.

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

Хостинг, сайты и домены

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

Например:

• WordPress;
• панель хостинга;
• регистратор домена;
• Cloudflare;
• Google Search Console;
• Яндекс Вебмастер;
• аналитика;
• репозитории исходного кода;
• FTP/SFTP;
• SSH.

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

В таком случае после увольнения пароль следует сменить.

Общие пароли — самая неприятная часть

Персональную учётную запись можно просто отключить.

С общими реквизитами всё сложнее.

Если бывший сотрудник знал общий пароль от Wi-Fi, VPN, роутера, NAS, системы видеонаблюдения, хостинга или другого сервиса, сам факт его увольнения этот пароль недействительным не делает.

Поэтому все известные общие реквизиты, которыми он пользовался, нужно менять.

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

Локальные административные пароли

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

Если в организации один и тот же пароль локального Administrator используется на нескольких ПК, его знание фактически может давать доступ сразу к группе устройств.

В такой ситуации после увольнения администратора или технического специалиста общий пароль необходимо менять.

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

Wi-Fi тоже является доступом

Корпоративный Wi-Fi часто вообще не включают в список отзыва прав.

Если используется общий пароль WPA2/WPA3-Personal, бывший сотрудник продолжает его знать после увольнения.

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

Но сам факт знания старого общего пароля необходимо учитывать.

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

Телефон, ноутбук и другие устройства

Возврат оборудования — это не только вопрос имущества.

На устройстве могут оставаться:

• активные почтовые сеансы;
• сохранённые пароли;
• VPN-профили;
• файлы компании;
• токены браузера;
• облачная синхронизация;
• сертификаты;
• ключи ЭЦП;
• данные мессенджеров.

Корпоративное устройство после возврата желательно проверить и подготовить к следующему пользователю, а не просто передать его вместе со старым профилем Windows.

Что делать с рабочими данными сотрудника

Отключение доступа не должно привести к потере рабочих документов.

До удаления профиля необходимо определить, где хранились:

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

Не стоит автоматически копировать всё подряд неизвестно куда. Рабочие данные должны быть переданы ответственному сотруднику или перемещены в корпоративное хранилище согласно принятому порядку.

Что делать с активными сеансами

Смена пароля не всегда мгновенно завершает все существующие сеансы.

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

Поэтому для критичных систем полезно отдельно использовать функцию:

• «Завершить все сеансы»;
• «Выйти со всех устройств»;
• «Отозвать токены»;
• «Отключить доверенные устройства».

Особенно это важно для почты, облаков и административных сервисов.

Не забудьте про API-ключи и токены

У технических специалистов и разработчиков могут быть не только обычные логины и пароли.

Доступ может осуществляться через:

• API-ключи;
• SSH-ключи;
• токены доступа;
• пароли приложений;
• сертификаты;
• ключи интеграций.

Такие реквизиты также необходимо отозвать или заменить.

Причём смена обычного пароля пользователя не всегда делает старый токен недействительным.

Что проверить в журналах после увольнения

Для критичных ролей полезно не просто закрыть доступ, но и убедиться, что после даты увольнения под этой учётной записью не происходят новые входы.

Можно проверить:

• Windows Security;
• RDP-журналы;
• VPN-логи;
• почтовые входы;
• логи облачных сервисов;
• историю административных панелей.

Для этого журналы должны хранить достаточную глубину истории.

При необходимости можно воспользоваться нашим калькулятором глубины журнала Windows Security .

Что отключить в первый день

Для системного администратора список должен быть шире

Если увольняется обычный пользователь, набор его прав обычно ограничен.

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

У такого человека могут быть:

• локальные административные пароли;
• Domain Admin или другие привилегированные роли;
• доступ к серверам;
• VPN;
• сетевое оборудование;
• гипервизоры;
• NAS;
• системы резервного копирования;
• антивирусные консоли;
• хостинг;
• домены;
• облачную инфраструктуру;
• SSH-ключи;
• пароли от оборудования.

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

Лучше не вспоминать доступы в день увольнения

Правильная схема строится ещё в момент приёма сотрудника.

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

Для каждого сотрудника полезно понимать:

• какие учётные записи ему созданы;
• к каким системам он имеет доступ;
• какие права ему выданы;
• какие устройства закреплены;
• какие средства удалённого доступа разрешены;
• какие дополнительные ключи или сертификаты выданы.

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

Минимальный принцип: один человек — одна учётная запись

Чем больше в компании персональных аккаунтов и чем меньше общих логинов, тем проще управлять увольнением.

Персональный аккаунт можно отключить одним действием.

Общий пароль приходится менять для всех.

Персональная учётная запись позволяет сохранить историю действий конкретного человека.

Общий логин эту связь разрушает.

Поэтому управление увольнениями напрямую связано с общей архитектурой прав доступа в компании.

С чего начать компании

Необязательно сразу внедрять сложную Identity Management-систему.

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

При увольнении ответственный сотрудник последовательно проходит этот список и подтверждает отзыв каждого доступа.

А если компания не может сейчас точно сказать, какие учётные записи, удалённые подключения и административные права существуют в её инфраструктуре, сначала стоит провести их инвентаризацию.

WEB-LABS проводит техническое обследование IT-инфраструктуры , в рамках которого можно проверить пользователей, административные права, RDP, VPN, удалённые подключения, сетевые ресурсы, журналы Windows и другие точки доступа.

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