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

Почему доступы нельзя передавать без разбора

Когда нужно срочно поправить сайт, перенести проект или настроить VPS, часто проще отправить специалисту все логины и пароли сразу. Но это не самый безопасный вариант.

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

Если передать лишние доступы, могут возникнуть риски:

• случайное удаление важных файлов;

• потеря контроля над доменом;

• доступ к почтовым ящикам компании;

• изменение DNS-записей;

• отключение сайта или сервера;

• сложности после смены подрядчика;

• невозможность понять, кто и что изменил.

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

Какие доступы бывают у сайта

У сайта может быть несколько уровней доступа. Владелец часто воспринимает их как один набор паролей, но на практике это разные зоны управления.

Разработчику не всегда нужны все эти доступы. Например, для правки текста или блока на сайте часто достаточно отдельного аккаунта администратора WordPress. Для переноса сайта могут понадобиться SFTP, база данных и панель хостинга. Для настройки VPS уже нужен SSH-доступ.

Доступ к WordPress

Если задача связана только с сайтом на WordPress, лучше создать отдельного пользователя для разработчика. Не стоит передавать свой личный логин и пароль от основной учётной записи владельца.

Отдельный пользователь удобнее по нескольким причинам:

• понятно, кто выполнял изменения;

• доступ можно отключить после завершения работ;

• не нужно менять основной пароль владельца;

• можно выбрать подходящую роль пользователя;

• меньше риск потерять контроль над сайтом.

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

Доступ к файлам сайта

Для работы с файлами сайта часто используют FTP или SFTP. Если есть возможность выбрать, лучше использовать SFTP, потому что он работает через защищённое SSH-соединение.

Доступ к файлам нужен, если специалист будет:

• править тему сайта;

• загружать или изменять файлы;

• переносить сайт;

• исправлять ошибки в коде;

• работать с резервной копией;

• восстанавливать сайт после сбоя.

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

Доступ к базе данных

Для WordPress база данных хранит страницы, записи, настройки, пользователей, заказы WooCommerce, формы и другую важную информацию. Поэтому доступ к базе нужно передавать только тогда, когда он действительно нужен.

Доступ к базе может понадобиться при:

• переносе сайта;

• восстановлении из бэкапа;

• поиске технической ошибки;

• смене домена в базе данных;

• чистке заражённого сайта;

• массовой замене данных.

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

Доступ к VPS и SSH

SSH-доступ к VPS — один из самых важных. Через него можно управлять сервером, устанавливать пакеты, менять конфиги, перезапускать службы, работать с файлами и базами данных.

Если специалисту нужен SSH, лучше заранее понять, для какой задачи:

• установка панели управления;

• перенос сайта;

• настройка веб-сервера;

• проверка нагрузки;

• настройка PHP или базы данных;

• восстановление после ошибки;

• поиск проблем с доступностью сайта.

Root-доступ даёт полный контроль над сервером. Его стоит передавать только проверенному специалисту и только если без него нельзя выполнить задачу.

Доступ к домену и DNS

Доступ к регистратору домена — один из самых критичных. Через него можно менять NS-серверы, DNS-записи, контактные данные и настройки домена.

Если нужно только направить домен на новый VPS, часто достаточно изменить A-запись или NS-серверы. Но полный доступ к аккаунту регистратора лучше передавать только в крайнем случае.

Перед работой с DNS важно сохранить текущие записи:

• A-записи сайта;

• CNAME-записи;

• MX-записи почты;

• TXT-записи SPF, DKIM, DMARC;

• NS-серверы;

• записи для сторонних сервисов.

Частая ошибка — перенести сайт на новый VPS и случайно сломать почту на домене, потому что при смене DNS забыли перенести MX и TXT-записи.

Как безопаснее передавать доступы

Не стоит отправлять все пароли обычным сообщением в мессенджере без структуры. Лучше передавать доступы аккуратно и понятно.

Безопаснее использовать такие правила:

• создавать отдельные аккаунты для разработчика;

• давать только нужный уровень прав;

• не передавать лишние доступы;

• не использовать один пароль для всех сервисов;

• сохранять список, кому и что было передано;

• отключать временные доступы после завершения работ;

• перед важными правками делать резервную копию.

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

Что проверить после завершения работ

Когда задача выполнена, доступы нужно не забыть привести в порядок. Это особенно важно, если работы выполнял внешний подрядчик.

После завершения работ стоит:

1. Проверить, что сайт работает корректно.

2. Сделать свежую резервную копию.

3. Отключить временных пользователей.

4. Сменить пароли, если передавались основные доступы.

5. Проверить пользователей в WordPress.

6. Проверить доступы к панели хостинга или VPS.

7. Убедиться, что домен и хостинг оформлены на владельца сайта.

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

Какие доступы должны быть у владельца сайта

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

У владельца должны быть:

• доступ к регистратору домена;

• доступ к хостингу или VPS-провайдеру;

• доступ к панели управления сервером, если она используется;

• администраторский доступ к WordPress;

• доступ к резервным копиям;

• доступ к корпоративной почте;

• доступ к сервисам аналитики и рекламы;

• понимание, кто обслуживает сайт и сервер.

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

Частые ошибки при передаче доступов

• Передавать один главный пароль от всего

  Такой подход удобен только на первый взгляд. Лучше использовать отдельные аккаунты и разные уровни прав.

• Не делать бэкап перед работами

  Перед правками, переносом или обновлением сайта нужна свежая резервная копия.

• Давать root-доступ без необходимости

  Root позволяет полностью управлять сервером. Его стоит передавать только когда это действительно нужно.

• Не отключать доступы после завершения работ

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

• Не хранить доступы у владельца

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

Итоги

• Доступы к сайту, VPS, домену и почте имеют разный уровень важности.

• Разработчику нужно передавать только те доступы, которые нужны для конкретной задачи.

• Для WordPress лучше создавать отдельного пользователя, а не отдавать основной аккаунт владельца.

• Root-доступ к VPS стоит выдавать только проверенному специалисту и только при необходимости.

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

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

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