WordPress Редактор vs. Роль Администратора: Полное Техническое Руководство

WordPress поставляется с детализированной системой управления доступом на основе ролей (RBAC), встроенной непосредственно в ядро. Из всех стандартных ролей Administrator и Editor являются двумя наиболее значимыми — и наиболее часто неправильно назначаемыми. Administrator обладает неограниченными возможностями над каждым объектом WordPress, тогда как Editor работает с широкими полномочиями в области контента, но без какого-либо доступа к элементам управления на уровне инфраструктуры, таким как темы, плагины или настройки сайта.

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

Как на самом деле работают роли и возможности WordPress

Прежде чем сравнивать две роли, стоит разобраться в базовой архитектуре. WordPress не хранит роли как фиксированное свойство учётной записи пользователя. Вместо этого он хранит сериализованный массив возможностей в таблице wp_usermeta под ключом wp_capabilities (где wp_ — ваш префикс таблицы). Каждая роль — это просто именованный набор возможностей, зарегистрированных в классе WP_Roles.

Когда пользователь пытается выполнить действие — опубликовать запись, удалить плагин, отредактировать профиль другого пользователя — WordPress вызывает current_user_can(), который сопоставляет сохранённые возможности пользователя с запрошенным примитивом. Это означает, что возможности аддитивны и, что важно, могут быть настроены для каждого пользователя независимо от его роли с помощью плагинов, таких как Members или User Role Editor.

Практическое следствие: если вам нужен пользователь, который может делать *почти* всё, что может Editor, но также управлять одним конкретным плагином, вам не нужно повышать его до Administrator. Вы можете предоставить одну дополнительную возможность. Понимание этого позволяет избежать наиболее распространённой ошибки избыточного предоставления прав при управлении командой WordPress.

Роль Administrator: полный разбор возможностей

Роль Administrator соответствует практически каждому примитивному полномочию, которое предоставляет WordPress. На односайтовой установке это включает, но не ограничивается следующим:

Основные возможности управления сайтом:

manage_options — чтение и запись всех настроек через wp-admin/options-general.php, включая URL сайта, email администратора, структуру постоянных ссылок и часовой пояс
install_plugins, activate_plugins, update_plugins, delete_plugins — полный контроль жизненного цикла плагинов
install_themes, switch_themes, edit_themes, delete_themes — полный контроль жизненного цикла тем, включая прямое редактирование файлов через встроенный редактор тем (значительный вектор атаки)
edit_files — доступ к встроенному редактору кода для тем и плагинов (эта возможность отключается, когда DISALLOW_FILE_EDIT установлен в true в wp-config.php)

Возможности управления пользователями:

create_users, edit_users, delete_users, promote_users, list_users — полные полномочия над каждой учётной записью пользователя на сайте, включая возможность понижения или удаления других Administrator
remove_users — удаление пользователей из сети Multisite

Возможности в области контента:

edit_others_posts, edit_published_posts, delete_others_posts, delete_published_posts, delete_private_posts

Расширенные возможности:

import — импорт контента через импортёр WordPress (может использоваться для массового внедрения произвольного контента)
export — экспорт всего контента сайта в виде XML-файла, включая все данные пользователей
update_core — запуск обновлений ядра WordPress
manage_categories, moderate_comments, unfiltered_html — публикация необработанного HTML, включая теги <script>, без санитизации

Возможность unfiltered_html заслуживает особого внимания. На стандартной односайтовой установке её получают как Administrator, так и Editor. В WordPress Multisite её сохраняют только Super Admin. Это значимая граница безопасности: без unfiltered_html фильтр wp_kses_post() удаляет JavaScript и другую потенциально опасную разметку из сохранённого контента.
Когда назначать роль Administrator

Лицо, которому принадлежит хостинг-аккаунт и которое несёт ответственность за техническую целостность сайта
Проверенный разработчик или DevOps-инженер, выполняющий разработку тем, настройку плагинов или серверную интеграцию
Специалист по миграции во время разовой операции импорта/экспорта (рассмотрите возможность отзыва роли после завершения)

