Управление доступом после увольнения: регламент смены прав и защиты корпоративных аккаунтов

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

Спойлер: ничего не закрыто. Блокировка входа не всегда срабатывает как рубильник для уже открытых сессий, а выданный access token продолжает действовать до окончания своего срока жизни. То есть уволенный сотрудник теоретически ещё некоторое время пользуется корпоративными ресурсами после того, как формально «отключён».

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

Техническая механика простая и одновременно коварная. Когда пользователь входит в облачное приложение, Microsoft Entra ID — бывший Azure AD — выдаёт ему access token с ограниченным сроком жизни и refresh token, который позволяет получать новые access-токены без повторного ввода пароля. Отзыв refresh-токена в Entra ID прекращает выдачу новых токенов. Но это не означает, что приложение, у которого уже есть действующий session token, немедленно выкинет пользователя.

Каждое стороннее SaaS-приложение управляет собственной сессией по собственной политике: GitHub, Salesforce, Slack, 1С в облаке, amoCRM, любой VPN-шлюз с собственной аутентификацией. Entra ID не умеет принудительно отзывать чужие session tokens — это не его зона ответственности. Результат предсказуем: сотрудник входит в CRM через SSO, получает токен от Entra, а CRM продолжает считать сессию валидной до окончания собственного таймаута.

Блокировка входа — это не финальное действие. Сброс пароля, отзыв токенов и принудительное завершение сессий — то, из чего складывается реальная защита.

Для IT-отдела, который не различает эти действия, разница остаётся теоретической. Для практикующего безопасника — критической. За время жизни уже выданного токена сотрудник с широкими правами может выгрузить клиентскую базу из CRM, скопировать репозиторий или изменить критичные настройки. А формально он уже «отключён»: HR закрыл задачу, в отчёте стоит отметка, инцидента как будто нет.

Именно здесь обычно ломается разговор о восстановлении доступа к рабочему аккаунту после увольнения сотрудника. Компания думает об учётной записи как о двери с одним замком. В реальности это связка из идентичности, сессий, ролей, MFA-факторов, API-ключей, приложений и устройств. Закрыть только один замок недостаточно.

Регламент NIST SP 800-53: как синхронизировать кадровые процессы с управлением учётными записями

Контроль AC-2 из NIST SP 800-53 Revision 5 полезен не тем, что превращает безопасность в набор формальностей для аудитора. Он задаёт внятный каркас управления учётными записями: создание, модификация, отключение, удаление, периодический пересмотр и назначение ответственных должны быть привязаны к реальным кадровым событиям — приёму, переводу, изменению роли, увольнению.

Конкретный срок уведомления владельца учётной записи и срок отключения определяет сама организация: NIST не диктует «24 часа» или «неделю». Это одновременно гибкость и ловушка. Организации часто устанавливают сроки, удобные HR-процессу, а не реальной модели угроз. Если человек увольняется конфликтно, задача «отключить до конца следующего рабочего дня» звучит как приглашение к инциденту.

Отдельная зона риска — общие и групповые учётные записи. Если в инфраструктуре до сих пор живёт учётка admin@, crm-team@ или backup-ops@ с паролем в общем чате, выход сотрудника из команды требует не только убрать его из группы. Нужно менять аутентификаторы, пересматривать доступы и выяснять, не осталось ли у него копий ключей, паролей или резервных кодов.

Это не формальность. Уволенного сотрудника можно корректно вывести из IAM-группы, но забыть про service account, ключ доступа к облаку или общий пароль от панели подрядчика. В отчёте будет написано «доступ отозван». В реальности он останется — просто в другом слое.

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

Проблема большинства компаний — между строками «IT-администратор» и «владелец сервиса». Владелец сервиса — не абстрактная роль в политике. Это конкретный человек, который знает, где отключается пользователь в его SaaS, кому принадлежат данные и какие права нельзя вернуть автоматически. Если такого человека нет или он узнаёт об увольнении через месяц — это провал процесса, а не «сбой в системе».

