Как разделить доступ редактора и администратора сайта

Начните с персональных учётных записей и выдавайте каждой роль под конкретную работу. Редактору обычно не нужны настройки сайта, плагины и управление пользователями; приложению не нужна административная учётка базы данных. Я покажу порядок проверки для WordPress и объясню, где нельзя применять один список разрешений ко всем CMS.

Зачем каждому человеку отдельная учётка

Общий логин «admin» экономит секунды при выдаче доступа и отнимает возможность понять, кто именно опубликовал страницу, поменял настройки или создал новую учётку. Если пароль знают несколько человек, после увольнения одного приходится менять общий секрет у остальных и проверять, где ещё его использовали. Отдельная запись на каждого сотрудника позволяет отключить только его доступ и сохранить историю действий под понятным именем. Для этой работы мы обычно начинаем с аудита информационной безопасности, а не с установки очередного защитного плагина.

Сам по себе распространённый логин не «открывает сайт» злоумышленнику. Он может облегчить подбор, если рядом слабый или повторно использованный пароль и нет других мер защиты. Но общая учётка в любом случае портит разбор инцидента: журнал связывает действие с одним именем, а не с человеком. Поэтому заведите индивидуальные записи, назначьте владельца каждой и включите многофакторную проверку входа там, где она доступна.

В условном примере — школе керамики из поля company — директор и два менеджера работают с сайтом. Это не повод раздавать троим права администратора. Сначала фиксируем задачи: кому нужно публиковать новости, кому — менять структуру и кто отвечает за плагины. Потом создаём отдельные записи и проверяем результат входом под каждой ролью. Если редактор видит кнопку «Плагины», настройка ещё не закончена.

• Создайте отдельную учётку каждому человеку
• Уберите общие пароли и проверьте MFA
• Запишите владельца и назначение доступа

Какие роли дать редактору и администратору

В WordPress есть встроенные роли и наборы возможностей (capabilities). Роль «Редактор» может публиковать и управлять записями, в том числе материалами других авторов; у неё также есть права на страницы и комментарии. Это шире, чем «добавить новость», поэтому перед выдачей проверьте полный набор задач. Для автора, который редактирует только собственные материалы, может подойти роль «Автор». У администратора одного сайта полномочия существенно шире: среди них управление параметрами и пользователями.

Не называйте роль безопасной по одному названию. В WordPress проверяются возможности, назначенные роли, а плагины и типы записей могут добавлять собственные разрешения. Если редактору запрещено публиковать, но разрешено править чужие записи, это не минимальный доступ, а странный компромисс. Составьте короткую матрицу «задача → нужное действие → роль», затем пройдите основные сценарии тестовой учёткой: создать черновик, загрузить изображение, отредактировать страницу, открыть настройки и список пользователей.

В примере со школой менеджерам нужна публикация новостей, а не управление темой или пользователями. Вначале проверяем штатную роль WordPress и только при реальном пробеле добавляем отдельные возможности. Кастомная роль не обязана быть правильной только потому, что её назвали «Редактор новостей». Плагин управления ролями тоже получает доверие: ставьте его из поддерживаемого источника, обновляйте и проверяйте, кто может менять его настройки. Если штатного редактора достаточно, дополнительный плагин — ещё один компонент, который нужно обслуживать.

К ролям WordPress есть официальное описание ролей и возможностей. Оно полезно именно списком действий: например, Editor может управлять записями других авторов. Учитывайте также режим Multisite: там полномочия администратора сайта и супер-администратора сети различаются.

• Сопоставьте роль с ежедневными задачами
• Проверьте права на чужие записи и страницы
• Отдельно тестируйте кастомные роли и плагины

Как ограничить права пользователя базы данных

Учётная запись базы данных, указанная в конфигурации CMS, нужна приложению для штатной работы. Ей не следует автоматически выдавать административные полномочия сервера БД или глобальные права на все базы. Принцип простой: ограничить доступ конкретной базой и оставить операции, действительно нужные установленной CMS и её расширениям. При утечке конфигурации это уменьшает доступный нарушителю набор действий, но не превращает SQL-инъекцию в безвредную мелочь: чтение и изменение данных в доступных таблицах всё ещё могут быть возможны.

Не копируйте список «только SELECT, INSERT, UPDATE, DELETE» как универсальный рецепт. Установка и обновление ядра, темы или плагина может требовать изменения структуры таблиц; набор зависит от продукта, версии и способа обслуживания. Сверьте требования документации именно вашей CMS и запланируйте отдельную процедуру обновлений, если обычной учётке приложения не нужны структурные операции. MySQL позволяет назначать права на разных уровнях; используйте узкую область действия вместо глобальных привилегий.

Перед изменением прав проверьте сайт на тестовой копии: вход, публикацию, загрузку медиа, фоновые задачи и обновление компонентов. Снимите резервную копию и подготовьте доступ администратора БД для отката. После проверки убедитесь, что сайт не пишет в журнал отказов и что регламентное обновление проходит выбранным способом. Команда отказа в доступе при обновлении — не доказательство, что надо немедленно раздать все права; это сигнал определить, какая операция и на каком этапе действительно требуется.

