Кому должны принадлежать домен, хостинг и доступы к сайту

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

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

Разделите владение и техническое управление

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

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

Пример: как выглядит реестр доступов для магазина

Условный учебный пример, не кейс REDBE. Производитель запускает интернет-магазин на новой CMS. В проекте участвуют собственник, маркетолог, бухгалтер, специалист по 1С и подрядчик по сайту. Если все аккаунты создать на почту одного разработчика, после смены исполнителя собственнику придётся восстанавливать доступ к домену, оплатам, счетчику и серверу одновременно.

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

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

Минимальный реестр: какие поля в нём нужны

Что передавать вместе с доступами

• Домен: регистратор, владелец, даты продления, DNS-записи и порядок согласования изменений.
• Хостинг: кабинет владельца, тариф и контакты поддержки, расположение файлов и базы, способ получить резервную копию.
• Исходный код: репозиторий и ветка релиза, инструкции запуска/сборки, список внешних библиотек, переменные конфигурации без публикации секретов.
• CMS: отдельная учётная запись администратора заказчика, список ролей, адрес админки и краткая инструкция по контентным операциям.
• Интеграции: какие системы связаны, какие события передаются, кто администрирует ключи, как проверить успешный обмен.
• Резервные копии: что копируется, как часто, где хранится, сколько хранится и как проверить восстановление. Сам файл архива без процедуры восстановления недостаточен; подробнее — в плане защиты и восстановления сайта.

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

Порядок безопасной передачи проекта

1. Составьте перечень. Перечислите домен, DNS, сервер, CMS, репозиторий, аналитику, CRM, почту, оплату, доставку и интеграции. Для магазина добавьте 1С/МойСклад, платёжный кабинет и службу доставки.
2. Определите владельца каждого ресурса. Если актив оформлен на сотрудника или исполнителя, заранее решите, как передать его на компанию согласно правилам сервиса и договору.
3. Создайте именные учётные записи. Не передавайте общий логин, если доступ можно выдать через роль. Ограничьте полномочия сроком и задачей.
4. Проверьте вход и восстановление. Заказчик сам входит под своей учётной записью и получает тестовое письмо/код на свой контакт. Передача ссылки-приглашения не равна проверенному доступу.
5. Проверьте рабочие процессы. Отправьте тестовую форму, убедитесь в доставке в почту или CRM, откройте тестовый заказ, проверьте резервное копирование и получение кода восстановления там, где это возможно.
6. Зафиксируйте изменение прав. Сохраните дату выдачи и отзыва доступа, ответственного и перечень оставшихся сервисных пользователей. После ухода подрядчика отзовите его персональный доступ, не стирая критичные учётные записи сайта.

Чего не стоит требовать от подрядчика без разбора

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

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

Как передать или сменить подрядчика без потери управления

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

Для передачи кода добавьте нового подрядчика в репозиторий, проверьте доступ к релизным веткам и инструкцию установки. Не отправляйте секреты в README и не передавайте production-токены в открытом виде. Для сервера уточните, где лежат файлы и база, какой пользователь выполняет деплой, как обновить конфигурацию и где логируются ошибки. Для обмена с 1С и CRM выясните, отдельная ли сервисная учётная запись используется; если удалить её вместе с аккаунтом прежнего агентства, обмен перестанет работать, хотя «доступы все сменили».

Запросите не только zip-архив сайта, но и проверяемую процедуру: получить свежую копию, восстановить её в тестовом окружении, открыть главную и карточку, отправить тестовую форму и убедиться, что интеграции не уходят на production. Этот процесс связывает передачу с реальной возможностью продолжать работу. Для хранения резервов пригодится отдельный план резервного копирования и тестового восстановления.

Пять красных флагов в управлении доступами

1. Домен продлевает неизвестный человек. У компании нет собственного входа и уведомлений о продлении.
2. Восстановление привязано к личной почте бывшего сотрудника. Формальный логин есть, но вернуть аккаунт бизнес не может.
3. Один пароль используют несколько подрядчиков. Нельзя отозвать одного пользователя и проверить журнал действий.
4. Никто не знает, где интеграционные ключи. Их случайный отзыв может остановить оплату, доставку или передачу заказа в CRM.
5. Есть резервная копия, но никто не пробовал её восстановить. Архив может быть неполным, повреждённым или не включать базу и загруженные файлы.

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

«Я на себя беру всю ответственность и компетенции, отвечаю полностью за проект и буду с ними общаться».

Вывод

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