Скрытые угрозы: общие пароли, ключи доступа и сторонние SaaS-приложения вне Entra ID

Entra ID, Okta или Google Workspace — это центр, но не вся вселенная. Дальше начинается длинный хвост из сервисов, живущих по собственным правилам. Сотрудник, проработавший несколько лет, знает, где лежат общие учётки от внешних подрядчиков, у кого в Jira выписан токен, в каком Notion-пространстве лежит база клиентов и какой SSH-ключ добавлен на сервер.

Если человек уходит с обидой — а обиженные бывают чаще, чем кажется HR-отделу, — диапазон ущерба простирается от утечки клиентской базы до удаления данных через пару недель после увольнения. Не потому, что IT ничего не сделал. А потому, что IT сделало только то, что было видно из центрального каталога учётных записей.

Самые опасные учётные записи — те, о которых IT-отдел не знает, потому что их когда-то завели в обход регламента.

Типовые «хвосты», которые всплывают при нормальном аудите депровижининга:

• Сервисные учётки в AWS, GCP или Azure, привязанные к личному email бывшего сотрудника. Он может получать уведомления, видеть ресурсы, участвовать в восстановлении доступа или ротировать ключи.
• Персональные токены в GitHub и GitLab с правами push в корпоративные репозитории. Удаление SSO-аккаунта само по себе не всегда решает судьбу выданного токена: его нужно инвентаризировать и отзывать по правилам конкретной платформы.
• MFA-приложения на личном телефоне — Google Authenticator, Authy, Microsoft Authenticator. После отвязки фактора в IdP коды могут продолжать отображаться в приложении, но не должны приниматься провайдером идентификации. Отдельно нужно проверять независимые MFA-регистрации в сторонних сервисах: если TOTP-фактор был добавлен напрямую в GitHub, Salesforce или CRM, он живёт собственной жизнью.
• API-ключи в CI/CD — Jenkins, GitHub Actions, GitLab CI. Они часто лежат в переменных окружения, секретах проектов или локальных конфигурациях и не привязаны к пользователю напрямую.
• VPN-конфиги и сертификаты на домашнем ноутбуке. Пока сертификат не отозван, а профиль не отключён на стороне шлюза, кадровый статус сотрудника ничего не меняет.
• Менеджеры паролей корпоративного уровня — 1Password, Bitwarden, KeePass и аналоги. Недостаточно удалить человека из общего хранилища: следует пересмотреть, какие пароли он мог сохранить, экспортировать или использовать вне менеджера.
• Браузерные сессии и расширения, через которые идёт доступ к конфиденциальным админкам. Logout в IdP не обязан убить сессию, открытую в браузере неделю назад.
• Учётные записи у подрядчиков: рекламные кабинеты, системы электронного документооборота, порталы поставщиков, почтовые рассылки, облачные телефонии. Именно они часто не попадают в инвентаризацию, потому что покупались отдельным подразделением.

Для каждого из этих пунктов нужен собственный сценарий отзыва, и ни один IdP не сделает его полностью автоматически. Поэтому «универсальная кнопка отключить сотрудника» — миф. Есть набор ручных и автоматизированных действий, и у каждого должен быть владелец, срок и подтверждение исполнения.

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

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

Процедура депровижининга: автоматизация вывода пользователя из корпоративной экосистемы

Microsoft Entra умеет автоматически депровижинить пользователя в подключённых SaaS-приложениях через SCIM. При изменении статуса пользователя в Entra ID служба provisioning отправляет в приложение запрос на отключение или деактивацию. Но автоматизация не означает мгновенности: синхронизация выполняется по расписанию, может зависеть от настроек коннектора, очереди задач и того, как конкретный SaaS трактует команду деактивации.

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

Для таких сервисов нужен заранее определённый ручной процесс и назначенные администраторы. Иначе депровижининг превращается в квест «найти того, кто знает пароль от админки».