В рекомендациях OWASP по безопасности баз данных принцип минимальных привилегий относится и к приложению, и к конкретным данным. В руководстве MySQL по привилегиям описаны отдельные операции вроде CREATE, ALTER и DROP; не выдавайте их без проверки процесса обновления.

• Выделите отдельную учётку для CMS
• Ограничьте её нужной базой
• Проверьте установку и обновление на копии

Что проверить в правах файлов и служебных учётках

Роль в админке не ограничивает процесс PHP и права файлов. Отдельно проверьте, от какого системного пользователя работает веб-приложение, что ему разрешено читать и изменять и кто может загружать или менять исполняемый код. Не делайте вывод по имени вроде www-data: это распространённое имя на некоторых системах, но конфигурация зависит от ОС и способа установки. Важно оценить фактического владельца процесса и границы доступа, а не назначить известное имя владельцем всего диска.

Сервисный сценарий не должен наследовать полномочия человека. Для резервного копирования определите, что именно он читает и куда записывает копию; для синхронизации — какие данные и в каком направлении передаются. Если один секрет используется одновременно приложением, задачей резервирования и ручными операциями, отзыв превращается в раскопки. Разнесите назначения, храните секреты в подходящем для вашей системы месте и документируйте, кто отвечает за ротацию.

Проверяйте границы между сайтами на одном сервере: компрометация одного процесса не должна автоматически давать запись в каталоги соседних проектов. Конкретный способ изоляции зависит от стека, поэтому здесь неуместен универсальный рецепт с chmod или владельцем каталога. Сверьте права с официальным руководством вашей CMS и веб-сервера, протестируйте обновления и загрузки. В журнал занесите не только итог, но и причину исключений, которые пришлось оставить.

• Сверьте фактического пользователя процесса
• Разделите учётки приложения и резервирования
• Проверьте границы доступа между сайтами

Как отозвать доступ и сохранить следы

При увольнении или потере устройства первым делом отключите индивидуальную учётную запись в CMS и отзовите связанные способы входа, включая активные сессии, если система даёт такую возможность. Затем проверьте доступы к панели хостинга, репозиторию, почте, резервным копиям и сторонним сервисам. Смените общий секрет только там, где он действительно был общим или мог попасть сотруднику; бессистемная ротация не заменяет инвентаризацию. Если у подрядчика была отдельная учётка, отключите её отдельно и оставьте запись об операции.

Не удаляйте пользователя до проверки, что CMS сохранит авторство и материалы. В WordPress при удалении можно переназначить его записи другой учётной записи; это стоит сделать осознанно, а не нажимать первый вариант. Сохраните журнал действий и проверьте недавние изменения пользователей, ролей, плагинов и параметров. Если аудит до этого не велся, честно зафиксируйте пробел и настройте журналирование на будущее — задним числом подробная история не появится.

Храните только тот срок журналов, который обоснован задачей расследования и вашими внутренними требованиями; универсальная рекомендация «ровно год» здесь ничем не подкреплена. Ограничьте круг тех, кто может удалять журнал, и предусмотрите резервирование. Для WordPress журнал событий часто реализуют отдельным поддерживаемым расширением: сначала проверьте, какие события оно фиксирует и куда пишет, затем протестируйте уведомления. Сам факт установки плагина аудитом не становится.

Принимая доступы от прежнего администратора, полезно сверить список учёток с нашей статьёй как принять ИТ-инфраструктуру. Для WordPress также есть официальная памятка о безопасности, включая управление ролями и права файлов.

• Отключите учётку и связанные сессии
• Проверьте внешние сервисы и секреты
• Сохраните авторство и журналы действий

Как проверять права после изменений

Сделайте инвентаризацию раз в установленный вами цикл и при каждом кадровом изменении. У каждой записи должны быть владелец, роль, цель и дата следующей проверки. Сверяйте фактические учётки в CMS, базе данных и панели размещения с этим списком. Отключайте неиспользуемые записи после подтверждения владельца; «может пригодиться» не является описанием бизнес-задачи. Для небольшого сайта достаточно контролируемого списка, если его действительно обновляют.

Проверка должна отвечать на конкретные вопросы: может ли редактор менять пользователей, может ли сервисная задача писать в контент, можно ли войти под общим логином, кто меняет роли, где хранится журнал? Проведите тест под каждой важной ролью после обновления CMS, плагина или темы. Если меню скрыто, это ещё не означает, что действие запрещено: проверяйте саму операцию. Так же и отсутствие ошибки при обычной публикации не доказывает, что обновление схемы БД пройдёт без нужных разрешений.

Включите уведомления только на события, на которые кто-то будет реагировать: добавление администратора, смену роли, изменение настроек или неудачные входы. Укажите получателя и порядок действий при сигнале. Слишком шумные письма быстро перестают читать, а молчащий журнал полезен только после инцидента. Результат проверки записывайте кратко: что проверили, какие исключения оставили и кто их принял. Это даёт следующему администратору опору, а не очередную легенду «так всегда было».

• Сверяйте записи с владельцами и задачами
• Тестируйте сами действия, а не только меню
• Настройте уведомления с ответственным получателем

Частые вопросы