Важное операционное примечание: Никогда не назначайте Administrator общей или обезличенной учётной записи. Каждый Administrator должен быть конкретным человеком с уникальным надёжным паролем и включённой двухфакторной аутентификацией. Если вы запускаете WordPress в среде VPS Hosting, сочетайте соблюдение гигиены Administrator на уровне WordPress с разделением пользователей на уровне ОС — процесс вашего веб-сервера никогда не должен работать от имени root, а владелец файлов WordPress должен отличаться от пользователя веб-сервера.
Роль Editor: разбор возможностей
Роль Editor создана специально для работы с контентом. Она предоставляет широкие полномочия в отношении записей, страниц, медиафайлов, комментариев и таксономии — но намеренно исключает все возможности на уровне инфраструктуры.
Возможности контента, которыми обладает Editor:

edit_posts, edit_others_posts, edit_published_posts, edit_private_posts

Что Editor явно не может делать:

• Получать доступ к wp-admin/options-general.php или любому экрану настроек
• Устанавливать, активировать, деактивировать или удалять плагины или темы
• Просматривать или изменять любую учётную запись пользователя, кроме собственного профиля
• Запускать обновления ядра WordPress
• Получать доступ к встроенным редакторам файлов тем или плагинов
• Изменять структуру постоянных ссылок, что нарушило бы все существующие URL сайта
• Экспортировать или импортировать данные сайта

Когда назначать роль Editor

• Главный редактор или директор по контенту, который управляет редакционным календарём и утверждает черновики от нескольких авторов
• SEO-специалист, которому необходимо публиковать, планировать и оптимизировать записи, но у которого нет необходимости касаться настроек плагинов
• Менеджер по социальным сетям или маркетингу, отвечающий за поддержание активности блога
• Клиент, которому необходимо обновлять собственные страницы без риска случайно сломать сайт

Administrator и Editor: сравнение бок о бок

Последствия неправильного назначения ролей для безопасности

Проблема избыточно привилегированного Editor

Распространённая практика в агентствах: автору контента предоставляется доступ Administrator, потому что «так проще». Это создаёт несколько конкретных рисков:

1. Установка плагинов как вектор выполнения кода. Любой Administrator может установить плагин. Плагин — это PHP-код, который выполняется на вашем сервере. Скомпрометированный аккаунт Administrator равнозначен удалённому выполнению кода.
2. Сбор учётных данных через экспорт. Инструмент экспорта WordPress создаёт XML-файл, содержащий весь контент записей, комментарии и метаданные авторов. Administrator может запустить это незаметно.
3. Сохранение эскалации привилегий. Злоумышленник, получивший доступ Administrator, может создать новую учётную запись Administrator, а затем удалить следы — заблокировав законного владельца.
4. Злоупотребление unfiltered_html. Даже без доступа к плагинам Administrator может внедрять теги <script> непосредственно в контент записей, что позволяет проводить атаки хранимого XSS против посетителей сайта.

Усиление защиты роли Administrator

Помимо назначения ролей, применяйте следующие элементы управления на уровне WordPress на любом рабочем сайте:

Добавьте следующее в wp-config.php, чтобы отключить встроенный редактор файлов:

define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true ); // Also blocks plugin/theme installation

Ограничьте доступ к панели администратора WordPress по IP на уровне сервера. Для Nginx:

location /wp-admin/ {
    allow 203.0.113.0/24;
    deny all;
}

Для Apache добавьте в .htaccess:

<Files "wp-login.php">
    Require ip 203.0.113.0/24
</Files>

Обеспечьте соблюдение требований к надёжным паролям и двухфакторной аутентификации с помощью плагина, такого как WP 2FA или Wordfence Login Security. Если ваш сайт работает на Dedicated Server, рассмотрите возможность размещения панели администратора WordPress за VPN или SSH-туннелем, а не открытого доступа к ней из публичного интернета.

Защита роли Editor от злоупотреблений

Роль Editor значительно безопаснее, чем Administrator, но не лишена рисков:

• Editor с unfiltered_html может внедрять пиксели отслеживания, партнёрские редиректы или вредоносные скрипты в контент записей. В Multisite эта возможность удаляется — весомый аргумент в пользу использования сети Multisite при наличии большого числа авторов контента.
• Editor может безвозвратно удалить любую запись или страницу, включая те, которые он не создавал. Встроенной корзины для страниц не существует. Используйте стратегию резервного копирования или ревизий для снижения этого риска.
• Editor может одобрять комментарии, в том числе содержащие спам-ссылки, что влияет на SEO и репутацию вашего сайта.