Практическая реализация нормального депровижининга строится на трёх слоях:

1. IdP-уровень — Entra ID или аналог. Блокировка входа, сброс пароля, отзыв токенов, завершение активных сессий и отключение MFA-факторов. Это базовый слой, он же самый быстрый.

2. SCIM-уровень — приложения с настроенной автоматической интеграцией. Здесь важно не просто включить коннектор, а проверить: что именно происходит с пользователем, ролями, группами, токенами и данными после деактивации.

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

Главная ошибка при построении депровижининга — автоматизировать только первый слой и посчитать задачу завершённой. Реальная безопасность появляется, когда для каждого SaaS-сервиса заранее известно:

• подключён ли он к IdP и какой именно механизм используется;
• умеет ли интеграция не только заводить, но и отключать пользователя;
• кому уходит задача, если автоматическое отключение не сработало;
• нужно ли передавать файлы, проекты, почту, лицензии или права владельца;
• как отзываются персональные токены, API-ключи и независимые MFA-факторы;
• где смотреть подтверждение, что блокировка доступа уволенного сотрудника к CRM, репозиторию или облаку действительно произошла.

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

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

Восстановление удалённого аккаунта в Microsoft 365: 30-дневное окно и условия возврата данных

Сценарий «удалили не того» или «сотрудник вернулся через неделю» встречается регулярно. В Microsoft 365 для удалённой учётной записи предусмотрено 30-дневное окно восстановления. В этот период можно вернуть саму учётную запись и связанные с ней данные в пределах возможностей и настроек сервиса. После восстановления обычно требуется заново назначить лицензию, если сотруднику нужен рабочий доступ к сервисам Microsoft 365.

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

Оно требует:

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

30 дней — правило Microsoft 365, а не универсальный срок жизни для всей корпоративной экосистемы. Его нельзя механически переносить на Google Workspace, VPN, CRM, Git-репозитории, менеджеры паролей и прочие системы. У каждой платформы собственные условия восстановления, хранения и удаления данных; часть сервисов вообще не гарантирует возврат удалённого содержимого.

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

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

1. HR или руководитель подразделения создаёт запрос с основанием для возврата, идентификатором сотрудника и подтверждением его нового статуса.

2. Владелец системы определяет, какие роли и права нужны сейчас. Старую матрицу доступа не копируют автоматически.

3. Администратор восстанавливает учётную запись в пределах доступного окна и назначает только необходимые лицензии.

4. Пароль сбрасывается, активные сессии завершаются, MFA-факторы регистрируются заново, старые токены и резервные методы входа пересматриваются.

5. Доступы к CRM, облачному хранилищу, репозиториям, VPN и внешним SaaS выдаются отдельно — по актуальной роли, а не по памяти о прошлом месте сотрудника.

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

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

Позиция автора

Управление доступом после увольнения — не одна кнопка, а оркестр из ручных и автоматизированных процессов, у каждого из которых есть владелец, срок и точка отказа. NIST SP 800-53 даёт полезную рамку для дисциплины учётных записей. Microsoft 365 и Entra ID дают инструменты. Но реальная безопасность определяется тем, насколько серьёзно компания относится к ручному слою депровижининга.

Тот, кто считает Block sign-in финальной точкой процесса увольнения, однажды будет разбирать утечку и рассказывать аудиторам, что «всё было по инструкции». Инструкция без реестра сервисов, владельцев, сценариев передачи данных и сроков — не инструкция, а бумажка для проверки.

Главная защита здесь не технология, а дисциплина процесса. IdP закрывает базовый слой, SCIM покрывает часть SaaS, а оставшийся хвост требует явного реестра и регулярного тестирования. Восстановление удалённой учётной записи — отдельная операция с отдельными основаниями, а не «отмена увольнения» по звонку. Всё это проверяется не чтением политики, а тем, что происходит в первые минуты после того, как последний рабочий день сотрудника закончился.