Сотрудник уволился, а доступ остался: аудит за один вечер

MAATRIX

Сотрудник уволился (или его уволили) вчера, а формального процесса отзыва доступа в компании никогда не было — просто потому что раньше не было повода его выстраивать. Сегодня вы понимаете, что этот человек мог заходить по SSH на десяток серверов, знать пароль от панели хостинга и держать в буфере API-токен от продового окружения. Ниже — конкретный порядок действий на один вечер: что проверить, в каком порядке и какими командами, чтобы закрыть реальные дыры, а не для галочки.

Соберите инвентарь за 15 минут: что вообще нужно проверить

Прежде чем что-то отзывать, нужен список того, что вообще может быть точкой доступа. Без единого реестра (о его отсутствии — ниже) собирать его придётся вручную, но 15 минут на это стоит потратить, иначе вы гарантированно что-то пропустите.

Откройте текстовый файл и выпишите по памяти и по факту (история браузера, почта, Slack/Telegram-переписка с этим человеком, тикеты в трекере) всё, к чему у уволенного мог быть доступ:

• Список серверов (IP или имена хостов) — из Ansible-инвентаря, Terraform-стейта, панели хостинг-провайдера или просто из истории ~/.ssh/config на своей машине.
• Панели управления — хостинг, DNS-регистратор, CDN, облачный провайдер, панель почты.
• Внешние сервисы с личным или общим логином: мониторинг, аналитика, платёжный шлюз, рассылки.
• Репозитории кода — GitHub/GitLab/Bitbucket организация, self-hosted Git.
• Общие пароли — менеджер паролей (если есть) или файл/чат, куда пароли когда-то скидывали (и это тоже нужно честно признать).
• Personal access token'ы и API-ключи, выданные лично этому человеку — CI/CD, мониторинг, платёжные API, внешние интеграции.

Дальше идите по списку сверху вниз — порядок важен: сначала SSH и панели (прямой доступ к инфраструктуре), потом токены и репозитории (могут дать доступ косвенно), в конце — общие пароли (наименее срочно, но забывать нельзя).

SSH-ключи и доступ на серверы

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

Если у вас есть инвентарь серверов (Ansible hosts, список в Terraform, просто текстовый файл), пройдитесь по всем разом:

#!/usr/bin/env bash
# audit_keys.sh — собрать все ключи с серверов из inventory.txt
while read -r host; do
  echo "== $host =="
  ssh -o BatchMode=yes -o ConnectTimeout=5 "$host" \
    "sudo cat /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys 2>/dev/null"
done < inventory.txt

Для каждого найденного ключа получите fingerprint и сравните с тем, что вы знаете об увольняемом (если ключ выдавали централизованно и записывали владельца — сверка тривиальна, если нет — ищите по комментарию в конце ключа вида user@hostname):

ssh-keygen -lf <(echo "ssh-ed25519 AAAA... dmitry@dmitry-thinkpad")

Если инвентаря нет вообще — идите от того, что точно есть: список серверов из панели хостинг-провайдера (в личном кабинете обычно виден список всех арендованных VPS/выделенных серверов разом), плюс всё, что найдёте в ~/.ssh/config на рабочих машинах команды. Дальше — та же проверка, но руками, хост за хостом.

После того как ключ найден — сразу удалите строку из authorized_keys и проверьте ~/.ssh/authorized_keys2 (легаси-путь, который отдельно читает часть старых конфигураций sshd) и AuthorizedKeysFile в /etc/ssh/sshd_config на нестандартный путь. Если ключи раскатывались автоматикой (Ansible, Puppet, Chef) — правьте источник в репозитории, а не только на сервере: иначе следующий прогон плейбука тихо вернёт ключ обратно. Разбор именно такого случая — когда ручное удаление на сервере не помогло, потому что источник правды в git не поменяли, — в статье про ключ подрядчика в authorized_keys: аудит за час.

