Доступы уволенного сотрудника: что отозвать в первые 30 минут

MAATRIX

Разговор об увольнении закончен, человек уже читает уведомление в HR-системе, а у вас в голове крутится один вопрос: куда он может зайти прямо сейчас. Если увольнение конфликтное или внезапное, у вас нет времени вспоминать, какие сервисы вообще есть в компании — нужен готовый порядок действий, который выполняется на автомате. Ниже — именно такой порядок: что отозвать в первые 30 минут, что сделать в течение дня, и почему этот список должен лежать у вас заготовленным заранее, а не рождаться в панике во время самого разговора.

Почему готовый чек-лист — это не бюрократия, а страховка

Офбординг, придуманный на ходу, почти всегда пропускает что-то важное. В момент стресса — а увольнение сотрудника, особенно конфликтное, это стресс для обеих сторон — мозг работает по принципу «вспомнил то, что на виду»: SSH-доступ к продовому серверу вспомнят сразу, а доступ к DNS-панели регистратора домена или к аккаунту в системе мониторинга — только через неделю, когда что-то отвалится или, хуже, когда кто-то воспользуется этим доступом.

Разница между компанией с готовым runbook'ом и без него на практике выглядит так: в первом случае весь блок критичных доступов закрывается за 15-30 минут одним человеком по чек-листу, во втором — растягивается на несколько дней, потому что приходится вспоминать, какие сервисы вообще существуют, у кого какие права были и куда стоит посмотреть в первую очередь. За эти дни бывший сотрудник, если он настроен недоброжелательно, успевает сделать что угодно — от банального повышения тарифа на VPS в личных целях до удаления бэкапов.

Готовый чек-лист решает три проблемы разом:

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

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

Минуты 0-10: SSH-доступ к серверам

SSH — это прямой путь на сервер, поэтому он закрывается первым, ещё до того, как вы разберётесь с панелями и репозиториями. Порядок:

1. Отзовите ключ на каждом сервере, куда у сотрудника был доступ. Если ключи именные (у каждого свой authorized_keys-файл или отдельная запись), достаточно удалить конкретную строку:

sudo sed -i '/user@former-employee/d' /etc/ssh/authorized_keys.d/*
# или, если ключи лежат в домашних директориях:
sudo sed -i '/user@former-employee/d' /home/*/.ssh/authorized_keys

1. Заблокируйте системную учётную запись, если она у сотрудника была персональная (не общий deploy-юзер):

sudo usermod -L username
sudo passwd -l username
# и, при необходимости, полное удаление после проверки, что учётка больше не нужна:
sudo userdel -r username

1. Проверьте sudo-права — уберите из /etc/sudoers.d/ или из группы sudo/wheel, если запись есть:

sudo deluser username sudo

1. Если у вас централизованное управление ключами (Ansible, Chef, Salt, или SSH-сертификаты через Vault/Teleport) — отзыв делается одной командой на всём парке серверов, а не вручную на каждом. Если такой системы нет и серверов больше 5-10, заведите её сейчас же после того, как закроете инцидент — вручную зачищать ключи на десятках хостов вы больше не хотите.
2. Не забудьте про облачные SSH-ключи, привязанные к аккаунту провайдера (AWS EC2 key pairs, ключи в панели VPS-провайдера) — они позволяют переустановить доступ даже после зачистки authorized_keys на самом сервере.

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

Минуты 10-20: панели управления хостингом и облаком

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

Что проверить и отозвать:

• Личный кабинет хостинг/VPS-провайдера — если у сотрудника был отдельный логин (не общий), удалите или заблокируйте его в разделе управления командой/сотрудниками. Если использовался общий логин — меняйте пароль и отзывайте все активные сессии, где это доступно.
• API-токены облака или хостинга — отдельно от паролей. Токен, выписанный полгода назад для CI/CD или для личного удобства, продолжает работать даже после смены пароля в панели. Проверьте раздел API-ключей и отзовите всё, что выдавалось на имя или под контролем этого человека.
• DNS-панель регистратора домена — недооценённый вектор: доступ к DNS позволяет перенаправить почту и трафик сайта на чужой сервер. Смените пароль и включите 2FA, если её не было.
• Панели облачных провайдеров (AWS/GCP/Yandex Cloud/Selectel и т.д.) — удалите IAM-пользователя или отключите его ключи доступа, а не просто смените пароль консоли.
• Мониторинг и алертинг (Zabbix, Grafana, Uptime Kuma и подобные) — доступ сюда не критичен для атаки, но даёт понимание вашей инфраструктуры, если попадёт не в те руки.

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

Минуты 20-30: репозитории кода и CI/CD

Третий блок — доступ к коду и конвейеру доставки. Здесь риск не только в утечке кода, но и в возможности незаметно внести изменения (например, бэкдор в деплой-скрипт), которые проявятся через недели.

• Удалите из организации на GitHub/GitLab/Bitbucket — не просто из конкретного репозитория, а из организации целиком, иначе форк или приватный клон может остаться доступен через личный токен.
• Отзовите deploy-ключи и personal access tokens, выписанные на имя сотрудника или используемые под его учётной записью в CI/CD. Проверьте раздел Settings → Developer settings → Personal access tokens (GitHub) или Access Tokens (GitLab) — токен мог быть выдан с широкими правами и долгим сроком жизни.
• Ротация секретов в CI/CD — если сотрудник имел доступ к настройкам пайплайна (GitHub Actions secrets, GitLab CI/CD variables), считайте все секреты, которые он мог видеть или экспортировать через лог, потенциально скомпрометированными. Это не паранойя: секрет, один раз попавший в переменную окружения раннера, мог быть выведен в лог по неосторожности задолго до увольнения — и здесь тоже стоит его перевыпустить.
• Registry-токены — Docker Hub, приватный npm/PyPI registry, GitHub Container Registry — отдельная точка, про которую часто забывают, потому что она не связана напрямую с Git.

