2026 WordPress 7.2: права доступа на нескольких сайтах — может ли sudo mode изолировать сайты?

По официальной дорожной карте выпуск WordPress 7.2 намечен на начало декабря 2026 года, а sudo mode описан как предварительная работа над повторной аутентификацией для отдельных привилегированных действий (дорожная карта WordPress 7.2). Вывод для вас: sudo mode не изолирует сайты, а пока это планируемое направление, не готовая функция. Разделяйте доступ через роли, базы данных, файлы и процессы; решение о раздельных установках принимайте по уровню доверия между сайтами.

Эта статья пригодится владельцам нескольких независимых сайтов, которым нужно выбрать границы доступа при размещении на одном сервере.
Она поможет руководителям интернет-магазинов оценить, достаточно ли общей авторизации для команды.
Командам, обслуживающим сайты разных клиентов, — определить, когда централизованное управление становится слишком рискованным.

Последнее обновление: 1 ноября 2026 года. Статус версии и функция sudo mode сверены с официальной дорожной картой и разделом WordPress Core о версии 7.2. План выпуска и состав работ могут измениться: сам проект предупреждает, что не все перечисленные инициативы обязательно войдут в итоговый релиз.

Права доступа WordPress 7.2: что именно может проверить sudo mode

В этом обсуждении важно не смешивать две разные задачи безопасности. Повторная аутентификация проверяет, что пользователь подтверждает личность перед конкретным действием. Изоляция сайтов должна ограничивать возможность воздействовать на файлы, данные, плагины или процессы другого сайта. Одно не следует автоматически из другого.

В дорожной карте sudo mode упомянут как предварительная работа: предполагается повторно подтверждать личность перед некоторыми действиями с повышенными привилегиями. Это не подтверждение того, что механизм уже доступен в установленной версии WordPress, и не обещание, что он обязательно появится в окончательном составе 7.2. Проверяйте страницу проекта WordPress 7.2 перед обновлением планов, а до официального выпуска проектируйте защиту так, будто этой возможности нет.

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

Не планируйте защиту на основании функции из дорожной карты. Пока WordPress не подтвердил её выпуск и окончательный охват, считайте sudo mode отсутствующим и проверяйте каждую границу отдельно.

Роли WordPress не заменяют системные права

На уровне WordPress нужно различать администратора отдельного сайта и сетевого супер-администратора. В Multisite сетевые полномочия шире: управление сетью может затрагивать сайты в её составе. Официальное руководство описывает управление сетью и роли в документации по администрированию Multisite.

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

Перед выдачей доступа команде проверьте:

• у кого есть роль администратора на каждом сайте, а у кого — полномочия уровня сети;
• используют ли сотрудники общую учётную запись и можно ли заменить её персональными доступами;
• совпадают ли владельцы сайтов или речь идёт о клиентах с разными требованиями к конфиденциальности;
• кто может устанавливать и обновлять плагины, темы и ядро;
• кто имеет доступ к панели хостинга, SSH или другим системным средствам управления.

Если сотруднику нужен доступ только к одному проекту, не выдавайте ему полномочия, позволяющие управлять всей сетью. Если команда обслуживает сайты клиентов, рассматривайте каждый общий административный доступ как часть модели риска, а не как удобную настройку панели.

Multisite и отдельные установки создают разные границы

Официальная документация определяет Multisite как режим с одной установкой WordPress и одним экземпляром базы данных, который обслуживает несколько сайтов сети (обзор Multisite). Эта архитектура упрощает централизованное обслуживание, но общие компоненты означают, что права и изменения нужно оценивать в масштабе всей сети.

Для независимых установок можно разнести код и настроить отдельные базы данных и пользователей БД. WordPress описывает такую архитектуру в руководстве по нескольким экземплярам. Она даёт более удобные точки разделения учётных данных и обслуживания, но не превращает один сервер в полностью изолированные среды.

Сравнение не означает, что отдельная БД автоматически защищает сайт от любой угрозы. Это полезная граница для доступа к данным, но не замена ограничениям файлов и процессов. Аналогично, отдельный каталог не гарантирует разделения, если один системный пользователь может читать и изменять все каталоги.

Сценарий: сайты разных клиентов на одном сервере

