Админ ушёл со всеми паролями: план возврата контроля

MAATRIX

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

Сначала — трезво оцените периметр

Прежде чем куда-то звонить, за 30–60 минут соберите картину: что вообще есть и где заканчивается ваш реальный контроль.

Пройдитесь по чек-листу:

• Домен. У какого регистратора он куплен, на чей email и чью компанию оформлена регистрация. Посмотрите whois (whois vashdomen.ru или сайт регистратора) — там виден регистратор, даже если админпанель недоступна.
• DNS. Кто хостит зону — тот же регистратор или отдельный DNS-провайдер (Cloudflare, PowerDNS и т.п.). Проверьте NS-записи: dig NS vashdomen.ru +short.
• Хостинг/облако. У какого провайдера арендован сервер, на какой email зарегистрирован аккаунт, привязана ли к нему банковская карта компании (это сильно облегчает восстановление — провайдеры охотно верят платёжным данным).
• Сервер. Доступен ли он ещё по SSH хоть с каким-то ключом или паролем, у кого ещё они могли остаться (бэкап-система, CI/CD, документация в закрытом Confluence).
• Почта и SaaS-аккаунты, завязанные на тот же email, что и хостинг/регистратор — если ушедший админ был единственным владельцем корпоративной почты, это отдельная и более быстрая проблема, которую тоже стоит решить в первую очередь: без доступа к почте вы не пройдёте верификацию «письмо на email владельца» ни у хостера, ни у регистратора.

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

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

Восстановление доступа к хостинг-аккаунту

Здесь всё зависит от того, кто юридически является владельцем аккаунта — компания или лично ушедший сотрудник.

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

1. Напишите в поддержку хостинг-провайдера с официального email компании, а не с личной почты. Укажите ID аккаунта, приложите последние счета/квитанции об оплате как подтверждение, что аккаунт ваш.
2. Попросите сброс пароля и отвязку email ушедшего сотрудника от аккаунта — на email, который контролирует компания.
3. Будьте готовы пройти верификацию: скан паспорта директора, реквизиты юрлица, иногда — фото карты, которой оплачивался хостинг (с закрытыми средними цифрами и CVV). Это нормальная антифрод-проверка, а не придирка.
4. Если у провайдера настроена 2FA на телефон ушедшего сотрудника — восстановление обычно идёт через тот же тикет: подтверждение личности заменяет второй фактор.

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

Через поддержку крупных провайдеров это решается быстрее, чем кажется — обычно 1–3 рабочих дня при полном комплекте документов. У небольших хостеров с одним оператором в чате может уйти больше времени — закладывайте это в план.

Восстановление доступа к регистратору домена

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

Порядок действий:

1. Определите регистратора через whois, если ещё не сделали это на первом шаге.
2. Найдите контактный email домена. В whois часто виден замаскированный контакт (privacy protection), но у самого регистратора в личном кабинете правильный email всегда есть в профиле — вопрос в том, у кого есть вход в этот кабинет.
3. Обратитесь в поддержку регистратора с подтверждением, что вы — представитель владельца домена (администратора). Для доменов .ru/.рф это обычно компания-администратор, указанная при регистрации, и подтверждается она документами юрлица, а не личностью того, кто нажимал кнопки в панели.
4. Проверьте срок действия домена и включите автопродление сразу после восстановления доступа — это первое, что стоит сделать, потому что просроченный домен могут перехватить конкуренты или доменные сквоттеры буквально в течение суток после освобождения.
5. Проверьте NS-записи — если они указывают не на вашу текущую DNS-зону, а на что-то незнакомое (например, оставшееся от давнего подрядчика), исправьте на актуальные. Похожий случай разобран в статье «У регистратора остались NS-записи прошлого подрядчика» — там же показано, как такие «забытые» записи превращаются в реальный риск угона поддомена.

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

Если панель хостинга доступна: сброс паролей без физического визита

Хорошая новость: если вы восстановили доступ к личному кабинету хостинг-провайдера (шаг выше), для смены root-пароля на сервере физический доступ почти никогда не нужен — у большинства VPS/выделенных серверов есть встроенная консоль.

Для VPS (виртуальный сервер на KVM/Xen/Hyper-V):

1. Зайдите в панель провайдера → раздел управления сервером → VNC/serial-консоль (часто называется «Консоль», «KVM Console» или «Screen»).
2. Откройте консоль — вы увидите экран сервера так, будто сидите перед ним физически, даже если SSH недоступен.
3. Загрузитесь в single-user mode или через recovery-образ, который обычно тоже доступен из панели («Rescue mode», «Recovery ISO»).
4. Смонтируйте корневой раздел и сбросьте пароль root:

# из rescue-окружения, когда основной диск примонтирован в /mnt
chroot /mnt
passwd root
# ввести новый пароль дважды
exit
umount /mnt
reboot

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

Подробный пошаговый разбор именно этой процедуры с частными случаями для разных панелей — в статье «Сброс пароля root на VPS».

