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

Что делать, если IT-подрядчик пропал

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

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

Подрядчик пропал: сначала определите ситуацию

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

Возможны четыре разных сценария:

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

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

Первые действия: не потерять то, что ещё работает

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

До вмешательства соберите:

• договоры, технические задания, акты и приложения;
• счета за домен, хостинг, облачные сервисы и лицензии;
• письма с регистрационными данными и уведомлениями о продлении;
• переписку о передаче доступов и выпуске версий;
• доступные резервные копии, выгрузки и инструкции;
• перечень известных аккаунтов, телефонов и адресов восстановления.

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

Проверьте не только главную страницу. Отправьте тестовую форму, убедитесь, что письмо пришло, проверьте корзину, оплату, личный кабинет и обмен с CRM. Сайт может выглядеть нормально, хотя заявки уже перестали доходить до бизнеса.

Какие активы должны контролироваться компанией

Один пароль от административной панели не даёт контроля над всей системой. DNS направляет запросы к домену, CDN выступает промежуточным сервисом доставки контента, SSL-сертификат защищает соединение, а RDAP и WHOIS показывают справочные данные о регистрации. Каждый уровень может принадлежать отдельному аккаунту.

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

Как найти регистратора и хостинг

Регистратор управляет продлением и делегированием домена. DNS направляет запросы, CDN может принимать трафик перед сайтом, хостинг содержит файлы и среду выполнения, а CMS управляет содержимым. Эти сервисы могут принадлежать разным аккаунтам.

Сначала ищите сведения внутри компании. Полезны поиск по почте по названию домена, выписки банка, счета, бухгалтерские документы, переписка с исполнителем и записи в менеджере паролей. Публичные данные RDAP или WHOIS помогают определить регистратора и статус домена, а DNS-записи — понять, какие сервисы участвуют в его работе.

Определить реальный хостинг по открытому IP удаётся не всегда. Если трафик проходит через CDN, публичный адрес относится к промежуточному сервису, а не к серверу сайта. Кроме того, файлы, база и почта могут находиться у разных поставщиков. Поэтому результаты внешней проверки нужно сопоставлять с договорами и письмами.

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

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

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

1. Верните корпоративную почту. Проверьте администраторов, резервные адреса, номера телефонов, правила пересылки и активные сеансы.
2. Усильте вход. Установите уникальный пароль и многофакторную аутентификацию, сохраните резервные коды в корпоративном хранилище.
3. Проверьте домен. Уточните администратора, регистратора, срок продления, контактные данные и текущие DNS-серверы.
4. Верните DNS, CDN и SSL. Сохраните действующие записи, проверьте пользователей и не меняйте маршрутизацию без подготовленной точки назначения.
5. Получите инфраструктуру. Восстановите законный доступ к хостингу, серверу или облачному проекту через владельца договора и поддержку.
6. Сделайте контрольную копию. Сохраните файлы, базу, пользовательские загрузки, конфигурацию и доступные журналы.
7. Проверьте CMS. Найдите лишних администраторов, неизвестные модули, задания по расписанию и признаки изменения контента.
8. Найдите код и историю. Получите репозиторий, ветки, выпущенные версии, инструкции сборки и развёртывания.
9. Перевыпустите секреты. Обновите API-ключи, SSH-ключи, токены развёртывания, вебхуки и пароли интеграций.
10. Отключите прежние доступы. Делайте это после фиксации состояния и передачи управления ответственным сотрудникам.

Конкретная процедура зависит от сервиса. Один провайдер восстанавливает кабинет через контактную почту, другой запрашивает реквизиты компании или документы владельца. Универсального набора доказательств нет, поэтому нельзя заранее гарантировать результат или срок.

Домен оформлен на подрядчика: что это меняет

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

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

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

Хостинг, резервная копия и исходный код — не одно и то же

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

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

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

Что проверить после возвращения доступа

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

Проверьте, что:

• пароли администраторов заменены на уникальные;
• активные сеансы завершены, а резервные контакты принадлежат компании;
• многофакторная аутентификация включена для критичных кабинетов;
• неизвестные пользователи и выданные им роли удалены;
• SSH-ключи, API-токены и ключи развёртывания перевыпущены;
• в почте нет скрытых переадресаций и правил удаления сообщений;
• журналы входов и изменений сохранены и изучены;
• DNS-записи, SSL и срок регистрации домена проверены;
• независимая резервная копия создана и протестирована;
• формы, заказы, оплаты, CRM и уведомления работают по всей цепочке.

Отдельно настройте мониторинг доступности, ошибок, свободного места, сроков действия домена и сертификата. Если проект критичен для продаж или внутренних операций, техническая поддержка по SLA помогает закрепить время реакции, порядок эскалации и отчётность по инцидентам. При этом регламент поддержки дополняет контроль доступов и копий, а не заменяет его.

Как передать проект новой команде

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

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

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