WordPress Editor vs. Administrator Role: Повний технічний посібник

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 — повні повноваження над кожним обліковим записом користувача на сайті, включаючи можливість пониження або видалення інших Administrators
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 заслуговує особливої уваги. На стандартній одиночній установці як Administrators, так і Editors її отримують. У WordPress Multisite лише Super Admins її зберігають. Це важлива межа безпеки: без 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. Якщо ваш сайт працює на Виділеному сервері, розгляньте можливість розміщення адміністративної панелі WordPress за VPN або SSH-тунелем, а не відкривати її для публічного інтернету взагалі.

Захист ролі Editor від зловживань

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

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

WordPress Multisite: як змінюються ролі

У мережі WordPress Multisite ієрархія ролей отримує додатковий рівень: Super Administrator. Super Admin стоїть вище всіх Administrators на рівні сайту та контролює загальномережеві налаштування, активацію плагінів на всіх сайтах та створення користувачів на рівні мережі.

У Multisite Administrator на рівні сайту втрачає кілька можливостей, які існують на одиночних установках, включаючи можливість встановлювати плагіни (лише Super Admins можуть робити це в масштабах мережі) та можливість 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 є обов’язковими на будь-якому робочому сайті з кількома Administrators.
• Можливість unfiltered_html існує як для Administrators, так і для Editors на одиночних установках. Multisite видаляє її у всіх нижче Super Admin.
• Editor може остаточно видалити будь-який запис або сторінку, включаючи контент інших користувачів. Впровадьте стратегію резервного копіювання або ревізій перед наданням цієї ролі будь-кому за межами вашої основної команди.
• Ніколи не використовуйте спільний обліковий запис Administrator. Один обліковий запис на особу, двофакторна автентифікація є обов’язковою, а журнали аудиту увімкнені за допомогою плагіна, такого як WP Activity Log.
• Власні ролі через add_role() є правильним рішенням, коли жодна стандартна роль не підходить — не надавайте надмірні права для компенсації відсутньої можливості.
• У Multisite Administrators на рівні сайту не можуть встановлювати плагіни. Це особливість, а не обмеження — це правильна архітектура для керованих багатоорендних середовищ.

Часті запитання

Чи може Editor видаляти записи іншого користувача у WordPress?

Так. Роль Editor включає delete_others_posts та delete_others_pages. Editor може остаточно видалити будь-який запис або сторінку на сайті, незалежно від того, хто їх створив. Вбудованого кроку підтвердження або кошика для сторінок не існує, тому ця дія є незворотною без резервної копії.

У чому різниця між Administrator та Super Administrator у WordPress?

На одиночній установці WordPress Administrator є найвищою роллю. У мережі WordPress Multisite Super Administrator стоїть вище всіх Administrators на рівні сайту та контролює загальномережеві налаштування, встановлення плагінів на всіх сайтах та можливість додавати або видаляти сайти з мережі. Administrator на рівні сайту у Multisite не може встановлювати плагіни або використовувати unfiltered_html.

Чи можу я надати Editor доступ до налаштувань одного конкретного плагіна, не роблячи його Administrator?

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

Чи безпечно мати кількох Administrators на сайті WordPress?

Це повністю залежить від ваших операційних засобів контролю. Кілька Administrators збільшують поверхню атаки — кожен обліковий запис є потенційною точкою входу. Якщо кілька Administrators є необхідними, забезпечте двофакторну автентифікацію для всіх них, обмежте доступ до /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 виводить кожну можливість, яку має користувач, включаючи ті, що були надані індивідуально поза призначеною роллю — це найнадійніший спосіб аудиту облікових записів із надмірними правами.