Как передавать доступы к домену, хостингу и сервисам
Как передать разработчику нужные права, сохранить контроль над аккаунтами и проверить доступы после запуска сайта. Практический порядок для заказчика.
Передавать доступы к сайту лучше через отдельные учётные записи с нужными правами. Основной аккаунт, восстановление входа и управление оплатой должны оставаться под контролем заказчика. Если сервис не поддерживает приглашение исполнителя, способ временного доступа нужно согласовать отдельно, а после работы пересмотреть его.
Не собирайте все пароли в брифе или общей переписке. На первом обсуждении достаточно списка сервисов и задач. Разработчику для оценки структуры сайта не нужен полный доступ к домену, почте и платёжным настройкам компании.
1. Составьте список аккаунтов и владельцев
У сайта обычно несколько независимых точек управления. Домен отвечает за адрес, хостинг — за размещение, система управления — за страницы. Отдельно могут существовать почта, аналитика, CRM и сервис отправки уведомлений. Доступ к одному кабинету не означает доступ ко всем остальным.
Соберите реестр без самих секретов. Для каждого сервиса укажите адрес входа, ответственного, почту восстановления, дату продления и способ оплаты. Отметьте, кто сейчас может приглашать пользователей и менять настройки. Если это бывший сотрудник или предыдущий подрядчик, выясните порядок передачи до начала работ.
Проверьте не только возможность войти, но и возможность восстановить вход. Аккаунт с неизвестной почтой восстановления остаётся зависимым от её владельца. Договоритесь, кто внутри компании хранит резервные коды и кто заменит ответственного в отпуске. Эти сведения нужны в закрытой инструкции, а не в публичном документе проекта.
Новые сервисы разумно регистрировать на реквизиты и рабочие контакты заказчика, когда правила сервиса это позволяют. Оформление домена и фактические права в кабинете проверьте отдельно: знакомый логин ещё не подтверждает, что все сведения о владельце актуальны.
2. Выдайте права под конкретную работу
Начните с вопроса «что исполнитель должен сделать». Для добавления текстов нужны одни права, для настройки размещения — другие. Не выдавайте максимальную роль только потому, что так быстрее заполнить приглашение.
Практический порядок выглядит так:
- разработчик перечисляет операции и нужные сервисы;
- заказчик или администратор создаёт отдельный доступ;
- стороны проверяют, что разрешений хватает для работы;
- дату пересмотра или отзыва доступа фиксируют вместе с этапом.
Названия ролей различаются, поэтому уточняйте их возможности в самом сервисе. «Редактор» может менять содержание, но не настройки публикации; другой продукт использует это название иначе. Важна не надпись в меню, а перечень доступных действий.
Если предстоит менять доменные настройки, заранее отметьте связанные сервисы, включая рабочую почту. Обсудите время изменений и ответственного за проверку результата. Полный доступ ко всему аккаунту компании не должен становиться автоматическим условием небольшой правки сайта.
3. Согласуйте способ передачи и восстановления
Используйте уникальные пароли и менеджер паролей. CISA рекомендует такие инструменты для создания и хранения паролей, а многофакторную аутентификацию — как дополнительный уровень защиты входа. Это снижает отдельные риски, но не делает передачу доступа безусловно безопасной.
Когда сервис поддерживает приглашения, отправьте приглашение на согласованный адрес исполнителя. Когда приходится передавать секрет, выберите защищённый способ с ограничением доступа и возможностью отзыва. Проверьте получателя до отправки. Не оставляйте пароли в задачах, скриншотах кабинета и документах, доступных всем участникам.
Не передавайте контроль над восстановлением основного аккаунта вместе с рабочим доступом. Резервные коды второго фактора храните отдельно от общедоступных материалов проекта. Если требуется подтверждение владельца, заранее договоритесь о времени совместной операции, а не отключайте защиту на весь период разработки.
Правила взаимодействия и границы работ стоит закрепить до старта. Общие условия работы помогают подготовиться к обсуждению, но конкретный набор доступов зависит от вашего проекта и возможностей выбранных сервисов.
4. Закройте передачу проверкой после запуска
После завершения этапа заказчик должен самостоятельно войти в основные кабинеты и найти нужные настройки. Попросите короткую инструкцию: где менять страницы, где продлевать услуги, где смотреть заявки и кому сообщать о проблеме.
Сверьте реестр с фактическим состоянием. Отзовите ненужные временные приглашения, пересмотрите права оставшихся пользователей. Если общий пароль передавался, согласуйте его замену и обновление связанных настроек: необдуманная смена может отключить работающую интеграцию.
Зафиксируйте результат передачи письменно: какие аккаунты проверены, какие доступы сохранены для поддержки и какие вопросы остались. Сам файл с инструкцией не должен содержать открытые секреты. Для поддержки оставляют согласованные рабочие права, а не бессрочное владение всеми аккаунтами.
Этот шаг входит в общий порядок работы над проектом. Чтобы спланировать старт, достаточно описать текущие сервисы и предстоящие задачи. Пароли для первого обращения не нужны.