Подрядчику в WordPress выдают отдельную учётную запись с минимальной ролью, которой хватает на задачу: «Редактор» для работы с контентом, «Администратор» только для настройки плагинов, темы и обновлений. Пароль владельца не передают никогда. После завершения работ учётную запись удаляют или понижают до «Подписчика», а данные хостинга меняют.
Обычная ситуация: сайт компании сделал один подрядчик, потом его вёл другой, тексты публиковал фрилансер, а SEO-специалист ставил свои плагины. Через два года в списке пользователей восемь администраторов, половину из них никто не узнаёт, а пароль от главной учётной записи знают трое бывших исполнителей. Любой из этих людей может зайти на сайт, и компания об этом не узнает.
Что такое роли пользователей WordPress
Роль в WordPress — это набор прав, который определяет, что пользователь может делать на сайте: писать записи, публиковать их, загружать файлы, ставить плагины или управлять другими пользователями. Права (capabilities) — отдельные разрешения внутри роли, например «устанавливать плагины» или «редактировать чужие записи».
Согласно документации WordPress о ролях и правах, в обычной установке есть пять ролей, а в сети сайтов (Multisite) добавляется шестая:
- Супер-администратор управляет сетью сайтов и всеми функциями, есть только в Multisite;
- Администратор имеет доступ ко всем функциям управления одним сайтом;
- Редактор публикует и управляет записями, в том числе чужими;
- Автор публикует и управляет своими записями;
- Участник пишет и управляет своими записями, но не может их публиковать;
- Подписчик может только управлять своим профилем.
При установке WordPress автоматически создаётся одна учётная запись администратора. Роль, которую получают новые пользователи по умолчанию, задаётся в разделе «Настройки → Общие».
Права администратора и других ролей: чем они отличаются на практике
Главная граница проходит между администратором и всеми остальными: только администратор может ставить и удалять плагины и темы, обновлять WordPress, менять настройки сайта и управлять пользователями. Редактор работает с контентом любого автора, но в техническую часть сайта не заходит.
| Действие | Администратор | Редактор | Автор | Участник | Подписчик |
|---|---|---|---|---|---|
| Устанавливать и удалять плагины и темы | да | нет | нет | нет | нет |
| Обновлять WordPress, плагины, темы | да | нет | нет | нет | нет |
| Менять настройки сайта | да | нет | нет | нет | нет |
| Создавать и удалять пользователей | да | нет | нет | нет | нет |
| Настраивать меню и виджеты темы | да | нет | нет | нет | нет |
| Редактировать чужие записи и страницы | да | да | нет | нет | нет |
| Публиковать записи | да | да | да | нет | нет |
| Загружать файлы в медиатеку | да | да | да | нет | нет |
| Писать свои черновики | да | да | да | да | нет |
Про одно право часто забывают: у администратора и редактора на обычном сайте есть право unfiltered_html. Оно позволяет вставлять в записи произвольный HTML, включая скрипты. На практике это значит, что редактор может добавить на страницу код счётчика или виджета, а недобросовестный редактор может добавить и что-то вредное. В сети сайтов Multisite это право остаётся только у супер-администратора.
Какую роль дать подрядчику под конкретную задачу
Роль подбирают под задачу, а не под уровень доверия к человеку. Если копирайтер честный, давать ему права ставить плагины всё равно незачем: учётную запись могут взломать, а пароль утечь с чужого компьютера.
| Кто и зачем | Рекомендуемая роль | Комментарий |
|---|---|---|
| Копирайтер, который сдаёт тексты на проверку | Участник | Пишет черновики, публикует ваш редактор. Картинки загрузить не сможет |
| Автор блога, который публикует сам | Автор | Работает только со своими записями |
| Контент-менеджер, SEO-специалист по текстам и мета-тегам | Редактор | Правит любые записи и страницы, но не трогает плагины |
| Разработчик: доработка темы, плагины, обновления | Администратор, временно | Отдельная учётная запись, срок доступа оговорён заранее |
| Внешний сервис, который публикует через API | Отдельный пользователь с минимальной ролью и пароль приложения | Основной пароль сервису не нужен |
SEO-специалисту часто действительно нужен администратор: настроить плагин SEO, поправить robots.txt, поставить код верификации. Тогда договоритесь, что учётная запись создаётся на время конкретных работ, а после их приёмки роль понижается. Если SEO ведётся постоянно, на проектах удобнее давать «Редактора» для текстов и отдельно согласовывать технические правки.
Как выдать доступ подрядчику в WordPress: пошагово
Доступ выдают через создание нового пользователя в разделе «Пользователи», с почтой подрядчика и нужной ролью. Пароль от своей учётной записи передавать нельзя даже на час.
- Зайдите в консоль WordPress под администратором и откройте раздел «Пользователи → Добавить нового».
- Укажите логин, по которому понятно, кто это и откуда: например, «ivanov-agency». Через год вы будете благодарны себе за понятное имя.
- Впишите рабочую почту подрядчика и оставьте включённой отправку письма новому пользователю. Он получит ссылку и задаст пароль сам, и знать его будет только он.
- Выберите роль по таблице выше.
- Сохраните пользователя и запишите в договоре или в задаче, кому и до какой даты выдан доступ.
- После окончания работ удалите пользователя или понизьте его роль до «Подписчика». При удалении WordPress предложит передать его записи другому пользователю, чтобы контент не пропал.
Если подрядчику нужен доступ к хостингу, FTP или базе данных, создавайте ему отдельные учётные записи и там. У большинства хостингов можно завести дополнительного FTP-пользователя с доступом только к папке сайта. Пароль от панели хостинга и от главной учётной записи хостинга лучше оставить у компании.
Тестовая копия сайта: доступ без риска для рабочей версии
Для крупных доработок безопаснее дать подрядчику администратора на тестовой копии сайта, а не на рабочем. Тестовая копия, её ещё называют staging, — это дубликат сайта на отдельном адресе, где можно ставить плагины, менять тему и проверять обновления, не рискуя заявками и позициями в поиске.
Многие хостинги умеют создавать такую копию в панели управления. Подрядчик делает работу на тестовой версии, вы проверяете результат, и только потом изменения переносятся на рабочий сайт. На рабочем сайте подрядчику в этом случае хватает доступа на время переноса. Тестовую копию закройте от индексации и паролем, иначе поисковики найдут дубль сайта, и он начнёт конкурировать с основным.
Пароли приложений: доступ для сервисов без основного пароля
Пароль приложения — это отдельный пароль, который WordPress выдаёт для подключения внешних программ через REST API и XML-RPC, без раскрытия основного пароля пользователя. Функция встроена в WordPress начиная с версии 5.6, о ней подробно рассказывает руководство разработчиков WordPress по паролям приложений.
Что важно знать:
- пароли приложений создаются и отзываются на странице редактирования пользователя;
- войти с таким паролем в консоль WordPress нельзя, он работает только для программных запросов;
- запрос с паролем приложения выполняется от имени пользователя, поэтому у сервиса будут те же права, что у этого пользователя.
Последний пункт определяет схему работы. Если сервису для публикации статей нужен только доступ к записям, создайте для него отдельного пользователя с ролью «Редактор» или «Автор» и выпустите пароль приложения уже для него. Пароль приложения от учётной записи администратора даёт сервису права администратора. Когда сервис больше не нужен, отзовите пароль: отключить доступ можно за минуту, не меняя основной пароль.
Когда стандартных ролей не хватает
Стандартных ролей пользователей WordPress не хватает, когда нужно дать человеку часть прав администратора, например доступ к заказам магазина, но без права ставить плагины. Тогда используют плагины управления ролями или роли, которые создают сами плагины.
Плагины интернет-магазина, форм, SEO и конструкторов страниц часто добавляют свои роли и права. Например, WooCommerce добавляет роли «Клиент» для покупателей и «Менеджер магазина» для сотрудников, которые работают с заказами и товарами. Менеджеру магазина не нужен администратор, чтобы обрабатывать заказы, и это хороший способ не раздавать лишние права отделу продаж. Перед тем как выдавать такую роль, откройте её описание в документации конкретного плагина и проверьте, что именно она разрешает. Названия ролей у разных плагинов похожи, а права могут сильно отличаться.
Плагины для редактирования ролей позволяют создать свою роль из нужного набора прав или поправить существующую. Это удобно, но требует аккуратности. Ошибка в настройке может как закрыть сотрудникам нужные разделы, так и выдать кому-то права, о которых вы не подозреваете. Если вы не уверены, проще поручить настройку тому, кто будет за неё отвечать, и попросить письменное описание получившихся ролей.
Какие роли дать своим сотрудникам
Своим сотрудникам роли выдают по тому же принципу, что и подрядчикам: по задаче, а не по должности. Директору, который хочет «на всякий случай иметь доступ», хватит редактора, а ключи администратора лучше хранить у одного ответственного человека в компании.
Типичная схема для сайта небольшой компании выглядит так. Одна учётная запись администратора принадлежит компании и записана на корпоративную почту, пароль хранится в менеджере паролей, а не в блокноте. Маркетолог получает роль «Редактор» и ведёт блог и страницы услуг. Менеджеры, которые иногда правят цены или контакты, получают «Редактора» только если это действительно их работа, иначе они присылают правки маркетологу.
Отдельно продумайте, что произойдёт при увольнении. Если единственный администратор сайта уходит из компании, а его учётная запись привязана к личной почте, восстановление доступа может занять дни. Поэтому у компании должно быть минимум два человека, которые могут войти как администратор, и оба на рабочих адресах.
Как провести аудит пользователей сайта
Аудит пользователей — это проверка списка учётных записей сайта: кто они, какие у них роли и нужны ли они ещё. Его стоит делать раз в квартал и обязательно при смене подрядчика.
- Откройте раздел «Пользователи» и отфильтруйте список по роли «Администратор».
- Для каждой учётной записи ответьте на вопрос, кто это и зачем ему права сейчас. Если ответа нет, это кандидат на удаление.
- Проверьте почты: учётные записи на личных почтах бывших сотрудников и подрядчиков лучше перевести на рабочие адреса или удалить.
- Посмотрите пароли приложений у администраторов и отзовите те, которые никто не может объяснить.
- Проверьте пользователей с ролью «Редактор»: им доступен произвольный HTML, поэтому список должен быть коротким.
- Сверьте доступы к хостингу, FTP и базе данных: они часто живут дольше, чем учётные записи в WordPress.
На проектах B2BPRO.KZ мы при приёмке сайта на сопровождение почти всегда находим лишних администраторов. Чаще всего это учётные записи предыдущих подрядчиков и тестовые пользователи, которые остались с этапа разработки. Удалить их можно за несколько минут.
Пример: как передать сайт новому подрядчику
Пример для иллюстрации. Компания в Алматы меняет студию, которая вела сайт на WordPress. У старой студии был администратор, доступ к хостингу и к домену. Порядок передачи выглядел так: компания попросила у старого подрядчика полный список выданных доступов, создала новому подрядчику отдельного администратора, затем удалила учётную запись старой студии, сменила пароли от хостинга и почты, к которой привязан домен, и проверила список плагинов на незнакомые позиции. Новый подрядчик начал работу уже с чистой схемой доступов.
Обратите внимание на домен и хостинг. Если они оформлены на подрядчика, никакая настройка ролей в WordPress не спасёт при конфликте. Подробнее мы писали об этом в статье о том, почему домен и хостинг должны быть оформлены на вас.
Как узнать, кто и что поменял на сайте
Базовый WordPress не ведёт полный журнал действий пользователей, но сохраняет ревизии записей и страниц. В ревизиях видно, кто и когда изменил текст, и можно вернуть предыдущую версию.
Изменения настроек, установку плагинов, вход в консоль и удаление пользователей ревизии не покрывают. Если на сайте работают несколько подрядчиков, имеет смысл поставить плагин журнала действий. Тогда при спорной ситуации, например когда пропала форма заявки или сломалось меню, можно открыть журнал и увидеть, какой пользователь что сделал перед этим.
Журнал работает только если у каждого человека своя учётная запись. Когда пять исполнителей заходят под одним «admin», журнал покажет одно имя на все изменения, и разобраться, кто что сделал, не получится. Это ещё один довод не делиться своим паролем.
Что записать в договор с подрядчиком о доступах
В договоре или приложении к нему стоит зафиксировать, какие доступы выдаются, кто их владелец и что происходит с ними после окончания работ. Это занимает полстраницы и избавляет от спора при расставании.
- Сайт, домен, хостинг и все учётные записи принадлежат заказчику и оформлены на его данные.
- Подрядчик получает отдельные учётные записи с ролями, необходимыми для работ, и не создаёт новых администраторов без согласования.
- Подрядчик не передаёт доступы третьим лицам, включая своих субподрядчиков, без письменного согласия.
- По окончании работ подрядчик сообщает список всех созданных им учётных записей, паролей приложений и установленных плагинов.
- Заказчик удаляет или понижает учётные записи подрядчика в течение оговорённого срока после приёмки.
Если подрядчик возражает против таких пунктов, это повод насторожиться. Нормальная студия сама заинтересована в прозрачной схеме доступов: так проще доказать, что проблема на сайте возникла не по её вине.
Как защитить учётные записи с высокими правами
Учётные записи с правами администратора защищают прежде всего уникальным длинным паролем и двухфакторной авторизацией. И таких учётных записей должно быть как можно меньше.
- Не используйте логин «admin» и не публикуйте логины администраторов в подписи статей. Записи для блога лучше публиковать от учётной записи с ролью «Автор» или «Редактор».
- Включите двухфакторную авторизацию для администраторов. В базовом WordPress её нет, она подключается плагином или на уровне хостинга.
- Своевременно обновляйте WordPress, плагины и темы. Уязвимость в плагине может дать злоумышленнику права, которых нет у его учётной записи.
- Регулярно делайте резервные копии и проверяйте, что они восстанавливаются.
Больше практических мер мы собрали в статье как защитить сайт на WordPress от взлома. Если схема доступов на вашем сайте давно не пересматривалась или сайт пора переделывать, такие задачи мы решаем в рамках услуги разработка сайтов под ключ: настраиваем роли, оформляем доступы на компанию и передаём их владельцу с описанием.
Частые вопросы
Какую роль WordPress дать копирайтеру?
Копирайтеру, который сдаёт тексты на проверку, достаточно роли «Участник»: он пишет черновики, а публикует ваш редактор. Если копирайтер должен публиковать сам и загружать картинки, подойдёт роль «Автор». Права редактора или администратора для работы с текстами не нужны и только увеличивают риск.
Можно ли дать подрядчику свой логин и пароль от WordPress?
Нет, лучше создать подрядчику отдельного пользователя. Со своим паролем вы не сможете ограничить его права, не увидите, какие изменения сделал именно он, и не отключите доступ без смены своего пароля. Отдельная учётная запись удаляется за минуту, когда работа закончена.
Чем отличается редактор от администратора в WordPress?
Редактор управляет контентом: публикует и правит любые записи и страницы, модерирует комментарии, работает с рубриками. Администратор дополнительно ставит и удаляет плагины и темы, обновляет WordPress, меняет настройки и управляет пользователями. Для работы с текстами хватает редактора, администратор нужен для технических задач.
Что делать с учётной записью подрядчика после окончания работ?
Удалите пользователя или понизьте его роль до «Подписчика». При удалении WordPress предложит передать записи этого пользователя другому, чтобы контент не пропал. Затем отзовите его пароли приложений и смените доступы к хостингу и FTP, если они передавались.
Как дать внешнему сервису доступ к сайту без пароля администратора?
Создайте для сервиса отдельного пользователя с минимальной нужной ролью и выпустите для него пароль приложения на странице редактирования пользователя. Такой пароль работает только для API-запросов, в консоль с ним не войти. Сервис получит права этого пользователя, а отозвать доступ можно в любой момент без смены основного пароля.