Отдельно проверьте sudo-права: если у пользователя был системный аккаунт с sudo, удаление ключа не отзывает саму учётную запись — проверьте /etc/passwd, /etc/sudoers и /etc/sudoers.d/*, при необходимости заблокируйте аккаунт (usermod -L username или usermod -s /usr/sbin/nologin username) и только потом удаляйте.

Если после увольнения есть подозрение, что доступом всё-таки пользовались (а не просто он технически остался открыт), проверьте логи входов по fingerprint найденного ключа за весь период после увольнения:

journalctl -u sshd --since "2026-08-01" | grep -F "SHA256:k9F3..."
# или для старых систем без systemd-журнала на нужную глубину
zgrep -F "Accepted publickey" /var/log/auth.log*.gz

Панели управления, облака и DNS

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

• Панели хостинга/VPS (личный кабинет провайдера, панели вроде aaPanel, cPanel, FastPanel на самих серверах) — если у уволенного была личная учётная запись, удалите её; если он знал общий пароль от аккаунта провайдера или root-панели — смените пароль и, если поддерживается, перевыпустите API-ключи личного кабинета отдельно от смены пароля (они не всегда меняются автоматически).
• DNS-регистратор и зона DNS — доступ сюда даёт возможность перехватить домен или поднять фишинговую копию сайта; проверьте список пользователей аккаунта регистратора и API-токены на управление DNS-записями.
• CDN и облачный провайдер (если используете отдельно от хостинга серверов) — IAM-пользователи, ключи доступа, консольные логины.
• Панель почтового сервиса — если увольняемый администрировал корпоративную почту, проверьте, не остался ли у него доступ к панели управления почтовыми ящиками (это отдельный риск от самого почтового ящика сотрудника, который обычно и так блокируют в первую очередь).
• Платёжные и биллинговые системы — доступ к платёжному шлюзу или биллингу хостинг-провайдера особенно чувствителен: там видны привязанные карты и история транзакций.

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

API-токены, вебхуки и интеграции

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

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

• CI/CD (GitLab CI, GitHub Actions, Jenkins) — personal access token'ы, привязанные к аккаунту уволенного, продолжают работать даже после того, как его убрали из организации, если токен не отозван явно. В GitHub organization: Settings → Personal access tokens → просмотр и отзыв токенов участников (доступно не на всех тарифах); в self-hosted GitLab — админ-панель /admin/users конкретного пользователя.
• Мониторинг и алертинг (Grafana, Zabbix, Uptime Kuma, PagerDuty) — API-ключи для чтения метрик или, что хуже, для управления алертами/эскалацией.
• Облачные API — ключи доступа к S3-совместимому хранилищу, DNS API, API самого хостинг-провайдера, если он выдаётся персонально.
• Мессенджеры и боты — токены Telegram-ботов, вебхуки Slack, интеграции с корпоративным чатом, которые сотрудник поднимал под себя.
• Внешние SaaS с API-доступом — платёжные шлюзы, email-рассылки, аналитика.

Проверить, что токен реально не работает, надёжнее, чем поверить интерфейсу — сделайте тестовый запрос после отзыва:

curl -s -H "Authorization: token ghp_xxx" https://api.github.com/user
# ожидаем 401, если токен отозван

Если токен успел засветиться где-то публично (коммит, лог сборки, публичный gist) — это отдельная и более срочная история, там мало просто отозвать токен, нужно понять масштаб утечки; подробный разбор, что именно нужно отозвать и проверить в такой ситуации, — в статье токен уехал в публичный репозиторий: что отзывать.

Репозитории кода, CI/CD и пакетные реестры

Доступ к репозиторию — это не только «может посмотреть код», а часто ещё и права на пуш в защищённые ветки, управление секретами CI/CD и публикацию пакетов.

• Уберите пользователя из организации/группы на GitHub, GitLab или Bitbucket — не просто из отдельных репозиториев, а из организации целиком, иначе он сохранит доступ к репозиториям, добавленным позже.
• Проверьте SSH-ключи и deploy-ключи, привязанные к его аккаунту в системе контроля версий отдельно от ключей на серверах — это разные списки.
• Проверьте CI/CD-переменные и секреты (GitLab CI/CD Variables, GitHub Actions Secrets) — если увольняемый администрировал пайплайны, он мог видеть или добавлять значения секретов; сами секреты (токены деплоя, пароли БД) стоит ротировать, а не только отозвать доступ к их просмотру.
• Пакетные реестры — если у компании свой Nexus Repository, npm-registry или Docker registry с приватными пакетами, проверьте список пользователей и API-токены публикации там отдельно: это обычно отдельная система авторизации, не связанная с Git.
• SSH-ключ для деплоя (отдельный ключ, которым CI пушит в продакшен или тянет образы) — если он генерировался лично увольняемым и использовался как «общий», его тоже стоит перевыпустить.

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

Идеально, если общих паролей в компании вообще нет — у каждого своя учётная запись в каждом сервисе. В реальности почти всегда есть исключения: root на легаси-сервере, аккаунт в старой панели без поддержки нескольких пользователей, общий логин в сервисе, который стоит на тарифе без ролей.

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

• root/administrator-пароли на серверах и в панелях, где не было персональных учёток.
• Пароль от общего почтового ящика (info@, support@), если он им пользовался.
• Пароли от общих аккаунтов в сервисах без ролевой модели.
• Мастер-пароль от общего менеджера паролей, если такой используется командой (Vaultwarden, Bitwarden, 1Password) — это самый чувствительный случай, потому что за одним мастер-паролем может стоять весь набор секретов компании; после смены не забудьте перевыпустить и все хранившиеся в нём отдельные пароли, которые он мог просматривать, а не только сам мастер-пароль.

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

Как построить offboarding, чтобы не делать это на нервах каждый раз

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

Минимальный офбординг, который реально работает и не требует сложной автоматизации:

1. Единая точка учёта доступов. Заведите один документ или таблицу (на первое время подойдёт обычная Google Sheets или Notion — лишь бы одно место, а не расползание по головам сотрудников) со списком: система → кто имеет доступ → уровень доступа → дата выдачи. Каждый новый доступ добавляется туда в момент выдачи, а не постфактум. Подробнее о том, как формализовать сам процесс выдачи доступа, чтобы потом было что отзывать, — в статье как оформить доступ сотрудников к продакшену.
2. Чек-лист офбординга с ответственным и дедлайном. Не абстрактное «отозвать доступ», а конкретный список пунктов (SSH, панели, токены, репозитории, общие пароли — ровно те шесть категорий из этой статьи) с именем того, кто выполняет каждый пункт, и сроком в часах, а не днях, от момента увольнения.
3. Отзыв доступа в день увольнения, а не постфактум. Дата фактического увольнения и дата отзыва доступа должны совпадать — если это технически не успевают сделать везде разом, порядок должен быть обратным тому, что обычно происходит по умолчанию: сначала блокировка всех известных точек входа, потом уже спокойное разбирательство, что именно человек делал.
4. Периодическая сверка, а не разовая акция. Раз в квартал (или чаще, если команда меняется быстро) прогоняйте тот же аудит, что описан выше, даже без повода — список активных сотрудников против списка реальных доступов на всех системах. Это ловит не только забытые увольнения, но и накопившиеся токены и ключи, которые никто не удосужился почистить вовремя.
5. Ротация секретов по расписанию, а не только по инциденту. Пароли и токены, к которым теоретически мог иметь доступ уволенный (даже если вы уверены, что он ими не пользовался), безопаснее менять по умолчанию, а не оставлять «раз ничего не случилось». Практику регулярной ротации, которая снимает необходимость каждый раз решать это в панике, разобрали в статье ротация секретов и ключей: практика.

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

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