Роли пользователей и права доступа в Drupal: как университеты контролируют, кто может что редактировать

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

Большинство руководств по этой теме достаточно хорошо объясняют механику, а затем останавливаются на общем примере. Это оставляет без ответа более сложный вопрос: как преобразовать организацию с факультетами, кафедрами, научными центрами и постоянно меняющимся студенческим персоналом в схему прав доступа, которую небольшая центральная команда сможет реально поддерживать? Ниже мы разбираем этот процесс, называя ключевые права доступа и contributed-модули, задействованные на каждом этапе.

Как работают роли и права доступа в Drupal

Каждое действие на сайте Drupal регулируется правом доступа. Каждое право покрывает одно действие или небольшую группу действий, и права определяются модулями, которые эти действия предоставляют. Вместо того чтобы выдавать права отдельным учётным записям, Drupal группирует их в роли и выдаёт роль целиком.

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

Три роли, с которых начинается любой сайт

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

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

Учётная запись пользователя 1 и почему в ней никто не должен работать

Первая учётная запись, созданная при установке, имеет внутренний ID 1 и отличается от всех остальных. Независимо от того, какие роли она имеет или не имеет, пользователь 1 может выполнить любое действие на сайте: просматривать и редактировать весь контент, редактировать любую учётную запись, менять конфигурацию, устанавливать и удалять модули, запускать скрипт обновления. Собственная документация Drupal сравнивает её с учётной записью root на Linux-сервере. Кроме того, её нельзя удалить через административный интерфейс.

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

• Действия на сайте протоколируются. Если вся веб-команда пользуется одной учётной записью, журнал не сможет сказать вам, кто изменил главную страницу.
• Роль администратора можно настроить безопаснее, чем пользователя 1, так что случайный клик не сможет удалить модуль.
• Обязанности людей меняются. Роли можно добавлять и снимать у обычной учётной записи; общие учётные данные нельзя отозвать у одного конкретного человека.
• Авторство контента фиксируется и часто отображается. Общие учётные записи делают невозможным отследить, кто написал ту или иную страницу.

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

Роли складываются, но никогда не вычитаются

Пользователь может одновременно иметь несколько ролей, и права из этих ролей накапливаются. В ядре Drupal нет механизма, позволяющего одной роли отозвать право, выданное другой ролью.

Это регулярно застаёт команды врасплох. На сайте есть роль редактора, который может удалять контент, и кто-то решает, что новым сотрудникам ничего удалять не следует, поэтому создаётся ограниченная роль редактора и назначается вдобавок к существующей. Теперь у человека есть обе роли, и право на удаление никуда не делось. Единственный способ отказать в праве — создать роль, у которой его никогда не было. Когда схема начинает требовать логики «вычитания», это сигнал переработать роли, а не добавлять ещё одну.

Модель ролей, соответствующая реальной работе университета

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

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

Что касается первого вопроса, большинство учреждений покрывают пять уровней:

• Администратор платформы. Поимённая группа из двух-четырёх человек в центральном ИТ-отделе, обладающих ролью администратора и отвечающих за конфигурацию, модули и обновления.
• Центральный редактор. Сотрудники отдела коммуникаций и маркетинга, публикующие материалы по всему сайту, включая главную страницу и страницы уровня учреждения.
• Редактор подразделения. Сотрудники факультетов и кафедр, создающие и публикующие материалы в рамках собственной области. Это, безусловно, самая многочисленная группа.
• Автор материалов. Преподаватели, студенты-ассистенты и эпизодические авторы, готовящие контент, который публикует кто-то другой.
• Просматривающий. Учётные записи, существующие для доступа к ограниченным страницам, а не для редактирования, — например, к внутренним документам, доступным только сотрудникам.

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

Предоставление кафедрам собственной редакционной территории

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

Доступ на основе разделов с модулем Workbench Access

Модуль Workbench Access создаёт контроль редакционного доступа на основе уже существующей иерархии, обычно таксономии факультетов и кафедр или структуры меню сайта. При создании контент помещается в редакционный раздел, пользователи привязываются к разделам по учётной записи или по роли, и они могут действовать только с контентом в своих разделах или разделах ниже по иерархии. Версия 2.0.5 вышла в сентябре 2026 года и поддерживает Drupal 9, 10 и 11. По имеющимся данным, его используют около восьми тысяч сайтов, а его разработка спонсировалась компанией Palantir.net при поддержке Charles Darwin University.

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

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

Когда модуль Group подходит лучше, чем разделы

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

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

По состоянию на конец 2026 года выбор версии требует внимания. Ветки 2.x и 3.x поддерживают Drupal 10 и 11, ветка 8.x-1.x завершила жизненный цикл одновременно с Drupal 10 в середине 2026 года, а ветка 4.x для Drupal 11.4 и выше находится в стадии альфа-версии. Платформа, запускаемая сейчас, не должна начинаться со старейшей ветки.

Роли в рамках multisite-платформы

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

Это также момент, в котором становится очевиден выбор между multisite и разделами. Если кафедрам нужны отдельные сайты, роли живут на уровне каждого сайта. Если им нужна лишь отдельная территория в рамках одного сайта, эту задачу решают разделы.

Права доступа, которые тихо дают всё

