Администратор ушёл и забрал доступы: возвращаем контроль над своей инфраструктурой

MAATRIX

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

Шаг 1: инвентаризация — что вообще есть

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

Соберите картину по категориям, даже если по некоторым пунктам ответ пока «не знаю»:

• Домен(ы). Где зарегистрирован, на какой email и на чьё имя/компанию. Даже без доступа в личный кабинет регистратора это видно через whois: whois vashdomen.ru. Обратите внимание на дату следующей оплаты — если она близко, это горящий приоритет.
• DNS-зона. Кто её обслуживает — тот же регистратор, Cloudflare, отдельный DNS-провайдер. Проверьте NS-записи: dig NS vashdomen.ru +short. Если DNS не совпадает с хостингом, это ещё одна отдельная система для восстановления.
• Хостинг-провайдер(ы). На каком провайдере физически стоит сервер, сайт, почта. Иногда это не один провайдер, а два-три — прод на одном, бэкапы на другом, тестовый стенд на третьем, и про часть из них владелец бизнеса вообще не подозревает.
• Репозитории кода. GitHub, GitLab, Bitbucket — где хранится исходный код продукта. Кто является владельцем организации (organization owner), а не просто участником с правом push.
• CI/CD и связанные сервисы. Пайплайны сборки, реестры контейнеров (Docker Hub, свой registry), системы мониторинга — часто там отдельные логины, не совпадающие с логином от сервера.
• Платёжные и биллинговые аккаунты. Кабинет провайдера с привязанной картой, платёжный шлюз (эквайринг, YooKassa, Stripe), подписки на сторонние сервисы (SaaS), которые оплачивались с карты компании или лично ушедшим сотрудником.
• Почта, завязанная на всё остальное. Если корпоративная почта тоже была под контролем ушедшего человека, это отдельная и более срочная проблема: без доступа к почте вы не пройдёте проверку «письмо на email владельца» ни у хостера, ни у регистратора, ни у платёжного провайдера.

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

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

Шаг 2: официальное восстановление доступа к каждой системе

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

Что обычно принимают провайдеры как подтверждение владения:

Порядок обращения:

1. Пишите в поддержку с официального email компании, а не с личной почты — это сразу поднимает доверие к тикету.
2. Указывайте ID аккаунта, если он известен (виден в старых счетах, в письмах-уведомлениях от провайдера).
3. Прикладывайте весь пакет подтверждений сразу, не дожидаясь, пока попросят — это сокращает переписку в разы.
4. Явно просите два действия: сброс пароля и смену привязанного email на контролируемый компанией адрес (не личный email кого-либо из сотрудников).

У крупных провайдеров это занимает от нескольких часов до 1–3 рабочих дней при полном пакете документов. Подробный разбор именно процедуры восстановления для хостинга и регистратора домена, включая консольный сброс root-пароля через VNC/IPMI, — в статье «Админ ушёл со всеми паролями: план возврата контроля», она дополняет этот материал именно по механике хостинг-провайдера и регистратора.

Шаг 3: возврат контроля над репозиториями кода

Про код часто забывают в панике — кажется, что если сервер жив, продукт работает, а с репозиторием разберёмся потом. Это ошибка: если у вас нет доступа к организации на GitHub/GitLab как владелец, вы не можете внести исправление в критичный баг, откатить деплой или просто убедиться, что исходники вообще совпадают с тем, что крутится на проде.

Что проверить и сделать:

• Кто formально owner организации. На GitHub это Settings → People, роль Owner. Если owner — личный аккаунт ушедшего человека, а не аккаунт компании, это системная проблема независимо от текущего конфликта: организация в буквальном смысле принадлежит не бизнесу.
• Обратитесь в поддержку платформы, если owner недоступен и не отвечает — у GitHub и GitLab есть процедура передачи владения организацией по подтверждению, что вы представляете компанию, оплачивающую подписку (счета за GitHub Enterprise/GitLab Premium — тоже доказательство владения).
• Проверьте локальные копии репозитория у всех, кто когда-либо клонировал код — на серверах CI/CD, на рабочих машинах других разработчиков. Полная актуальная копия репозитория с историей коммитов — это страховка на случай, если облачный доступ восстанавливается долго.
• Смените deploy-ключи и токены доступа, которые CI/CD использует для деплоя на сервер — они могли быть выписаны на аккаунт ушедшего сотрудника и исчезнуть вместе с ним.

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

