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

Почему возникает оставшийся доступ

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

Основатель даёт доступ к репозиторию на GitHub, чтобы подрядчик исправил одну ошибку. Тимлид добавляет его в Slack во время запуска. Кто‑то даёт доступ к хостингу, документам, аналитике или трекингу ошибок, потому что нужно быстро двинуть работу. Контракт заканчивается, счёт оплачен, и никто не проходит заново по всем инструментам, к которым обращался этот человек.

Этот разрыв обходится дороже, чем многие команды ожидают. Забытая лицензия продолжает выставлять счета каждый месяц. Старый API‑токен всё ещё работает в скрипте, о котором никто не помнит. Подрядчик, которому давали права админа в экстренной ситуации, может сохранить их через полгода. Чаще всего ничего драматичного не происходит, но риск остаётся открытым всё это время.

Увольнение сотрудников обычно проходит чище, потому что компании выстраивают процесс вокруг него. HR ставит дату ухода, IT отключает аккаунты, менеджеры собирают устройства, а бухгалтерия закрывает финансовые вопросы. Подрядчики часто остаются вне этой системы. Они используют личную почту, свои ноутбуки и клиентские аккаунты, которые никогда не привязывали к единому поставщику идентификации. Даже аккуратные команды получают путаницу.

Малые компании чувствуют это сильнее, чем крупные. Они действуют быстро, выдают доступ на ходу и полагаются на доверие. Это работает, пока кто‑то не задаёт простой вопрос: какие логины получил этот человек и кто сейчас владеет этими аккаунтами?

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

Что собрать до последнего дня

Начните с простого инвентаря. Если пропустить этот шаг, доступ выживет в местах, о которых никто не вспомнит до следующего месяца.

Задайте один вопрос первым: где этот человек входил, загружал файлы, утверждал изменения или платил за что‑то? Запишите все системы, к которым он имел доступ, даже если он казался временным. Обычно это репозитории кода, CI/CD, облачные аккаунты, серверы, менеджеры паролей, чат, почта, документы, инструменты управления проектами, аналитика, саппорт‑инструменты, порталы биллинга, домены и аккаунты магазинов приложений. Малые команды также забывают странные вещи: DNS, трекинг ошибок, формы, AI‑сервисы и общие автоматизации.

Одна только таблица недостаточна. Каждая система нуждается в одном назначенном владельце внутри компании. Если у инструмента нет владельца, никто не будет отзывать доступ, ротировать секреты или проверять, не остались ли там данные компании.

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

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

Для маленькой команды одной простой таблицы обычно достаточно. Используйте пять столбцов: система, текущий уровень доступа, внутренний владелец, дата отключения и нужно ли что‑то переносить. Эта одна страница предотвращает множество неожиданных ошибок.

Порядок отзыва доступа, который работает

Порядок имеет значение.

Если отобрать доступ слишком рано, подрядчик не сможет завершить передачу. Если ждать слишком долго, старые логины, токены и привязки к платежам останутся активны после окончания работы.

Чистый поток выглядит так:

1. Прекратить новую работу и завершить передачу.
2. Передать права собственности на всё, что подрядчик создал или контролировал.
3. Поменять общие пароли, секреты и токены.
4. Отключить аккаунты и активные сессии.
5. Протестировать каждый старый путь доступа и закрыть связи с биллингом.

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

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

После этого смените всё, что было общим. Измените каждый пароль, который знали несколько человек. Замените API‑ключи, SSH‑ключи, секреты CI, webhook‑секреты, VPN‑учётки и сервис‑аккаунты, к которым подрядчик мог получить копию.

Теперь удалите доступ одним заходом. Отозвите аккаунты на хостах кода, в облачных консолях, трекерах задач, чатах, почте, хранилищах файлов, менеджерах паролей и админ‑панелях в один и тот же день. Выйдите из активных сессий, отзовите персональные токены доступа и удалите доверенные устройства там, где это возможно.

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

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

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

Код, CI/CD и секреты

Доступ к коду часто остаётся дольше всего. Подрядчик может потерять доступ к чату в первый день, но забытый deploy‑токен или старый SSH‑ключ всё ещё будут открывать дверь недели спустя.

Начните с хоста репозиториев. Удалите человека из организации, команд и проектов на GitHub, GitLab или Bitbucket. Затем проверьте побочные двери: машинные аккаунты, общие учётки, персональные токены доступа и сохранённые Git‑учётные данные на билд‑агентах.

Рассматривайте CI/CD как отдельную систему. Пайплайны могут продолжать деплоить код долгие после удаления пользователя, если deploy‑токены, доступ раннеров, креды в регистри пакетов или секреты автоматизации релизов всё ещё работают.

Быстрый обзор должен покрыть членство в репозиториях, доступ команд, экстренные роли админа, deploy‑токены, креды регистров пакетов и переменные пайплайнов, к которым мог иметь доступ подрядчик. Поменяйте SSH‑ключи, API‑ключи, секреты сервис‑аккаунтов и ключи подписи, связанные с их работой. Проверьте правила защиты веток и CODEOWNERS, чтобы утверждения не зависели от бывшего подрядчика.

Не забывайте неформальные части доставки. Команды теряют процессы релиза, потому что кто‑то хранил скрипт деплоя в приватном gist, папке на ноутбуке или в личных заметках. Перенесите эти скрипты, заметки по релизам и инструкции по сборке в хранилище, принадлежащее компании, до смены доступа.

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

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