Уволили разработчика в пятницу: что отозвать в первые два часа

MAATRIX

Разговор закончен, разработчик уже не сотрудник компании, а у вас на руках список из десятка систем, к которым у него был доступ, и смутное ощущение, что что-то из этого списка вы точно забудете. Хуже, если дело происходит в пятницу вечером — до понедельника никто не проверит, что на самом деле осталось открытым. Ниже — практический порядок действий на первые два часа: что закрывать в первую очередь, что может подождать до утра понедельника, и как не оказаться в этой ситуации со списком «с нуля» в следующий раз.

Почему это не про доверие, а про гигиену безопасности

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

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

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

Приоритет 1: продакшен-серверы и панели хостинга

Это первое, что закрывается, — прямой доступ к работающей инфраструктуре даёт максимум возможностей за минимум времени, поэтому именно отсюда начинается отсчёт двух часов.

SSH-доступ на каждом сервере, куда у разработчика был вход:

# если ключи именные — удалить конкретную строку
sudo sed -i '/user@fired-dev/d' /home/*/.ssh/authorized_keys

# заблокировать персональную системную учётку
sudo usermod -L username
sudo passwd -l username

# убрать из sudo/wheel, если запись была
sudo deluser username sudo

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

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

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

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

Приоритет 1: репозиторий кода — права на запись и администратора

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

• Удалите из организации целиком на GitHub/GitLab/Bitbucket — не из отдельных репозиториев, а именно из организации. Удаление только из репозитория оставляет доступным личный форк или клон, если он уже был сделан.
• Отзовите personal access tokens и deploy-ключи, выписанные на имя разработчика или использующиеся под его учёткой в CI/CD. Проверьте раздел токенов доступа отдельно от самого членства в организации — токен может пережить удаление аккаунта, если срок его жизни не ограничен.
• Проверьте права администратора репозитория отдельно от прав на запись — если разработчик был мейнтейнером или имел админские права на настройки CI/CD, вебхуков или защиты веток, эти права критичнее обычного доступа на push и должны закрываться в первую очередь.
• Ротация секретов, которые он мог видеть в CI/CD — переменные окружения раннера, ключи облака в GitHub Actions/GitLab CI. Если секрет был доступен пайплайну, к которому у разработчика был доступ, считайте его потенциально скомпрометированным и перевыпустите, а не оставляйте «на всякий случай».
• Registry-токены — Docker Hub, приватный npm/PyPI, container registry — отдельная точка, про которую забывают чаще всего, потому что она не привязана напрямую к Git-хостингу.

Если разработчик настраивал автодеплой вручную, проверьте и сами серверы на предмет отдельного deploy-ключа (~/.ssh/id_deploy и подобные файлы) — он мог существовать в стороне от обычного личного SSH-доступа и остаться незамеченным при первой зачистке.

Приоритет 1: платёжные и финансовые доступы

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

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

• Личный кабинет платёжного провайдера или биллинга облака — если был отдельный логин, отзовите его; если общий — смените пароль и включите двухфакторную аутентификацию, если её ещё не было.
• API-ключи платёжных систем (Stripe, ЮKassa, любой другой шлюз) — отдельно от логина в панель, потому что ключ продолжает работать даже после смены пароля от кабинета.
• Привязанные карты и способы оплаты в панелях хостинга и облака, если разработчик их когда-либо настраивал сам, — проверьте, что карта принадлежит компании, а не оказалась личной картой сотрудника «пока не оформили корпоративную».
• Доступ к бухгалтерским и биллинговым системам, если он был выдан для автоматизации отчётов или интеграций — довольно частый, но редко вспоминаемый в момент увольнения канал.

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

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

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

В маленькой команде это особенно частая ситуация: общий пароль администратора в закреплённом сообщении чата, доступ к менеджеру паролей команды, пароль от Wi-Fi офиса, который заодно даёт доступ к внутренней сети. Подробный разбор того, почему такая модель доступа опасна сама по себе, независимо от увольнений, — в статье «Антипаттерн: общий root-пароль на всю команду»; при увольнении эта же проблема просто проявляется резче и быстрее, чем в спокойное время.

Что делать прямо сейчас:

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

Второй час: мониторинг, SaaS-инструменты команды и физический доступ

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

Системы мониторинга и алертинга (Grafana, Zabbix, Uptime Kuma, PagerDuty и подобные). Прямой угрозы инфраструктуре здесь обычно нет, но доступ даёт понимание вашей архитектуры и уязвимых мест, если попадёт не в те руки, а входящие алерты на телефон бывшего сотрудника — это ещё и утечка операционной информации о состоянии системы в реальном времени.

Сторонние SaaS-инструменты команды. У разработчика почти наверняка есть доступ к сервисам, не связанным напрямую с продакшеном: трекер задач, документация в Notion/Confluence, дизайн-инструменты, аналитика, почтовые рассылки, если он настраивал их сам. Пройдитесь по списку используемых в команде SaaS-сервисов и отзовите или переведите на другого владельца каждый, где он числится участником или, тем более, администратором аккаунта.

Физический доступ, если применимо. Пропуск в офис, ключи от серверной, если инфраструктура частично находится на месте, корпоративное оборудование — ноутбук, токены двухфакторной аутентификации, аппаратные ключи безопасности (YubiKey и подобные). Для распределённой команды на удалёнке этот пункт может свестись к возврату ноутбука и корпоративной SIM-карты, но проверить его всё равно стоит явно, а не пропускать по умолчанию.

Как не собирать чек-лист в панике: готовим его заранее

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

Заведите простой реестр: одна строка на систему, к которой у технических сотрудников обычно есть доступ, — сервер, панель хостинга, репозиторий, платёжный сервис, менеджер паролей, SaaS-инструмент. Для каждой отмечайте, у кого именной доступ, а не общий, и когда он последний раз проверялся. Такой реестр не нужно делать сложным — таблица в git-репозитории или в облачном документе справляется не хуже специализированного инструмента. Подробная методология сборки подобного реестра с нуля, если инфраструктура росла бессистемно и полного списка ещё нет, — в статье «Инфраструктура выросла стихийно: собираем реестр серверов, доменов и доступов».

Дальше — сам процесс, а не только список:

• Именные учётки вместо общих на всех системах, где это технически возможно — увольнение одного человека тогда не требует смены пароля для всей команды.
• Один ответственный за офбординг — не «кто-нибудь разберётся», а конкретный человек, который знает, где лежит реестр, и умеет пройтись по нему за два часа, даже если это происходит не при нём лично.
• Ревизия реестра на регулярной основе — при каждом новом сервисе или сервере список обновляется сразу, иначе к моменту, когда он реально понадобится, в нём не окажется актуальных записей.
• Чек-лист офбординга как отдельный документ, отдельно от общего реестра доступов — конкретная последовательность действий по приоритету, а не абстрактный список систем. По сути, именно такой документ вы держите перед глазами прямо сейчас, если это первое увольнение технического сотрудника в вашей команде.

Более полный общий разбор процедуры отзыва доступов при уходе сотрудника, не только разработчика, включая ревизию логов и подозрительной активности за последние недели перед увольнением, — в статье «Доступы уволенного сотрудника: что отозвать в первые 30 минут»; там же разобрано, что делать в течение дня после того, как первый острый блок уже закрыт.

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