Сотрудник недоступен неделю: как законно забрать доступы к рабочим системам

MAATRIX

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

Чем это отличается от истории с уволившимся сотрудником

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

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

Кому по сути принадлежит доступ, созданный для рабочих задач

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

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

Практически полезное разделение — не про право, а про то, где физически лежит доступ:

• Доступ на инфраструктуре, которую администрирует или оплачивает компания — аккаунт в панели хостинга на корпоративный email и карту; организация в GitHub/GitLab, где компания владеет workspace; сервер, за аренду которого выставляется счёт компании. Здесь у компании почти всегда есть административный канал получить доступ независимо от конкретного сотрудника — просто потому, что компания и есть клиент провайдера.
• Доступ на личном аккаунте сотрудника, используемом для работы — личная почта, к которой привязан домен вместо корпоративной; личный телефон с 2FA; личный аккаунт в облаке, где сотрудник когда-то завёл ресурс «по-быстрому». Здесь вы зависите от инфраструктуры человека, а не компании, и легальных путей получить доступ без него заметно меньше — остаётся либо ждать, либо обращаться в поддержку провайдера и доказывать, что компания фактически владеет ресурсом.

Первый шаг: проверьте, не готовились ли к этому заранее

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

Стоит также проверить менее очевидные, но не менее полезные вещи:

• Есть ли в организации, а не у конкретного человека, роль администратора или владельца. Во многих корпоративных инструментах это разделено: аккаунт конкретного сотрудника и учётная запись-владелец организации в целом (organization owner в GitHub/GitLab, super admin в Google Workspace, root-аккаунт в AWS/GCP отдельно от IAM-пользователей). Если такая роль настроена и доступна кому-то ещё, личный доступ недоступного сотрудника вообще не нужен.
• Есть ли корпоративный менеджер паролей с общими сейфами. Если пароли хранились в общем сейфе, у администратора менеджера паролей почти всегда есть функция восстановления или сброса доступа для конкретного пользователя, даже если именно этот пароль сотрудник не расшаривал заранее вручную.
• Есть ли зафиксированная документация инфраструктуры. Паспорт сервера, список того, что где лежит. Если да, вы сразу знаете, куда идти, вместо того чтобы тратить время на выяснение, где вообще искать нужный доступ.

Если аварийного доступа не готовили — восстановление через официальные каналы

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

Хостинг и облачные провайдеры. Почти у всех есть процедура восстановления доступа к аккаунту через поддержку. Что обычно требуется для подтверждения:

• данные оплаты — номер счёта, последние цифры карты, история платежей (провайдер видит, что аккаунт оплачивался с корпоративной карты или счёта компании);
• email, на который зарегистрирован аккаунт, если это корпоративный адрес, — доступ к такому ящику у компании обычно есть независимо от сотрудника, через администратора почтового домена;
• реквизиты компании, указанные при регистрации (юрлицо, ИНН или аналог, адрес);
• иногда — переписку с поддержкой от имени того же аккаунта в прошлом, как подтверждение истории владения.

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

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

Сервер, к которому нет доступа вообще ни через какую панель. Если нужен вход именно в сам сервер, а не в панель управления над ним, у большинства хостинг- и VPS-провайдеров есть режим восстановления (rescue или recovery mode) — сервер загружается с отдельного образа, диск монтируется, и проблему можно исправить без знания текущего пароля или ключа:

# Типичная последовательность в rescue-режиме
# (точные шаги зависят от провайдера)

mount /dev/sda1 /mnt
chroot /mnt

# Добавить свой SSH-ключ вместо утерянного
mkdir -p /root/.ssh
echo "ssh-ed25519 AAAA... your_new_key" >> /root/.ssh/authorized_keys
chmod 700 /root/.ssh && chmod 600 /root/.ssh/authorized_keys

# Либо сбросить пароль root напрямую
passwd root

exit
umount /mnt
# после этого — обычная перезагрузка сервера

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

Практический чек-лист по типам систем

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

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

Когда сотрудник снова на связи

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

• Расскажите сами и сразу, как только человек снова на связи, — не ждите, пока он сам заметит следы входа. «Пока ты был недоступен трое суток, нужно было продлить домен, мы вошли через поддержку регистратора, вот что именно делали» звучит совершенно иначе, чем когда сотрудник сам находит чужую активность в логах.
• Зафиксируйте, что было сделано, кем и зачем — по той же логике, что протокол вскрытия аварийного доступа: не для поиска виноватых, а чтобы у всех была одна картина произошедшего, а не версия по памяти каждого.
• Не меняйте автоматически все его пароли «на всякий случай» без объяснения. Здесь человек продолжает работать, и тотальная ротация без причины воспринимается как недоверие. Меняйте только то, что реально было раскрыто третьим лицам — например, если пароль пришлось передать в поддержку.
• Спросите, что помогло бы в следующий раз. Сотрудник, который сам пережил ситуацию «меня трое суток не могли найти, а домен чуть не отвалился», обычно становится самым мотивированным сторонником того, чтобы в следующий раз всё было готово заранее.

Почему стоит готовиться к этому заранее — и это не история про увольнения

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

Именно поэтому подготовка, описанная в статье «Bus factor: что будет с бизнесом, если единственный админ завтра пропадёт», стоит того, чтобы заняться ей не «когда-нибудь», а в ближайшее время. Час на инвентаризацию ключевых доступов и настройку организационных ролей — owner в GitHub, super admin в Google Workspace, корпоративный, а не личный email при регистрации домена — избавляет от необходимости в следующий раз доказывать поддержке регистратора, что вы действительно владелец бизнеса, а не человек, пытающийся перехватить чужой домен.

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