Представьте: прежняя команда передала логин от CMS, а домен зарегистрирован на её сотрудника, почта сайта уходит через неизвестный сервис, а публикация зависит от личного аккаунта разработчика. Сайт пока работает, но бизнес не контролирует цепочку, которая его обслуживает.
При смене команды передают не набор паролей, а контроль над ресурсами, процессами и восстановлением. Договорные основания на код и материалы и технический контроль — связанные, но разные вопросы: один не гарантирует автоматически другой.
Сначала составьте карту ресурсов
Начните с перечня: что обеспечивает работу сайта, кто владелец учётной записи, кто оплачивает сервис, куда приходит восстановление доступа и кто может выполнить действие. Для каждого ресурса зафиксируйте не пароль, а ответственного, URL входа, роль нового сотрудника, порядок оплаты и способ восстановления.
Реестр ресурсов храните отдельно от хранилища секретов. В нём указывают, например, «SMTP-провайдер — администратор: компания — восстановление: общий рабочий адрес». Пароли, ключи API, токены и резервные коды размещают только в корпоративном менеджере секретов с ограниченным доступом. Не отправляйте их по электронной почте, не вставляйте в рабочие документы и не коммитьте в репозиторий.
Проверьте по группам:
| Область | Что передать под контроль компании |
|---|---|
| Домен и DNS | Регистратор, администратор домена, срок продления, DNS-зона, DNSSEC, контакты восстановления |
| Хостинг и сервер | Кабинет провайдера, договор и биллинг, серверы, базы, хранилища, доступ ответственных |
| Код и выпуск | Репозиторий Git, ветки, история, CI/CD, build и deploy, окружения, расписание задач |
| Почта и заявки | Почтовый провайдер, отправитель, маршруты форм, CRM, телефония и уведомления |
| Интеграции | 1С, оплаты, доставки, аналитика, карты, внешние API, вебхуки и их владельцы |
| Лицензии и материалы | CMS и модули, домены лицензий, дизайн-исходники, документация, инструкции |
| Восстановление | Бэкапы файлов и базы, место хранения, доступ к копиям, инструкция восстановления |
У домена запросите не только доступ к кабинету, но и подтвердите администратора и актуальность контактного адреса. DNS может обслуживаться отдельно от регистратора. Изменение DNS без понимания записей способно затронуть сайт, почту и проверку сторонних сервисов. Если TLS-сертификат обслуживается отдельно, зафиксируйте адреса и кабинет, где он устанавливается; практическую проверку описывает статья SolverWeb о сроках и обновлении TLS-сертификатов. Для конкретной схемы DNS сверяйтесь с инструкцией своего провайдера; например, Cloudflare описывает настройку авторитетных DNS-серверов. В статье SolverWeb о проверке данных для доменов .RU, .РФ и .SU описан отдельный сценарий идентификации администратора.
Для кода проверьте, что репозиторий принадлежит организации или аккаунту компании, а не личному профилю исполнителя. Git — это не только текущие файлы: история, ветки, настройки сборки, ключи деплоя и инструкции могут понадобиться для выпуска. При передаче GitHub отдельно описывает передачу репозитория и последствия для связанных ресурсов; изучите официальную инструкцию GitHub по передаче репозитория.
Зафиксируйте, как сайт собирается и принимает заявки
Новый подрядчик должен понять, как изменение попадает на рабочий сайт. Запишите, где лежит исходный код, какие команды собирают проект, кто запускает публикацию, какие среды используются и как откатить неудачный выпуск. Отдельно отметьте ручные шаги, планировщик задач, cron, очереди, фоновые процессы и зависимости от конкретного сервера.
Сделайте сквозную проверку на безопасном тестовом обращении: форма принимает данные, уведомление приходит ответственному, запись появляется в CRM, а ответ можно найти в журнале. Проверьте и обратное: что произойдёт, если почтовый сервис или API временно недоступен? Маршрут заявок должен оставаться понятным до отзыва старых доступов. Иначе можно потерять обращение именно в день передачи.
Наличие интеграции в списке ещё не значит, что она действует. Для каждой связи укажите, кто её обслуживает, куда уходит ошибка, как проверить последнюю успешную операцию и где менять настройки. Не переносите ключи в документацию — запишите ссылку на соответствующую запись в корпоративном хранилище секретов.
Передайте доступ через именные аккаунты
Создайте для нового подрядчика отдельные именные учётные записи или пригласите его в существующие сервисы. Для доступа к серверу добавьте его публичный SSH-ключ, а после перехода отзовите ключи прежней команды. Выдавайте минимальную роль, достаточную для работы. Административный доступ оставьте владельцу компании и назначенным ответственным. Включите MFA там, где сервис его поддерживает; резервные коды храните отдельно, с ограниченным кругом доступа.
До отключения прежней команды проверьте, что компания может сама восстановить доступ. Используйте штатный процесс сервиса: запросите тестовое письмо восстановления на адрес компании, проверьте доступ к доменной почте или убедитесь, что второй администратор может сбросить пароль. Не начинайте процедуру сброса без согласования, если она может завершить активные сеансы или изменить данные.
Передавайте секреты через корпоративный менеджер паролей или предусмотренный сервисом безопасный механизм, а не в переписке. Если подрядчику временно нужен повышенный доступ, согласуйте срок и после завершения работ понизьте роль. Документация GitHub отдельно рекомендует хранить чувствительные значения как secrets, а не включать их в код; см. руководство GitHub по секретам в Actions.
Ротация секретов — отдельный управляемый этап
После подтверждения работы нового подрядчика смените пароли и ключи, к которым у прежней команды был доступ: администраторы CMS и хостинга, SSH-ключи, токены CI/CD, API-ключи, SMTP, вебхуки, базы и сторонние кабинеты. Сначала составьте список зависимостей: один ключ может использовать сайт, CRM, фоновые задачи и мониторинг одновременно.
Меняйте секреты по одному контуру, проверяя после каждого шага публикацию, формы, отправку писем и обмены. Если сервис позволяет создать второй ключ, сначала выпустите и проверьте новый, переключите потребителей, затем отзовите старый. Если возможен только мгновенный сброс, заранее согласуйте окно, ответственных и проверочный сценарий. Не храните старые ключи в резервной копии документации как «на всякий случай».
Завершайте передачу только после проверок
Попросите нового подрядчика выполнить контрольный выпуск или безопасную тестовую процедуру и проверить получение заявки. Восстановление файлов и базы выполняйте в изолированной среде: тест не должен отправлять письма клиентам, проводить платежи или запускать обмены с production. Резервная копия, к которой никто не может получить доступ или которую никто не проверял восстановлением, не закрывает риск передачи. Подробнее о проверке копий — в статье SolverWeb «Бэкапы сайта и базы».
Сверьте итоговый список и отключите прежние учётные записи, отзовите ключи и приглашения только после проверки маршрута заявок, публикации, почты и резервного восстановления. Если сервис хранит журнал действий, отключайте аккаунт, сохраняя историю. Уточните у прежнего исполнителя, какие локальные копии данных, экспорты или доступы остались, и согласуйте их удаление в рамках ваших договорённостей.
Короткий чек-лист закрытия передачи:
- домен, DNS, серверы, Git и биллинг доступны ответственным со стороны компании;
- указаны владельцы и рабочие контакты восстановления;
- новый подрядчик вошёл под собственной учётной записью и включил MFA;
- тестовая публикация и маршрут заявки проверены;
- известны лицензии, интеграции, сборка, деплой и зависимости;
- проверен доступ к резервным копиям и пробное восстановление;
- секреты ротированы согласованно, старые доступы отозваны после проверки;
- реестр ресурсов актуален, секреты находятся только в хранилище секретов.
Подробный регламент плановых проверок и границ поддержки можно сверить со статьёй «Техподдержка сайта: что входит». Такой регламент помогает заранее договориться, кто проверяет доступность, сертификат, копии и заявки.
Если вы меняете подрядчика и не знаете, кто контролирует домен, выпуск сайта или интеграции, обсудите передачу проекта с SolverWeb. Можно пройтись по карте ресурсов, проверить маршрут заявок и подготовить порядок смены доступов для конкретной инфраструктуры.
Обсуждение
Поделитесь мнением — первый комментарий задаст тон.