Здесь же стоит проверить список деплой-ключей на самих серверах (~/.ssh/id_deploy и подобные) — если сотрудник настраивал CI/CD вручную, у него мог быть свой отдельный ключ для автодеплоя, не привязанный ни к личной учётке в Git, ни к обычному SSH-доступу.

Параллельно: общие пароли и секреты, которые мог знать сотрудник

Пока идёт зачистка первых трёх блоков, параллельно (в идеале — вторым человеком, если он есть) нужно закрыть то, что сложнее всего гарантированно отозвать: секреты, которые сотрудник просто знал, а не имел к ним технический доступ через свою учётку.

• Общий root-пароль на серверах — если в команде практиковался общий пароль администратора (антипаттерн, но встречается сплошь и рядом), его нужно менять на каждом сервере, где он использовался, причём сразу, не откладывая на «в течение дня». Один и тот же пароль на десяти серверах — это десять точек, которые нужно закрыть одновременно, иначе зачистка первых девяти теряет смысл, пока не закрыта десятая.
• Менеджер паролей команды (Vaultwarden, 1Password, Bitwarden) — удалите пользователя из организации/сейфа. Если использовались общие записи (не персональные), которые сотрудник мог видеть или экспортировать — считайте их скомпрометированными и меняйте, даже если формально доступ уже отозван: экспорт списка паролей делается за одну кнопку, и отзыв доступа к менеджеру постфактум это не отменяет.
• Секреты в .env-файлах и конфигах, к которым был прямой доступ через SSH или репозиторий — токены сторонних сервисов (платёжные шлюзы, email-рассылки, облачные API) нужно перевыпустить, а не просто «на всякий случай оставить, вдруг не успел скопировать».
• HashiCorp Vault или аналог, если используется — отозвать токен и AppRole-доступ, привязанные к сотруднику, и, если есть подозрение на злой умысел, отдельно проверить журнал обращений к секретам за последние недели его работы.

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

VPN и удалённый доступ в сеть

Отдельный, часто забываемый пункт — доступ в саму сеть, а не к конкретным сервисам внутри неё. Если у сотрудника был VPN-доступ (для удалённой работы или для доступа к внутренним ресурсам), через него можно достучаться до всего, что доступно только «изнутри» — включая базы данных без внешнего IP и админки без публичного адреса.

• WireGuard — удалите peer-конфигурацию сотрудника на сервере (wg set wg0 peer <публичный_ключ> remove и перезапись конфига, чтобы правило не вернулось после перезагрузки).
• OpenVPN — отзовите сертификат клиента через easy-rsa (./easyrsa revoke username и пересборка CRL) или удалите пользователя, если используется аутентификация по логину/паролю.
• Tailscale/Netbird и аналоги zero-trust-сетей — удалите устройство и учётную запись из ACL-группы, а не просто из «списка участников»: если политика привязана к группе, а не к конкретному узлу, устройство может сохранить доступ до следующей синхронизации.
• RDP — если был отдельный внешний доступ по RDP (что само по себе рискованная практика), закрывайте порт или отзывайте учётку в первую очередь, до всех остальных пунктов этого раздела — это один из самых частых векторов для атак с шифровальщиками, когда доступ остаётся висеть.

Если у вас несколько VPN-серверов на разных площадках (например, для разных регионов), проверяйте каждый — конфигурация переезда обычно не синхронизируется автоматически, и «убрал на одном сервере» не значит «убрал везде».

В течение дня: смена паролей и ревизия последних действий

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

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

Ревизия последних действий перед увольнением. Особенно важно, если увольнение было конфликтным — проверьте, не осталось ли следов подготовки к уходу с «подарком»:

• логи аутентификации на серверах за последние 2-4 недели (journalctl -u sshd, /var/log/auth.log или /var/log/secure в зависимости от дистрибутива) — необычное время входа, вход с новых IP;
• список пользователей и SSH-ключей на серверах — не появился ли новый пользователь или ключ, который сотрудник добавил себе «про запас»;
• crontab на серверах, где у него был доступ (crontab -l -u username, /etc/cron.d/) — на предмет заданий, которых там не должно быть;
• история коммитов в репозиториях за последние недели — необычные изменения в правах доступа, в конфигах CI/CD, в файлах, отвечающих за аутентификацию;
• журнал обращений к секретам (если используется Vault или аналог) и audit trail облачного провайдера — не выгружались ли данные или бэкапы массово незадолго до увольнения.

Если находите что-то подозрительное — не спешите делать выводы в одиночку: сохраните логи как есть (скопируйте, а не просто просмотрите — они могут ротироваться), зафиксируйте время находки и, если компания достаточно крупная, подключите юриста и/или того, кто отвечает за безопасность, прежде чем делать оргвыводы. Похожий разбор конкретного инцидента — с забытым на восемь месяцев ключом бывшего сотрудника — есть в статье «SSH-ключ уволенного сотрудника работал восемь месяцев»: там показано, к чему приводит именно отсутствие ревизии в первый день.

Частые вопросы