Некоторые права выглядят как узкоспециализированные административные удобства, но на практике равносильны передаче сайта целиком. Drupal сам отмечает самые опасные из них: право может быть объявлено с флагом ограниченного доступа в определении модуля, из-за чего на странице прав доступа рядом с ним отображается стандартное предупреждение о безопасности. Ядро использует это, например, для прав на администрирование текстовых форматов и фильтров.

На странице с несколькими сотнями флажков это предупреждение легко пролистать, не заметив, поэтому стоит назвать их поимённо.

• Администрирование прав доступа. Любой, кто им обладает, может выдать себе или кому угодно любое право на сайте, включая это самое.
• Администрирование пользователей. Позволяет редактировать любую учётную запись. В сочетании с правом выше или на сайте, где можно редактировать учётную запись администратора, это прямой путь к полному контролю.
• Администрирование текстовых форматов и фильтров. Контролирует, какой HTML разрешён и какие роли могут использовать какой формат. Ослабление формата — это способ, которым через редактор в сайт проникает внедрение скриптов.
• Обход контроля доступа к контенту. Отменяет действие любых других прав на контент, включая всё, что применяют Workbench Access или Group.
• Администрирование конфигурации сайта. Затрагивает настройки, влияющие на всю платформу, а не на один раздел сайта.
• Администрирование модулей. Установка кода — самый прямой путь к запуску произвольного кода на сервере.

Вывод из этого короткий. Эти права принадлежат роли администратора платформы и никому больше. Когда поступает запрос на одно из них, полезный ответ — спросить, что человек на самом деле пытается сделать, потому что ответом почти всегда оказывается более узкое право или назначение на раздел.

Стоит исправить одно утверждение, которое кочует по более старым текстам на эту тему: будто contributed-модули по своей природе менее безопасны, чем ядро. Contributed-модули со стабильными релизами подпадают под политику уведомлений о безопасности Drupal, и все модули, упомянутые в этой статье, находятся под этим покрытием. Что действительно различается, так это статус поддержки, который указан на странице каждого проекта, и именно его нужно проверять.

Позволить кафедрам самостоятельно управлять своими людьми

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

Именно для этого существует модуль Role Delegation. Он создаёт отдельное право «назначить» для каждой роли на сайте, так что администратору факультета можно дать возможность назначать роль автора материалов и ничего больше. Такие пользователи видят виджет назначения ролей в формах учётной записи и в массовых операциях в списке пользователей, вообще не обладая правом администрирования прав доступа. Его используют, по имеющимся данным, более чем на пятидесяти тысячах сайтов, и текущий релиз поддерживает Drupal 10.3 и 11.

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

Назначение ролей из системы идентификации кампуса

Ручное назначение не масштабируется в рамках кампуса, да и не должно. Когда сотрудники входят в систему через провайдера идентификации учреждения, атрибуты, передаваемые при этом входе, могут напрямую определять назначение роли, так что членство в группе каталога становится ролью Drupal без того, чтобы кто-либо касался учётной записи. Сторону аутентификации мы рассмотрели в статье об интеграции SSO с SAML, Shibboleth, LDAP и CAS; далее речь о том, что происходит после того, как приходит идентификационная информация.

Это обеспечивают два семейства модулей. Модуль simpleSAMLphp Authentication предлагает создание учётных записей по факту первого входа (just-in-time) и автоматическое назначение ролей на основе атрибутов SAML и по-прежнему широко применяется. Страница его проекта теперь имеет статус «минимальная поддержка», и сам его сопровождающий рекомендует вместо него рассмотреть модуль SAML Authentication, у которого гораздо более короткая цепочка зависимостей. Этот второй модуль обрабатывает назначение ролей через свой подмодуль user roles, а сопутствующий модуль сопоставляет атрибуты SAML с членством в Group для учреждений, использующих группы, а не разделы.

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

Часть, которую большинство учреждений пропускают: отзыв доступа

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

У университета — особая версия этой проблемы, потому что текучесть кадров здесь сезонная и предсказуемая. Студенческий персонал меняется каждый семестр. Академические административные обязанности меняются ежегодно. Кафедры объединяются. Ничто из этого не порождает уведомления для веб-команды.

Три привычки покрывают большую часть риска.

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

Короткий список того, кто обладает ролями администратора платформы и центрального редактора, пересматриваемый раз в семестр поимённо назначенным человеком, стоит больше, чем любой объём документации по политике.

Персональные данные и уровень прав доступа

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

В США закон FERPA разграничивает образовательные записи и информацию каталога, и решение о том, какие поля относятся к какой категории, принимает деканат, а не веб-команда. В Европейском союзе и Великобритании в том же направлении указывает принцип минимизации данных в GDPR: люди должны иметь доступ только к тем данным, которые требуются для их работы, и не более того.

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

Проверка и тестирование схемы прав доступа

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

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

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

Планирование структуры ролей

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

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

Платформы на Drupal, которые команда Drupal4edu в Drupart построила для таких учреждений, как университет Sabancı, METU и Технический университет Йылдыз, спроектированы именно вокруг этого уровня: небольшая центральная команда поддерживает согласованность платформы, а каждый факультет редактирует собственные страницы. Подробнее о нашем подходе можно прочитать на странице Drupal для образования.

Часто задаваемые вопросы о ролях и правах доступа в Drupal

Последнее обновление: 18.09.2026 16:26