Передать подрядчику логин и пароль основного администратора кажется самым быстрым способом начать работу. Но после завершения задачи такой доступ часто остаётся активным, один пароль используют несколько человек, а определить автора изменения становится невозможно. Безопасная передача доступа к WordPress строится иначе: отдельная учётная запись, минимально необходимые права, ограниченный срок и журналирование действий.
Подрядчику нужно выдавать не «доступ к сайту вообще», а ровно те права, которые необходимы для конкретной задачи и на конкретный срок.
Почему нельзя передавать общий аккаунт администратора
Общий логин лишает сайт персональной ответственности. В журнале все изменения будут записаны от имени одного пользователя, поэтому при ошибке или подозрительной активности нельзя быстро понять, кто устанавливал плагин, менял настройки или редактировал файлы. Кроме того, пароль может сохраниться в браузере, менеджере проектов, переписке или системе подрядчика.
- невозможно корректно отозвать доступ только у одного исполнителя;
- смена общего пароля затрагивает владельца сайта и остальных сотрудников;
- администратор может устанавливать код, создавать пользователей и менять критические настройки;
- при утечке сложно определить источник и время компрометации;
- двухфакторная авторизация превращается в неудобную общую схему и часто отключается.
Создайте отдельную учётную запись
Для каждого специалиста создавайте отдельного пользователя с рабочим адресом электронной почты. Не называйте аккаунт просто admin2 или developer: по имени должно быть понятно, кому он принадлежит или с какой компанией связан. Это упрощает аудит и удаление устаревших доступов.
Пароль должен быть уникальным и сгенерированным менеджером паролей. Не отправляйте логин и пароль одним сообщением в открытом чате. Лучше использовать защищённую передачу секрета с ограниченным временем просмотра, а для длительной работы — корпоративный менеджер паролей с возможностью отзыва доступа.
Выберите минимально достаточную роль
Не каждая задача требует роли администратора. Перед созданием пользователя определите, что именно должен сделать подрядчик.
| Задача | Подходящий доступ |
|---|---|
| Подготовка и редактирование материалов | Автор или редактор |
| Работа с товарами и заказами WooCommerce | Менеджер магазина с проверенными возможностями |
| Настройка SEO-контента | Редактор и только нужные функции SEO-плагина |
| Разработка темы или плагина | Доступ к staging, репозиторию и процессу развёртывания |
| Установка плагинов и системные настройки | Временный администратор под контролем |
Стандартные роли WordPress подходят не всегда. Если подрядчику нужна одна административная возможность, безопаснее создать ограниченную роль или настроить capabilities, чем открывать всю панель. После настройки войдите под тестовым пользователем и убедитесь, что лишние разделы и действия действительно недоступны.
Разработку проводите на staging, а не на рабочем сайте
Если задача связана с PHP, JavaScript, шаблонами, базой данных или интеграциями, основной доступ подрядчика должен вести на тестовую копию. На staging можно включить журналирование, проверить изменения, провести приёмку и подготовить контролируемое развёртывание.
Рабочий сайт при этом остаётся закрытым от случайных экспериментов. Доступ к production выдаётся только для согласованного запуска, а изменения переносятся через Git, архив релиза или автоматизированный процесс. Перед развёртыванием создаётся резервная копия и определяется способ отката.
Не выдавайте больше серверных доступов, чем требуется
Админка WordPress, хостинг, SSH, база данных, CDN и регистратор домена — разные уровни доступа. Не нужно передавать их комплектом. Для загрузки файлов используйте отдельного SFTP-пользователя с ограниченным каталогом. Для Git создайте доступ только к нужному репозиторию. Для внешнего API выпустите отдельный токен с минимальными разрешениями и понятным названием.
Пароль приложения WordPress подходит для REST API и автоматизации, но не заменяет обычный вход в административную панель. Создавайте отдельный пароль приложения для каждой интеграции. Тогда его можно отозвать, не меняя основной пароль пользователя и не отключая другие процессы.
Включите двухфакторную авторизацию и защиту входа
Для пользователей с расширенными правами включите двухфакторную авторизацию. Дополнительно ограничьте число попыток входа, настройте уведомления о новых администраторах и подозрительных авторизациях. Если сайт обслуживается из предсказуемых сетей, административный доступ можно дополнительно ограничить через VPN, Cloudflare Access или правила веб-сервера.
IP-ограничение не всегда удобно для внешнего специалиста с динамическим адресом, поэтому его стоит применять осознанно. Двухфакторная авторизация, уникальный аккаунт и минимальные права остаются базовыми мерами даже при наличии сетевого фильтра.
Фиксируйте задачу и действия
До начала работ запишите область изменений: какие страницы, плагины, файлы и интеграции разрешено менять, что нельзя трогать и как будет проходить приёмка. Для сложной задачи полезно зафиксировать текущее состояние сайта, версии компонентов и контрольные сценарии.
- установите журнал действий пользователей;
- сохраняйте историю изменений кода в Git;
- не отключайте журнал ошибок во время тестирования;
- проверяйте создание новых администраторов и изменение ролей;
- фиксируйте дату выдачи и плановую дату отзыва доступа;
- сохраняйте отчёт о выполненных работах и список изменённых компонентов.
Что сделать после завершения работ
Приёмка задачи не заканчивается проверкой внешнего вида страницы. Убедитесь, что формы отправляются, письма доходят, магазин принимает заказы, фоновые задания выполняются, а в журналах нет новых повторяющихся ошибок. После этого закройте временные доступы.
- Заблокируйте или удалите временную учётную запись WordPress.
- Отзовите пароли приложений, API-токены, SSH-ключи и доступ к репозиторию.
- Удалите временного пользователя SFTP и доступ к панели хостинга.
- Проверьте, не были ли созданы дополнительные администраторы.
- Смените общие секреты, если подрядчик всё же получал к ним доступ.
- Сохраните финальный бэкап, список изменений и инструкции по поддержке.
Короткий чек-лист безопасного доступа
- отдельная учётная запись для каждого исполнителя;
- минимально необходимая роль и набор capabilities;
- уникальный пароль и двухфакторная авторизация;
- staging для разработки и проверки;
- раздельные доступы к WordPress, серверу, Git и внешним сервисам;
- журнал действий и понятная область работ;
- резервная копия и проверенный откат;
- дата автоматического или ручного отзыва всех временных доступов.
Такая схема требует нескольких дополнительных минут при старте, зато снижает риск взлома, случайного сбоя и споров о выполненных изменениях. Главное правило простое: доступ должен быть персональным, ограниченным, наблюдаемым и временным.
Нужно безопасно организовать доступ и поддержку WordPress?
Команда UWEAM настроит роли и отдельные учётные записи, подготовит тестовый стенд, резервное копирование и контролируемое развёртывание изменений. Проверим существующие доступы, закроем лишние права и выстроим понятный процесс работы с подрядчиками.
Регулярная поддержка — от 12 000 ₽ в месяц. Регламент и объём работ согласуем до начала.
Разработка и поддержка WordPress — wp.uweam.ru.