Шаг 4: платёжные и SaaS-аккаунты

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

Практический порядок:

1. Составьте список активных списаний по банковской выписке компании за последние 2-3 месяца — это быстрее, чем вспоминать по памяти, на какие сервисы вообще была подписка.
2. По каждому найденному сервису — тот же принцип, что и в шаге 2: обращение в поддержку с подтверждением, что платит именно ваша компания.
3. Отдельно проверьте платёжный шлюз (эквайринг, платёжный агрегатор), если через него проходят деньги от клиентов — блокировка доступа к личному кабинету эквайринга может остановить приём платежей бизнесом целиком, это самый чувствительный пункт из всех.
4. Для сервисов, где восстановление через поддержку не удаётся или подписка стоит недорого — иногда проще и быстрее оформить новую подписку на аккаунт компании и перенести настройки заново, чем неделями ждать ответа от поддержки мелкого SaaS-сервиса.

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

Шаг 5: после восстановления — меняем всё, а не один пароль

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

Обязательный чек-лист сразу после получения контроля над каждой системой:

• Пароль от аккаунта/панели — меняется первым, сразу после подтверждения владения провайдером.
• SSH-доступ на сервере — смена root-пароля и, что важнее, полная чистка ~/.ssh/authorized_keys у всех пользователей на всех серверах, а не только там, где заходил ушедший специалист.
• API-токены и ключи интеграций — всё, что выдавалось в панелях хостинга, CI/CD, платёжных сервисов, систем мониторинга. Список редко есть в одном месте — приходится пройтись по каждой панели вручную.
• 2FA-привязки — если двухфакторная аутентификация была привязана к телефону ушедшего человека, перепривязать её нужно в первую очередь: без этого поддержка провайдера может отказать в дальнейших действиях по аккаунту.
• OAuth-приложения и интеграции, которые ушедший специалист мог подключить к рабочим аккаунтам (личный доступ через «Sign in with GitHub», подключённые Zapier/Make-сценарии, боты в Slack/Telegram с широкими правами).
• Пароли от общих сервисов команды, до которых у него был доступ, даже если формально они не считались «его зоной ответственности».

Смена делается сразу, одним заходом по всему списку, а не по мере того, как «вспомнили» — растянутая во времени ротация оставляет окна, в которые старые доступы всё ещё действуют.

Шаг 6: скрытые точки доступа, которые легко пропустить

Смена паролей закрывает очевидное. Проблема в неочевидном: доступ мог быть организован способами, которые не видны в списке «где были пароли».

На что стоит проверить сервер и инфраструктуру отдельно:

# кто и когда заходил на сервер
last -a
lastlog

# все ключи во всех authorized_keys на сервере
find / -name authorized_keys -exec echo "=== {} ===" \; -exec cat {} \; 2>/dev/null

# запланированные задачи — не оставлена ли скрытая точка входа
crontab -l -u root
systemctl list-timers
ls -la /etc/cron.d/

# правила firewall — не появился ли неожиданный проброшенный порт
iptables -L -n -v

Отдельно проверьте:

• SSH-ключи третьих лиц, добавленные ушедшим администратором «для удобства» — подрядчика, фрилансера, знакомого, который когда-то помогал с настройкой. Об этом легко забывают все стороны, а ключ продолжает работать годами.
• Локальные учётные записи пользователей на сервере, отдельные от корневого доступа — иногда для повседневной работы заводится отдельный sudo-пользователь, про которого забывают при смене root-пароля.
• API-ключи в переменных окружения и конфигах — .env-файлы, конфиги CI/CD, секреты в Docker Compose. Их не видно в панелях провайдеров, они лежат прямо в коде или на сервере.
• Webhook-интеграции и боты с широкими правами — телеграм-бот с доступом к серверу через API, вебхук в CI/CD, который триггерит деплой по внешнему запросу.

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

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