Представьте, что ваша команда поддерживает корпоративный сайт и интернет-магазин одного владельца, а также сайты внешних клиентов. Для первых двух могут быть общими администраторы, разработчики и правила обновления. Для клиентских проектов доверие другое: владелец сайта может самостоятельно устанавливать плагины, а последствия ошибки должны быть ограничены его проектом.

В этой ситуации Multisite может быть уместен для тесно связанных сайтов одной организации, если сетью управляет одна ответственная команда. Для клиентских проектов разумнее рассматривать отдельные установки, базы и пользователей БД, а затем отдельно проверять, не выполняются ли все сайты с общими системными правами. Если требования к изоляции высокие, одного разделения баз недостаточно — нужно проектировать раздельные среды исполнения.

Плюс общей установки — меньше разрозненных точек администрирования. Минус — общие компоненты и административные полномочия увеличивают область потенциального воздействия. Плюс отдельных установок — проще назначать самостоятельные настройки, учётные данные и графики обслуживания. Минус — каждую установку нужно отдельно обновлять, проверять и включать в резервное копирование.

База данных и файлы нужно оценивать отдельно

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

Но разделение БД не становится полноценной системной изоляцией, если все сайты могут читать один каталог или выполняются от имени одного системного пользователя. В таком случае уязвимый плагин может получить доступ к ресурсам, которые доступны процессу, даже если базы разделены. Поэтому не сводите аудит к проверке наличия отдельных баз.

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

Практическая последовательность проверки:

• найдите владельца каталогов WordPress, загрузок, конфигурации и временных файлов;
• установите, от какого системного пользователя выполняется PHP и какие каталоги этот процесс может изменять;
• проверьте, не может ли процесс одного сайта записывать код или файлы другого;
• проверьте права пользователей БД и соответствие каждой учётной записи конкретным сайтам;
• определите, кто может менять конфигурацию, пароли и системные службы;
• отдельно проверьте резервные копии: кто может их читать, где они хранятся и как восстановить один сайт без изменения остальных.

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

Разные базы данных — полезный барьер для учётных данных и управления содержимым, но не доказательство полной изоляции. Проверяйте, что ещё доступно процессу сайта и системной учётной записи.

Примите решение по доверию и области возможного сбоя

Выбирайте архитектуру не по количеству сайтов и не по наличию одной новой функции авторизации, а по отношениям между владельцами и администраторами. Чем больше различаются требования к доступу, обновлениям и восстановлению, тем менее оправдано объединять проекты в одну общую административную область.

Используйте такую логику:

• Если у сайтов один владелец, общая команда и единые правила обновления, сравните удобство Multisite с последствиями общих компонентов.
• Если владельцы или команды разные, назначьте отдельные установки и учётные данные, затем проверьте системные права.
• Если ошибка в одном проекте не должна затрагивать другие, одной отдельной базы может быть недостаточно — оцените разделение процессов и окружений.
• Если плагины и темы устанавливают разные команды, ограничьте, кто может менять код, и не считайте повторную аутентификацию заменой проверке полномочий.
• Если для проекта важны восстановление и аудит, проверьте, можно ли отдельно резервировать и восстанавливать сайт, его базу и конфигурацию.

До выбора схемы заполните проверочный список по каждому проекту. Это не оценка «безопасно/небезопасно» по одному признаку, а способ не пропустить разные уровни доступа.

• [ ] Зафиксируйте владельца сайта и ответственного администратора.
• [ ] Отметьте, какие сотрудники имеют права администратора сайта и сети.
• [ ] Проверьте, используются ли общие учётные записи или повторяющиеся пароли.
• [ ] Укажите, какие установки, каталоги и плагины используются совместно.
• [ ] Сопоставьте каждую базу данных с пользователями и сайтами, которым она служит.
• [ ] Установите владельцев файлов и системного пользователя, от имени которого выполняется PHP.
• [ ] Запишите, кто может менять код, конфигурацию и системные настройки.
• [ ] Проверьте возможность отдельного восстановления каждого проекта.
• [ ] Отнесите к одной группе доверия только сайты с совместимыми требованиями и владельцами.
• [ ] Для сайтов с разными клиентами или последствиями сбоя отдельно оцените разделение окружений.