WordPress Multisite: как меняются роли

В сети WordPress Multisite иерархия ролей получает дополнительный уровень: Super Administrator. Super Admin стоит выше всех Administrator на уровне сайта и управляет общесетевыми настройками, активацией плагинов на всех сайтах и созданием пользователей на уровне сети.

В Multisite Administrator на уровне сайта лишается ряда возможностей, существующих на односайтовых установках, включая возможность устанавливать плагины (только Super Admin могут делать это в масштабах всей сети) и возможность unfiltered_html. Это делает Multisite более защищённой архитектурой для агентств, управляющих сайтами клиентов, или издателей, управляющих несколькими редакционными ресурсами.

Если вы создаёте многопользовательскую издательскую платформу, VPS с cPanel может упростить уровень управления на стороне сервера, пока WordPress Multisite обеспечивает разделение ролей на уровне приложения.

Пользовательские роли: когда ни Administrator, ни Editor не подходят

Функции add_role() и add_cap() WordPress позволяют определять роли именно с теми возможностями, которые требует ваш рабочий процесс. Например, Senior Editor, который может делать всё, что Editor, плюс управлять пользователями (но не плагинами), может быть создан программно:

add_role(
    'senior_editor',
    'Senior Editor',
    array(
        // Inherit all standard Editor capabilities
        'read'                   => true,
        'edit_posts'             => true,
        'edit_others_posts'      => true,
        'edit_published_posts'   => true,
        'publish_posts'          => true,
        'delete_posts'           => true,
        'delete_others_posts'    => true,
        'delete_published_posts' => true,
        'edit_pages'             => true,
        'edit_others_pages'      => true,
        'edit_published_pages'   => true,
        'publish_pages'          => true,
        'delete_pages'           => true,
        'manage_categories'      => true,
        'moderate_comments'      => true,
        'upload_files'           => true,
        // Extended capability
        'list_users'             => true,
        'edit_users'             => true,
    )
);

Разместите этот код в плагине для конкретного сайта (не в functions.php темы), чтобы роль сохранялась при смене тем. Роли хранятся в базе данных после первой регистрации, поэтому add_role() нужно запустить только один раз — оберните его в хук активации плагина с помощью register_activation_hook().

Практическая матрица принятия решений по назначению ролей

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

Назначайте Administrator только если пользователь:

• Владеет сайтом или несёт договорную ответственность за его техническую эксплуатацию
• Нуждается в установке, настройке или обновлении плагинов и тем
• Должен управлять другими учётными записями пользователей или изменять роли пользователей
• Требует доступа к настройкам WordPress, структуре постоянных ссылок или URL сайта
• Имеет включённую двухфакторную аутентификацию и использует уникальную, не общую учётную запись
• Понимает, что DISALLOW_FILE_MODS будет установлен в true в рабочей среде

Назначайте Editor если пользователь:

• Отвечает за качество контента, графики публикаций или редакционную проверку
• Нуждается в управлении записями и страницами, созданными другими членами команды
• Должен иметь возможность модерировать комментарии и управлять медиафайлами
• Не нуждается — и не должен иметь — доступа к каким-либо плагинам, темам или экранам настроек
• Может быть клиентом, фрилансером или подрядчиком, безопасность учётной записи которого вы не можете полностью контролировать

Рассмотрите пользовательскую роль если:

• Встроенный Editor слишком ограничен (например, пользователю нужен list_users для плагина редакционного рабочего процесса)
• Встроенный Administrator слишком широк (например, разработчику нужен доступ к плагинам, но он не должен касаться учётных записей пользователей)
• Вы управляете сетью Multisite с дифференцированными обязанностями на разных сайтах

Для команд, управляющих WordPress наряду с транзакционной электронной почтой, рассмотрите возможность дополнить вашу стратегию ролей выделенным Email Hosting, чтобы уведомительные письма WordPress (сброс пароля, регистрация новых пользователей, оповещения о комментариях) отправлялись через надёжный, аутентифицированный почтовый сервер, а не через стандартный sendmail хостинг-сервера — распространённую точку отказа доставки, которая влияет на рабочий процесс каждой роли.

