Сотрудник увольняется в пятницу, а в понедельник выясняется, что пароль от хостинга знает только он, доступ к Tilda сохранён в его личном браузере, а токен Telegram-бота вообще нигде не записан. Передача доступов при увольнении - это не строчка в трудовом договоре, а отдельная процедура, которую нужно запускать в первый же день, пока человек ещё в офисе и помнит, что где лежит. За годы работы с чужими проектами я регулярно вижу одну и ту же картину: доступы годами копились в голове одного разработчика или маркетолога, а после его ухода владелец бизнеса неделями восстанавливает пароли через почту для восстановления, которая тоже принадлежит уволенному.
Что сделать в первые два часа после новости об увольнении
Если расставание конфликтное, время критично: доступ к рабочим системам стоит начать закрывать до того, как разговор об увольнении официально закончится, а не после того, как человек уже забрал трудовую книжку. В первую очередь меняю или отзываю:
- пароль от хостинга и панели управления (ISPmanager, cPanel, личный кабинет Timeweb или Beget)
- SSH-ключи и API-токены, привязанные к серверу
- пароль от регистратора домена и почту, на которую он зарегистрирован
- ключи эквайринга в T‑Bank или ЮKassa, если сотрудник имел доступ к личному кабинету банка
- пароль от корпоративной почты, к которой привязаны формы восстановления остальных сервисов
Почта для восстановления - самое узкое место. Если она осталась у уволенного, он в теории может откатить смену пароля в любом сервисе, где эта почта указана как контактная. Поэтому смена пароля от почты идёт одним из первых шагов, а не последним.
Аудит доступов: где искать то, о чём все забыли
После экстренных мер начинается менее очевидная часть: нужно понять, куда вообще у человека был доступ. На практике список почти никогда не совпадает с тем, что записано в должностной инструкции. Проверяю:
- список пользователей в GitHub или GitLab организации и права коллабораторов на конкретных репозиториях
- пользователей DNS-панели и панели CDN, если сайт стоит за Cloudflare
- список менеджеров в CRM и их роли
- расшаренные папки в Google Диске или Яндекс.Диске, куда мог попасть экспорт клиентской базы
- интеграции через OAuth, подключённые к личному аккаунту сотрудника, а не к корпоративному
Если в компании нет единого менеджера паролей уровня Bitwarden или 1Password, аудит доступов растягивается на недели: приходится идти по каждому сервису отдельно и вспоминать, заводил ли его вообще уволившийся сотрудник или это было ещё до него.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Смена паролей и токенов по системам: от Tilda до эквайринга
Под разные системы нужен разный подход, потому что где-то достаточно сменить пароль, а где-то придётся перевыпускать ключи целиком.
| Система | Что менять | На что обратить внимание |
|---|---|---|
| Tilda | пароль аккаунта, права на проект, доступ к кастомным JS/CSS в футере | если скрипты подключались через сторонний CDN на личном аккаунте разработчика, после смены пароля сайт может перестать работать корректно |
| WordPress + WooCommerce | пароль администратора, FTP/SFTP, ключи T‑Bank или ЮKassa в настройках оплаты | ключи эквайринга часто видны в базе в открытом виде, их лучше перевыпустить в личном кабинете банка, а не просто сменить пароль от админки |
| Интеграция с СДЭК | API-логин и пароль, привязка к личному кабинету | если кабинет СДЭК был оформлен на почту сотрудника, перевыпуск ключей может занять 1-2 рабочих дня на стороне службы поддержки |
| Домен и DNS | пароль регистратора, email для восстановления | если домен зарегистрирован на личные данные сотрудника, это отдельный юридический вопрос, который решается быстрее, пока человек ещё готов к диалогу |
| CRM (Bitrix24, amoCRM) | пароль, роль пользователя, права на выгрузку | аккаунт лучше не удалять сразу, а сначала выгрузить историю переписки и сделки, привязанные к менеджеру |
Отдельно про эквайринг: смена пароля от админки WooCommerce не отзывает ключи T‑Bank, потому что они хранятся как отдельная сущность в личном кабинете банка. Если сотрудник настраивал интеграцию сам, у него могли остаться доступы к тестовому и боевому окружению одновременно, и про тестовое обычно забывают.
Боты, n8n и автоматизации: доступы, о которых вспоминают последними
Телеграм-бот на aiogram выглядит как мелочь, но токен бота даёт полный контроль: возможность читать сообщения, менять команды, подключать вебхуки на чужой сервер. Токен выдаётся через BotFather и привязан к аккаунту того, кто создавал бота, поэтому регенерировать его через команду /revoke может только владелец этого Telegram-аккаунта. Если бот делался на личный номер сотрудника, а не на корпоративный, это отдельная проблема, которую проще предотвратить заранее, чем решать в день увольнения.
С n8n похожая история, только масштабнее. В самостоятельно развёрнутом инстансе n8n хранятся кредлы всех подключённых сервисов сразу: почта, CRM, банковские API, Google Таблицы. Если сотрудник был единственным администратором панели, после его ухода нужно проверить пароль от самой панели n8n, ключ шифрования кредлов и все OAuth-подключения, сделанные через его личные облачные аккаунты. Такие цепочки офбординга я обычно собираю в виде отдельного сценария, чтобы отзыв доступов при увольнении не требовал ручного обхода десятка сервисов, и настраиваю это как часть автоматизации бизнес-процессов под конкретный стек компании.
База данных бота или сервера - ещё одна точка, о которой забывают. Доступ к Postgres или SQLite с клиентскими данными часто настроен через тот же SSH-ключ, что и доступ к серверу, поэтому отзыв одного не отменяет второй автоматически.
Как выстроить регламент, чтобы не тушить пожар каждый раз
После третьего подобного увольнения в проекте владельцы обычно решают один раз навести порядок вместо того, чтобы каждый раз собирать список доступов по памяти. Практика, которая реально работает:
- единый менеджер паролей с ролями и логом действий, а не общий файл в облаке
- реестр доступов: система, логин, кто владелец, дата последней смены пароля
- правило заводить критичные сервисы на корпоративную почту, а не на личный номер телефона сотрудника
- ежеквартальная сверка списка пользователей во всех системах с текущим штатом
Для проектов без своего IT-отдела такой регламент проще один раз собрать вместе с подрядчиком, который потом же держит техподдержку и видит все системы целиком, а не разбирается в них заново при каждом увольнении.
Чтобы сайт работал без сбоев
Техподдержка
от 15 000 ₽/мес
Подробнее →Частые вопросы
Что делать, если бывший сотрудник не отдаёт пароли?
Отзывать доступ на уровне инфраструктуры, а не ждать паролей от него. Служба поддержки хостинга и регистратора доменов меняет владельца аккаунта по заявлению и подтверждению оплаты без участия прежнего пользователя, банк перевыпускает ключи эквайринга по запросу владельца юрлица, а Telegram-бота проще пересоздать заново на корпоративный аккаунт, чем добиваться передачи токена.
Нужно ли менять токен Telegram-бота, если увольняется разработчик, который его создавал?
Да, если токен создавался на личный аккаунт сотрудника. Токен даёт полный контроль над ботом, поэтому его стоит регенерировать через BotFather командой /revoke, обновить в коде и переразвернуть бота, даже если явных признаков конфликта нет.
Сколько времени должна занимать полная передача доступов при увольнении?
Критичные системы, хостинг, домен, эквайринг, я закрываю в первые пару часов. Полный аудит остальных доступов, включая CRM, интеграции и облачные папки, обычно укладывается в 1-3 рабочих дня и должен завершиться до того, как закончится двухнедельная отработка сотрудника.
Кто должен отвечать за передачу доступов, если в компании нет своего IT-отдела?
Один конкретный человек, а не «все понемногу». Это может быть владелец бизнеса или подрядчик на техподдержке, у которого уже есть единый реестр доступов и менеджер паролей. Размытая ответственность - главная причина, по которой доступы теряются именно в момент увольнения, когда счёт идёт на часы.