Для описания выбранной схемы полезно заранее определить, кто получает SSH-доступ, кто отвечает за установку и как оформляется передача доступа. В руководстве по доступу к серверу можно сверить общий порядок доступа; детали архитектуры и подготовки сервера фиксируйте отдельно. Это не заменяет настройку прав WordPress, БД и ОС, но помогает не оставлять управление сервером за пределами аудита.

Настройте разделение до передачи сайтов команде

Выполняйте проверку по порядку, чтобы не принять решение только по интерфейсу WordPress.

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

Затем выберите тип установки. Оставляйте сайты в Multisite, когда им действительно нужны общие административные правила и централизованное обслуживание. Используйте независимые установки, если проектам нужны самостоятельный код, настройки, учётные данные или график изменений. Для более строгого разделения оцените не только каталоги и базы, но и процессы.

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

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

Проверьте файловые и процессные границы. Сверьте владельцев и разрешения каталогов с фактическим пользователем PHP. Установите, может ли один сайт записывать в каталог другого, менять общий код или читать его конфигурацию. Если все процессы используют общие права, зафиксируйте это как остаточный риск, даже при раздельных базах.

Проведите тест доступа. Используйте тестовые учётные записи с минимальными ролями. Проверьте, что администратор одного сайта не может выполнять действия в другом через интерфейс; отдельно проверьте серверные права у ответственного системного администратора. Не проводите проверку на боевых данных без согласованного плана и резервной копии.

Закрепите обслуживание и восстановление. Для каждого сайта укажите ответственного за обновления, порядок проверки плагинов, хранение резервных копий и процедуру восстановления. Уточните, кто имеет право откатывать изменения и как команда узнает о доступности обновлений. При подготовке сервера и смене схемы заранее сверяйте этапы в порядке предоставления услуги, не предполагая, что сама инфраструктура автоматически задаёт нужные права WordPress.

После проверки оставьте короткую запись: почему выбрана Multisite или отдельные установки, какие данные и процессы общие, кто несёт ответственность и какой риск принят. Пересматривайте её при смене владельца, команды, плагинов или требований к восстановлению. Для планирования серверных расходов отдельно учитывайте выбранную инфраструктуру и условия в информации о тарифах; цена аренды не является показателем качества изоляции.

Частые вопросы об изоляции сайтов WordPress

Может ли sudo mode разделить доступ между сайтами WordPress?

Нет. В дорожной карте WordPress 7.2 sudo mode описан как планируемое повторное подтверждение личности перед отдельными привилегированными действиями. Это проверка пользователя, а не разделение файлов, данных, плагинов и процессов. Пока функция не выпущена и её окончательный охват не подтверждён, не учитывайте её как готовый механизм изоляции.

Чем Multisite отличается от нескольких отдельных установок WordPress?

Multisite использует одну установку WordPress и один экземпляр базы данных для сайтов сети. Несколько установок позволяют независимо обслуживать код и настраивать базы данных и пользователей. Это упрощает разделение доступа к данным, но не изолирует автоматически системные процессы и файлы. Выбирайте схему с учётом владельцев, администраторов и допустимого общего риска.

Как разделить права, если на сервере размещено несколько сайтов?

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

Нужны ли каждому сайту отдельная база данных и пользователь базы данных?

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

Подберите инфраструктуру под выбранные границы

Если после аудита вы оставляете связанные сайты в общей административной схеме, отдельный сервер сам по себе не создаст изоляцию между ними: роли, процессы и доступ к файлам всё равно нужно настраивать. Если же вам нужны независимые проекты, предсказуемое владение ресурсами и самостоятельный контроль над конфигурацией, аренда выделенного AMD-сервера может быть уместнее общего VPS, где окружение виртуализировано и системная граница зависит от провайдера. AmdMetal предлагает аренду выделенных AMD физических серверов в Японии и выбор операционной системы из доступных вариантов; конкретную схему WordPress, права и изоляцию процессов вы проектируете отдельно.

Прежде чем выбирать инфраструктуру, зафиксируйте, какие сайты делят администратора, код, базу и системные полномочия. Если нужен выделенный сервер для постоянного размещения таких установок, сопоставьте эту потребность с предложением AmdMetal, но не рассматривайте sudo mode как замену архитектурному разделению.

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