Если ваш сайт WordPress обрабатывает электронную коммерцию, членство или любые пользовательские данные, убедитесь, что ваши SSL Certificates актуальны и правильно настроены. Просроченный сертификат влияет не только на SEO — он нарушает контекст безопасности браузера, который защищает учётные данные для входа Administrator при передаче.

Ключевые технические выводы

• Возможности WordPress хранятся для каждого пользователя в wp_usermeta, а не жёстко закодированы — их можно настраивать без изменения отображаемой роли пользователя.
• DISALLOW_FILE_EDIT и DISALLOW_FILE_MODS в wp-config.php обязательны на любом рабочем сайте с несколькими Administrator.
• Возможность unfiltered_html существует как для Administrator, так и для Editor на односайтовых установках. Multisite лишает её всех, кто ниже Super Admin.
• Editor может безвозвратно удалить любую запись или страницу, включая контент других пользователей. Реализуйте стратегию резервного копирования или ревизий, прежде чем предоставлять эту роль кому-либо за пределами вашей основной команды.
• Никогда не используйте общую учётную запись Administrator. Одна учётная запись на человека, двухфакторная аутентификация обязательна, журналы аудита включены с помощью плагина, такого как WP Activity Log.
• Пользовательские роли через add_role() — правильное решение, когда ни одна из стандартных ролей не подходит — не предоставляйте избыточные права, чтобы компенсировать отсутствующую возможность.
• В Multisite Administrator на уровне сайта не могут устанавливать плагины. Это особенность, а не ограничение — это правильная архитектура для управляемых многопользовательских сред.

Часто задаваемые вопросы

Может ли Editor удалять записи другого пользователя в WordPress?

Да. Роль Editor включает delete_others_posts и delete_others_pages. Editor может безвозвратно удалить любую запись или страницу на сайте, независимо от того, кто её создал. Встроенного шага подтверждения или корзины для страниц не существует, поэтому это действие необратимо без резервной копии.

В чём разница между Administrator и Super Administrator в WordPress?

На односайтовой установке WordPress Administrator является высшей ролью. В сети WordPress Multisite Super Administrator стоит выше всех Administrator на уровне сайта и управляет общесетевыми настройками, установкой плагинов на всех сайтах и возможностью добавлять или удалять сайты из сети. Administrator на уровне сайта в Multisite не может устанавливать плагины или использовать unfiltered_html.

Могу ли я предоставить Editor доступ к настройкам одного конкретного плагина, не делая его Administrator?

Да. Используйте add_cap() для предоставления конкретной возможности отдельному пользователю или создайте пользовательскую роль, включающую стандартные возможности Editor плюс конкретную возможность, которую регистрирует плагин. Большинство хорошо написанных плагинов используют current_user_can( 'manage_options' ) или пользовательскую возможность для своих страниц настроек — проверьте исходный код плагина, чтобы определить точную требуемую возможность.

Безопасно ли иметь несколько Administrator на сайте WordPress?

Это полностью зависит от ваших операционных мер контроля. Несколько Administrator умножают поверхность атаки — каждая учётная запись является потенциальной точкой входа. Если несколько Administrator необходимы, обеспечьте двухфакторную аутентификацию для всех из них, ограничьте доступ к /wp-admin/ по IP на уровне сервера, установите DISALLOW_FILE_MODS в true и используйте плагин журнала активности для аудита всех административных действий.

Как проверить, какими возможностями фактически обладает конкретный пользователь WordPress?

Запросите базу данных напрямую или используйте плагин, такой как Members или User Role Editor. Для программной проверки используйте get_user_meta( $user_id, $wpdb->prefix . 'capabilities', true ) в пользовательском скрипте или WordPress CLI:

wp user get <user_id> --field=roles
wp user list-caps <user_id>

Команда wp user list-caps выводит каждую возможность, которой обладает пользователь, включая те, что были предоставлены индивидуально вне назначенной роли — это наиболее надёжный способ аудита учётных записей с избыточными правами.