Наняли разработчика, чтобы поправить сайт, обновить тему, подключить оплату или докрутить WooCommerce? Нормальная история. Но вот где люди часто подставляются — просто скидывают логин и пароль от главного админа. В телеграм. Или, еще веселее, отдают доступ еще и к хостингу, и к домену, и к почте. Сразу весь сейф. Плохая идея.
На самом деле доступ разработчику давать можно и нужно. Без этого он ничего не сделает. Вопрос в другом — как дать ровно столько, сколько надо для работы, и потом не гадать, кто удалил плагин, почему пропали заказы и откуда на сайте внезапно редирект на казино.
Если коротко: не отдавайте все ключи одному человеку, не работайте с общей учеткой и заранее думайте не только про вход, но и про выход. То есть как вы потом этот доступ закроете. Вот это и есть контроль.
Главная ошибка — общий админ на всех
Знакомо? На сайте уже есть пользователь admin, пароль знают владелец, бывший фрилансер, маркетолог, сеошник и “тот парень, который что-то правил в 2022-м”. И вот к этой же учетке подключают нового разработчика. Так делать не надо.
Почему это плохо:
- вы не понимаете, кто именно что менял;
- нельзя быстро отключить одного человека без смены пароля для всех;
- если логин утек, вы даже не узнаете откуда;
- в журнале действий будет одна и та же учетка — толку ноль.
Для каждого человека — отдельный юзер. Даже если это “на пару часов”. Особенно если на пару часов. Создать нового пользователя в WordPress — дело двух минут. А разгребать последствия общей учетки можно неделями.
Кстати, если у вас до сих пор есть админ с логином admin, это уже повод притормозить и привести доступы в порядок. Боты такие логины любят. Да, до смешного банально.
Какой доступ давать на самом деле
Не всем нужен полный админ. Честно говоря, большинству — нет.
Смотрите, тут все зависит от задачи. Если человек пишет тексты или ставит картинки, ему хватит роли редактора. Если правит товары в магазине — иногда хватает менеджера магазина. Если лезет в плагины, тему, код, настройки оплаты — тут уже да, скорее всего нужен админ.
Но даже админ в WordPress — это еще не доступ к хостингу, базе данных, DNS и домену. И хорошо.
Нормальный принцип такой: минимум прав под задачу. Не “на всякий случай дам все”, а “что конкретно нужно сегодня”.
Примеры:
- Поправить верстку на сайте — часто нужен доступ к админке и, возможно, SFTP к конкретной папке.
- Обновить плагины и тему — админка WordPress, иногда без хостинга вообще.
- Чинить белый экран после апдейта — тут уже может понадобиться хостинг, логи и база.
- Перенос сайта — да, тут доступов больше. Но все равно временно и по списку.
Если человек сразу просит вообще все, не объясняя зачем — это не обязательно мошенник. Но уже красный флаг. Нормальный спец обычно может по-человечески сказать, что ему нужно и для какой части работы.
Что дать, а что лучше не отдавать
Есть доступы, которые лучше держать у владельца бизнеса почти всегда. Даже если разработчик хороший. Даже если “мы давно работаем”. Просто потому что жизнь длинная, а подрядчики меняются.
Лучше оставить у себя:
- доступ к регистратору домена;
- главную почту компании, на которую завязаны восстановления;
- основной аккаунт хостинга владельца;
- доступ к платежным системам;
- Google аккаунты, аналитика, Search Console, рекламные кабинеты.
Разработчику можно выдать отдельного пользователя в панели хостинга, отдельный SFTP, временный доступ в WordPress, тестовую копию сайта. Вот это — взрослая схема. Чуть дольше по времени, зато потом без сюрпризов.
Если у вас с доступами бардак уже сейчас, есть смысл не ждать взлома, а просто навести порядок и собрать нормальную схему обслуживания. Для этого обычно и берут обслуживание WordPress — чтобы доступы, апдейты, бэкапы и мониторинг были не “где-то записаны”, а настроены по-человечески.
Перед тем как дать доступ — сделайте вот это
Тут многие ленятся. А потом жалеют.
Перед стартом работ у вас должны быть три вещи:
- свежий бэкап файлов и базы;
- список, какие доступы и кому выдали;
- понимание, где смотреть изменения, если что-то пойдет не так.
Бэкап — обязательно. И не тот, про который “ну вроде хостинг что-то сохраняет”. А нормальный, проверяемый. Кстати, если думаете, что копия сама по себе уже решает проблему, советую почитать про разницу между копией и реальным восстановлением: бэкап — это еще не план восстановления. Там как раз про ту самую ловушку, в которую попадают владельцы сайтов.
Еще совет — договоритесь заранее, где ведется работа. На боевом сайте или на тестовом. Для маленькой визитки правка на бою еще ладно. Для интернет-магазина с заказами — я бы не рисковал. Видел, как из-за “быстро сейчас подкручу” ломалась корзина в пятницу вечером. Не надо так.
2FA, журнал действий и прочая “скучная” защита
Вот тут начинается самое полезное и самое недооцененное.
Если вы даете доступ в админку, включите двухфакторную аутентификацию. Да, даже если разработчик торопится. Да, даже если “мы потом”. Настроить можно минут за пять. Зато если пароль утечет, одной пары логин-пароль уже не хватит. Вот страница про двухфакторную аутентификацию — штука базовая, а спасает отлично.
Вторая фишка — журнал действий. Он нужен не для паранойи, а для нормальной жизни. Кто вошел, какой плагин обновил, кто поменял email админа, кто удалил страницу. Когда на сайте работает несколько людей, без журнала вы слепые.
И да, полезно понимать, как вообще читать такие записи, а не просто смотреть в поток событий и закрывать вкладку. Если тема актуальна, гляньте статью как читать журнал действий WordPress. Она как раз для владельцев сайта, а не для технарей.
Еще минимум, который стоит включить:
- ограничение попыток входа;
- уведомления о входе новых юзеров;
- автообновления хотя бы для патчей безопасности;
- сканирование на известную малварь.
Это не дорого. Часто вообще бесплатно или уже входит в нормальный набор защиты.
Если разработчику нужен хостинг доступ
Вот тут аккуратнее.
Лучший вариант — не отдавать главный аккаунт хостинга, а создать отдельный технический доступ. Если хостинг это умеет, дайте отдельный SFTP или пользователя панели с ограниченными правами. Если не умеет — хотя бы сразу договоритесь, что после работ пароль меняется. Без обид. Это не недоверие, это гигиена. Как поменять код от сигнализации после ухода подрядчика.
И еще момент. Никогда не отправляйте все доступы одним сообщением в мессенджере в стиле: “вот логин, пароль, ссылка на вход, база, домен, почта”. Разбейте инфу по разным каналам хотя бы минимально. Например, логин в одном сообщении, пароль в другом, 2FA отдельно. Не идеал, но уже лучше.
Если работа серьезная — перенос, чистка после заражения, восстановление магазина — записывайте, кто и когда получил доступ. Прямо в заметке. Дата, какой доступ, когда отключить. Это звучит скучно, зато реально спасает.
После работы доступ надо не “оставить на всякий случай”, а закрыть
Вот это люди забывают постоянно.
Разработчик все сделал, вы довольны, сайт жив. И доступы остаются навсегда. Через полгода этот человек меняет ноутбук, теряет старый файл с паролями, его почту ломают, или он просто уже не помнит, где у него что. А ваш сайт все еще открыт.
После завершения работ:
- отключите или удалите временного пользователя;
- смените пароль, если давали доступ к хостингу или общей системе;
- отвяжите лишние API-ключи, токены, интеграции;
- проверьте, не осталось ли новых админов, cron-задач, “служебных” плагинов;
- убедитесь, что сайт работает — форма, корзина, письма, оплата.
Именно тут часто всплывают сюрпризы. Например, на сайте остался скрытый админ, потому что “так удобнее потом зайти, если что”. Не-а. Если что — создадите заново.
А если сайт уже повел себя странно после доступа
Редиректы, новые админы, странные плагины, письма от хостинга, непонятные файлы в wp-content — это уже не “может показалось”. Лучше проверить сразу. Потому что если сайт реально зацепил малварь или в нем оставили бэкдор, он может внешне работать нормально еще какое-то время. А потом бах.
Если есть подозрение на взлом или кривую “доработку”, не тяните. Есть отдельная помощь для ситуации сайт взломан — с очисткой, восстановлением и разбором, как зло вообще попало внутрь. Для малого бизнеса это часто дешевле, чем потом терять заявки, рекламу и репутацию.
Итог — контроль не в том, чтобы никого не пускать
Короче, безопасный доступ разработчику — это не про недоверие и не про бюрократию. Это про простую мысль: сайт ваш, бизнес ваш, значит и контроль должен оставаться у вас.
Давайте отдельные учетки. Не скидывайте главный админ всем подряд. Включайте 2FA. Делайте бэкап до работ. Отключайте доступ после. И храните критичные вещи — домен, почту, платежки — на своей стороне.
Все. Этого уже хватит, чтобы не попасть в самую дурацкую ситуацию, когда разработчик давно исчез, а вы даже не понимаете кто вообще может войти в ваш сайт.
А такое, увы, случается сплошь и рядом.