Почти любая компания уверена, что умеет увольнять сотрудников безопасно. На бумаге этот процесс (Offboarding) выглядит идеально прямой линией: приказ HR ➔ заявка в ИТ ➔ блокировка учетной записи ➔ возврат обклеенного стикерами ноутбука.

На практике именно в этот день выясняется, что ваша система управления доступами - это просто набор костылей, скрепленных скриптами пятилетней давности и доброй волей парочки сисадминов.

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

Представьте классический инцидент: через три месяца после жесткого увольнения DevOps-инженера в вашем AWS-аккаунте внезапно поднимается ферма для майнинга крипты, сжигая $50,000 за выходные. Вы бежите смотреть логи и видите легитимную авторизацию по API-ключу. Как? Ведь вы лично видели, как HR заблокировал его в Active Directory.

Добро пожаловать в мир цифровых призраков.

Иллюзия единственной кнопки

Главная ошибка ИБ и ИТ - считать, что инфраструктура всё еще живет в 2010 году, где блокировка учетки в Active Directory (AD) автоматически и мгновенно отрезает человека от всего корпоративного мира.

Сегодня доступы размазаны тонким слоем по десяткам микросервисов, облаков и платформ. Если вы просто нажали Disable в AD, вы лишь срубили верхушку айсберга. Под водой остается Residual Access (остаточный доступ) - невидимая сеть связей, ключей и сессий, которые продолжают жить своей жизнью.

Кладбище забытых доступов: Где прячутся хвосты?

1. Теневое IT и SaaS-зоопарк Маркетологи купили подписку на сервис аналитики (Miro, Notion, Figma) с корпоративной карты, завели там локальные учетки и никому не сказали. ИТ-отдел про эти сервисы даже не знает, а значит - никогда не отзовет доступ при увольнении. Уволенный сотрудник может годами читать стратегии компании, просто заходя по старому паролю.

2. Инфраструктурные «закладки» Доменную учетку инженера отключили, но его личный SSH-ключ навсегда остался в файле authorized_keys на production-серверах. Туда же идут личные API-ключи, постоянные токены для CI/CD-пайплайнов и доступ к облачным консолям (AWS/Azure/GCP), которые часто администрируются вне корпоративного каталога.

3. Личные аккаунты в корпоративной среде Бич современной разработки - использование личных GitHub, GitLab или Docker Hub аккаунтов для доступа к корпоративным репозиториям. Человек уволился, а его личный аккаунт nagibator99 всё еще имеет права на чтение (а иногда и запись) в приватные репозитории с исходным кодом вашего флагманского продукта.

4. Проклятие общих ящиков (Shared Accounts) Пароль от учетки info@, support@ или root на сервере базы данных знает половина отдела. При увольнении одного человека пароль нужно менять и перераздавать всем остальным. Делает ли это кто-то в реальности? Конечно нет, «иначе интеграции отвалятся и Петрович расстроится».

5. VPN, токены и доверенные устройства Учетка выключена, пароль изменен. Но сессия на личном мобильном устройстве (например, в корпоративном мессенджере, почтовом клиенте или мобильной CRM) по факту будет жить, пока не истечет срок действия Refresh-токена. А это может быть 30, 90 дней или вообще бесконечность.

6. OAuth и сторонние интеграции Сотрудник когда-то нажал кнопку «Войти через Google/Microsoft» в каком-то левом приложении-календаре и выдал ему права на чтение корпоративной почты. Приложение продолжает стучаться в ящик (через API), даже когда сотрудник уже пакует коробки.

Почему это ломается организационно?

Проблема остаточных доступов - это редко технический баг. Это провал процессов (Governance). Отзыв доступов в 90% компаний превращается в суетливый квест по чатам: «А в подрядном портале его отключили? А из чатика с безопасниками в телеге удалили?».

Если процесс не имеет единого владельца, несущего ответственность за финальный результат, он развалится. ИТ отвечает только за домен, ИБ - только за VPN, а за доступы в CRM отвечает руководитель отдела продаж, который вообще забыл написать заявку в HelpDesk. Надежда - плохая стратегия информационной безопасности.

Чек-лист: 5 признаков, что ваш Offboarding сломан:

  1. Отзыв доступов зависит от памяти конкретного админа.
  2. В обходном листе нет пункта про передачу данных (что делать с файлами на Google Drive/OneDrive уволенного).
  3. Вы не можете за 5 минут получить выгрузку абсолютно всех систем, куда имел доступ конкретный менеджер.
  4. Вы не сбрасываете активные веб-сессии при блокировке учетной записи.
  5. У вас нет процедуры ротации паролей от сервисных УЗ при увольнении ключевых инженеров.

Лекарство: Как строить зрелый Offboarding

Если у вас нет многомиллионного бюджета на внедрение тяжелого IdM/IGA (Identity Governance and Administration), начните с базовой процессной гигиены.

1. Инвентаризация точек входа (SSO как религия) Все корпоративные SaaS, порталы и VPN должны быть заведены за Single Sign-On (Keycloak, Entra ID). Никаких локальных учеток. Если сервис не поддерживает SAML/OIDC - это веский повод отказаться от сервиса. Только тогда единственная кнопка Disable в каталоге реально сработает для 95% ландшафта.

2. Принудительный отзыв сессий (Continuous Access Evaluation) Блокировка учетки не обрывает текущие соединения. Обязательный технический шаг при увольнении - сброс всех активных токенов (Revoke Refresh Tokens) в Office 365, Google Workspace и корпоративном Identity-провайдере. Выкидывайте сессии жестко.

3. Фазирование (T+0 и T+30) Здоровый оффбординг делится на этапы.

  • День увольнения (T+0): Блокировка входов, отзыв токенов, смена паролей, отключение VPN.
  • Через 30 дней (T+30): Передача данных руководителю, удаление почтового ящика, очистка лицензий (чтобы не платить за мертвые души), удаление домашних папок.

4. Аудит общих и сервисных учеток (PAM) Переход на корпоративные менеджеры паролей (VaultWarden, KeePassXC) с жестким ролевым доступом. Никаких паролей в Excel. Если человек уволился, PAM-система должна в идеале автоматически ротировать пароли от всех общих учеток, к которым он имел доступ. Если PAM нет - это становится прямой обязанностью руководителя отдела.

5. Матрица доступов (RBAC) вместо клонирования Перестаньте выдавать права по принципу "сделайте новенькому Васе доступы как у сениора Пети, только добавьте еще админку". Если вы не знаете точно, на основании какой роли был выдан доступ, вы никогда не вспомните, что именно нужно забирать.

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

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