Для выделенного сервера (bare metal) процедура почти та же, но консоль обычно называется IPMI или iDRAC/iLO в зависимости от производителя железа, и доступ к ней тоже выдаётся через панель провайдера — отдельный логин/пароль на IPMI-интерфейс, который можно сбросить через ту же поддержку, что и панель.

Если на сервере остались рабочие SSH-ключи (ключ CI/CD-системы, деплой-ключ или ключ второго администратора, о котором все забыли) — это самый быстрый путь: зайдите под ним и добавьте свой ключ в ~/.ssh/authorized_keys, не трогая пароли вообще. Иногда «единственный доступ» на самом деле не единственный — просто про запасной ключ никто не вспомнил в панике первого часа. Стоит проверить last, lastlog и содержимое authorized_keys у всех пользователей, прежде чем сразу переходить к rescue-режиму.

Если и панели хостинга нет: работа только через провайдера

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

Что можно и нужно делать:

• Открыть тикет с подтверждением владения аккаунтом — так же, как в разделе про восстановление хостинг-аккаунта: счета, договор, реквизиты компании, привязанная карта.
• Попросить провайдера сменить контактный email и пароль от панели после проверки. Большинство провайдеров технически может это сделать без вашего участия в консоли сервера — это их аккаунт, они управляют доступом на своей стороне.
• Не пытаться получить доступ в обход провайдера. Попытки самостоятельно «восстановить» пароль через уязвимости, брутфорс панели или обращение к третьим лицам, предлагающим «взломать за деньги», неэффективны и создают юридические риски, если что-то пойдёт не так на чужой инфраструктуре.
• Если провайдер отказывается верить на слово — эскалируйте выше: просите разговор с руководителем поддержки, ссылайтесь на договор, при необходимости привлекайте юриста компании. У серьёзных провайдеров это отработанная процедура — люди увольняются регулярно, и хостеры об этом знают.

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

После восстановления: меняйте всё, а не только один пароль

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

Сделайте в первый же день:

1. Смените root-пароль ещё раз, уже осознанно, и сразу переключитесь на вход по SSH-ключам, отключив парольную аутентификацию (PasswordAuthentication no в /etc/ssh/sshd_config).
2. Проверьте и почистите authorized_keys у всех пользователей на всех серверах — не только там, где сидел ушедший админ, а на всей инфраструктуре, если у него был доступ шире, чем вы думали.
3. Смените пароли и API-токены во всех системах, куда у него был доступ: панель хостинга, регистратор, DNS-провайдер, CI/CD, облачные хранилища бэкапов, панель мониторинга, VPN.
4. Проверьте cron и systemd-таймеры на сервере — вредоносных изменений скорее всего нет, но и убедиться в этом стоит на всякий случай, особенно если увольнение было конфликтным: crontab -l -u root, systemctl list-timers, ls -la /etc/cron.d/.
5. Проверьте правила firewall и NAT — не появились ли открытые порты или проброшенные наружу сервисы, о которых вы не знаете.
6. Смените 2FA-привязки — если двухфакторная аутентификация к панели хостинга или регистратора была настроена на телефон ушедшего сотрудника, перепривязать её нужно в первую очередь, а не последним пунктом списка.

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

Bus factor: как больше не оказаться в этой точке

«Bus factor» (иногда «truck factor») — число людей, чей внезапный уход останавливает работу системы. Если bus factor вашей инфраструктуры равен единице — вы только что убедились, к чему это приводит, и стоит закрыть эту дыру системно, а не просто «взять на заметку».

Практические меры, которые реально снижают риск:

• Учётная запись хостинга и регистратора всегда оформлена на компанию, а не на личный email конкретного человека, даже если этот человек — единственный технарь в команде. Email для регистрации — общий адрес вида admin@company.ru, доступ к которому есть минимум у двух человек (например, у технического и у административного руководителя).
• Второй администраторский аккаунт существует всегда, даже если им никто не пользуется в обычной работе. Второй набор SSH-ключей, второй логин в панели хостинга у другого человека — руководителя, партнёра, доверенного подрядчика.
• Пароли и ключи компании хранятся не в голове одного человека, а в общем корпоративном менеджере паролей (Vaultwarden, 1Password Business, Bitwarden Organizations) с разграничением доступа — не все видят всё, но у ответственных лиц есть аварийный доступ к критичным записям.
• Раздавайте доступ по ролям, а не через передачу root, если в команде больше одного человека — sudo с ограниченными правами для рутинных задач сильно снижает и риск ошибки, и зависимость от одного всемогущего аккаунта. Практика описана в статье «Как раздать доступ команде без выдачи root».
• Документация доступов актуализируется регулярно, а не пишется один раз при найме сотрудника. Простая таблица «система — кто имеет доступ — где хранится пароль/ключ — когда проверено в последний раз» закрывает большую часть риска почти бесплатно.
• Офбординг — формальная процедура с чек-листом, выполняемая в день увольнения: отзыв SSH-ключей, смена паролей от общих сервисов, отвязка 2FA, передача владения доменом и хостингом, если они были на личном аккаунте увольняющегося.

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

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