Привет, я Максим, веб-разработчик. За годы работы с клиентами из самых разных ниш я наблюдаю одну и ту же картину: владелец бизнеса нанимает разработчика — и впадает в ступор на этапе передачи доступов. Одни от страха не дают вообще ничего, а потом удивляются, почему работа стоит неделю. Другие высылают в мессенджер открытым текстом логин и пароль от всего подряд, включая интернет-банк. Обе крайности — плохо. В этой статье я подробно расскажу, какие доступы реально нужны разработчику на каждом этапе, как передать их безопасно и что категорически нельзя делать.
Почему тема доступов — это серьёзно
Сайт — это актив бизнеса. Домен, хостинг, контент, аналитика, рекламные кабинеты — всё это имеет конкретную рыночную стоимость. Если доступы передаются бесконтрольно, вы рискуете:
Потерять контроль над доменом. Если разработчик зарегистрировал домен на свой аккаунт — формально он владелец. При конфликте вернуть домен будет непросто, а иногда — невозможно без судебного разбирательства. Я видел ситуации, когда бизнес терял домен с историей и наработанной репутацией просто потому, что при старте никто не подумал о том, на чей аккаунт он регистрируется.
Лишиться данных аналитики. Если счётчик Яндекс.Метрики привязан к аккаунту подрядчика, при разрыве отношений вы потеряете всю накопленную статистику — а это годы данных о поведении пользователей, настроенные цели, воронки продаж.
Стать жертвой шантажа. К сожалению, случается и такое. Недобросовестный подрядчик, имеющий root-доступ к серверу и контроль над доменом, может потребовать оплату «за передачу» того, что и так принадлежит клиенту.
Получить утечку данных. Если на сайте есть личные кабинеты клиентов, персональные данные, история заказов — неконтролируемый доступ к базе данных создаёт риски утечки и нарушения 152-ФЗ.
Поэтому грамотная передача доступов — это не паранойя и не бюрократия. Это базовая цифровая гигиена, которая защищает ваш бизнес.
Принцип минимальных привилегий
Прежде чем перечислять конкретные доступы, обозначу ключевой принцип: разработчик должен получить минимум прав, необходимых для выполнения текущей задачи. Не больше и не меньше.
Это значит: не нужно давать root-доступ к серверу, если задача — поправить текст на сайте. Не нужно передавать пароль от Яндекс ID, если требуется только доступ к Метрике. Не нужно открывать FTP ко всему серверу, если работа идёт в рамках одной папки.
Каждый доступ — это потенциальный вектор атаки. Чем меньше точек входа — тем безопаснее.
Доступы для разработки нового сайта
Хостинг
Разработчику нужен доступ к серверу, на котором будет размещён сайт. Но способ предоставления доступа зависит от типа хостинга:
Виртуальный хостинг (shared hosting). Создайте отдельный аккаунт FTP/SFTP с доступом только к папке сайта. В панели управления (cPanel, ISPmanager) можно создать дополнительного пользователя с ограниченными правами. Не давайте пароль от основной панели — это даёт доступ ко всем сайтам на аккаунте.
VPS/VDS (виртуальный сервер). Создайте отдельного пользователя SSH с ограниченными правами. Добавьте его в sudoers только для необходимых команд, если это требуется. Не передавайте root-пароль. Если разработчику нужны привилегированные действия (установка пакетов, настройка Nginx) — обсудите конкретный список и настройте sudo для этих команд.
Docker-окружение. Если проект деплоится через Docker — передайте доступ к контейнеру приложения, а не к хост-машине. Это естественная изоляция.
Домен
Домен — самый ценный цифровой актив после самого бизнеса. Подходите к доступу максимально осторожно:
Лучший вариант: дайте разработчику доступ только к DNS-записям, а не к аккаунту регистратора. В reg.ru и других регистраторах можно создать дополнительного пользователя с правами на управление DNS. Либо меняйте DNS-записи самостоятельно по инструкции разработчика — это займёт минуту, но полностью исключит риски.
Категорически нельзя: передавать пароль от аккаунта регистратора. Через этот аккаунт можно перенести домен к другому регистратору, сменить NS-серверы, и вы потеряете контроль.
Отдельный совет: убедитесь, что домен зарегистрирован на вас (физическое или юридическое лицо), а не на подрядчика. Проверьте это прямо сейчас через WHOIS, если сомневаетесь.
Доступ к системе контроля версий
Если разработчик использует Git (GitHub, GitLab, Bitbucket) — создайте репозиторий на аккаунте вашей компании и добавьте разработчика как collaborator с правами push/pull. Не создавайте репозиторий на аккаунте разработчика — иначе при расставании код останется у него.
SSL-сертификат
Для подключения HTTPS разработчику может понадобиться доступ к панели хостинга для установки сертификата. Если используете Let's Encrypt — автоматическое обновление настраивается один раз. Если сертификат платный — устанавливайте через панель хостинга вместе с разработчиком, но не передавайте приватный ключ по незащищённым каналам.
Доступы для доработки существующего сайта
Всё вышеперечисленное плюс:
Админка CMS. Если сайт на WordPress, 1С-Битрикс, MODX или другой CMS — создайте отдельный аккаунт администратора специально для разработчика. Не используйте одну учётную запись на всех. Во-первых, это безопаснее. Во-вторых, по логам можно отследить, кто и когда вносил изменения.
Доступ к базе данных. Если требуется работа с данными напрямую (миграция, оптимизация, исправление ошибок) — создайте отдельного пользователя MySQL/PostgreSQL с правами только на базу конкретного сайта. Не давайте пользователя с правами на все базы сервера.
Резервные копии. Перед тем как дать разработчику доступ к боевому сайту — сделайте полный бэкап: файлы + база данных. Это страховка на случай ошибки. Я всегда прошу клиентов сделать бэкап перед началом моей работы — и сам делаю дополнительный.
Доступы для настройки аналитики и рекламы
Яндекс.Метрика
Добавьте разработчика как пользователя к конкретному счётчику с правами «Редактирование». Это делается в настройках счётчика: «Доступ» → «Добавить пользователя» → указать логин на Яндексе → выбрать уровень доступа. Никогда не передавайте пароль от своего Яндекс ID — через него доступна почта, диск, все сервисы.
Яндекс.Директ
Добавьте разработчика (или маркетолога) как представителя через раздел «Мои клиенты» / «Управление представителями». Можно выбрать уровень прав: «Только просмотр», «Управление кампаниями», «Полный доступ». Для настройки кампаний достаточно «Управление кампаниями».
Яндекс.Вебмастер
Добавьте пользователя через раздел «Права доступа» в панели вебмастера. Можно дать права на просмотр или на делегирование (полное управление). Ваш аккаунт остаётся владельцем сайта.
Google Search Console и Google Analytics
Аналогично — добавьте пользователя через интерфейс управления доступом. В Google Analytics есть гибкая система ролей: просмотр, редактирование, управление пользователями, администратор. Дайте минимально необходимый уровень.
Рекламные кабинеты ВКонтакте
Добавьте администратора или редактора через настройки рекламного кабинета. Доступ к личной странице ВК не нужен и не должен передаваться.
Что категорически нельзя передавать
Я выделяю несколько «красных линий», которые нельзя пересекать ни при каких обстоятельствах:
Пароль от основного Яндекс ID или Google-аккаунта. Через них доступна не только аналитика, но и почта, облачные хранилища, платёжные данные, а иногда — и другие сервисы с авторизацией через этот аккаунт.
Данные банковских карт и платёжных систем. Если разработчик просит привязать карту к сервису — делайте это сами. Никогда не пересылайте реквизиты карты в мессенджерах.
Root-пароль от сервера (без крайней необходимости). Root — это полный контроль: можно удалить все данные, установить вредоносное ПО, перехватить трафик. Создавайте отдельных пользователей.
Пароль от аккаунта регистратора домена. Повторю ещё раз, потому что это самая болезненная ошибка — потеря домена может стоить бизнесу всего.
Доступ к интернет-банку или бухгалтерии. Разработчику сайта они не нужны. Точка.
Как безопасно передавать доступы
Никогда не пересылайте логины и пароли в открытом виде через email или мессенджеры. Сообщения сохраняются в истории, аккаунты взламывают, телефоны теряют. Вот безопасные способы:
Менеджеры паролей с функцией шаринга. 1Password, Bitwarden, LastPass позволяют предоставить доступ к конкретным записям без раскрытия самого пароля. Разработчик видит автозаполнение, но не может скопировать пароль. Это оптимальный вариант для долгосрочного сотрудничества.
Одноразовые ссылки. Сервисы вроде onetimesecret.com позволяют создать ссылку, которая работает только один раз и автоматически уничтожается после прочтения. Хороший вариант для разовой передачи.
Разделение каналов. Логин отправляете в одном мессенджере, пароль — в другом. Или логин — в чате, пароль — голосовым сообщением. Это не идеальная защита, но значительно снижает риск при компрометации одного канала.
SSH-ключи вместо паролей. Для доступа к серверу используйте аутентификацию по SSH-ключам. Разработчик генерирует ключевую пару, передаёт вам публичный ключ — вы добавляете его на сервер. Пароль вообще не фигурирует.
Что делать после окончания работы
Когда проект завершён или сотрудничество с разработчиком прекращается — обязательно выполните ревизию доступов:
Удалите аккаунт разработчика из админки CMS. Отзовите доступы к Яндекс.Метрике, Вебмастеру, Директу. Удалите FTP/SSH-аккаунт с сервера. Смените пароли от панели управления хостингом. Проверьте, нет ли неизвестных вам пользователей в системе. Просмотрите список SSH-ключей на сервере и удалите незнакомые. Проверьте cron-задачи — иногда через них остаются скрытые бэкдоры.
Эту ревизию стоит делать не только при расставании, но и регулярно — хотя бы раз в полгода. За время работы накапливаются устаревшие аккаунты бывших сотрудников, забытые тестовые доступы и прочие потенциальные дыры в безопасности.
Как зафиксировать передачу доступов юридически
Если вы работаете с подрядчиком по договору — включите в него пункт о порядке передачи и возврата доступов. Укажите, что все аккаунты, зарегистрированные в рамках проекта, принадлежат заказчику. Зафиксируйте обязанность подрядчика удалить все копии данных после завершения работ. Пропишите ответственность за нарушение конфиденциальности. Это не гарантия от проблем, но создаёт правовую базу для разрешения споров.
Мой совет
Относитесь к доступам как к ключам от офиса. Вы же не даёте каждому подрядчику мастер-ключ от всего здания — вы выдаёте ключ от конкретного помещения и забираете его после окончания работ. С цифровыми доступами — та же логика. Создавайте отдельные аккаунты, ограничивайте права, отзывайте доступы после завершения. Это занимает пять минут, но может сэкономить месяцы головной боли.